Simplifying the Audit and Remediation of Keys and Certificates

Published: December 2023. Updated: August 2026. Reviewed by Encryption Consulting’s PKI and Key Management Advisory team.

Why do keys and certificates accumulate audit debt in the first place?

Cryptographic assets accumulate audit debt because they are created faster than they are tracked. A developer requests a TLS certificate for a staging server and it goes to production. A team generates an SSH key pair to script a deployment and never rotates it. A cloud service spins up a new encryption key and the security team finds out during the next compliance cycle, if at all. None of these are malicious; they are the ordinary friction of distributed teams provisioning cryptography faster than governance can follow.

The result is a gap between what your certificate and key inventory says exists and what actually exists in production. That gap is what an auditor finds, and it is what an attacker exploits: an orphaned key with excess privilege, an expired certificate silently disabling a revocation check, or a self-signed certificate someone trusted “temporarily” three years ago. Closing it is not a one-time project. It is a cycle of discovery, classification, remediation, and verification that has to run continuously because the underlying environment never stops changing.

Who owns the lifecycle of a key versus a certificate?

Ownership has to be assigned per asset type, because keys and certificates fail in different ways and answer to different stakeholders. A key with no named owner cannot be rotated safely because nobody can confirm what breaks if it changes. A certificate with no named owner renews itself into an outage the day nobody notices it expired.

Lifecycle stage	Cryptographic keys	Certificates
Generation	Key custodian or security team, inside an HSM or approved key management system, never on a developer laptop	Requested by an application/service owner, issued by an approved internal or public CA
Registration	Logged in a key inventory with algorithm, length, owner, and intended use	Logged in a certificate inventory with SAN, issuing CA, validity window, and deployment location
Active use	Access restricted by role; no direct administrator access to raw key material	Deployed to the exact endpoints that need it; discovery scans confirm deployment matches inventory
Rotation/renewal	Rotated at the end of its defined cryptoperiod or on a triggering event	Renewed before expiry, increasingly through automated enrollment (ACME/EST) as validity windows shrink
Retirement	Destroyed or archived per a documented key-destruction procedure with audit log entry	Revoked if compromised or replaced; removed from trust stores and inventory
Typical owner	Security/cryptography team (key custodian model)	Application or infrastructure owner, with a central PKI/CLM team as governance authority

The practical fix is a named accountable owner for every key and every certificate at the moment it is issued, not discovered after the fact. Certificate lifecycle management platforms and key management systems both support owner metadata as a first-class field precisely because “who owns this” is the single most common gap auditors flag.

What actually triggers a key rotation or certificate renewal?

Rotation should never be purely calendar-driven. A defensible program combines time-based limits with event-based triggers, and for certificates, an external constraint that is changing fast: the CA/Browser Forum’s shrinking maximum validity period.

Time-based rotation

NIST SP 800-57 Part 1, Revision 5 defines the cryptoperiod as the span of time a specific key is authorized for use, balancing the risk of a key being compromised the longer it stays active against the operational cost of rotating it. There is no single correct number; NIST leaves the exact interval to the organization’s risk assessment, algorithm, and key strength, but the principle is fixed: every key needs a defined maximum lifetime set in advance, not left open-ended.

Event-based rotation

A key or certificate should be rotated immediately, outside its normal schedule, when:

• An administrator with access to the private key changes roles or leaves the organization.
• A suspected or confirmed compromise occurs anywhere in the chain, including the issuing CA.
• An algorithm or key length is deprecated by NIST guidance or internal policy.
• A vendor, cloud provider, or third-party CA reports an incident that could have exposed key material.
• An audit finds the asset was issued outside the approved process (a self-signed or shadow certificate, an unregistered key).

The certificate-specific trigger: shrinking maximum validity

Certificates carry an additional, externally imposed rotation trigger that keys do not: the CA/Browser Forum’s Ballot SC-081v3 phases the maximum public TLS certificate validity period down on a fixed schedule:

Effective date	Maximum TLS certificate validity
Through March 14, 2026	398 days
March 15, 2026 to March 14, 2027	200 days
March 15, 2027 to March 14, 2029	100 days
March 15, 2029 onward	47 days

Domain validation reuse periods shrink on the same schedule, eventually to 10 days. This means an audit and remediation program built around annual or even quarterly manual certificate reviews will not keep up. By 2029, a certificate issued today will need to be replaced roughly eight times a year instead of once. We cover the operational math of that transition in more depth in Preparing for 47-Day TLS Certificates.

Who should have authority to audit and remediate keys and certificates?

Audit and remediation authority has to be separated from day-to-day issuance authority, or the audit is not really independent. A workable access model looks like this:

• Key custodians hold operational responsibility for specific keys but do not have unsupervised access to raw key material; dual control and split knowledge apply to any operation that could expose or misuse a key.
• Certificate/CA administrators can issue and revoke certificates within policy but cannot alter the audit log of their own actions.
• Auditors (internal security or external QSA/assessor) have read-only access to the full inventory, issuance logs, and policy configuration, with no ability to change what they are reviewing.
• Approvers for remediation actions (revoking a certificate, rotating a production key) are a separate role from the person who identified the finding, so no single person can both flag and fix a critical issue without a second set of eyes.

Administrators should never have standing, direct access to private key material outside a managed system, and any exception has to be logged and time-boxed. This separation-of-duties model is also what PCI DSS 4.0 and SOC 2 assessors expect to see documented, not assumed.

What evidence do auditors actually want to see?

This is the core of the problem most teams get wrong: they treat “we have a policy” as evidence. Auditors want proof the policy is followed, current, and enforced. For a cryptographic asset audit, that evidence generally breaks into four categories.

A complete, current inventory

PCI DSS 4.0 Requirement 4.2.1.1 requires organizations handling cardholder data to keep an up-to-date inventory of all cryptographic keys and certificates, including algorithm, key strength, expiry date, and the specific data each one protects. An inventory that was accurate at the last audit but has not been reconciled against a live discovery scan since is not current, and assessors increasingly ask for the scan date, not just the spreadsheet.

Documented, dated policy review

PCI DSS Requirement 12.3.3 requires organizations to document and review their cryptographic cipher suites and protocols in use at least annually, including a documented justification for continued use of any deprecated algorithm and a plan to migrate away from it. Auditors want a dated document, a named reviewer, and a change log, not a policy that has not been touched since it was written.

Access and operation logs

Every key generation, rotation, export, and destruction event, and every certificate issuance, renewal, and revocation, needs a secure, tamper-evident log entry: who performed the action, when, and under what approval. For SOC 2 engagements, this log is frequently the single piece of evidence that determines whether a control is rated as operating effectively or as a gap in the report.

Closed-loop remediation records

A finding without a documented remediation and re-verification date is an open finding, no matter how old it is. Auditors specifically look for evidence that a previously flagged issue (an expired certificate still in a trust store, a key past its cryptoperiod) was actually fixed and confirmed fixed, not just noted in a spreadsheet and forgotten.

What does a practical audit-and-remediation workflow look like?

Run the same five-step cycle whether the trigger is a scheduled internal audit, an upcoming PCI DSS assessment, or a SOC 2 renewal.

1. Inventory and discover. Run network and endpoint scans to find every key and certificate in use, then reconcile the results against the existing inventory. Establish a defined process for registering any key or certificate that scanning cannot discover, such as those embedded in offline systems or hardware devices.
2. Classify by risk. Score each asset by what it protects, where it sits (production versus non-production, internet-facing versus internal), how close it is to expiry or end of cryptoperiod, and whether its algorithm or key length still meets current policy.
3. Remediate. Fix the highest-risk findings first: revoke or replace weak or unauthorized certificates, rotate keys past their cryptoperiod, correct missing ownership, and remove test or non-production keys and certificates that migrated into production environments.
4. Verify. Confirm the fix actually took effect in production, not just in the management console. A certificate marked “renewed” that was never redeployed to the load balancer is still a finding.
5. Report. Produce a dated report showing what was found, what was fixed, what remains open with a target date, and who approved each remediation. This report is the artifact an auditor reviews, so it needs to stand on its own.

Two additional controls belong in every cycle regardless of asset type: preventing migration of non-production keys and certificates into production by restricting test CA usage to non-production systems, and maintaining a documented CA-compromise response plan that names who replaces which certificates, in what order, if a trusted root or intermediate CA is ever compromised.

Manual spreadsheet audits or automated discovery and inventory tooling?

The honest answer depends on scale, but the crossover point arrives earlier than most teams expect.

Factor	Manual/spreadsheet audit	Automated discovery and inventory tooling
Discovery coverage	Limited to what teams self-report; misses shadow and orphaned assets	Continuous network, endpoint, and cloud API scanning finds assets nobody reported
Currency of data	Accurate only as of the last manual review	Refreshed on a schedule or continuously, matching what auditors expect from 4.2.1.1
Scale	Manageable into the low hundreds of assets; breaks down beyond that	Scales to tens of thousands of keys and certificates across hybrid and multi-cloud environments
47-day validity readiness	Cannot keep pace with 8+ renewals per certificate per year by 2029	Automated renewal and enrollment (ACME/EST) built for high-frequency cycles
Audit log integrity	Depends on manual discipline; easy to fall behind or edit after the fact	System-generated, tamper-evident logs tied to every action
Cost profile	Low tooling cost, high and growing labor cost as inventory expands	Upfront platform cost, materially lower ongoing labor cost at scale

A spreadsheet is a reasonable starting point for a small, mostly-static estate. It stops being reasonable the moment certificate renewal frequency triples under the shortening validity schedule, or the moment an auditor asks for a discovery scan date rather than a self-reported list. Platforms like CBOM Secure are built specifically to close that gap by continuously discovering and inventorying cryptographic assets, including keys and certificates a manual process would never find.

What happens when an audit surfaces a critical finding?

Not every finding is routine. When an audit uncovers something that looks like an active compromise, a rogue certificate issued outside the approved CA, or a private key exposed in a public repository or log file, the remediation workflow above needs to hand off into incident response rather than sit in the normal remediation queue.

1. Contain. Revoke the affected certificate or disable the affected key immediately; do not wait for the normal rotation window.
2. Scope. Determine everything the compromised key or certificate could touch: what it authenticated, what it encrypted, what trusted it.
3. Notify. Loop in the incident response team and, where the finding involves a CA-level compromise or a regulated data type, the compliance and legal stakeholders who determine disclosure obligations.
4. Replace. Issue and deploy the replacement key or certificate, verified in production, before closing the finding.
5. Root-cause and prevent recurrence. Determine how the asset escaped normal governance (unregistered issuance, missing scan coverage, a policy gap) and fix the process gap, not just the single asset.

This is exactly why a documented CA-compromise response plan, with a maintained backup CA relationship, matters before an incident happens rather than after. Deciding who can remove a trusted root from production trust stores is not a decision to make for the first time under pressure.

Decision guide: where should you focus first?

Your current state	Priority action
No complete inventory of keys and certificates exists	Run a discovery scan before anything else; you cannot classify or remediate what you have not found
Inventory exists but is not tied to named owners	Assign an accountable owner to every asset before the next audit cycle
Certificates are renewed manually on expiry alerts	Move to automated enrollment (ACME/EST) now, ahead of the 100-day and 47-day validity milestones
Keys have no defined cryptoperiod	Set maximum lifetimes per NIST SP 800-57 risk guidance and enforce them in the key management system
Findings get fixed but not re-verified	Add a verification step to remediation before a finding can be marked closed
Preparing for a PCI DSS or SOC 2 assessment within 90 days	Prioritize evidence generation: inventory currency, policy review dates, and access logs

Limitations

No audit and remediation program eliminates risk entirely. Discovery scanning cannot find every asset; keys embedded in offline hardware, air-gapped systems, or legacy appliances still require a manual registration process, and that process depends on people following it. Automated tooling reduces but does not eliminate the need for defined roles and separation of duties; a platform cannot substitute for a named key custodian or approver. And no cryptoperiod or validity schedule protects against a key or certificate that was mishandled before rotation was ever due, which is why access policy and audit logging matter as much as the schedule itself.

What Would Encryption Consulting Recommend?

Treat keys and certificates as two connected but distinct audit tracks, and match tooling to each. For cryptographic discovery and inventory across your full estate, keys included, CBOM Secure gives you the continuous, auditor-ready inventory that a spreadsheet cannot maintain at scale, closing the exact gap PCI DSS 4.2.1.1 asks about. For the certificate side specifically, especially as validity windows compress toward 47 days, CertSecure Manager automates discovery, issuance, renewal, and revocation with the deployment verification and audit logging assessors expect to see.

Where a program needs an outside review before its next assessment, our Encryption Advisory services evaluate an organization’s existing key and certificate landscape, refine cryptographic and key management policy against current standards, and help build the evidence trail auditors and assessors actually expect, backed by our ISO/IEC 27001:2022 and SOC 2 certified delivery practice.

Frequently asked questions

How often should we audit our keys and certificates?
Discovery and inventory reconciliation should run continuously or at minimum monthly, given how fast unregistered assets appear. Formal policy review is required at least annually under PCI DSS Requirement 12.3.3, but organizations preparing for a SOC 2 audit typically run a full remediation cycle quarterly to keep evidence current between assessment windows.

What is the difference between auditing keys and auditing certificates?
Keys are governed by cryptoperiods, algorithm and length policy, and strict access control under NIST SP 800-57; the core question is who can touch the key material and for how long it stays valid. Certificates are governed by CA/Browser Forum validity limits, issuance policy, and deployment verification; the core question is whether the certificate presented in production matches what was actually issued and where it is supposed to be.

Do we need automated tooling, or can we manage this with spreadsheets?
Spreadsheets can work for a small, largely static inventory, but they cannot keep pace with continuous discovery requirements or the accelerating certificate renewal cadence created by the CA/Browser Forum’s move toward 47-day validity. Most organizations reach the point where automated discovery and inventory tooling pays for itself in avoided labor and avoided outages well before they hit that wall.

What is the biggest audit finding organizations get wrong?
Unowned assets. A key or certificate with no named accountable owner cannot be confidently rotated, renewed, or revoked, because nobody can confirm what depends on it. Assigning ownership at issuance, not after the fact, closes most of the findings a first-time audit typically surfaces.

What should we do first if an audit finds a compromised key or certificate?
Contain first: revoke the certificate or disable the key immediately rather than waiting for a scheduled rotation window. Then scope what it touched, notify incident response and compliance stakeholders, replace and verify the new asset in production, and fix the process gap that let the compromised asset go unnoticed.

Conclusion

Auditing and remediating keys and certificates is not a once-a-year compliance exercise anymore. It is a continuous cycle of discovery, classification, remediation, and verification, made more urgent by the CA/Browser Forum’s shrinking certificate validity schedule and made more rigorous by what PCI DSS 4.0 and SOC 2 now expect assessors to actually verify. The organizations that treat this as ongoing operational discipline, with named ownership, defined rotation triggers, and evidence generated as a byproduct of the workflow rather than assembled under deadline pressure, are the ones that walk into an audit with nothing to scramble for.

References

• NIST, SP 800-57 Part 1, Revision 5, Recommendation for Key Management: Part 1, General
• CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• DigiCert, TLS Certificate Lifetimes Will Officially Reduce to 47 Days
• Red Sift, Your Guide to PCI DSS 4.0 Cryptographic Requirements