As reported by BleepingComputer, a threat actor is actively conducting voice phishing (vishing) campaigns targeting Microsoft 365 users across multiple industry sectors, manipulating victims into enrolling attacker-controlled passkeys into their Microsoft Entra accounts — effectively handing over persistent, phishing-resistant authentication access.
Why This Attack Is Particularly Dangerous
There's a deep irony at the heart of this campaign: passkeys are widely promoted as a defense against phishing. They are hardware- or biometric-bound credentials designed to replace passwords and resist credential interception. Yet this threat actor has identified a critical seam in the enrollment process itself — the moment before a passkey is anchored to a legitimate user's device — and is exploiting it through human manipulation rather than technical exploitation.
This is a textbook example of what security professionals call an enrollment attack surface. The security guarantee of a passkey only holds once it is correctly provisioned to a trusted device. During enrollment, organizations are often dependent on human verification procedures — and that's precisely where social engineering thrives.
"The strength of your authentication technology is only as good as the weakest step in your enrollment workflow. If a help desk agent or end user can be talked into enrolling a new credential, the cryptographic security of the passkey becomes irrelevant."
Who Is at Risk
Any organization using Microsoft 365 and Microsoft Entra ID with self-service or help-desk-assisted passkey enrollment is potentially exposed. This includes:
The Broader Implications for Passwordless Strategies
Security leaders who have invested heavily in passwordless authentication journeys should treat this campaign as a maturity check — not a reason to abandon the strategy. Passkeys and FIDO2 credentials remain significantly more secure than passwords or SMS-based MFA in steady-state operation. However, this campaign reveals that enrollment governance has not kept pace with deployment ambitions.
Most enterprise passwordless rollouts have focused on the end-user experience and technical integration. Far fewer have developed rigorous, auditable procedures for what happens when a user needs to add, replace, or recover a passkey. Attackers have noticed this gap before many security teams have.
This also signals a broader trend: as phishing-resistant MFA becomes more common, adversaries are pivoting from credential theft to identity lifecycle attacks — targeting account recovery, device registration, and enrollment flows rather than attempting to intercept credentials in transit.
Shield53 Recommendations
Immediate Actions
- Audit Entra passkey enrollment logs now. Review Microsoft Entra sign-in and audit logs for unexpected passkey registrations, particularly those not initiated by the user's primary device or outside normal business hours. Look for the
Register security infoaudit event type. - Restrict self-service passkey enrollment. If your organization does not have strict controls on who can enroll new authentication methods, implement Conditional Access policies that restrict passkey registration to trusted, managed devices or require admin approval.
- Require out-of-band identity verification for all credential enrollment changes. Any request to add a new passkey, authenticator app, or recovery method should require a secondary verification step that cannot be completed over a phone call alone — such as a manager approval ticket or in-person verification.
- Train help desk staff specifically on vishing pretexts. Generic phishing awareness is insufficient. Help desk and IT teams need scenario-based training on impersonation calls requesting authentication changes, including escalation paths when requests feel unusual.
Longer-Term Controls
- Implement an Authentication Methods policy in Entra ID to limit which users or groups are permitted to register passkeys, and log all registration events to your SIEM with high-priority alerting.
- Consider requiring a Temporary Access Pass (TAP) issued only through a verified ticketing workflow as a prerequisite for any new passkey enrollment — removing the ability for a caller to initiate enrollment without a formal request chain.
- Establish a "golden rule" for your help desk: legitimate security teams never call users to initiate credential changes. Any unsolicited call requesting authentication actions should be treated as a social engineering attempt until proven otherwise.
- Review your Identity Protection and Defender for Identity alerting rules to surface anomalous authentication method registrations as high-severity incidents.
This campaign is a timely reminder that identity security is not solved by deploying stronger technology — it is an ongoing discipline that must account for the human processes wrapped around that technology. Organizations that treat passkey deployment as a finish line rather than a foundation will find attackers waiting on the other side.