We talk to organizations daily that are preparing for PCI DSS 4.0 requirements. March 31, 2025 marks the end of the transition period, and on this date, businesses must be fully compliant with PCI DSS v4.0.1.
One of the ways PCI 4.0.1 varies from PCI 3.2 is an updated Requirement 4, which covers encrypting cardholder data transmissions over public networks to protect sensitive information from unauthorized access and interception. The PCI Security Standards Council describes this change as a way to “reflect the focus on ‘strong cryptography’ to protect transmissions of cardholder data.”
Let’s unpack exactly what has changed, and the best way to build an inventory of certificates to be PCI DSS 4.0 compliant with as little effort as possible
The new certificate inventory requirement for PCI DSS 4.0
In v4.0.1 the PCI Security Standards added to Requirement 4. This blog will be dedicated to requirement 4.2.1.1, which reads:
“An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.”
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
By having an inventory, an organization can monitor core cryptographic assets and key expiration dates. This proactive tracking enables the organization to address vulnerabilities identified in encryption software, certificates, and cryptographic algorithms.
The PCI Security Standards Council also notes that it is good practice for the certificate inventory to include the issuing CA and certification expiration date.
Different approaches for building a certificate inventory for requirement 4.2.1.1
We are going to go through a couple of different ways you can build your certificate inventory. All of the methods we discuss here will be centered around five core steps:
- Prioritization of the assets that are in scope based on PCI requirements. This includes certificates for third party owned assets like payment gateways on your site.
- Using identifiers to track in scope certificates.
- Once you know what is in scope you can export the reports of the assets to show a full and complete inventory of certificates.
The approach that works best for you will depend on the current state of your certificate estate, the complexity of your estate, and the resources that you have dedicated to managing the estate and ensuring compliance with PCI 4.0.1.
Spreadsheets
Spreadsheets are commonly used by organizations to track and manage the certificate estate and could be used for an inventory for Requirement 4.2.1.1.
Who is it good for
If an organization is using spreadsheets today to track certificates, creating a similar version for tracking certificates used to protect PAN during transmission can be an acceptable way to satisfy the PCI 4.0 requirement.
While it’s not the most sophisticated approach, it can work assuming there is rigorous upkeep and dedicated resource for manual tracking. If a team is stretched thin without headcount to ensure the spreadsheet is up to date, this is the wrong approach.
This is also the wrong approach if you currently use a spreadsheet but it is outdated or incomplete. You will want something automated that will help you start with an up to date inventory. More on that below.
How to do it
- Define the Required Data Fields. Identify all the necessary data points that need to be tracked for each certificate. This would include things like:
- Certificate Name/ID: A unique identifier for each certificate.
- Issuer: The Certificate Authority (CA) that issued the certificate.
- Subject: The entity for which the certificate was issued (e.g., domain name).
- Type of Certificate: SSL/TLS, Code Signing, Client Certificate, etc.
- Key Strength: The cryptographic strength of the certificate (e.g., 2048-bit RSA).
- Algorithm Used: The cryptographic algorithm used (e.g., RSA, ECC).
- Validity Period: Start and end dates of the certificate.
- Expiration Date: When the certificate is due to expire.
- Key Custodian: The individual or team responsible for managing the certificate.
- Usage: The specific application or system where the certificate is used.
- Revocation Status: Whether the certificate has been revoked.
- Renewal Status: Notes on whether the certificate is up for renewal.
- Vulnerability Notes: Any known vulnerabilities related to the certificate or associated algorithms.
- Comments/Notes: Additional remarks or actions related to the certificate.
- Populate the Spreadsheet. Enter the information for each certificate into the corresponding row and column.
- Implement Conditional Formatting. Set up conditional formatting to flag certificates that are nearing expiration (e.g., highlight certificates expiring within the next 30 or 60 days in red or yellow).
- Create Reminders and Alerts. Use spreadsheet functions to calculate the number of days until expiration and create automatic alerts or reminders for certificates that need renewal.
- Regular Review and Updates. Schedule regular reviews of the spreadsheet to ensure all information is current. Update the spreadsheet whenever a certificate is issued, renewed, or revoked.
- Secure the Spreadsheet. Ensure the spreadsheet is stored securely, with access limited to authorized personnel only. If the spreadsheet contains sensitive information, consider encrypting it or storing it within a secure, PCI-compliant environment.
Using a Certificate Lifecycle Management (CLM) Tool
Certificate Lifecycle Management tools (like AppviewX and Venafi) were created to automate the issuance, renewal, and deployment of certificates. Given the number of steps in the process – and the mistakes that can happen – CLM emerged as a way for security and IT practitioners to get a handle on their certificate estates.
Who is it good for
By design, CLMs must be comprehensive in their scope so that they can sign, validate, issue, deploy, revoke, and report on a certificate. For existing CLM users, there is functionality within these tools to help satisfy PCI requirement 4.2.1.1.
Some CLMs also help inventory trusted keys which is another part of requirement 4.2.1.1.
For those that don’t currently have a CLM, deploying one can be cumbersome and resource intensive (with user manuals that are 2,761 pages long).
The other scenario that can make CLMs a poor fit is complex certificate estates that require complex discovery scenarios. While CLMs do offer automated discover, the seeding, integrations and discovery methods can take time to configure and miss critical certificates.
How to do it
The exact process you follow will vary based on the CLM tool you are using. Here we will describe at a high level the steps you need to take regardless of the tool you are using.
- Start with certificate discovery. Depending on the CLM tool you use and where you are in your journey of certificate management, this process may be more or less resource intensive. Refer to your CLM providers docs for integrating with CAs and scanning your infrastructure to make sure all of the certificates that fall in scope of PCI 4.0 are discovered.
- Start with the CLM inventory. These tools provide a centralized repository where certificates across your organization can be discovered, inventoried, and managed. Some CLMs can integrate with various Certificate Authorities (CAs) to import certificate details.
- Leverage audit logs and compliance reporting. Most CLM platforms maintain detailed audit logs of all actions taken on certificates. Some can also generate compliance reports that align with PCI DSS requirements, making it easier to demonstrate compliance during audits.
Using a certificate monitoring app like Red Sift Certificates
We’re obviously biased, but we think a certificate monitoring tool – like Red Sift Certificates – is one of the best ways to build your certificate inventory to meet requirement 4.2.1.1.
Who is it good for
Red Sift Certificates is good for businesses that lack confidence that they have complete visibility of their current certificate inventory. This is because Red Sift Certificates is the only tool on the market that monitors Certificate Transparency (CT) Logs in real-time to see every certificate as it is issued. To date, Red Sift Certificates has processed over 7 billion certificates. Its configuration and deployment monitoring is conducted from 10 global locations.
For those worried about expiring certificates, this CT log monitoring also keeps information about deployed certificates constantly fresh. Red Sift Certificates is suitable for those who already have or are seeking a solution for automating the rotation of certificates.
However it is important to note that unlike CLMs, Red Sift Certificates does not automate the renewal process.
How to do it
Building a certificate inventory for PCI 4.2.1.1 is easy with Red Sift Certificates.
- Discover all of your certificates. Enter a single seed domain and Red Sift Certificates will identify all of your organization’s certificates. We know, this sounds too good to be true, but with a single domain Red Sift Certificates can create a complete inventory of all owned, third-party, self-signed and private certificates that are visible on the internet. The app does this by discovery then monitoring all hostnames and network ranges that belong to your organization. We can even connect to your cloud computing instance. And best of all, this can be done in less than an hour.
- Tag all certificates in scope of PCI. Using simple groups or tags, you can annotate which certificates are in scope of Requirement 4.2.1.1 so you have an easy way to report.
- Export as needed. Export your inventory as a .csv, .xls, or JSON file to document the inventory. This can be done based on time since last export, or whenever something changes based on user preference and need.
Take action before March 31, 2025
If you are looking to build a certificate inventory and think Red Sift Certificates could be the right approach for your organization, drop us a line, or book a demo. Our team members will be happy to help you build your inventory ahead of the PCI 4.0.1 deadline.
If you have questions about the upcoming cryptographic requirements for PCI 4.0.1, tune in to our on-demand webinar to find out more.
