The Evolving Threat: Social Engineering Targets Passkeys

The Paradox of Passkeys: Strong Authentication Meets Human Vulnerability

Passkeys represent a significant leap forward in authentication security, offering robust protection against traditional phishing by binding cryptographic keys to specific devices and services. Their adoption by major platforms like Microsoft Entra ID, now making them the default for many users, is a welcome development in the fight against credential theft. However, recent threat intelligence reveals a critical paradox: while passkeys are technically phishing-resistant, new social engineering tactics are actively exploiting the human element within the passkey adoption and management process.

Enterprise security architects, CISOs, and IAM engineers must understand that the shift to passkeys, while beneficial, introduces a new attack surface. Adversaries are adapting, turning the very process of passkey enrollment and support into a pretext for sophisticated identity hijacking.

The New Wave of Passkey-Focused Social Engineering

Threat actors are leveraging the widespread rollout of passkeys to craft convincing social engineering campaigns. These attacks often mimic legitimate IT help desk communications, exploiting user unfamiliarity or urgency around new security measures. The core objective is to trick users into inadvertently granting attackers access, often by guiding them through a seemingly legitimate process that is, in reality, an adversary-in-the-middle (AiTM) attack or an abuse of authentication flows.

One prevalent tactic involves attackers impersonating IT support via phone calls, SMS, or even Microsoft Teams messages. They claim that a passkey, MFA, or SSO configuration needs immediate updating to prevent loss of access. This "sense of urgency" is a classic social engineering ploy, now re-contextualized for passkey migrations. MINE2 and Tech Pulse highlight these campaigns, noting that attackers began leveraging the Entra ID passkey rollout as a pretext months before Microsoft made passkeys default for SMS/voice MFA users on September 1st, 2026.

Exploiting Trust and Authentication Flows

These campaigns go beyond simple credential harvesting. Attackers are using advanced techniques such as OAuth 2.0 Device Code Flow abuse to gain unauthorized access without needing to steal a user's password. By impersonating IT staff, they can trick users into initiating a device authorization grant, enabling the attacker to link their own device to the victim's account. This allows for session hijacking and persistent access to cloud resources, particularly within Microsoft 365 environments. This method, detailed by Tech Pulse, circumvents the phishing resistance of passkeys by manipulating the authentication process itself rather than attacking the passkey credential directly.

Another critical insight comes from Proofpoint, which observed China-aligned espionage groups using AiTM techniques to relay real Microsoft logins, including one-time codes. While this specific campaign targeted traditional MFA, it underscores the sophistication of current adversaries. The UK's NCSC correctly states that FIDO2 security keys (the foundation of passkeys) "remove this class of attack entirely" by making the credential non-replayable. However, the human element remains a vulnerability if users can be manipulated into inadvertently approving malicious authentication requests or enrolling malicious devices. On The Wire discusses how even one-time codes failed to stop advanced phishing.

What This Means for Enterprise Security Teams

For enterprise security and IAM teams, the shift to passkeys requires a renewed focus on user education and robust monitoring capabilities. While passkeys are indeed a stronger form of authentication, their effectiveness can be undermined by sophisticated social engineering.

Key Considerations:

• Comprehensive User Education: Beyond simply announcing passkey adoption, educate users on the mechanics of passkeys, how legitimate enrollment processes work, and crucially, what suspicious requests look like. Emphasize that IT will never ask for authentication codes or to approve unusual login requests over the phone or via unsolicited messages.
• Strengthen Incident Response for Identity: Traditional account compromise runbooks, which focus on password resets and session revocation, may be insufficient. The "credential that survives your remediation," as highlighted by sbd.org.uk, suggests that simply resetting a password or revoking sessions might not remove an attacker's persistent access if they've abused device code flows or enrolled a rogue passkey.
• Monitor Authentication Flows and Device Registrations: Implement enhanced logging and anomaly detection for new device registrations, passkey enrollments, and OAuth 2.0 device code flow activities. Unusual patterns in these areas could indicate an ongoing attack.
• Review and Harden CIAM Policies: Ensure your Customer Identity and Access Management (CIAM) systems have granular controls over passkey enrollment, recovery, and device linking. Consider policies that require out-of-band verification for sensitive actions like adding new passkeys or initiating account recovery.
• Leverage FIDO2 Attestation: Where possible, enforce FIDO2 attestation to ensure that registered passkeys come from trusted authenticators. This adds a layer of assurance about the legitimacy of the passkey itself.

Conclusion: Beyond Technical Controls

Passkeys are a critical advancement in our journey towards a phishing-resistant future. However, their security benefits are maximized only when integrated into a holistic security strategy that accounts for the persistent threat of social engineering. Enterprises must move beyond relying solely on technical controls and invest in continuously educating their workforce, refining incident response procedures for identity, and monitoring authentication ecosystems for subtle signs of manipulation. The human element, while often the weakest link, can also be the strongest defense if empowered with knowledge and vigilance.