How Many Internal Certificates Does Your Company Actually Have?
If your answer starts with “probably around…” — you have a visibility problem. And that problem is bigger than you think.
The Guess vs. The Reality
When we ask IT teams this question, the typical answer is somewhere between 200–500 certificates.
When we actually scan the environment, the real number is usually 1,500–5,000.
That’s not a rounding error. That’s a 3–5× gap between what teams think they manage and what actually exists.
| What Teams Estimate | What Discovery Finds | The Gap |
|---|---|---|
| 200–500 certificates | 1,500–5,000 certificates | 3–5× undercount |
| ”We know our important ones” | 60% were unknown to any team | Ownership: zero |
| ”Auto-enrollment handles it” | 40% are manually issued or imported | No renewal process |
The Certificate Visibility Gap
Typical enterprise: what's tracked vs. what actually exists
Tracking Coverage
Certificates Found by Source
⚠️ In the average mid-market enterprise, less than 15% of certificates have both ownership documentation and expiry monitoring.
Where Do the Extra Certificates Come From?
The gap exists because internal certificates get created from multiple sources — most of which don’t feed into a central inventory:
Auto-enrolled machine certificates — These exist on every domain-joined device. 1,000 devices = 1,000+ machine certs. Nobody counts these because “auto-enrollment handles it.”
Manually requested certificates — Engineers request certs for specific apps, services, or test environments through the CA web enrollment page or MMC. These live outside templates.
Self-signed certificates — Developers and DevOps teams generate self-signed certs for internal services, dev environments, and testing. Nobody tracks these.
Imported certificates — Certificates purchased from public CAs and imported to internal systems (load balancers, appliances, third-party integrations).
Service-specific certificates — Exchange, SCCM, SCOM, SQL Server, ADFS, WAP — each generates its own certificates during installation.
Forgotten infrastructure — Decommissioned servers still running with active certs. Lab environments. Legacy apps nobody wants to touch.
Why the Gap Matters
A certificate you don’t know about is a certificate you can’t manage. And a certificate you can’t manage will eventually expire — with no warning, no owner, and no documented remediation path.
Risk 1: Unmonitored expiry If it’s not in your tracking (spreadsheet, tool, or otherwise), nobody gets alerted when it expires. You find out from users.
Risk 2: No ownership Who’s responsible for renewing the certificate on that internal API? If the answer is “I don’t know” — that’s a future outage waiting.
Risk 3: Compliance gaps ISO 27001, PCI-DSS, and SOC 2 auditors increasingly ask: “Show me your certificate inventory.” If your inventory covers 30% of actual certificates, that’s a finding.
Risk 4: Crypto migration blockers Post-quantum migration requires knowing where current cryptographic assets are deployed. You can’t migrate RSA-2048 if you don’t know where it lives.
What a Real Certificate Inventory Looks Like
A useful inventory isn’t just a list of certificates. It maps:
| Data Point | Why It Matters |
|---|---|
| Certificate subject | What is it for? |
| Issuing CA | Internal? External? Self-signed? |
| Expiry date | When does it become a risk? |
| Key algorithm + size | Crypto posture (RSA, ECC, key length) |
| Location (server/store) | Where does it physically live? |
| Service binding | What depends on it? |
| Owner | Who fixes it when it breaks? |
| Template (if applicable) | Is it auto-enrolled or manually managed? |
Most teams have a partial view — they know about certs on their “important” servers. The other 60–70% lives in the shadows.
The Discovery Exercise
Here’s a quick way to sanity-check your certificate count:
Step 1: Query your CA database: certutil -view -out "Issued Common Name,Certificate Expiration Date,Certificate Template" csv > issued_certs.csv
Step 2: Count domain-joined devices (Active Directory): each one likely has 1–3 machine certificates.
Step 3: Check load balancers, reverse proxies, and network appliances — these are outside AD CS.
Step 4: Scan internal subnets for services presenting certificates on common ports (443, 8443, 636, 3389).
Step 5: Compare against whatever tracking exists today (spreadsheet, someone’s memory, nothing).
The delta between Step 5 and Steps 1–4 is your visibility gap.
What To Do About It
You need discovery before management. You can’t manage what you haven’t found.
- Run a certificate discovery scan across your internal network
- Query your CA database for everything ever issued (not just what’s “active”)
- Map certificates to services — which cert is bound to which application?
- Assign ownership — every certificate needs a team or person responsible
- Establish a tracking mechanism — spreadsheet (short-term) or CLM tool (long-term)
- Set up expiry monitoring — even a basic script that checks
NotAfterdates weekly
Next Step
We run a certificate discovery assessment that answers exactly this question — how many certificates exist in your environment, where they live, and which ones are untracked.
If you’ve never done a full internal certificate discovery, let’s start there.