The countdown is over, and so it is the grace period. PCI DSS v4.0.1 was published in June 2024 as a maintenance release of v4.0 (March 2022), which had 64 new or updated requirements, and 51 of them were future-dated. Those 51 became mandatory on March 31, 2025.
That deadline turned PCI DSS cryptography from a roadmap item into a live operating requirement. For merchants, service providers, and the qualified security assessors (QSAs) who evaluate them, encryption and key management now sit at the center of every cardholder data conversation. If your controls were built for the old baseline, the gap is already an audit finding waiting to happen.
This guide walks through the cryptographic controls that govern cardholder data under v4.0.1, what assessors probe for, and how to build a program that answers the next requirement as well as this one.
Why cryptography moved to the center of PCI DSS
PCI DSS is a contractual standard, not a law. You agree to it through your acquiring bank and the card brands, so enforcement is commercial rather than statutory. Falling short can trigger fines from acquirers, higher per-transaction fees, and, in the worst case, the loss of your right to accept cards at all.
Cryptography carries much of that weight because it is how cardholder data stays protected wherever it lives or travels. The v4.0 update raised the bar and v4.0.1 clarified wording on encryption, key management, authentication, and cryptographic visibility, which is why so many of the newly mandatory requirements touch these areas.
Scope determination is often the first place organizations stumble. If you misjudge which systems store, process, or transmit account data, every cryptographic control downstream inherits that error. Getting scope right is the foundation everything else rests on.
The requirements that govern PCI DSS cryptography
Six interlocking control areas define how cardholder data must be protected under v.4.0 and v4.0.1. Each one stands on its own, and together they form the backbone of a defensible program. Here is what each requires and why it matters.
Protecting stored account data (Requirements 3.5 to 3.6)
Stored cardholder data must be rendered unreadable using strong cryptography, tokenization, or truncation. Storing a primary account number (PAN) in the clear is not an option.
Full disk encryption alone is not enough for many environments. The stronger pattern is to layer file, column, or field level encryption on top of disk encryption, with key management kept independent of the operating system’s own access controls. That separation ensures that a compromised host does not automatically expose the data it holds.
Managing cryptographic keys across their lifecycle (Requirements 3.6 to 3.7)
Encryption is only as strong as the keys behind it, so PCI DSS requires documented procedures that cover the full key lifecycle: generation, distribution, storage, rotation, and retirement. Every stage needs a defined, repeatable process.
For manual key operations, the standard calls for dual control and split knowledge. No single person should be able to reconstruct or misuse a key on their own. This is one of the areas assessors examine most closely, so the documentation has to match what actually happens in practice.
Encrypting cardholder data in transit (Requirements 4.1 to 4.2)
Card data crossing open, public networks must be protected with strong cryptography, meaning algorithms and key strength must meet certain minimum requirements (with 112 bits being the minimum keysize). For example, TLS 1.2 becomes the practical floor that assessors expect. Older protocols and weak configurations are exactly what the update is designed to push out.
A related rule is easy to overlook: PAN must never be sent unprotected through end-user messaging channels such as email or chat. Keeping an inventory of the trusted keys and certificates used to protect PAN in transit makes this control verifiable rather than assumed.
Authenticating access to the cardholder data environment (Requirements 8.4 to 8.5)
All access to the cardholder data environment (CDE) now requires multi-factor authentication, and the strongest approach is certificate-based, phishing-resistant MFA. This applies to remote access and to third-party vendor access, not just internal staff.
Requirement 8’s expanded MFA mandate is one of the most common gaps heading into 2026. Many organizations covered administrative logins but left service accounts, vendor connections, or specific CDE systems behind. Closing those gaps is now non-negotiable.
Building a cryptographic cipher suite inventory (Requirements 4.2.1.1 and 12.3.3)
You cannot secure what you cannot see, so v4.0.1 requires an inventory of the cipher suites and protocols in use, reviewed on a defined cadence of at least once every 12 months. The review is what catches deprecated or weakening algorithms before an attacker or an assessor does.
This is another of the most frequently cited gaps for 2026. A cryptographic inventory is straightforward to describe and genuinely hard to maintain by hand, especially across hybrid and multi-cloud estates.
Securing payment pages and scripts (Requirements 6.4.3 and 11.6.1)
Scripts running on payment pages must be authorized, inventoried, and monitored for tampering. This extends code-integrity thinking to the browser, where skimming attacks increasingly target the checkout flow.
The practical answer is signed and authorized scripts paired with tamper detection. It applies code-signing discipline to the flows sitting right next to cardholder data.
What auditors and assessors actually ask
The audit-readiness probes behind v4.0 and v4.0.1 turn into a checklist you can self-assess against today. Walk through each of these before an assessor does:
- Have all 51 future-dated requirements been closed and evidenced, not just planned?
- Is key management documented end to end, with dual control and split knowledge in place?
- Does MFA cover every path into the CDE, including remote and vendor access?
- Is there a current cryptographic inventory of cipher suites, protocols, keys, and certificates?
- Can you produce the service-provider attestation chain for every vendor in scope?
- Have segmentation and scope been validated so the CDE boundary holds up?
- Does every entity-defined frequency and customized-approach control have a documented, current targeted risk analysis behind it?
If any answer is uncertain, that is where to focus first. Assessors evaluate against evidence, so documentation that reflects real, running controls carries far more weight than intent.
Future-proofing card data: the post-quantum horizon
The cryptographic inventory you build for PCI DSS does double duty. The same visibility required by Requirements 4.2.1.1 and 12.3.3 is the foundation for identifying quantum-vulnerable algorithms across your environment.
The timeline is closer than it looks. In 2024, NIST finalized the first post-quantum cryptographic standards (FIPS 203, 204, 205, August 2024) and published a transition timeline that deprecates widely used public-key algorithms such as RSA and elliptic curve cryptography by 2030, with full disallowance targeted for 2035. Payment data with a long retention life is exposed to harvest-now, decrypt-later attacks, where an adversary captures encrypted traffic today to decrypt once a quantum computer is available.
That makes long-lived transaction data a present concern, not a future one. A well-maintained cryptographic inventory becomes the cryptographic bill of materials (CBOM) that anchors an orderly migration to post-quantum cryptography.
How Keyfactor supports PCI DSS cryptography and key management
Keyfactor maps directly to each PCI DSS control area, so you can move from requirement to capability without stitching together point tools.
- Keyfactor AgileSec: discovers and catalogs cipher suites, protocols, keys, and algorithms to satisfy the Requirement 12.3.3 inventory and score cryptographic risk.
- EJBCA: issues the certificates behind stored-data and transmission encryption and behind certificate-based MFA for the CDE.
- SignServer: signs and protects the scripts on payment pages, supporting integrity controls for flows adjacent to cardholder data.
- Keyfactor Command: provides documented, automated key and certificate lifecycle management, from generation through retirement, with the audit trail assessors expect.
Underneath these products, the Keyfactor Trust Control Plane acts as a single system of record for every cryptographic asset and machine identity. It runs a continuous loop that observes, analyzes, provisions, orchestrates, and governs keys and certificates across core banking, payments, and open banking infrastructure, so the evidence any framework asks for comes from one place.
Conclusion: a program, not a project
PCI DSS cryptography is now an operating capability, not a one-time remediation sprint. The 51 future-dated requirements are mandatory, and the controls behind them, encryption, key management, MFA, and cryptographic inventory, only hold their value when they run continuously.
The good news is that the same foundation answers the next requirement too. A current cryptographic inventory that satisfies v4.0.1 is also the starting point for your post-quantum migration. Build it once, govern it continuously, and each new mandate becomes an update rather than an emergency.
Ready to see where your cardholder data environment stands? Request a Demo to explore how Keyfactor helps you inventory, automate, and govern the cryptography behind PCI DSS compliance.
Got PCI DSS cryptography questions? We’ve got answers.
What does PCI DSS require for protecting stored cardholder data?
Stored cardholder data must be rendered unreadable using strong cryptography, tokenization, or truncation. PCI DSS expects file, column, or field level encryption with independent key management layered on top of full disk encryption, not full disk encryption alone. That separation keeps a compromised host from automatically exposing the data it holds.
When did the future-dated PCI DSS v4.0.1 requirements become mandatory?
They became mandatory on March 31, 2025. The 51 requirements that were treated as best practice under v4.0 are now scored in every assessment, so the transition window has closed.
What does PCI DSS Requirement 12.3.3 cover?
Requirement 12.3.3 calls for a documented inventory of the cryptographic cipher suites and protocols in use. That inventory must be reviewed on a defined cadence of at least once every 12 months to identify deprecated or weakening algorithms before they become a vulnerability.
Does PCI DSS require multi-factor authentication for cardholder data?
Yes. PCI DSS v4.0.1 mandates multi-factor authentication for all access to the cardholder data environment, including remote and third-party vendor access. Certificate-based, phishing-resistant methods provide the strongest assurance.
What encryption is required for cardholder data in transit?
Cardholder data sent across open, public networks must use strong cryptography, meaning TLS 1.2 or higher. Primary account numbers must never be sent unprotected through end-user messaging technologies such as email or chat.
What key management controls does PCI DSS expect?
PCI DSS requires documented procedures covering key generation, distribution, storage, rotation, and retirement. Manual key operations must use dual control and split knowledge so no single person can compromise a key.
Is PCI DSS a law?
No. PCI DSS is a contractual standard rather than a statute, but non-compliance carries real commercial consequences, including fines from acquiring banks, higher per-transaction fees, and potential loss of the ability to accept card payments.
How should PCI DSS teams prepare for post-quantum cryptography?
Start with the cryptographic inventory that Requirements 4.2.1.1 and 12.3.3 already demand, then assess those algorithms against NIST’s published deprecation timelines. Because long-lived transaction data can be harvested now and decrypted later, planning the migration early protects data whose sensitivity outlasts today’s algorithms.
