47-Day Readiness Audit Checklist

💡 Your CLM tool's inventory and your actual inventory are different numbers. CT logs are the truth source for public certs.

💡 Shadow certificates are the #1 discovery gap. Developers provisioning Let's Encrypt certs in CI/CD pipelines won't show up in Venafi or Keyfactor unless you've configured discovery for those environments.

💡 Don't forget DR/failover sites — they often have certificates that only get attention during an actual failover.

💡 "Semi-automated" means "manual" when it matters. If a human has to click "approve" at 3 AM on a weekend, it's manual.

💡 The honest split for most enterprises is 20–40% automated, 60–80% manual. If your number is higher than 50% automated, double-check — you may be counting "auto-renew enabled in the CA portal" as automation when deployment is still manual.

💡 The 10-day DCV reuse window (8 days effective) means ~35 domain validations per cert per year in Phase 3. If any of those require a human, your pipeline is broken.

💡 DNS-01 is the most flexible method and the only one that works for wildcards. Prioritize DNS-01 automation above all else.

💡 If you manage DNS through a ticketing system ("open a ticket to create a TXT record"), that's a human dependency that won't scale.

💡 Let's Encrypt rate limits: 50 certificates per registered domain per week. At 500 certs on 47-day rotation, that's ~40 renewals/week — you're fine. But burst renewals after a mass expiry could hit limits.

💡 "Works in dev, breaks in prod at scale" is the most common issuance pipeline failure. Test with realistic volume.

💡 If you use a CLM (Venafi, Keyfactor, DigiCert Trust Lifecycle, Sectigo SCM), verify that its ACME connector actually works for your environment — many CLMs have ACME support that's technically available but not production-tested in your specific deployment.

💡 Deployment is the #1 failure point in certificate automation. The renewal succeeds, the new cert sits in a directory, and nobody notices until the old cert expires and the site goes down.

💡 F5 BIG-IP is notoriously difficult to automate for cert deployment. If you have F5s, this is probably your biggest single risk area.

💡 "The CDN handles it" is only true if you've verified it. Cloudflare and AWS managed certs auto-renew. Custom certs uploaded to CDNs do NOT auto-renew.

💡 At 47-day validity with renewal at day ~30, you have roughly 17 days between "renewal should have happened" and "certificate expires." That's your entire response window.

💡 The most important alert isn't "cert expiring soon" — it's "renewal attempted and failed." By the time you get an expiry alert, you've already lost time.

💡 If your monitoring only checks certificate expiry dates and not pipeline health, you're monitoring the symptom, not the cause.

💡 Phase 1 is your free trial for automation. If anything breaks at 2x throughput, you have time to fix it before 4x (Phase 2) and 8x (Phase 3).

💡 Sectigo starts enforcing 199-day max on March 12, 2026 — 3 days early for safety margin. Check your CA's specific enforcement date.

💡 Frame this to leadership as infrastructure modernization, not a PKI project. "Certificate automation readiness" gets a shrug; "preventing the next certificate outage that takes down production" gets budget.

💡 The exception list is the most important output. Every cert on the exception list is a cert that will cause an outage in 2029 if you don't have a plan.

💡 Your readiness percentage is auto-calculated from all checked items in Sections 1–8. Use the progress bar at the top of this page as your readiness score.

💡 **Scoring guide:** 90–100% = ✅ Ready (automation in place, monitoring works, team prepared) | 70–89% = 🟡 On Track (core automation exists, gaps known and being addressed) | 50–69% = 🟠 At Risk (significant manual dependencies remain, timeline tight) | Below 50% = 🔴 Critical (major gaps — immediate action needed)

💡 Focus on Section 5 (Deployment) and Section 3 (DCV) first — these are the hardest to fix and the most common failure points.