A passkey lets you sign in with a credential tied to the service you intended to visit. That design helps resist phishing because a lookalike sign-in page cannot use the passkey issued for the real service. Your device may ask for a fingerprint, face scan, or PIN to unlock it. What a passkey does not remove is the need for a way back in when that device is gone.

How a passkey works

The FIDO Alliance, whose standards passkeys are built on, says passkeys replace passwords with cryptographic key pairs. When a passkey is created, the password manager or security key generates a key pair unique to that account on that service. The public key goes to the service and, as Apple puts it, is not a secret. The private key is what actually signs you in, and the server never learns it.

At sign-in, as the FIDO Alliance's Passkey Central site explains, the service sends a random challenge, the device signs it with the private key, and the service checks the signature against the public key it has on record. The service holds nothing equivalent to a password hash, and a passkey is only presented to the site it was registered with. The person approves the sign-in with the same fingerprint, face, PIN or password that unlocks the device, and the FIDO Alliance says biometric data never leaves the device; the server only sees an assurance that the check succeeded.

A passkey on a phone can also sign someone in on a nearby computer. The FIDO Alliance calls this cross-device authentication: the sign-in uses a QR code, and Bluetooth confirms that the two devices are physically close.

What changes for a business

Employees have one less password to type, but administrators still need to know which devices can sign in and what happens when someone replaces a phone or laptop. Some passkeys sync through a provider. Others stay on a device or hardware security key. The distinction affects how you onboard staff, recover access, and remove access when someone leaves.

Turning passkeys on in Microsoft 365 and Google Workspace

Microsoft says passkeys are available in all Microsoft Entra ID editions, including Microsoft Entra ID Free, with no extra licenses. In the Microsoft Entra admin center they are set up in the Authentication methods policies under Passkey (FIDO2), where passkey profiles apply different rules to different groups, up to three profiles including the default one. Microsoft notes that once you opt in to passkey profiles you cannot opt out. Allow self-service set up must be set to Yes for people to register a passkey on their Security info page, and they must have completed multifactor authentication within the past five minutes to register one.

In the Google Admin console, the control is under Security, then Authentication, then Passwordless, where you click Skip passwords and check Allow users to skip their password and authenticate with a passkey. Changing it requires the Security Settings administrator privilege. Google says turning it on does not deactivate or remove the user's existing password, and that enrolling a passkey does not automatically turn on 2-Step Verification.

So on both platforms, switching passkeys on does not by itself close the older ways into an account. Microsoft treats requiring a passkey as a separate, optional step, done with a Conditional Access authentication strength. Microsoft says Conditional Access requires Microsoft Entra ID P1 licenses and is also available to Microsoft 365 Business Premium customers. Whatever methods stay enabled, and whoever can reset them, remain a way in.

A joint advisory from CISA, the FBI and partner agencies shows why that matters. It describes the Scattered Spider group posing as employees to get IT help desk staff to reset their passwords and move their MFA to a device the attackers control. As sign-in gets harder to phish, the recovery process becomes the part worth attacking.

Synced passkeys and device-bound passkeys

Microsoft's documentation describes the two types. A synced passkey is encrypted on the device and stored with a cloud passkey provider, so other devices signed in to that provider can use it, and Microsoft names Apple iCloud Keychain and Google Password Manager as examples. A device-bound passkey is created and stored on one physical device and never leaves it, as with a security key or a passkey in Microsoft Authenticator.

Sync makes a lost phone less of a crisis. Apple says iCloud Keychain is end-to-end encrypted with keys not known to Apple, that passkeys are recoverable even if the user loses all their devices, and that any Apple Account using iCloud Keychain requires two-factor authentication. If the replacement phone uses a different provider and the old device still works, the FIDO Alliance says the old device can sign the person in on the new one so they can create a passkey there. Otherwise, the service can treat the sign-in as a normal account recovery.

The cost is that a synced passkey is only as well protected as the account that syncs it. NIST's authentication guidelines, SP 800-63B-4, require multifactor authentication at an AAL2-equivalent level for access to synced keys, and they note that synced keys can be reached through cloud-based account recovery, which NIST calls a potential weakness. NIST does not allow syncable authenticators at its highest assurance level, AAL3, because their keys can be exported.

Some providers also let people share synced passkeys. NIST says that in a workplace, device management can stop keys leaving approved devices or sync fabrics, its term for any service that stores or transmits the keys away from the user's device. For federal enterprise use, it requires agency-managed accounts for the sync fabric and mobile device management, or equivalent controls, on the devices that hold the keys.

If an employee saves a work passkey to a personal Apple Account or Google Account, the way back into your system runs partly through a recovery process you do not manage. The FIDO Alliance says organizations with a low tolerance for risk benefit most from device-bound passkeys, and that device-bound passkeys in modern hardware security keys offer the highest assurance. Microsoft adds that synced passkeys do not support attestation, the check that verifies a passkey's make and model, and advises treating them as phishing-resistant but with the same security posture as other unattested authenticators.

Choose where credentials should live

The tradeoff looks different for a small team using managed laptops than it does for a team sharing workstations. A synced passkey can make device replacement easier, but the organization should understand the recovery rules of the account that syncs it. A hardware key can provide a separate option for an administrator, but it needs a documented replacement process. Review the options each service actually supports. Keep the pilot small until a second administrator can repeat the recovery steps without relying on the person who wrote them.

Microsoft's own example profiles put IT administrators, executives and engineering on device-bound passkeys with attestation enforced, and HR and sales on synced or device-bound passkeys. For most small offices, rules along these lines hold up:

  • Administrators and anyone who can change sign-in policy use device-bound passkeys on hardware security keys, two keys each.
  • Staff on managed company devices may use synced passkeys, as long as the account that syncs them has multifactor authentication and you know who controls it.
  • Passkeys are not saved to a shared login on a shared workstation, because anyone who can unlock that login can approve them; people there use their own phone or security key.
  • Your records show which type of passkey each person holds, because the recovery steps differ.
  • Before narrowing the allowed passkey types, confirm the people affected have another way in.

Both vendors warn that tightening the rules can strand passkeys people already registered. In Google Workspace, choosing Passkeys restriction, then Allow passkeys on hardware security keys only, means passkeys stored on phones or computers can no longer be used. In Microsoft Entra ID, turning off synced passkeys in a profile, or removing a model you previously allowed from its key restrictions, blocks sign-in with passkeys already registered.

Other mistakes run the opposite way. Microsoft says attestation is checked only at registration, so turning on Enforce attestation later does not block passkeys registered without it; review those in each user's Authentication methods list and delete what does not belong. Microsoft also says a person covered by several profiles can use any passkey that satisfies at least one of them, so an administrator left in an all-staff profile that allows synced passkeys can still register one. And if you have not opted in to passkey profiles and attestation enforcement is off, Microsoft says synced passkeys are already enabled.

Build the recovery path before the pilot

Start with an account that matters and a group small enough to support. Before the pilot, document the recovery path and check whether it works when the employee's usual device is unavailable. After the pilot, ask which steps were confusing and fix the instructions before expanding. Keep emergency administrator access in the plan and verify it separately.

NIST says services should encourage people to keep at least two separate means of authentication, which reduces how often recovery is needed. Its guidelines also require a way to invalidate a lost physical authenticator, such as a security key, as soon as the loss is reported, a notice through a separate channel when a new authenticator is added, and a notification after every account recovery. Write your recovery document so it answers five questions:

  • Who can issue a recovery credential for staff, and who can do it for administrators?
  • How does the person prove who they are with something an impersonator would not have?
  • Which verified channel carries the recovery code or pass?
  • Which lost passkey or key gets removed, and who confirms it is gone?
  • Who is told about the recovery, through a channel other than the one just used?

How recovery works in Microsoft 365

Microsoft's tool for this is the Temporary Access Pass, a time-limited passcode a person signs in with to register a new method, and Microsoft says it makes recovery easier when someone loses or forgets a strong authentication method. Because registering a passkey requires a recent multifactor sign-in, a person whose only method was on the lost phone needs a pass first. An Authentication Policy Administrator turns the pass on in the Authentication methods policies, under Temporary Access Pass, and chooses which users and groups may sign in with one. A pass can be created for anyone, but only people included in that policy can use it.

By default a pass lasts one hour, the policy's maximum lifetime is eight hours, and one-time use is off; an administrator can set lifetimes from 10 minutes to 30 days. To issue one, open Entra ID, then Users, select the person, and choose Authentication methods, then Add authentication method, then Temporary Access Pass. Note the code before you select OK, because Microsoft says it cannot be viewed again.

The person enters the pass on their Security info page, or signs in with it after adding their work account in Microsoft Authenticator, and registers a new passkey. With a one-time pass, registration has to be finished within 10 minutes of signing in. Microsoft says people who replace methods after losing a device should remove the old ones, and an administrator can delete a lost passkey from the person's Authentication methods list.

Microsoft's role list says Authentication Administrators can create passes for members, and Privileged Authentication Administrators can create them for administrators and members, in both cases except for themselves. Every administrator therefore needs a second person who can recover them. An expired pass also does not end sessions already opened with it; Microsoft points to the Conditional Access sign-in frequency setting to limit that.

How recovery works in Google Workspace

In the Google Admin console, open Directory, then Users, click the person's name, and click Security at the top. Under 2-Step Verification, Get backup verification codes gives a locked-out user a temporary way in, and Generate new codes invalidates the old set. Google says turning off 2-Step Verification for a locked-out user is possible but not recommended, and that only super administrators can generate backup codes for other administrators.

The same page lists passkeys and security keys under Passkeys & security keys, each with a Remove option. Google says to remove a security key only when it is lost, and to use backup codes as a temporary workaround when it is just unavailable. Passkeys that Android creates automatically when someone signs in are removed under Connected applications. Sign-in cookies, then Reset, signs the user out across all devices and browsers, though Google says current Gmail sessions can take up to an hour.

Check recovery details while you are there. The Recovery information section holds an email address outside your organization and a phone number. Google says each user's recovery phone number should be unique, and a number used by several users is automatically blocked for security reasons.

Run the recovery drill before you expand

Imagine a bookkeeper who normally signs in on a company laptop and replaces their phone while traveling. Can they get into the account on a device they are allowed to use? Who can verify their identity if they have to call for help? If the process relies on the same missing phone, the team has a gap to fix before the rollout. Test with an approved pilot account and record the steps, including how to remove the old credential.

Now imagine a ten-person accounting office on Microsoft 365. The owner and the office manager are the administrators, and two staff share a front-desk computer. The office opts in to passkey profiles and adds two: device-bound passkeys with attestation enforced for the administrators, who each register two security keys, and synced or device-bound passkeys for three pilot staff.

On drill day, a pilot bookkeeper whose passkey lives in Microsoft Authenticator pretends their phone was lost and replaced. The office manager, an Authentication Administrator who knows the bookkeeper by sight, verifies them on a video call, issues a one-time pass with a one-hour lifetime, and reads it out. The bookkeeper adds their work account in Microsoft Authenticator on the new phone, signs in with the pass, and registers a new passkey. The office manager then deletes the old passkey and tells the owner.

The second run finds the real gap. With both of the office manager's keys treated as unavailable, she cannot issue herself a pass, and because she holds an administrator role, the pass has to come from someone with higher privileges. The owner holds the Privileged Authentication Administrator role but has never issued a pass, and no one else in the office could issue one for the owner. The office writes the steps down, covers the owner in its emergency administrator access plan, and keeps the pilot small until the owner can repeat the steps without help. Only then does it expand to the front desk, where staff use their own phones or security keys.

Remove access when devices are lost or people leave

NIST notes that synced passkeys use keys specific to each service, which makes revoking access centrally difficult, unlike traditional certificates that can be revoked through a central list. Removal happens service by service. Once the passkey is deleted at the service, or the account is suspended, a copy left in a personal password manager no longer signs anyone in. Every service where staff registered passkeys belongs on the offboarding checklist, along with the Microsoft and Google removal steps described above.

What to check this week

  • List the accounts that would hurt most to lose and who administers each.
  • Confirm that each administrator can be recovered by someone other than themselves.
  • Check recovery phone numbers and email addresses for shared or outdated entries.
  • Decide which roles need device-bound passkeys, and register two security keys per administrator.
  • Write down the identity check required before anyone issues a recovery code or pass.
  • Run one drill with an approved pilot account, time it, and fix the instructions.
  • Review which older sign-in methods still work once passkeys are on.

Where ALCO can help

ALCO USA Inc is an IT services company headquartered in Caldwell, Idaho. Its services include Microsoft 365, Google Workspace, cybersecurity and compliance, mobile device management and user training. The account-security checklist on its Microsoft 365 page includes reviewing multifactor authentication and recovery methods, and planning and piloting any change so authorized staff keep a recovery route. The ALCO help desk is staffed 24 hours a day, including holidays, and calls are answered by a person.

Sources