Why Passkeys Are Secure — How They Work, How They Sync, and What to Watch for If You Lose a Device

“You can log in with your fingerprint, so it is secure.” Passkeys are sometimes introduced this way, but the core of their security is not the fingerprint or the face itself. It lies in proving by signature that you hold the key for that site, without handing the private key to the service you log in to.¹

That said, if you take this to mean “a passkey can never be taken over” or “the private key never leaves the phone under any circumstances,” you will make the wrong calls about syncing and about a lost device. Hardening the login mechanism is one thing; the device, the recovery methods, and the post-login session becoming secure automatically is another.

This article starts from the difference against passwords, illustrates the registration and login flows, and then works through why passkeys resist phishing, how synced and device-bound passkeys differ, and what to do when a device is lost. The second half covers the points to check when rolling passkeys out to your own web service or to Windows business systems.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (38 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

1. There Are Three Reasons Passkeys Are Secure

A passkey is a credential based on public-key cryptography that can be used to log in in place of a password. Of the key pair created at registration time, the private key stays under the user’s control and the public key is registered with the service. On the web, registration and authentication use a standard API called WebAuthn.¹²

flowchart TB
        accTitle: Three authentication weaknesses that passkeys change
        accDescr: Handing over a secret, replaying a response, and mistaking where a credential may be used are each handled by a different mechanism.
        A["Logging in with a passkey"] --> B["Return a signature, never the private key"]
        A --> C["Match the challenge and consume it"]
        A --> D["Check the RP ID and the origin"]
        B --> E["The public key alone cannot forge a signature"]
        C --> F["An earlier response cannot be replayed"]
        D --> G["Unusable on an unrelated fake site"]

Figure 1: The strength of a passkey comes from combining cryptography, a single-use request, and a restriction on where the credential may be used.

When this article says the private key “is never sent,” the destination in question is the server of the service you log in to. With a synced passkey there is a separate path that stores and replicates the private key in encrypted form. Separating the two resolves the question of what “never sending the secret” can mean when the key syncs to the cloud.

The server also holds more than the public key: the credential identifier, its mapping to an account, session information, and so on. “The public key alone is not enough to impersonate someone” and “the database does not need protecting” are not the same statement.²

2. What Long Passwords and One-Time Codes Leave Behind

In ordinary password authentication the password the user types is sent to the server over a TLS-protected connection, and the server compares it against a stored hash or similar. A properly salted hash with a high enough computational cost makes repeated guessing attacks after a leak of the stored data difficult. Random, long passwords that are not reused are worth having as well.³

If the same password is reused across several services, credential stuffing — trying an ID and password pair leaked from one place against other sites — can spread the damage to other accounts. A long password does not stop that spread if it is reused.⁴

Even so, one thing remains: the correct password can still be handed to the wrong party. If you type your genuine password into a site the attacker set up, the value reaches the attacker even when that site’s TLS certificate is valid. TLS has not been broken; you have mistaken who you are securely talking to.

sequenceDiagram
        accTitle: TLS alone does not prevent input to a fake site
        accDescr: The password and code a user types into a fake site reach the operator of that fake site even over an encrypted connection.
        participant U as User
        participant P as Fake site
        participant S as Genuine service
        U->>P: Types the genuine password
        P->>S: Relays the entered password
        S-->>P: Requests additional authentication
        P-->>U: Asks for a one-time code
        U->>P: Types the code
        P->>S: Relays the code while it is still valid
        S-->>P: Issues a session when verification succeeds

Figure 2: An outline of AiTM phishing, which relays the password and the code in real time.

TOTP is a scheme in which the authenticator app and the server hold a shared seed and generate a code from the current time. The seed itself is not sent on every login. But the code the user types is not bound to the genuine site’s domain, so within its validity window there is room for a fake site to relay it. SMS codes have the same problem of being typeable into a fake site.³

This is not to say that multi-factor authentication is pointless. It blocks more attacks than password-only authentication does. On top of that, against attacks that go after the manual entry of a code, there is a reason to move on to phishing-resistant authentication such as FIDO/WebAuthn.⁵

Generating strong passwords in a password manager and autofilling them only on the correct domain is an effective measure too. But the user can still copy that password and paste it into a different field. What makes a passkey different is that the user cannot lift this restriction on where the credential may be used through their own actions alone.

3. What Actually Travels During Registration and Login

Registration Creates a Key Pair and Binds It to the Account

There are three broad roles in handling a passkey: the relying party (RP) on the service side, the browser and OS that provide WebAuthn, and the authenticator that generates and uses the key. Authenticators include ones that work with OS features and credential managers, and external FIDO2 security keys. Matching a face or a fingerprint is the step that authorizes their use.²⁶

sequenceDiagram
        accTitle: The passkey registration flow
        accDescr: A key pair is created in response to the registration request, and the service verifies the registration response and binds the public key and the credential ID to the account.
        participant S as Service
        participant B as Browser and OS
        participant A as Authenticator
        S->>B: Challenge and account information
        B->>B: Checks where the credential will be used
        B->>A: Request to create a credential
        A->>A: User verification and key pair generation
        A-->>B: Public key, credential ID, and more
        B->>S: Sends the registration response
        S->>S: Verifies the registration response
        S->>S: Registers the credential on the account

Figure 3: What gets registered is not only the public key but a response that includes an identifier and verification data. The private key is never sent to the service you log in to.

The credential ID is the value that identifies which passkey is which. The server stores it mapped to the public key and to the account. When adding a new passkey to an existing account, first confirm through an existing method that the person is the user of that account, and re-authenticate where necessary. The account to register against must never be decided from a username sent by the browser alone.⁶⁷

Normally a separate key pair is created when registering with a different service or a different account, so users never have to do anything equivalent to reusing a password. That said, this is not a mechanism that prevents users from being correlated through other information such as an email address, and it does not mean that “using a passkey makes you anonymous.”

Login Returns a Signature Over the Current Request

At login the server issues a challenge, a random value that is hard to predict. The authenticator produces a signature with the private key, and the browser returns it to the server. The server verifies it with the registered public key and confirms that it is a correct response to the request it issued this time.⁶

sequenceDiagram
        accTitle: The passkey login flow
        accDescr: The authenticator produces a signature bound to the current request, and the server verifies the signature, the challenge, where it was used, and the account.
        participant S as Service
        participant B as Browser and OS
        participant A as Authenticator
        S->>B: An unused challenge and the RP ID
        B->>B: Checks that the intended site is valid
        B->>A: RP ID and the hash of the data
        A->>A: Confirms with biometrics or a PIN
        A->>A: Signs with the private key
        A-->>B: Authenticator data and the signature
        B->>S: Credential ID and the authentication response
        S->>S: Verifies the response and the account
        S-->>B: Issues a session only on success

Figure 4: The login response is proof of holding the private key, not the private key itself.

More precisely, the data signed at authentication time is the following. || denotes concatenation of byte strings.⁸

Signed data = authenticatorData || SHA-256(clientDataJSON)

clientDataJSON:
  type       webauthn.get for authentication
  challenge  the challenge the server issued
  origin     the origin of the caller

authenticatorData:
  rpIdHash   SHA-256 hash of the RP ID
  flags      results such as user presence and user verification
  signCount  signature counter

“Signing the challenge” is a shorthand used to grasp the whole picture. In practice, where the credential is used and the state of the authenticator also take part in verifying the signature. The division of labor matters too: the authenticator does not read the web page to determine the origin, it receives the hash of the client data that the browser collected.

flowchart TB
        accTitle: The data bound into the signature at authentication time
        accDescr: The hash of the client data, which includes the challenge and the origin, is concatenated with the authenticator data, which includes the hash of the RP ID, and the result is signed.
        A["Challenge, origin, and more"] --> B["Hash of clientDataJSON"]
        C["Hash of the RP ID, flags, and more"] --> D["authenticatorData"]
        B --> E["Concatenate authenticator data and the hash"]
        D --> E
        E --> F["Sign with the private key"]

Figure 5: Not only the challenge but also where the credential is used and the state of the authenticator take part in verifying the signature.

An earlier signature cannot be replayed, but not because the signature itself expires with time. It is because the server binds the challenge to a login attempt, sets a deadline, and refuses to accept a request that has already been used. Successful public-key signature verification on its own is not a sufficient condition for allowing a login.

4. Why Even a Pixel-Perfect Fake Site Cannot Use Your Passkey

RP ID and Origin Play Different Roles

The RP ID is the domain name that determines a credential’s scope, and it is usually specified as something like example.com. The origin, by contrast, is the combination of scheme, host, and port. One conceivable arrangement is https://login.example.com as the origin and example.com as the RP ID.⁹

Under the usual domain-relationship check, a page on login.example.com may specify example.com as the RP ID. A page on the unrelated examp1e.com, however, cannot specify example.com and use the passkey meant for the genuine site. What the browser verifies is the relationship to the site where the credential will be used, not whether the two look alike.

flowchart TB
        accTitle: How the RP ID restricts where a credential may be used
        accDescr: A page with a legitimate domain relationship and an unrelated fake site get different decisions from the browser when they request the genuine RP ID.
        A["Specify example.com as the RP ID"] --> B{"Where is the caller"}
        B -->|"login.example.com"| C["Meets the domain relationship condition"]
        B -->|"examp1e.com"| D["Rejected as an unrelated domain"]
        C --> E["Proceed to authenticate with the matching passkey"]
        E --> F["Server also verifies it is an allowed origin"]
        D --> G["The passkey for the genuine site cannot be used"]

Figure 6: Both the browser’s restriction on where a credential may be used and the server’s origin verification underpin phishing resistance.

On the server side too, verify that the origin returned with the signature is an allowed origin and that rpIdHash is the hash of the expected RP ID. A key created under a fake site’s own RP ID, or a response from an origin you have not allowed, must never be accepted as authentication for a genuine account.⁸

Note that WebAuthn Level 3 also has Related Origin Requests, which let the same RP ID be used from another origin that the service has explicitly associated. The claim that “it can never be used unless the host name matches exactly” is not accurate either. What matters is keeping use of the credential inside the scope the service has approved. Even when you use related origins, that is not about widening the server’s allowlist without limit.⁹

“Phishing Resistance” Is Not Resistance to Every Kind of Fraud

Everything explained so far assumes that the browser, the OS, and the authenticator are trustworthy and that the server performs the verification it must. Compromise of the genuine site, malware on the device, and a weak account recovery procedure are not things WebAuthn alone can solve.

A fake site may steer you with “passkeys are unavailable, so please enter your password and SMS code,” and you end up using a different login path. Passkeys are strong against the breakage of handing genuine credentials to a fake site; they do not mean users never have to pay attention again.⁵

5. Fingerprint, Face, and PIN Are Not Passwords Sent to the Server

You are asked for a fingerprint or a face when using a passkey so that the device can confirm that its legitimate user is approving the operation that uses the private key. This step is called user verification (UV). A WebAuthn authentication response never carries a fingerprint image or a facial feature vector to the service you log in to.¹²

flowchart TB
        accTitle: Local user verification on the device and signature verification at the service
        accDescr: Fingerprint, face, and PIN are used on the user's side to authorize use of the key, while the service checks the signature and the verification result rather than any biometric data.
        A["Confirm with fingerprint, face, or PIN"] --> B["Authenticator authorizes use of the private key"]
        B --> C["Build the signed authentication response"]
        C --> D["Service verifies it with the public key"]
        D --> E["Service also checks the requested user verification result"]

Figure 7: Unlocking the device and authenticating to the service work together, but the server does not match the fingerprint or the PIN.

If a PIN is enough to use it, you may feel that this is the same as a password. The difference is what that PIN is matched against. The PIN here exists to authorize use of the authenticator; it is not a password that a website holds for every user and receives on each login. A well-designed authenticator also enforces a limit on the number of wrong entries.³

Still, if the device is stolen and the way to unlock it is known as well, the risk that an attacker can use the passkey rises. Switching to face recognition does not make it acceptable for the device passcode to be simple. Also, user presence (UP), which indicates something like a touch on the screen, is a different flag from UV by biometrics or PIN. Implementers request the UV they need and check it in the response as well.

6. Synced and Device-Bound Passkeys Protect Different Places

Some passkeys sync between devices, and others are bound to a specific authenticator. Both authenticate without handing the private key to the service you log in to, but they differ in how the key is stored, replicated, and restored.¹⁰

flowchart TB
        accTitle: Syncing and logging in are different paths
        accDescr: A synced passkey replicates the key through an encrypted vault, but what both synced and device-bound passkeys send to the service is an authentication response.
        V["Encrypted sync vault"] <-->|"Sync and restore"| A["Synced passkey on device A"]
        V <-->|"Sync and restore"| B["The same passkey on device B"]
        A -->|"Signed response"| S["The service being logged in to"]
        B -->|"Signed response"| S
        K["Device-bound authenticator"] -->|"Signed response"| S

Figure 8: Separating the sync path that replicates the private key from the login path to the service makes the difference between the two clear.

Apple’s and Google’s implementations protect synced passkeys with end-to-end encryption. The design is not one in which the provider can read the data stored in the cloud as is and obtain the private key.¹¹¹²

On the other hand, restoring on a new device can require, in addition to signing in to the sync account, something like the previous device’s screen lock or the vault’s PIN. The exact conditions differ by product and configuration. You can neither say that “the cloud account password alone restores every passkey” nor that “getting the cloud account back always restores them.”¹¹¹³

With synced passkeys, if the vault’s unlock and recovery methods and the participating devices are compromised as well, the impact can spread across several services. Multi-factor authentication on the sync account, a strong device lock, and management of the recovery destinations all matter. Where the service supports it, consider protection with a physical security key too. But if the recovery key is kept only on the same device or in the same vault, you have built an arrangement in which you lose everything at once.

Assurance levels in an organization need attention too. Under NIST SP 800-63B-4 a syncable authenticator may be used at AAL2 if it meets the conditions, but it cannot be used at AAL3, which does not permit export of the private key. Conversely, a device-bound passkey does not automatically reach AAL3 either; it still has to meet the remaining requirements, such as hardware protection.¹⁴¹⁵

Using Your Phone via a QR Code Is Not the Same as Syncing

There is also a method in which you scan a QR code shown on a PC with your phone and log in with the passkey on that phone. FIDO’s cross-device authentication confirms proximity over Bluetooth or similar and performs the authentication on the phone. This is not an operation that copies the phone’s private key to the PC.¹⁶¹

flowchart TB
        accTitle: Logging in to another PC with the key on your phone
        accDescr: The phone scans the QR code on the PC, and authentication proceeds through a proximity check and user verification on the phone. It is not a flow that copies the private key to the PC.
        A["PC login screen shows a QR code"] --> B["Scan the QR code with the phone"]
        B --> C["Confirm proximity between the devices"]
        C --> D["User verification and signing on the phone"]
        D --> E["Service verifies the authentication response"]
        E --> F["Login completes on the PC"]

Figure 9: Cross-device authentication uses the phone in your hand as the authenticator and does not replicate the key onto the PC.

It can work even from a PC that does not share the same sync destination, but it is no backup for losing the phone that stores the key. Keep “I was able to log in from the PC” and “an independent passkey is registered on the PC as well” apart.

7. When You Lose a Phone, Stop the Device, the Credential, and the Session Separately

When a device is lost, arrange a remote lock and similar measures from a safe device, and if abuse is suspected, contact the service’s or the organization’s support desk promptly. In parallel, check whether you can get into the account with a backup passkey or a recovery method. There is no need to wait until recovery is finished before reporting the loss or suspending use. Protecting the device, protecting the sync account, and revoking on the service side play different roles.¹⁷¹⁸

flowchart TB
        accTitle: What to check separately when a device is lost
        accDescr: While securing the lost device and contacting the support desk, check for a safe recovery method. Revoking the passkey and ending existing sessions are done separately.
        A["The device was lost"] --> B["Remote lock and contacting the support desk"]
        A --> C["Check backup keys and recovery methods"]
        B --> D["Suspend use of the risky passkey"]
        C --> E["Sign in to the management screen from a safe device"]
        D --> F["End existing sessions separately"]
        E --> F
        F --> G["Check sync destinations and registered authentication methods"]
        G --> H["Set up a new key and a backup in a safe environment"]

Figure 10: Stopping the device, revoking the passkey, and terminating the logged-in state are three separate actions.

With a device-bound passkey you can separate the steps: revoke the lost authenticator’s credential on the service side and use a separately registered backup credential. With a synced passkey the copies on several devices are one and the same credential as far as the service is concerned, so deleting that credential on the service side also stops the copies on your other devices from logging in to that same service. You cannot count on being able to revoke the copy on a single device individually from the service side.¹⁰²

A remote wipe does not necessarily take effect immediately either if the device is offline. With Apple’s Find My, erasing an offline device begins the next time that device comes online.¹⁹ It is dangerous to conclude that merely removing a device from the sync account has reliably made the copy of the private key on that device unusable. Where there is concern about abuse, you need to decide to suspend or revoke the credential in question promptly at each service. If you cannot log in, use the official support channel and work through the procedure for the legitimate user to get back in at the same time.

Also, deleting a passkey does not by itself necessarily end every existing session. Check separately for a feature such as the service’s “sign out of all devices,” and check as well that no suspicious passkey or recovery destination has been added.²⁰¹⁸

Before you ever lose a device, it pays to find out whether your important services support registering more than one passkey, to register an independent backup, and to try actually logging in with it. Having the same key on two devices through syncing is convenient, but it is not the same as having registered a second, separate key. Before deleting your last means of logging in, confirm the ways back in, including where your recovery codes are kept.

8. Where the Weak Points Remain Even with Passkeys

Passkeys harden an important part of authentication, but the normal login screen is not the only way into an account. When rolling them out, inspect the following paths in addition to asking whether more people are using passkeys.

flowchart TB
        accTitle: Attack paths that remain after rolling out passkeys
        accDescr: Aside from passkey login, weak alternative methods, the recovery procedure, the device and the vault, and existing sessions all remain targets.
        B["Weak alternative login"] --> A["Unauthorized access to the account"]
        C["Abuse of the recovery procedure"] --> A
        D["Compromise of the device or the vault"] --> A
        E["Abuse of the session"] --> A

Figure 11: Even when the normal passkey login is strong, the other entrances and the post-login state have to be protected individually.

Alternative login. If the same operations can be performed with a password or SMS alone, attackers can aim there instead. Disabling everything at once before backups and recovery have been checked, however, locks legitimate users out too. Get supported devices, backup keys, and support procedures in place, then narrow the scope and reduce the alternatives in stages.⁵

Account recovery and key enrollment. Relaxing identity verification on nothing more than a claim that “my device broke” turns into a path for getting the attacker’s own passkey registered. For important accounts, combine verification of the recovery request, re-authentication when an authentication method is added or removed, change notifications, and auditing. A notification on its own does not prevent an unauthorized enrollment, so the check has to happen before the enrollment.¹⁸

The device and the sync vault. Keeping the OS and the browser updated, locking the device, and knowing which devices participate in the vault all remain necessary. A passkey is not a feature that turns an insecure PC into a secure one. On shared devices, check who the configuration lets use the credential as well.

Sessions. If an ordinary session cookie can be stolen and used, an attacker can sometimes operate without performing a new passkey authentication at all. Design Secure, HttpOnly, an appropriate SameSite, lifetimes, re-authentication, and server-side revocation separately. HttpOnly restricts JavaScript from reading the cookie, but it does not prevent XSS from abusing a logged-in session.²⁰

9. Key Points When Rolling Passkeys Out to Your Own Web Service

Calling the API Is Not the Whole Login Implementation

WebAuthn’s registration API is navigator.credentials.create() and its authentication API is navigator.credentials.get(). FIDO2 consists of WebAuthn and CTAP, and CTAP is the specification for how a client talks to an authenticator such as an external security key. Web service implementers do not have to build the USB or Bluetooth communication themselves.²¹

flowchart TB
        accTitle: Division of responsibilities when implementing passkeys in a web service
        accDescr: The server issues requests and verifies responses, the browser provides the API, and the authenticator uses the key.
        S["Server - issues requests and verifies responses"] <-->|"Requests and responses"| B["Browser - the WebAuthn API"]
        B <--> O["Integration with the OS and credential managers"]
        B <-->|"CTAP and similar"| A["External authenticator"]

Figure 12: Implement the browser-side call together with verification and account management on the server.

Next is the browser-side skeleton, showing where the values passed to the API belong. This fragment alone does not complete registration or login. registrationOptions and authenticationOptions are values the server built for this particular attempt, and binary items such as challenge, user.id, and the credential ID are assumed to have already been converted into the appropriate byte strings rather than left as the Base64URL strings from the JSON.²

// Call this from the register button. The server issues and stores the options.
async function createPasskey(registrationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("Passkeys are not available in this environment.");
  }
  const credential = await navigator.credentials.create({
    publicKey: registrationOptions,
  });
  if (!credential) throw new Error("Passkey registration did not complete.");
  return credential;
  // The caller serializes the registration response and sends it to the server.
  // Do not report registration as complete until the server's check succeeds.
}

// The normal authentication flow, called from the login button.
async function usePasskey(authenticationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("Passkeys are not available in this environment.");
  }
  const assertion = await navigator.credentials.get({
    publicKey: authenticationOptions,
  });
  if (!assertion) throw new Error("Passkey authentication did not complete.");
  return assertion;
  // The caller serializes the authentication response and sends it to the server.
  // The server verifies it and creates a session only when that succeeds.
}

In a real UI, handle the rejected promise in the caller and explain cancellation, timeouts, unsupported environments, and so on. For the binary conversion of the registration response and for the network calls, using the corresponding APIs of whichever library you adopt reduces the chance of missing something.

In the registration options, authenticatorSelection.residentKey: "required" is the setting that requests a discoverable credential the user can pick an account with. In a design that makes confirmation by biometrics or PIN mandatory, specify authenticatorSelection.userVerification: "required" at registration and userVerification: "required" at authentication. Make user.id an opaque identifier of at most 64 bytes issued by the server, do not use the email address itself, and keep it distinct from the display name.⁷

If you use Conditional UI, which offers the passkey as an autofill suggestion in the login field, check for support with PublicKeyCredential.isConditionalMediationAvailable() and combine mediation: "conditional" with autocomplete="username webauthn" on the input field. For environments without support, keep the normal button-driven flow shown above.²²

Design What the Server Verifies Before You Write It

For verifying the cryptographic part you can use libraries such as SimpleWebAuthn on Node.js or fido2-net-lib on .NET. Having a library, however, does not automatically make the binding to accounts or the recovery design safe.²³²⁴

This table is a set of checkpoints for the implementation, not a replacement for the verification procedures in the specification. If you use iframes or related origins, check the additional conditions those bring as well. For ordinary explicit authentication, check UP, and if you made UV mandatory, check UV in the response too.⁷⁸

flowchart TB
        accTitle: The server-side authentication decision
        accDescr: A session is issued only after checking the correspondence with the current request, where the credential was used, the owner of the credential, and the signature and policy.
        A["Authentication response received"] --> B{"Does it match this unused request"}
        B -->|"Yes"| C{"Are the site and the owning account correct"}
        C -->|"Yes"| D{"Are the signature and the required results correct"}
        D -->|"Yes"| E["Consume the request once and issue a session"]
        B -->|"No"| X["Reject the authentication"]
        C -->|"No"| X
        D -->|"No"| X

Figure 13: Confirm both that the signature is valid and that this request should be allowed to log in to that account.

signCount is not an all-purpose clone detector either. Some authenticators have no counter and return 0, and there are reasons other than duplication for a value not to increase monotonically. Check how the environments you support, synced passkeys included, and your library handle it, and use anomalous values as an input to a risk decision. Avoid blanket judgments such as “at or below the previous value always means a clone” or “0 means it is safe.”⁸

In a test environment, check WebAuthn’s secure context requirement and its RP ID requirement separately. HTTPS is normally required, and http://localhost can be used for development. That http://127.0.0.1 is treated as a potentially trustworthy origin is a different matter from whether an IP address can be an RP ID. Because a WebAuthn RP ID has to satisfy domain name conditions, test during development with a configuration your browser accepts, such as localhost. Credentials created there cannot simply be carried over to the production domain.⁹²⁵

10. What to Check on Windows and In-House Systems

On Windows, the important thing is not to conclude where a passkey is stored or whether it syncs from the mere observation that “the Windows Hello prompt appeared.” User verification by Windows Hello and storage and syncing with a credential manager from Microsoft or another vendor are separate items to check. Some passkeys are stored locally and others are stored with a sync provider.²⁶

flowchart TB
        accTitle: The order of checks when rolling out passkeys on Windows
        accDescr: Check the login target, where the credential is stored, the organization's permission policy, and recovery after a loss, separately and in that order.
        A["What are you logging in to"] --> B["Distinguish web services, Entra ID, and Windows"]
        B --> C["Check where the passkey is stored and whether it syncs"]
        C --> D["Check the authentication methods policy and the authentication strength"]
        D --> E["Test backup keys and the procedure for a loss"]

Figure 14: The same Windows Hello prompt can mean different things operationally depending on the login target and the storage location.

Credentials kept in the Windows Hello local container are not the same as a synced vault. In a Windows Hello configuration that uses the TPM, TPM protection of the key plays an important role. Even so, do not equate the general classification of passkeys with the presence of a TPM; judge by the actual storage location, the device, and the organization’s requirements.²⁷²⁸

In Microsoft Entra ID, design the authentication methods policy that permits passkey use separately from Conditional Access authentication strength, which decides how strong an authentication a given resource demands. Merely making it possible to register a passkey does not automatically restrict all access to phishing-resistant MFA. Which kinds of passkey you permit, synced ones included, should be settled against the current support status and your organization’s policy.²⁹

If you are making an in-house web app support WebAuthn directly, first get HTTPS, certificates, name resolution, and a domain name that will serve as a stable RP ID in place. If you delegate the work to an identity platform, the app side designs the integration with that platform and its session management. Using Entra ID from a WinForms or WPF app and the app itself becoming a WebAuthn relying party are not the same thing either.

Passkeys are also not a feature that automatically replaces authentication to SMB shares or directly fixes NTLM or Kerberos problems. Deciding which login you are changing, and first trying registration, authentication, loss, and recovery on a small target, is what leads to a rollout that does not stop the business.

11. Summary — Not Handing Over the Secret and Protecting Everything Around It Go Together

The strength of a passkey lies in authenticating with a signature bound to the current request and to the site where it is used, without handing the private key to the service you log in to. A leak of the public key alone does not let anyone produce a valid signature, and the credential meant for the genuine site cannot be used from an unrelated fake site.

At the same time, the synced vault, the device lock, alternative logins, the recovery procedure, and the post-login session all still have to be protected. Separating the measures that switching to passkeys makes unnecessary from those that remain necessary is the perspective you need to evaluate a rollout correctly.

As a user, check where your passkeys are stored and what your recovery methods are, and set up an independent backup for important accounts. As an implementer, design server-side verification, management of multiple passkeys, and revocation and recovery as a single feature. Covering that much is what carries the convenience and the phishing resistance through into real operation.

Related Articles

• What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• Integrating Entra ID Authentication into WinForms/WPF Apps — A Practical Architecture with MSAL.NET and the WAM Broker
• Handling Credentials Safely in PowerShell — Banishing Plaintext Passwords from Your Scripts
• A Minimum Security Checklist for Windows App Development
• Where Should SMEs Start on Security? — A Walkthrough of IPA’s “Information Security Guidelines for SMEs,” 4th Edition

Related Consulting Areas

At Komura Soft LLC we handle Custom Software Development that includes reviewing the authentication features of in-house web systems, integrating with Entra ID, and building authentication into Windows business applications such as WinForms and WPF. When you are considering passkey support as well, we organize not just the login screen but the devices in use, the existing authentication platform, and the recovery procedures together.

References

Specifications and product information were checked as of September 8, 2026. The features available differ depending on browser, OS, and tenant settings.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Why are passkeys safer than passwords?

Because they authenticate with a signature bound to the current challenge and to the site where it is used, without ever handing the private key to the service you log in to. A leak of the public key alone does not let an attacker forge a signature, and a passkey meant for the genuine site cannot be used from an unrelated fake site. Even so, the server still has to perform the proper verification, and the device, the recovery methods, and the session still have to be protected.

Is fingerprint or face data sent to the site?

A WebAuthn authentication response never carries a fingerprint image or a facial feature vector to the service you log in to. Biometrics and the PIN are used on the user's side to authorize use of the private key, while the service checks the signature and the user verification result.

If the private key is never sent, how can a passkey sync?

Because authentication to the service and synchronization by the credential manager are two different paths. A synced passkey encrypts the private key and replicates it between devices, but that is not the same as handing the private key to the service you log in to. The conditions for unlocking and restoring the sync vault differ by product and configuration.

What happens to accounts that use passkeys if I lose my phone?

With a synced passkey you may be able to use it on another device once you meet the vault's recovery conditions, and with a device-bound passkey you need a separately registered backup credential or a recovery method. While you secure the device and report the loss, check that you have a safe way to recover, and treat revoking the risky credential and ending existing sessions as two separate steps. If the service revokes the same synced credential, the copies on your other devices can no longer log in to that service either.

Do passkeys make anti-phishing measures unnecessary?

No. Passkeys are strong against handing credentials to a fake domain, but being lured into switching to a password or SMS, abuse of the recovery procedure, and compromise of the device or the session all still need their own countermeasures.

Is a passkey used with Windows Hello always device-bound?

The Windows Hello prompt alone does not tell you where the credential is stored or whether it syncs. Distinguish credentials in the local container from passkeys saved with a sync provider, and check the actual storage location, the device, and the organization's policy.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.