Adaptive MFA changes the challenge based on risk, while passkeys remove the reusable password that stuffing depends on. Adaptive MFA limits abuse during sign-in, but passkeys reduce the attack surface itself. Most teams need both, with passkeys as the structural fix and adaptive MFA as the transition control.
Why This Matters for Security Teams
adaptive mfa and passkeys solve different parts of the same account-protection problem. Adaptive MFA reduces sign-in abuse by changing the challenge based on risk, while passkeys remove reusable passwords that can be phished, stuffed, or reused across services. That distinction matters because credential attacks increasingly start with stolen secrets, then pivot into session hijacking or privilege escalation. NIST’s Cybersecurity Framework 2.0 is clear that identity assurance and risk-based access both belong in the control stack.
The operational difference is structural. Passkeys reduce the attack surface at the authentication layer, but they do not replace step-up checks for anomalous behavior, unusual geography, or device changes. Adaptive MFA still has value where the account, device, or transaction risk changes in real time. For teams managing high-value access, the right question is not which one wins, but which one closes which failure mode. NHI Mgmt Group’s guidance on the Ultimate Guide to NHIs — What are Non-Human Identities shows why identity controls fail when they only cover one layer of the problem. In practice, many security teams discover credential replay only after a phishing or stuffing campaign has already succeeded.
How It Works in Practice
Passkeys replace passwords with phishing-resistant cryptographic credentials bound to a user device and authenticating platform. That means there is no reusable secret for an attacker to harvest from a login page, helpdesk workflow, or breach dump. For most organisations, this is the stronger long-term fix because it removes the most abused credential type rather than trying to detect abuse after the fact.
Adaptive MFA, by contrast, evaluates risk at sign-in or during a session and may ask for a stronger factor only when conditions change. Current guidance suggests using it to respond to context such as new devices, impossible travel, suspicious IP reputation, or high-risk transactions. In practice, this works best when paired with policy signals from device trust, user behavior, and application sensitivity. NIST SP 800-53 Rev. 5, especially access control and identification/authentication controls, remains a useful reference point for translating those signals into policy.
- Use passkeys as the default primary sign-in method where the platform supports them.
- Keep adaptive MFA for step-up authentication on risky actions, recovery flows, and unsupported legacy apps.
- Prefer phishing-resistant factors over push prompts, especially for admin and helpdesk accounts.
- Review account recovery, because recovery often becomes the weakest bypass even when login is hardened.
This aligns with breach patterns documented in NHIMG research, including the Microsoft Midnight Blizzard breach and the Salt Typhoon US telecoms breach, where credential abuse and access persistence created outsized impact. These controls tend to break down in legacy environments that cannot support passkeys and rely on brittle fallback methods.
Common Variations and Edge Cases
Tighter authentication often increases user friction and recovery overhead, requiring organisations to balance phishing resistance against operational support burden. That tradeoff is real, especially during migration from password-based login to passkeys.
There is no universal standard for this yet, but current practice is to treat passkeys as the preferred authentication mechanism and adaptive MFA as a contextual control for exceptions. Legacy SSO stacks, shared devices, air-gapped systems, and contractor-heavy environments may still need passwords or alternate factors for a time. In those cases, adaptive MFA helps reduce risk, but it should not be treated as equivalent to removing the password attack surface.
Another edge case is account recovery. If recovery uses SMS, weak knowledge-based questions, or overbroad helpdesk approval, the organisation can reintroduce the same weaknesses that passkeys removed. Teams should also distinguish between consumer-grade adaptive prompts and enterprise-grade risk engines that can ingest device posture, session telemetry, and privileged action context. For account protection, the strongest design is passkeys for primary authentication, adaptive MFA for exception handling, and tightly governed recovery for the small number of users who cannot yet move fully off passwords.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Phishing-resistant auth reduces credential exposure across NHI and user accounts. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication map directly to account protection choices. |
| NIST SP 800-63 | Digital identity guidance covers phishing-resistant authentication and recovery assurance. | |
| NIST AI RMF | Risk-based decisions and context-aware controls fit AI-driven adaptive authentication. | |
| NIST Zero Trust (SP 800-207) | SC.VA-1 | Zero Trust supports continuous verification instead of relying on a single login event. |
Replace reusable secrets with strong auth and rotate any remaining shared credentials aggressively.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org