Government agencies should treat certificate lifecycle management as an identity control, not an infrastructure task. That means every certificate needs an owner, an expiry path, a revocation process, and a link to the business service it protects. Managed PKI helps operationally, but the agency still has to govern when trust starts, ends, and is verified.
Why This Matters for Security Teams
In a managed PKI model, agencies often assume the provider owns certificate risk end to end. That is the wrong assumption. Certificates are machine identities, and lifecycle failures can take down services, weaken trust chains, or leave revoked access effectively valid. The operational issue is not issuance alone, but ownership, expiry, revocation, and verification across dozens of business services and environments.
NHIMG’s research on machine identity management shows why this matters: only 38% of organisations have automated certificate lifecycle management, and certificate expiry is the leading cause of outages for 45% of organisations, according to the Critical Gaps in Machine Identity Management report from SailPoint. That finding aligns with the broader control expectations in the NIST Cybersecurity Framework 2.0, where identity governance is a core risk-management function. In practice, many security teams encounter certificate outages only after production services have already failed, rather than through intentional lifecycle control.
How It Works in Practice
Agencies should manage certificate lifecycle risk as a governed identity process, not a ticket queue. In a managed PKI model, the provider can issue, renew, and sometimes revoke certificates, but the agency still needs policy ownership for who requests certificates, what systems they bind to, how long they remain valid, and what happens when a service is decommissioned or compromised. The strongest programmes define certificate ownership at the service level, not the team level, so revocation and renewal are tied to a business service with a named accountable owner.
Operationally, that means building a minimum control set around the full lifecycle. Current guidance suggests agencies should:
- inventory every certificate and map it to a system, application, or API owner;
- set short, risk-based validity periods and automate renewal where possible;
- separate issuance authority from approval authority for sensitive trust domains;
- require revocation triggers for compromise, decommissioning, or ownership change;
- monitor expiry windows continuously so outages are detected before trust breaks.
This is where the NHI Lifecycle Management Guide is directly relevant: certificate lifecycle controls only work when identity state changes are tracked from creation to retirement, not just at issuance. For implementation discipline, many agencies also align renewal and revocation workflows with the OWASP Non-Human Identity Top 10, which treats unmanaged machine credentials as an attack surface rather than an admin detail. There is no universal standard for tooling architecture yet, but policy-as-code and automated inventory are becoming the practical baseline.
These controls tend to break down when certificates are embedded in legacy appliances or disconnected operational technology because the agency cannot reliably inventory ownership or automate replacement.
Common Variations and Edge Cases
Tighter certificate control often increases operational overhead, requiring agencies to balance outage prevention against change-management friction. That tradeoff becomes sharper in environments with shared infrastructure, third-party managed services, or embedded systems that cannot support modern rotation tooling.
One common edge case is a managed PKI service that provides issuance but not enforcement. In that model, agencies still need internal guardrails for certificate requests, approval thresholds, and revocation validation. Another is emergency revocation: if a certificate is suspected compromised, best practice is evolving toward pre-approved revocation playbooks so security teams do not wait on manual business sign-off while exposure continues. Agencies should also treat auditability as part of lifecycle risk. If they cannot prove when a certificate was issued, renewed, or revoked, they cannot demonstrate control.
The most difficult environments are cross-domain trust networks and mission systems with long-lived certificates, because renewal windows are easy to miss and replacement can trigger service dependencies that are not documented. In those cases, the goal is not perfect automation on day one, but explicit ownership, tighter expiry periods, and verified revocation paths for the highest-risk trust anchors first. That is the practical lesson echoed across Lifecycle Processes for Managing NHIs and Regulatory and Audit Perspectives: if lifecycle events are not governed, managed PKI only automates the failure.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers certificate and secret rotation risk in machine identity lifecycles. |
| NIST CSF 2.0 | PR.AC-1 | Identity lifecycle control depends on managed access and trust decisions. |
| NIST Zero Trust (SP 800-207) | SC-12 | Zero Trust relies on verifying trust anchors and limiting standing trust. |
| NIST AI RMF | Governance and monitoring are needed for automated trust decisions. | |
| CSA MAESTRO | Addresses machine identity governance across distributed service flows. |
Assign accountability for certificate risk and monitor lifecycle failures as operational AI-style risk.
