PCI DSS v4.0.1 Requirement on CBOM: A Quick Guide

Quick answer: PCI DSS v4.0.1 Requirement 12.3.3 requires every organization that stores, processes, or transmits cardholder data to maintain a documented, reviewed inventory of every cryptographic cipher suite and protocol in use, a Cryptographic Bill of Materials (CBOM). The requirement became a mandatory assessed control on March 31, 2025, alongside the related key and certificate inventory in Requirement 4.2.1.1. The recommended action: build a versioned CBOM covering algorithms, keys, certificates, and libraries, assign an owner, and review it at least every 12 months.

Key takeaways

• PCI DSS v4.0.1 Requirement 12.3.3 and Requirement 4.2.1.1 stopped being “future-dated” and became fully assessed requirements on March 31, 2025. QSAs now test for them in every assessment.
• A Cryptographic Bill of Materials (CBOM) is the practical mechanism for satisfying 12.3.3: a structured, versioned inventory of every cipher suite, protocol, algorithm, key, and certificate in the cardholder data environment.
• The requirement has three parts: maintain the inventory, actively monitor industry deprecation trends, and document a response plan for when a cipher or protocol becomes unsafe.
• Requirement 4.2.1.1 (trusted keys and certificates) and Requirement 12.3.3 (cipher suites and protocols) are complementary and should be built from the same discovery process, not treated as separate projects.
• An audit-ready CBOM needs an assigned owner, a 12-month review cadence documented in writing, and evidence that ties directly to QSA assessment procedures for both requirements.

Published: July 2025  |  Updated: August 2026  |  Reviewed by the Encryption Consulting compliance advisory team

This post is part of Encryption Consulting’s cryptographic compliance series. It complements our guides on how CBOM differs from SBOM, NIST SP 800-53 control mapping, and the FIPS 140-3 transition playbook, each targeting a distinct compliance framework’s cryptographic inventory expectations.

What Is PCI DSS Requirement 12.3.3, and What Is a CBOM?

The Payment Card Industry Data Security Standard (PCI DSS) is the security standard maintained by the PCI Security Standards Council (PCI SSC) for any organization that stores, processes, or transmits payment card data. PCI DSS v4.0.1, published in June 2024, is a clarifying revision of v4.0 and remains the current version of the standard as of this writing; the council has not published a v4.1 or v5.0 timeline.

Requirement 12.3.3 states that an organization must document “an up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used,” must “actively monitor industry trends” on the continued viability of that cryptography, and must document a response plan for anticipated changes in cryptographic vulnerabilities. A Cryptographic Bill of Materials (CBOM) is the artifact that satisfies all three parts: a structured, machine-readable inventory of cipher suites, protocols, algorithms, key lengths, certificates, and the cryptographic libraries and modules (OpenSSL, BoringSSL, HSM firmware) that implement them, each mapped to the system or service where it runs.

Requirement 4.2.1.1 is the closely related sibling requirement: it requires an inventory of trusted keys and certificates used to protect primary account data (PAN) in transit. Most organizations build both inventories from the same discovery process, since a certificate inventory and a cipher-suite inventory overlap heavily in practice.

How Do Requirements 12.3.3 and 4.2.1.1 Map to Controls, Owners, and Evidence?

Passing a QSA assessment means every sub-requirement traces to a named control, a named owner, and a piece of evidence the assessor can inspect. The table below is the mapping Encryption Consulting uses when scoping a CBOM engagement against PCI DSS v4.0.1.

Requirement	Control	Owner	Evidence artifact
12.3.3(a) cipher suite and protocol inventory	Versioned CBOM register covering every cipher suite, protocol, and algorithm in the CDE	Cryptography / security engineering	Exported CBOM with system, purpose, and location fields populated
12.3.3(b) monitor industry viability	Subscription to NIST, IETF, and CVE deprecation advisories with a defined review cadence	Security engineering / GRC	Monitoring log and annual review sign-off, dated within 12 months
12.3.3(c) documented response plan	Cryptographic vulnerability response runbook with timelines and stakeholders	Security engineering / incident response	Response plan document and evidence of at least one tabletop exercise
4.2.1.1 trusted key and certificate inventory	Certificate and key inventory tied to PAN-in-transit systems	PKI / certificate lifecycle team	Certificate inventory export and key custodian assignment log
3.6 / 3.7 key management for stored account data	Documented key management procedures covering generation, rotation, and destruction	Key management team	Key management policy and HSM audit log excerpts
12.10.5 incident response for critical alerts	Incident response plan explicitly scoped to cryptographic and IDS/change-detection alerts	Security operations	IR plan with crypto-specific escalation path

What Are the Implementation Steps for Building a PCI DSS-Ready CBOM?

1. Discover every cryptographic asset in the cardholder data environment: cipher suites and protocols via network and endpoint scanning (nmap, sslscan, or continuous discovery tooling), plus certificates, keys, libraries, and HSM/TPM modules.
2. Classify and contextualize each finding: purpose (for example, “TLS termination for the cardholder-facing API gateway”) and location (system, service, or third-party integration).
3. Build the CBOM register in a version-controlled format so every change, deprecation, and remediation is tracked over time rather than overwritten.
4. Assign ownership for each cryptographic domain (cipher suites, certificates, keys, HSMs) to a named team, not a general security mailbox.
5. Establish the 12-month review cadence in writing, aligned to the organization’s PCI DSS assessment calendar, so the review date itself becomes an artifact.
6. Subscribe to deprecation sources: NIST, IETF, and CVE advisories, so a cipher moving from “approved” to “discouraged” is caught before an assessor asks about it.
7. Document the response plan: timelines for deprecating a cipher, fallback configuration, responsible stakeholders, and validation steps before go-live.
8. Package the evidence the QSA will ask for: CBOM export, monitoring log, response plan, and the certificate/key inventory required under 4.2.1.1.

What Is the Current Status of PCI DSS v4.0.1, and What Deadline Applies Now?

PCI DSS v4.0.1 is the current published version of the standard. Version 3.2.1 was fully retired at the end of March 2024, and the “future-dated” requirements introduced in v4.0, including Requirement 12.3.3 and Requirement 4.2.1.1, became mandatory, assessed requirements on March 31, 2025. That date has already passed: as of this update, both requirements are treated exactly like any other PCI DSS control during a Report on Compliance or Self-Assessment Questionnaire. There is no grace period remaining, and the PCI SSC has not announced a public timeline for a v4.1 or v5.0 release, so organizations should plan around v4.0.1 as the baseline for the foreseeable future.

What Are the Limitations of a CBOM-Based Approach?

• A CBOM is only as complete as the discovery process behind it; unmanaged shadow certificates, hard-coded API keys, and internal east-west TLS connections are the most common blind spots.
• Requirement 12.3.3 does not mandate a specific tool or file format, so QSAs will accept different CBOM implementations as long as the three sub-requirements are demonstrably met.
• An inventory that is not version-controlled cannot prove a 12-month review actually occurred; a spreadsheet overwritten each year satisfies neither the spirit nor, in practice, most QSA testing procedures.
• CBOM scope under PCI DSS is limited to the cardholder data environment; organizations pursuing broader cryptographic governance (NIST SP 800-53, FIPS 140-3, or crypto-agility programs) will need a wider-scope inventory than 12.3.3 strictly requires.

Audit-Ready Checklist for Requirement 12.3.3

1. CBOM export covering every cipher suite, protocol, algorithm, and key length in the CDE, with purpose and location populated for each entry.
2. Certificate and key inventory satisfying Requirement 4.2.1.1, cross-referenced to the CBOM.
3. Documented 12-month review cadence with the most recent review sign-off dated and named.
4. Monitoring log showing subscription to NIST, IETF, or CVE deprecation advisories.
5. Cryptographic vulnerability response plan with defined timelines, fallbacks, and stakeholders.
6. Evidence of at least one tabletop exercise or simulated deprecation response.
7. Named owner assigned to each cryptographic domain (cipher suites, certificates, keys, HSMs).
8. Version history for the CBOM register showing changes over time, not a single static snapshot.

What Would Encryption Consulting Recommend?

Treat Requirements 12.3.3 and 4.2.1.1 as one discovery project, not two. Organizations that build a certificate inventory in isolation from a cipher-suite inventory routinely end up re-scanning the same environment twice, once for each requirement, when a single CBOM discovery pass with the right data model covers both. Our recommendation is to invest in continuous discovery rather than a point-in-time scan: cardholder data environments change between assessment cycles, and a CBOM built once and never refreshed is a compliance liability disguised as a compliance artifact. Pair the CBOM with our CBOM Secure platform for continuous discovery and our Compliance Advisory Services for gap analysis against the exact QSA testing procedures for v4.0.1.

Frequently Asked Questions

What is PCI DSS Requirement 12.3.3?

It requires organizations in scope for PCI DSS to maintain a documented, up-to-date inventory of all cryptographic cipher suites and protocols in use, monitor industry trends on their continued viability, and document a response plan for anticipated cryptographic vulnerabilities. It became a mandatory assessed requirement on March 31, 2025.

Is a CBOM mandatory under PCI DSS?

PCI DSS does not name “CBOM” as a required artifact, but a CBOM is the practical way most organizations satisfy Requirement 12.3.3’s inventory, monitoring, and response-plan sub-requirements in a form a QSA can test against.

How does CBOM differ from SBOM under PCI DSS?

A Software Bill of Materials (SBOM) inventories all software components in an application. A CBOM narrows that scope to cryptographic assets specifically: cipher suites, protocols, algorithms, keys, and certificates. PCI DSS Requirement 12.3.3 concerns the CBOM scope, not the broader SBOM. See our CBOM vs. SBOM guide for the full comparison.

What happens if an organization does not maintain a cryptographic inventory?

Since March 31, 2025, failing to demonstrate Requirement 12.3.3 compliance results in a finding during the Report on Compliance or Self-Assessment Questionnaire, the same as any other PCI DSS control gap, which can delay certification and, depending on acquiring bank policy, affect processing privileges.

How often must the cryptographic inventory be reviewed?

At least once every 12 months, and the review date itself needs to be documented as evidence, not just the existence of an inventory.

Ready to close the gap? Contact Encryption Consulting at [email protected] to scope a CBOM discovery engagement aligned to PCI DSS v4.0.1.

References

• PCI DSS v4.0.1, PCI Security Standards Council
• PCI SSC: Just Published, PCI DSS v4.0.1
• PCI Security Standards Council