Designing Secure Credential Lifecycle Management
Credential systems are usually designed around issuance. They fail in production around everything else — rotation, recovery, revocation, attestation drift. This post is the operations-grade view: what every state in a credential’s life is, what has to happen in each, and where real deployments get hurt.
Most credential programmes are written down as "we issue keys; users log in with them". The hardware vendor talks about cards and keys; the IdP vendor talks about WebAuthn and OIDC; nobody talks about the day an employee’s card goes through the washing machine. This post is for the people who own the day after.
The states a credential lives in
A useful mental model: a hardware credential moves through eight states.
- Unbound stock. Cards / keys sit in a personalisation queue. Not yet tied to any user.
- Personalised, unenrolled. Hardware has been written with cryptographic material under issuer keys, but no user account is associated.
- Enrolled. Credential is bound to a user, registered with one or more relying parties.
- Active. User authenticates with it day to day.
- Suspended. Temporarily disabled (user on leave, suspected compromise under investigation).
- Rotated-out. Replaced by a new credential as part of policy or expiry rotation; old credential not yet purged.
- Revoked. Permanently rejected by all relying parties.
- Destroyed. Physically returned and disposed of (or hardware retired, key escrow zeroised).
An end-to-end credential programme has to handle every transition. The easy ones are 1?2?3?4. The hard ones are 4?5, 5?4 (reactivation), 4?6 (rotation), and 4?7 (revocation).
Issuance
Issuance is the state where most programmes feel like they’ve done the work. They usually haven’t — they’ve done about 30% of the work, but 100% of the visible work.
What good issuance looks like
- Identity verification before binding. The operator does not bind a credential to a user account based on the user’s say-so. There is an HR-record check, a photo-ID check, or both.
- Hardware-bound on-card key generation. The private key is generated on the secure element. It does not exist in any operator’s memory at any point in the flow.
- Attestation captured. The credential’s attestation is logged at issuance, not just at enrolment. You want to know later "what AAGUID, what serial, signed by what attestation root".
- Issuance audit log. Operator identity, timestamp, batch number, user account, credential serial. Append-only.
Common issuance failures
- Credentials issued in transit. A card mailed to a remote worker with a "set your PIN on first use" sticky note. The credential lives outside the trust boundary in transit; if intercepted, the attacker can claim the user’s identity at first activation.
- Operator screens too privileged. A helpdesk-side console that can register any credential against any account. This is a privileged-access nightmare; even if the operator is well-meaning, their workstation is a high-value target.
- No batch identifier on issuance log. When a manufacturing lot turns out to be problematic later, you cannot identify which user credentials came from that lot.
Rotation
Every credential has a finite life. The question is whether your system rotates them deliberately or accidentally.
Why rotate
- Algorithm migration. Eight years from now the algorithm in today’s credential may not meet your security policy. Rotation is how you migrate the population without retrieving devices.
- Personnel change. A user has a new role, new permissions, new applets on the same physical card. Rotation re-personalises without re-issuing the plastic.
- Suspected compromise. A single credential is suspected compromised; rotate-and-revoke the single credential without disrupting the rest of the population.
- Policy expiry. Many policy regimes require a maximum credential age (commonly 3-5 years). Rotation enforces it.
Rotation patterns that work
- In-place rotation. User goes to the IT desk; a new credential is generated on the existing hardware (smart card or FIDO key) and registered alongside the old; old credential revoked once new credential is verified.
- Replacement rotation. New hardware issued, new credential bound, old credential revoked when the user returns the old hardware.
- Backend-driven rotation (EST). Common for IoT. Device runs an EST re-enrolment flow over its normal connectivity; new key generated in secure element; new certificate signed; old credential phased out by validity-date overlap.
Rotation anti-patterns
- Hot-swap with no overlap window. Revoking the old credential the moment the new one is issued, before the user has logged in once with the new one. If anything goes wrong in the issuance, the user has no working credential.
- Manual rotation only. If the system cannot rotate the entire population without operator-per-user effort, the rotation will not happen until a crisis forces it.
- Rotation that depends on user action. "Users will re-enrol within 90 days". They won’t.
Recovery
The hardest credential-lifecycle problem. Users will lose hardware. They will also forget PINs. The system has to keep working in both cases without becoming a phishing surface itself.
Recovery design principles
- Recovery is not a feature, it is a process. Code does not solve it; runbooks do.
- Recovery has to be at least as strong as initial issuance. If issuance requires in-person identity check, recovery does too. Otherwise recovery becomes the phishing target.
- Recovery should not fall back to a password. A passwordless deployment that recovers to a password has reintroduced the credential it spent millions to remove.
- Recovery should be measured. Track time-to-recover. If it’s above your SLA, your helpdesk is wrong, not your architecture.
Recovery patterns that work
- Backup credential. Every user (or every privileged user) gets a sealed backup hardware credential at issuance time. The backup is enrolled at the same time. Recovery is "user goes to IT desk, breaks seal, logs in with backup, gets a new primary".
- Time-bound break-glass code. A short-lived recovery code, generated under M-of-N operator approval, lets the user authenticate once for 24-48 hours so they can present at the IT desk for full re-issuance.
- In-person recovery only. The user has to show up. The trade-off (time) is accepted because the security posture (no remote recovery) is the whole point.
Recovery anti-patterns
- Email-based recovery. Email is not a strong factor; building credential recovery on top of it is building the credential’s security around the email account’s security.
- SMS-based recovery. SIM-swap is a known and active threat. Recovery via SMS is recovery to an SMS-equipped attacker.
- Helpdesk-can-fix-anything recovery. If a single helpdesk operator can restore a privileged credential, the helpdesk operator is the credential.
Revocation
Revocation is the cleanup state. It is also the state that decides whether a leaver scenario produces a clean cut-off or a long tail of access.
Where revocation actually has to happen
A FIDO2 / WebAuthn credential is registered with each relying party independently. Revoking a credential means visiting every relying party. In practice this is one of three patterns:
- Federated revocation. The IdP (Okta, Entra ID, etc.) owns the credential record; revoking at the IdP propagates to every downstream SP via SSO session-revocation. This is the cleanest.
- Per-RP revocation. Each RP holds its own credential record; revocation has to be repeated per RP. Inefficient but sometimes unavoidable.
- Validation-server-driven revocation. A central FIDO Validation Server is the RP for every internal application; revocation happens once, applies everywhere.
Revocation pitfalls
- Local credential caches. Some platform authenticators cache credentials locally and don’t re-check the RP before reuse. Revocation doesn’t propagate until the cache expires.
- Long-lived backend sessions. Revoking the credential doesn’t kill an existing SSO session. Make sure your IdP also revokes the session, not just the credential.
- Forgotten relying parties. A credential registered six months ago with a niche internal tool that has since been forgotten. Audit your RP inventory.
Destruction
Final state. Hardware returns, secure element is zeroised or physically destroyed, audit log is updated. For most enterprises this is a small detail; for regulated environments (national ID, financial sector) it’s a controlled disposal process subject to audit.
Attestation drift over time
One subtle lifecycle issue: the credential class you allow at registration in 2026 may not match the certified hardware list in 2030. Attestation policy must be allowed to evolve without breaking existing credentials.
Patterns:
- Pin AAGUIDs at registration, not on every authentication. Re-checking AAGUID against a current allow-list on every login means a policy change can lock out the population.
- Maintain a "grandfathered" list. Credentials registered under an old policy keep working until rotated; new registrations follow the new policy.
- Plan a rotation cadence that beats your policy expiry. If your policy might require a credential class change every 5 years, your rotation cadence should be 3-4 years.
Audit and forensics
Three logs that every credential programme should keep, append-only and unforgeable:
- Issuance log. Operator, timestamp, user account, credential serial, AAGUID, attestation hash, batch ID.
- Authentication log. Credential serial, timestamp, relying party, success/fail, origin. Useful for forensics after a credential is suspected compromised.
- Revocation log. Operator, timestamp, credential serial, reason (lost / leaver / rotated / suspected compromise), full propagation status across relying parties.
If you can’t answer "when was this credential issued and to whom" in under a minute, you don’t have an audit log; you have a database.
Operational numbers we’ve seen in practice
From real deployments (numbers approximate, anonymised):
- Issuance time per user, in-person: 4-7 minutes at a well-trained IT desk. Slower in the first month.
- Recovery time per user, in-person backup-credential model: 8-15 minutes including identity re-verification.
- Loss / damage rate per year, smart card with badge artwork: 4-7% annual replacement.
- Loss / damage rate per year, FIDO USB key: 8-12% annual replacement (smaller form factor, easier to lose).
- Helpdesk ticket rate per user per year, first year: 0.3-0.5. Second year and after: 0.1-0.2.
None of this is invented; it’s the order of magnitude. Plan for it.
Putting it together: programme design
A defensible credential programme answers, in writing, before issuance starts:
- What are the credential classes, and what account class does each map to?
- Who can issue a credential? Under what verification?
- Where does the private key get generated? Where does it ever exist outside the secure element? (Answer should be: nowhere.)
- What is the rotation cadence, and how is it triggered?
- What is the recovery flow, including the privileged-account variant?
- Where does revocation propagate, and how is propagation verified?
- What is the audit log, and who reviews it?
- How is the attestation policy evolved over time?
If you can’t answer those eight questions, you’re not running a credential programme; you’re running a procurement event.