Manual PKI does not scale well in hybrid and sovereign cloud environments. Issuance, renewal, and revocation become bottlenecks, certificate sprawl grows, and audit evidence becomes inconsistent. The control failure is not the absence of cryptography, but the absence of repeatable lifecycle governance.
Why This Matters for Security Teams
Modernizing PKI without automation usually changes the technology stack faster than the operating model. Certificates still need issuance, renewal, revocation, policy enforcement, and evidence capture, but manual processes turn each of those into a queue. The result is not just delay. It is inconsistent trust states across hybrid infrastructure, sovereign environments, and CI/CD pipelines, where expired or misissued certificates can quietly break service-to-service communication.
For security teams, the real issue is that PKI is now part of identity governance for machines and agents, not a back-office cryptography function. When certificate lifecycle work depends on tickets, spreadsheets, and human memory, teams lose visibility into what is active, what is stale, and what should already have been revoked. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, which is exactly the kind of lifecycle drift that manual PKI creates. That operational drift is why PKI modernization often looks successful on paper while silently increasing exposure in practice.
In practice, many security teams discover certificate sprawl only after an expired chain or stale trust anchor has already interrupted production traffic.
How It Works in Practice
The breakage usually starts when certificate management is upgraded in isolation. Teams may adopt a modern CA, cloud HSM, or stronger key policy, but keep manual workflows for enrollment, renewal, and revocation. That leaves the control plane modern while the lifecycle remains brittle. A better model is to treat certificates as managed workload identity, with automated issuance tied to policy, short validity periods, and revocation events that happen as part of the workload or device lifecycle.
In operational terms, this means binding certificates to automation, not administrators. Systems should request and renew identities through policy-driven tooling, with approvals or constraints based on workload type, environment, and trust posture. That approach aligns with the direction of the NIST Cybersecurity Framework 2.0, which emphasizes governance, protection, and continuous monitoring rather than one-time setup. It also fits the guidance in the Ultimate Guide to NHIs, where lifecycle visibility and rotation are treated as core security controls rather than administrative chores.
- Automate issuance so new workloads receive certificates at creation time, not after a ticket is approved.
- Use short TTLs so renewal is routine and compromise windows are reduced.
- Trigger revocation when workloads are decommissioned, reimaged, or moved across trust boundaries.
- Maintain inventory so expired, duplicated, and shadow certificates are visible to operations and audit.
When this works well, certificate state stays close to workload state, which reduces drift and audit ambiguity. These controls tend to break down in sovereign cloud or air-gapped environments because approval latency, offline trust distribution, and manual exception handling make lifecycle automation incomplete.
Common Variations and Edge Cases
Tighter certificate governance often increases operational overhead, so organisations must balance speed of delivery against the cost of stricter trust controls. That tradeoff becomes sharper in regulated sectors, legacy estates, and multi-tenant platforms where some systems cannot support modern enrollment protocols. Best practice is evolving, but there is no universal standard for how quickly every certificate should be automated across every environment.
One common edge case is the hybrid estate. Public cloud workloads can often use automated issuance through native tooling, while on-premises systems still rely on manually imported certificates or appliance-specific renewal. Another is third-party integration, where external partners may require different trust chains or renewal windows. In those cases, security teams should prioritize the highest-risk certificates first: internet-facing services, privileged automation accounts, and internal trust anchors that would create wide outage or lateral-movement impact if compromised.
Operationally, the question is not whether automation is ideal. It is whether exceptions are documented, time-bound, and monitored. If a certificate remains outside the automated path, it should be treated as a deliberate risk acceptance with an owner and expiry date, not as an invisible legacy dependency.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate lifecycle drift maps to weak NHI rotation and revocation. |
| NIST CSF 2.0 | PR.AC-1 | PKI modernization changes how machine identities are authenticated and governed. |
| NIST CSF 2.0 | DE.CM-8 | Manual PKI reduces visibility into active certificates and trust state. |
Automate issuance, renewal, and revocation so non-human identities never rely on manual lifecycle handling.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
