Analyst Field Guide · Identity & Access
Authentication is the gate before the gate: proving who you are, before anything decides what you may do. Passwords and why they fail, the MFA hierarchy and how it's bypassed, phishing-resistant auth, single sign-on, and the identity lifecycle.
Identity is the new perimeter. When trust no longer comes from being on the network (Zero Trust), the credential is the front door — which is why stolen and phished credentials are behind so many breaches. Authentication answers "who are you?"; authorization answers "what may you do?". This guide is about the first question — and its recurring lesson is that having MFA is not the same as having MFA that can't be phished.
Two words that get blurred and shouldn't. Authentication (AuthN) establishes who you are. Authorization (AuthZ) decides what that identity may do. You authenticate once and are authorized many times, per resource — and this guide is the AuthN half; the AuthZ half lives in Zero Trust and the Access Decision handbook.
Authentication rests on factors — categories of evidence:
Multi-factor authentication (MFA) means two or more factors of different kinds — a password plus a texted code is two factors; two passwords is not. MFA is the single highest-value control against account takeover, so the rule is simple: turn it on everywhere. The catch — the whole reason this guide has six more sections — is that not all MFA is equal, and attackers walk straight through the weaker kinds.
Passwords fail in predictable ways: people reuse them, so one breached site becomes many (credential stuffing — replaying leaked username/password pairs at scale); they're phishable; and complexity rules push people toward Password1! and sticky notes.
Current NIST guidance (SP 800-63B) moved away from forced complexity and periodic rotation toward length over complexity, screening new passwords against known-breached lists, allowing long passphrases and paste (so password managers work), and not forcing periodic changes unless there's evidence of compromise. If your policy still mandates a special character and a 90-day reset, it's following advice the standard abandoned. Verify the current 800-63 revision before citing specifics — it has been revised recently.
The durable fixes: a password manager (unique random password per site kills reuse and stuffing), and — for anything that matters — a second factor, so a leaked password alone isn't enough. But which second factor is exactly the question §3–§5 answer.
CISA ranks MFA from strongest to weakest — and the gap between top and bottom is not cosmetic. It's the difference between "an attacker cannot phish this" and "an attacker phishes this routinely."
The everyday tiers — push with number matching and TOTP apps — are a real improvement over SMS and worth deploying widely. But note the ceiling: number matching is an interim mitigation (it defeats blind push-spam, not a live proxy), and TOTP codes can be typed into a fake site. Both still transmit a secret a determined attacker can relay — which is the subject of the next section.
"We have MFA" stops password-only attacks. It does not, by itself, stop the techniques attackers now use routinely. Know the three:
MFA protects the login, not the session. Modern attacks steal the session token/cookie after a valid login, then replay it — no password, no MFA needed. Mitigate with short session lifetimes, token binding, and re-authentication for sensitive actions. And the recovery/help-desk path is now a primary target — reset flows that fall back to SMS or knowledge questions undo everything above.
There is a class of MFA that AiTM cannot relay, and CISA recognizes exactly two implementations: FIDO2/WebAuthn and PKI-based (PIV/CAC smart cards, certificates). The mechanism is what matters.
Terms worth pinning down: WebAuthn is the W3C browser API; FIDO2 is WebAuthn plus CTAP (the protocol to the authenticator). A passkey is the user-friendly name for a FIDO2/WebAuthn credential. Authenticators come as platform (built in — Windows Hello, Touch ID/Face ID) or roaming (a USB/NFC security key like a YubiKey). Passkeys are scaling fast, but one distinction is load-bearing:
Synced passkeys replicate across a provider's cloud (convenient, good for consumers and lower-risk accounts) — but trust moves to that provider account, and they may not meet the hardware-bound requirement for the highest assurance levels. Device-bound passkeys (hardware security keys, TPM-backed) keep the key in hardware — the choice for privileged accounts. Passkeys remove the most common phishing and replay paths, but they're not a silver bullet: account recovery and legacy systems are the real deployment blockers, and synced storage relocates rather than removes the trust. Deploy them deliberately, strongest accounts first.
Single sign-on (SSO) lets one authentication grant access to many applications through a central identity provider (IdP). It's a security win — fewer passwords, central MFA and policy, instant disable — with one caveat: it concentrates risk, so the IdP becomes the crown jewel. Three protocols get confused constantly:
| Protocol | Really does | Use / trap |
|---|---|---|
| SAML | Enterprise web SSO — XML assertions between IdP and app | The workhorse for corporate SaaS SSO |
| OAuth 2.0 | Authorization — delegated access via tokens ("let app X read my calendar") | Not authentication — using it to "log in" is the classic misuse |
| OIDC | Authentication layered on OAuth 2.0 — adds an ID token | This is the "log in with…" standard; OAuth alone isn't |
OAuth authorizes; OIDC (built on OAuth) authenticates; SAML is the older enterprise-SSO equivalent. Because SSO is one key to many doors, the IdP earns the strongest phishing-resistant MFA you have and the tightest monitoring — a phished IdP credential is a skeleton key.
The IdP is also where authentication stops being all-or-nothing. Conditional access weighs signals at login — device health, location, impossible travel, the sensitivity of what's being reached — and adjusts the bar: allow, step up to a stronger factor, or deny. Done well it removes friction on low-risk access and concentrates strong authentication where it counts; done badly it becomes a thicket of exceptions that each punch a hole (the Access Decision guide's warning about allowlists applies here too). The residual: the signals can be spoofed or simply wrong — impossible-travel misfires on VPNs, device posture can be faked — so treat the risk score as one input to the decision, not a verdict.
Inside a corporate network, identity usually lives in a directory (Active Directory) and authentication runs on Kerberos. The mechanics you need:
Credential-theft techniques (dumping hashes/tickets, replaying them for lateral movement) target exactly this machinery — it's the "Credential Access" tactic in the Attack Taxonomy guide. Compromise of the directory or its admin accounts is effectively game over, which is why privileged directory accounts get phishing-resistant MFA and dedicated admin workstations, not shared with email and browsing.
An account exists from hire to departure, and each stage is a control point (joiner-mover-leaver):
Attackers increasingly skip the login and target account recovery and the help desk — impersonating a user to get a password or MFA reset (the Scattered Spider pattern). Reset flows that fall back to SMS or knowledge questions defeat even phishing-resistant MFA. Recovery should re-verify identity strongly (in-person, manager attestation, a second registered authenticator), and help-desk staff need a script that refuses unverified reset requests. This is not "secure" — it's a specific, high-value gap that the strongest login MFA does not cover.
Every control so far assumed a human logging in. Most identities in a modern environment are not human: service accounts, API keys, OAuth client credentials, tokens, certificates, and cloud workload identities that let one service call another. They usually can't do MFA, often hold broad standing privilege, rarely rotate, and — as the leaver note above hints — are watched least, which makes them a prime route for lateral movement and persistence. What helps: inventory them (you can't govern what you haven't enumerated); scope each to least privilege and a single purpose; prefer short-lived, auto-rotated credentials (managed/workload identity, federation) over long-lived static keys and passwords in config; keep any unavoidable secrets in a managed vault, never in code or tickets; and monitor their behavior, since an anomalous service account is as strong a signal as an anomalous user. None of this makes the account "secure" — it narrows specific risks (credential theft, over-broad blast radius, stale access) and leaves others (a compromised vault, an over-permissioned role you missed).
The help-desk fork mirrors §1: is this authentication (can't prove who they are) or authorization (proved it, but can't reach the thing)? Then walk it down.
| Symptom | Look at |
|---|---|
| "Password rejected" | Account locked / disabled / expired? caps-lock/keyboard layout? password actually expired? recently reset elsewhere? |
| "MFA won't work" | Time drift on the TOTP device (TOTP is clock-based); wrong number-match; lost/replaced phone; the factor was never enrolled. |
| "SSO login loops / fails" | IdP↔app trust (cert expiry, clock skew on SAML assertions), the account exists in the IdP but not the app, or attribute/claim mismatch. |
| "Logs in but access denied" | That's authorization, not authentication — group membership, role, or resource policy. A different guide (Access Decision). |
| "Kerberos / domain login fails" | Clock skew (tickets rejected), DNS to the domain controller, or replication lag after a change. |
Two themes recur: clock skew breaks time-based factors and Kerberos and SAML alike (verify time sync first — it's cheap), and "authenticates fine but can't reach X" is an authorization problem, so stop debugging the login.
| Belief | Reality |
|---|---|
| "We have MFA, so we're safe from phishing" | AiTM proxies relay SMS/TOTP/push and steal the session cookie. Only phishing-resistant MFA (FIDO2/PKI) is origin-bound. |
| "SMS MFA is good enough" | SIM-swap, SS7, and carrier social engineering intercept it. It's the floor — inadequate for privileged accounts. |
| "Enforce complexity and 90-day rotation" | Modern NIST guidance dropped both — length, breach-list screening, and no forced rotation do more. |
| "SSO is a bigger risk than many passwords" | SSO removes password reuse and enables central MFA/disable; the risk is concentration, so protect the IdP hardest. |
| "MFA protects the whole session" | It protects the login. Stolen post-login tokens are replayed with no MFA — use short sessions and token binding. |
| "Passkeys solve everything" | They remove common phishing/replay paths, but recovery, legacy systems, and synced-vs-bound trust remain real decisions. |
AuthN = who you are · AuthZ = what you may do. Factors: know / have / are. MFA = two different factors. Turn MFA on everywhere — but not all MFA is equal.
Phishing-resistant (FIDO2/WebAuthn · PKI) → push with number matching → TOTP app → SMS/voice (floor; not for privileged). Only the top tier is origin-bound.
AiTM proxy relays creds + OTP and steals the session cookie · push-bombing (number matching = interim fix) · SIM-swap on SMS · recovery/help-desk social engineering. MFA guards the login, not the session.
OAuth authorizes · OIDC (on OAuth) authenticates · SAML = enterprise web SSO · Kerberos = ticketed AD login (clock-sensitive) · LDAP = directory · RADIUS = 802.1X/VPN. Protect the IdP hardest.
Least privilege at joining · remove-then-add on role change · deprovision fast (orphaned accounts) · separate + JIT privileged access · harden recovery (no SMS/knowledge-Q fallback). Nothing here is "secure" — each control names a threat and leaves residual risk.
Standards and threat facts current as of mid-2026. The MFA hierarchy and the "two phishing-resistant implementations (FIDO2/WebAuthn, PKI)" framing follow CISA's phishing-resistant-MFA guidance; number matching is CISA's stated interim mitigation. FIDO2 = W3C WebAuthn + FIDO CTAP; "passkey" is the FIDO2/WebAuthn credential, synced or device-bound. Password guidance references NIST SP 800-63B — verify the current revision before citing specifics, as it has been updated. Passkey adoption is scaling rapidly (Google and the FIDO Alliance reported billions of authentications / accounts in 2024) but figures and vendor capabilities change — verify current sources. No configuration is "secure" in the abstract; MFA reduces specific threats and leaves session-token theft and account-recovery gaps that need their own controls. Companion to Zero Trust and Access Decision (authorization), Wi-Fi (802.1X/RADIUS), Networking (Kerberos/NTP), Incident Response (credential compromise), and Attack Taxonomy (the Credential Access tactic).