Cryptographic Failures
detect, prioritise, remediate
Cryptographic failures (OWASP A02:2021) is the parent category for every situation in which an application either does not apply cryptography where it is required or applies it badly enough that the protection is illusory. It covers missing encryption in transit, missing encryption at rest, broken or deprecated algorithms, weak key sizes, ECB-mode block ciphers, predictable initialisation vectors, hardcoded keys, exposed signing material, insecure randomness used as a security primitive, broken certificate validation, missing integrity protection, and key-management failures across the production stack.
No credit card required. Free plan available forever.
What are cryptographic failures?
Cryptographic failures is the OWASP Top 10 category that covers every situation in which an application either fails to apply cryptography where it is required or applies it badly enough that the protection is illusory. OWASP renamed and reframed the category as A02:2021 (it was previously A03:2017 Sensitive Data Exposure) to push the discussion upstream from the symptom (data leaks) to the root cause (the cryptographic control did not exist, was wrongly chosen, was wrongly configured, or was wrongly operated). The canonical parent CWE is CWE-310 (Cryptographic Issues), with the OWASP A02 mapping spanning CWE-311 (missing encryption of sensitive data), CWE-319 (cleartext transmission), CWE-326 (inadequate encryption strength), CWE-327 (broken or risky cryptographic algorithm), CWE-328 (use of weak hash), CWE-330 (insecure randomness), CWE-331 (insufficient entropy), CWE-347 (improper verification of cryptographic signature), CWE-759 (use of one-way hash without a salt), CWE-915 (improper restriction of writable attributes), and CWE-916 (use of password hash with insufficient computational effort).
The category is a parent, not a single bug. A finding falls inside A02:2021 when sensitive data is sent or stored without encryption, when the algorithm chosen is deprecated (MD5, SHA1, DES, 3DES, RC4), when the algorithm is correct but the mode is broken (AES in ECB mode), when initialisation vectors are predictable or reused, when key sizes are below the modern threshold for the algorithm, when keys are hardcoded in source code or shipped in configuration files, when TLS allows downgrade to deprecated versions, when certificates are self-signed in production or missing chain validation, when password hashes use generic SHA without per-account salts or use insufficient work factor, when random numbers used as session tokens or password-reset tokens come from a non-cryptographic source, when signature verification is wrongly implemented, or when key custody, rotation, and revocation are not operated as a structured discipline.
A02:2021 is mechanistically broader than the per-finding entries it produces. The category is the root, and the entries you usually see on an engagement record are the specific findings underneath it: weak cryptography for the algorithm and mode choices, TLS and SSL misconfiguration for the transport layer, sensitive data exposure for the disclosure symptoms, insecure randomness for the RNG choices, and JWT vulnerabilities for token signing failures. SecPortal records both shapes on the engagement record through external scanning, authenticated scanning, and code scanning, with the broader programme work landing through findings management so the cryptographic backlog and the per-finding result share one canonical record.
Where cryptographic failures live in the stack
A02 reaches across every layer of a production system, and a programme that scans only one layer surfaces only one slice of the category. The six layers below carry distinct cryptographic decisions, each with its own scan window, advisory source, and remediation pattern.
Data in transit
TLS protocol versions and ciphers on every internet-facing endpoint, internal service-to-service mTLS, mail transport TLS (SMTP STARTTLS, MTA-STS), database connection strings, message-broker links, and outbound API calls. A single endpoint accepting TLS 1.0 or null ciphers can hold the rest of the perimeter to a weaker line.
Data at rest
Disk encryption at the volume, database, object store, cache, queue, backup, log archive, and snapshot layers. A02 includes the cases where data is encrypted on one layer (the volume) but not on the layers above it that hold the same content (the database column, the snapshot, the backup).
Key custody and rotation
Where the master keys, data-encryption keys, signing keys, and OAuth client secrets live; who can read them; how often they rotate; how revocation propagates after a compromise. Keys in source code, in environment variables exposed by an SSRF, in container images, or in unrotated KMS slots all live here.
Algorithm and mode choice
MD5, SHA1, DES, 3DES, and RC4 should no longer be used as security primitives; AES-ECB leaks plaintext structure; CBC without integrity protection enables padding oracles; static or reused IVs in CTR or GCM modes break confidentiality; RSA below 2048 bits or ECC below P-256 falls short of the modern threshold.
Identity and signature material
JWT signing algorithms (the none-algorithm bypass, the HMAC-with-RSA-key confusion, weak HMAC secrets), session-token entropy, password-reset-token entropy, password hashing work factor (bcrypt, scrypt, Argon2 with sufficient cost), and signature verification correctness on every inbound signed payload.
Randomness as a security primitive
Session tokens, password-reset tokens, API keys, CSRF tokens, and nonces drawn from a non-cryptographic RNG (Math.random, java.util.Random, std::rand) are predictable enough to enumerate. Cryptographic randomness needs a documented entropy source (urandom, getrandom, CNG, SecureRandom) on every security-sensitive value.
How A02 surfaces in production
OWASP names A02 as a category because the same risk shape arrives through several distinct failure modes. The four patterns below are the most common entry points for an A02 finding on an enterprise engagement record.
Missing encryption
Sensitive data travels or sits in cleartext where encryption was expected. An internal API call goes over plain HTTP, a database column holds PII unencrypted, a backup tape ships unencrypted to offsite storage, or a log archive captures sensitive request bodies. The cryptographic control was never applied.
Wrong algorithm choice
Encryption is applied but the chosen algorithm or mode does not deliver the security guarantee. MD5 or SHA1 used for password hashing or for signature verification, AES in ECB mode for structured plaintext, RSA at 1024 bits, JWTs accepting the none algorithm. The data looks protected and is not.
Wrong configuration
The algorithm is appropriate but the configuration weakens it. TLS allows downgrade to deprecated versions, certificates skip chain validation, password hashes use insufficient work factor, GCM mode reuses an IV across messages, signing keys are reused for both authentication and encryption. The control is in place and is operationally weakened.
Key management failure
The cryptographic primitives are correct but key custody breaks the chain. Hardcoded keys in source code, keys shipped in container images, environment variables exposed through SSRF, signing keys reused across environments, KMS keys never rotated, or revocation that does not propagate after a credential leak. The system is cryptographically sound and operationally compromised.
Common causes
No data-classification baseline
The team cannot answer which fields, columns, files, and logs hold sensitive data, so the encryption-required decision is made one feature at a time rather than against a documented baseline. New data flows ship without the encryption requirement because nobody enumerated the classification first.
No central cryptographic standard
Each service picks its own algorithms, modes, key sizes, IV strategies, and hashing functions because no organisation-wide standard exists. The result is a portfolio of inconsistent choices, some sound and some not, with no single artefact the audit reads.
Key custody is unowned
Application teams generate and store their own keys because the central key management service is hard to use, the documentation is sparse, or the ownership is unclear. Keys end up in environment variables, container images, source control, and shared password managers rather than in a managed vault.
Library defaults inherited unchecked
The cryptographic primitives come from a framework default rather than a deliberate choice. The framework default may have been appropriate when the framework version was new and may now be obsolete. Library upgrades silently change the default and the application still runs on the old call sites.
TLS configuration drift
The perimeter TLS configuration was reviewed at launch and never revisited. Cipher suites that were modern at launch became weak, protocol versions that were acceptable were deprecated, and the configuration kept accepting them because nobody scheduled the periodic review.
No rotation discipline
Keys, certificates, signing material, and OAuth client secrets sit in place for years because no one owns the rotation calendar. When a credential leak surfaces, the response requires a multi-team excavation to find every place the leaked material was trusted from.
How to detect it
Detection is layered. Automated scanning surfaces the symptoms a tool can see (a weak TLS cipher, a deprecated hash in source, a JWT signed with the wrong algorithm), and design-stage review surfaces the gaps a scanner cannot see (a missing encryption requirement, a key custody story that nobody owns). A defensible A02 detection posture runs both halves and lands findings on a record that distinguishes a per-endpoint cryptographic finding from a programme-level governance gap.
Automated and tooling signals
- SecPortal external scanning runs the SSL Checker module across the verified perimeter for TLS protocol versions, cipher suites, certificate validity and chain trust, HSTS posture, OCSP stapling, and downgrade exposure on every external host inside the engagement scope.
- Authenticated scanning probes JWT signing-algorithm acceptance (the none-algorithm bypass, the RS256-to-HS256 key confusion, weak HMAC secrets), cookie security attributes, and cleartext sensitive-data transmission across logged-in workflows.
- Code scanning executes Semgrep rule packs against connected repositories for hardcoded keys, deprecated hashing algorithms (MD5, SHA1), ECB-mode AES, predictable initialisation vectors, weak random number generators used as security primitives (Math.random, java.util.Random, std::rand on token paths), missing certificate validation on outbound clients, and password-hash patterns that lack salting or work-factor configuration.
- Findings management captures CWE-310, CWE-311, CWE-319, CWE-326, CWE-327, CWE-330, the affected component, the cryptographic primitive at fault, and a CVSS 3.1 vector that reflects the worst plausible exploitation path the failure exposes for the affected asset.
Programme-stage review
- Maintain a data-classification baseline that names every field, column, file, message, and log that holds sensitive content. Without the baseline, the encryption-required decision is made one feature at a time rather than against a documented requirement.
- Publish a cryptographic standard that names approved algorithms, modes, key sizes, hashing functions, work factors, randomness sources, and TLS configurations for every layer of the stack. Tie the standard to OWASP ASVS V6 Stored Cryptography, V9 Communications, and V11 Business Logic, and to NIST SP 800-175B and SP 800-131A approved-algorithm guidance.
- Own a key management lifecycle (generation, distribution, custody, rotation, revocation, destruction) with a named owner, a documented rotation cadence, and a tested revocation runbook. Pair the lifecycle with the cryptographic standard so the audit reads one coherent story.
- Run a periodic cryptographic posture review (annually at minimum, quarterly for regulated estates) that walks the data classification, the algorithm standard, the key management lifecycle, the TLS configuration baseline, and the inventory of cryptographic libraries in use. Findings from the review land on the engagement record alongside scanner findings.
How to fix it
Establish the data-classification baseline first
Enumerate every field, column, file, queue, log, backup, and snapshot that holds sensitive content. Mark each one with the classification (public, internal, confidential, regulated) and the required protection (none, integrity, encryption in transit, encryption at rest, both, with key custody requirements). The classification is the input the encryption decisions key off; without it, the decision is improvised per feature.
Publish a cryptographic standard the portfolio operates against
Pick approved algorithms, modes, key sizes, hash functions, password-hash work factors, randomness sources, and TLS configurations. Document why each was chosen and which standard backs the choice (OWASP ASVS V6, V9, V11; NIST SP 800-175B; SP 800-131A; FIPS 140-3 if regulated). The standard reads as a single artefact and is the input every architecture review checks against.
Replace deprecated primitives on a scheduled cadence
MD5 and SHA1 should no longer be used as security primitives; DES, 3DES, and RC4 should be retired; SSLv2, SSLv3, TLS 1.0, and TLS 1.1 should be off; password hashes should use bcrypt, scrypt, or Argon2 with a calibrated work factor rather than generic SHA. Treat the migration as a scheduled programme, not an emergency response to the next finding.
Centralise key custody through a managed vault or KMS
Store master keys, data-encryption keys, signing keys, and OAuth client secrets in a managed vault or KMS rather than in source code, environment variables, container images, or shared password managers. Scope access through the vault permission model, audit every retrieval, and rotate on a documented cadence so the revocation story works on the day it is needed.
Configure TLS to the modern baseline and re-verify on a schedule
Disable TLS 1.0 and 1.1, require TLS 1.2 minimum, prefer TLS 1.3, allow only modern cipher suites, enable HSTS with preload, configure OCSP stapling, and enforce certificate chain validation on outbound clients. Run the external SSL Checker scan on a continuous monitoring schedule so drift surfaces on the engagement record before the next audit cycle.
Use cryptographic randomness for every security-sensitive value
Session tokens, password-reset tokens, API keys, CSRF tokens, and nonces draw from a cryptographic randomness source (urandom, getrandom, CNG, SecureRandom, crypto.randomBytes), never from a general-purpose RNG. Audit the source for each token-producing site rather than trusting framework defaults.
Verify closure with a follow-up scan against the changed component
A cryptographic finding moves to closed only when a fresh scan against the changed component (the new TLS configuration, the updated algorithm choice, the rotated key, the corrected JWT verification) confirms the failure is no longer present. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures.
How SecPortal records and tracks A02 findings
SecPortal is not a key management service, does not host an HSM, does not generate or rotate cryptographic material on your behalf, and does not federate against a vault. It is the workspace where every A02 finding lands on the engagement record alongside source-level findings, external attack-surface findings, and authenticated DAST findings so severity, ownership, evidence, fix, and retest stay on one canonical record per service. The flow for an A02 finding looks like this on the platform.
Run external scanning across the verified perimeter
External scanning includes the SSL Checker module that audits TLS protocol versions, cipher suites, certificate validity, HSTS posture, and downgrade exposure across every verified host inside the engagement. Findings land on the engagement record with the scanner module, the affected host, and the evidence captured.
Run authenticated scanning for cryptographic surfaces behind login
Authenticated scanning probes JWT signing-algorithm acceptance, cookie attributes, and cleartext sensitive-data transmission inside logged-in workflows. Encrypted credential storage holds the cookie, bearer, basic auth, or form login material so the scan covers post-login behaviour without exposing credentials.
Run code scanning across connected repositories
Code scanning executes Semgrep against connected GitHub, GitLab, and Bitbucket repositories under OAuth for hardcoded keys, deprecated hashes, ECB-mode AES, predictable IVs, weak RNG sources on token paths, and missing certificate validation on outbound clients. The findings carry the file path, line number, and matched rule on the engagement record.
Record findings with CWE-310 and the OWASP A02 mapping
Findings management captures the OWASP A02:2021 category, the matching CWE family, the cryptographic primitive at fault, the affected asset, the evidence, and a CVSS 3.1 vector calibrated for the asset tier the failure runs in rather than the generic base score.
Run continuous monitoring on a schedule
Continuous monitoring runs the SSL Checker, the authenticated scan, and the code scan on daily, weekly, biweekly, or monthly cadences so configuration drift, new deprecations, and library upgrades surface on the canonical record without anyone re-triggering a manual scan.
Map findings against multi-framework compliance
Compliance tracking maps A02 findings against PCI DSS Requirements 3 and 4, ISO 27001 Annex A.8.24 use of cryptography and A.8.20 networks security, SOC 2 CC6.1 logical access and CC6.7 transmission and disposal, NIST SP 800-53 SC family system and communications protection, NIST SP 800-171 access control and transmission protection, HIPAA Security Rule encryption specifications, GDPR Article 32 security of processing, and OWASP ASVS chapters V6 V9 and V11 in parallel.
Capture cryptographic exceptions on the finding record
When a cryptographic finding cannot be remediated immediately (a legacy integration, a third-party dependency, a regulated workflow with a longer migration path), the exception lives on the finding through the override pattern with named owner, compensating controls, residual-risk rationale, review cadence, and expiry rather than in a meeting note.
Retest against the changed component through the lifecycle
The retesting workflow pairs the retest to the original finding so closure means the SSL scan, the authenticated scan, or the code scan no longer reports the cryptographic failure on the changed component. The verified_at and resolved_at timestamps preserve the audit chain of when the change shipped and who confirmed it.
Generate evidence packs through AI report generation
AI report generation turns the A02 backlog and closure cadence into an exported report aimed at engineering leadership, audit, or board reporting without rebuilding the narrative from spreadsheets each cycle. The report cites the underlying findings rather than fabricating numbers.
What SecPortal does not do
Honesty on capability matters when the topic is enterprise cryptography. SecPortal does not act as a key management service, does not host a hardware security module, does not federate against AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault, or any enterprise vault, does not generate or rotate cryptographic material on your behalf, does not parse FIPS validation certificates, does not maintain an algorithm-deprecation calendar inside the workspace, does not run a continuous CT-log monitor for unauthorised certificates issued against your domains, and does not integrate with Jira, ServiceNow, Slack, SIEM, SOAR, or any ticket system through a packaged API surface. Programmes that need real-time KMS-policy reconciliation, HSM-backed signing operations, post-quantum-cryptography migration tooling, or CT-log subscription typically run a separate worker against those upstream feeds and land the resulting findings on the engagement record through bulk finding import. The platform value is the consolidated record where every A02 finding (whether it came from native external scanning, authenticated scanning, code scanning, bulk import from an outside crypto-audit tool, or a manual finding entry against a key management gap) lives alongside the rest of the security backlog with the same lifecycle, the same role-based access control, the same activity log, and the same evidence trail.
Related vulnerabilities and recommended reading
A02 is the parent category for a cluster of more specific findings and the upstream concern for several SecPortal workflows. The pages below cover the per-finding shapes A02 produces, the frameworks that map control evidence against cryptographic posture, and the programme workflows that hold the A02 backlog across detect, triage, prioritise, route, remediate, and verify.
- Weak cryptography the per-finding shape that A02 most often produces in source code: deprecated hashes, ECB-mode AES, predictable IVs, and JWTs accepting the none algorithm.
- TLS and SSL misconfiguration the transport-layer A02 finding that the external SSL Checker scan reads against every endpoint on the verified perimeter.
- Sensitive data exposure the disclosure symptom that surfaces when an A02 cryptographic failure lets data reach a context the protection should have prevented.
- Insecure randomness the per-finding shape for non-cryptographic RNG use on session tokens, password-reset tokens, and CSRF tokens that A02 covers as a category.
- JWT vulnerabilities the signing and verification failures (none-algorithm bypass, RS256-to-HS256 confusion, weak HMAC secrets) that the authenticated scanner probes inside A02.
- Hardcoded secrets the key custody failure that code scanning surfaces when keys, signing material, or API credentials live in source rather than in a managed vault.
- Padding oracle attack the specific exploitation path that emerges when CBC-mode encryption is deployed without authenticated integrity protection across an attacker-observable surface.
- Insecure design (A04:2021) the upstream design-stage category that explains why an A02 failure exists when the threat model never named the cryptographic requirement.
- OWASP ASVS Chapter V6 Stored Cryptography, V9 Communications, and V11 Business Logic are the verification standard sections that read against the controls A02 expects.
- PCI DSS Requirements 3 (protect stored account data) and 4 (protect cardholder data with strong cryptography during transmission) are the payment-industry mapping for A02 evidence.
- ISO/IEC 27001 Annex A.8.24 use of cryptography and A.8.20 networks security are the ISO mapping for A02 control evidence in an ISMS-style audit.
- NIST SP 800-53 the SC system and communications protection control family is the federal mapping for A02 cryptographic posture evidence.
- OWASP Top 10 explained the parent reference that sets A02 alongside the rest of the Top 10 and the 2021 rename from Sensitive Data Exposure.
- CVSS scoring explained the severity-calibration reference for translating a raw A02 finding into an asset-tier-calibrated CVSS 3.1 vector.
- SDLC vulnerability handoff the workflow that hands cryptographic findings from AppSec to engineering owners without losing the trail back to the missing standard or the bypassed control.
- Control gap remediation workflow the programme-level workflow that carries cryptographic-control gaps from discovery to closure with framework mapping intact.
- Audit fieldwork evidence request fulfillment the workflow that turns A02 findings and the closure trail into the evidence pack the audit fieldwork request reads.
- SecPortal for AppSec teams the audience overview for the teams that own application-layer cryptographic standards across the portfolio.
- SecPortal for GRC and compliance teams the audience overview for the teams that read A02 evidence into PCI DSS, ISO 27001, SOC 2, NIST, HIPAA, and GDPR control packs.
Compliance impact
OWASP ASVS
V6 Stored Cryptography, V9 Communications
PCI DSS
Req. 3 Protect Stored Data, Req. 4 Encrypt in Transit
ISO/IEC 27001
A.8.24 Use of Cryptography, A.8.20 Networks Security
SOC 2
CC6.1 Logical Access, CC6.7 Transmission and Disposal
NIST 800-53
SC System and Communications Protection
NIST 800-171
3.13.8 Encrypt Sensitive Data in Transit
HIPAA
Security Rule Encryption Specifications
GDPR
Article 32 Security of Processing
Related features
Vulnerability scanning tools that map your attack surface
Test web apps behind the login
Find vulnerabilities before they ship
Vulnerability management software that tracks every finding
Monitor continuously catch regressions early
Compliance tracking without a full GRC platform
Verify fixes and track reopens on the same finding record
Encrypted credential storage for authenticated scans
Run A02 cryptographic findings on one engagement record
SecPortal pairs the SSL Checker scan, the authenticated JWT scan, and the code scanner against connected repositories with one findings record per cryptographic failure, with CVSS 3.1 severity, framework mapping, retest pairing, and an append-only activity log. Start scanning for free.
No credit card required. Free plan available forever.