MFA and account security — the first line of repository defence

Every control in this part rests on one assumption: the identity behind a push is the human it claims to be. Branch protection restricts who can push. Required reviews record who approved. Signed commits attest who authored. All three are statements about an account, and an account with a reusable password is a statement anyone who has phished that password can make. Multi-factor authentication is the control that makes the rest of this part mean something.

The account is the perimeter

An infrastructure repository is rarely broken into through the repository. It is entered through an engineer, and the usual sequence is short: a credential is phished or reused from an unrelated breach, the attacker signs in, and from that moment every downstream control is being applied to an attacker wearing a legitimate identity. The attacker does not need to defeat branch protection - they inherit whatever the account was allowed to do.

flowchart LR
    A["password reuse or phish"] --> B["forge sign-in"]
    B --> C{"second factor required?"}
    C -->|"no"| D["session as the engineer"]
    C -->|"phishable factor"| E["relay attack succeeds"]
    C -->|"hardware key"| F["origin mismatch, sign-in fails"]
    D --> G["push, token mint, settings change"]
    E --> G

The branch on the right is the whole point of this lesson. A hardware-backed factor is bound to the origin the browser is talking to, so a proxy that looks like the forge to the user gets a signature that the real forge will not accept.

The factor hierarchy

Not all second factors are equivalent, and treating them as equivalent is how teams get a false sense of coverage:

• Hardware security keys and passkeys (WebAuthn). The challenge is signed against the origin. A relay proxy cannot forward it. This is the only factor that survives a well-built phishing page.
• TOTP authenticator apps. Six digits with a 30-second window. Strong against password reuse, weak against a live relay - the victim types the code into the attacker’s page and the attacker replays it within the window.
• Push notification approval. Convenient and vulnerable to fatigue: a stream of prompts at 02:00 gets approved.
• SMS. Delivery is not authentication. SIM swap and carrier-side interception both defeat it. Acceptable only as a strictly better alternative to nothing.

Recovery without a back door

Recovery codes are the account’s last resort, and they are credentials with no second factor in front of them. Treat them as the highest-value secret an engineer holds:

• Generate them once, store them in the team password manager under an entry only the holder and the security team can read, and never in a repository, a note file, or a chat message.
• Regenerate the set whenever one code is used. A used code means the set was consulted, which means the set was exposed to whatever read it.
• Record the date of the last regeneration. An account whose recovery codes were printed four years ago and stored in a drawer has a four-year-old bypass attached to it.

Enforcing it across the organisation

Enforcement at organisation scope is the step teams delay because it can lock people out. Sequence it:

1. Report first. Publish the list of members without MFA and give a deadline.
2. Convert machine identities before the deadline. Bots, integration users, and any account a pipeline signs in as must move to tokens, deploy keys, or a forge app, because interactive MFA cannot be satisfied by a script.
3. Enable the requirement. Members still without MFA are removed from the organisation and must be re-invited, so confirm the list is empty first.

ORG=example-org
gh api "/orgs/$ORG/members?filter=2fa_disabled" --paginate \
  --jq '.[].login'

Production discipline

1. MFA is a joining condition, not a project. An account without a second factor does not get write access to an infrastructure repository, on day one, without exception.
2. Phishing resistance is the only ranking that matters. Count hardware keys and passkeys separately from TOTP in your coverage reporting; a dashboard that shows “100% MFA” while the estate is entirely TOTP is measuring the wrong thing.
3. Every enforcement change is announced before it lands. Locking out an on-call engineer at 03:00 because MFA enforcement went live overnight is an availability incident you caused yourself.

Cross-course references

• Linux for Production Sysadmins - the PAM and SSH hardening parts cover the host-level analogue: key-based authentication and second factors on interactive login.
• Kubernetes for Production Engineers - cluster authentication and OIDC identity providers carry the same distinction between human and machine identity.
• Terraform for Production Sysadmins - the state backend and cloud provider credentials are protected by the same account whose MFA posture this lesson sets.

Quiz