Certificates fail because the certificate is only proof of trust, while the private key proves control. If the key is exposed, copied, or reused, an attacker can impersonate the subject even when the certificate remains technically valid. This turns a trust mechanism into an impersonation path, which is why key handling is the real control point.
Why This Matters for Security Teams
Digital certificates are often treated as the trust boundary, but the operational failure point is the private key behind them. When keys are copied into source control, left on shared hosts, or reused across services, the certificate can remain technically valid while the identity behind it is no longer controlled. NIST’s NIST Cybersecurity Framework 2.0 frames this as an asset governance problem as much as an authentication problem.
For machine identities, the scale and turnover make this worse. NHIMG research in The Critical Gaps in Machine Identity Management report notes that 69% of organisations now have more machine identities than human ones, while 57% still lack a complete inventory. That combination means compromised or mishandled keys can persist long after the original deployment is forgotten. In practice, many security teams discover key misuse only after an outage, a lateral movement event, or an impersonation incident has already started.
How It Works in Practice
A certificate proves that a public key was signed by a trusted issuer. It does not, by itself, prove that the current holder still controls the private key in a safe way. Security teams therefore need to manage the lifecycle around the key material, not just the certificate file. That includes generation, storage, rotation, revocation, inventory, and access restrictions.
Current best practice is to treat private keys as high-value secrets and bind them to workload identity wherever possible. For services and automation, that usually means using short-lived credentials, hardware-backed key storage, or workload identity systems such as SPIFFE rather than copying long-lived keys between systems. The operational goal is to reduce the time a stolen key remains usable and to limit where it can be extracted from memory or disk.
- Generate keys in controlled environments and avoid exporting them unless there is a documented need.
- Store private keys in hardened secret managers, HSMs, or platform-native key stores with strict access controls.
- Use short certificate TTLs where rotation can be automated, because expiry alone is not a control if key reuse is uncontrolled.
- Revoke certificates and rotate related keys immediately after suspected exposure.
- Monitor issuance, access, and reuse patterns so abnormal key behaviour is visible early.
This guidance lines up with NHIMG’s analysis in the Ultimate Guide to NHIs — What are Non-Human Identities, which emphasises that machine trust depends on ownership, visibility, and lifecycle control. It also reflects the reality seen in the Sisense breach, where credential handling failures became a security event rather than a simple certificate issue. These controls tend to break down in environments with ad hoc certificate issuance, unmanaged service accounts, and no authoritative inventory of where keys are deployed.
Common Variations and Edge Cases
Tighter key control often increases operational overhead, requiring organisations to balance cryptographic safety against deployment speed and service availability. That tradeoff is especially visible when legacy systems cannot support automated rotation or when teams depend on embedded keys in appliances, CI pipelines, or third-party integrations.
There is no universal standard for how much certificate TTL should shrink or how aggressively private keys should be isolated, because the right answer depends on automation maturity and blast radius. Current guidance suggests using the shortest practical validity period, but only where renewal, revocation, and distribution are reliable. A short-lived certificate with a long-lived, shared private key is still a weak design.
Edge cases also matter. Self-signed certificates, internal PKI, and mutual TLS do not eliminate the problem if the key is exported or reused across environments. Likewise, revocation is not a complete fix when clients do not check revocation status consistently. In these cases, the safer control is to prevent key exposure in the first place, not rely on certificate invalidation after the fact. NHIMG’s CI/CD pipeline exploitation case study is a good reminder that build and delivery systems often become the easiest path to private key reuse.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Key rotation and lifecycle control are central when certificates stay valid after key exposure. |
| NIST CSF 2.0 | PR.AC-1 | Access control is relevant because mishandled keys undermine authenticated identity assurance. |
| NIST Zero Trust (SP 800-207) | IA-5 | Zero Trust depends on strong credential handling and rapid revocation of compromised material. |
Inventory keys, shorten TTLs, and automate rotation so exposed private keys stop being reusable.
