Why do passkeys and phishing-resistant MFA not solve fraud on their own?

They reduce credential theft, but they do not stop a compromised device, a manipulated session, or social engineering that exploits a legitimate user after authentication. Fraud controls must continue after login by checking device state, behavioral signals, and transaction intent. Otherwise, the attacker simply moves from identity compromise to transaction abuse.

Why This Matters for Security Teams

Passkeys and phishing-resistant MFA are strong controls for stopping credential replay, but they only harden the authentication event. They do not verify whether the device is trusted, whether the session has been hijacked, or whether a legitimate user has been manipulated into approving a fraudulent action after login. That distinction matters because fraud increasingly happens after identity proofing, not before.

NHI Management Group research shows how often identity control gaps become broader compromise: in the Ultimate Guide to NHIs, 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. The same pattern appears in human workflows when the attacker shifts from login theft to transaction abuse. The lesson is consistent with NIST Cybersecurity Framework 2.0: identity assurance is only one part of risk management, not the whole control plane.

In practice, many security teams discover fraud only after a valid session has already been used to authorize an irreversible action, rather than through intentional post-authentication controls.

How It Works in Practice

Effective fraud prevention needs to continue after the passkey or MFA prompt succeeds. The control model should treat authentication as the start of a trust decision, not the end. Current guidance suggests layering session and transaction checks so the system can evaluate whether the request still looks consistent with the authenticated user, the device, and the expected business action.

That usually means combining multiple signals:

• Device posture, such as managed status, jailbreak or root detection, and endpoint risk.

• Session continuity, such as anomalous IP movement, impossible travel, or token replay indicators.

• Behavioral patterns, including timing, navigation, and approval habits that differ from the user norm.

• Transaction intent, such as whether the payee, amount, or scope matches the user’s prior context.

• Step-up verification for unusual actions, especially payments, account recovery, beneficiary changes, and privileged admin tasks.

This approach aligns with zero trust principles because it re-evaluates trust at each sensitive step, not just at sign-in. The operational goal is to make high-risk actions contingent on runtime risk, not on a one-time authentication event. For background on why identity compromise often shows up as broader abuse, see the Microsoft Midnight Blizzard breach, where identity access became a pathway into wider operational impact.

Fraud controls also need clear ownership between IAM, security operations, and fraud teams, because authentication telemetry alone rarely captures the business meaning of a transaction. These controls tend to break down in consumer-scale environments with high latency tolerance requirements and limited device telemetry, because the system cannot reliably distinguish legitimate friction from suspicious behavior.

Common Variations and Edge Cases

Tighter fraud controls often increase customer friction, so organisations have to balance conversion and support cost against loss prevention. There is no universal standard for how aggressive post-login controls should be, and current guidance suggests tuning them by transaction risk rather than applying one fixed policy to every user.

Some edge cases deserve special handling. Passkeys reduce phishing risk substantially, but they do not solve:

• Device compromise, where malware can operate inside a legitimate session.

• Adversary-in-the-middle attacks that leverage a real user after authentication.

• Session hijacking through stolen tokens or insecure browser state.

• Social engineering that persuades the user to approve a malicious transfer or recovery step.

For high-value actions, best practice is evolving toward intent-based checks that confirm the transaction matches the user’s expected goal, not just their identity. That is why phishing-resistant MFA should be treated as one layer in a broader fraud architecture, alongside device risk scoring, step-up authentication, approval workflows, and anomaly detection. The Schneider Electric credentials breach is a useful reminder that once an attacker can act through a legitimate path, the downstream damage is driven by what the session can do, not by how it was opened.

Related resources from NHI Mgmt Group

• What is the difference between compliance-ready MFA and phishing-resistant MFA?
• What is the difference between push-based MFA and phishing-resistant authentication?
• Why do phishing-resistant MFA controls still fail against social engineering?
• What is the difference between strong MFA and phishing-resistant MFA?