12.1 Two-Factor Authentication and Passkeys

Why GH-900 tests account security before repository admin

Domain 6 of GitHub Foundations (GH-900) is 10–15% of the exam. The January 2026 outline opens that domain with describe how to secure accounts with 2FA and passkeys. Repository roles, Enterprise Managed Users, Copilot policy, branch protection, and organization settings all assume the person signing in is actually the account holder. If a GH-900 stem is about who can log in rather than who can push, start here.

Two-factor authentication (2FA) is an extra layer of security at sign-in. After username and password, GitHub requires a second form of authentication that only you know or have. GitHub generates an authentication code (or a cryptographic challenge) whenever someone tries to sign in. The attacker needs both the password and the second factor.

As of March 2023, GitHub required all users who contribute code on GitHub.com to enable one or more forms of 2FA. Eligible groups received an email and on-site banners and had a 45-day enrollment period. If you never received that notice, you were not in a mandated group—GitHub still strongly recommends 2FA. GH-900 will treat contributing-user 2FA as required on GitHub.com, not as an optional hobby setting. The mandate is about GitHub.com contributing users, not a claim that every GitHub Enterprise Server account was forced onto 2FA on the same date.

Primary methods: TOTP and SMS

You enable 2FA under Settings → Password and authentication. GitHub's documented first methods are:

• A time-based one-time password (TOTP) app on a phone or desktop. The app generates a rotating six-digit code (SHA1, 6 digits, 30-second period). GitHub is app-agnostic—search for a TOTP app; cloud-backed apps can restore codes if you lose the device. During setup you scan a QR code or type the setup key (the TOTP secret). To enroll several devices, scan the same QR (or save the setup key) on each device during setup.
• SMS (text message) to a mobile number in a country where GitHub supports SMS authentication. Carrier rates may apply. You complete a CAPTCHA, enter the number, and type the code GitHub texts you.

GitHub strongly recommends TOTP over SMS, with security keys as backups instead of SMS. SMS can be intercepted, does not resist phishing the way WebAuthn does, has unreliable delivery, and is not supported in every country. Organizations and enterprises can prevent content access for members who have SMS 2FA. If your org made that decision, enable TOTP and disable SMS. Outside collaborators may be blocked from enabling SMS 2FA when the org or enterprise disallows it.

After you turn 2FA on, the account enters a 28-day checkup period. Successfully performing 2FA during those 28 days ends the checkup. Otherwise GitHub prompts you on the 28th day in an existing session. If you cannot complete 2FA then, you must use the provided shortcut to reconfigure 2FA and keep access.

You can reconfigure 2FA methods without disabling 2FA entirely, which keeps recovery codes and membership in organizations that require 2FA. Disabling 2FA while you belong to a 2FA-required organization is a different, harsher path (covered with org policy below).

After TOTP or SMS: security keys, GitHub Mobile, and passkeys

Once TOTP or SMS is on, you may add:

WebAuthn is the browser standard behind security keys and passkeys. It succeeds U2F and works in modern browsers. Not every FIDO authenticator can be a passkey. You can still register those authenticators as security keys. Security keys verify user presence only, so they count as a second factor and must be used with your password. If you lose the key, you still sign in with TOTP or SMS.

GitHub Mobile as 2FA is optional and not a first method. Install the app, sign in, and allow push notifications. You then approve browser sign-ins from that device. If you later lose GitHub Mobile, TOTP, SMS, or security keys still work. Do not tell the exam that Mobile replaces TOTP setup.

If you are a member of an enterprise with managed users, you cannot configure 2FA on the managed user account unless you are signed in as the setup user. Everyone else gets 2FA from the identity provider (IdP). That fact belongs with Enterprise Managed Users in 12.3; it is the exception to “everyone sets 2FA in GitHub settings.”

Passkeys, recovery codes, and organization 2FA requirements

Passkeys replace the password-plus-2FA dance—not your fallback

A passkey lets you sign in to GitHub in the browser without typing a password. If 2FA is enabled, the passkey satisfies both password and 2FA, so sign-in is one step. If 2FA is not enabled, a passkey skips new-device email verification. Passkeys also work for sudo mode and password reset.

A passkey is a public/private key pair stored by an authenticator you control: an iPhone or Android device, Windows Hello, a FIDO2 hardware key, or a password manager. The authenticator proves you are present with a PIN, passcode, biometric, or device password. GitHub never receives the private key. Passkeys are bound to the site domain (for example GitHub.com) and need a secure connection, so the browser refuses lookalike phishing sites. That phishing resistance is why GitHub describes passkeys as much harder to attack than SMS or TOTP, which can be phished.

Synced (cloud-backed) passkeys (Apple iCloud, Android, some password managers) work across devices on the same service. Device-bound passkeys stay on one authenticator and cannot be backed up or moved. FIDO2 hardware keys are device-bound but portable (USB, NFC, or Bluetooth). Nearby-device flows let a laptop without a local passkey complete sign-in via a QR code or push to a phone that holds the passkey.

To reduce account lockouts, GitHub tells you to also configure a fallback 2FA method such as TOTP or SMS. If you already registered a passkey-eligible security key for 2FA, GitHub may prompt you to upgrade it to a passkey at sign-in or in account settings. Platform authenticators such as Windows Hello, Face ID, or Touch ID can be registered as passkeys. You still need TOTP or SMS configured first before adding a passkey through the 2FA wizard GitHub documents.

If you do not enable 2FA, GitHub may still ask for extra verification the first time you sign in from a new or unrecognized device.

Recovery codes are the last door; Support will not pick the lock

When you configure 2FA you download recovery codes. Store them offline. If you lose the phone, a recovery code signs you in. GitHub's warning is exam-critical: for security reasons, GitHub Support will not restore access to accounts with 2FA enabled if you lose your 2FA credentials or lose access to your account recovery methods. That is not “Support might help after a ticket.” It is a documented will not.

If you cannot use any recovery method, you have permanently lost the account. GitHub does allow unlinking an email address from a locked account so you can attach that email to a new or existing account. Unlinking email is not the same as recovering the old username, repositories, and contributions.

Organization owners can require 2FA—and can ban SMS

Organization owners can require 2FA for members, billing managers, and outside collaborators. Enterprises can require it for organizations they own. The owner's own account must already have 2FA before the org requirement can be turned on.

Consequences GitHub documents:

• Members and billing managers without 2FA cannot access organization resources until they enable it. They keep membership (and consume seats).
• Outside collaborators without 2FA are removed, lose repository access, and lose forks of the organization's private repositories. If they enable 2FA within three months, an owner can reinstate former access.
• Unattended bots and service accounts that are outside collaborators also need 2FA or they are removed.
• An outside collaborator who disables 2FA later is removed automatically.
• The sole owner of a 2FA-required org cannot disable 2FA on their personal account without first disabling the org requirement.

Owners can additionally only allow secure two-factor methods: passkeys, security keys, authenticator apps, and the GitHub mobile app. Users who have only SMS (an insecure method) are blocked from org resources until they add a secure method.

If you are an outside collaborator on a private repository of a 2FA-required org, you must leave the organization before you can disable 2FA. Members and billing managers who disable 2FA lose org resource access until they re-enable it; outside collaborators also lose private forks and need an owner to restore access.

Exam traps for D6.1

• March 2023 is the contributing-user GitHub.com mandate, not “2FA was invented in 2023.”
• TOTP or SMS first. Security keys, GitHub Mobile, and passkeys are additional methods after that baseline.
• Security key ≠ passkey. A security key is a second factor with a password. A passkey can complete password + 2FA in one step.
• Keep a fallback. Passkeys do not retire TOTP, SMS, or recovery codes.
• Support will not restore a 2FA-locked account if credentials and recovery methods are gone. Unlinking email is not account recovery.
• Org 2FA is an owner policy on top of GitHub's contributing-user rule. Members keep seats without 2FA; outside collaborators are removed.
• SMS can be forbidden by org or enterprise policy even when GitHub.com still offers it.