Treat them as one credential estate with different control requirements, not as separate administration problems. Define ownership, issuance, recovery, revocation and audit responsibility for each credential type, then make sure offboarding and exception handling work across all three. If the lifecycle is split, identity assurance becomes inconsistent even when each individual tool is configured correctly.
How to govern PKI, FIDO2, and physical access credentials as one estate
Governing these credentials together starts with a shared control model. PKI certificates, FIDO2 authenticators, and physical badges all prove trust, so the question is not whether they differ technically, but whether they are owned, issued, recovered, revoked, and audited with the same discipline. Separate tool teams can still fail if lifecycle ownership and exception handling are fragmented.
A useful way to structure the estate is by control objective rather than by technology. PKI covers cryptographic trust, FIDO2 covers phishing-resistant authentication, and physical credentials cover facility and workstation access, but all three create access authority that must be attributable, time-bound, and removable. Treating them as one estate makes it easier to align policy, inventory, and offboarding across the full trust chain.
The strongest governance pattern is to define one authoritative inventory with fields that matter across all three types: owner, subject, issuer, issue date, expiry or renewal date, recovery path, revocation path, and exception owner. That inventory becomes the bridge between identity governance, security operations, facilities, and help desk processes. Without that shared view, a revoked account can still retain valid building access, a lost security key can remain trusted, or a certificate can stay active after a role change.
What has to be controlled differently across PKI, FIDO2, and physical access
Each credential type has different failure modes, so “one estate” does not mean “one control set.” PKI needs certificate lifecycle discipline, private key protection, and CA governance. FIDO2 needs strong registration, device binding, recovery controls, and reset resistance. Physical credentials need issuance control, badge deactivation, and protection against tailgating or shared use. The common model is governance, while the control implementation remains credential-specific.
Revocation is the clearest example. A certificate can be revoked through CA processes, a FIDO2 key may need re-registration or recovery workflows, and a physical badge must be disabled in the access control system. If those paths are not coordinated, an offboarded person may lose one form of access but still retain another. That is why the estate should define revocation service levels and maximum allowed delay for each credential type.
Recovery deserves equal attention because it is often the weakest point in the chain. Help desk resets, badge re-issuance, and key replacement are common abuse targets, especially when a recovery process relies on weak identity proofing or informal exceptions. Workforce Identity Security Guide is useful here because the same reset and recovery controls that protect employee sign-in also shape how organizations keep fallback paths from undermining the estate.
Physical access should also be treated as part of the same assurance model, not as a separate facilities-only topic. If an employee can still enter a site after account disablement, the organization has retained a privileged access path that may not show up in standard IT reviews. Conversely, strong door controls do not compensate for weak digital revocation if the person can still use certificates or phishing-resistant sign-in to reach systems remotely.
Where governance usually breaks and what practitioners should verify
Most failures come from ownership gaps, not from weak cryptography or a bad authenticator. PKI is often run by infrastructure teams, FIDO2 by IAM, and badges by facilities, with no shared decision on who owns exception approval, lifecycle evidence, or emergency recovery. That split creates inconsistent assurance, especially when audit teams ask for a single answer to “who can still get in?”
Practitioners should verify three things before they trust the model: first, that every credential type maps to a named business owner; second, that offboarding triggers all relevant revocation actions; and third, that exceptions expire and are reviewed. If any one of those is missing, the estate is governed by tool behavior rather than by policy.
For certificate and key management, NIST SP 800-57 Key Management gives a strong anchor for cryptographic lifecycle discipline, while NIST SP 800-63 Digital Identity Guidelines helps frame assurance and recovery expectations for FIDO2-based authentication. For public certificate issuance and revocation, the CA/Browser Forum remains the practical baseline for public PKI behavior.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-63 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | PKI governance depends on cryptographic key lifecycle, cryptoperiods and revocation discipline. |
| Recommendation — Define key lifecycle ownership, rotation and destruction rules for certificates and private keys. | ||
| NIST SP 800-63 | Digital Identity Guidelines | FIDO2 assurance and recovery must align to digital identity proofing and authenticator management. |
| Recommendation — Apply authenticator assurance and recovery rules when issuing and resetting FIDO2 credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | Unified credential governance needs consistent provisioning, deprovisioning and exception handling. |
| Recommendation — Centralise account and credential lifecycle control so offboarding revokes every access path. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | The estate is fundamentally an access-control governance problem across multiple credential types. |
| A.8.5 — Secure Authentication | FIDO2 and certificate-based sign-in require authentication controls tied to assurance and recovery. | |
| A.8.24 — Use of Cryptography | PKI control depends on cryptographic key handling and certificate trust management. | |
| Recommendation — Implement access-control policy that covers digital and physical credentials together. Set authentication requirements and recovery rules for strong credentials such as FIDO2 and PKI. Govern cryptographic keys and certificate trust as a managed lifecycle, not an ad hoc asset. | ||
Practitioner Guidance
What to prioritise: Start with offboarding, recovery, and exception handling before trying to perfect issuance workflows. Those three areas create the fastest paths to inconsistent trust if they are split across teams or systems.
What to verify: Confirm that disabling a person removes every active access path, including certificates, passkeys, badges, and fallback recovery channels. The test is whether the estate can produce a single, timely revocation outcome rather than three disconnected tickets.
Decision rule: If a credential can still be used after employment ends, it needs the same urgency as an exposed secret. If a recovery path cannot be attributed to a named approver and expiry date, treat it as a governance defect, not a convenience feature.
What good looks like: One inventory, one offboarding trigger, distinct control rules by credential type, and a reviewable exception register. That combination gives assurance that the organization is managing access authority, not merely running separate authentication systems.
Practitioner takeaway: The real control boundary is the lifecycle, not the login mechanism. If ownership, revocation, and recovery are unified, PKI, FIDO2, and physical access can coexist without creating hidden residual access.
Related resources from NHI Mgmt Group
- How do security teams decide whether to centralise FIDO2, PKI, and physical access credentials in one workflow?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- How should teams govern mobile credentials alongside PKI and physical cards?