Encryption that is missing, weak, badly configured or protected by a key stored next to the data gives a false sense of safety and leaves sensitive data readable. A04:2025 Cryptographic Failures is the fourth risk in the OWASP Top 10:2025, down two places from second in 2021 but still one of the largest categories, with 32 mapped CWEs and more than 2,000 CVEs. This guide sets out what OWASP counts as a cryptographic failure, the specific algorithms, parameters and configurations to require, how to roll changes out without breaking clients, and what evidence proves it is under control. It is for developers, AppSec engineers, platform teams and architects. For the full list, start with the OWASP Top 10 Guide.
Key takeaways
- Most failures are choices, not broken maths. OWASP's list is dominated by weak or deprecated algorithms, reused IVs, ECB mode, unsalted fast hashes, poor randomness and keys committed to source code.
- Classify data first. OWASP's first prevention step is classifying data by sensitivity; controls, retention and key handling follow from that, and data you do not keep cannot be stolen.
- Transport baseline is TLS 1.2 or higher with forward secrecy and HSTS. OWASP 2025 also advises dropping CBC cipher suites and planning for quantum-safe key exchange.
- Passwords need a password hashing function, not a hash. Argon2id, scrypt, yescrypt or PBKDF2 with the OWASP cheat sheet parameters; MD5, SHA-1 and plain SHA-256 are not acceptable for password storage.
- Key management is where most real breaches happen. Keys in repositories, environment variables or the same storage as the encrypted data defeat the encryption; hold the most sensitive keys in an HSM or cloud KMS.
What it is and who it applies to
OWASP's A04:2025 covers failures related to the lack of cryptography, insufficiently strong cryptography, leaking of cryptographic keys and related errors. The category was called Sensitive Data Exposure in 2017, was renamed A02:2021 Cryptographic Failures to focus on root causes, and dropped to fourth place in 2025. OWASP highlights four CWEs linked to weak random number generation as commonly seen: CWE-327, CWE-331, CWE-1241 and CWE-338.
It applies to any application that handles passwords, session tokens, payment card data, health records, personal data or business secrets, and to the services and NHIs that carry those data between systems. Regulators commonly treat encryption as an expected technical measure, so a cryptographic failure often becomes a compliance finding as well as a security one.
The 2025 score table
| Metric (OWASP Top 10:2025 data) | A04 value |
|---|---|
| CWEs mapped | 32 |
| Max / average incidence rate | 13.77% / 3.80% |
| Max / average coverage | 100.00% / 47.74% |
| Average weighted exploit / impact | 7.23 / 3.90 |
| Total occurrences / CVEs | 1,665,348 / 2,185 |
Structure and key requirements
OWASP lists eleven conditions that make an application vulnerable. Grouped by theme, with the CWEs and the requirement that closes each:
| Failure theme | Examples of mapped CWEs | Requirement |
|---|---|---|
| Weak or deprecated algorithms and modes | CWE-327, CWE-326, CWE-780, CWE-1240 | AES with at least 128-bit keys (256 preferred) in GCM or CCM; no ECB; RSA only at 2048 bits or more with OAEP; no MD5, SHA-1, CBC or PKCS #1 v1.5 in new designs |
| IV and nonce misuse | CWE-323, CWE-329 | IVs appropriate to the mode, generated by a CSPRNG where required, never reused with the same key (ASVS V11.3.4) |
| Missing integrity | CWE-325, CWE-347 | Authenticated encryption, or encrypt-then-MAC where AEAD is unavailable; verify signatures before trusting data |
| Weak randomness | CWE-330 to CWE-338, CWE-340, CWE-1241 | Platform CSPRNG only, no manual low-entropy seeding (ASVS V11.5.1) |
| Password storage | CWE-759, CWE-760, CWE-916, CWE-328 | Salted, adaptive password hashing with a work factor |
| Key management | CWE-321, CWE-324, CWE-320 | Keys generated randomly, never hard-coded or committed, rotated on a defined cryptoperiod, sensitive keys in HSM or KMS |
| Transport and certificates | CWE-319, CWE-523, CWE-296, CWE-322, CWE-757 | TLS everywhere, full certificate chain validation, no downgrade, HSTS enforced |
| Side channels and errors | Padding oracle class issues | Constant-time comparisons and cryptographic modules that fail securely (ASVS V11.2.4, V11.2.5) |
Reference parameters
| Use | Recommended setting | Source |
|---|---|---|
| Password hashing (preferred) | Argon2id, minimum 19 MiB memory, 2 iterations, parallelism 1 | OWASP Password Storage Cheat Sheet |
| Password hashing (alternatives) | scrypt N=2^17, r=8, p=1; PBKDF2-HMAC-SHA256 600,000 iterations or PBKDF2-HMAC-SHA512 220,000 where FIPS-140 is required; bcrypt cost 10 or more on legacy systems only, 72-byte input limit | OWASP Password Storage Cheat Sheet |
| Data encryption | AES-GCM or AES-CCM; envelope encryption with a data encryption key wrapped by a separately stored key encryption key | OWASP Cryptographic Storage Cheat Sheet |
| Transport | TLS 1.2 and 1.3 only; ECDHE key exchange with AES-GCM or ChaCha20-Poly1305 suites; HSTS max-age of two years (63072000 seconds) | Mozilla intermediate server configuration; OWASP A04 |
| Randomness | Python secrets, Java SecureRandom, Node.js crypto.randomBytes(), Go crypto/rand, .NET RandomNumberGenerator; never Math.random() or java.util.Random | OWASP Cryptographic Storage Cheat Sheet |
| Post-quantum | ML-KEM (FIPS 203) for key establishment, usually in hybrid mode with a classical algorithm during migration; ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures | NIST FIPS 203, 204, 205 (August 2024) |
For the foundations behind these choices, see the Cryptography Basics Guide and the How TLS Works Guide.
Identity and NHI requirements
Cryptographic keys, certificates and tokens are themselves non-human identities, and many A04 failures are identity lifecycle failures in disguise.
- Keys in source code: OWASP lists keys committed to repositories as a direct vulnerability (CWE-321). Scan commits and history, and treat any found key as compromised. See the Git Secret Scanning Guide.
- Key storage: keep keys out of environment variables and away from the data they protect; use a KMS, HSM or secrets manager with access limited to the workload identity that needs it. See the Cryptographic Key Management Guide.
- Service-to-service TLS: ASVS V12.3.2 requires TLS clients to validate certificates, and V12.1.3 requires mTLS client certificates to be validated before the identity is trusted. See the mTLS Guide.
- Certificate lifecycle: expired keys (CWE-324) and unvalidated chains (CWE-296) come from unmanaged machine identities. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Rotation triggers: rotate on suspected compromise (including when a person with key access leaves), at the end of the cryptoperiod, when usage limits for the mode approach, and when a weakness is found in the algorithm. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
The GoTo breach illustrates the point: encrypted backups were stolen together with an encryption key for part of them, so for that portion the encryption gave no protection.
Implementation steps
- Classify and minimise: label data by sensitivity, delete what you do not need, and use tokenisation or truncation (for example, card numbers) where full values are not required.
- Build a cryptographic inventory: record algorithms, key sizes, libraries, certificates and where keys live (ASVS V11.1.2). This also underpins post-quantum migration planning. See the Cryptographic Inventory and CBOM Guide.
- Fix transport: scan external and internal endpoints with a TLS testing tool, disable TLS 1.0 and 1.1 and non-forward-secret suites, enable HSTS starting with a short max-age, then raise it once no mixed content or HTTP-only subdomain remains. Roll back by lowering max-age before a long value is cached by clients, which is why you start short.
- Fix password storage: adopt Argon2id for new hashes and upgrade legacy hashes at next login, by verifying with the old scheme and rehashing; wrapping old hashes inside the new function covers dormant accounts.
- Move keys: migrate keys from code, config files and environment variables into KMS or HSM, introduce envelope encryption, then rotate every key that was ever exposed.
- Replace weak primitives: use static analysis rules to find MD5, SHA-1, ECB, DES, RC4, non-cryptographic random functions and hard-coded IVs; fix in order of data sensitivity.
- Design for agility: centralise cryptographic choices in a small, well-reviewed library or wrapper so algorithms can be replaced without touching every caller (ASVS V11.2.2). See the Crypto-Agility Guide.
- Plan post-quantum: OWASP points to the ENISA-referenced aim of protecting high-risk systems by the end of 2030. Start with long-lived confidential data exposed to harvest-now, decrypt-later risk. See the Post-Quantum Cryptography Migration Guide.
Decision guidance
| Decision | Choose this | When |
|---|---|---|
| Argon2id vs PBKDF2 | Argon2id | Default for new systems; choose PBKDF2-HMAC-SHA256 at 600,000 iterations only when a FIPS-140 validated module is mandatory |
| Cloud KMS vs dedicated HSM | Cloud KMS | Most organisations and workloads; a dedicated HSM where regulation, key custody or signing volume demands sole control |
| Application-layer encryption vs storage encryption only | Application-layer field encryption | For the most sensitive fields, where database administrators or backups should not see plaintext; storage encryption alone protects mainly against lost media |
| TLS 1.3 only vs TLS 1.2 and 1.3 | TLS 1.2 and 1.3 | Public services with mixed clients; TLS 1.3 only for internal and API traffic where all clients are known. NIST SP 800-52 Rev. 2 required US federal systems to support TLS 1.3 by 1 January 2024 |
| Small vs large organisation | Managed services | Small teams gain most from managed TLS termination, managed KMS and framework defaults; large organisations need an inventory, a crypto standard and ownership per key |
Evidence and assessment
- Configuration evidence: TLS scan reports for every external hostname and key internal service, HSTS headers, and certificate inventory with expiry dates.
- Code evidence: static analysis results with rules for weak algorithms, insecure random functions and hard-coded keys; secret scanning reports for repositories.
- Key management evidence: key policy and lifecycle (ASVS V11.1.1), KMS access policies, rotation history and key usage logs.
- Password storage evidence: the hashing algorithm and parameters in configuration, and the share of accounts migrated to the current scheme.
- Testing: the OWASP Web Security Testing Guide chapter on weak cryptography covers transport, padding oracle, unencrypted channels and weak encryption tests.
A practical test plan
| Test | How | Pass condition |
|---|---|---|
| Protocol and suites | Run a TLS scanner against each hostname and port, including APIs and admin interfaces | Only TLS 1.2 and 1.3; forward-secret suites; no CBC suites where the client base allows |
| HTTPS enforcement | Request every page over HTTP and inspect the response headers | Redirect to HTTPS and a Strict-Transport-Security header on HTTPS responses |
| Certificate validation | Point service clients at a test endpoint with an untrusted or mismatched certificate | Connection refused and an error logged |
| Password storage | Inspect the stored hash format and configured parameters | Argon2id, scrypt, yescrypt or PBKDF2 at or above cheat sheet parameters |
| Randomness | Code search for non-cryptographic generators used for tokens, IDs, IVs or keys | No hits outside non-security uses |
| Key exposure | Secret scanning across repositories, history, container images and CI logs | No live keys; any historic hit rotated |
| Caching | Check Cache-Control on responses containing personal or account data | no-store on sensitive responses |
Run the transport and certificate tests on every release that changes load balancers, proxies or client libraries, since those are where downgrades usually creep back in.
Metrics
| Metric | Target direction |
|---|---|
| Endpoints still offering TLS 1.0/1.1 or non-forward-secret suites | Zero |
| Share of user password hashes on the current algorithm and parameters | Towards 100% |
| Hard-coded or committed keys found per month (and time to rotate) | Falling; rotation within hours |
| Keys past their defined cryptoperiod | Zero |
| Applications with a complete cryptographic inventory entry | Towards 100% |
| Certificates expiring within 14 days without a renewal in flight | Zero |
What to monitor
Alert on KMS decrypt calls from unexpected identities or at unusual volume, on disabled key rotation, on certificate validation being turned off in client configuration changes, and on new endpoints appearing in external attack surface scans without HSTS.
Mapping to other frameworks
| Framework | Relevant items |
|---|---|
| OWASP ASVS 5.0 | V11 Cryptography (V11.1 inventory, V11.2 implementation, V11.3 encryption algorithms, V11.4 hashing, V11.5 random values, V11.6 public key), V12 Secure Communication (V12.1 to V12.3). See the OWASP ASVS Guide |
| NIST SP 800-53 Rev. 5 | SC-8 Transmission Confidentiality and Integrity, SC-12 Cryptographic Key Establishment and Management, SC-13 Cryptographic Protection, SC-17 Public Key Infrastructure Certificates, SC-23 Session Authenticity, SC-28 Protection of Information at Rest, IA-5 Authenticator Management |
| NIST CSF 2.0 | PR.DS-01 data at rest protected, PR.DS-02 data in transit protected |
| CIS Controls v8.1 | Control 3 Data Protection (encryption of sensitive data in transit and at rest) |
| ISO/IEC 27001:2022 Annex A | A.8.24 Use of cryptography |
| MITRE ATT&CK v20 | T1557 Adversary-in-the-Middle, T1040 Network Sniffing, T1552.004 Private Keys, T1110.002 Password Cracking, T1600 Weaken Encryption |
| Related OWASP lists | M10 Insufficient Cryptography (mobile), A07:2025 Authentication Failures for session handling, A08:2025 Software or Data Integrity Failures for signatures |
Common pitfalls
- Encrypting with the key beside the data. Backups or databases encrypted with a key stored in the same bucket, config file or environment add little, as the GoTo case shows.
- Fast hashes for passwords. OWASP's second scenario: unsalted or simply hashed passwords exposed through a file upload flaw are matched against rainbow tables, and even salted fast hashes fall to GPU cracking.
- TLS on the login page only. OWASP's first scenario: without TLS enforced everywhere and HSTS, an attacker on a hostile network downgrades to HTTP, steals the session cookie and can alter requests such as payment recipients.
- Disabling certificate validation to fix a test. A flag set in development reaches production and silently removes protection against interception.
- Home-made crypto and wrong primitives. ECB mode, reused nonces with GCM,
Math.random()for tokens, or Base64 treated as encryption (CWE-261 covers weak encoding of passwords). - Caching sensitive responses. OWASP advises disabling caching for sensitive responses at CDN, web server and application layers; encrypted transport does not help once a shared cache stores the page.
Practitioner checklist
- Classify data, delete what you do not need and tokenise or truncate what you keep where possible.
- Maintain a cryptographic inventory of algorithms, libraries, keys and certificates per application.
- Enforce TLS 1.2 or higher with forward secrecy on every endpoint, validate certificates on every client and enable HSTS.
- Store passwords with Argon2id (or scrypt or PBKDF2 at OWASP parameters) and migrate legacy hashes.
- Use AES-GCM or another authenticated mode through a vetted library; ban ECB, MD5, SHA-1 and non-cryptographic random functions in code rules.
- Move keys into KMS or HSM, use envelope encryption and rotate any key ever found in code or config.
- Define cryptoperiods and rotation triggers, and alert on keys and certificates that exceed them.
- Disable caching of sensitive responses across CDN, server and application caches.
- Start a post-quantum plan for long-lived sensitive data, beginning with key exchange.
Standards and references
- OWASP: A04:2025 Cryptographic Failures
- OWASP: Password Storage Cheat Sheet
- OWASP: Cryptographic Storage Cheat Sheet
- OWASP: Application Security Verification Standard 5.0
- NIST: SP 800-52 Rev. 2 Guidelines for TLS Implementations
- NIST: First 3 Finalized Post-Quantum Encryption Standards
- NIST: SP 800-53 Rev. 5
- Mozilla: Server Side TLS Configuration Guidelines
Related NHI Mgmt Group resources: OWASP Top 10 Guide · Encryption Guide · Cryptographic Key Management Guide · OWASP Top 10 A03 Guide · OWASP Top 10 A05 Guide