Skip to main content

Certificate Rotation and Inventory Matter for PCI DSS 4.0

· 7 min read
Wojciech Kotłowski
Senior Technical Writer

As organizations modernize their security architecture, compliance with PCI DSS 4.0 brings sharper focus to cryptographic hygiene — particularly the management and rotation of digital keys and certificates that they depend on. While PCI DSS doesn't explicitly demand that certificates be rotated, it does require regular cryptographic key rotation and a maintained inventory of all trusted keys and certificates. Given that certificates are tightly coupled with cryptographic key pairs, this means certificate rotation is an essential part of compliance.

In this post, we’ll unpack the relationship between certificate rotation, cryptographic key lifecycles, mutual TLS (mTLS), and PCI DSS 4.0 requirements — and provide guidance on how to stay compliant.

Digital certificates — such as those used in TLS or mTLS — are wrappers around public keys. These keys are part of a key pair, including a private key kept secret. When a certificate is used in a protocol like TLS, it signals to the other party that the sender holds a specific private key and a trusted certificate authority (CA) has verified the sender's identity.

Mutual TLS (mTLS) builds on this by requiring both sides (e.g., client and server) to present certificates, enabling two-way authentication. If either party’s private key is compromised, or if it ages beyond its secure cryptoperiod, the certificate becomes a weak point in the system. That’s why rotating certificates — and by extension, the key pairs they carry — is a non-negotiable part of secure communications.

What PCI DSS 4.0 Says About Key Rotation​

PCI DSS 4.0 does not mandate a fixed lifespan for cryptographic keys or certificates, but it sets clear expectations:

  • Keys must be rotated at the end of their defined cryptoperiod.

  • Organizations must document and implement cryptographic key rotation policies.

  • All trusted keys and certificates protecting cardholder data must be inventoried and monitored.

Certificates used for TLS/mTLS authentication fall within this scope, as they directly impact the confidentiality and authenticity of cardholder data in transit.

→ Read more about automated key rotation for PCI-DSS 4.0 compliance.

Why Certificate Rotation Matters for mTLS​

TLS banner

In mTLS, both parties authenticate each other using certificates that encapsulate public keys. If the associated private key is exposed or reaches the end of its cryptoperiod, the entire trust model is compromised. Rotating the certificate means:

  • Generating a new key pair.

  • Issuing a new certificate signed by a trusted CA.

  • Updating server and client systems with the new certificate.

  • Retiring the old certificate securely.

Failing to rotate mTLS certificates increases the risk of man-in-the-middle (MITM) attacks, expired trust chains, and compliance violations.

Certificate Inventory: A New Compliance Requirement​

PCI DSS 4.0 introduces explicit requirements for maintaining an inventory of certificates and trusted keys. This inventory must include:

  • Issuer and subject of each certificate.

  • Expiration dates.

  • Usage context (e.g., TLS, mTLS, encryption, code signing).

  • Key algorithm and key length.

Application Certificates Inventory

An up-to-date inventory helps ensure timely rotation before expiration and supports audit readiness. It also enables automated checks to avoid outages caused by expired or misconfigured certificates.

How Often Should You Rotate Certificates?​

While PCI DSS 4.0 allows organizations to define their own cryptoperiods, industry best practices suggest:

  • Client certificates (mTLS): Rotate every 90–180 days, especially if private keys are stored in software.

  • Server TLS certificates: Rotate every 90 days (aligned with Let's Encrypt and other short-lived CAs).

  • Certificates with keys in HSMs or secure elements: May allow for longer cryptoperiods (up to 1–2 years), but should still be evaluated based on risk.

Documented policies should define these intervals, supported by automated tooling to detect and replace certificates before expiry.

Recommendations for Certificate Management under PCI DSS 4.0​

To meet both the letter and the spirit of PCI DSS 4.0, organizations should adopt a proactive, policy-driven approach to certificate management. This starts with implementing automated discovery and renewal mechanisms to eliminate the risk of manual error and ensure continuity of service. Cryptoperiods for all key pairs and their associated certificates must be clearly defined and enforced, guided by a risk-based assessment of the underlying cryptographic material and its usage context.

Maintaining an up-to-date certificate inventory is essential — not only for compliance, but also for operational visibility. This inventory should include ownership, expiration data, usage type, and relevant key metadata. Coupled with monitoring systems, teams can be alerted in advance of upcoming expirations to avoid service interruptions.

Support for seamless rotation is critical, especially in environments using mTLS or pinned certificates. Techniques such as automated updates, phased certificate deployments, and zero-downtime key swaps help minimize disruption during renewal events. Finally, every certificate issuance, renewal, and revocation should be logged to create a comprehensive audit trail, supporting internal oversight and external assessments.

How the Raidiam Trust Platform Supports Certificate Rotation and Inventory​

The Raidiam Trust Platform is designed with strong cryptographic lifecycle management at its core, offering native support for certificate rotation, inventory tracking, and auditability — all essential for PCI DSS 4.0 compliance and beyond.

Certificate Rotation via Integrated PKI​

At the heart of the platform is a dedicated Public Key Infrastructure (PKI) responsible for issuing, managing, and revoking certificates across the ecosystem. This PKI enables automated issuance of certificates to organizations and their resources — such as applications, authorization servers, or APIs — through both UI and API workflows. These certificates can be configured with short lifespans, encouraging regular rotation and reducing risk associated with long-lived credentials.

Renewal workflows are supported natively, allowing expiring certificates to be rotated without manual deregistration or downtime. This is especially important in mutual TLS (mTLS) contexts, where seamless certificate replacement is critical to maintaining uninterrupted secure communication.

The platform also ensures continuity by binding rotated certificates to relevant OAuth and OpenID Connect metadata, preserving trust relationships between technical components even as certificates change.

Full Certificate Inventory Management​

All certificates issued or trusted within the ecosystem are tracked in a centralized, searchable inventory. This includes critical metadata like the subject and issuer, validity period, associated organization or technical component, intended usage (such as mTLS or transport layer security), and cryptographic algorithm and key length.

This detailed inventory gives administrators real-time visibility across the ecosystem. They can proactively monitor certificate expiration, validate that key lengths meet policy, and ensure rotation schedules are being followed — all aligning with PCI DSS 4.0's call for documented and enforceable key management practices.

Auditability and Traceability​

The platform logs every certificate lifecycle event — issuance, renewal, or revocation — in a tamper-evident way. These logs form a complete, non-repudiable audit trail, enabling ecosystem operators to trace certificate usage historically, support compliance checks, and investigate potential security incidents.

Logs can be queried directly through the platform’s user interface or exported to external SIEM systems, providing flexible integration into enterprise monitoring and audit workflows.

Final Thoughts​

Certificates are not just passive assets — they’re active components of your encryption and authentication strategy. If your certificates rely on aging or poorly managed keys, your compliance and security posture suffer.

PCI DSS 4.0 rightly emphasizes that protecting cardholder data in transit requires a complete view of the cryptographic landscape: from inventory to rotation. Organizations that adopt proactive certificate lifecycle management will be better positioned to meet compliance goals and reduce security risk.

Stay ahead of certificate expiry, cryptographic compromise, and compliance failures by treating certificate rotation and inventory as first-class citizens in your infrastructure.

Payment Industry Webinar

Beyond Static Secrets:

Modernizing API Security for PCI DSS 4.0

Sign Up Now →
Open Book IconTABLE OF CONTENT