Insufficient cryptography is the use of weak, obsolete, misconfigured or missing cryptographic controls to protect data or communications. It includes short keys, outdated algorithms, poor key management, and failures to encrypt data at rest or in transit, leaving confidentiality, integrity or authentication weaker than intended.
What insufficient cryptography means in practice
Insufficient cryptography is not just “using encryption,” it is using cryptography in a way that fails to deliver real protection. Weak algorithms, short keys, broken modes, hard coded keys, poor randomness, or incomplete coverage can leave sensitive data readable, forgeable, or easier to impersonate even when a control appears to exist.
The core problem is assurance. If the design, implementation, or configuration is weak, attackers may be able to recover data, alter protected traffic, or bypass authentication boundaries that depend on cryptographic strength. That is why cryptography has to be treated as a managed security control, not a checkbox.
Where the weakness shows up
Insufficient cryptography commonly appears in two places, data protection and communications protection. At rest, the issue may be missing encryption, obsolete algorithms, or poor key handling. In transit, it may be weak TLS configuration, broken certificate validation, or acceptance of insecure fallback paths.
It can also appear in supporting mechanisms such as password storage, token signing, session protection, and key generation. The failure is often subtle because the system still “uses crypto,” but the cryptography is not strong enough, not deployed consistently, or not enforced where the data actually moves.
OWASP Mobile Top 10 M10 Insufficient Cryptography Guide is a useful reference when weak crypto patterns show up in mobile apps, especially around local storage, key handling, and platform keystores.
Why it is dangerous
Weak cryptography undermines confidentiality, integrity, and often authentication at the same time. If an attacker can decrypt stored secrets, tamper with protected traffic, or replay material protected by weak primitives, the control boundary disappears even though the application may still look “encrypted.”
The danger is amplified when the same weakness affects many users, services, or integrations. A single weak design choice, such as a shared hard coded key or outdated hashing scheme, can create systemic exposure rather than a one off defect.
PCI DSS v4.0 matters here because payment environments require strong protection for account data and strict control over how cryptographic material is used.
ISO/IEC 27001:2022 Information Security Management is relevant because cryptography is only effective when it is governed as part of a broader security management system, including access control, authentication, and key protection.
How organisations evaluate exposure and reduce it
Exposure assessment starts with knowing where cryptography is used, which assets depend on it, and whether the implementation is current and correctly configured. That means checking applications, mobile clients, APIs, data stores, certificates, and key management processes, not just the visible encryption setting.
Remediation usually involves replacing weak algorithms, enforcing secure transport, strengthening key generation and rotation, and removing any design that exposes keys or secrets to the client side. If immediate replacement is not possible, compensating controls such as segmentation, stricter access boundaries, and reduced data sensitivity can narrow the blast radius.
NIST SP 800-57 Key Management is the clearest external reference for key lifecycle choices, including generation, rotation, cryptoperiods, and algorithm selection.
NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control view of this term, especially for authentication, cryptographic protection, and integrity related safeguards.
Detection, verification, and post incident review
Detection focuses on finding weak configuration and evidence of abuse. That includes reviewing protocol settings, certificate chains, key lengths, hashing choices, insecure randomness, and any traffic or storage path that is supposed to be protected but is not. Testing should confirm both implementation quality and actual enforcement.
After a compromise, post incident review should assume cryptographic material may be exposed if the weakness enabled decryption, token forgery, session replay, or credential capture. In those cases, organisations should review whether keys, certificates, tokens, and related secrets need replacement, not just whether the software was patched.
OWASP API Security Top 10 is relevant when insufficient cryptography weakens API authentication, token handling, or transport security.
NIST SP 800-57 Key Management also supports incident review because recovery often depends on replacing compromised keys and reestablishing trust in the cryptographic chain.
Risk and Threat Considerations
Weak cryptography is attractive to attackers because it can turn a protected system into one that is effectively readable, forgeable, or replayable without requiring a full application bypass. The threat is often quiet, because the system may continue functioning while protection is no longer meaningful.
Failure mechanism: Attackers exploit weak algorithms, poor key handling, broken certificate validation, or missing encryption to recover data, tamper with traffic, or abuse trusted sessions and tokens.
Impact: Confidentiality, integrity, and authentication can all fail at once, which can expose sensitive data, enable impersonation, and force broad credential or key replacement after compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57, NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management | Cryptography quality here depends on key lifecycle and algorithm choices. |
| Recommendation — Apply key lifecycle policy to replace weak algorithms and rotate compromised or obsolete keys. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Weak crypto often breaks authentication material, signing, or token protection. |
| Recommendation — Manage authenticators and related secrets so cryptographic protection remains strong throughout use. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | This term is directly about selecting and operating cryptography securely. |
| Recommendation — Define cryptographic requirements, approved algorithms, and key handling rules. | ||
| OWASP ASVS | V11 — Cryptography | ASVS V11 directly verifies cryptographic design, strength, and implementation. |
| Recommendation — Verify that encryption, hashing, and key handling meet current cryptographic requirements. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Protecting data with strong cryptography is a core data protection safeguard. |
| Recommendation — Encrypt sensitive data in transit and at rest with approved, current cryptographic settings. | ||
Practitioner Guidance
What to watch for: Treat any use of legacy algorithms, short keys, client side secrets, weak randomness, or inconsistent encryption coverage as a design and assurance problem, not merely a configuration detail. The important question is whether the control still provides real security under current threat conditions.
Governance implication: Ownership should extend beyond the application team to include architecture, key management, and security review, because insufficient cryptography often persists when nobody is accountable for reviewing the cryptographic design end to end.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org