When machine certificates are not inventoried and revoked properly, old devices and exposed systems can keep authenticating long after they should have lost access. That creates hidden persistence paths, especially for kiosks, IoT devices, and other connected systems that use embedded or hardcoded credentials. Inventory and revocation discipline are what keep machine trust bounded.
When certificate inventory fails, what actually keeps working?
Machine certificates are not just a formality. They are the trust material that lets devices, appliances, services, and embedded systems prove who they are to other systems. When inventory is incomplete, the organisation loses sight of where those certificates exist, which ones are still active, and which ones are still trusted. A certificate can be expired on paper and still be operationally alive if a dependent system keeps accepting it.
That is why the failure is usually not an immediate outage. The more dangerous pattern is residual trust: a certificate remains valid somewhere in the environment, so an old device, kiosk, integration host, or IoT endpoint can continue authenticating even after it should have been removed from service. For the broader machine identity lifecycle, see the Machine Identity, PKI and Certificate Lifecycle Guide and the NHI Lifecycle Management Guide.
In practice, inventory is the control that tells you what exists, what is trusted, and what must be rotated or removed. Without that control, certificate sprawl turns into hidden access sprawl. The lifecycle processes for managing NHIs and the section on static vs dynamic secrets are useful because they show why long-lived trust material needs explicit ownership, rotation, and retirement.
Why stale certificates create hidden persistence paths
When revocation is weak, attackers do not need to defeat the whole authentication stack. They only need one credentialed path that the environment still trusts. If a stolen, copied, or forgotten certificate remains accepted, it can function as a quiet persistence mechanism that survives account changes, password resets, and even some device refresh activity.
This is especially problematic for machines that are hard to track operationally. Kiosks, industrial devices, remote sensors, image-based appliances, and embedded systems often outlive the teams that first deployed them. If their certificates are not tied to a current inventory and revocation process, they may continue to access internal services long after the asset should have been isolated or decommissioned.
That is why certificate management and secret hygiene are inseparable. The relevant issue is not only the certificate itself, but the trust decision downstream of it. The Guide to the Secret Sprawl Challenge is a good companion resource because the same operational failure pattern appears whenever hardcoded or embedded credentials are left behind in distributed systems.
For certificate-specific lifecycle discipline, the external baseline from the CA/Browser Forum and the key-lifecycle guidance in NIST SP 800-57 Key Management both reinforce the same practical point: trust material must be time-bounded, rotated, and retired on a known schedule.
What breaks operationally, and what practitioners should watch for
Once certificate inventory and revocation drift, the breakage is often asymmetric. Security teams lose the ability to answer basic questions quickly, such as which systems can still authenticate, whether a compromised device has been fully cut off, and whether a replacement certificate actually displaced the old one. That creates both exposure and uncertainty, which is a bad combination in mixed estates with legacy and modern machine authentication.
For practitioners, the main failure signal is any certificate that cannot be traced to an owner, asset record, or expiry workflow. Another warning sign is a system that still accepts a certificate after the asset has been retired, reimaged, or reassigned. At scale, this becomes a governance problem as much as a technical one, because revocation only works when ownership, discovery, and enforcement are aligned.
The most useful operational question is not “can we issue certificates?” but “can we prove every live certificate is still needed?” If the answer is no, then revocation will always lag reality. The OWASP Non-Human Identity Top 10 and the Top 10 NHI Issues both frame this as a lifecycle and overprivilege problem, not just a certificate hygiene problem.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-57 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Machine certificates are authenticators that must be inventoried, rotated, and revoked. |
| IA-9 — Service Identification and Authentication | Covers machine and service authentication using certificates and similar trust material. | |
| AC-2 — Account Management | Revocation and removal of certificate-backed access mirrors lifecycle offboarding control. | |
| Recommendation — Inventory all machine authenticators and enforce timely rotation and revocation. Apply service authentication controls so only current machine identities can authenticate. Remove stale certificate-backed access paths as soon as the asset is offboarded. | ||
| NIST SP 800-57 | Key Management | Certificate trust depends on key lifecycle, cryptoperiods, rotation, and destruction. |
| Recommendation — Bind certificate lifecycles to key lifecycle policy, including retirement and destruction. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale machine certificates let decommissioned assets keep authenticating. |
| NHI-02 — Secret Leakage | Certificates and embedded credentials can persist as exposed trust material. | |
| NHI-07 — Long-Lived Secrets | Long-lived machine certificates create hidden persistence when not tracked or revoked. | |
| Recommendation — Revoke certificates when the associated machine is decommissioned or retired. Scan for exposed certificate material and rotate any compromised trust artifacts. Shorten certificate lifetimes and automate renewal to reduce stale trust. | ||
| CIS Controls v8 | CIS-5 — Account Management | Lifecycle control over machine access depends on inventory and removal of stale credentials. |
| CIS-6 — Access Control Management | Revocation of certificate trust is an access-control action on machine identities. | |
| Recommendation — Track every machine credential and remove access when it is no longer required. Revoke stale certificate trust paths and verify enforcement on dependent systems. | ||
Practitioner Guidance
What to prioritise: Start with discovery and ownership. If you cannot tie a certificate to a live asset, a business owner, and a revocation path, treat it as a control gap even before you investigate abuse.
What to verify: Confirm that revocation actually reaches the relying systems that matter. A revoked certificate that is still trusted by a downstream gateway, appliance, or local cache is not really revoked in operational terms.
Decision rule: If the certificate can authenticate to production, prioritise rotation and trust removal before debating whether the asset is “probably” unused. If the device is retired or unreachable, remove its trust path from the environment anyway.
What to measure: Track the percentage of live machine certificates with known owner, known expiry, and explicit renewal or retirement workflow. The goal is not just fewer expired certificates, but fewer unknown certificates.
Practitioner takeaway: Machine certificate risk is usually a trust-lifecycle problem, not a cryptography problem; the environment is only secure when discovery, ownership, and revocation keep pace with every system that can still authenticate.