U.S. MFA requirements are pushing cryptographic authentication higher

At a glance

What this is: This article argues that U.S. MFA expectations are shifting toward phishing-resistant, cryptographic authentication and away from weaker factors such as SMS-based OTP.

Why it matters: IAM and PAM teams need to treat MFA as an assurance control, not a checkbox, because U.S. compliance expectations now shape what counts as acceptable access proof.

Context

U.S. MFA policy is no longer a simple question of adding a second factor. The practical issue is which authenticators satisfy federal assurance, regulated-sector risk, and zero trust expectations when access is privileged, external, or sensitive.

The article frames that shift through NIST SP 800-63B, NIST SP 800-207, and Executive Order 14028. In that model, cryptographic authenticators and phishing-resistant workflows matter more than legacy OTP patterns because the control is now judged by resistance to interception and replay as much as by factor count.

Key questions

Q: How should organisations replace SMS 2FA for high-risk access in regulated environments?

A: Organisations should prioritise phishing-resistant and device-bound factors for sensitive workflows, especially admin access and transaction approvals. TOTP can be a practical step up, but FIDO2, push authentication, biometric factors, and PKI-based MFA provide stronger assurance. The right choice depends on risk, user population, recovery processes, and whether regulators expect higher assurance for critical use cases.

Q: Why do weak MFA factors still create risk even when a policy says MFA is enabled?

A: Because factor count does not equal assurance. If the second factor can be phished, intercepted, or replayed, the attacker can satisfy the policy while still bypassing the security intent. The control fails at the authenticator layer, not the policy layer.

Q: What signals show that MFA is not actually phishing-resistant?

A: Look for SMS, OTP, push approvals, and broad exception use on high-value accounts. If users can approve login from a fraudulent prompt, if help desk resets re-enable weak factors, or if administrators still rely on shared-secret methods, the programme is not resistant enough to withstand modern phishing.

Q: What should teams do when federal or contractor access must meet stronger authentication rules?

A: They should treat access assurance as a shared responsibility across IAM, PAM, and governance teams. Define the required authenticator strength per use case, enforce it at policy level, and keep evidence that the chosen factor resists phishing for the accounts that matter most.

Technical breakdown

Phishing-resistant authenticators and U.S. assurance levels

U.S. MFA guidance increasingly distinguishes between mere multi-factor use and authenticators that resist phishing, replay, and man-in-the-middle capture. In practice, that means hardware-backed keys, PIV/CAC-style credentials, and FIDO2/WebAuthn flows are treated as materially stronger than SMS or voice OTP. The assurance question is not just whether a user presents two factors, but whether those factors bind authentication to the intended relying party and survive real-world attack paths. That is why cryptographic proofing and authenticator strength sit at the center of U.S. compliance discussions.

Practical implication: Treat authenticator type as a policy decision and phase out factors that do not provide phishing resistance.

Risk-based authentication in zero trust architectures

Risk-based authentication uses contextual signals such as device posture, location, and behavior to decide when to challenge, step up, or step down access. In a zero trust model, MFA is not a one-time gate at login but part of continuous verification across the session. That shifts the technical question from static approval to dynamic trust evaluation. The article’s framing aligns with the idea that authentication strength and session assurance are linked, especially where contractors, administrators, or sensitive workloads are involved.

Practical implication: Design MFA policies to re-evaluate trust during the session, not only at the initial login.

Why SMS and email OTP fall short in regulated access paths

Legacy OTP channels are vulnerable because the secret can be intercepted, redirected, or socially engineered before it proves possession. For regulated U.S. environments, that weakness matters most at privileged access points and external partner access where compromise has higher blast radius. The article points to a broader identity governance issue: the factor itself becomes part of the attack surface, so a nominal MFA policy can still leave an organisation exposed if the authenticator is easy to phish. Auditability also suffers when the control does not clearly demonstrate cryptographic binding or device assurance.

Practical implication: Map every privileged and external access path to the authenticator used and remove weak OTP factors where stronger alternatives are available.

Threat narrative

Attacker objective: The attacker seeks authenticated access to high-value accounts or regulated systems by exploiting MFA that is strong in policy language but weak in cryptographic assurance.

1. Entry occurs through weak authentication paths such as SMS-based or email-based OTP, which can be intercepted or phished rather than cryptographically bound to the session.
2. Credential abuse follows when the attacker reuses the captured factor or tricks the user into completing a fraudulent login flow that satisfies the MFA check.
3. Impact lands in privileged or regulated access paths, where the attacker gains authenticated access that appears compliant on paper but lacks phishing resistance in practice.

Breaches seen in the wild

• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
• SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

U.S. MFA policy is really an assurance policy: The centre of gravity has moved from factor count to phishing resistance, cryptographic binding, and auditability. That matters because compliance teams can no longer treat OTP-based controls as interchangeable with hardware-backed authenticators. For identity programmes, the real question is whether the chosen authenticator can survive the attack paths regulators now assume.

Risk-based authentication exposes the limits of static access models: Zero trust assumes access should be re-evaluated as context changes, not granted once and forgotten. That makes MFA part of a live trust decision, not a login ritual. Practitioners should expect authentication policy, session governance, and privileged access policy to converge.

Legacy OTP creates assurance debt: SMS and email OTP may satisfy a superficial second-factor requirement, but they do not satisfy the harder problem of phishing resistance. Once those methods are embedded in privileged workflows, the gap becomes a governance problem, not just a technical one. The implication is that teams must measure whether their authenticators actually prove possession in a way attackers cannot reuse.

Cryptographic authentication is becoming the baseline for regulated access: In U.S. environments, the market is converging on a narrower definition of acceptable MFA for federal, contractor, healthcare, and finance use cases. That does not just affect login UX. It changes what auditors, security architects, and PAM teams must accept as defensible control design.

Named concept - assurance gap in MFA: The assurance gap is the space between a policy that claims MFA and an authenticator that still allows phishing, replay, or factor interception. U.S. identity programmes that leave this gap open may appear compliant while still failing the threat model. Practitioners should treat authenticator assurance as a control classification problem, not a branding exercise.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Assurance will replace factor counting as the practical MFA question: Identity teams should expect more scrutiny on whether an authenticator is phishing-resistant, cryptographically bound, and auditable. That pushes programme owners to separate low-risk convenience logins from high-risk access paths instead of applying one MFA rule everywhere.

U.S.-style MFA governance also tightens the relationship between IAM, PAM, and compliance evidence. If the organisation cannot prove that privileged access uses a stronger authenticator than standard workforce sign-in, the control may satisfy a checkbox but still fail the threat model.

For practitioners

• Replace weak OTP factors Audit all external and privileged access paths for SMS and email OTP dependencies, then prioritise those flows for phishing-resistant authenticators and certificate-backed login where the risk is highest.
• Align authenticator policy to assurance levels Map each use case to the authenticator strength it actually needs, separating low-risk access from regulated or administrative access that demands cryptographic proofing.
• Embed step-up logic into session policy Use device posture, location, and behavior signals to trigger re-authentication when risk changes, rather than relying on a single login event.
• Review contractor and federated access Check whether supplier, contractor, and cross-agency identities are forced through the same assurance model as internal users, especially where federal expectations apply.

Key takeaways

• U.S. MFA requirements are narrowing the acceptable gap between policy and attack reality, especially for privileged and regulated access.
• The main weakness is not the absence of a second factor, but the use of factors that can be phished, intercepted, or replayed.
• Practitioners should align authenticator strength, session re-evaluation, and audit evidence so MFA means demonstrable assurance rather than just multiple prompts.

Key terms

• Phishing-resistant Authenticator: An authentication factor that cannot be easily replayed, proxied, or tricked into disclosure by phishing. In practice, it uses public key cryptography and binds the authentication response to the legitimate origin and transaction context, reducing the value of stolen passwords or repeated prompts.
• Risk-Based Authentication: An access model that changes verification requirements based on the estimated risk of the request. It combines identity assurance, device posture, application sensitivity, and contextual signals to decide whether to allow, block, or step up verification before access is granted.
• Authenticator assurance level: Authenticator assurance level is a measure of how strongly an identity event proves the claimant is genuine. In NIST 800-63B, higher levels require stronger factor evidence and tighter cryptographic protections, which makes the level a practical way to map identity controls to regulated access requirements.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.