The common mistake is treating shadow cryptography as a local convenience issue instead of an unmanaged trust problem. If a team can create encryption or certificates outside central governance, those assets can outlive the controls meant to renew or revoke them. That is why discovery and ownership are essential.
Why This Matters for Security Teams
Shadow cryptography becomes a security problem when encryption keys, certificates, or signing workflows are created outside the asset and policy controls that govern the rest of the environment. The risk is not just hidden crypto, but hidden trust: if teams cannot see who issued it, where it is stored, or how it is revoked, then the organisation cannot prove control over data access, integrity, or lifecycle. That is why this issue overlaps with NHI governance, secrets hygiene, and operational resilience.
NHIMG’s Ultimate Guide to NHIs shows how often organisations underestimate this class of risk, including the reality that 96% of organisations store secrets outside of secrets managers in vulnerable locations such as code, config files, and CI/CD tools. When crypto assets are created informally, revocation and rotation usually become manual, inconsistent, or forgotten. That creates a long tail of trust relationships that survive far beyond the original use case, especially in fast-moving DevOps and multi-team environments. In practice, many security teams only discover shadow cryptography after a certificate expires, a signing key leaks, or a legacy integration keeps authenticating long after it should have been retired.
How It Works in Practice
Shadow cryptography usually appears when engineers solve a delivery problem faster than central governance can respond. A team spins up its own certificate authority, hardcodes a private key into a pipeline, uses ad hoc encryption for a partner integration, or issues self-managed tokens for internal tooling. Those choices may be operationally convenient, but they create unmanaged trust paths that bypass inventory, rotation, revocation, and approval workflows.
Good practice starts with discovery and ownership. Security teams need to identify where cryptographic material exists, who controls it, what systems depend on it, and how long it remains valid. The most effective programs treat certificates, keys, and signing material as governed identities with lifecycle controls, not as one-time implementation details. That means pairing inventory with policy, enforcing approved storage, and requiring documented ownership before a key or certificate can be used in production.
For external alignment, PCI DSS v4.0 reinforces the need to protect authentication data and reduce uncontrolled exposure of sensitive cryptographic material, while NHIMG’s Ultimate Guide to NHIs is useful for mapping crypto assets to the broader non-human identity lifecycle. In practice, this means setting short validity periods where possible, automating renewal, and revoking unused material quickly when ownership changes or systems are retired. Teams should also distinguish between approved machine identities and local convenience credentials so that exceptions do not become permanent trust relationships. These controls tend to break down when engineering teams can generate new keys or certificates inside CI/CD, because the issuance path is faster than central review and the resulting assets are easy to forget.
Common Variations and Edge Cases
Tighter crypto governance often increases operational overhead, so organisations must balance speed against the cost of unmanaged trust. That tradeoff is especially visible in legacy systems, partner integrations, and research environments where teams need temporary cryptography before formal onboarding is complete.
Best practice is evolving for these edge cases. Some organisations allow temporary exceptions, but current guidance suggests those exceptions should still be inventoried, time-bound, and owned. Self-signed certificates, internal signing services, and per-team encryption schemes are not automatically wrong, but they become risky when no one can answer basic questions about issuance, expiry, rotation, or revocation.
Shadow cryptography also becomes harder to spot when it is embedded inside tools that already hold secrets, such as build systems, deployment automation, or developer laptops. The practical response is to extend discovery into those environments instead of assuming central vault coverage is enough. A program can be technically strong and still fail if it ignores where developers actually create trust relationships. The biggest gap is usually not cryptographic strength, but lifecycle control and ownership clarity across distributed teams.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shadow crypto is unmanaged machine trust that should be inventoried and owned. |
| NIST CSF 2.0 | PR.AA-1 | Unapproved keys and certificates undermine identity and access assurance. |
| NIST AI RMF | AI systems often create hidden crypto paths through tooling and automation. |
Map autonomous or automated cryptographic issuance into governance, ownership, and accountability processes.
