Passwordless at Work: How IT Teams Should Prepare for Passkeys

If your organisation still relies on passwords plus occasional MFA, you face support tickets from locked accounts, phishing exposure, and the cost of password resets. Passkeys change the balance: they replace reusable passwords with cryptographic credentials stored on devices or in encrypted cloud vaults, which stops phishing that tricks users into surrendering credentials.

For IT teams, the practical questions are immediate: how do you onboard users so they accept the change, which applications should use device‑bound keys versus cloud‑synced keys, and how do you regain control when a device is lost or an employee leaves? The answers matter now because major platforms and standards bodies have moved passkeys from an experimental feature to a supported authentication option.

Passkeys are FIDO‑based credentials: a pair of cryptographic keys where the private key never leaves the user’s secure device or an encrypted cloud vault, and the public key is stored by the service. WebAuthn is the web standard that defines the browser‑side registration and authentication flows. These credentials are phishing‑resistant because a site can cryptographically verify a challenge only if the correct private key is used; malicious sites cannot reuse stolen secrets.

There are two common deployment patterns to understand. Device‑bound keys are generated and kept on a single device or external security key (for example a USB security key). They provide strong provenance — useful for privileged accounts. Synced passkeys store an encrypted copy in a platform vendor’s cloud vault so a user can sign in from multiple devices. Synced passkeys improve usability and recovery but introduce additional governance questions about the sync service.

Use the provenance of device‑bound keys for high‑risk roles; consider synced passkeys for general staff to lower support friction.

Standards and regulators have started to recognise synced models. A 2024 NIST supplement allowed syncable authenticators to meet elevated assurance levels when implemented with encrypted storage, strong recovery controls, and enterprise device management. That does not remove the need for policies — it simply means synced passkeys are technically viable in controlled environments.

For an IT programme this means the architecture choices are clear: decide which user groups, devices and applications require device‑bound keys; define which may use synced passkeys; and map those choices to identity provider (IdP) capabilities and device management tools.

If a table helps teams compare options, use one that lists key attributes (provenance, cross‑device use, recovery complexity); this keeps design conversations practical and avoids abstract debates.

Onboarding is the first user journey to get right. A staged approach works best: pilot a small, mixed group; measure registration success and support calls; then extend the deployment. Many organisations combine passkeys with single sign‑on (SSO) so that passkey registration happens as part of joining the corporate identity system. That reduces the number of per‑application keys and simplifies lifecycle controls.

Helpdesk workflows change but do not disappear. Lost devices or resigned employees still require account recovery and revocation. For synced passkeys, recovery often relies on the platform vendor’s account recovery flow, which uses the vendor’s multi‑factor processes. For device‑bound keys, helpdesk processes commonly include requiring the user to perform a secure re‑registration after identity verification. In either model, a consistent, documented escalation procedure reduces risky ad‑hoc fixes.

Practical tips for operations teams:

• Start with a two‑week pilot involving typical users and at least a few privileged users to test device‑bound workflows.
• Integrate passkey registration with IdP onboarding so accounts gain a verified passkey as part of provisioning.
• Train helpdesk staff on verification steps and provide scripted processes for re‑registration and temporary access, always logging actions for audit.

Platform vendors provide admin controls to help. For instance, major cloud identity providers allow Conditional Access policies and authentication method controls to require passkeys for certain apps while allowing password fallbacks for low‑risk services during transition.

Passkeys reduce phishing and shared‑password risks, but they surface other governance questions. The main operational tensions are recovery versus control, and convenience versus attestation of the authenticator.

Recovery is the largest practical challenge. If keys are synced, the organisation relies in part on the vendor’s recovery mechanisms; if keys are device‑bound, central teams must provide alternatives such as managed re‑enrolment. Either way, recovery should require an AAL2‑equivalent secondary verification — for example, a previously registered second factor plus a helpdesk confirmatory process — to avoid turning recovery into a new vulnerability.

Attestation is a technical signal that an authenticator meets a known hardware or software profile. Attestation helps prove a key came from a managed security key or a certified authenticator. However, enforcing attestation for all users can block synced passkeys and harm rollout velocity. A balanced approach is to require attestation for privileged accounts and allow less strict checks for general staff, documenting the choice in policy.

Revocation and incident handling deserve specific procedures. Unlike passwords, there is no universal ‘‘revoke everything’’ button for all relying parties; revoking access often means coordinating IdP‑level actions, disabling sessions, and triggering re‑registration for affected applications. Practice these steps in tabletop exercises so teams know who calls which vendor and what logs to consult.

Finally, compliance mapping matters. Regulators and internal audit will ask where private keys are stored, how recovery is protected, and what device controls exist. Map your passkey architecture to those questions early, using available standards guidance from NIST and FIDO Alliance as the common reference frame.

A realistic rollout plan avoids a single‑day switchover. Recommended phases are: discovery, pilot, controlled expansion, and broad adoption. Discovery lists applications, user groups, device types and SSO dependencies. Pilots validate device compatibility, helpdesk scripts and conditional access policies. Controlled expansion splits users into cohorts and tightens monitoring. Broad adoption relaxes fallbacks once confidence is high.

Tooling choices matter. Identity providers increasingly offer passkey configuration, attestation support and APIs for provisioning. Endpoint management (MDM) can enforce that enterprise passkeys are created only on managed devices. Look for IdP features such as authentication method policies and API support for bulk provisioning and reporting; these reduce manual work and lower error rates during ramp‑up.

Metrics to track during all phases should include registration success rate, sign‑in success rate, helpdesk ticket volume related to authentication, and time to recover an account. Vendors report large gains in user success and speed — for example, some providers report registration success near 99% and sign‑in times measured in seconds rather than minutes — but organisations should derive their own baseline.

Plan budget items: security keys for privileged staff, staff training, helpdesk hours for the pilot, and possible subscription costs for vendor sync services. Finally, document decisions about synced versus device‑bound keys, attestation requirements for different user tiers, and a stop‑gap when an IdP or platform feature is still in preview.

Passkeys make many of today’s authentication problems simpler: fewer phishing successes, fewer password resets, and a clearer cryptographic basis for identity. For IT teams the task is not just technical enablement but practical governance. Successful programmes separate user tiers, use attestation where assurance is needed, and provide clear recovery and helpdesk processes. A phased rollout, tied to IdP and device management capabilities, keeps risk controlled while delivering a noticeably better user experience.