Every May, World Passkey Day arrives with a fairly simple pitch. Passwords are bad, passkeys are good, so go adopt passkeys. And the pitch is right. The FIDO Alliance, Microsoft, Apple, and Google have spent years building toward a world where cryptographic device-bound credentials replace the phishable string of characters most people still use to protect their digital lives. Passkeys make phishing attacks against the authentication event itself extremely difficult.
But there's a question the World Passkey Day press releases don't answer. It's the one that matters most when you're deploying passkeys at scale across thousands of employee accounts in Microsoft Entra ID.
Who actually verified the person who enrolled that passkey?
Passkeys Solve Authentication, Not Identity
Before an employee enrolls a passkey for their Entra account, the directory confirms the account exists and that the session is authenticated. What it doesn't confirm is whether the person on the other side of that session is the legitimate account owner. If an attacker has already compromised an account through credential theft or social engineering, passkey enrollment becomes their most durable next move. Once that passkey is saved, the attacker has a device-bound credential that survives password resets and MFA changes. Most organizations won't know it's there until long after the damage is done.
This isn't theoretical. Account takeover followed by passkey enrollment is documented behavior in nation-state and cybercrime campaigns. According to Verizon's 2024 Data Breach Investigations Report, 80% of breaches begin with compromised credentials. The threats passkeys were designed to stop are the same threats being used to compromise accounts before passkeys are even enrolled.
Strong Credentials Need Strong Enrollment
Microsoft Entra ID's self-service security info registration is the flow where employees enroll passkeys and other authentication methods. By default, it requires that the user is authenticated, not that the user is identity-verified. A compromised session, a stolen credential, a convincing social engineering call to IT — any of these can produce an authenticated session. None of them produce a verified human.
That gap isn't a flaw in Entra. It's a gap in scope. Entra manages accounts and credentials. Verifying the human behind those accounts is a separate layer it was never designed to provide.
Yubico — whose hardware security keys are widely regarded as the strongest authentication factor in enterprise security — recognized exactly this gap. They recently partnered with Nametag to ensure that every YubiKey is issued to and activated by a verified person, because even the world's most trusted credential is only as trustworthy as the enrollment process behind it.
The same logic applies to passkeys in Entra.
The Fix Already Exists in Entra
Microsoft Entra ID supports a mechanism called External MFA methods, which lets organizations integrate a third-party identity verifier directly into the Entra authentication flow. Nametag integrates as an external MFA method.
When you combine Nametag as an external MFA method with Entra's Conditional Access policies, you can require that a user complete Nametag identity verification before they can enroll a passkey for their account. The result is straightforward: no one adds a passkey to an account without first proving, biometrically, that they are the legitimate account owner.
The verification is not a friction-heavy process. A first-time user scans their government-issued ID, then takes a selfie that captures a 3D facial scan. This process protects organizations from injection and presentation attacks by checking for actual depth geometry that photos and screens cannot reproduce. It takes as little as 27 seconds. Returning users verify with a quick selfie matched against their established biometric profile in about 3 seconds, which is faster than approving a push-based MFA notification.
Every verification generates an auditable record. Not which account was authenticated. Which verified human enrolled this passkey, at this time, for this account. For new employees without an existing biometric profile, Microsoft's Temporary Access Pass handles the bootstrapping — our Entra external MFA method setup guide walks through the full configuration.
What Makes a Passkey Trustworthy
Passkeys inherit whatever identity assumptions already exist in your directory. If your organization has been operating on unverified assumptions about who owns which account, a passkey rollout doesn't fix that — it encodes those assumptions into a credential that's hard to revoke and hard to detect when it's in the wrong hands.
Identity-verified enrollment changes that. When a passkey can only be enrolled after Nametag confirms the person against a government-issued ID, the credential and the verified human are in sync from day one. And because the same biometric profile carries forward across account recovery, helpdesk interactions, and high-privilege actions, the verified identity doesn't restart every time — it compounds.
Is Your Passkey Rollout Secure?
The right question isn't "have we deployed passkeys?" It's "do we know who enrolled them?"
If you're planning a large-scale Entra passkey deployment, adding Nametag as an external MFA method and enforcing it at the "Register security information" action is a configuration that can be tested in Report-only mode, scoped to a pilot group, and validated before full rollout. The technical lift is manageable. The identity assurance it adds is not available through Entra alone.
The strongest passkey is one that was issued to the right person. Reach out to our team to talk through what that looks like in your environment.
