Skip to main content
Two-factor authentication (2FA) adds a critical second verification step beyond a username and password. For secure operations at scale, require 2FA for organization members, outside collaborators, and billing managers wherever possible. This guide explains GitHub’s supported 2FA methods, the operational risk of enabling enterprise-wide enforcement without preparation, and a practical runbook to avoid outages. Why this matters: enforcing 2FA protects code, secrets, and CI/CD access. But at enterprise scale, enabling enforcement without an audit can immediately remove large numbers of users (and bots) from organizations — causing significant operational disruption.

​
GitHub 2FA methods (overview)

GitHub supports three primary 2FA methods. Use this table to compare security, usability, and typical use cases. First — security keys
  • Hardware security keys (FIDO2/WebAuthn) require a physical device and mitigate phishing and remote account takeover risks.
  • Best practice for privileged accounts (admins, CI deploy keys owners, and service accounts with elevated access).
Second — TOTP applications
  • TOTP apps (Google Authenticator, Authy, 1Password) generate local, time-based codes.
  • They work offline and, depending on the app, can support multi-device backups and account recovery.
TOTP apps are typically the best balance of security and usability for most teams — they avoid phishing risks from SMS, work offline, and support recovery options in many authenticators.
A presentation slide about TOTP (time-based one-time passwords) showing a phone with a six-digit code and a countdown ring. It notes "GitHub's recommended method," "codes generated locally," and lists example apps: Google Authenticator, Authy, and 1Password.
Third — SMS/text messages
  • SMS is the least secure option due to SIM swapping and interception risks.
  • GitHub is deprecating SMS for 2FA; plan to migrate users off SMS where possible and use it only as a last resort.
A presentation slide about SMS authentication showing a phone stamped "DEPRECATED" and labeled "The least secure method." It notes SMS is being phased out and should be used only as a last resort when TOTP apps aren't viable.

​
Why enterprise-wide enforcement is dangerous

Turning on “Require two-factor authentication for everyone” at the enterprise level is conceptually simple — flip a switch — but operationally destructive if you haven’t audited and prepared your users. When you enable this setting for all organizations under an enterprise, GitHub immediately evaluates every member’s 2FA status. Any account without an active 2FA method is removed from every organization in the enterprise with no warning and no grace period. This is true for user accounts and bot/service accounts.
A presentation slide titled "One Simple, Dangerous Switch" showing a green toggle labeled "Require two-factor authentication for everyone." A small diagram below notes it's "simple as a concept" but "dangerous as an operation" unless accompanied by a proper runbook.
Example impact:
  • If you have 3,000 developers and 400 have not enabled 2FA, enabling enterprise-wide enforcement instantly removes 400 developers and any associated bots from all organizations. Expect high-priority incident tickets, blocked CI, and disrupted deployments.
The rule: audit first, enforce second. Never flip the switch without a clear, communicated plan.

​
Practical runbook to enable 2FA safely

Follow these operational steps to minimize disruption:
  1. Audit current 2FA status
    • For each organization: open the People tab, apply the two-factor authentication filter, and export the CSV of users lacking 2FA.
    • Aggregate CSVs across organizations to create a master list.
  2. Cross-reference and prioritize
    • Compare the master list against your employee directory and service-account inventory to identify active staff, contractors, and bots.
    • Prioritize high-risk accounts (admins, CI users, deploy keys) to bring into compliance first.
  3. Communicate and provide resources
    • Announce the enforcement timeline and provide step-by-step setup guides for security keys and TOTP apps.
    • Offer help channels and scheduled office hours for users needing assistance.
  4. Set a compliance window
    • Provide a reasonable compliance period (example: 14 days) and send automated reminders during the window.
  5. Validate before enforcing
    • Re-run exports after the compliance window to validate progress.
    • Manually confirm any remaining accounts that must be handled by exception (e.g., onboarding new hardware keys).
  6. Enable enforcement and monitor
    • Enable enterprise-wide 2FA enforcement only after confirmation of compliance targets.
    • Monitor support queues, CI runs, and org membership logs for any unexpected removals.
A slide titled "Audit First, Enforce Second" showing a two-step workflow: audit GitHub org users for disabled 2FA (export CSV) then enforce access changes. The graphic includes a mock "People" page, steps to cross-reference the employee directory, send a 14-day notice, and run enforcement on day 15.
Analogy: think of enforcement as a new strict bouncer at a club. The old bouncer let people in with little checking; the new bouncer checks every ID and immediately turns away anyone without one. If you don’t announce the policy, you’ll have an angry crowd outside and empty seats inside — and the same goes for developer productivity.
An illustration titled "The New Bouncer" showing people queuing outside a club as a person labeled "new" checks IDs at the entrance. A regular-looking patron appears annoyed while the club's interior shows empty stools.

​
Key facts to remember (for exams and operations)

  • Enterprise-level enforcement of required two-factor authentication immediately removes non-compliant members from organizations; there is no grace period and no warning.
  • Enterprise-level enforcement overrides organization-level 2FA settings.
  • Prioritize security keys and TOTP apps; deprecate SMS where possible.
Do not enable enterprise-wide “Require two-factor authentication for everyone” without auditing members, notifying users, and providing a compliance window. The action is immediate and can remove active users and bots from organizations.
Use the audit-first, communicate-second, enforce-third pattern to scale 2FA safely across your enterprise.

Watch Video