Passkeys have been promoted as the future of authentication because they replace passwords with cryptographic credentials that are resistant to traditional phishing. That is a significant improvement. A properly implemented passkey cannot simply be copied from a fake login page and replayed against the legitimate service. But a new campaign targeting Microsoft Entra users exposes an important limitation. Passkey cryptography may be strong, while the process used to enroll a new passkey can still be manipulated.
Attackers are not cracking an existing passkey. They are first taking control of the user’s account and then registering a new passkey on hardware they own. Once that enrollment is complete, Microsoft recognizes the attacker’s passkey as a legitimate authentication method for the victim’s account. The result is a persistent and highly trusted form of account access created through social engineering.
This attack demonstrates that passkeys are not completely secure merely because the underlying protocol is phishing resistant. The security of a passkey system also depends on who is allowed to enroll a new credential, how that person’s identity is verified, where the enrollment is performed, and whether the new credential is bound to dedicated enterprise controlled biometric hardware.
Researchers have documented a coordinated campaign in which attackers impersonate corporate IT personnel and guide employees through what appears to be a legitimate Microsoft passkey enrollment process.
The attack begins with preparation. The criminal registers a domain containing credible terms such as passkey, deploy, register, assign, security, or Microsoft. The site is then customized to resemble the targeted company’s Microsoft 365 environment. It may contain the organization’s branding, familiar Microsoft graphics, realistic login screens, and language that appears consistent with an internal security rollout.
This is particularly effective because many companies are actively encouraging employees to adopt passkeys. A call informing an employee that a new authentication method must be registered does not sound unusual. It sounds like a normal security initiative.
The attacker then calls the employee while pretending to be from IT, the help desk, Microsoft support, or the company’s identity security team. The employee is told that the organization is upgrading its authentication system and that passkey enrollment must be completed immediately. The caller directs the employee to the fraudulent enrollment site. The employee enters a Microsoft username and password, believing the credentials are being provided to the company’s legitimate enrollment portal. The phishing platform immediately transfers those credentials to the attacker. The attacker then enters them into the real Microsoft login page from a separate computer under the attacker’s control.
The employee remains on the fraudulent site while the attacker advances through the legitimate Microsoft authentication process. The phishing platform can dynamically change what the employee sees, allowing the criminal to respond to the authentication steps presented by Microsoft. Once the attacker has successfully authenticated to the legitimate Microsoft account, the attacker begins the real passkey registration process from inside the compromised account.
This is the critical moment. The new passkey is not being created on the employee’s computer, phone, or enterprise issued device. It is being created on an authenticator controlled by the attacker. The attacker can give the credential an innocent looking name so that it appears to be part of the company’s legitimate passkey deployment.
While this is happening, the employee continues interacting with the fraudulent portal. The site may display progress messages, enrollment confirmation screens, or even a fabricated recovery phrase. These elements have no legitimate role in the Microsoft enrollment process. They are simply designed to occupy the employee while the attacker completes the genuine passkey registration elsewhere. Microsoft may then send the employee a legitimate notification stating that a new passkey has been registered.
Under ordinary circumstances, that notification might alert the user to an attack. In this situation, however, the employee has just spent several minutes on the phone supposedly registering a passkey. The real Microsoft message appears to confirm that the process was successful. The attacker has therefore turned the security notification itself into part of the deception.
After enrollment, the attacker possesses a valid cryptographic credential associated with the employee’s real account. The phone call can end. The phishing site can disappear. The employee’s password can even be changed. The attacker can continue accessing the account with the newly registered passkey until the credential is discovered and removed.
It is important to describe this attack accurately. The attacker did not extract the victim’s existing passkey. The attacker did not break the encryption used by WebAuthn or FIDO2. The attacker did not cause a passkey registered for a fraudulent domain to work against Microsoft. Instead, the attacker gained sufficient control of the real account to create a completely new passkey. Because that credential was registered through Microsoft’s legitimate enrollment process, Microsoft treats it as valid.
This distinction is crucial for CISOs. Phishing resistant authentication does not automatically produce phishing resistant enrollment. A strong credential can still be undermined if a weaker process is allowed to create, replace, recover, or approve it.
The security question therefore cannot be limited to whether passkeys are technically resistant to phishing. The more important question is whether the organization can establish with certainty who is registering the passkey, which physical device will contain it, and whether the enrollment is occurring from an authorized endpoint in the presence of the legitimate employee.
Without those assurances, an attacker can exploit the enrollment process to become a trusted user.
A passkey stored on a general purpose computer or mobile device is ultimately dependent on the security and identity controls of that device. The organization may have limited visibility into the device, limited control over its configuration, and limited ability to prove which individual was physically present when the passkey was created.
Dedicated biometric hardware introduces a much stronger trust model.
With Token Biometric Assured Identity, the credential is bound to a purpose built physical authenticator. The private key remains inside the secure hardware and cannot be exported, synchronized through a consumer cloud account, copied to another device, or registered remotely by an attacker.
Authentication also requires a live fingerprint match directly on the Token device. Possession of the user’s account credentials is therefore not enough. Access to the user’s Microsoft session is not enough. Control of a remote computer is not enough. The person requesting access must present the authorized fingerprint to the registered Token hardware.
Token also adds proximity as an enforceable security control. The biometric authenticator must be physically near the computer or mobile device conducting the authentication. That requirement is particularly important in this attack.
The criminal is attempting to register or use a credential from an attacker controlled endpoint located somewhere else. The legitimate employee and the employee’s Token device are not physically present beside that endpoint. The attacker cannot convert a telephone conversation into physical proximity.
The enterprise can therefore require that every new authentication method be approved using the employee’s existing Token device. Adding a passkey, replacing a Token, changing a recovery method, or registering a new computer would require the existing hardware, the registered fingerprint, the legitimate service, and physical proximity to the endpoint conducting the enrollment. The attacker cannot satisfy those conditions remotely.
The first stage of the attack depends on the criminal convincing the employee to participate in a fraudulent process. Token does not require employees to determine whether a caller, website, or enrollment request appears trustworthy. The decision is enforced by the authentication architecture.
A fraudulent site cannot obtain a reusable Token credential because the private key never leaves the device. The credential is cryptographically associated with the legitimate relying party, so a fake domain cannot receive a valid authentication response for Microsoft.
The attacker also cannot duplicate the legitimate credential onto another device. Token credentials are bound to dedicated hardware rather than being synchronized through a general purpose cloud account. Most importantly, the attacker cannot use a compromised Microsoft session to register a new authentication method if Token is required to authorize that enrollment.
The existing Token device would need to be physically present beside the endpoint performing the registration. The authorized employee would need to provide a live fingerprint on the hardware. The request would need to originate from the legitimate service, and the enterprise policy would need to approve the specific enrollment action.
An attacker operating from another location cannot remotely reproduce that chain of trust. The fake enrollment portal may still fool the employee visually, but the deception cannot produce a valid credential. The attacker cannot transfer the Token, cannot copy its private key, cannot manufacture physical proximity, and cannot reproduce the employee’s fingerprint. The attack reaches a hard stop before a new passkey can be registered.
This campaign reveals a larger architectural issue. Authentication security cannot be limited to the moment of login. The same standard must be applied to the entire identity lifecycle. That includes the initial creation of an account, enrollment of a new authenticator, replacement of a lost device, modification of recovery methods, removal of an existing credential, privilege elevation, and help desk assisted account restoration.
A company cannot deploy strong authentication for normal access while permitting support personnel to bypass it through a phone conversation. It cannot require dedicated biometric hardware for login but allow a new passkey to be added through a weaker recovery process. Every path that creates or replaces trust must require the same assured identity.
Token gives enterprises a physical root of trust that can be used throughout that lifecycle. The employee’s identity remains bound to dedicated biometric hardware that the company can register, manage, revoke, and require for sensitive changes.
Passkeys remain an important improvement over passwords. But this attack shows that passkeys alone should not be treated as the final answer for enterprise identity security. The cryptography can be secure while the enrollment process remains vulnerable.
For high value enterprise systems, a passkey should be bound to dedicated biometric hardware. The organization should know exactly which device holds the credential, which employee can unlock it, which endpoint is performing the authentication, and whether the device is physically present during enrollment. That is the difference between passwordless authentication and Biometric Assured Identity.
Token does not merely make the credential difficult to steal. It makes the creation and use of the credential dependent on the legitimate person, the registered physical authenticator, the authorized endpoint, and the real service.
Without those elements, no new credential should be enrolled and no access should be granted. That is how Token stops this attack cold.