Slow Roll 2FA Requirement in GitHub

[bnb]

hey y'all!

currently, when you enable 2FA for an org you force out everyone who doesn't have 2FA. I can totally see why this is the default that was chosen, but in a larger org that doesn't have it enabled it's extremely frustrating to have to build out an internal communications plan on how to get everyone on 2FA + take on the additional support burden of re-enabling people who missed the memo.

it would be exceptionally lovely if GitHub provided options for this. Specifically, the option that immediately comes to mind is that rather than booting people, just giving them the option next time they log in to GitHub.com to add 2FA or to remove themselves from the org. Perhaps using a similar barrier to the SAML barrier that exists for repos in an org - even if they're public - for when a user hasn't authed with SAML in the past day, except have it provide that option.

Outside of the OSPO lens, this would also have been an exceptionally useful feature in Node.js when we were enabling 2FA for the nodejs org - we booted several hundred people and had to add a good number back, IIRC. So, this could definitely also generally help security for open source projects and ease a burden on their maintainers.

Obviously this is slightly more thorn-y and edge-case-y than "if you don't have 2FA enabled, you're removed" but the initial investment from GitHub on this has the potential to save tremendous numbers of hours across many companies while lowering the barrier to every account on GitHub having 2FA enabled.

[ljharb]

Yes please; the eviction also means that any laboriously constructed team and permission setup gets lost. That consequence is why i haven't enabled 2FA in every github (or npm) org - because it's simply not worth evicting even one person to get there.

[ahpook]

Heyya! Thanks for the post - we dug into this a bit and I think we will be able to improve the 2FA situation. You have probably seen the recent blog post about our push to get 2FA enabled across all of GitHub by the end of the year, and this is definitely helpful feedback to keep the entire site from having these kinds of problems.

One solution that came up is a modification of the 2FA enforcement timeline that's described in that post:

... But where you as an org admin would have the option to start the notifications/prompting on your own schedule, and, importantly, the consequences of a user being past the deadline would be restricting their access to org-owned resources, rather than removing their membership.

@bnb This flow wouldn't provide the "Enable 2FA, or remove me from the org" flow you described (because it's derived from the way the whole site will get enabled), but would it be a viable alternative for you?

[ljharb]

It would absolutely be a viable alternative for me, fwiw.