Certificate practices and PKI design are a security control, not a detail

At a glance

What this is: This is a PKI and certificate governance piece arguing that certificate lifetime, key protection, and revocation must be designed together to limit exposure.

Why it matters: It matters because certificate policy is identity policy for machines, and weak PKI decisions can undermine workload identity, device trust, and broader IAM controls.

By the numbers:

• 61% rely on spreadsheets or manual tracking for machine identity management.
• 53% of organisations have experienced a security incident directly related to machine identity management failures.
• Certificate expiry is the leading cause of outages for 45% of organisations.

👉 Read DigiCert's article on mitigating risk in certificate practices

Context

PKI is the trust layer for machine identity, and this article argues that certificate policy is part of security design, not just operations. The core issue is that long-lived certificates, weak private-key storage, and slow revocation turn authentication into a liability once a certificate or key is exposed.

For IAM and NHI teams, the practical question is how to govern certificate validity, rotation, and revocation as lifecycle controls rather than one-time setup choices. That is why lifecycle management guidance such as the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs keeps showing up in certificate conversations.

The article also makes a broader point about resilience: revocation has to work even when devices are intermittent, distributed, or hard to reach. In other words, policy, key protection, and recovery mechanics need to be designed as one system, not three separate tasks.

Key questions

Q: How should security teams govern certificate lifetimes in machine identity programmes?

A: Security teams should align certificate lifetimes with their ability to renew, reissue, and revoke at scale. Long-lived certificates are only defensible when replacement is automated and key protection is strong. Otherwise, the organisation is extending the useful life of a credential that may already be compromised or cryptographically stale.

Q: Why do private keys need separate controls from certificate policy?

A: Because a certificate only authenticates trust if the private key remains secret. If the key is stored in plain text or otherwise easy to extract, an attacker can impersonate the device or workload even if the certificate itself looks valid. Key protection is therefore an identity control, not just a storage practice.

Q: What breaks when certificate revocation is difficult to reach operationally?

A: Revocation becomes ineffective if devices cannot reliably check status through CRL or OCSP paths. In that case, compromised certificates can continue to function long after the organisation believes they have been neutralised. Revocation must work in cached, intermittent, and distributed environments to be meaningful.

Q: How do certificate lifetimes, key storage, and revocation work together?

A: They form a single trust chain. Longer lifetimes increase exposure, weak key storage increases compromise likelihood, and revocation determines whether compromise can be contained. If any one of those three is poorly designed, the whole PKI trust model becomes easier to abuse.

Technical breakdown

Certificate validity periods and replacement cycles

Certificate validity is a trade-off between operational convenience and risk concentration. Longer-lived certificates reduce renewal frequency, but they also extend the period in which stolen or weak credentials remain useful and increase the number of private keys that must be protected. The article correctly ties validity to future cryptographic breakage as well, since algorithms and key sizes eventually age out. In PKI terms, expiry is not just an administrative event. It is the moment when replacement, reissue, and trust revalidation must already be engineered into the system.

Practical implication: Set certificate lifetimes with replacement mechanics already built, not as a separate cleanup task after expiry.

Private key protection in device and application PKI

A certificate is only as trustworthy as the private key behind it. If the key can be extracted from plain text storage, attackers can impersonate the device, decrypt traffic, and authenticate into services that trust that identity. The article points to encrypted key stores and hardware-backed protection such as TPMs because key protection changes the economics of compromise. Without that protection, certificate policy becomes a fast path to impersonation rather than a control. This is a classic machine identity problem, not a theoretical cryptography issue.

Practical implication: Treat private key storage as an identity control surface and remove any plaintext persistence from device or application design.

Certificate revocation, CRL, and OCSP as operational controls

Revocation closes the gap between compromise and continued trust. CRL and OCSP are both standard ways to tell relying parties that a certificate should no longer be accepted, but they solve different deployment problems. CRLs are better suited to intermittent connectivity because they can be cached, while OCSP provides fresher status and can be stapled into the TLS handshake for efficiency. The main lesson is that revocation is not optional overhead. It is the mechanism that keeps a compromised certificate from remaining valid after key theft or policy failure.

Practical implication: Design revocation to work in offline, cached, and distributed environments before you rely on certificates for authentication.

NHI Mgmt Group analysis

Certificate policy is identity policy for machines. The article is strongest when it treats certificate validity, key protection, and revocation as one governance problem rather than separate technical settings. That maps directly to OWASP-NHI and NIST CSF thinking: the trust boundary is the credential, not the application alone. For practitioners, the lesson is that certificate governance belongs in lifecycle management, not in a post-deployment troubleshooting queue.

Long-lived certificates create identity blast radius. The longer a certificate remains valid, the more opportunity there is for compromise, stale trust, and delayed replacement. The article shows why extended validity must be matched by stronger revocation and better storage, otherwise the credential simply accumulates exposure over time. The practitioner conclusion is that certificate lifetime should be measured as risk duration, not convenience.

Plaintext private key storage is a governance failure, not a storage preference. Once a private key is easy to extract, the organisation has effectively delegated trust to whoever finds the file. That failure mode matters across device identity, software authentication, and workload identity because the same weakness turns any certificate into an impersonation token. The practical conclusion is that key storage controls belong in the security baseline, not in optional hardening.

Revocation only works if it is operationally reachable. The article’s CRL and OCSP discussion highlights a persistent NHI problem: many controls are designed as if every identity can always check back with a central service. That assumption fails in embedded, intermittent, and distributed environments, so revocation design has to reflect actual runtime conditions. The practitioner conclusion is to validate revocation paths under real network constraints, not ideal ones.

Identity lifecycle for machines is the real control plane. Certificate issuance is easy to celebrate, but replacement, revocation, and decommissioning are what determine whether trust decays safely. This is where the article aligns with the broader NHI governance problem space: unmanaged lifecycle is what turns a certificate into standing privilege. The conclusion for teams is simple. If you cannot replace and revoke at speed, you do not have controlled machine identity.

From our research:

• 53% of organisations have experienced a security incident directly related to machine identity management failures, according to The Critical Gaps in Machine Identity Management report.
• 61% rely on spreadsheets or manual tracking for machine identity management, which leaves certificate ownership and expiry monitoring vulnerable to human error.
• For the lifecycle side of this problem, the NHI Lifecycle Management Guide shows why issuance, renewal, revocation, and offboarding need to be governed as one process.

What this signals

Certificate governance is becoming a broader machine identity control problem. As organisations expand private-trust PKI into applications, devices, and workload authentication, the operational risk shifts from isolated certificate expiry to lifecycle sprawl. Teams should expect certificate policy to sit alongside access review, secret rotation, and workload identity governance in the same programme conversation.

The practical signal is that revocation and replacement must be validated under real runtime conditions, not idealised architecture diagrams. When a device cannot reliably reach a central service, the organisation still needs a way to assert that trust has changed. That is why machine identity programmes increasingly need the same operational discipline used for other identity lifecycle controls.

Identity blast radius: when a certificate lives too long or a private key is easy to extract, the credential can outlast the trust model built around it. That makes lifecycle ownership, not just cryptographic strength, the decisive control variable for certificate-based identity.

For practitioners

• Shorten certificate lifetimes to match replacement capability Set validity periods only after confirming that reissue, renewal, and rollback are automated across the environments where certificates are used. Long-lived certificates should exist only where the organisation can prove reliable replacement and revocation.
• Move private keys out of plaintext storage Use encrypted key stores or hardware-backed protection such as TPMs for device and application keys. If the key can be copied from disk, the certificate is already weaker than the trust model assumes.
• Test revocation in offline and intermittent environments Validate CRL caching, OCSP reachability, and fallback behaviour on devices that cannot depend on constant internet access. Revocation must still work when connectivity is limited, delayed, or routed through an internal gateway.
• Treat certificate replacement as a planned lifecycle event Build a renewal and reissue process that can handle algorithm deprecation, key compromise, and policy change without forcing emergency manual work. Lifecycle governance should cover issuance, replacement, and retirement as one chain.

Key takeaways

• PKI decisions are identity governance decisions because certificate lifetime, key storage, and revocation determine how long machine trust can survive compromise.
• Long-lived certificates and weak private key handling increase identity blast radius, especially when replacement and revocation are not automated.
• Teams should govern certificates as a lifecycle process, with tested renewal, revocation, and offline validation paths already in place.

Key terms

• Certificate Validity Period: The certificate validity period is the time window during which a certificate is trusted as authentic. In machine identity programmes, that window is also a risk window, because longer lifetimes increase exposure to compromise, cryptographic obsolescence, and delayed replacement.
• Private Key Protection: Private key protection is the set of controls that keep the secret behind a certificate from being extracted or reused. For devices and workloads, this means preventing plaintext storage, using encrypted stores, or relying on hardware-backed protection so trust cannot be copied easily.
• Certificate Revocation: Certificate revocation is the process of marking a certificate as no longer valid before its expiry date. In practice, revocation only matters if relying parties can check status through CRL or OCSP paths that still work in the environments where the certificate is used.
• Machine Identity Lifecycle: Machine identity lifecycle is the governed sequence of issuing, renewing, replacing, revoking, and retiring non-human credentials such as certificates. It is the operational discipline that prevents machine trust from outliving the systems, relationships, or cryptographic assumptions it was created for.

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.

This post draws on content published by DigiCert: Mitigating Risk: The Importance of Considering Your Certificate Practices. Read the original.