I lean towards #2. The risk of #1 is that something could go wrong with denying read rights based on 2FA status (maybe they can still read some things, or maybe logging in and managing their preferences/2FA doesn't work right), and I think that's a bigger risk than the risk of #2, which is that we don't normally expect users to have only recovery codes and nothing else.

This will also be useful for T420383: Require 2FA for all accounts on donatewiki and thankyouwiki (and other fishbowl wikis, though these two wikis are more dangerous since they have raw HTML enabled).

Email recovery codes as a 2FA starter

Note we need clear guidance for them to properly setup 2FA - many new users (say, new WMF employees) may not be aware that recovery code is for single use and can not be relied forever.

recovery codes only

So we need a recovery-code-only mode, which is currently not yet supported.

This means restricting read rights isn't needed, and there is no state where a user account doesn't have 2FA.

We need to also consider legacy users. Of course we can add a recovery code to each of users, but there are no guarantee that the email of user is reachable, or even the user has an email at all.

I believe using an expiring recovery code is not enough: some private wikis may be rarely used (e.g. (1) they are no longer active but still contain useful contents for historical purposes; (2) they are used by 3rd party which does not frequently - but does - collaborate with WMF; (3) they are used by some chapter that have different usual means for communication). So for legacy users in private wikis, we should guarantee they can set up 2FA anytime when they want to use it.

Another case to consider is many users in private wikis are blocked, which means they can not login and thus can not setup 2FA. Usually they are former (for example) checkusers or stewards that no longer have access, so it is meaningless to notify them to set up 2FA (some are even globally banned by WMF). However once a user has regain such access their private wiki account should be unblocked, and we need some way to let (and require) them setting up 2FA.

After this task we should consider demoting sysops without 2FA in private wikis, since they can see more confidential content than normal users (deleted and revdelled pages and revisions, which may be contents no longer in use, but still contains PII).

Added 2026-05-09: what's more, any sysops in private wikis can create new accounts thus invite others to see the wiki's content.

Change #1297647 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@master] Mandatory2FACheckerTest: Add test for 'user' requiring 2FA

https://gerrit.wikimedia.org/r/1297647

Even without the patch above... Some (display type things) things just work

Change #1299643 had a related patch set uploaded (by Reedy; author: Reedy):

[operations/mediawiki-config@master] wmf-config: Add $wmgOATHAuthRequire2FAForAll config

https://gerrit.wikimedia.org/r/1299643

Change #1299649 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@master] Add UserModifyCreateAccountEmailHook to modify AbstractTemporaryPasswordPrimaryAuthenticationProvider::sendNewAccountEmail()

https://gerrit.wikimedia.org/r/1299649

Change #1297647 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@master] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1297647

Change #1300080 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@REL1_46] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300080

Change #1300080 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@REL1_46] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300080

Change #1300093 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@master] WIP: Add UserModifyCreateAccountEmailHook subscriber

https://gerrit.wikimedia.org/r/1300093

Change #1300102 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@wmf/1.47.0-wmf.6] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300102

Change #1299643 merged by jenkins-bot:

[operations/mediawiki-config@master] wmf-config: Add $wmgOATHAuthRequire2FAForAll config

https://gerrit.wikimedia.org/r/1299643

Change #1300104 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/extensions/OATHAuth@wmf/1.47.0-wmf.5] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300104

Change #1300102 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@wmf/1.47.0-wmf.6] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300102

Change #1300104 merged by jenkins-bot:

[mediawiki/extensions/OATHAuth@wmf/1.47.0-wmf.5] Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups

https://gerrit.wikimedia.org/r/1300104

Mentioned in SAL (#wikimedia-operations) [2026-06-10T11:57:02Z] <reedy@deploy1003> Started scap sync-world: Backport for [[gerrit:1300104|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1300102|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1299643|wmf-config: Add $wmgOATHAuthRequire2FAForAll config (T420792)]]

Mentioned in SAL (#wikimedia-operations) [2026-06-10T11:59:09Z] <reedy@deploy1003> reedy: Backport for [[gerrit:1300104|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1300102|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1299643|wmf-config: Add $wmgOATHAuthRequire2FAForAll config (T420792)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes c

Mentioned in SAL (#wikimedia-operations) [2026-06-10T12:08:08Z] <reedy@deploy1003> Finished scap sync-world: Backport for [[gerrit:1300104|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1300102|Mandatory2FAChecker: Allow getGroupsRequiring2FA() to work on implicit groups (T420792)]], [[gerrit:1299643|wmf-config: Add $wmgOATHAuthRequire2FAForAll config (T420792)]] (duration: 11m 06s)

Sending a recovery code to everyone does not solve everything. Consider:

• Users with no email set at all
• Users whose email is unreachable
• Users that missed the 2FA notification or recovery code email (e.g. email go to spam folder, or user does not check before the recovery code expiries)
• Users who do not know why they need to set up 2FA (e.g. T428733: "Two-factor authentication will be required for you to have access to this wiki" email for closed wikis)
• Previously blocked users that are later unblocked.
• (see 17:09 comment for the sixth scenario)

No matter how we do there will always users without 2FA in private wikis.

In T420792#12004658, @Bugreporter wrote:

No matter how we do there will always users without 2FA in private wikis.

Such is life. Doesn't mean they'll be able to use their account though.

In T420792#12005613, @Reedy wrote:

In T420792#12004658, @Bugreporter wrote:

No matter how we do there will always users without 2FA in private wikis.

Such is life. Doesn't mean they'll be able to use their account though.

So what will happen if they try to login (at least some friendly error should be shown if they can not log in to set up 2FA at all). We should not surprise users comes back to private wikis years later.

A simple hack would be: (1) allow crats of private wikis to recover 2FA; (2) locked out users can then ask crats to set up 2FA. This does not always work; user may not easily know who crats of some private wiki are, and some private wikis may have no crats at all.

The whole process hasn't been designed and implemented yet, but I'm sure we can cope with these cases.

I'm sure that it happens that people come back years later, but probably not that often. Many private wikis haven't been used in years.

Similarly, potentially editing MediaWiki:loginprompt or something to display information about this.

They'll also be able to reach out to T&S for help getting emails attached and/or recovery codes sent... As there's not going to be many private wiki users that don't have an equivalent presence on another WMF wiki, for example.

We explicitly don't allow email confirmation on private wikis either... Which is, yeah, a choice.

private wikis haven't been used in years

but they may contain historical information that user may want to access.

A sixth scenario is someone who want to access a private wiki for whatever reason, and then created a task to do so (e.g. T243491, T327352, T184961#4470128). One way to get a private wiki account is let an admin inside create it, but user may not know who admins are, and they may be inactive or locked out (due to not having 2FA); some private wikis may have no admins at all. Another is using createAndPromote.php script, but accounts created that way have no 2FA and can not be used until 2FA is setup

potentially editing MediaWiki:loginprompt or something to display information about this.

This should be done in software, otherwise we need to edit it in every private wikis and likely no one has accounts on every private wikis.

Sure, we can do it via WikimediaMessages, it's not a big deal.

None of this is insurmountable. Most of these private wikis aren't going to be having masses of people being signed up down the road, as an ad hoc process.

Same as the description dictates

When a new user is created, enable 2FA for them immediately, with recovery codes only.

Bugreporter, I'm going to be as gentle as possible and say that you're coming up with a whole bunch of edge cases that aren't going to be an issue with the processes in place as already described by Reedy. Please move on to something useful.