TL;DR: Phishing-resistant MFA uses origin-bound cryptography, device-bound authenticators, and verified user intent to stop proxy-based phishing and session replay attacks, according to 1Kosmos. Traditional MFA can be relayed in real time, which makes recovery paths, fallback methods, and enrollment policy the real governance problem.
NHIMG editorial — based on content published by 1Kosmos: phishing-resistant MFA and passwordless security guidance
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
Questions worth separating out
Q: How should security teams implement phishing-resistant MFA for privileged users?
A: Start with administrators, developers, finance teams, and remote access paths where a compromised session has the highest blast radius.
Q: Why do traditional MFA methods still fail against phishing attacks?
A: Because many common factors can be relayed in real time.
Q: What do security teams get wrong about recovery after phishing-resistant MFA rollout?
A: They often treat recovery as an administrative afterthought, then leave email resets, help desk shortcuts, or temporary exceptions in place.
Practitioner guidance
- Eliminate downgrade methods in policy Remove SMS, OTP app, email link, and push approval fallback from high-risk sign-in flows so the primary phishing-resistant method cannot be bypassed through a weaker option.
- Harden enrollment and proofing Bind each authenticator to a verified individual and device at enrollment, then require auditable proofing steps for replacements, resets, and new device registration.
- Redesign recovery as a controlled privileged workflow Treat account recovery like privileged access, with verified identity, logged approvals, and step-up checks before any credential reset is issued.
What's in the full article
1Kosmos's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on phishing-resistant MFA methods such as FIDO2, WebAuthn, smart cards, and identity-backed biometrics
- Enrollment and recovery workflow considerations for managed devices, backups, and identity proofing
- Policy enforcement patterns that prevent fallback to weaker methods in real sign-in flows
- Deployment challenges in legacy applications and bring-your-own-device environments
👉 Read 1Kosmos's analysis of phishing-resistant MFA for passwordless access →
Phishing-resistant MFA and passwordless access: are your controls ready?
Explore further
Phishing-resistant MFA is a control category shift, not an incremental MFA upgrade. Traditional MFA assumes a shared secret or approval can be trusted if it is presented in the right sequence. Phishing-resistant authentication replaces that assumption with cryptographic binding to origin, device, and user intent. For identity governance, that changes the control objective from factor count to assurance quality, which is the more useful lens for IAM and PAM teams.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to GitGuardian research.
A question worth separating out:
Q: Who is accountable when phishing-resistant MFA is bypassed through fallback methods?
A: Accountability sits with the identity programme that approved the downgrade path, not just the user who clicked through it. If policy still permits weaker methods, the organisation has left the control boundary open. Frameworks such as NIST SP 800-63 and zero trust guidance expect assurance to be maintained across the full authentication journey.
👉 Read our full editorial: Phishing-resistant MFA is becoming the baseline for identity security