Traditional MFA usually adds a second step to a password flow, while passkeys replace the password with cryptographic authentication bound to the device and user verification. That makes passkeys more resistant to phishing, but it also shifts control effort toward device enrollment, sync policy and recovery management.
How passkeys change the infrastructure access model
For infrastructure, the practical difference is that traditional MFA still sits on top of a password or another shared secret, while passkeys turn the login itself into a cryptographic challenge that is bound to a device and a user-verification step. That means the control objective shifts from “add a second factor” to “remove reusable secrets from the sign-in path.”
That shift matters because infrastructure access is often the place where legacy habits linger: VPNs, admin portals, jump hosts, cloud consoles and remote support flows may still assume passwords, backup codes or recovery exceptions. Passkeys reduce phishing and replay exposure, but they also make enrollment, device trust and recovery process quality part of the access design rather than an afterthought.
For teams standardising the model, a Passwordless and Passkeys Guide is useful because it frames passkeys as a deployment and recovery problem, not just a sign-in UX change.
What traditional MFA still does well, and where it stays weak
Traditional MFA is still valuable when the environment needs step-up checks, fallback coverage, or support for mixed device populations. It is especially common in infrastructure because it can be added to existing password-based flows without redesigning every application, directory, or remote access path.
Its weakness is structural: if the first factor is phishable or reusable, many MFA schemes only reduce risk rather than remove it. Push approvals, one-time codes and SMS can all be coerced, relayed, intercepted or socially engineered, so the password remains a valuable target and the second factor becomes a control that can be bypassed under pressure. For a broader comparison of those bypass patterns, MFA Guide is a good reference point.
Infrastructure teams also have to think about recovery. If administrators can reset MFA through a help desk, a lost device or a weak fallback channel, the security of the “second factor” is only as strong as the weakest recovery path.
Why passkeys are better for phishing resistance, but harder to govern
Passkeys are stronger because they are designed to bind the credential to a device and prevent the secret from being typed, copied, or reused in a way that a phisher can trivially capture. That is why passkeys are generally more resistant to phishing, adversary-in-the-middle interception, and credential replay than password plus MFA combinations that still depend on user-entered secrets.
The trade-off is that infrastructure security teams inherit more governance responsibility. They need to decide whether passkeys are device-bound, synced, or both; how enrollment is approved; what happens when a device is lost or replaced; and what recovery path is allowed when a user is locked out. Those decisions affect assurance as much as the authenticator itself.
That is why passkey programmes should be evaluated with the same seriousness as remote-access control design, not just authentication tooling. The most useful comparison is not “which is more modern,” but “which one better limits credential theft, supports admin workflows, and survives device loss without creating an easier recovery channel than the login it replaced.” A practical starting point is to compare your current administrator access flow against the controls described in NIST SP 800-63 Digital Identity Guidelines, which set expectations for phishing-resistant authentication and authenticator assurance.
Risk and Threat Considerations
The main risk with traditional MFA is not that it is useless, but that attackers increasingly target the password, the approval flow, or the recovery path instead of the one-time code itself. In infrastructure environments, that can turn a “second factor” into a speed bump if the primary secret is stolen, relayed, or bypassed through help desk abuse.
Failure mechanism: A phishable password, weak reset process, or approval fatigue attack lets an attacker preserve or recreate access even when a second factor is present; session theft can also sidestep authentication entirely after sign-in.
Impact: Administrative compromise can expose consoles, remote access gateways, cloud control planes, and privileged tooling, which increases the blast radius far beyond a single user account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication and authenticator assurance directly shape passkey design for infrastructure access. |
| Recommendation — Use phishing-resistant authenticator guidance to set assurance, enrollment, and recovery requirements for infrastructure sign-in. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Infrastructure workforce sign-in depends on authenticating admins and operators to privileged systems. |
| IA-5 — Authenticator Management | Passkeys and MFA both depend on authenticator lifecycle, including issuance, replacement, and revocation. | |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Infrastructure often includes external admins, contractors, or vendor access that needs distinct assurance handling. | |
| Recommendation — Require strong user authentication for administrative and operator access paths. Manage authenticator issuance, replacement, and revocation with a controlled lifecycle process. Apply stronger authentication requirements to external users with infrastructure access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Passkeys support stronger verification and reduced reliance on reusable credentials in high-trust infrastructure flows. |
| Recommendation — Treat each infrastructure access request as a fresh verification event and avoid implicit trust from prior logins. | ||
| OWASP ASVS | V6 — Authentication | Passkeys versus MFA is fundamentally an authentication design question for applications and admin portals. |
| Recommendation — Verify that authentication flows support phishing-resistant methods and robust recovery handling. | ||
| CIS Controls v8 | CIS-5 — Account Management | Infrastructure access depends on provisioning, deprovisioning, and recovery controls around privileged accounts. |
| Recommendation — Harden account lifecycle controls so access changes and recovery do not weaken authentication strength. | ||
Practitioner Guidance
What to prioritise: For infrastructure, prioritize passkeys first where the access path is high-value and the user population can support stronger device governance, especially admins, operators, and remote access users. Keep traditional MFA where you still need transitional coverage, shared workstations, or exception handling, but treat it as a legacy control, not the end state.
What to verify: Before trusting passkeys operationally, verify the recovery design. You should be able to answer who can enroll a new device, what evidence is required for re-issuance, how lost-device cases are handled, and whether a backup path quietly reintroduces the password risk you were trying to remove.
Practitioner takeaway: Passkeys are strongest when the organisation is willing to manage devices and recovery as first-class security controls; if those processes are weak, the apparent authentication upgrade can simply move the attack surface from login interception to account restoration.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org