They often focus on algorithm choice and ignore key custody, secret storage, and lifecycle control. Strong encryption does little if keys are hardcoded, reused, or exposed in logs and repositories. The real control question is whether secrets, certificates, and tokens are rotated, scoped, and monitored with the same discipline as user access.
Why This Matters for Security Teams
Cryptographic failure is rarely a mathematics problem. It is usually a control failure around how keys, certificates, and secrets are issued, stored, rotated, and retired. Teams that treat encryption as a box-ticking exercise often miss the operational risk: leaked API keys, stale certificates, unrevoked tokens, weak backup handling, and accidental exposure in source control. The result is that a strong algorithm can still protect very little.
This is why the issue belongs in governance, not just engineering. The NIST Cybersecurity Framework 2.0 places clear emphasis on protective controls, asset management, and continuous oversight, which is exactly where cryptographic hygiene lives. Security teams also need to understand where secrets intersect with identity, because a certificate or token often functions like an unattended privileged credential. In practice, many security teams encounter cryptographic failure only after a repository leak, service outage, or unauthorized access event, rather than through intentional design review.
How It Works in Practice
Good cryptographic practice starts with asset visibility. Organisations need to know where cryptographic material exists, who can use it, and what depends on it. That includes application keys, TLS certificates, signing keys, SSH keys, machine tokens, and recovery secrets. Current guidance suggests treating these items as high-value identities, not static configuration. If a secret grants access, it needs ownership, approval, expiry, rotation, logging, and revocation paths.
Implementation usually fails in predictable places. Hardcoded secrets in code or CI pipelines are difficult to rotate. Shared certificates create hidden dependencies that make renewal risky. Long-lived tokens reduce operational friction but expand blast radius. Weak separation between development, testing, and production can also expose production-grade credentials in lower-trust systems. The control objective is not simply to encrypt more data. It is to ensure cryptographic material is issued to the right component, stored in a protected system, rotated before exposure becomes likely, and monitored for unusual use.
- Keep secrets out of source code, images, and build logs.
- Use dedicated secret managers or hardware-backed key storage where appropriate.
- Rotate certificates, keys, and tokens on a defined schedule, and immediately after suspicion of exposure.
- Scope credentials narrowly so compromise of one workload does not expose an entire environment.
- Track cryptographic dependencies so renewal and revocation do not cause service outages.
For teams building controls, the practical lens is lifecycle management: creation, distribution, usage, rotation, revocation, and destruction all need auditability. That aligns with broader control thinking in the NIST SP 800-53 family, especially where key management and access control intersect. These controls tend to break down when legacy applications cannot support rotation or when third-party integrations depend on shared secrets with no clean revocation path.
Common Variations and Edge Cases
Tighter cryptographic control often increases operational overhead, requiring organisations to balance resilience against renewal complexity and service availability. That tradeoff is real, especially in environments with many short-lived services, customer-managed keys, or legacy systems that were never designed for automated rotation. Best practice is evolving here, and there is no universal standard for every deployment pattern.
Some edge cases need special handling. Backups can preserve revoked secrets long after production rotation, so encrypted archives and recovery media need the same discipline as live systems. SaaS and managed service integrations may hide key custody inside a provider boundary, which means accountability shifts to contract terms, logging, and revocation assurance. In containerised and cloud-native environments, secret sprawl is common because credentials appear in environment variables, orchestration manifests, and deployment artifacts. If the organisation is using non-human identities, the cryptographic material attached to those identities should be governed like privileged access, not like passive configuration. The same is true for service-to-service authentication in zero trust architectures, where a stolen token can become the fastest route to lateral movement.
For regulated environments, the question is often not whether encryption exists, but whether it can be proven to be correctly controlled. That is where teams should map the issue to MITRE ATT&CK for abuse patterns and to CISA guidance for defensive prioritisation. Organisations with strong crypto but weak custody controls usually discover the gap during incident response, when the failure is already operational rather than theoretical.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Cryptographic material must be governed as protected access infrastructure. |
| NIST AI RMF | GOV | Crypto failures often reflect weak governance over secure system design and lifecycle control. |
| MITRE ATT&CK | T1552 | Exposed credentials and secrets are a common abuse path behind crypto failures. |
| OWASP Non-Human Identity Top 10 | NHI-2 | Non-human identities depend on secure credential custody and rotation discipline. |
| NIST SP 800-63 | Identity assurance principles help distinguish valid credential use from uncontrolled secret exposure. |
Apply identity assurance thinking to machine credentials and require traceable issuance and revocation.
Related resources from NHI Mgmt Group
- What do organisations get wrong about cryptographic bill of materials data?
- What do organisations get wrong about segregation of duties in federated environments?
- What do organisations get wrong about automated data classification?
- What do organisations get wrong about transaction control assurance?
