How to Test Cryptographic Failures: OWASP A04 2026 Guide

Cryptographic failures happen when an application encrypts data incorrectly, transmits it in the clear, stores keys insecurely, or relies on broken algorithms — and testing for them means validating every point where sensitive data is encrypted, hashed, transmitted, or stored, not just scanning for outdated TLS versions. OWASP designates Cryptographic Failures as category A04 in its 2025 Top 10 revision, covering weak encryption schemes, improper certificate validation, insecure key storage, and predictable random number generation. A scanner will flag an expired certificate; it will not tell you that your session tokens are generated from a predictable seed or that your API stores card data encrypted with a key hardcoded in a config file.

TL;DR

• Testing cryptographic failures under OWASP A04:2025 requires manual review of TLS configuration, key management, hashing, and encryption-at-rest controls.
• Automated scanners catch outdated TLS versions but miss hardcoded keys, weak key derivation, and predictable randomness — the failures that lead to real breaches.
• PCI DSS Requirement 4, HIPAA's encryption safeguards, and SOC 2's confidentiality criteria all require documented evidence that cryptographic controls were tested, not just implemented.
• A manual penetration test in 2026 should validate cipher suite negotiation, certificate pinning, key rotation practices, and password hashing cost factors end to end.

Why This Matters

Cryptographic failures rarely show up as a single headline vulnerability. They surface as a chain: a weak key derivation function combined with a leaked API key combined with an unencrypted backup, and the result is a full data exposure. Regulators treat cryptography as a control category, which means auditors expect evidence that encryption was tested, not just enabled.

A PCI DSS penetration testing engagement that skips cryptographic validation will fail Requirement 4 review even if the network segmentation is sound. HIPAA's Security Rule expects encryption of electronic protected health information both at rest and in transit, and auditors ask for test evidence, not policy statements. Getting this wrong in 2026 costs more than a failed audit — it costs incident response time when a breach investigation reveals the encryption was misconfigured from the start.

How to Test for Cryptographic Failures Under OWASP A04:2025

Testing cryptographic failures is a structured process, not a single scan. The methodology below reflects how a manual penetration test should approach this category across web applications, APIs, and infrastructure.

1. Map every point where sensitive data is created, transmitted, or stored — authentication tokens, PII, payment data, API keys, session identifiers.
2. Enumerate the cryptographic algorithms and protocols in use through traffic capture, source code review, and configuration files.
3. Test transport-layer configuration for cipher suite strength, protocol version, and certificate validation behavior.
4. Test data-at-rest encryption for algorithm strength, key storage location, and access control around the encryption keys themselves.
5. Review key management practices — generation, rotation, storage, and revocation.
6. Validate password and secret hashing against current cost-factor and algorithm standards.
7. Assess randomness sources used for tokens, session IDs, and password reset links.
8. Document findings with reproduction steps and business impact, then verify remediation through retesting.

Transport layer

• What to Validate: TLS version, cipher suites, certificate chain, HSTS
• Common Tooling: Manual traffic capture, protocol analyzers

Data at rest

• What to Validate: Algorithm strength, key isolation from data
• Common Tooling: Source code review, configuration audit

Key management

• What to Validate: Generation, rotation, storage, access control
• Common Tooling: Manual review, cloud KMS audit

Hashing

• What to Validate: Algorithm, salt, cost factor
• Common Tooling: Manual code review, hash extraction testing

Randomness

• What to Validate: Entropy source, predictability
• Common Tooling: Manual statistical analysis, token capture

Transport Layer Testing

Transport-layer testing starts with confirming which TLS versions the application actually negotiates in production, not what the configuration file claims. Testers capture live traffic to verify cipher suite selection, check certificate validity and chain of trust, and confirm HTTP Strict Transport Security is enforced across every subdomain that handles session cookies.

Transport Layer Checklist

• TLS 1.2 or 1.3 enforced; older protocols disabled
• Weak cipher suites (RC4, export-grade, NULL ciphers) rejected
• Certificate chain validates without manual override
• HSTS header present with adequate max-age
• Mixed content and downgrade paths tested manually

Data-at-Rest Encryption Testing

Encryption at rest fails most often not because the algorithm is weak, but because the key sits next to the data it protects. Testers review whether database-level encryption, disk encryption, and application-level field encryption use keys stored in a separate, access-controlled location such as a cloud KMS or HSM.

Data-at-Rest Checklist

• AES-256 or equivalent used for sensitive fields
• Encryption keys stored outside the database or codebase
• Backups encrypted with the same rigor as production data
• Access to decryption keys logged and restricted
• Field-level encryption applied to PII and payment data specifically

Key Management Testing

Key management is where most cryptographic failures actually originate. A tester reviews how keys are generated (weak entropy sources produce predictable keys), where they are stored (hardcoded in source, committed to a repository, or sitting in an environment variable visible to every service), and whether rotation happens on a defined schedule or only after an incident.

Key Management Checklist

• Keys generated using a cryptographically secure random source
• No keys hardcoded in source code or config files committed to version control
• Key rotation policy defined and enforced, not ad hoc
• Access to key management systems requires separate authentication from application access
• Revocation process tested, not just documented

Hashing and Password Storage Testing

Password storage testing checks the hashing algorithm and the cost factor together — bcrypt or Argon2 with a cost factor set too low defeats the purpose of using a strong algorithm at all. Testers extract sample hashes (in an authorized test environment) and confirm salting is unique per record, not a single global salt.

Hashing Checklist

• bcrypt, scrypt, or Argon2 used instead of MD5 or unsalted SHA-1
• Cost factor tuned to current hardware, not a legacy default
• Unique salt per password, not a shared application-wide salt
• API keys and secrets hashed or encrypted, never stored in plaintext
• Password reset tokens expire and cannot be reused

Random Number Generation Testing

Predictable randomness quietly undermines session tokens, password reset links, and CSRF tokens even when the surrounding cryptography looks correct. Testers capture a sample of generated tokens and run statistical analysis to check for patterns tied to timestamps, sequential counters, or low-entropy seeds.

Common Cryptographic Failures and Their Business Impact

Deprecated TLS version accepted

• Root Cause: Legacy configuration never updated
• Business Impact: Man-in-the-middle exposure, failed PCI scan

Hardcoded encryption key

• Root Cause: Key embedded in source or config
• Business Impact: Full data exposure if source leaks

Weak password hashing

• Root Cause: MD5 or low cost-factor bcrypt
• Business Impact: Mass credential compromise after breach

Predictable session tokens

• Root Cause: Weak random number generator
• Business Impact: Session hijacking, account takeover

Unencrypted backups

• Root Cause: Encryption applied only to live database
• Business Impact: Data exposure through backup theft

Key stored with the data it protects

• Root Cause: No separation between data and KMS
• Business Impact: Single compromise exposes both

Compliance Mapping for Cryptographic Failures

Every major compliance framework treats cryptography as a testable control, and auditors in 2026 increasingly ask for evidence tied to specific requirement numbers rather than a general attestation.

PCI DSS

• Requirement: Requirement 4 (transmission), Requirement 3 (storage)
• What Assessors Check: Strong cryptography for cardholder data in transit and at rest
• Testing Implication: Manual TLS and key management testing required annually

HIPAA

• Requirement: Security Rule technical safeguards
• What Assessors Check: Encryption of ePHI at rest and in transit
• Testing Implication: Documented test evidence, not policy alone

SOC 2

• Requirement: Confidentiality and security criteria
• What Assessors Check: Encryption controls operating effectively
• Testing Implication: Testing evidence tied to a defined testing period

ISO 27001

• Requirement: Annex A cryptographic controls
• What Assessors Check: Key management policy and enforcement
• Testing Implication: Evidence-backed risk register entries

GDPR

• Requirement: Article 32 security of processing
• What Assessors Check: Encryption as a stated technical measure
• Testing Implication: Testing evidence supports data protection impact assessments

This category rarely stands alone during an audit. Findings here often connect to gaps identified during OWASP A01 broken access control testing, since weak encryption combined with broken authorization frequently produces the highest-severity chained findings in a penetration test report. It also overlaps with security misconfiguration testing, where default TLS settings and exposed configuration files are common root causes, and with software supply chain failures testing, since compromised dependencies frequently ship with hardcoded or weak cryptographic defaults.

Manual Testing vs Automated Scanning

Automated scanners are effective at flagging expired certificates, deprecated TLS versions, and known-weak cipher suites — configuration issues that exist in a signature database. They cannot determine whether a key is stored next to the data it encrypts, whether a password reset token is statistically predictable, or whether a development team hardcoded a key during a migration three years ago and never rotated it.

Manual testing closes that gap because it requires a tester to read source code, capture live traffic, and reason about how components interact. This is the same reasoning applied during an API penetration testing engagement, where token generation, key exchange, and encryption of payloads in transit require the same manual scrutiny as a full application test. A scanner reports what it recognizes; a tester finds what was never supposed to be there.

How AppSecure Tests for Cryptographic Failures

AppSecure's penetration testers approach cryptographic failures the way an attacker would — by chaining a weak point in key management to a misconfigured transport layer, then validating whether the combination produces exploitable access to sensitive data. Testing includes manual traffic analysis, source code review where scope allows, key storage audits, and statistical testing of token randomness, followed by retesting once remediation is applied.

This hacker-led approach reflects why AppSecure operates as an Agentic Penetration Testing Company — manual attack-path discovery finds the cryptographic weaknesses that automated tools report as passing.

Test your cryptographic controls

Get a manual penetration test that validates encryption, key management, and hashing end to end.

Talk to AppSecure

Related Questions on Cryptographic Failures Testing

Is TLS 1.2 still acceptable in 2026?

TLS 1.2 remains acceptable in 2026 when configured with strong cipher suites, but TLS 1.3 is the stronger default because it removes legacy negotiation paths that testers commonly exploit. Any configuration still permitting TLS 1.0 or 1.1 should be treated as a finding requiring immediate remediation.

What's the difference between encryption-in-transit and encryption-at-rest testing?

Encryption-in-transit testing validates how data moves between systems — TLS configuration, certificate handling, and API payload encryption. Encryption-at-rest testing validates how data sits in storage — database encryption, backup encryption, and where the decryption keys live relative to the data itself.

How often should cryptographic controls be retested?

Cryptographic controls should be retested at least annually and after any change to key management infrastructure, TLS configuration, or hashing libraries. Organizations under PCI DSS or handling regulated data typically align this cadence with their broader penetration testing schedule rather than treating it as a standalone exercise.

FAQ

What is OWASP A04:2025 Cryptographic Failures?

OWASP A04:2025 Cryptographic Failures covers weak encryption algorithms, improper key management, missing encryption in transit or at rest, and predictable randomness. It replaced the older cryptographic-failures classification with an expanded focus on key management and hashing practices.

How do you test for cryptographic failures manually?

Testing cryptographic failures manually means capturing live traffic to validate TLS configuration, reviewing source code and configuration for hardcoded keys, extracting hashes to confirm algorithm and cost-factor strength, and statistically testing token randomness. Automated scanners only catch a fraction of these checks.

What algorithms are considered weak in 2026?

MD5, SHA-1 for password hashing, DES, and RC4 are considered weak in 2026. AES-256 for symmetric encryption, RSA at 2048-bit minimum, and bcrypt or Argon2 for password hashing are the current accepted standards.

Does PCI DSS require penetration testing for cryptographic controls?

Yes, PCI DSS Requirement 4 requires strong cryptography for cardholder data in transit, and Requirement 3 covers data at rest. Assessors expect test evidence showing these controls were validated, not just implemented.

What is the difference between a vulnerability scanner and a penetration test for cryptography?

A vulnerability scanner flags known configuration issues like expired certificates or deprecated TLS versions. A penetration test manually reviews key storage, hashing implementation, and randomness sources that scanners cannot evaluate without source access and traffic analysis.

How does key management testing work?

Key management testing reviews how encryption keys are generated, where they are stored, whether they are separated from the data they protect, and whether rotation and revocation processes are enforced rather than documented only on paper.

Why do password hashing cost factors matter?

A hashing algorithm like bcrypt is only as strong as its cost factor. A cost factor set too low for current hardware allows attackers to brute-force extracted hashes far faster than the algorithm's design intended.

Can cryptographic failures lead to full account takeover?

Yes, predictable session tokens or password reset links caused by weak random number generation can allow an attacker to guess or forge valid tokens, leading directly to account takeover without needing the actual password.

One Last Thing

The most damaging cryptographic failures found during testing engagements are rarely the algorithm itself — they are the key sitting one folder away from the data it protects. Before the next audit cycle in 2026, confirm that whoever can read your encrypted database cannot also read the key that decrypts it; that single separation check catches more real exposure than a TLS version audit ever will.