Certificate inventory for PCI DSS 4.2.1.1

A QSA expects a dated inventory of every trusted key and certificate used to protect cardholder data in transit, plus proof that the inventory is kept current. The inventory itself is the core artifact, but assessors also sample supporting records that show where each certificate came from, who approved it and how gaps were closed. Ask your QSA which of these records they want to see and in what format before you design the exports.

• Inventory export with a generation timestamp and the source of each entry
• CA issuance and revocation logs for the sampled certificates
• Scanner reports showing the scan scope and date
• Reconciliation records for resolved gaps
• Key custody and HSM inventories, change tickets and expiry alerts

The inventory is usually generated from a certificate management system or CA database, with scanner results used to confirm what is actually deployed. step-ca stores issued certificates for its provisioners, cert-manager records Kubernetes Certificate and Secret objects, and OpenBao PKI tracks issued certificates for its roles. Each export should carry a generation timestamp, the system of record and the query used. Confirm with your QSA that a single export, not a manual spreadsheet, is acceptable as the inventory.

Issuance and revocation logs come from the CA itself, and they must show who or what requested each certificate, which provisioner or role approved it and when it was revoked. In step-ca, the audit log and provisioner records serve this purpose, while OpenBao keeps audit devices that record requests and responses. Make sure logs are shipped off the CA host to a store that the CA administrators cannot edit, because assessors test whether records are complete and tamper resistant.

Scanner reports prove that the inventory was checked against the live cardholder data environment, and the scope of the scan matters as much as its results. A report should list the network ranges, ports and hostnames scanned, the date, the tool version and the scan credentials used. Scanners that inspect TLS endpoints can flag certificates that were never registered with the CA, which is the reconciliation signal you need. Document why any in-scope address was excluded.

Reconciliation records are the tickets or log entries that pair each discrepancy between the inventory and the scan with its resolution, such as a certificate added to the inventory, replaced, revoked or removed from scope. Keep the original discrepancy, the owner, the action and the closing date together so an assessor can follow one gap from detection to closure. Gaps that remain open should be listed with a remediation plan rather than left out of the export.

Assessors check that the keys behind trusted certificates are inventoried, stored and controlled, and that secure cryptographic devices are listed. For CA keys, this means recording where each root and issuing key lives, whether it sits in a hardware security module, a cloud KMS or a YubiKey, and who holds administrative control. step-ca can protect CA keys in HSMs, cloud KMS or YubiKeys, and cert-manager and OpenBao depend on the same custody decisions. Requirement 3.6.1.1 applies only to service providers, so confirm with your QSA whether the HSM inventory is needed for your entity type.

Change tickets link each new or replaced certificate to a documented request, an approver and a deployment record. Where renewals are fully automated through ACME or cert-manager, the ticket can be a standing change covering the automation, with its configuration recorded and version controlled. Assessors often sample certificates that were added manually, so those always need an individual ticket. Ask your QSA whether automated renewals need per-certificate tickets or a single approved change.

Expiry monitoring alerts show that the team tracks validity before a certificate lapses, which supports the requirement that certificates are confirmed valid and not expired. Keep the alert rules, the notification history and the acknowledgment or renewal record for each alert. Monitoring should cover certificates in the inventory and any that scans discover, so an unregistered certificate also triggers an alert. Confirm with your QSA the retention period for alert history, because it is commonly requested as sample evidence.

The effort follows the size and spread of your certificate estate, not the requirement text itself. The main drivers are the number of endpoints and services that terminate TLS for cardholder data, how many certificate authorities and issuing paths you already run, how large and dynamic your Kubernetes footprint is, and how many certificates come from third parties such as payment processors, hosting providers or public CAs. Each additional CA or issuing path adds a source to reconcile, and each third-party certificate needs an owner and a renewal path recorded. Ask any implementation partner to size the work from a list of in-scope hosts, load balancers, ingress controllers and CA exports rather than from a headcount guess.

Often yes, if the environment is small, the CA is a single well-documented system and someone on the team can export certificate data and run scans. The harder part is the reconciliation: matching what the CA issued against what scanners see on the network, then deciding which certificates protect cardholder data in transit and which do not. Teams without a PKI owner, or with certificates spread across several CAs and manual deployments, usually need outside help for the discovery and reconciliation step. Whether you build it in-house, partner or buy a tool, the inventory still has to be owned and maintained by your organization.

The work needs three groups with different inputs. CA administrators provide exports of issued, renewed and revoked certificates, along with issuance profiles, lifetimes and key storage details. The network or infrastructure team provides scan results, load balancer and gateway configurations, and the list of services that accept connections from untrusted or public networks. The Qualified Security Assessor, or your internal assessor if you use one, agrees on the scope: which systems store, process or transmit cardholder data, which connections cross open, public networks, and how segmentation limits the affected components. Settle that scoping early, because it determines which certificates belong in the inventory.

The initial build is one-time work: collecting CA data, running discovery, reconciling sources, assigning owners and writing the first description of each certificate's function. Recurring work is what keeps the inventory accurate. It includes reviewing new and renewed certificates, updating records when systems change, monitoring expiry, handling revocations and re-checking third-party certificates. Requirement 4.2.1 also expects certificates to be confirmed valid, not expired and not revoked, so the recurring process needs a defined owner and a review cadence. Ask any partner to separate one-time and recurring costs in the quote and to state who runs each recurring task after handover.

No. The PCI Security Standards Council does not certify, endorse or approve individual tools for certificate inventory or any other purpose. The standard describes what must be in place, and an assessor reviews the evidence your organization produces. A tool can help you collect and track data, but you still need to show that the inventory is complete, accurate and maintained. Compliance is validated through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, and a certificate or badge from a vendor is not recognized as validation. Confirm with your assessor how they will review the inventory before you buy or build anything.

DeployOpen works mainly on fixed-scope engagements. Before work starts, the scope, deliverables and timeline are agreed in writing, and the quote follows from that written scope. In practice, the scope should name the CAs and issuing paths in view, the discovery sources to be used, the number of environments and Kubernetes clusters, the third-party certificates to cover, the recurring processes to hand over and the evidence the assessor will need. DeployOpen does not publish a price list, so ask for a quote based on your own inventory data. DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications; your QSA or the relevant certification body does.

Prepare a short data pack so the quote reflects your actual estate. Useful items include a count of in-scope hosts and services, a list of CAs and issuing tools, a sample export of issued certificates, current scan output or network discovery data, a list of Kubernetes clusters, and the names of the QSA and internal owners. Ask the partner to state assumptions, the handover of the recurring process, what they will not cover, and how changes to scope are priced. For reference, the PCI DSS v4.0.1 requirement text is the source to check against, and your assessor should confirm the final scope before any figures are discussed.