The 3 Questions Every IT Team Should Answer About Their Certificates
Here’s a 30-second test that reveals whether your organization has a certificate management problem.
Answer three questions:
- How many certificates do you have?
- When do they expire?
- Who owns them?
If you answered all three with confidence — with specific numbers, dates, and names — you’re in the minority. And you probably don’t need this article.
If you hesitated on even one — you have a visibility gap. And that gap is where certificate outages live.
Question 1: How Many Certificates Do You Have?
This sounds simple. It’s not.
Most teams can tell you how many certificates their CA has issued. That’s a number you can pull from the Certificate Authority console. But “issued” is not the same as “active” or “deployed” or “relevant.”
What counts:
- Certificates issued by your internal AD CS
- Certificates from public CAs (DigiCert, Sectigo, Let’s Encrypt)
- Certificates on load balancers (F5, Citrix, AWS ALB)
- Certificates on network appliances (firewalls, WAFs, proxies)
- Certificates in cloud services (Azure Key Vault, AWS ACM, GCP)
- Self-signed certificates on test/dev systems that somehow made it to production
- Certificates on Linux systems that AD CS doesn’t manage
- Wildcard certificates shared across multiple services
The typical gap:
| What teams think they have | What they actually have |
|---|---|
| 200 certificates (AD CS count) | 400-600 certificates (full environment) |
| All from one CA | 3-5 different issuers |
| All on Windows | 30%+ on Linux, appliances, cloud |
| All tracked | 40-60% untracked or “unknown” |
The first step to managing certificates is knowing how many exist. Most teams undercount by 50-100%.
Why you’re undercounting
- AD CS only shows what it issued — not what’s deployed elsewhere
- Public CA portals show what you bought — not what’s actually in use
- Cloud-provisioned certs (ACM, managed certificates) aren’t in your on-prem inventory
- Self-signed certs on dev boxes don’t show up anywhere until they expire and break something
- Departed employees provisioned certs that nobody inherited
How to get the real number
# Start here: what AD CS knows about
certutil -view -restrict "Disposition=20" -out "CommonName,NotAfter,RequesterName" > issued-certs.csv
# Then scan your network for what's actually deployed
# (This requires a discovery tool or custom scanning)A complete answer to “how many?” requires scanning endpoints, not just querying CAs. Any cert that’s deployed and serving traffic is relevant — regardless of where it came from.
Question 2: When Do They Expire?
Knowing what you have is step one. Knowing when they expire is step two.
This question has two layers:
Layer 1: The data exists somewhere
Most certificates have an expiration date. If you have an inventory (even partial), you can sort by expiry. The question is whether anyone is actively monitoring that list.
Layer 2: The data reaches the right person at the right time
A spreadsheet with expiry dates is only useful if someone reviews it before those dates arrive. A certificate expiring in 14 days is only actionable if someone sees that alert and has time to act.
What “answering this well” looks like:
| Maturity Level | How You Know What’s Expiring |
|---|---|
| Level 0 (blind) | You find out when users report errors |
| Level 1 (reactive) | Someone checks a spreadsheet monthly |
| Level 2 (basic monitoring) | Automated script emails weekly report |
| Level 3 (proactive alerting) | Alerts at 60/30/14/7/1 days to named owner |
| Level 4 (automated) | Auto-renewal fires + deployment verified |
Most teams are at Level 1 or 2. They have some visibility, but it’s incomplete, inconsistent, or depends on one person checking regularly.
The danger of “we check monthly”
Monthly checks work for annual certificates. They don’t work when:
- Certificate validity is 90 days (Let’s Encrypt)
- Certificate validity moves to 47 days (upcoming industry change)
- Multiple certificates expire in the same week
- The person who checks is on vacation
- A certificate was provisioned between checks
What goes wrong
You have 400 certificates. You check monthly. In a given month:
- 3-5 certificates are within their 30-day expiry window
- Of those, 1-2 are on systems nobody remembers
- One expires on a Tuesday when the reviewer was out Monday
- That one breaks a customer-facing integration
This isn’t a skill problem. It’s a coverage problem.
Question 3: Who Owns Them?
This is the hardest question. And the most important.
A certificate without an owner is a certificate that nobody renews, nobody monitors, and nobody fixes when it expires.
Ownership means:
- A named person (not a team alias, not “IT,” not “the system”)
- Who receives expiry alerts
- Who is responsible for renewal and deployment
- Who gets paged when it breaks
- Who the auditor can ask “what’s the status of this certificate?”
The ownership gap:
| Certificate Type | Typical Owner | Common Problem |
|---|---|---|
| Web server (IIS) | Web/app team | Owner left. Nobody inherited. |
| Load balancer | Network team | ”Network team” isn’t a person. No one specific. |
| VPN gateway | Infrastructure | Provisioned 3 years ago. Original engineer left. |
| Partner API (mTLS) | Integration team | Cert was set up by a consultant. |
| Wildcard cert | Security team | Shared across 12 services. Who owns renewal? |
| Dev/test cert | Developer | ”Temporary” cert in production since 2022. |
The “nobody’s job” problem
Certificate ownership often falls in organizational gaps:
- Security team says “we set policy, not operations”
- Network team says “we manage the appliance, not the cert”
- App team says “we don’t manage infrastructure”
- Infrastructure team says “we didn’t provision that one”
Result: nobody owns it. Nobody monitors it. Nobody renews it. It expires. Someone gets paged.
What good ownership looks like
For every certificate, you should be able to point to:
- A named individual who is the primary owner
- A backup owner for when that person is unavailable
- A notification path (how do they learn it’s expiring?)
- A renewal process (what do they do about it?)
- A verification step (how do they confirm it’s deployed?)
If you can’t produce this for more than 80% of your certificates, your ownership model has gaps that will produce outages.
The Framework in Practice
These three questions form a simple qualification framework:
| Question | Confident Answer | Uncertain Answer |
|---|---|---|
| How many? | ”We have 847 active certificates" | "Probably around 200… maybe more” |
| When do they expire? | ”I can pull that report right now" | "I’d have to check a few systems” |
| Who owns them? | ”Every cert has a named owner in our system" | "The teams handle their own… I think” |
Scoring:
- 3/3 confident = You have a mature certificate management practice
- 2/3 confident = You have partial visibility (workable, but risky)
- 1/3 confident = You have a visibility gap that will cause outages
- 0/3 confident = You’re operating blind on certificate management
Why This Matters Now
These three questions have always mattered. But three trends are making the consequences of wrong answers worse:
Trend 1: Certificate volumes are growing
More microservices = more service-to-service mTLS certificates. More cloud workloads = more managed certificates. More APIs = more certificates. The number only goes up.
Trend 2: Certificate lifespans are shrinking
The industry is moving from 1-year to 90-day to (soon) 47-day certificates. Shorter lifespans mean more frequent renewals. More renewals mean more opportunities for failure. Less margin for error.
Trend 3: Same team sizes
Certificate volumes double. Certificate lifespans halve. Team headcount stays flat. The math doesn’t work without either automation or tooling.
The 30-Second Assessment
Use this as a self-check. Or use it with your team in your next infrastructure review:
| # | Question | Your Answer | Confidence |
|---|---|---|---|
| 1 | How many active certificates in your environment? | ___ | High / Medium / Low |
| 2 | Can you produce a list of everything expiring in 30 days? | ___ | High / Medium / Low |
| 3 | Is there a named owner for every certificate? | ___ | High / Medium / Low |
If any answer is “Low” confidence — that’s your starting point. That’s where the next outage is hiding.
Next Step
We use these three questions as the opening of every certificate risk assessment we run. The answers tell us exactly where the gaps are and how urgent the fix needs to be.
If you want to run through this with actual data from your environment — 30 minutes, no pitch, just answers — let’s talk.
Related: Do You Actually Need a CLM Platform? →
Tags: Certificate Management, Certificate Visibility, Certificate Inventory, PKI, Certificate Ownership, AD CS, Certificate Assessment, Certificate Monitoring