Adversary-in-the-Middle (AiTM) phishing exposes a fundamental weakness in many enterprise authentication programs: A control can satisfy an MFA requirement and still be phishable. By proxying a legitimate sign-in flow, an attacker can relay credentials and one-time approvals, then capture the resulting session token. The user completes MFA, but the attacker inherits the authenticated session.

For IT and identity teams, the question is no longer simply whether MFA is enabled. The more important questions are which authentication methods are allowed, how credentials are enrolled and recovered, which applications still depend on passwords, and whether session controls can contain an account compromise.

This article explains how passkeys, FIDO2 security keys, password managers, and traditional MFA fit into an enterprise identity strategy; and it provides a practical roadmap for moving toward phishing-resistant authentication.

 

why aitm changes the authentication conversation

Traditional phishing focuses on stealing a reusable secret. AiTM phishing goes further by placing attacker-controlled infrastructure between the user and the legitimate service. The proxy presents the real sign-in experience, relays each interaction, and captures the authenticated session after the identity provider accepts the user’s credentials and MFA response.

A typical attack follows this sequence:

  1. The user opens a link to an attacker-controlled domain.
  2. The phishing infrastructure proxies the legitimate sign-in page.
  3. The user submits a password and completes a phishable MFA challenge.
  4. The identity provider issues a session cookie or token.
  5. The attacker captures that artifact and replays it to access the service.

This technique can defeat SMS codes, time-based one-time passwords (TOTP), and some push-based approvals because those methods do not cryptographically bind authentication to the legitimate application origin. Number matching can reduce accidental approvals and MFA fatigue, but it does not make an authentication flow inherently phishing-resistant.

AiTM also highlights why authentication strength cannot be evaluated in isolation. Enrollment, account recovery, device registration, token lifetime, application access, and post-authentication monitoring all influence whether an attacker can establish and retain access.

 

how fido2 and passkeys work

FIDO2 is an open authentication framework built on public-key cryptography. It combines the Web Authentication API (WebAuthn), which allows websites and applications to request strong authentication, with the Client to Authenticator Protocol (CTAP), which enables communication between a client and an external authenticator such as a hardware security key or mobile device.

When a passkey is registered, the authenticator creates a unique key pair for that service:

  • The public key is stored by the relying party.
  • The private key remains under the authenticator’s control and is not disclosed to the application or transmitted during sign-in.

During authentication, the relying party sends a cryptographic challenge. After the user verifies presence or identity with a device PIN, biometric gesture, or security key interaction, the authenticator signs the challenge with the private key. The service validates the response with the corresponding public key.

Origin Binding Provides the Phishing Resistance

A FIDO credential is scoped to a relying party identifier associated with the legitimate service. A credential registered for one domain cannot be used to authenticate to an attacker’s look-alike domain. The browser and authenticator enforce this relationship, shifting domain validation away from the user and into the protocol.

This origin binding disrupts the normal AiTM workflow. The phishing domain cannot request a valid assertion for the legitimate relying party, and it has no password or one-time code to relay.

Not All Passkeys Have the Same Management Model

IT teams should distinguish among platform credentials, synced passkeys, device-bound passkeys, and roaming hardware security keys. Platform credentials are held by an authenticator built into a device. Synced passkeys may be securely synchronized through a credential provider for usability and recovery. Device-bound credentials remain tied to a particular authenticator. Hardware security keys can provide portable, strongly controlled authentication for administrators and other high-risk users.

The right choice depends on assurance requirements, device ownership, platform support, recovery expectations, and the organization’s ability to govern the credential lifecycle.

 

where each authentication control fits

Passkeys, password managers, and MFA applications are not interchangeable. Each addresses a different layer of identity risk, and most organizations will need them to coexist during a transition period.

Passkeys and FIDO2 Security Keys

Passkeys replace shared secrets with asymmetric cryptography and provide strong resistance to credential phishing, credential stuffing, password spraying, and many AiTM scenarios. They are the preferred target state for supported applications, especially for administrators, finance teams, executives, remote-access users, and other high-impact identities.

Password Managers

Password managers generate and store unique credentials for applications that still require passwords. They materially reduce password reuse, weak password selection, and the blast radius of a third-party breach. They do not make a password-based sign-in inherently phishing-resistant, although domain-aware autofill can provide an additional signal when a site does not match the stored credential.

Traditional MFA

SMS, voice, TOTP, and push notifications remain useful when stronger methods are unavailable, but they should be treated as transitional controls rather than equivalent substitutes for phishing-resistant authentication. Organizations should prioritize the strongest available configuration, limit weak fallback options, and apply additional access controls around applications that cannot support modern methods.

Certificate-Based Authentication

Certificate-based authentication can also provide strong assurance when implemented with managed devices, protected private keys, and disciplined certificate lifecycle processes. It may remain appropriate for specialized workloads, regulated environments, or existing public key infrastructure investments, although deployment and recovery can be more operationally complex.

Control

Primary Role

Phishing Resistance

Best Enterprise Use

Passkey or FIDO2 security key

Passwordless, public-key authentication

Strong, through origin binding

Target state for supported applications and high-risk users

Password manager

Unique password generation and secure storage

Limited; passwords remain phishable

Legacy and third-party applications that still require passwords

TOTP, SMS, voice, or push MFA

Additional factor layered onto a password

Variable and generally phishable

Transitional coverage where stronger methods are unavailable

Certificate-based authentication

Device- or user-held cryptographic credential

Strong when correctly implemented

Managed-device, regulated, or PKI-aligned environments

 

enterprise deployment decisions

A passkey rollout is an identity transformation, not simply a new sign-in option. IT teams should define the operating model before enabling broad adoption.

Application and Identity Provider Support

Inventory workforce, customer, cloud, SaaS, VPN, and legacy applications. Identify which systems support WebAuthn or federation through an identity provider that can enforce phishing-resistant authentication. Document legacy protocols and direct-authentication paths that could bypass the intended control.

Managed and Unmanaged Devices

Decide whether users may create credentials on personal devices, whether synced passkeys are permitted, and which high-risk populations require organization-controlled or device-bound authenticators. Align those decisions with device compliance, endpoint management, and bring-your-own-device policies.

Enrollment and Attestation

Protect initial registration as carefully as authentication itself. Require strong proof of identity before a user can add a passkey or security key. Where assurance requirements justify it, evaluate authenticator attestation and approved authenticator models rather than allowing any available credential.

Recovery and Fallback

Recovery cannot become the easiest path around the primary control. Define lost-device procedures, backup credential requirements, help-desk verification, temporary-access methods, and administrative overrides. Monitor and restrict weaker fallback methods so attackers cannot downgrade authentication.

Privileged Access

Start with administrators and other high-impact identities, but pair phishing-resistant authentication with separate administrative accounts, least privilege, privileged access workflows, hardened endpoints, and tighter session policies. Strong authentication does not compensate for excessive standing privilege.

Telemetry and Support

Prepare service-desk teams for enrollment, device replacement, cross-platform behavior, and user verification. Track registration coverage, authentication success, fallback usage, recovery events, blocked legacy authentication, and sign-in risk. These metrics show whether the program is reducing exposure or merely adding another available method.

 

a practical migration roadmap

  1. Assess the current state. Inventory authentication methods, application dependencies, privileged identities, recovery paths, unmanaged-device use, and legacy protocols.
  2. Define assurance tiers. Establish which populations and resources require phishing-resistant authentication, device binding, approved authenticators, or stronger enrollment evidence.
  3. Pilot high-value use cases. Begin with IT administrators and a controlled group of business users. Validate platform compatibility, provisioning, recovery, service-desk procedures, and sign-in telemetry.
  4. Harden enrollment and fallback. Require appropriate identity proofing, provide backup authenticators, limit temporary methods, and alert on credential registration or recovery changes.
  5. Expand by application and user risk. Prioritize email, remote access, administrative interfaces, finance systems, and applications that expose sensitive data or enable lateral movement.
  6. Retire weaker methods. Once coverage and recovery processes are mature, remove passwords or phishable MFA where feasible instead of leaving them available as permanent bypass paths.
  7. Measure and improve. Review adoption, failures, fallback activity, sign-in risk, account compromise, and support volume to refine policy and user experience.

During migration, retain an enterprise password manager for applications that cannot eliminate passwords and use the strongest available MFA for systems that do not yet support phishing-resistant methods. The objective is progressive risk reduction without interrupting business access.

 

passkeys reduce risk, but they do not eliminate it

Passkeys directly address credential phishing and replay, but they do not protect every part of the identity attack surface. IT teams still need controls for:

  • Compromised endpoints: Malware, malicious extensions, remote-control tools, and local privilege abuse can expose data or actions after authentication.
  • Session theft: Attackers may steal an existing token from a compromised device or browser rather than intercept the initial sign-in.
  • Enrollment abuse: An attacker with temporary account access may attempt to register an attacker-controlled authenticator.
  • Recovery abuse: Weak help-desk verification or fallback methods can undermine a strong primary credential.
  • Consent and application abuse: Users can still be manipulated into authorizing malicious applications or granting excessive permissions.
  • Authorization failures: Excessive privileges, stale accounts, and poor entitlement governance remain dangerous after successful authentication.

Layer passkeys with endpoint detection and response, device compliance, conditional access, token protection where supported, risk-based sign-in policies, application consent governance, privileged access controls, and continuous identity monitoring.

 

final takeaway for it leaders

The strategic choice is not passkeys versus password managers. It is how to move from a password-dependent environment to a phishing-resistant identity architecture without creating unmanaged recovery paths or operational friction.

Use passkeys and FIDO2 security keys as the target authentication method for supported services. Maintain an enterprise password manager for unavoidable password-based access. Treat phishable MFA as a transitional control, and strengthen it with access, device, session, and monitoring policies.

The result is more than a better login experience. A disciplined rollout reduces reliance on shared secrets, constrains common AiTM attack paths, and gives IT teams a clearer, more enforceable model for managing identity risk.

How Avertium can help

Avertium helps organizations assess, design, implement, and operationalize passkey management by integrating phishing-resistant authentication with Microsoft Entra, Conditional Access, device trust, secure recovery, and providing ongoing monitoring to reduce credential risk without disrupting user access.

Turn passkeys from a newly enabled authentication option into a secure, governed, and operationally sustainable identity program. Contact us to learn more.

 

 

 

You might also enjoy...

 
password sharing phishing MFA Multifactor Authentication identity access management password managers AiTM Phishing FIDO2 identity security Blog