Token Lifecycle Governance
Pillar 14 of 25 · 5 min read · How most organisations lose control between provisioning and decommissioning — and the policy architecture that closes the gap.
See how this applies to your environment
Book a 30-minute briefing with Ciptor. We'll walk through what live-fire validation typically uncovers in environments like yours.
The Assumption
"We issued hardware tokens to all privileged users. Our authentication is covered."
The Reality
Issuing tokens is the easiest part. The risk accumulates in the gaps: the key that wasn't revoked when someone changed role, the token handed back at offboarding but never deregistered, the spare unit sitting in a desk drawer that was never enrolled in the asset register. In most organisations, the token you can't account for is the one that gets exploited.
Token lifecycle governance is the discipline that closes these gaps. It is not a product — it is a policy architecture, supported by the right hardware properties and enforced by operational processes. This volume walks through the three phases where control breaks down and the specific controls that restore it.
The Three Phases
Where Lifecycle Control Breaks Down
Every hardware token passes through three phases. The governance failures in each phase are distinct — and each requires a different class of control.
Where It Fails
The Four Most Common Lifecycle Failures
The Blueprint
Token lifecycle governance requires five specific controls, each mapped to a phase and each generating the audit evidence your NIS2 compliance posture requires. These are not theoretical — they are operational requirements that can be implemented today with your existing identity infrastructure.
Policy Architecture
Five Controls That Close the Lifecycle Gap
Hardware Properties That Support Lifecycle Governance
Not all hardware tokens are equally governable. The physical and cryptographic architecture of a key determines how well it supports lifecycle controls. Both keys Ciptor distributes are architected specifically for the kind of governance described above — and their certifications make that architecture independently verifiable.
Feitian BioPass K49
On-device fingerprint matching inside a CC EAL6+ secure element. Private keys are generated on-device and never exported — the credential binding is permanently tied to the physical token. When the token is returned and decommissioned, the credential is physically unrecoverable from that device.
NeoWave Winkeo-C FIDO2
Manufactured in France with complete European supply chain transparency. The ANSSI Visa de Sécurité provides independent confirmation of the key's cryptographic architecture — the same kind of third-party attestation your auditors will want to see in a NIS2 review. CC EAL6+ chip-level tamper resistance ensures that physical recovery of credentials from a returned token is not possible.
Regulatory Mapping
NIS2 Article 21(2)(i): What Token Lifecycle Governance Needs to Demonstrate
NIS2 Article 21(2)(i) requires essential and important entities to implement policies and procedures on access control and asset management. In the context of hardware authentication, a regulator or auditor reviewing your NIS2 posture will typically ask for evidence across four dimensions:
- An authoritative register of all authentication assets, including physical tokens, with assignment history
- Documentation of the access rights each token provides, reviewed against current role assignments
- A demonstrable process for timely credential revocation on offboarding or role change
- Periodic attestation confirming the register is accurate and complete — not just a policy that says it should be
Audit Evidence
What a Hardware Token Lifecycle Programme Produces for NIS2 Review
A well-governed lifecycle programme generates its own audit evidence: the asset register provides the asset inventory; credential provisioning logs provide the access-grant documentation; the decommissioning SLA log provides the timely-revocation evidence; the annual attestation provides the periodic review evidence. The five controls above map directly to what an auditor will request. Implement them, and the evidence is a by-product of normal operations — not something assembled under pressure before an audit.
Token lifecycle governance is not glamorous. It does not appear in threat intelligence reports. It does not generate conference talks. It is the unglamorous operational discipline that determines whether the hardware security investment your organisation made is actually producing security — or just producing a sense of security.
The tokens you cannot account for are the ones that will appear in your post-incident report. The lifecycle programme that exists only as a policy document will not survive an NIS2 audit. Both problems have the same solution: operational controls, enforced systematically, generating evidence continuously.
Vol. 15 closes Pillar 3 with Physical Access Convergence — the security architecture for organisations moving toward unified logical and physical access using the same hardware token.
