Shadow certificates are certificates that exist outside the organisation’s authoritative inventory or lifecycle control. They create blind spots similar to unmanaged non-human identities, because no one can reliably prove who owns them, when they expire, or how quickly they can be revoked.
Expanded Definition
Shadow certificates are a machine identity control problem, not just a certificate hygiene issue. The term covers any certificate that is deployed, copied, renewed, or embedded outside the organisation’s authoritative inventory, approval path, or revocation workflow. In practice, that can include certificates issued by a public CA, internal PKI, or a platform team, as long as nobody can reliably trace ownership, usage scope, expiry, or revocation authority.
Definitions vary across vendors, but in NHI security the core issue is the same: an identity artifact exists without effective lifecycle governance. That makes shadow certificates closely related to unmanaged Non-Human Identities, because both create gaps in visibility, rotation, and offboarding. A certificate may still validate at the protocol level while being operationally invisible to the teams responsible for risk.
The most common misapplication is treating “not expired” as “under control,” which occurs when organisations rely on scattered spreadsheets or ad hoc renewals instead of a current authoritative inventory aligned to NIST Cybersecurity Framework 2.0 asset and access governance.
Examples and Use Cases
Implementing shadow certificate controls rigorously often introduces inventory and automation overhead, requiring organisations to weigh operational visibility against the time and tooling needed to maintain it.
- A TLS certificate is issued for a workload in a test environment, then copied into production without being recorded in the central PKI inventory.
- An application team renews a client certificate manually, but the security team never learns that the old certificate is still trusted by a downstream service.
- A container image contains a bundled certificate that survives deployment changes, creating a hidden trust path that bypasses normal approval and revocation processes.
- A third-party integration uses a certificate issued during onboarding, but ownership was never transferred into the authoritative asset register.
- A certificate outage investigation reveals that the certificate existed in a legacy vault no one had audited, echoing the visibility failures highlighted in the Sisense breach.
These cases are especially common when teams equate certificate management with renewal reminders alone. In a mature program, certificate lifecycle handling is tied to service ownership, dependency mapping, and revocation readiness, not just expiry dates. That is why machine identity guidance and NHI governance are best read together, especially when workloads scale faster than manual review processes. The Ultimate Guide to NHIs — What are Non-Human Identities frames this as part of the broader visibility problem across non-human estates.
Why It Matters in NHI Security
Shadow certificates matter because they undermine trust decisions at the exact point where systems assume trust is already established. If a certificate cannot be discovered, owned, rotated, or revoked quickly, it becomes a standing credential with an unclear blast radius. That is particularly dangerous in Zero Trust and machine-to-machine environments, where certificates often back service authentication, mutual TLS, API access, and workload federation. A hidden certificate can keep an obsolete workload trusted long after the owner believes it has been retired.
The risk is not theoretical. According to NHI Mgmt Group, only 5.7% of organisations have full visibility into their service accounts, which is a useful proxy for how often non-human trust assets escape oversight entirely. When that visibility gap exists, certificate expiry events, renewal failures, and emergency revocations become incident response problems rather than routine operations.
Organisations typically encounter shadow certificates only after an outage, a failed audit, or a compromise investigation reveals an unknown trust path, at which point the term becomes operationally unavoidable to address.
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-02 | Covers hidden or unmanaged secrets and identity assets that escape inventory control. |
| NIST CSF 2.0 | ID.AM-01 | Asset management requires maintaining an inventory of systems and related trust artifacts. |
| NIST Zero Trust (SP 800-207) | JA | Zero Trust relies on continuous verification of identities and trusted endpoints. |
Inventory every certificate, assign ownership, and revoke anything outside approved lifecycle control.
