OWASP Top 10 is the most widely used awareness standard for web application security, built to help product teams prioritize the risks that consistently show up across real applications and real incidents. In OWASP Top 10:2025, A04 Cryptographic Failures sits at rank 4 and focuses on what usually goes wrong in practice: missing cryptography, weak cryptography, leaked keys, and implementation mistakes that turn "protected data" into exposed data.

OWASP's own dataset signals the scale of the problem: A04 maps to 32 CWEs and is associated with 1,665,348 total occurrences and 2,185 total CVEs, which is why this category keeps showing up in audits, breach postmortems, and compliance reviews. And when cryptography fails, the downstream impact is rarely "just privacy"; it often becomes monetizable fraud such as account takeover, account opening abuse, and bot driven credential stuffing because attackers can reuse what they stole across many systems.

Cryptographic Failures happen when an application does not correctly protect sensitive data during storage, processing, or transmission, even if "encryption exists somewhere" in the system. In many real incidents, the cryptography itself is not broken; the failure is that encryption is missing where it matters, protocols are misconfigured, keys are leaked, or insecure defaults remain in place. OWASP explicitly calls out failures related to the lack of cryptography, insufficiently strong cryptography, leaking cryptographic keys, and related errors.

A04 also includes practical protocol issues such as weak TLS, missing enforcement, invalid certificate validation, nonce misuse, insecure modes, and weak password hashing. This is why A04 is tightly tied to fraud: once an attacker steals sessions, tokens, or credentials through crypto mistakes, they can impersonate users and monetize access quickly.

Three of the most common Common Weakness Enumerations in this risk involved the use of a weak pseudo random number generator: CWE 327 Use of a Broken or Risky Cryptographic Algorithm, CWE 331 Insufficient Entropy, CWE 1241 Use of Predictable Algorithm in Random Number Generator, and CWE 338 Use of Cryptographically Weak Pseudo Random Number Generator (PRNG). OWASP's scoring table also illustrates the magnitude and breadth: A04 maps to 32 CWEs and is tied to over 1.6 million occurrences across the dataset.

Teams keep legacy hashes or ciphers because "it still works," then an attacker uses modern GPU cracking or downgrade paths to recover secrets. OWASP explicitly warns against deprecated hashes such as MD5 and SHA1 and insecure modes such as CBC. This cause is common in older codebases, internal tools, and forgotten subsystems, which is exactly where attackers look first.

Encryption is only as strong as the key lifecycle, and failures often happen in rotation, storage, reuse, or accidental exposure in repositories. OWASP highlights risks such as default keys, key reuse, missing rotation, and keys checked into source control. When keys leak, attackers do not need to break cryptography; they simply use your keys.

Some data is never encrypted at rest, or it is stored in reversible formats, or it is left accessible through backups and exports. OWASP stresses that teams must decide what requires encryption at rest and what requires extra protection beyond transport encryption. This shows up in exposed databases, analytics pipelines, debug dumps, and long lived data lakes.

Missing TLS enforcement, weak protocol support, and downgrade vulnerabilities let attackers intercept traffic, steal cookies, and hijack sessions. OWASP's example scenario explicitly describes HTTPS downgrade leading to stolen session cookies and account hijack. Even "mostly HTTPS" is not enough if the sensitive endpoints allow fallback or mixed content.

Crypto libraries are easy to misuse: wrong IV or nonce handling, insecure modes, unsafe padding, or weak certificate checks can destroy guarantees. OWASP calls out IV reuse, insecure modes such as ECB, missing authenticated encryption, and exploitable error messages such as padding oracle signals. These failures often pass code review because the code "looks encrypted," but the security properties are not actually satisfied.

Personal data covers any information related to an identified or identifiable natural person, including identifiers such as names, IDs, location data, and online identifiers. Non personal data, in contrast, does not relate to identifiable people or is not linkable to a specific individual in a meaningful way, which is why it usually has lower regulatory risk. The hard part is that many "technical" signals become personal data once they can be linked to a user or a household at scale.

Sensitive data (often called special category data in EU terms) is personal data that reveals highly sensitive attributes such as health, biometric identifiers, genetic data, racial or ethnic origin, political opinions, religious or philosophical beliefs, and trade union membership, plus sex life or sexual orientation. From a cryptographic failures perspective, this distinction matters because the expected controls and impact of exposure increase dramatically as you move from general personal data to sensitive data.

This variation appears when passwords or secrets are stored in plaintext, logged in readable form, or hashed using fast legacy algorithms that are cheap to crack. A high profile regulatory example is Meta's €91 million fine related to storing user passwords in plaintext, where the regulator cited failures under GDPR security obligations. A breach example is Freecycle, where reporting indicated exposure of user credentials including MD5 hashed passwords for more than 7 million users, illustrating how weak hashing decisions become a direct account takeover risk.

This variation appears when TLS is not enforced everywhere, weak protocols are still enabled, or security headers are missing, allowing attackers to intercept traffic and steal sessions. OWASP's scenario explicitly describes HTTPS downgrade to HTTP leading to stolen session cookies and account hijacking. Even though the web broadly moved toward HTTPS, Google's own reporting indicates HTTPS usage plateaued around the 95 to 99 percent range in Chrome, which implies that insecure holdouts and misconfigurations still exist and still get exploited.

This variation occurs when keys are hard coded, checked into repositories, copied into tickets, or stored alongside encrypted data, turning encryption into a façade. OWASP calls out risks such as default keys, key reuse, missing rotation, and keys checked into source repositories. A real magnitude signal is the scale of secret leakage in code ecosystems: GitGuardian reporting summarized by InfoQ notes nearly 23.8 million new hard coded secrets detected in public GitHub commits during 2024. In practice, once a key leaks, the attacker does not need to break encryption; they simply decrypt, sign, or impersonate using your own credentials.

This variation appears when session tokens, reset links, nonce values, or cryptographic keys are derived from predictable seeds, weak entropy sources, or non cryptographic random APIs. OWASP explicitly highlights that several common CWEs in A04 involve weak pseudo random number generation and insufficient entropy. The impact is severe because predictable randomness often compromises many accounts at once: if token generation is flawed, attackers can enumerate or guess valid tokens without any breach of storage.

This variation appears when teams keep MD5 or SHA1, rely on insecure padding, allow algorithm downgrade, or use encryption without integrity protection. OWASP explicitly warns to avoid deprecated functions and padding schemes, and it also emphasizes using authenticated encryption rather than only encryption. A04's mapped CWEs include issues such as cleartext transmission, hard coded keys, algorithm downgrade, insufficient computational effort in password hashes, and certificate chain trust problems, which shows how broad the surface is.

Freecycle reported a breach impacting over 7 million users, where exposed data included usernames, emails, and MD5 hashed passwords. Even when passwords are "hashed," using a legacy hash like MD5 increases the likelihood of cracking at scale, especially when users reuse passwords across services. This is exactly why A04 is not only a privacy concern: cracked credentials become a direct driver of account takeover, bot abuse, and fraud rings that test stolen passwords elsewhere.

Exactis, a marketing and data aggregation firm, was reported to have exposed a database of roughly 340 million records on a publicly accessible server, with highly detailed personal information. While this incident is often classified as exposure and misconfiguration, it is also a cryptographic failures lesson: when sensitive datasets are placed in publicly reachable storage, strong encryption at rest and strict key access boundaries can reduce what a finder can actually read.

In 2019, researchers reported that third party Facebook apps left hundreds of millions of records exposed on Amazon cloud infrastructure, including a dataset described as around 540 million records. The same reporting also noted plaintext password exposure for a smaller app dataset, showing that "partner ecosystems" can carry cryptographic failures into your user base even when your core platform is hardened.

Equifax disclosed a 2017 breach impacting around 148 million people, exposing highly sensitive identity data. Reporting also describes how an expired encryption certificate on a monitoring tool contributed to detection failures, illustrating how crypto and certificate hygiene impacts visibility and response, not only confidentiality. The lesson is that cryptography must be treated as an operational lifecycle, not only a library choice.

Heartland's breach analysis describes an SQL injection driven compromise that enabled attackers to access and exfiltrate payment card data, showing how weaknesses can move from application flaws to data exposure at massive scale. In payment systems, the cryptographic baseline is not negotiable: card data must be protected by strong storage and transmission controls, and compliance expectations are explicit about encryption and key management.

GDPR makes cryptographic failures a business risk because Article 32 explicitly lists encryption and pseudonymisation as examples of appropriate technical measures, alongside continuous evaluation of security controls. A concrete cryptography related enforcement example is the Irish Data Protection Commission's decision fining Meta €91 million, citing failures including the storage of user passwords in plaintext and lack of appropriate measures under GDPR security obligations. Another recent enforcement example is the French CNIL sanctioning FREE MOBILE and FREE with €27 million and €15 million fines after a breach that exposed subscriber data affecting 24 million contracts, including IBANs, because security measures were inadequate.

PCI DSS similarly turns A04 into a measurable obligation for any environment handling card data. The PCI DSS quick reference guide states that cardholder data should not be stored unless necessary, that stored PAN must be rendered unreadable, and that transmission of cardholder data over open public networks must be encrypted using strong cryptography and protocols such as TLS. PCI also emphasizes key protection and key management procedures, which directly maps to A04's focus on key leakage and key lifecycle failures.

Start by classifying data flows, storage, and logs so you know exactly which fields require encryption, masking, strict retention, and extra monitoring. It is highly effective because it prevents "we forgot that field" incidents and makes compliance discussions evidence based. Pros: it reduces scope, lowers cost, and improves auditability. Cons: it requires upfront effort and ongoing maintenance when data models change.

Use HSMs or managed key services so private keys are not sitting in application containers, developer laptops, or shared file systems. It is extremely effective at reducing key theft and enforcing lifecycle controls such as rotation and access policy. Pros: hardened key isolation and auditable access. Cons: added cost, integration work, and the need to design for availability.

Prefer battle tested libraries and managed platform capabilities over custom cryptography, because most catastrophic crypto failures come from subtle misuse. Pros: fewer bespoke bugs and easier patching. Cons: developers still need correct usage patterns, which is why code review and security testing remain essential.

If you do not retain data, it cannot be stolen later, which is why OWASP recommends discarding data quickly or using compliant tokenization or truncation where feasible. Pros: lower liability and smaller breach impact. Cons: product teams must ensure business workflows still work.

Encryption at rest must cover primary databases, file stores, object storage, analytics exports, and backup snapshots, not only the "main table." Pros: mitigates many storage exposure incidents. Cons: if keys are mishandled or stored alongside data, encryption becomes theater.

OWASP calls out weak keys, default keys, key reuse, missing rotation, and keys checked into repositories as recurring failure modes. Pros: reduces systemic compromise risk. Cons: requires discipline and tooling, and rotation can break systems if key identifiers and versioning are not designed well.

OWASP recommends enforcing TLS 1.2 or above, using forward secrecy ciphers, dropping CBC ciphers, and enforcing HTTPS with HSTS. Pros: strong baseline for confidentiality and integrity in transit. Cons: legacy client compatibility can be painful.

OWASP explicitly advises preparing for post quantum cryptography so high risk systems are safe no later than end of 2030, and it points to ENISA and NIST references. Pros: future proofing for regulated and high value data. Cons: the ecosystem is still evolving, and teams must plan staged transitions and compatibility.

OWASP warns that caching sensitive responses in CDNs, web servers, or application caches such as Redis can accidentally create a second data store outside your usual access controls. Pros: reduces unexpected exposure paths. Cons: performance tradeoffs require careful tuning.

Authenticated encryption ensures confidentiality and integrity, meaning attackers cannot silently tamper with ciphertext. OWASP explicitly recommends authenticated encryption instead of just encryption. Pros: stronger guarantees with fewer edge case exploits. Cons: requires careful handling of nonces and keys.

SAST helps you catch cryptographic failures at code level, such as hard coded keys, use of deprecated algorithms, weak randomness APIs, and unsafe protocol usage patterns. It is most effective when integrated into CI so every pull request gets feedback before it reaches production, and when rules are tuned to your language and frameworks. For A04, SAST should be treated as a guardrail, not a one time scan, because crypto regressions often happen during "small refactors" and dependency upgrades.

DAST validates crypto controls from the outside, such as TLS configuration, HSTS presence, cookie flags, downgrade resistance, and exposure of sensitive data in responses. It is most effective when run against staging and pre production environments that mirror real edge configs, because many A04 issues live in CDNs, load balancers, and reverse proxies rather than application code. For Cryptographic Failures, DAST is a practical way to confirm that encryption is actually enforced, that legacy endpoints are not leaking, and that sensitive responses are not cacheable when they should not be.

Modern teams hear "encrypt sensitive data at rest and in transit" and feel relief, because encryption feels like the final boss of security. OWASP itself pushes encryption as a baseline, and compliance programs reinforce that expectation, so product owners naturally internalize a simple belief: "If it is encrypted, we are safe."

The problem is that attackers rarely need to break encryption to win; they steal sessions, steal keys, abuse misconfigurations, and exploit human behavior around authentication and recovery paths. OWASP's own A04 scenarios show that a single downgrade or weak hashing choice can turn "protected data" into "reusable credentials," which directly converts into account takeover and fraud. And the industry is already shifting toward crypto agility because post quantum migration is coming and long lived data is already being harvested, meaning encryption is a moving target, not a checkbox.

Device fingerprinting closes a critical gap that cryptography cannot cover: identity continuity. Even with perfect encryption, a stolen cookie or a replayed token can create a "valid looking" session, and systems that only validate credentials can miss the fraud until money moves. CrossClassify's device fingerprint intelligence is designed around detecting devices, revealing fraud, and protecting accounts through continuous device monitoring, which makes it a strong compensating control for A04's realities around session theft and key misuse.

When you bind sessions and high risk actions to stable device signals, you gain the ability to detect sudden device changes, suspicious emulation, and abnormal reuse patterns that commonly appear after cryptographic failures. Start from https://www.crossclassify.com/solutions/device-fingerprint/ where the platform positions device intelligence as a continuous monitoring layer.

Behavioral biometrics solves another blind spot of encryption: a session can be valid while the user is not the same human. When attackers use stolen credentials, remote control tools, or bot automation, encryption still works perfectly, yet the account is compromised. CrossClassify describes continuous behavioral biometrics authentication across steps beyond login, combining signals such as keystroke dynamics, pointer trajectory, touch pressure, scroll rhythm, and session context, and explicitly ties those behaviors with device fingerprinting for stronger identity binding.

To understand how this becomes a concrete fraud control, read https://www.crossclassify.com/solutions/behavioral-biometrics/ and focus on the parts about continuous monitoring and risk based authentication decisions.

Cryptographic Failures are a data protection risk, but they are also an identity risk, because attackers monetize by impersonating users, not only by reading databases. OWASP explicitly describes scenarios where weak transport protection leads to stolen session cookies and account hijacking, showing that crypto failures directly create identity compromise. This is why continuous monitoring of device fingerprints and behavioral biometrics is not "nice to have"; it is the practical layer that catches fraud when cryptography and compliance controls are bypassed through real world attack paths.

When you treat A04 as both a cryptography engineering problem and a fraud operations problem, you naturally end up with layered defenses: encrypt and manage keys correctly, then continuously validate identity continuity during real usage.

OWASP A04 Cryptographic Failures remains a top risk because the failure modes are operational and human, not theoretical cryptography math. Encryption at rest and in transit is mandatory, but real incidents show that weak hashing, leaked keys, misconfigured TLS, and ecosystem exposures still convert into account takeover and fraud, even in teams that believe they "did encryption."

That is why modern prevention must combine strong cryptography and key management with continuous monitoring that can detect identity breaks when sessions appear valid. CrossClassify addresses this gap by pairing device intelligence with behavioral biometrics to keep trust anchored across devices, networks, and user actions. If you want a practical path forward, use the cryptography checklist to close A04 root causes, then use continuous monitoring to reduce fraud outcomes when attackers inevitably find a weak link.