Private certificate management demands lifecycle control, not just PKI

At a glance

What this is: This is a guide to building and running an internal PKI, with the key finding that certificate issuance is the easy part and lifecycle operations are where trust succeeds or fails.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly depend on certificate-based trust for services, workloads, devices, and internal platforms, and weak certificate lifecycle control becomes an identity risk and an outage risk.

By the numbers:

• The maximum lifetime of a public TLS certificate is now 200 days, down from 398, and the CA/Browser Forum's approved schedule takes it to 100 days in March 2027 and 47 days in March 2029.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure.

👉 Read Infisical's guide to building and running an internal PKI

Context

Private certificate management is the operational discipline behind internal trust. A certificate can authenticate a service or encrypt a connection, but the programme only works if root keys stay protected, intermediates are scoped correctly, renewal is automated, and revocation remains available when a key is compromised.

That makes PKI a governance problem as much as a cryptographic one. For NHI and platform teams, certificates behave like machine identities with a lifecycle, which means inventory, distribution, rotation, offboarding, and auditability matter as much as issuance.

Key questions

Q: How should teams govern private certificates across a hybrid environment?

A: Treat certificates as governed identities, not just cryptographic artifacts. Maintain an inventory of roots, intermediates, leaf certificates, trust stores, and owners, then enforce profile-based issuance and automated renewal. Without that operating model, certificate trust becomes fragmented across platforms and outages appear when renewal, revocation, or distribution fails.

Q: Why do short-lived certificates force changes in PKI operations?

A: Shorter certificate lifetimes reduce the time an exposed certificate can be abused, but they also eliminate the margin for manual renewal. Teams need automation, monitoring, and tested replacement paths or they will turn security improvements into availability incidents. The control shift is from calendar-based administration to continuous lifecycle management.

Q: What breaks when certificate revocation is not reliable?

A: Revocation stops being a real control when clients cannot reach status services or when operators cannot prove which systems consume which trust chain. In that case, compromised certificates may remain functionally trusted until expiry, which defeats the point of early invalidation. This is a design and dependency problem, not just an operations problem.

Q: Who should own certificate lifecycle governance in the enterprise?

A: Ownership should sit with the identity or platform function that can coordinate trust policy, automation, and audit evidence across workloads and devices. Security can set control requirements, but PKI governance fails when no team owns root protection, issuance scope, trust-store distribution, and revocation validation as one system.

Technical breakdown

Internal PKI hierarchy and trust anchors

An internal PKI works because every certificate chains back to a trust anchor that relying systems already accept. The root CA is the top of that chain, but it should almost never issue leaf certificates directly. Instead, it signs intermediate CAs that handle daily issuance and enforce policy. That separation limits blast radius and keeps the root key offline or tightly protected. The real control challenge is not creating certificates, but maintaining the hierarchy, the trust stores, and the certificate profiles that stop one request from becoming a broad authority grant.

Practical implication: design the hierarchy so the root key is offline and intermediates are scoped by environment, workload, or certificate purpose.

Certificate issuance, CSR validation, and profile enforcement

A certificate signing request is only a request. The CA should verify that the requested identity, key usage, validity period, and allowed subject names match a defined certificate profile before it signs anything. This is where least privilege shows up in PKI: a workload that needs one TLS identity should not be able to mint a broader one. The policy layer is what prevents certificate issuance from becoming an uncontrolled identity factory. Without strict profile enforcement, issuance becomes technically valid but operationally unsafe.

Practical implication: require profile-based approval for every CSR and limit each CA to the narrowest certificate types it genuinely needs to issue.

Revocation, renewal, and certificate lifecycle automation

Certificate management breaks when renewal and revocation depend on people remembering dates or running ad hoc scripts. Revocation services such as CRLs and OCSP exist to invalidate certificates before expiry, while short-lived certificates reduce the window of misuse. But the operating model only holds if discovery, renewal, replacement, and audit trails are automated across servers, containers, and device fleets. In practice, certificate lifecycle work is the control plane that keeps trust from decaying as environments change faster than manual administration can keep up.

Practical implication: automate discovery and renewal before shortening lifetimes further, or the programme will turn certificate expiry into an outage pattern.

Threat narrative

Attacker objective: The attacker wants to impersonate trusted services or weaken internal trust so they can intercept, alter, or reroute encrypted traffic without being detected.

1. Entry occurs when a private key, root trust anchor, or issuing CA is exposed through poor key protection or an unscoped issuance path. Once that trust boundary is weakened, an attacker can mint certificates that appear legitimate to relying systems.
2. Escalation follows when the compromised CA or stolen private key is used to issue or replace identities across services, turning a single trust failure into broad impersonation potential. Because certificate trust is inherited, each valid chain extends the attacker’s reach.
3. Impact is service impersonation, man-in-the-middle abuse, or silent trust decay across the fleet when expired, revoked, or misissued certificates are still accepted. In a mature environment, the blast radius is not just one endpoint but every system that inherited that trust anchor.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Private certificate management is identity governance for machine trust, not a side task for infrastructure teams. Certificates are how workloads, devices, and internal services prove who they are, so lifecycle failure in PKI is an identity failure. That means ownership, scope, renewal, revocation, and auditability need the same governance attention as human access or API key management. Practitioners should treat certificate operations as part of the broader identity programme.

Certificate lifecycle control is the named concept this article really exposes. The guide makes clear that issuance is trivial while trust decays when inventory, renewal, revocation, and distribution are left to manual effort. That is the operational failure mode: a certificate can be cryptographically valid but governance-invalid because no one can prove where it lives, who depends on it, or how it will be removed. The implication is that certificate management must be measured as a lifecycle discipline, not a signing service.

Root CA protection and intermediate scoping define the real blast radius of an internal PKI. A root key is not just another secret, because it authorises every subordinate trust decision beneath it. When the root is exposed or intermediates are overbroad, the trust model ceases to be compartmentalised and becomes fleet-wide risk. The practitioner conclusion is simple: hierarchy design is the primary control boundary, not an implementation detail.

Shorter certificate lifetimes shift PKI from periodic administration to continuous operations. As public certificate lifetimes contract, manual renewal habits become less defensible even in private environments. That pressure does not remove the need for governance, it increases it, because automation must now carry more of the trust workload without reducing policy precision. Teams should re-evaluate whether their current PKI model can sustain frequent renewal without generating outages.

Internal PKI now intersects directly with NHI governance and Zero Trust design. Service identities, workload identities, and device identities often depend on certificates for authentication, which makes certificate management part of the same control surface as secrets, tokens, and access policy. The more distributed the environment becomes, the more a PKI failure looks like a broader identity governance failure. Practitioners should align PKI operations with NIST SP 800-207 and NHI lifecycle controls, not treat them as separate programmes.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why certificate and workload identity inventories need continuous ownership rather than periodic clean-up.
• The certificate-lifecycle problem sits alongside that visibility gap, so teams should pair lifecycle controls with NHI Lifecycle Management Guide practices before shrinking certificate validity further.

What this signals

Certificate management is converging with broader NHI governance. The same control failures that affect service accounts, API keys, and workload identities also show up in private PKI when no one can reliably inventory, renew, or revoke certificates. Teams that still run certificate operations as a separate infrastructure function will find that identity risk is spreading faster than their review cycles can track.

Access scope and trust scope are now the same governance question. If a workload certificate can be minted too broadly, the identity can outgrow the workload it was meant to represent. That is why certificate profiles, trust-store distribution, and root scoping should be reviewed alongside least-privilege policy, not after the fact.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs, certificate programmes cannot assume the environment already protects related trust material. Private PKI now needs the same operational discipline as secret governance, because the surrounding control failures are usually what turn a valid certificate into a security incident.

For practitioners

• Map every certificate trust chain Build an inventory of roots, intermediates, leaf certificates, trust stores, and dependent systems so you can see where trust is actually anchored and where revocation will matter most. Link each chain to a named owner and review it on a fixed cadence.
• Scope issuing CAs by purpose Separate issuance by environment, certificate type, or business unit so a problem in one branch does not become a universal trust event. Keep the root offline and restrict each issuing CA to the narrowest certificate profile it needs.
• Automate renewal before lifetimes shrink further Use ACME, API-driven enrollment, or platform integrations to renew and replace certificates without waiting for humans. Prioritise systems with the shortest certificate lifetimes and the highest outage impact, then verify that replacement is fully tested.
• Operationalise revocation testing Test CRL and OCSP availability, verify client behaviour when revocation data is missing, and confirm that compromised certificates can be removed before expiry. If revocation cannot be relied on, treat that as a design defect rather than an exception.

Key takeaways

• Private PKI fails at the lifecycle layer first, not the signing layer.
• Certificate trust is only as strong as the root hierarchy, renewal automation, and revocation availability behind it.
• Identity teams should govern certificates as machine identities with owners, scope, and offboarding paths.

Key terms

• Internal PKI: An internal public key infrastructure is a privately operated trust system that issues and validates certificates for an organisation's own services, devices, and workloads. It uses the same cryptographic machinery as public PKI, but the organisation owns the hierarchy, policy, trust stores, renewal, and revocation responsibilities.
• Certificate Lifecycle Management: Certificate lifecycle management is the ongoing process of discovering, issuing, deploying, renewing, rotating, revoking, and retiring certificates. In practice, it is what prevents certificates from becoming stale trust artifacts that remain valid long after ownership, scope, or risk has changed.
• Trust Anchor: A trust anchor is the root certificate or root trust source a system is configured to accept as authoritative. All downstream certificate trust depends on it, which makes trust anchor protection and distribution a governance issue as much as a cryptographic one.
• Certificate Revocation: Certificate revocation is the act of invalidating a certificate before its natural expiry when a key is compromised, a certificate is misissued, or trust must be withdrawn. It only works operationally if clients can check status reliably and the organisation can act on failures quickly.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Root and intermediate CA ceremony guidance for building a two-tier PKI model
• Step-by-step CSR, profile, and issuance examples for internal TLS certificates
• Practical revocation options, including CRLs, OCSP, and short-lived certificate trade-offs
• Implementation paths for ACME, API-driven enrollment, and device provisioning workflows

👉 The full Infisical post covers CA hierarchy design, revocation mechanisms, and automation patterns for private certificate management.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.