Certificate management is easy to overlook as a part of security infrastructure, but they frequently surface in audits, especially in regulated industries. When it happens, auditors usually want to see four things:

A list of every certificate in scope
Proof no certificate is expired or untrusted
A documented process for issuing and renewing certificates
A record showing that process was followed.

Different frameworks have different requirements: PCI DSS asks for these directly, while ISO 27001 and SOC 2 have cryptography and asset inventory controls that cover certificates. The evidence to satisfy the auditor is usually the same: if you can produce the list and the process document, you’re usually fine.

The problem is that those documents can be hard to produce. Few organizations have a full inventory of all certificates and their complete history. Even if the list can be assembled, it’s often laborious because it requires manually pulling data from disparate sources.

Without a centralized source of truth, manual certificate management can create compliance risks: Can you prove your documentation is exhaustive? Did your process hold for the whole audit period?

If your business hinges on compliance, it’s important to look at how you handle certificates.

What do auditors look for in certificate management?

Auditors look for the same four kinds of certificate evidence across PCI DSS, ISO 27001, and SOC 2:

An inventory. Every certificate protecting in-scope data, with the certificate authority (CA) that issued it, its expiry date, its key algorithm and strength, and an owner.
Validity. No expired or revoked certificates in use, and clients that refuse a certificate they can't verify.
A documented process. How certificates are requested, approved, issued, renewed, and revoked, and which CAs are allowed to issue them.
A history. Records showing the process ran the way the documentation says it does, including who did what.

Proving inventory and validity are usually a matter of admittedly annoying work, but they can be done. The process is different because it needs to be set in advance. If every person on the team has had full CA access for a year, you can’t undo that when an auditor comes around. The history is the hardest part because many organizations manage certificates with such a patchwork of tools that no single audit trail exists.

How do auditors test certificate controls?

Auditors usually sample an inventory instead of reading it end to end. This happens both ways:

From the inventory to the network. The auditor picks entries from your list and wants to see the endpoint serving it, the issuance record, and the approval (if required).

An entry for a revoked certificate would be a finding.
From the network to the inventory. The auditor picks endpoints from your network and asks you to find specific certificates on your list.

A finding here would look like a self-signed certificate that was never registered anywhere.

For a SOC 2 Type II report, the samples span the observation window to prove you’ve been following best practices throughout the period, not just recently. This is why a clean spreadsheet on audit day can fail.

Which compliance frameworks require certificate management?

PCI DSS v4.0.1 explicitly requires certificate management practices. ISO 27001 and SOC 2 cover certificates through broader controls. The latter two require you to have a policy that covers certificates, but doesn’t mandate any specific policy.

	PCI DSS v4.0.1	ISO 27001:2022	SOC 2
Names certificates in a requirement	Yes, 4.2.1 and 4.2.1.1	No. Covered by the cryptography control, Annex A 8.24	No. Covered by the CC6.1 and CC6.7 criteria
What the auditor checks you against	The standard's own requirements	Your cryptography policy	The controls you describe in your system description
Point in time or over a period	Point in time, annually	Point in time, with annual surveillance audits	Type II covers an observation period, usually 3 to 12 months
Scope	Certificates protecting cardholder data in transit	Whatever your Statement of Applicability includes	Systems inside your report's boundary

What does PCI DSS v4.0 require for certificates?

Because PCI DSS protects specific types of infrastructure and transactions, it is the most opinionated about certificates. It demands certificates protecting cardholder data in transit to be valid, trusted, and inventorized.

These have been mandatory since March 2026 and are stated in two places:

Requirement 4.2.1 requires valid and trusted certificates. Certificates protecting primary account numbers (PAN) over public networks can't be expired or revoked. This is a simple pass/fail. But it also demands your systems must accept only certificates they can verify, which is trickier.

Here, the assessor looks at client configuration, so there are settings that can sneak in during development that can cause findings:

InsecureSkipVerify: true in its Go HTTP client
verify=False in Python
NODE_TLS_REJECT_UNAUTHORIZED=0 set to get past a certificate error in staging

This configuration is sometimes set to unblock a test, but can stick around if not revisited. An innocent error would fail the PCI DSS requirement.

Requirement 4.2.1.1 requires an inventory. You need a maintained inventory of the keys and certificates protecting PAN in transit and prove that you keep it current. This can be relatively automatic with a tool like Infisical Certificate Management, but it requires being able to track certificates everywhere:

Internal traffic: The wording is somewhat ambiguous, but some auditors will expect you to cover internal traffic handling PANs as well as public networks.
Shared wildcard certificates. A *.example.com certificate can create wider obligations because its scope can grow quickly and encompass compliance-relevant domains.
Cipher suites and protocols. Requirement 12.3.3 asks for a yearly-reviewed inventory of cipher suites and protocols in use, which comes from similar endpoints as certificates.

Keys that encrypt stored cardholder data are a separate problem, covered in our guide to secrets management requirements for PCI DSS 4.0.

What does ISO 27001 require for certificates?

ISO 27001:2022 doesn’t mention certificates explicitly, but requires you to write and follow rules for cryptography, key management, and keeping an inventory. Since each certificate and CA has a private key, what applies to keys also applies to certificates.

In practice, the auditor most likely reads your cryptography policy and samples certificates against it. If your policy says certificates are renewed 30 days before expiry and come only from approved CAs, the auditor might verify this with a few certificates.

Some organizations fail because they write a perfect policy that ends up being impossible to implement. If some of your certificates are renewed by hand, you’ll never have perfect coverage for a rule that states you renew certificates after a given number of days. If you write a policy, you should be able to automatically enforce it to comply with your own rules.

Certificates and CA keys also belong in your asset inventory, and auditors reviewing the cryptography control often ask to see them there.

What does SOC 2 require for certificates?

The certificate-related criteria in SOC 2 cover encryption keys, asset inventory, and encrypting data in transit. Certificates have to do with each.

Because SOC 2 makes no specific demands of your certificate management, you need to write your own policy and prove you follow it. You describe your controls and the auditor tests those. If you write "production certificates are issued from the approved internal CA and monitored for expiry" means you need to do it.
SOC 2 Type II’s observation period can change what you need to provide. The auditor samples events across a window, usually 3 to 12 months. Your own policy must be narrow enough to always be true. "All certificates are renewed automatically" fails if any is ever renewed by hand.

What certificate evidence satisfies all three frameworks?

Most of the evidence overlaps, so one set can serve all three audits, as long as it is a record kept over time rather than a snapshot.

Evidence to have ready	PCI DSS v4.0.1	ISO 27001:2022	SOC 2
Certificate inventory with issuing CA, expiry, key algorithm and size, and owner	4.2.1.1	5.9, 8.24	CC6.1
Documented procedure for issuing, renewing, and revoking certificates	4.2.1.1	8.24	CC6.1
Proof the inventory is current: discovery scans or issuance records reconciled against it	4.2.1.1	5.9	CC6.1
Validity checks: no expired or revoked certificates in scope, and clients reject untrusted ones	4.2.1	8.24	CC6.7
Log of issuance, renewal, and revocation events, with who performed each	4.2.1.1	8.24	CC6.1, sampled over the Type II period
Access control over who can issue certificates and who can reach CA keys	4.2.1	8.24	CC6.1
Expiry monitoring and alerting	4.2.1	8.24	CC6.1, and availability criteria if in scope
Cipher suite and protocol inventory, reviewed every 12 months	12.3.3	8.24	CC6.7

Before the assessment, ask two questions of each row: could you hand this to the auditor today, and would it cover the last 12 months or only this week?

Why is the certificate inventory the hardest evidence to keep current?

It’s hard to keep an authoritative certificate inventory because few organizations can reliably discover every certificate created on their infrastructure. A cloud load balancer might provision its own certificates, a Kubernetes cluster runs cert-manager, a vendor appliance ships with a built-in cert, etc. If these need to manually be added to a spreadsheet, you’re guaranteed to miss some.

Renewal is even harder because serial numbers and expiry dates must be updated in your inventory, which creates another manual workflow that’s easy to forget. Public TLS certificate lifetimes are shrinking from 200 days today to 47 days by 2029, which roughly quadruples renewals.

Automating an accurate inventory requires two main things:

Issuance records that log everything that goes through your CA or certificate manager.
Ongoing discovery that captures what is actually being served on your network, including certificates that never went through the process.

As long as you ensure coverage of your infrastructure, this results in an asset inventory that’s almost up to date. To automate further parts of your policy, look into automating certificate management more generally.

One way to do so is to use a dedicated certificate management tool.

How does Infisical produce certificate compliance evidence?

Infisical Certificate Management unites the inventory, history, and access controls and enforces the policies you’ve written. This makes it easier to submit evidence to the auditor and makes life easier for your team.

Keep track of all certificates. Infisical integrates with a broad range of tools and CAs to automatically issue certificates over ACME, EST, SCEP, or API. Certificate syncs push certificates and renewals automatically, which means you have proof of every issuance, revocation, or renewal.

Prove certificates both ways. Infisical stores detailed data, which means every certificate’s details are easy to find, and each action is logged. This includes Certificate discovery scanning domains, IP addresses, and CIDR ranges over TLS. This means you can directly connect a specific certificate to your inventory and vice-versa.

History across the audit period. Infisical keeps the old certificate after a renewal. It sticks around marked Renewed, which makes it better in case of an audit. The certificate search API makes it easy to find any certificate. Audit logs record issuance and revocation. Approval requests keep who asked, who approved, and what was issued.

The policy you wrote, enforced. Certificate policies constrain names, maximum validity, key algorithms, and key usages. Out-of-policy requests are denied, which gives you proof that the policy you wrote is enforced.

Separation of duties and CA keys. Access control separates admins (with rights to manage CAs and policies) from teams (who issue certificates within applications), so nobody can read or write something they shouldn’t.

Expiry. Alerts go out before expiry to email, Slack, PagerDuty, or a webhook. Infisical can renew certificates whose keys it manages on its own schedule, and ACME clients such as cert-manager renew theirs.

Infisical can also be fully self-hosted, which matters when the certificate system itself sits inside a PCI or ISO scope boundary.

If you are building out the internal CA side of this, our guide to running an internal PKI covers the architecture, and the certificate management guide covers the full lifecycle.

FAQ

Does PCI DSS 4.2.1 apply to internal certificates?

The validity requirement, 4.2.1, applies to PAN sent over open, public networks, and encrypting PAN internally is recommended rather than required. The inventory requirement, 4.2.1.1, is worded more broadly, so confirm the scope with your QSA before you leave internal TLS out.

Is a spreadsheet acceptable as a PCI DSS certificate inventory?

PCI DSS does not prescribe a format, so a spreadsheet can satisfy the inventory requirement. It fails when certificates are issued or renewed outside the process that updates it, which is exactly what a network-to-inventory sample finds.

Does SOC 2 require automated certificate renewal?

SOC 2 does not require automation. It tests whether the controls you describe operated throughout the observation period. Automation matters because a manual renewal process has to produce a record for every certificate across months, and one missed renewal is an exception in the report.