Help talk:Two-factor authentication/Archives/2026

Global 2FA?

Since accounts use a global login, is it possible to enable 2FA globally? Or does it work independently from project to project? Thanks! It's moon (talk) 17:22, 22 January 2026 (UTC)

@It's moon It works globally, if you enable it from one project, it will be activated for all project, like your wikimedia username and password —MdsShakil (talk) 17:25, 22 January 2026 (UTC)

Awesome! Thanks ^^ It's moon (talk) 17:31, 22 January 2026 (UTC)

Setting-up 2FA

Hello, was thinking of setting-up 2FA as looks like it will be a requirement in the future. But cannot work out how to do this as I do not have another device, just a laptop running Windows 11 with Firefox browser. Just want it for Wiki work, so what is the best option? Keith D (talk) 02:21, 27 January 2026 (UTC)

You can install a windows application that supports TOTP. Here is an outdated page with some info: w:en:Special:PermaLink/1327995122#Enabling_2FA_on_desktop_and_laptop_computers. — xaosflux ^Talk 15:42, 27 January 2026 (UTC)

That "outdated" page you linked (w:en:Special:PermaLink/1327995122) explains in detail how to setup 2FA on smartphones & tablets, and laptop & desktop computers. Can those sections be reinstated in the current version of this help page? They still are relevant. —Bruce1ee^talk 07:04, 28 January 2026 (UTC)

@TBurmeister (WMF): I'm not sure if that sort of thing belongs on this page, or on another - but agree that there is information drain going on with centralizing to this page as is. — xaosflux ^Talk 11:06, 28 January 2026 (UTC)

Thanks for bringing this up! I agree the Help page on Meta could make it a little clearer that "authenticator apps" aren't necessarily always phone or tablet apps. On that page, we chose to link to w:Comparison_of_OTP_applications instead of trying to list a large number of apps for all the different platforms, but since this could be a blocker for some users, it should be called out. I just revised the Meta page like so: https://meta.wikimedia.org/w/index.php?title=Help:Two-factor_authentication&diff=prev&oldid=29994906

I didn't add all the content from w:en:Special:PermaLink/1327995122#Enabling_2FA_on_desktop_and_laptop_computers, because I don't think the Meta-Wiki page should include that level of detailed instructions. My reasoning:

1. I think explaining step-by-step how to install and set-up specific 2FA or password manager applications is too much information to include on the Meta-Wiki 2FA Help page;
2. That info doesn't add a lot of value because the setup process for each app is not that complicated;
3. Maintaining that type of detailed instruction is difficult as the apps change over time, and is usually better done by the app's developers or community.

However, I'm open to discussion about this and would be happy to work towards a mutually-agreeable state if my arguments don't convince you :-) TBurmeister (WMF) (talk) 15:56, 29 January 2026 (UTC)

I agree that THIS page isn't the right place to give that help, but before pushing this back out to local projects perhaps we consolidate to project space here, like Project:Two-factor authentication tips or the like? — xaosflux ^Talk 19:06, 29 January 2026 (UTC)

Vulcan agrees, a centralised place for 2FA and passkey would be helpful, especially for passkey/WebAuthn (Project:Two-factor authentication/Tips or similar name). Vulcan❯❯❯Sphere! 09:23, 31 January 2026 (UTC)

Can you specify what tips or information you think is still missing from the Help page for 2FA, now that it includes information about desktop apps for managing 2FA tokens? The only information I think is still excluded is the desktop application-specific installation instructions, and (for the reasons 2 & 3 in my response above) I think the drawbacks of maintaining that info in any centralized location outweigh the benefits. TBurmeister (WMF) (talk) 15:32, 2 February 2026 (UTC)

@User:Keith D: There is a solution. Contact me if you encounter a problem. Taylor 49 (talk) 03:58, 8 February 2026 (UTC)

Passkey on Firefox

Tracked in Phabricator:
Task T415089

I'm on Firefox with the KeePassXC-Browser add-on to connect it to my KeePassXC instance. Even though I have 2FA and I've enabled passkeys in the add-on, the button is still grayed out. Manually enabling it with inspect element and then clicking it works though and I've been able to use the added passkey as a 2FA with the same setup.

It seems like the passkey support detection of Firefox might not work 100% of the time. Laura240406 (talk) 12:30, 8 February 2026 (UTC)

Vulcan can confirm about the greyed-out passkey button on Firefox (on Linux), even with Bitwarden installed and running. There is a workaround for Firefox on Linux users that Vulcan can recommend, adding passkey from Android (or iOS) Firefox should work (Vulcan added passkeys to both Google Password Manager and Bitwarden from Android) Vulcan❯❯❯Sphere! 13:53, 8 February 2026 (UTC)

This appears to be a general issue with Firefox on Linux: it tells us that it doesn't support passkeys, even when a browser extension that supports passkeys is installed. To work around this, we plan to always enable the button in Firefox on Linux, even if it reports no passkey support. This change will most likely go live next week. See task T415089 for more details. Roan Kattouw (WMF) (talk) 23:12, 10 February 2026 (UTC)

Special:AccountRecovery

• @TBurmeister (WMF): - should we have the I can't use any of my authentication methods start using this intake form to send things to WMF, or do they only want standard email? Using a contact form is generally more accessible. 13:10, 9 March 2026 (UTC)

  Which intake form do you mean? When I was working on these doc revisions and asked the Security team about the contact methods listed in the doc; emailing ca@wikimedia.org was the primary method they said people should use. Adding @EMill-WMF to confirm and also advise about the intake form (if you can link to it that would help, thanks). TBurmeister (WMF) (talk) 17:50, 10 March 2026 (UTC)

  The link is the header for this section (it isn't available when you are logged in, try "open in private/incognito/etc tab". — xaosflux ^Talk 18:05, 10 March 2026 (UTC)

  It seems to have been born from the emailauth processing team, but could serve this purpose as well. — xaosflux ^Talk 18:07, 10 March 2026 (UTC)

  From phab:T399742. — xaosflux ^Talk 18:08, 10 March 2026 (UTC)

  At the moment, Special:AccountRecovery goes directly into our EmailAuth recovery flow. 2FA resets wouldn't be handled in that flow, and might be swept up in the at-scale triaging which could be annoying/confusing to users. I think in the future we could adapt that form to allow for 2FA resets to be sent through in a similar way but at the moment we'd prefer an email to ca@. Joe Sutherland (Wikimedia Foundation) (talk) 22:55, 10 March 2026 (UTC)

  Thanks Joe - we'll leave it out then - it may be reusable or adaptable in the future if needed. — xaosflux ^Talk 19:14, 11 March 2026 (UTC)

This section was archived on a request by: — xaosflux ^Talk 19:14, 11 March 2026 (UTC)

Please do not lock us out

I have a following problem with the hard 2FA requirement: if 2FA does not work for some reason:

• broken/lost/misplaced phone
• broken WebAuthn key (happened to me, that is why I am writing this)

the person affected will not be able to log in to their account for even for a simple things, such as editing or community participation.

I think this is a very important thing - being away on a hackathon and having 2FA broken is really a big issue.

I read in the release notes that we finally can have recovery codes independent of the 2FA method chosen (at least they should work for WebAuthn now). This is very good news but I am not sure I want to travel with my recovery codes printed to Wikimania for example.

What if we will have to remove the last 2FA method from the account with the help of ca@ (because the hardware is dead) - will I also lose the extended rights?

Most people can probably survive such a disaster for some days without advanced rights, but having account access blocked can be very frustrating as it was to me.

If the user has no other device for the second factor, do we really think that "2FA" done in software on the same computer (as suggested in another thread here) is the security we want?

While on mobile, using 2FA can be hard or impossible or insecure - my security key didn't work with the mobile phone at all (some NFC issue probably). The help page says the mobile apps do not support security keys. Having 2FA application on the same phone we use to enter the password is ... questionable.

Why change this now? Do we have some new data that mandate this and keeping the current setup (extended rights temporarily disabled) is no longer good? Is there a more long term plan about how this thing should develop? For example, if we realize that the hijacking of a logged in session becomes a prevalent problem, you might need to change the set up again and introduce additional restrictions. You might want to introduce a periodic re-authentication for example.

Are the alternatives that were considered?

• What is wrong with status quo?
• can we think of other solutions, such as "sudo mode" - enabling extra flags on demand with 2FA?
• some other solutions?

Otherwise we might end up in a sad corporate-style reality (I know this first hand, which is another reason why I write this) where I need to pull out my authenticator multiple times a day to continue working.

 « Saper // talk »  20:45, 23 February 2026 (UTC)

Hi @Saper and sorry for late response.

Until now, 2FA couldn't have been fully enforced for Wikimedia accounts, because the OATHAuth extension supported only a single authentication method at a time. This meant that there were numerous legitimate reasons for 2FA-required users to turn off their 2FA (eg., when switching from one method to another). Recently, Product Safety and Integrity team updated the extension, so that multiple authentication methods are now supported. Now, it's possible to have a few YubiKeys, authentication apps and/or passkeys at once at your account. This makes it much less likely to lose all authentication methods.

What also changes it the recovery process. Trust & Safety used to disable user's 2FA, so that they would log in with just password. Now, T&S will generate additional recovery codes, instead. This enables user to log in to their account again and adjust 2FA as they wish (add another authentication app or whatever else they wish). In this model, 2FA will never be disabled during recovery.

And regarding the "second factor-same device" thing. What we'd like to prevent primarily are attacks like credential stuffing (similar to what we saw during spring 2025). Even if you log into Wikimedia on your phone, using authentication app there, an attacker who doesn't have access to your phone won't be able to log in.

Status quo is for sure safer than no 2FA enforcement at all. However, there's still a significant vulnerability. If an attacker obtained a password to an account with extended rights, they could log in, set up 2FA on that account and make use of the sensitive permissions. The current 2FA enforcement wouldn't prevent them from doing any harm. We perceive this as a significant weakness in the system. In fact, 14% of users who – by policy are required to have 2FA – don't have it.

Introducing a "sudo mode" is something that is considered for future (without exact specifications yet). However, if we wanted to mitigate the issue like it's now (attacker logs in — configures 2FA — has full access), we probably would need to mandate having 2FA on an account. And the "sudo mode" would be a mitigation primarily against potential malicious user scripts, which could try to perform mass sensitive operations on behalf of another user.

Regards, MSzwarc-WMF (talk) 19:28, 2 March 2026 (UTC)