Shadow cryptography is encryption, certificate use, or trust material created outside central governance. It may work technically, but it bypasses the visibility, renewal, and revocation processes that security teams need to manage risk and maintain accountability.
Expanded Definition
Shadow cryptography refers to encryption, certificate issuance, key generation, or trust material that exists outside central governance controls. In NHI and agentic AI environments, it often emerges when teams need a fast technical workaround for a service, pipeline, or integration and create their own keys, self-signed certificates, or ad hoc trust chains.
The core issue is not whether the cryptography functions. It is whether security, operations, and audit teams can see it, renew it, revoke it, and prove who owns it. That distinction aligns closely with the governance expectations described in the Ultimate Guide to NHIs, where lifecycle control and visibility are treated as foundational to NHI risk management. For broader control expectations around credential handling and trust protection, PCI DSS v4.0 reinforces the need to manage cryptographic materials under defined security processes.
Definitions vary across vendors when shadow cryptography is discussed under certificate sprawl, key sprawl, or unsanctioned trust stores, but the governance failure is the same: cryptographic trust exists without accountable ownership. The most common misapplication is treating self-generated certificates as harmless temporary fixes, which occurs when development teams bypass central key management during urgent deployments.
Examples and Use Cases
Implementing cryptographic governance rigorously often introduces friction for development and platform teams, requiring organisations to weigh deployment speed against the cost of standardisation and review.
- A CI/CD pipeline generates its own signing key for release artifacts because the approved vault is slow to access, leaving the key outside renewal and revocation workflows.
- A microservice uses a self-signed certificate for mutual TLS in staging, then that trust path is copied into production without being registered in central certificate inventory.
- An AI agent is granted a local certificate to authenticate to a data service, but the certificate never enters the normal ownership and rotation process.
- A vendor integration stores its own API gateway trust bundle on an edge host, creating a hidden dependency that security teams cannot easily inspect.
These patterns are best understood alongside the governance and lifecycle emphasis in the Ultimate Guide to NHIs, and with the certificate hygiene expectations reflected in PCI DSS v4.0. In practice, shadow cryptography is often a sign that teams have optimized for delivery but not for recoverability, especially when emergency fixes become long-lived trust anchors.
Why It Matters in NHI Security
Shadow cryptography weakens the security model around non-human identities because trust material is only useful if it can be governed over time. When certificates, keys, or tokens are created off-books, revocation becomes incomplete, expirations go unnoticed, and ownership becomes ambiguous. That creates a direct path from convenience to compromise, especially in environments where NHIs already outnumber human identities by 25x to 50x, according to Ultimate Guide to NHIs.
The business risk is not limited to one misconfigured service. Hidden trust artifacts can preserve access long after a team has changed, a workload has been retired, or a certificate should have been revoked. They also complicate incident response because responders cannot quickly determine where trust was established or whether an issuer is still valid. This is why governance frameworks increasingly treat cryptographic sprawl as an identity problem, not just a PKI problem.
Organisations typically encounter the consequences only after a service outage, key compromise, or failed audit reveals that undocumented trust paths were still active, at which point shadow cryptography 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 secret and trust-material sprawl that escapes centralized control. |
| NIST CSF 2.0 | PR.AA-01 | Identity and credential lifecycle controls apply to hidden cryptographic trust chains. |
| NIST Zero Trust (SP 800-207) | SC | Zero Trust depends on explicit trust validation rather than unmanaged certificates. |
Inventory, approve, and rotate all NHI cryptographic material through governed processes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
