Passkeys split into workforce and customer identity programmes

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Secfense's blog post: Passkeys are one standard, but workforce and customer deployments diverge on device control, recovery, fraud risk, compliance and rollout.

Why it matters: IAM and identity security teams need different operating models for workforce and CIAM passkey programmes because device trust, recovery and assurance requirements do not line up.

Context

Passkeys reduce password dependence by replacing shared secrets with public-key authentication, but the governance problem is not the cryptography itself. The harder question is who controls the device, who can recover access, and what assurance the organisation can actually enforce across different user populations.

Workforce and customer authentication are both identity programmes, but they are not the same operating environment. Employees usually sit inside managed-device and IT-support boundaries, while customer identity often has to work across personal devices, variable sessions and weaker operational control.

Key questions

Q: How do passkeys work in workforce identity systems?

A: Passkeys replace passwords with public-key authentication, so the user proves possession of a registered authenticator instead of typing a shared secret. In workforce identity, organisations can usually enforce managed-device rules, policy-based authenticator selection, and stronger recovery controls, which makes passkey deployment more predictable than in consumer environments.

Q: Why is passkey recovery harder in customer identity than in workforce identity?

A: Passkey recovery is harder in customer identity because there is no managed device estate, help desk, or enforced joiner-mover-leaver process to rebind credentials after loss. Recovery usually depends on account recovery proofs, verified devices, or re-authentication through a trusted user device, and weak recovery flows become the main takeover path.

Q: What is the difference between device-bound and synced passkeys?

A: Device-bound passkeys stay on one physical device and are harder to export or replay elsewhere, while synced passkeys move through cloud services across multiple devices. The difference matters because synced credentials expand the trust boundary to account recovery and sync infrastructure, which makes them harder to govern in enterprise access models.

Q: What should auditors look for in passkey deployments?

A: Auditors should check whether passkeys are bound to phishing-resistant authentication, whether enrolment and recovery are tightly controlled, and whether logs are centralised for enrolment, reset, and step-up events. They should also verify device binding, fallback methods, and administrator override paths, because weak recovery or shared credentials can defeat the passkey control.

Technical breakdown

Device ownership changes passkey assurance

Passkey assurance depends on the authenticator, the device, and the enrollment policy. In workforce environments, the organisation can often require managed devices, hardware security keys, or attestation-backed controls. In CIAM, that assumption breaks because the organisation cannot dictate what device a customer uses or how often it changes. Synced passkeys become operationally necessary when users move across phones, browsers, and ecosystems, but that changes the trust model from device possession alone to a broader account recovery and ecosystem trust model. See the Passwordless and Passkeys Guide.

Practical implication: Separate device policy for workforce and customer journeys, because the same passkey standard does not justify the same enforcement model.

Recovery is the real control plane

Passkey recovery is the process that restores access when a user loses the authenticator or cannot complete sign-in. In workforce settings, recovery can be centrally administered, logged, and tied to internal support processes. In CIAM, recovery must balance speed, fraud resistance, and usability at consumer scale. That makes the recovery path part of the authentication attack surface, because social engineering and account recovery abuse often target the weakest restoration step rather than the passkey itself. See the Authentication Guide.

Practical implication: Design recovery as a security control, not a support afterthought, especially where external users can self-serve account restoration.

Regulated deployment requires audit-ready authentication

Passkey programmes in regulated environments must produce evidence, not just better sign-in. Device binding, enrollment policy, recovery decisions, and authentication logs all become part of the audit story. For workforce identity, that often lands in internal governance and access assurance. For CIAM, the same controls may also intersect with consumer protection or financial-sector obligations, which means the architecture has to support traceability before rollout starts rather than after adoption problems appear. See the Workforce Identity Security Guide.

Practical implication: Build logging, policy definition, and recovery traceability into the architecture before the rollout begins.

NHI Mgmt Group analysis

Passkeys are one standard, but identity governance is still context-specific. The cryptographic primitive is shared, yet the control environment is not. Workforce identity assumes managed devices, central administration, and structured support, while customer identity has to absorb device variability, self-service recovery, and higher fraud pressure. Practitioners should treat the standard as common infrastructure, not as a single deployment model.

Recovery design is the decisive risk boundary in customer passkey programmes. When the user base sits outside IT control, the restoration flow becomes the most abuse-prone part of the programme. A passkey can be strong while the fallback process remains weak, which means account takeover risk shifts from the authenticator to the recovery path. The control that fails is not passkey cryptography, but recovery governance.

Device control is the hidden divider between workforce and CIAM assurance. Managed endpoints let organisations constrain authenticators, issuance, and attestation. Consumer devices do not, so the trust model has to accommodate roaming authenticators, changing hardware, and weaker visibility into endpoint posture. That is why device policy is an identity design choice, not a technical preference.

Compliance turns passkeys into an evidentiary problem, not just an authentication problem. DORA, NIS2 and PSD2 push teams to show how authentication assurance, device binding and auditability are implemented. Those obligations differ in how they land across workforce and customer identity, so the governance question is which programme needs which proof, and when. Practitioners should separate architectural decisions from compliance reporting assumptions.

Synced passkeys represent an operational compromise, not a failure of the standard. In customer identity, synced credentials are often the only workable scale pattern, but they move the trust boundary to the user ecosystem rather than a single managed device. That creates a different assurance profile from hardware-bound workforce deployments. The implication is that identity architecture must follow the user context, not the other way around.

From our research library:

• eBay's passkey data shows 55-60% of passkey adoption happens on mobile, against around 20% on desktop.

What this signals

Passkey governance splits along the same line as identity ownership. Workforce programmes can rely on managed devices, controlled recovery and enforced rollout, while CIAM programmes have to tolerate user-owned hardware, self-service restoration and variable adoption. Teams that try to run both with one control model usually discover that one side dictates compromises for the other.

Recovery flow is the control most likely to move from support function to security decision point. As soon as external users are involved, the restoration path becomes a place where fraud, usability and assurance collide. Identity teams should expect recovery design to receive the same architectural attention as enrollment, because that is where the weakest assumptions usually live.

For practitioners

• Define separate passkey operating models Map workforce and customer identity to different authentication policies, recovery paths, and rollout criteria instead of treating them as one programme.
• Treat recovery as a primary control Document who can restore access, what verification is required, and which fallback methods remain available when the authenticator is lost.
• Set device policy before enrollment Decide whether the default model is managed-device binding, synced passkeys, or a mixed approach, then align authenticator policy to that choice.
• Build audit evidence into rollout Centralise logs for enrollment, recovery, and enforcement decisions so auditors can trace how the programme operated across user populations.

Key takeaways

• Passkeys do not remove identity-design trade-offs, because workforce and customer programmes face different device, recovery and assurance conditions.
• The strongest operational boundary is recovery, where secure restoration can be harder to engineer than initial enrollment.
• Identity teams need separate policies for workforce and CIAM passkey deployments if they want predictable governance and auditability.

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Authentication Guide · Workforce Identity Security Guide

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• FIDO2: FIDO2 is a passwordless authentication standard that uses public-key cryptography instead of shared secrets. A service stores the public key while the authenticator keeps the private key, allowing users to prove possession without sending reusable credentials over the network.
• Customer Identity And Access Management: Customer Identity and Access Management is the discipline of governing how external users sign in, recover access, and move through digital services. It combines authentication, profile management, and lifecycle control so organisations can deliver secure, low-friction experiences at scale.
• Device binding: A control that links an authenticator or key pair to a specific endpoint so the same secret cannot be copied and reused elsewhere. It strengthens assurance, but the binding step itself becomes a high-value target if attackers can intercept the enrollment process.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.