PCI DSS:
Cryptography and Key Management for Cardholder Data
| Region | International |
| Applicability | Merchants: any entity that stores, processes, or transmits cardholder data, scoped by merchant level and Self-Assessment Questionnaire (SAQ) type Service Providers: payment processors, gateways, and hosting providers handling cardholder data on a merchant’s behalf QSAs and ASVs: Qualified Security Assessors and Approved Scanning Vendors performing Reports on Compliance and vulnerability scans |
| Relevant sections | Requirement 3: Protect stored account data Requirement 4: Protect cardholder data with strong cryptography during transmission Requirement 8: Identify users and authenticate access to system components Requirement 12.3.3: Cryptographic cipher suite and protocol inventory |
Overview
PCI DSS v4.0.1, published in June 2024 as a maintenance release of v4.0 (March 2022), is the payment card industry’s mandatory security standard. It introduced 64 new or updated requirements over the previous version, 51 of which were “future-dated”: treated as best practice until they became fully mandatory on March 31, 2025.
That transition window has closed. Every PCI DSS assessment conducted since March 31, 2025, scores against the full requirement set, including mandatory MFA for all access to the cardholder data environment (CDE), quarterly external vulnerability scans even for fully-outsourced SAQ A merchants, and a documented inventory of the cryptographic cipher suites and protocols in use.
Why it matters
PCI DSS is contractual rather than statutory, but non-compliance carries direct commercial consequences: fines levied by acquiring banks, increased per-transaction fees, and, in the most serious cases, loss of the right to accept card payments. Because the standard applies wherever cardholder data touches an environment, scope determination is often the first compliance failure, not the last. Organizations that validated compliance under v3.2.1, or that treated the future-dated requirements as optional during 2024, are now assessed against a materially larger control set. Requirement 8’s expanded MFA mandate and Requirement 12.3.3’s cryptographic inventory are among the areas most commonly cited as gaps in 2026 assessments.
How this maps to cryptography
PCI DSS addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:
| Section | Function | What it says | Supporting Products |
| Requirements 3.5–3.6 | Stored Account Data Protection | Strong cryptography, tokenization, or truncation for stored cardholder data, layering file, column, or field-level encryption with independent key management on top of full-disk encryption. | EJBCA |
| Requirements 3.6–3.7 | Cryptographic Key Management | Documented key-management procedures covering generation, distribution, storage, rotation, and retirement, with dual control and split knowledge for manual key-management operations. | Keyfactor Command |
| Requirements 4.1–4.2 | Transmission Encryption | Strong cryptography (TLS 1.2 or higher) for cardholder data sent across open, public networks, with PAN never sent unprotected via end-user messaging technologies. | EJBCA |
| Requirements 8.4–8.5 | Multi-Factor and Certificate-Based Authentication | Certificate-based, phishing-resistant multi-factor authentication for all access to the CDE, including remote and third-party vendor access. | EJBCA |
| Requirement 12.3.3 | Cryptographic Suite and Algorithm Inventory | An inventory of cryptographic cipher suites and protocols in use, reviewed on a defined cadence to identify deprecated or weakening algorithms. | AgileSec |
| Requirements 6.4.3, 11.6.1 | Payment Page and Script Integrity | Signed and authorized scripts on payment pages with tamper-detection, extending code-signing controls to flows adjacent to cardholder data. | SignServer |
Readiness questions
Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:
- Future-Dated Requirement Closure: Can the organization demonstrate that all 51 previously future-dated requirements have been implemented and evidenced since March 31, 2025?
- Key-Management Documentation: Are key-management procedures documented, including dual control and split knowledge for any manual key operations?
- MFA Coverage Evidence: Is certificate-based or otherwise strong MFA enforced for all access into the CDE, including vendors and remote sessions?
- Cryptographic Inventory Currency: Does the organization maintain and periodically review an inventory of cryptographic cipher suites and protocols per Requirement 12.3.3?
- Service Provider Attestation Chain: Are current Attestations of Compliance on file for every service provider touching cardholder data, mapped to the specific requirements they cover?
- Segmentation and Scope Validation: Has network segmentation been tested to confirm the boundaries of the cardholder data environment?
TAKE THIS TO MANAGEMENT
The transition period for PCI DSS v4.0 closed on March 31, 2025. Every assessment we undergo now scores against the full requirement set, including certificate-based MFA across the entire cardholder data environment and a documented cryptographic cipher suite inventory. Falling short here is not a future risk, it is what our next Report on Compliance will test.
Loss of card acceptance rights, not just a fine, is the real exposure. If we cannot produce evidence of key-management controls, dual control for manual key operations, and a current cryptographic inventory, we are not positioned to pass that next assessment cleanly, and every service provider in our payment chain is a dependency we have to verify, not assume.
Related Compliances
SWIFT Customer Security Controls Framework
