Notifications
Clear all
Topic starter
22/06/2026 4:56 pm
TL;DR: Phishing-resistant MFA binds the authentication ceremony to the relying-party origin, making phishing-site replay and man-in-the-middle relays ineffective; CISA, OMB M-22-09, and regulated sectors now treat it as the practical baseline, according to Scramble ID. The governance question is no longer whether MFA exists, but whether the authentication path can actually survive hostile session proxying.
NHIMG editorial — based on content published by Scramble ID: What Is Phishing-Resistant MFA?
By the numbers:
- CISA and OMB M-22-09 treat phishing-resistant MFA as the required direction for federal access paths.
Questions worth separating out
Q: How should security teams implement phishing-resistant MFA across enterprise access paths?
A: Start with the highest-blast-radius accounts and enumerate every path where authentication happens, including recovery and partner access.
Q: Why do push, TOTP, and SMS remain risky even when they are called MFA?
A: They remain risky because the user can approve or enter a code into a phishing proxy, and the attacker can relay that approval to the real service.
Q: What breaks when a phishing-resistant primary login still falls back to SMS recovery?
A: The security promise breaks at the recovery step, because the attacker targets the weakest authenticator path after bypassing the strong one.
Practitioner guidance
- Classify every authentication path by relay resistance Inventory web, mobile, recovery, voice, partner, and admin paths, then mark each as phishing-resistant, upgradeable, or fundamentally relayable.
- Eliminate non-resistant recovery as a hidden back door Replace SMS reset, help-desk override, and email-link recovery for high-risk accounts with methods that preserve the same assurance as the primary ceremony.
- Upgrade privileged access first Move administrators, cloud operators, and break-glass users to FIDO2/WebAuthn or PKI-based authenticators before broad workforce rollout.
What's in the full article
Scramble ID's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how FIDO2/WebAuthn scopes the ceremony to the relying-party origin.
- A full list of authenticators that qualify and those that do not, including edge cases and common misconceptions.
- Regulatory mapping across OMB M-22-09, CISA, FedRAMP, PCI DSS v4.0.1, CJIS, and other regimes.
- Implementation sequencing for workforce, privileged, partner, contact-centre, and machine-to-machine access paths.
👉 Read Scramble ID's explanation of phishing-resistant MFA and verifier-impersonation resistance →
Phishing-resistant MFA and AiTM phishing: are your controls ready?
Explore further
22/06/2026 5:07 pm
Phishing-resistant MFA is an origin-binding control, not a stronger version of MFA. The industry still talks about MFA as if factor count were the main variable, but the decisive property is whether the assertion is bound to the verifier’s origin. SMS, TOTP, and push approval all preserve a relayable trust path, which means they fail under adversary-in-the-middle conditions. The practitioner conclusion is that assurance must be measured by ceremony integrity, not by factor count.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that identity control failures often outlast detection.
A question worth separating out:
Q: How do regulated organisations know whether their MFA is actually phishing-resistant?
A: They should verify whether the authenticator binds cryptographically to the relying-party origin and whether the private key remains hardware-protected. If the user can copy, type, relay, or approve a code that works on a phishing site, the control is not phishing-resistant.
👉 Read our full editorial: Phishing-resistant MFA is the new bar for identity assurance
