PCI DSS 4.0.1 Requires Cryptographic Agility. Cardholder Data Architectures Have to Move.

PCI DSS 4.0 published in March 2022 introduced future-dated requirements that became binding on March 31, 2025. PCI DSS 4.0.1 published in June 2024 refined the requirements and clarified the assessment expectations. The next revision, 4.0.2, is on the PCI Security Standards Council roadmap. The cryptographic requirements that emerged across these revisions converge on the same expectation. Cardholder Data Environments are expected to operate with cryptographic agility. The expectation reaches the architecture of the CDE, not only the algorithms in use.

Section 3 of PCI DSS addresses protected account data. Requirement 3.5 addresses Primary Account Number (PAN) protection through strong cryptography. Requirement 3.6 addresses cryptographic key management. Requirement 12.3.3 specifies that the entity maintains documented cryptographic cipher suites and protocols in use, including any business or technical reasons for retaining cryptography vulnerable to attack. The convergence across these requirements is that cryptography in the CDE has to be inventoryable, replaceable, and accountable. Architectures that cannot produce this evidence cannot pass a current assessment cleanly.

What cryptographic agility actually means in PCI scope

A cryptographically agile CDE has three properties. The cryptographic operations protecting PAN are inventoryable by purpose, algorithm, key length, mode, and key management approach. The cryptographic operations are replaceable without rebuilding the applications that consume them. The cryptographic operations produce logs sufficient to demonstrate which keys were used, when, and against what data.

These properties are difficult to produce in architectures where cryptographic operations are implemented in application code. Each application owns its key handling, its cipher choice, its rotation schedule, and its logging. The inventory is the union of every application's behavior. The replacement is the rebuild of every application. The logging is whatever each application chose to emit.

Architectures that move cryptographic operations to a centralized service produce the three properties by construction. The service holds the keys. The service performs the operations. The service logs the events. The applications call the service. The inventory is the service's configuration. The replacement is the service's algorithm choice. The logging is the service's audit chain.

Where the post-quantum window applies

PCI DSS does not currently require PQC. PCI DSS does require strong cryptography aligned with NIST guidance. NIST IR 8547 establishes the migration direction for federal civilian systems. Card brands and major acquirers operate globally and increasingly align cryptographic policy with NIST direction even where PCI text does not yet mandate it.

The PCI assessment window for any given merchant is typically annual. A merchant on a March assessment cycle in 2026 may face a 2027 cycle in which the assessor expects evidence of a PQC migration plan, not yet evidence of completed migration. The assessor expectation in 2028 may be evidence of migration in progress. The expectation in 2029 may be evidence of completed migration for non-legacy PAN protection. The schedule is more compressed than the multi-year PCI revision cadence suggests because the cryptographic context is changing faster than the standard.

A merchant whose CDE cryptography is tightly coupled to application code cannot migrate inside that window. The migration requires application rebuild, application revalidation, and application redeployment across the merchant's entire CDE footprint. A merchant whose CDE cryptography runs through a centralized service migrates by changing the service's configuration.

How Lattix architecture maps to PCI requirements

Lattix Technologies implements cryptographic agility at the data object level. Each protected data object carries a data encryption key wrapped under a key encryption key held at the policy enforcement point. The PEP enforces attribute-based access control under FIPS 140-3 validated cryptographic modules. The wrapping algorithm is configurable, and the implementation includes ML-KEM-768 and ML-KEM-1024 alongside classical algorithms.

For PCI assessment, this architecture produces direct evidence against Requirement 3.5 (cryptographic protection of PAN), Requirement 3.6 (cryptographic key management), Requirement 10 (logging and monitoring), and Requirement 12.3.3 (cryptographic inventory). The inventory is the PEP configuration. The protection is the wrapped key over the object. The logging is the Merkle-tree lineage chain over key release decisions.

The architecture also addresses Requirement 7 (least privilege access to cardholder data). The PEP evaluates attribute claims at every key release. The PAN is not readable by a principal whose attributes do not match the policy bound to the object. The least-privilege boundary is enforced at the data, not at the application.

What CDEs should be doing in the next 90 days

Three operational priorities matter for organizations operating CDEs against PCI DSS 4.0.x.

The first is the cryptographic inventory required by Requirement 12.3.3. The inventory deliverable identifies the cipher suites, key management approaches, and rotation schedules in use across the CDE. The inventory is the baseline against which agility is measured.

The second is the architecture decision about cryptographic centralization. CDEs with crypto in application code face migration cost proportional to the application portfolio. CDEs with centralized cryptographic services face migration cost proportional to the service configuration. The decision made in 2026 determines the assessment outcome in 2027 and beyond.

The third is the logging architecture. PCI Requirement 10 specifies audit logs for cardholder data access. Logs that survive an attacker present in the CDE are logs anchored cryptographically outside the application infrastructure. The Lattix lineage chain pattern is one implementation. Other implementations exist. The principle is consistent.

How the architecture maps to standards alignment

PCI SSC, NIST IR 8547, NIST FIPS 140-3, and the broader cryptographic agility direction across federal and commercial regulators all converge on the same architectural pattern. Cryptographic operations are centralized, validated, and configurable. Applications call the cryptographic service rather than implementing cryptography directly. Audit logs are produced at the policy decision point and anchored cryptographically.

The decision to align PCI cryptographic architecture with this pattern is a decision that compounds. Each migration step gets easier when the cryptographic operations are centralized. Each compliance assessment gets cleaner when the evidence is produced by the architecture rather than reconstructed from logs. The architectural investment in 2026 is the investment that scales across PCI revisions in the years to follow.

References

• PCI Security Standards Council, PCI DSS v4.0.1
• PCI SSC Document Library, PCI DSS 4.0.1 Supporting Documents
• NIST IR 8547, Transition to Post-Quantum Cryptography Standards
• NIST FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST SP 800-57, Recommendation for Key Management
• PCI SSC, Cryptographic Failures Information Supplement