Skip to main content
Commerce Security Authority

Cardholder Data Encryption Playbook

Get the playbook

AES or ECC? Pick the Right One for Every Payment Workload

Key-length, mode, and curve choices for data at rest, in transit, and key wrapping, each tied to what PCI DSS v4.0 accepts.

You encrypt the data. You still fail the assessment.

Encryption is present, so the control feels done. But PCI DSS v4.0 tests against a precise definition of strong cryptography, not a general concept, and assessors trace algorithm name, key length, mode of operation, and key management together. Teams that treat cryptography as an implementation detail rather than a control discipline routinely produce findings at assessment time. If you cannot show your AES key length, cipher mode, and ECC curve choices are defensible, you carry compensating controls or remediation commitments that delay your Report on Compliance.

37-Page Operational Playbook

Get the encryption playbook

Written for practitioners who own Requirement 3 controls. Get defensible AES key lengths, cipher modes, and ECC curve choices for every payment workload, with the NIST rationale QSAs expect documented.
  • Algorithm acceptability vs. the 112-bit threshold
  • AES-128 vs. AES-256, GCM/CBC/XTS mode selection
  • NIST-approved ECC curves and what to avoid
  • Key-length justification for Requirements 3.6 and 3.7
The Cardholder Data Encryption Playbook

Download the playbook

Written for practitioners who own Requirement 3 controls.

Verifying you're human...

The thresholds your choices are measured against

Acceptability is not determined by algorithm name alone. These are the numbers assessors test against.

112-bit
Minimum security strength PCI DSS v4.0 requires for strong cryptography, tied to NIST's framework.
AES-128
Minimum acceptable symmetric key length; AES-256 is the defensible choice for new deployments.
RSA-2048
Provides only 112-bit strength, acceptable through 2030 but not beyond; RSA-1024 is disallowed.
P-256
128-bit ECC baseline for most TLS and P2PE deployments, broadly FIPS 140-3 validated.

The problem is rarely the cipher. It is the rationale.

PCI DSS v4.0 does not publish a closed list of approved algorithms. It defers to NIST, so acceptability is not determined by algorithm name alone. A repeated GCM nonce, a CBC mode with no MAC, an RSA-1024 certificate on an internal API, a key stored in the same schema as the data it protects, all pass a casual glance and fail a QSA. This playbook resolves the ambiguity by mapping each choice to the specific requirement and the authoritative reference behind it.

What is inside the playbook

Algorithm acceptability table: AES, RSA, and ECC measured against the 112-bit security-strength threshold
AES-128 vs. AES-256 compared by NIST strength, performance overhead, and quantum posture
Mode selection: GCM for transit and API payloads, CBC with a separate MAC for legacy, XTS for storage
ECC vs. RSA equivalence table and the approved NIST prime curves P-256, P-384, and P-521
Curves to avoid in PCI scope: secp256k1, Brainpool, and the Curve25519 FIPS-validation caveats
How to document key-length justification for Requirements 3.6 and 3.7

What you can do once you have read it

Justify every algorithm to an assessor

Point to a specific PCI DSS v4.0 sub-requirement and NIST reference for each key length, mode, and curve you deploy.

Match the primitive to the workload

Choose confidently for data at rest, data in transit, and the key-wrapping layer instead of applying one setting everywhere.

See findings before the QSA does

Recognize the recurring weak-cryptography and key-management finding patterns and close them ahead of fieldwork.

Walk into assessment ready

Apply the assessment-readiness checklist and remediation priority tiers to triage gaps and organize your evidence bundle.

Grounded in the standards assessors actually cite

Maps recommendations to PCI DSS v4.0 Requirements 3.5, 3.6, 3.7, 4.2.1, 10, 11.5, and 12.3.3 by sub-requirement
Built on NIST SP 800-57 Part 1 Rev. 5, SP 800-131A Rev. 2, SP 800-38F, and SP 800-133
References FIPS 197 for AES, FIPS 186-5 and SP 800-186 for curves, and FIPS 140-2/140-3 CMVP validation
Covers the 2024 NIST post-quantum standards: FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA)
Includes a recommended cryptoperiod table and a lifecycle evidence-artifact table by stage

Questions practitioners ask

No. It is an operational playbook for educational and informational purposes. It is not legal, regulatory, audit, or compliance advice, and you should still consult qualified counsel and your QSA on your specific obligations.

The Cardholder Data Encryption Playbook

Move from control intent to auditable encryption.

Written for practitioners who own Requirement 3 controls. Get the AES, ECC, and mode choices, each tied to what PCI DSS v4.0 accepts.