The certificate inventory your auditor asks for, and why your cloud console can't produce it

An auditor asks for your certificate inventory. You open the AWS console, filter ACM to the right region, export a CSV. Domain name, status, expiry, ARN. Four columns. You send it over and feel fine about it.

Then the follow-up lands: which of these protect cardholder data in transit, what key sizes and signature algorithms are in use, what TLS versions and cipher suites do the endpoints actually negotiate, who owns each one, and can you show me this inventory was accurate three months ago as well as today.

None of that is in the export. Some of it isn't in ACM at all.

What the requirements actually say

People wave at "compliance" like it's fog. The PCI DSS 4.0 certificate requirements are not fog. They're a few short paragraphs, and you can read them yourself in ten minutes.

PCI DSS v4.0 / v4.0.1

Requirement 4.2.1 covers strong cryptography for PAN in transit over open, public networks. Four things have to hold: only trusted keys and certificates are accepted; certificates protecting PAN in transit are confirmed valid and not expired or revoked; the protocol supports only secure versions and configurations, with no fallback to insecure versions, algorithms, key sizes, or implementations; and the encryption strength suits the methodology in use.

Read that second one again. It doesn't ask whether you have monitoring. It asks that certificates are confirmed valid and not expired or revoked. Revocation checking is in scope. That lands badly on teams who built an expiry dashboard and called the control done. The bullet was future-dated and became mandatory on 31 March 2025, so it's live.

Requirement 4.2.1.1 is one sentence: an inventory of the entity's trusted keys and certificates used to protect PAN during transmission is maintained. Also future-dated to 31 March 2025, also live. The scoping word is transmission, which makes this a different animal from the key management requirements in 3.6 and 3.7 covering keys that protect stored account data. Engineers conflate those two far more often than assessors do, and walking in with the right inventory for the right requirement saves you a round trip.

Notice what 4.2.1.1 leaves out: any review cadence. "Maintained" gets read by every assessor I've dealt with as "current at assessment time, and demonstrably kept that way." An annual refresh doesn't clear that bar.

Then there's 12.3.3, the one people miss. Cipher suites and protocols in use must be documented and reviewed at least once every 12 months, including an up-to-date inventory of all cipher suites and protocols in use, with purpose and where used, plus active monitoring of industry trends on their continued viability and a documented strategy for responding to anticipated cryptographic vulnerabilities.

"Purpose and where used" is the clause that kills people. A dump of enabled cipher suites is not an answer. The answer is a mapping from cipher suite to the systems negotiating it and the reason it's still turned on.

SOC 2

SOC 2 works differently, and the difference matters. The Trust Services Criteria never say the words "certificate inventory." CC6.1 wants logical access security over protected information assets, with points of focus that include using encryption to protect data and protecting encryption keys. CC6.7 wants information protected during transmission, movement, and removal, with a point of focus on encryption technologies or secure communication channels.

That's an outcome, not a deliverable. Your auditor decides what evidence proves the control operates. For anything with a public TLS surface, that evidence lands on the same artifact PCI names outright: a current, owned, attributed certificate inventory, plus proof the process producing it ran all period. PCI tells you what to hand over. SOC 2 lets your auditor decide for you, which is worse, because you find out in month nine.

The fields no cloud console exports

So here's what I'd actually collect. Your cloud provider knows some of it. Most of it, it doesn't.

Subject CN and the full SAN list. Issuer, and whether that's a public CA or your internal PKI. Key algorithm and size — RSA-2048 versus P-256 is exactly the kind of thing 12.3.3 asks about, and somewhere in your fleet there is an appliance still presenting RSA-1024. Signature algorithm. Serial and fingerprint, so you can tell that the same cert is deployed in four places rather than four certs existing. Not-before, not-after, revocation status. The TLS versions and cipher suites actually negotiated wherever the cert gets presented. Where termination physically happens: ALB, CloudFront distribution, Front Door, an nginx ingress pod, an F5, some vendor's edge. Whether the private key is managed and non-extractable or sitting in /etc/ssl/private where anyone with sudo can walk off with it. And an owning team.

ACM gets you a real slice of that. Its InUseBy field lists the ARNs of load balancers and distributions referencing a certificate, which is more than most systems bother to give you. What it can't tell you is what TLS policy those listeners enforce or what a client negotiates in practice, and the field goes empty the moment a certificate is used outside AWS-integrated services. Key Vault knows a certificate's policy, thumbprint, and whether the key is exportable or HSM-backed. Connecting that to the Application Gateway listener or Front Door route consuming it is a separate set of API calls across a separate resource graph. GCP Certificate Manager has certificates and certificate map entries, which helps, and then stops at the same wall.

One assumption worth dropping: that cloud-issued keys are never extractable. AWS added exportable public certificates to ACM, and Key Vault exportability is a per-certificate policy decision. "Is the private key extractable" is a field you record per certificate now, not something you infer from the provider name.

The owner column rots first

Every other field on that list is derived from the certificate or the connection. It regenerates itself. The owner column is pure human assertion, and it starts decaying the day someone changes teams.

Two things help. Make the owner a team identifier that resolves to an on-call rotation or a group alias, never a person's name — people leave, the payments-platform rotation doesn't. Then enforce it at issuance rather than at audit time, which is the part almost everyone skips. IAM policies can condition certificate requests on required tags. Azure Policy can deny resource creation without one. GCP has label constraints. If an untagged certificate can't be created, the owner column never rots, because there's nothing left to reconcile.

The alternative is retroactive owner archaeology in month eleven of an audit period. I've watched people spend a week on that. Twice.

Where the discovery gap lives

Cloud certificate services only know about certificates you handed them. That's not a flaw, it's the design. But it means their inventory is a subset, and nobody can tell you how big a subset without going and looking somewhere else.

What lives outside: certificates on EC2 and VM filesystems, some managed by certbot, some dropped there by a Chef run in 2021 that nobody has touched since. Java keystores, an archaeology project unto themselves. Appliances with web UIs — BIG-IPs, NetScalers, iDRAC and iLO controllers, storage arrays, the occasional printer with a self-signed cert that expired during the Obama administration. Services on ports that aren't 443: LDAPS on 636, SMTPS, syslog over TLS on 6514, Kafka brokers on 9093, database TLS, admin consoles on 8443. Vendor-managed SaaS sitting on your domain — status pages, docs sites, marketing subdomains, email click-tracking hosts — where someone else entirely issues and renews the cert but the name is yours and so is the finding. And internal PKI leaves for service-to-service mTLS, which in a mature Kubernetes estate may outnumber everything above combined.

Certificate Transparency covers one slice: publicly trusted issuance for your domains. It's excellent at that slice. It will surface the cert somebody provisioned through a personal Let's Encrypt account for a production hostname, and it will surface typosquats. It will never show you an internal CA leaf, because private CAs don't log to CT, and it can't tell you whether anything it logged is actually deployed.

Be honest about the arithmetic. Cloud APIs plus endpoint probing plus CT monitoring covers your public and cloud-managed surface well. Internal-only certificates still need host-level collection: osquery's certificates table, an Ansible fact-gathering pass over the standard trust store paths, keystore enumeration on JVM hosts, Windows certificate store queries. There is no remote-scan shortcut for a cert that only ever gets presented inside a VPC. Anyone who tells you otherwise is selling you an incomplete inventory with a nicer dashboard.

Why point-in-time evidence stops working

The old game: auditor schedules fieldwork, you generate a snapshot, the snapshot describes the fleet accurately for the week they're looking at it, everyone goes home.

Shortened lifetimes break that game.

The CA/Browser Forum's SC-081v3 timeline is already running. Since 15 March 2026, maximum certificate validity is 200 days. On 15 March 2027 it drops to 100. On 15 March 2029 it drops to 47, with domain validation reuse cut to 10 days.

Now run that against a SOC 2 Type II observation period, typically 6 to 12 months. At 200 days, a 12-month period sees essentially every public certificate you own replaced at least once. At 100 days, three or four times. At 47 days, roughly eight. The serial numbers in the inventory you exported in month two do not exist by month eleven.

That matters because auditors sample. They take your population, pick items, test them. Sample from a month-two list for a cert that's rotated twice since and the test either fails outright or turns into a long, unhappy conversation about whether your inventory means anything. A snapshot no longer describes a population. It describes a moment.

Which changes the shape of the deliverable. What satisfies an assessor stops being a spreadsheet and becomes a system: queryable, with retained history, able to answer "what did the inventory look like on 14 April" and "show me every certificate change on this endpoint during the period." The change records — issued, renewed, revoked, rebound to different infrastructure — are what demonstrate the control operated continuously. Continuous operation is the whole thing a Type II report attests to.

Building the evidence pipeline

One system of record. Not the wiki, not a shared sheet, not "the wiki and also Jim's sheet." One system, one named owning team, and everything else reconciles against it. Two systems of record means zero.

Feed it cloud inventories on a schedule. ACM is regional, so enumerate every region in every account, and remember that CloudFront certificates have to live in us-east-1 no matter where the origin sits. Key Vault across every subscription. Certificate Manager across every project. Read-only roles, assumed rather than stored, wherever the provider supports it.

Then probe the endpoints, because this is where most inventories quietly become fiction. The API tells you which certificate is attached. Only a connection tells you what version and cipher suite get negotiated, whether the chain is complete, whether stapling works, and whether a second listener on the same host is still serving last year's cert to anyone who asks. The API answer and the wire answer disagree more often than anyone expects, and 12.3.3 is asking about the wire.

Monitor CT logs for your registrable domains. Anything you can't map back to something you knew about is shadow IT, a forgotten vendor, or a genuine problem. All three earn a ticket.

For internal PKI, push osquery or config-management output into the same store with the same schema, so internal and external certs are queryable in one place rather than two half-answers you join by hand at audit time. Enforce owner tagging at issuance, per above — highest-leverage item here by a distance. And export a dated report every period: timestamped, retained, with the query that produced it stored next to it. Twelve boring monthly exports beat one heroic export in month eleven, every time.

Keeping the multi-cloud, external-endpoint, and CT sides of this current is what CertPulse does. Host-level collection for internal PKI you'll still wire up yourself with osquery or Ansible.

What this doesn't solve

Automation gets you an accurate, current, historical inventory. It makes exactly zero scoping decisions. Whether a given certificate protects PAN in transit, where your cardholder data environment boundary sits, whether a vendor-managed subdomain counts as in scope, whether a segment is adequately isolated — human judgment, all of it, documented in your scoping exercise and defended to your assessor. The inventory feeds that work. Any tool claiming to determine your CDE boundary for you is selling you a story.

But the scoping conversation goes very differently when "what certificates exist and where are they terminated" is a query instead of a two-week discovery project. For most teams today, the honest answer to that question is a spreadsheet with question marks in the owner column. In three years, when a certificate's entire life is shorter than a sprint, that spreadsheet will be stale before the auditor finishes opening it.