Choose the company account on a laptop, approve the sign-in on your device and continue working: a passkey can make daily work simpler. For businesses, this also needs a plan for permitted devices, replacements and recovery.
What actually happens when you sign in
A passkey is a sign-in credential based on FIDO standards and a cryptographic key pair. The service knows the public key. The authenticator uses the matching private key, for example on a smartphone, computer or security key. During sign-in, it answers a challenge from the service with a digital signature. This does not require a sign-in password shared with the website.
WebAuthn is the standard interface for this sign-in on the web; FIDO2 encompasses the underlying mechanisms. For employees, the visible process matters most: check the account and destination, then approve with the device PIN or an appropriate biometric check. The available choices depend on the service, operating system, browser and passkey provider.
Why this differs from a password plus a one-time code
A password and a manually entered SMS or app code can be requested on a fake sign-in page and forwarded. WebAuthn binds the credential to the intended service. This makes passkey sign-ins phishing-resistant. It does not automatically secure an infected device, a stolen session or a weak recovery route.
Local device approval is not a second website password. Whether a sign-in meets the required multifactor or authentication strength is assessed against the actual method and policy. Pressing an arbitrary button on just any key is not an adequate description. Sources: FIDO Alliance: passkeys explained (external link).
Device-bound or synced: the crucial difference
Device-bound passkeys remain on the specific authenticator. This might be a suitably supported phone or a FIDO2 security key. A new key or replacement phone does not have that credential merely because it belongs to the same person. Another permitted authenticator must be registered, or a prepared recovery process used.
Synced passkeys can reach other authorised devices belonging to the same person through a passkey provider. Its account, protection and recovery therefore matter. Supported devices and transfer routes depend on the provider. This does not imply arbitrary export between all platforms or automatic inclusion in company management.
| Variant | What happens when changing devices? | Clarify before operational use |
|---|---|---|
| Device-bound passkey | Register a new authenticator or use the designated recovery route. | Prepare replacement and responsibility independently. |
| Synced passkey | Available on a supported device through the appropriate provider; its recovery route matters. | Define the permitted provider account, devices and account protection. |
| Cross-device sign-in | Use an existing authenticator on another device; this is not the same as copying it. | Test the supported combination and a secure session on the destination device. |
A phone can sign you in without copying the passkey
A hypothetical workflow: an employee opens an approved company portal on a meeting-room laptop. Her permitted smartphone approves the sign-in. A supported cross-device method uses the authenticator on the phone. This differs from synchronisation or permanent registration on the laptop.
Such flows may require a proximity check and additional technical prerequisites. They are tested with the devices and browsers actually in use. On a shared computer, the correct account, suitable session duration and signing out afterwards also matter. Having the phone nearby does not replace these organisational steps.
Keep personal and managed devices distinct
If company access is synced only through a personal platform account, business recovery may depend on an individual’s private account. Decide in advance which providers, devices and passkey types are allowed for each user group. A managed device helps enforce certain requirements, but management does not automatically let administrators read every private key.
According to the documentation checked, Microsoft Entra ID supports both synced and device-bound passkeys and can apply requirements to groups through passkey profiles. This does not approve every combination: registration, existing permissions, device support and policies must fit together. Sources: Microsoft: passkeys and profiles in Entra ID (external link).
Plan replacement and leaving the company before broad rollout
A pilot includes not only successful sign-in but also a lost phone, a failed security key and a locked provider account. Depending on protection needs, prepare an independently registered replacement authenticator or a controlled recovery route. A device change is a poor time to start looking for the responsible person and necessary evidence.
When someone leaves, company access is blocked at the identity service or destination system and registered methods are revoked appropriately. A copy in a personal sync account does not necessarily disappear from the personal device; what matters is that company access no longer accepts it. Existing sessions and other sign-in routes are addressed separately. This does not imply blanket remote wiping of personal devices.
What happens to fingerprints and facial data
During WebAuthn sign-in, the service receives no biometric characteristics such as a fingerprint or facial template. Verification happens locally at the authenticator; the service receives cryptographic proof and the specified verification information. The device PIN is not sent as a website password either. Exact processing on the device and by the passkey provider still belongs in device and provider selection.
Sources: W3C: local biometric verification with WebAuthn (external link). This does not mean that a participating cloud provider processes no account data or metadata whatsoever.
Start with a manageable pilot
DAXS helps select suitable services and devices, agree roles and a recovery route, and run a pilot with documented results. Checks cover normal sign-in, replacement, shared workstations and leaving the company. Only then is a decision made on which methods to deploy broadly.
Discuss passkey adoption · Plan workplaces and identities · Manage shared company access in an orderly way
Frequently asked questions
Can I simply copy a device-bound passkey to a new phone?
That is precisely what device-bound passkeys are not intended to allow. Synced passkeys can become available on supported devices using the appropriate provider account. The actual replacement route is tested in advance.
Does everyone have to use their personal smartphone?
That is defined in the business operating concept. Depending on service and requirements, managed devices, suitable security keys or other supported authenticators may be used.
Does a passkey replace all permissions in the company?
It proves sign-in to an account. Which applications and data that account may use remains a separate task of user and permission management.
