If you have MFA enabled, you may still have a control gap. Here is why phishing-resistant authentication is becoming an auditor expectation — and how passkeys close that gap.

🔐 The Problem With “MFA Enabled” as a Control

If you are running an access controls program for a financial services organization, you have probably already checked the MFA box. Authenticator app, push notifications, maybe SMS as a fallback. It feels like the job is done.

It is not — and auditors are starting to notice.

The shift happening right now in frameworks like SOC 2 and ISO 27001 is not just about whether MFA is enabled. It is about whether your MFA is actually resistant to the attacks that are actively targeting your organization. For finance teams — pension funds, investment firms, FP&A teams sitting on material non-public data — that distinction matters more than most.

Traditional MFA was a meaningful improvement over passwords alone. But it was designed for a threat model that has since evolved.

Adversary-in-the-middle (AiTM) attacks have made push-based MFA largely ineffective against targeted phishing. The mechanics are straightforward: an attacker sets up a reverse proxy between the user and the legitimate login page, intercepts the session in real time, and captures both the password and the MFA token before the user even realizes something is wrong. Tools to do this are widely available and do not require sophisticated attackers.

Microsoft’s own threat intelligence has documented AiTM kits being used specifically against financial services targets — precisely because the payoff is high enough to justify the effort.

📋 What SOC 2 and ISO 27001 Actually Require

Neither SOC 2 nor ISO 27001 prescribes specific MFA technology by name. What they require is evidence that your controls are commensurate with the risk.

SOC 2 — Common Criteria CC6.1

The organization must implement controls to restrict logical access to systems, including authentication mechanisms appropriate to the sensitivity of the data. If your risk assessment acknowledges phishing as a threat — and every financial services organization’s risk register should — then MFA that is vulnerable to phishing creates a control gap.

ISO 27001:2022 — Control A.8.5 (Secure Authentication)

Authentication should be based on the sensitivity and classification of the information being accessed. High-privileged access to financial systems warrants stronger authentication than reading a shared calendar. The framework expects you to have thought about this proportionality.

What auditors are increasingly looking for is evidence of that proportionality — not just that MFA exists, but that you have considered the risk profile of different access scenarios and applied controls accordingly.

Phishing-resistant MFA closes that gap in a way that push notifications cannot.

🔑 How Passkeys Work and Why They Satisfy This Requirement

A passkey is a credential based on the WebAuthn open standard. When a user registers a passkey, two keys are generated:

  • Private key — stored securely on the user’s device (TPM on Windows, Secure Enclave on Mac, or a FIDO2 hardware key)
  • Public key — stored on the service provider’s side, such as the user’s account in Microsoft Entra

When the user authenticates, Entra sends a challenge. The device uses the private key to sign that challenge, and Entra verifies the signature using the public key. The critical detail: the challenge includes the relying party domain — login.microsoftonline.com — and the private key will only sign for that exact domain.

This means a fake login page on a look-alike domain gets nothing. There is nothing to intercept in transit because the private key never leaves the device. There is nothing to replay because each challenge is unique. The entire attack surface that AiTM exploits simply does not exist.

On the MFA front, passkeys satisfy both factors in a single step:

  • Something you have — the device storing the private key
  • Something you know or are — the PIN or biometric that unlocks it

A single authentication method that meets the intent of MFA requirements, without relying on a second factor that could be phished out.

🏛️ Device-Bound vs Synced Passkeys — What Matters for Compliance

There are two types of passkeys in Microsoft Entra, and they have different implications for your compliance posture.

Device-Bound Passkeys

The private key is stored in hardware — TPM, Secure Enclave, or a FIDO2 hardware key. The credential cannot be exported. This is the stronger option for high-privilege access because authentication is tied to a specific, attestable device.

Microsoft Entra allows you to enforce attestation, meaning you can verify that the FIDO2 key model is genuine and certified. For privileged roles — Global Admin, Application Administrator, anyone with write access to financial reporting systems — this is the appropriate control.

You can create authentication strength policies in Entra Conditional Access that require a FIDO2 key specifically for role elevation, separate from the Authenticator app used for day-to-day access. That kind of granular, role-proportionate control maps cleanly to what SOC 2 and ISO 27001 are asking for.

Synced Passkeys

The private key is encrypted and stored in a cloud keychain — Apple Keychain, Google Password Manager, or a vault like 1Password. These are still phishing-resistant and still satisfy MFA, but the credential can move between devices. Synced passkeys are currently in Public Preview in Microsoft Entra.

For standard user access, synced passkeys are a significant improvement over push-based MFA. For privileged access, device-bound is the more defensible choice from an audit standpoint.

✅ What You Should Do

  • Pilot first: Enable the passkey profile in Entra and let a small group register before adding any Conditional Access enforcement. If users hit the CA policy before registering a passkey, they will be locked out. The sequence matters.
  • Get users registered: Registration happens through My Account > Security Info > Add sign-in method. This must be completed before the authentication strength policy is active for that group.
  • Document your attestation decisions: If you enforce attestation for device-bound passkeys, you are creating an allowlist of approved FIDO2 key models by AAGUID. This gives you something concrete to point to in an audit — evidence that you reviewed and approved the hardware used for privileged access.
  • Map this to your risk register: Do not just deploy passkeys. Update your risk assessment to reflect that AiTM phishing has been addressed for the access paths covered. This is what connects the technical control to the audit evidence.
  • Review authentication strength per role: Not every user needs a FIDO2 hardware key, but every privileged role should have a documented decision on authentication requirements.

💡 Expert Analysis

This is not a future concern. AiTM phishing kits targeting financial services organizations are active today. The gap between “MFA enabled” and “phishing-resistant MFA” is where most finance teams are currently sitting — and it is the gap that is showing up in audit findings.

Why This Matters for Finance Specifically:

  • Finance users access high-sensitivity systems — ERP, treasury, investment management platforms — where a single compromised session has significant downstream consequences
  • Privileged accounts with access to financial data are high-value targets that justify sophisticated, targeted attacks
  • Regulatory and audit expectations around access controls are tightening, not loosening

The Compliance Opportunity:

Deploying phishing-resistant MFA is one of the cleaner wins available in a SOC 2 or ISO 27001 program. It is technically well-supported in Microsoft Entra today, it maps directly to documented control requirements, and it eliminates a real attack vector rather than just satisfying a checkbox.

One thing worth watching: Microsoft recently announced that Entra passkeys will support sign-in on personal and unmanaged Windows devices using the Windows Hello container. This is significant for organizations that deal with contractors, board members, or external advisors accessing Entra-protected resources on personal devices — the same phishing-resistant guarantees, extended to a broader device population.

Questions? Contact us for a complimentary access controls assessment.

📬 Stay Updated

Subscribe to receive weekly security and compliance insights directly in your inbox.

Questions or feedback? Contact us

GRC Vitrix provides cloud security and compliance advisory for financial services professionals. This article references publicly available information from Microsoft, FIDO Alliance, and industry sources.