Product Safety and Integrity/Account Security

As the Product Safety and Integrity team, we want to strengthen the security of user accounts on the wikis. We are particularly focused on users with sensitive permissions. Compared to other internet platforms, an exceptionally high number of users are able to take security- or privacy-sensitive actions: stewards, checkusers, oversighters, interface administrators, and bureaucrats, to name a few groups. While these are generally trusted and competent members of the community, anyone can be phished or have their passwords stolen. If an account with such rights is taken over, it could be misused to hurt other users.

The end goal of this initiative is to technically enforce that all privileges that enable users to take security- or privacy-sensitive actions can only be performed by accounts that have enabled two-factor authentication (2FA). In 2025, we have already expanded 2FA enforcement to interface administrators, checkusers, and oversighters, and we will be expanding this further in 2026.

There are three main areas of technical development that will allow us to meet this goal:

• Improving the quality of our two-factor authentication system, by letting people register as many "factors" as they want, and by adding full support for both security keys and passkeys.
• Making two-factor authentication more widely available to the general user base, not just users with extended rights.
• Define and enforce policies that require 2FA for sensitive actions in the software, so that users whose accounts don't have 2FA can't take sensitive actions and can't be added to sensitive groups.

• March 2025 – We began technically enforcing 2FA for interface administrators, following a bulk account compromise.
• June 2025 – We began technically enforcing 2FA for checkuser and oversighters.
• September 2025 – We began gradually increasing the number of users who can opt-in to 2FA, while closely monitoring both uptake and our support desk load. We expect these gradual increases to continue through 2026.
• October 2025 – We deployed the first wave of 2FA changes, including support for multiple authenticators and security keys, and general improvements to the user experience.
• November 2025 – We deployed a form that makes it easier for users to ask for help when they have lost access to their email and need a code sent to their email to log in.
• December 2025 – We expect to deploy a second wave of 2FA changes, focused on adding support for passkeys, and further improvements to the user experience.
• Early 2026 – We expect to have implemented a more consistent and reliable mechanism for enforcing 2FA for local and global user groups in MediaWiki.
• Throughout early/mid 2026 – We expect to expand 2FA enforcement for additional privileged user groups, in defined stages and with clear advance notice.

• Support for more authentication types: Before, you had to choose between using an authenticator app or a security key for two-factor authentication. Now, you can have any number of authenticator apps, security keys, and (soon) passkeys.
• Easier 2FA across devices: Because you could previously only have one authenticator app, if you were switching to a new phone that meant that you had to disable 2FA entirely and then re-enable it. Now, you can add the new one before removing the old one.
• Recovery codes are no longer tied to your authenticator app: Before, recovery codes were directly connected to your authenticator app enrollment, but now they are separate. This means every user who has any sort of 2FA enabled now has recovery codes, and your existing recovery codes will persist even if you add a new authenticator app. As long as you have at least one 2FA method enrolled, your recovery codes stay the same.
• Regenerating recovery codes is simpler: You don't have to disable and re-enable 2FA to generate a new set of recovery codes, you can click a button to do it automatically.
• Improved account security page: We redesigned Special:AccountSecurity to serve as a central location for all account security settings and actions. From this page, you can change your password, add or remove 2FA methods, and download or regenerate recovery codes.

We will continue to improve the Special:AccountSecurity page and add features to it. We are targeting the end of 2025 for most major improvements to this page.

Historically, we have supported only one-time codes through a single authenticator app (like Google Authenticator) for two-factor authentication, with some limited experimental support for security keys (like YubiKeys).

After our recent improvements, users can now use any combination of multiple authenticator apps and multiple security keys.

We are next planning to add support for passkeys. This will allow users to store a passkey on their device or in their password manager, and then use that during login. Passkeys will generally be both the simplest and most secure way to log in to a user account, and we will encourage users to register as many passkeys as possible.

While some passkeys can be synced across multiple devices, not all devices support this and not all users will want this. So for the time being, we will be supporting passkeys conservatively, and treating them as always stored only in the device with which the user is registering the passkey.

To reduce the risk of users locking themselves out as they change devices, we will not support having a passkey as the only registered 2FA method. Users must first set up another method (an authenticator app or a security key) before they can register a passkey.

Some users who don't have 2FA are asked for a code from their email when they log in (see also this FAQ entry). This isn't the same as 2FA, but it's similar, and it can cause users to be locked out of their account if they have lost access to their email address. Previously, users in this situation could only ask for help recovering their account by sending an email. We now direct these users to an on-wiki form instead. This makes it easier for users to submit account recovery requests, and allows WMF staff to process these requests more quickly.

Only users with certain kinds of extended rights, or those who have been specifically added to a particular group, can consistently see an option in their settings to manage two-factor devices. We are now gradually testing allowing more users to enable 2FA, while closely monitoring the enablement rate, to maintain confidence that any increase to the rate of recovery requests can be handled by our support desk.

Some privileged user groups have policies stating that group members should meet certain requirements, such as a minimum account age or having 2FA enabled. Historically these requirements have been enforced by users checking manually whether other users meet the conditions, or by ad hoc technical means that only work for particular groups. We are improving this by introducing a way for the software to enforce any group policy. Groups can be configured via $wgRestrictedGroups to require that group members and/or group updaters meet certain conditions. The temporary account IP viewer group is now configured this way to require a minimum number of edits and a minimum account age, and we are currently working on migrating 2FA-requiring groups to use this system.

We have not finalized the set of roles for which we expect to enforce 2FA. We have been consulting with stewards and other users with extended rights, and we will remain sensitive to the impact on the user experience of our volunteers.

In our announcement of enforcing 2FA for checkusers and oversighters, we specifically mentioned bureaucrats as a role that we believe likely needs 2FA enforcement, given its ability to grant and revoke rights to other users. We also acknowledged the need to improve our 2FA system before enforcing it further, which is what we’re currently focused on doing before we make decisions on additional roles.

Starting in 2025, following the compromise of ~36,000 user accounts, we introduced an email confirmation step when we need additional confidence in a user login. While the conditions for when this happens may change over time, this typically occurs when logging in from unknown devices and/or network locations.

For most users, confirming a code from your email should be very infrequent. Users who clear their cookies and rotate network addresses will experience it more frequently.

If this is causing you issues, here are some options to make it easier:

• If you frequently clear your cookies, allow list the loginnotify_prevlogins cookie for auth.wikimedia.org. This cookie is not your session cookie and is much less sensitive. Leaving it present helps the platform know that you’ve used this device to successfully login before.
• If you can, enable two-factor authentication (2FA) – this will disable email confirmation for your account. As of 2025, two-factor authentication is now much easier to use, and will continue to get easier.
• If you do not yet see the option in your settings to enable 2FA, and you are experiencing frequent email confirmation checks, you can request the two-factor tester right from a steward or (if there are bureaucrats on your wiki) a local bureaucrat. You can then opt in to 2FA for your account.

The only known way to opt out of this is to remove your email address from your account. It is a necessary baseline for the security of Wikipedia in the current day.

Every human, no matter how experienced or technically capable, can have their passwords stolen, and the risk of user account takeover is not just borne by individual users. The integrity and reputation of Wikipedia as an encyclopedia written by and for human beings depends on keeping a tolerably high bar for authorized use of its user accounts.

Subscribe to the newsletter

• 
  Roan Kattouw
  Software Engineer, Key Result owner
  roanwikimedia.org
• 
  Szymon Grabarczuk
  Movement Communications
  sgrabarczukwikimedia.org