Organisations should treat FIDO2 lifecycle management as an identity governance process, not a one-time enrollment task. Batch issuance, policy assignment, PIN controls, passkey provisioning, and secure reset should be managed together so devices can be issued, reused, and retired without creating unmanaged credentials. Recording every lifecycle action also helps preserve auditability and reduces the chance that device cleanup becomes a security gap.
Managing FIDO2 Devices as a Lifecycle, Not a Login Event
FIDO2 devices and passkeys become risky when organisations treat them as a one-time registration step instead of a governed lifecycle. The real work is managing issuance, assignment, replacement, reuse, and retirement so authentication material does not linger after a device changes hands or a user changes role. That requires ownership, status tracking, and recovery paths that are designed before scale creates exceptions.
At volume, the security problem is not whether FIDO2 is strong. It is whether every enrolled authenticator still belongs to the right person, under the right policy, with the right recovery constraints. Organisations that do this well align lifecycle handling with identity governance, not helpdesk convenience, and they make every state change visible enough to audit later. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because the same lifecycle discipline that applies to machine identities also applies to passkeys once they are deployed at enterprise scale.
In practice, many security teams only discover lifecycle gaps when a lost device, delayed offboarding, or unmanaged recovery flow has already become a support and access issue.
What Scalable FIDO2 Operations Need to Control
Scalable management depends on controlling the whole lifecycle as a set of linked state transitions. Issuance should be tied to verified identity proofing and policy assignment. Reuse should be constrained by whether a device is reassigned, repurposed, or replaced. Reset and revocation should be explicit actions, not informal helpdesk workarounds. If a recovered passkey can still satisfy authentication after the underlying trust relationship has changed, the lifecycle is not complete.
For large organisations, the practical design choice is to centralise registration records, device status, and recovery authority so the security team can answer three questions quickly: who owns the passkey, which policy governs it, and whether it can still authenticate. That means binding the passkey to an identity record, logging administrative actions, and ensuring secure recovery does not become a universal bypass. Guidance from the OWASP Non-Human Identity Top 10 is relevant because unmanaged credentials, whether human or machine-adjacent, fail for the same reasons: weak inventory, weak rotation discipline, and weak offboarding.
- Issue devices only through a controlled enrollment flow that records owner, policy, and assurance level.
- Track whether the authenticator is active, suspended, replaced, or retired.
- Make secure reset and rebind steps auditable and approval-based for high-risk accounts.
- Ensure lost, stolen, or decommissioned devices are removed from the authentication set promptly.
Lifecycle control also has a recovery dimension. If users can self-service too much, attackers can abuse recovery paths; if recovery is too rigid, support teams create shadow processes that bypass policy. These controls tend to break down when organisations run mixed device populations, allow unmanaged personal devices, or lack a single authoritative source for authenticator state.
Where Lifecycle Management Breaks Down at Scale
Tighter authenticator governance often increases operational overhead, so organisations have to balance strong control against onboarding speed and support friction. The main edge case is not the standard user with one registered passkey. It is the user who has multiple devices, multiple recovery methods, or cross-environment access that is not obvious from the front-end login flow.
Best practice is still evolving for how much local user autonomy should be allowed in passkey replacement and recovery. In some environments, especially regulated or high-risk ones, the safer choice is to require stronger verification before adding or re-enrolling a device. In lower-risk settings, a more flexible process may be acceptable, but only if it preserves traceability and rapid revocation. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a helpful reminder that auditability matters as much as technical strength when lifecycle actions affect access rights.
Organisations also need to plan for shared endpoints, contractors, and rapid employee turnover. Passkeys are strong, but they do not solve ownership ambiguity, and they do not make an abandoned device safe by default. Where device reassignment, recovery exceptions, or offboarding are handled inconsistently, the lifecycle becomes the weak point rather than the authenticator itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Lifecycle and Ownership | Passkey lifecycle depends on inventory, ownership, and offboarding discipline. |
| NHI-05 — Rotation and Revocation | Device replacement and secure reset require timely revocation of stale credentials. | |
| NHI-07 — Visibility and Auditability | Lifecycle actions must be logged so authenticator state remains auditable. | |
| Recommendation — Track each registered authenticator and revoke it promptly when ownership changes. Rotate or revoke stale authenticators before re-enrollment creates duplicate trust. Log enrollment, reset, reassignment, and retirement events for every FIDO2 device. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Proofing, Authentication, and Credential Management | FIDO2 lifecycle sits within identity proofing, authentication, and credential governance. |
| PR.AC-1 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | The question centers on managing credentials through their full lifecycle at scale. | |
| Recommendation — Bind passkey issuance and recovery to verified identity and approved credential policy. Manage passkeys through issuance, verification, revocation, and audit as one process. | ||
| CIS Controls v8 | 6 — Access Control Management | Lifecycle management must ensure stale authenticators cannot retain access. |
| Recommendation — Remove access immediately when a device is lost, retired, or reassigned. | ||
Practitioner Guidance
What to prioritise: Build a single authoritative inventory of enrolled FIDO2 devices, linked to user status, policy state, and recovery method. If the organisation cannot answer who can still authenticate after a role change or device replacement, lifecycle governance is already incomplete.
What to verify: Confirm that reset, replacement, and revocation are separate actions with different approvals and logs. The control is not trustworthy if helpdesk staff can silently rebind a passkey without preserving evidence of why the change was made.
Decision rule: If an authenticator is associated with an account that has changed owner, lost assurance, or crossed into a higher-risk role, treat it as a re-enrolment case rather than a simple device replacement.
Practitioner takeaway: Scalable passkey management is won or lost on lifecycle discipline, not on the strength of the cryptography, so the critical control is proving that every authenticator still belongs to the right identity and can be removed just as easily as it was added.
Related resources from NHI Mgmt Group
- What breaks when organisations manage PKI certificates and FIDO2 passkeys in separate workflows?
- How should organisations manage the lifecycle of credentials across smart cards, tokens, certificates, and FIDO2 factors?
- How should MSPs manage passkeys at scale across mixed devices and users?
- How should organisations manage dormant IAM accounts before they become a security and cost problem?
