Authentication Guide: Methods, Protocols and Assurance for Humans and Machines

Most identity breaches still start with an authentication step that should have failed: a replayed password, an approved push prompt, a stolen session cookie or a leaked API key. Authentication is the act of proving that a person, device or workload is the identity it claims to be, and it now spans far more than the login screen: passwords and passkeys, federation protocols such as SAML and OpenID Connect, the tokens and sessions issued afterwards, account recovery, and the keys, certificates and tokens that service accounts, workloads and AI agents present thousands of times a day. This guide is the overview for the whole field. It explains the core concepts and assurance levels, the main threats, the controls that matter at each stage of maturity, who owns what, and where authentication sits in NIST, CIS and ISO frameworks. It is written for IAM architects, security engineers and security leaders, and it ends with a map of every NHI Mgmt Group guide in the Authentication category.

Key takeaways

• Phishing resistance is the line that matters. CISA names only FIDO/WebAuthn and PKI-based authentication as phishing-resistant; SMS, voice, OTP and push, even with number matching, can all be relayed or socially engineered.
• Authentication does not end at login. The session cookie, refresh token or SAML assertion issued afterwards is a bearer credential, and stealing it bypasses every factor checked earlier.
• Recovery is part of authentication. A help desk reset or a new MFA enrolment is a re-binding of credentials, and attackers target it precisely because it is usually weaker than the login itself.
• Machines authenticate more than people do. Service accounts, workloads and AI agents mostly prove identity by possession of a secret; the mature pattern replaces long-lived secrets with federated, short-lived and sender-constrained credentials.
• Use NIST SP 800-63-4 as the benchmark. Revision 4 (final, July 2025) sets AAL2 to offer phishing resistance, allows synced passkeys at AAL2 but not AAL3, and drops forced password rotation and composition rules.

What the field covers

Authentication answers one question, "is this caller who it says it is?", and leaves "what may it do?" to authorisation. In practice the field covers six connected areas, and weaknesses in any one undo strength in the others:

• Authenticators: what the claimant presents. Passwords, one-time codes, push approvals, passkeys, hardware security keys, smart cards, platform authenticators such as Windows Hello for Business, and biometrics used to unlock a local key.
• Protocols and federation: how proof is carried between parties. Kerberos and NTLM inside Windows domains, SAML 2.0 and OpenID Connect for web single sign-on, OAuth 2.0 for delegated API access, RADIUS and certificate-based authentication for networks.
• Sessions and tokens: what is issued after a successful login. Session cookies, ID tokens, access and refresh tokens, Kerberos tickets and SAML assertions, with their lifetimes, binding and revocation.
• Lifecycle and recovery: enrolment, binding a new authenticator, lost-device recovery, help desk resets and removal at leaver time.
• Adaptive and continuous authentication: conditional access policies, device and risk signals, step-up prompts and continuous access evaluation that can revoke a session mid-flight.
• Machine and agent authentication: API keys, client secrets, X.509 certificates and mTLS, SSH keys, cloud instance identities, workload identity federation, SPIFFE identities and the delegated tokens AI agents use. See the NHI Authentication Guide.

Out of scope here, and covered by their own category guides, are authorisation models, identity proofing for customer onboarding and privileged access management workflows.

Core concepts

Factors, authenticators and assurance

The classic factors are something you know (a password), something you have (a key or device) and something you are (a biometric). NIST SP 800-63B-4 is more precise: it defines authenticator types (password, look-up secret, out-of-band device, single-factor and multi-factor OTP, single-factor and multi-factor cryptographic authenticator) and three Authentication Assurance Levels. Biometrics in this model are a way to unlock a local authenticator, not a remote secret.

The level is chosen per user group through the Digital Identity Risk Management process. See the NIST SP 800-63 Digital Identity Guidelines Guide.

Phishing resistance, replay resistance and binding

• Phishing resistance: the authenticator will not release a usable response to the wrong site. FIDO2/WebAuthn scopes each key pair to the relying party, and smart card or certificate authentication binds the proof to a TLS channel or a specific verifier.
• Replay resistance: a captured response cannot be reused. OTPs are replay-resistant once used but can be relayed in real time; passwords are neither.
• Sender-constrained tokens: after login, tokens can be bound to a key the client holds, using mutual TLS certificate-bound tokens (RFC 8705, cnf claim with x5t#S256) or DPoP (RFC 9449, DPoP header and jkt thumbprint). A stolen bound token is useless without the private key.

Comparing the main methods

Human and machine authentication differ in kind

A person can answer a prompt; a workload cannot. Machines therefore authenticate by presenting something: an API key, a client secret, a signed JWT assertion, a certificate in an mTLS handshake or a token issued by their platform. The credential effectively is the identity, it is copied into configuration and pipelines rather than typed, and it often lives for years. The direction of travel is the same as for people, from shared secrets towards asymmetric keys and short-lived, bound credentials. See the Workload Identity Federation Guide, the mTLS Guide and the Machine-to-Machine OAuth (Client Credentials) Guide.

Main threats

Two attacks sit outside the technical login and deserve equal weight. Help desk social engineering converts a phone call into a password and MFA reset; the MGM Resorts breach began this way, according to the attackers' account. OAuth device code and consent phishing trick a user into authenticating on the attacker's behalf. See the Device Code Phishing Guide and the MFA Fatigue and Bypass Guide.

Key controls by maturity

Foundation: close the open doors

• MFA coverage: enforce MFA on every internet-facing login, remote access, email and the identity provider itself. The Snowflake breach showed what happens without it: infostealer credentials, some years old, opened about 165 customer accounts that had no MFA and no network allow lists.
• Legacy authentication: block protocols that cannot do MFA (basic authentication to mail, POP, IMAP, legacy SMTP AUTH where possible). The Midnight Blizzard breach started with a low-volume password spray against a legacy test tenant account without MFA.
• Password policy: length over complexity, screening against breached lists, no forced periodic change, allow password managers and paste, rate-limit failures. See the Password Policy Guide (NIST-aligned).
• Inventory of machine credentials: know which API keys, secrets and certificates exist, who owns them and when they expire.

Intermediate: make it phishing-resistant

• Administrators first: require FIDO2 keys, device-bound passkeys or smart cards for all privileged roles, then help desk and IT staff, then everyone else, following CISA's recommended order.
• Push hardening: where push remains, turn on number matching and display sign-in context; remove SMS except as a monitored fallback.
• Secure recovery: help desk identity verification that does not rely on information an attacker can find, call-back to a registered number, manager approval and a delay or alert on any MFA reset for privileged users. See the Account Recovery and Help Desk Security Guide.
• Conditional access: require compliant or managed devices for sensitive apps, block high-risk sign-ins, and use authentication strength policies rather than "any MFA". See the Conditional Access Guide.
• Machine credentials: move CI/CD and cloud workloads to OIDC-based workload identity federation and managed identities; rotate what cannot yet be removed.

Advanced: bind and evaluate continuously

• Passwordless by default: passkeys or Windows Hello for Business as the primary sign-in, with passwords removed from the user experience. See the Passkey Rollout Guide.
• Token binding: sender-constrained tokens (DPoP or certificate-bound) for high-value APIs, short access-token lifetimes and refresh-token rotation.
• Continuous evaluation: share session revocation and risk events between IdP and applications using the OpenID Shared Signals Framework (CAEP and RISC). See the Shared Signals Framework Guide.
• Protected signing keys: keep IdP and token-signing keys in HSMs, rotate on schedule and confirm every relying party validates issuer, audience and key scope. The Storm-0558 key breach showed the cost: a consumer signing key that should have been retired was used to forge tokens accepted for enterprise mailboxes.
• Agent authentication: AI agents act with their own workload identity plus delegated, scoped tokens obtained by token exchange, never a copied user password or a shared API key. See the Agent-to-Agent Authentication Guide.

Rolling out a stronger method

1. Baseline: export sign-in logs and report MFA registration, method mix, legacy protocol use and accounts excluded from policy.
2. Choose the target per group: AAL3 hardware keys for administrators, passkeys for the general workforce, an approved fallback for staff without smartphones.
3. Pilot ring: IT and security staff first; run new conditional access or authentication strength policies in report-only mode and review the impact before enforcing.
4. Enrol before enforcing: give users a registration window, with Temporary Access Pass or in-person enrolment for bootstrapping, so nobody is enrolled through a weaker channel.
5. Enforce in waves: by department or risk, with a named support desk and a documented break-glass process (two emergency accounts with hardware keys, excluded from normal policy and alerted on use).
6. Remove the old method: retire SMS and passwords for the group once the new method is stable; leaving them in place keeps the downgrade path open.
7. Roll back safely: keep the previous policy as a disabled copy; if lockouts spike, revert the policy for the affected wave rather than disabling MFA globally.

Choosing between options

• Synced versus device-bound passkeys: synced passkeys solve loss and scale for most users at AAL2; device-bound keys are needed where non-exportable keys are required (AAL3, administrators, shared or high-risk roles).
• Smart cards versus FIDO2: smart cards suit estates that already run PKI and need certificate-based Windows logon or document signing; FIDO2 keys are simpler to issue and work natively with web SSO.
• SAML versus OpenID Connect: SAML remains common for established enterprise SaaS; OIDC is the default for new and mobile applications and fits OAuth API access. See the SAML vs OIDC Guide.
• Small versus large organisations: a small business can reach most of the benefit with an IdP that enforces passkeys or authenticator apps, blocks legacy protocols and has two break-glass accounts. Large organisations add hardware keys for privileged tiers, PKI, workload federation at scale and a dedicated identity detection capability.

Detection and measurement

Log and alert on: failed and successful sign-ins with method, client app and location (Entra ID sign-in logs, Okta System Log, Windows Security events 4624, 4625, 4768, 4769, 4771 and 4776); MFA method registration and removal; password and MFA resets made by the help desk; new federation trusts or token-signing certificates; consent grants to OAuth apps; and new credentials added to service principals. Metrics that show progress:

• Phishing-resistant coverage: percentage of users, and separately of privileged users, whose only allowed methods are phishing-resistant (target 100% for privileged).
• Legacy authentication volume: sign-ins using protocols without MFA (target zero).
• Policy exclusions: number of accounts excluded from MFA or conditional access, each with an owner and expiry.
• Long-lived machine secrets: count of API keys and client secrets older than 90 days, trending down as federation replaces them.
• Recovery abuse signals: MFA resets followed by privileged activity within 24 hours, each investigated.
• Time to revoke: minutes from a confirmed compromise to all sessions and tokens revoked.

Common failure patterns

• "MFA" that only covers the web portal: VPN, legacy mail clients or a remote access gateway still accept a password alone. The Change Healthcare breach began with a Citrix login without MFA.
• Approvable push prompts: the Uber breach combined a bought contractor password with repeated push prompts until one was accepted.
• Strong login, weak reset: phishing-resistant sign-in undermined by a help desk that resets MFA on a convincing phone call.
• Long-lived tokens nobody revokes: refresh tokens and session cookies remain valid after a password reset, so the attacker keeps access.
• Service accounts excluded from policy: machine accounts exempted from MFA "because they cannot do it", with no compensating network or credential controls.
• Forgotten test and legacy tenants: environments outside the main policy set, as in Midnight Blizzard.

Roles and ownership

Standards and frameworks

Where to go next

New to Authentication? These are the foundational guides to read first.

Start here

• NIST SP 800-63 Digital Identity Guidelines Guide: IAL, AAL and FAL in practice under revision 4.
• MFA Guide: methods, phishing resistance and how each can be bypassed.
• Top 10 MFA Mistakes: the deployment errors that leave MFA open.
• Password Policy Guide (NIST-aligned): length, screening and no forced rotation.
• Phishing-Resistant MFA Guide: what qualifies and how to deploy it.
• Passwordless and Passkeys Guide: passkeys for workforce and customers.
• Hardware Security Keys Guide: FIDO2 keys, issuance and lifecycle.
• MFA Fatigue and Bypass Guide: push bombing, SIM swap and downgrade attacks.
• Account Recovery and Help Desk Security Guide: secure resets and enrolment.
• SAML Security Guide: Golden SAML, signature wrapping and safe configuration.
• JWT Security Guide: signing, validation and token attacks.
• Token and Session Security Guide: lifetimes, binding and revocation of sessions and tokens.

For machine and agent authentication, continue with the NHI Authentication Guide and the OAuth 2.0 and OpenID Connect Guide.

Browse all Authentication guides

Practitioner checklist

• Set a target assurance level per user group and record exceptions with an owner and expiry.
• Require phishing-resistant authentication (FIDO2 or certificates) for every privileged account and the identity provider admin roles.
• Block legacy authentication protocols and confirm the sign-in logs show zero use.
• Apply NIST-aligned password rules: length, breached-password screening, no forced rotation.
• Harden recovery: verified identity checks, call-back and alerting on every MFA reset for privileged users.
• Set session and refresh-token lifetimes deliberately and test that a password reset revokes them.
• Keep two monitored break-glass accounts protected by hardware keys.
• Replace static secrets in CI/CD and cloud workloads with workload identity federation or managed identities.
• Protect token-signing keys in HSMs and verify relying parties validate issuer, audience and key scope.
• Track the six metrics above monthly and report phishing-resistant coverage to leadership.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• CISA: Implementing Phishing-Resistant MFA
• FIDO Alliance: Passkeys
• IETF: RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
• IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• OpenID Foundation: Shared Signals Framework 1.0
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Multi-Factor Authentication Request Generation

Related NHI Mgmt Group resources: Identity Visibility, Posture and Threat Detection Guide · NHI Authentication Guide · Conditional Access Guide · OAuth 2.0 and OpenID Connect Guide