PCI Compliance Specification

Published: April 2021. Updated: August 2026. Reviewed by Encryption Consulting’s Compliance Advisory team.

This article is a specification-level, technical deep dive into what PCI DSS requires at the cryptographic and key-management layer: algorithm and protocol selection, the threat model behind each control, key-custody dependencies, and concrete deployment patterns. If your team needs the full certification path, merchant levels, SAQ types, and program-level guidance instead, see our companion piece, A Comprehensive Guide to Achieving and Maintaining PCI DSS Compliance, which covers the broader compliance program. This post exists for the security and engineering teams who already know they need to comply and are now designing the systems that have to pass an assessor’s technical review.

What Does PCI DSS Specify for Cryptography?

PCI DSS specifies that any cardholder data at rest or in transit must be protected using strong cryptography, defined by the PCI Security Standards Council (PCI SSC) as algorithms and key strengths that are widely tested, accepted by the international cryptography community, and free of known practical exploits at the key size deployed. In practice that means a minimum of 112-bits of effective key strength, which rules out DES, single-key 3DES, and RC4 outright, and points implementers toward AES-256, RSA at 2048 bits or higher, and ECC at 224 bits or higher.

A handful of terms recur throughout the specification and this article, so it is worth defining each precisely before going further:

• PCI DSS (Payment Card Industry Data Security Standard): the technical and operational security standard maintained by the PCI SSC for any organization that stores, processes, or transmits payment card data.
• PAN (Primary Account Number): the card number itself, the specific data element most PCI DSS cryptographic controls exist to protect.
• CDE (Cardholder Data Environment): the people, processes, and technology that store, process, or transmit cardholder data, plus any system that could impact that data’s security.
• QSA (Qualified Security Assessor): an individual certified by the PCI SSC to perform formal on-site PCI DSS assessments.
• ROC (Report on Compliance): the detailed report a QSA produces documenting how each requirement was tested and validated, required for Level 1 merchants and most service providers.
• SAQ (Self-Assessment Questionnaire): the self-reported validation tool smaller merchants use in place of a full QSA-led audit.

The specification’s cryptographic requirements break into three distinct engineering problems: rendering stored PAN unreadable (Requirement 3), protecting cardholder data in transit (Requirement 4), and authenticating every user who reaches the CDE (Requirement 8). Each has its own threat model and its own algorithm or protocol choice, and the sections below walk through each in the order an architecture review typically tackles them.

Which Algorithms and Protocols Does PCI DSS Require?

PCI DSS requires AES-256 or an equivalent-strength algorithm for protecting stored account data, and TLS 1.2 as the enforced minimum protocol version for cardholder data in transit over open, public networks, with TLS 1.3 preferred for any new deployment. The standard itself does not hard-code a single protocol version in its text, but the PCI SSC’s own guidance rules out SSL and early TLS (TLS 1.0 and 1.1) as no longer meeting the definition of strong cryptography.

Threat Model for Data at Rest and in Transit

Stored cardholder data is targeted through database compromise, insider misuse, backup and log exposure, and lateral movement from a lower-sensitivity system into the data store, so the control has to survive an attacker who already has read access to the storage layer. Data in transit faces a different threat model: man-in-the-middle interception, protocol downgrade attacks, and cipher-level exploits such as POODLE and BEAST that specifically target SSL and early TLS. A QSA testing Requirement 4 will scan for any listener still accepting a deprecated protocol version, not just confirm that TLS is enabled somewhere in the stack.

Algorithm and Protocol Selection Guidance

For data at rest, AES-256-GCM is generally preferred over CBC mode for new implementations because it provides authenticated encryption, detecting tampering as well as concealing the data, at comparable performance on modern CPUs with AES-NI acceleration. For data in transit, disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 on every system component that touches the CDE, including internal load balancers and legacy point-of-sale integrations, and configure cipher suite preference to favor forward-secrecy suites (ECDHE-based) over static RSA key exchange. The PCI SSC points to NIST SP 800-52 as a reference for TLS configuration hardening.

Performance and Interoperability Trade-offs

TLS 1.3 removes several legacy handshake round-trips and drops known-weak cipher suites, reducing both connection latency and misconfiguration risk, but some older point-of-sale terminals, payment SDKs, and embedded devices still only negotiate TLS 1.2. That is why TLS 1.2 remains the practical minimum baseline rather than TLS 1.3 outright; a phased upgrade path that retires TLS 1.2 hardware on a defined schedule is a more realistic architecture decision than an immediate cutover. On the storage side, AES-256-GCM’s authentication tag adds a small, fixed overhead per block that is negligible on hardware-accelerated systems but can matter on constrained embedded payment terminals, which is one reason those devices are frequently tokenized at the point of capture instead of encrypted locally.

Deployment example: a common pattern is TLS termination at a load balancer or API gateway configured for TLS 1.2 minimum and TLS 1.3 preferred, with re-encryption, not plaintext, on the internal segment between the gateway and the application tier, so cardholder data is never transmitted in the clear even inside the organization’s own network.

What Do PCI DSS Requirements 3.5 to 3.7 Require for Key Management?

Requirements 3.5, 3.6, and 3.7 require, respectively, that stored PAN be rendered unreadable, that the keys protecting it be secured against disclosure and misuse, and that a documented lifecycle govern every key from generation to destruction. Encryption is only as strong as the key management behind it, and this is the sub-requirement family QSAs most often flag in failed assessments.

• Requirement 3.5 requires the PAN to be rendered unreadable anywhere it is stored, using strong cryptography, truncation, index tokens with a securely stored pad, or one-way hashing of the entire PAN.
• Requirement 3.6 requires that cryptographic keys used to protect stored account data be themselves protected: encrypted with a separate key-encrypting key, stored within a secure cryptographic device such as an HSM, or split into components under dual control, with access restricted to the fewest custodians necessary.
• Requirement 3.7 requires documented procedures across the full key lifecycle: strong key generation, secure distribution, secure storage, rotation at the end of a defined cryptoperiod, and retirement or destruction of compromised or expired keys. It also requires split knowledge and dual control for manual key-management operations, and signed acknowledgment from custodians of their responsibilities.

Key-management dependency: an AES-256 database column encrypted with a key stored in a configuration file next to it provides essentially no real protection, and is a routine finding in failed assessments. Neither Requirement 3.5’s rendering-unreadable control nor Requirement 4’s TLS control is meaningful without the custody and lifecycle discipline that 3.6 and 3.7 impose on the keys underneath them. Centralizing that lifecycle through a dedicated certificate and key lifecycle platform like CertSecure Manager gives an organization enforced rotation schedules, custodian accountability, and audit-ready reporting instead of a spreadsheet tracking key ages manually.

What Does PCI DSS Require for Multi-Factor Authentication?

PCI DSS v4.0.1 requires MFA for all access into the cardholder data environment under Requirement 8.4.2, not Requirement 8.4.3, and this control has been fully enforced since March 31, 2025. We verified this directly for this article because two other posts on this topic disagree on the number, and getting it right matters for anyone building an access-control architecture against the spec.

Three related sub-requirements under Requirement 8.4 are easy to conflate, so it is worth distinguishing them precisely:

• Requirement 8.4.1: MFA for all non-console administrative access into the CDE. Carried forward from PCI DSS v3.2.1 and in effect for years before v4.0.
• Requirement 8.4.2: MFA for all access into the CDE, for every role, from any location, not administrative access alone. This is the headline new control introduced in v4.0 and became mandatory on March 31, 2025.
• Requirement 8.4.3: MFA for all remote network access originating from outside the entity’s network that could reach the CDE, covering personnel and third-party or vendor remote access alike. This requirement existed before v4.0 and was clarified rather than newly introduced.

Requirement 8.5.1 works alongside 8.4.2 and also became mandatory on March 31, 2025: MFA implementations must resist bypass except through a documented, risk-assessed exception process, require at least two independent factors, confirm all factors succeed before granting access, and resist replay attacks. For most organizations, the practical work is extending MFA from the administrator population already covered under 8.4.1 out to every application user, contractor, and third-party integration that touches the CDE, then documenting the anti-bypass controls an assessor will specifically ask to see evidence of.

How Does Tokenization Protect the PAN Under PCI DSS?

Tokenization protects the PAN by replacing it with a surrogate value, a token, at the point of capture and storing the real PAN only inside a separate, tightly scoped token vault, so every downstream system that touches the token never touches the actual card number. Format-preserving encryption (FPE) is the technique most tokenization schemes use to keep the token the same length and character set as the original PAN, so legacy databases, log formats, and downstream applications do not need schema changes to accept it.

Where encryption keeps the PAN’s value recoverable in place, which matters when downstream systems such as recurring billing or chargeback processing still need the original number, tokenization removes the real PAN from the environment entirely. That is what actually reduces PCI DSS assessment scope, but it introduces a dependency on the token vault being reachable and available for every system that needs to detokenize, and format-preserving tokenization adds a network round trip per detokenization call that matters at high transaction volume.

Deployment example: a payment gateway typically tokenizes the PAN at the point of capture and stores only the token in its own database, keeping the token vault itself as the sole system in full PCI DSS scope. A legacy on-premises billing system that must retain the real PAN for recurring charges more often relies on column-level or transparent data encryption with AES-256, backed by an HSM-protected key, because replacing the PAN with a token would break its billing logic.

What HSM Requirements Apply to Key Custody?

A hardware security module (HSM) is the practical way most compliant organizations satisfy Requirement 3.6’s “secure cryptographic device” language: a tamper-resistant, dedicated appliance that generates, stores, and uses cryptographic keys without ever exposing them in plaintext to the host application or operating system. FIPS 140-3 is the current validation standard HSMs are assessed against, and QSAs increasingly expect FIPS-validated key storage rather than software-based key vaults for high-value environments.

Organizations generally choose between on-premises HSMs, which offer maximum control and are common where contractual requirements demand it, and cloud-hosted HSM-as-a-Service, which removes the capital cost and physical key-ceremony overhead while still delivering FIPS-validated key storage. Deployment example: a payment processor’s tokenization vault stores its master encryption key inside an HSM cluster, and every token generation or detokenization call is signed or decrypted inside the HSM boundary, so the key itself never leaves validated hardware.

Which PCI DSS Requirements Govern Cryptography and Key Management?

The table below maps each crypto- and key-management-relevant requirement number to what it covers and the technical control that typically satisfies it, useful as a quick reference during an architecture review.

Requirement	What It Covers	Typical Technical Control
3.5	Render stored PAN unreadable	AES-256 encryption, tokenization, or truncation
3.6	Protect keys used to secure stored account data	HSM-backed key storage, key-encrypting keys, dual control
3.7	Document and enforce the full key lifecycle	Defined cryptoperiods, automated rotation, custodian sign-off
4.2.1	Protect cardholder data in transit over public networks	TLS 1.2 minimum, TLS 1.3 preferred, no SSL or early TLS
8.4.1	MFA for non-console administrative access to the CDE	MFA on all admin consoles and jump hosts
8.4.2	MFA for all access into the CDE, any role, any location	MFA enforced at every CDE authentication point
8.4.3	MFA for remote access originating outside the entity’s network	VPN or remote-access gateway MFA, including third-party access

What Is the PCI DSS Compliance Validation Process?

PCI DSS validation follows the same technical assessment sequence regardless of merchant level, though the depth of testing at each stage differs based on transaction volume and validation path (QSA-led ROC versus self-assessed SAQ).

1. Confirm CDE scope. Map every system, process, and network segment that stores, processes, or transmits cardholder data, or that could impact its security. Segmentation is the single most effective way to shrink this scope.
2. Inventory cryptographic assets. Build an accurate list of every algorithm, protocol, certificate, and key in the CDE before deciding on remediation; you cannot protect what you cannot see.
3. Test cryptographic and key-management controls against Requirements 3, 4, and 8 specifically. Verify PAN rendering, TLS configuration, key custody, and MFA coverage against the specification, not against what feels secure.
4. Remediate the highest-severity gaps first. Unencrypted stored PAN, deprecated TLS versions, and missing MFA on CDE access are consistently the most severe assessment findings.
5. Complete formal validation. Lower-volume merchants complete the applicable SAQ; Level 1 merchants and most service providers undergo a QSA-led on-site assessment producing a Report on Compliance (ROC).
6. Submit the Attestation of Compliance (AOC) to the acquiring bank, backed by the SAQ or ROC.
7. Maintain continuous validation. Quarterly ASV scans, annual penetration testing, and an annual scope-confirmation exercise keep cryptographic controls from silently drifting between formal assessments.

Limitations

The specification is precise, but it does not cover everything a real deployment needs. Some limitations worth flagging directly:

• Passing an assessment is a point-in-time attestation. A configuration drift or an unscoped new system after the ROC or AOC is signed can put an organization back out of compliance immediately.
• Encrypting the PAN does not remove it from scope by itself. A system still storing encrypted account data generally stays in scope; only tokenization that removes the real PAN entirely tends to reduce scope.
• Compensating controls require documented rigor, not convenience. Each one needs a formal risk analysis and QSA sign-off, and used loosely they become a way to avoid fixing the underlying gap.
• The standard evolves. This article reflects PCI DSS v4.0.1 as of August 2026. A future v5.0 revision may renumber requirements or shift timelines, so verify against the current published standard before making architecture decisions.
• QSA interpretation can vary on borderline scoping questions. Engaging your QSA early in an architecture decision avoids rework later.

What Would Encryption Consulting Recommend?

Our position, after supporting cryptographic architecture reviews for organizations from regional merchants to national banks, is that most PCI DSS crypto programs fail an assessment not because a control is missing, but because it was bolted on rather than architected against the specification from the start. Here is what we would actually do, in order.

Start with a real cryptographic inventory. Before choosing between encryption and tokenization or auditing TLS configuration, build an accurate inventory of every cipher suite, protocol, certificate, and key touching the CDE.

Centralize key and certificate lifecycle management. We deploy CertSecure Manager to give organizations enforced rotation schedules, custodian accountability, and centralized visibility, directly addressing the Requirement 3.6 and 3.7 findings that show up most often in failed assessments. For master keys protecting tokenization vaults or bulk encryption, we generally recommend FIPS 140-3 validated storage through on-premises HSMs or HSM-as-a-Service, depending on operational maturity and existing infrastructure.

Extend MFA deliberately, not just technically. Meeting Requirement 8.4.2’s letter is straightforward; meeting Requirement 8.5.1’s anti-bypass intent takes more discipline. We help clients document every legitimate MFA exception, tie it to a compensating control, and remove informal bypasses that accumulate over time.

Treat cloud-stored cardholder data with the same custody discipline as on-premises data. Our Cloud Data Protection services extend HSM-backed key custody and encryption architecture into cloud and hybrid environments, so tokenization vaults or encrypted data stores hosted in the cloud meet the same key-management bar as an on-premises deployment.

Treat validation as continuous, not annual. Our Compliance Advisory services pair PCI DSS work with the broader regulatory landscape many clients face, including DORA and NIS2, so cryptographic controls built for PCI DSS serve overlapping mandates instead of being rebuilt for each one. If you are early in this process, the highest-leverage first move is a gap assessment against Requirements 3, 4, and 8 specifically, since that is where the cost of getting it wrong is highest.

Conclusion

PCI DSS’s cryptographic specification is narrower and more precise than the standard’s full 12 requirements might suggest: strong algorithms and TLS 1.2+ for data in motion, a documented key-management lifecycle under Requirements 3.6 and 3.7, MFA for all CDE access under Requirement 8.4.2, and a deliberate choice between encryption and tokenization for stored PAN. Get those four right, back them with HSM-protected key custody, and most of what a QSA tests for at the technical layer falls into place.

None of that replaces disciplined validation: quarterly scans, annual penetration tests, and a genuine habit of treating the crypto layer as a living architecture rather than a one-time build. If you want a second set of eyes on how your cryptographic controls hold up against the specification, our Encryption Advisory services can help scope the gap and prioritize remediation.

Frequently Asked Questions

Is the PCI DSS MFA-for-all-CDE-access mandate Requirement 8.4.2 or 8.4.3? It is Requirement 8.4.2. Requirement 8.4.2 mandates MFA for all access into the cardholder data environment, for every role and from any location, and has been enforced since March 31, 2025. Requirement 8.4.3 is a separate, narrower control that mandates MFA specifically for remote network access originating from outside the entity’s network.

Does PCI DSS require a specific encryption algorithm? PCI DSS does not name one mandatory algorithm in its text, but requires strong cryptography with at least 112 bits of effective key strength. AES-256 is the de facto standard for stored account data because it is explicitly recognized as strong cryptography and performs well in hardware.

Is tokenization required, or is encryption enough? Neither is individually mandated; PCI DSS Requirement 3.5 accepts encryption, tokenization, truncation, or one-way hashing to render the PAN unreadable. Tokenization is generally preferred when scope reduction is the goal, because removing the real PAN from a system can take that system out of assessment scope, while encrypted storage generally does not.

Do PCI DSS keys have to be stored in an HSM? Requirement 3.6 does not name HSMs specifically, but it requires keys to be protected in one of a small set of forms, including storage “within a secure cryptographic device.” An HSM validated to FIPS 140-3 is the most common way organizations satisfy that language, and QSAs increasingly expect FIPS-validated hardware for high-value key custody rather than software-based key vaults.

How is this article different from EC’s general PCI DSS compliance guide? This article is a specification-level, cryptography-and-key-management deep dive intended for security and engineering teams designing systems against the standard. Our companion guide, A Comprehensive Guide to Achieving and Maintaining PCI DSS Compliance, covers the full certification program: merchant levels, SAQ types, and the end-to-end path to an AOC.

References

• PCI DSS v4.0.1 standard document, PCI Security Standards Council
• Now Is the Time to Adopt the Future-Dated Requirements of PCI DSS v4.x, PCI SSC Blog
• PCI DSS 4.0 MFA Requirements: What You Need to Know, Schellman
• PCI DSS Version 4.0 Multi-Factor Authentication, BDO
• Migrating from SSL and Early TLS, PCI SSC Information Supplement
• PCI SSC Document Library