How should organisations manage the lifecycle of credentials across smart cards, tokens, certificates, and FIDO2 factors?

Why This Matters for Security Teams

Smart cards, tokens, certificates, and FIDO2 factors all look like “credentials,” but they fail in different ways and at different points in their lifecycle. If issuance, binding, renewal, and revocation are handled in separate tools or by separate teams, organisations create blind spots that undermine MFA assurance, break offboarding, and leave dormant access behind. That is why lifecycle management is not an administrative detail, it is a core control surface.

The risk is especially visible when credentials outlive the identity state they were issued for. NHIMG’s 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, which is a strong indicator of how often revocation fails in practice. The same lifecycle problem shows up across certificates, hardware-backed factors, and recovery channels when no single system owns the full chain of custody. Current guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-63 Digital Identity Guidelines points toward continuous identity assurance, not one-time enrollment.

In practice, many security teams discover the lifecycle gap only after a departed user still has a valid factor, rather than through intentional revocation testing.

How It Works in Practice

A defensible lifecycle model starts with a single workflow that binds each credential to a verified identity, records its assurance level, and tracks its status from issuance to retirement. That workflow should cover smart cards, software or hardware tokens, client certificates, and FIDO2 authenticators under the same policy logic, even if the underlying cryptography differs. The goal is not uniformity of technology, but uniformity of control.

For most organisations, the practical sequence is:

• Issue credentials only after identity proofing, approval, and device or authenticator registration are complete.
• Bind each factor to a named user, role, device, or service account, and record who approved it.
• Set renewal and expiry rules that match risk, with shorter validity for higher-risk or higher-impact access.
• Revoke immediately on termination, role change, loss, suspected compromise, or failed attestation.
• Log every lifecycle event into IAM, PKI, and audit systems so security teams can prove what happened and when.

For certificate-heavy environments, PKI automation matters because manual renewal is one of the most common causes of unplanned outages and stale trust. For FIDO2, the lifecycle question is not just enrollment, but recovery: organisations need strong identity re-verification before issuing replacement authenticators. NHIMG’s Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide both reinforce the same operational point: lifecycle control only works when issuance and revocation are tied to a live inventory, not a spreadsheet. The same principle is echoed in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects formal control over account and credential management.

These controls tend to break down when renewal is delegated to local administrators in distributed business units because revocation and attestation drift out of sync with central identity records.

Common Variations and Edge Cases

Tighter credential control often increases operational overhead, requiring organisations to balance stronger assurance against user recovery time, support load, and outage risk. That tradeoff is especially visible in hybrid environments where smart cards remain on-premises, certificates are issued by one platform, and FIDO2 is managed through a separate identity provider.

There is no universal standard for how every factor type must be unified, so current guidance suggests prioritising a common policy model rather than forcing a single technical implementation. Some environments will keep PKI renewal separate from FIDO2 management, but they should still share a common inventory, expiry policy, and revocation trigger. In high-assurance use cases, a lost smart card may require immediate deprovisioning and reissuance, while a FIDO2 recovery event may require step-up verification and a temporary access hold.

One practical edge case is shared or emergency access. Organisations often keep break-glass credentials or backup authenticators, but those exceptions need shorter TTLs, stronger monitoring, and explicit post-use review. Another is contractor access, where credential lifecycles should usually be shorter than employee lifecycles and tied to contract end dates. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because the same sprawl dynamics that affect secrets also affect physical and cryptographic factors when ownership is unclear.

For implementation, the right baseline is to treat every factor as an inventory item with an owner, expiry, and revocation path, then test those paths regularly.

Related resources from NHI Mgmt Group

• How should organisations manage signing certificates across employee lifecycle changes?
• How can organisations reduce the risk of stale API keys and machine tokens?
• How should organisations manage the lifecycle of agent-issued credentials after registration?
• How should organisations manage identity security across the lifecycle?