Cryptographic failures happen when an application encrypts data incorrectly, uses a broken or outdated algorithm, or fails to encrypt sensitive data at all — and they sit at #2 on the OWASP Top 10 (2021), right behind Broken Access Control. The category replaced what the 2017 list called "Sensitive Data Exposure," a rename OWASP made deliberately: exposure is the symptom, but the root cause is almost always a cryptographic mistake — a hardcoded key (CWE-798), an unsalted hash (CWE-759), a deprecated cipher like 3DES-ECB, or plaintext transmission over HTTP. The 2013 Adobe breach exposed 153 million user records partly because passwords were encrypted with unsalted 3DES instead of hashed; the 2012 LinkedIn breach leaked 6.5 million unsalted SHA-1 hashes that were cracked within days. This post covers what qualifies as a cryptographic failure under OWASP's taxonomy, which CWEs map to it, real incidents that illustrate it, and how engineering teams detect and remediate it before it ships.
What Is OWASP's Cryptographic Failures Category?
OWASP's A02:2021 Cryptographic Failures category covers any flaw where sensitive data is inadequately protected through encryption, hashing, or key management — 29 distinct CWEs are mapped to it, more than any other category except Injection. According to OWASP's 2021 Top 10 data set, drawn from over 500,000 applications across roughly 2.8 million CWE occurrences, the category carries a total of 233,788 recorded occurrences and 3,075 associated CVEs, with an average exploitability score of 7.29 out of 10 — among the highest of any Top 10 category. The defining CWEs include CWE-259 (hardcoded password), CWE-327 (use of a broken or risky cryptographic algorithm), CWE-331 (insufficient randomness), and CWE-320 (key management errors). Unlike categories such as Injection, which describe a single attack pattern, Cryptographic Failures spans the entire lifecycle of data protection: what gets encrypted, how it's encrypted, where keys live, and whether TLS is actually enforced end to end.
What Causes Cryptographic Failures in Practice?
Most cryptographic failures trace back to one of four root causes: transmitting sensitive data in cleartext, using a deprecated or weak algorithm, poor key management, or storing data that should never have been retained in the first place. Cleartext transmission still appears in codebases that mix HTTP and HTTPS endpoints or that downgrade to TLS 1.0/1.1 — protocols the PCI Security Standards Council required merchants to stop using by June 30, 2018, because both have known padding-oracle and cipher-suite weaknesses. Weak algorithms show up as MD5 or SHA-1 for password hashing (both are fast enough to brute-force on consumer GPUs at billions of hashes per second) or as ECB-mode block ciphers, which leak plaintext patterns because identical plaintext blocks always produce identical ciphertext blocks — a flaw visible to the naked eye when you encrypt an image with ECB and the outline is still recognizable. Key management failures include committing private keys or API secrets to source control, reusing the same key across environments, or never rotating a key after an employee with access leaves. GitGuardian's 2023 State of Secrets Sprawl report found over 10 million secrets exposed in public GitHub commits in 2022 alone, a 67% year-over-year increase.
What Real-World Breaches Were Caused by Cryptographic Failures?
The Heartbleed bug (CVE-2014-0160), disclosed April 7, 2014, is the clearest large-scale example: a missing bounds check in OpenSSL's heartbeat extension let attackers read up to 64KB of process memory per request, exposing private keys, session tokens, and credentials on an estimated 500,000-plus servers — roughly 17% of the internet's SSL-secured sites at the time, per Netcraft's contemporaneous scan. Juniper Networks' ScreenOS backdoor (CVE-2015-7755), found in December 2015, stemmed from a modified Dual_EC_DRBG random number generator that made VPN traffic decryptable by anyone who knew the injected constant — a textbook CWE-331 insufficient-randomness failure. The 2018 Marriott/Starwood breach exposed 383 million guest records, including 5.25 million unencrypted passport numbers sitting alongside encrypted payment card data whose encryption keys may have also been accessed, illustrating that partial encryption coverage still leaves a breach on the table. And the 2012 LinkedIn incident bears repeating: 6.5 million unsalted SHA-1 password hashes leaked that year, and a second, larger dataset of 117 million credentials from the same breach surfaced for sale in 2016 — four years after the original disclosure, because the failure was in the hashing scheme itself, not a patchable bug.
How Do Cryptographic Failures Differ From Broken Access Control or Injection?
Cryptographic failures are distinct because they fail closed on the wrong layer — access control and injection flaws let an attacker reach data they shouldn't, while cryptographic failures mean the data was never actually protected even when access controls worked correctly. A SQL injection flaw (A03:2021) lets an attacker query a database directly; a cryptographic failure means that even without injection, the data an attacker steals through a misconfigured S3 bucket or an intercepted network request is either plaintext or trivially reversible. This is why OWASP scores Cryptographic Failures with a high average impact rating (6.81 out of 10 in the 2021 data) despite requiring, in many cases, no direct exploitation of application logic — an attacker who gains any read access to a database, a backup file, or network traffic inherits the full value of the data if encryption was weak or absent. It also means cryptographic failures often aren't caught by traditional dynamic scanning (DAST), which tests application behavior rather than inspecting how data is stored or transmitted at rest — they require code-level and configuration-level review.
How Can Teams Detect and Fix Cryptographic Failures?
Detection requires static analysis that flags specific CWE patterns — hardcoded secrets, deprecated algorithm calls (MD5, SHA-1, DES, RC4, ECB mode), and missing TLS enforcement — combined with dependency scanning, since many cryptographic failures live in third-party libraries rather than first-party code. NIST's guidance in SP 800-131A deprecated 1024-bit RSA and SHA-1 for digital signatures as of 2013 and set 2015 as the cutoff for federal systems to stop accepting them, giving teams a concrete deadline to audit against. The fix pattern is consistent across cases: replace MD5/SHA-1 password hashing with bcrypt, scrypt, or Argon2id (Argon2id won the 2015 Password Hashing Competition and is now OWASP's recommended default); replace ECB-mode ciphers with AES-256-GCM; enforce TLS 1.2 or higher everywhere, including internal service-to-service traffic; and move key storage out of source code and environment variables into a dedicated KMS or HSM with defined rotation intervals. Classifying data before encrypting it also matters — PCI DSS 4.0, effective March 2024, requires documented data retention and disposal policies specifically because unencrypted data that should have been deleted is a recurring root cause in breach postmortems.
How Safeguard Helps
Safeguard identifies cryptographic failures across code, dependencies, and infrastructure configuration, then uses reachability analysis to determine whether a vulnerable crypto library or deprecated algorithm call is actually invoked in a code path attackers can reach — cutting through the noise of theoretical findings that never execute in production. Griffin AI, Safeguard's reasoning engine, correlates hardcoded secrets, weak cipher usage, and TLS misconfigurations against real traffic and deployment context to prioritize which cryptographic findings carry actual breach risk versus which are dormant. Safeguard generates and ingests SBOMs to track exactly which components introduce weak or deprecated cryptographic primitives across your software supply chain, and it opens auto-fix pull requests that upgrade vulnerable dependencies or swap deprecated algorithm calls for modern equivalents, so remediation ships in a normal code review rather than a separate security ticket queue.