AD CS + CLM: Why You Need Both (Not Either/Or)
AD CS vs. CLM: Capability Coverage
Each tool excels in its domain — together they provide full lifecycle coverage
AD CS = Issuance Engine
Templates, enrollment, renewal, key generation
CLM = Visibility Layer
Inventory, alerts, deployment, ownership, compliance
The Misconception That Costs You Outages
“We have AD CS. Why do we need CLM?”
This question comes up in every PKI conversation. And it’s the wrong question — because it assumes AD CS and CLM solve the same problem. They don’t. They solve different problems at different layers.
AD CS is an issuance engine. It signs certificates, enforces templates, handles enrollment. That’s its job. It does it well.
CLM (Certificate Lifecycle Management) is a visibility layer. It tracks what’s deployed, where it’s deployed, when it expires, and who owns it. AD CS doesn’t do this. It was never designed to.
Running AD CS without CLM is like running production servers without monitoring. The servers work fine. You just don’t know when they’re about to fail.
What AD CS Actually Does
AD CS handles the supply side of certificates:
| AD CS Function | What It Does |
|---|---|
| Certificate issuance | Signs and delivers certs based on templates |
| Template enforcement | Controls who can request what type of cert |
| Auto-enrollment | Pushes certs to domain-joined machines via GPO |
| Revocation (CRL/OCSP) | Publishes revocation status |
| Key archival | Stores private keys for recovery scenarios |
AD CS is good at this. The problem isn’t what AD CS does — it’s what it doesn’t do.
What AD CS Does NOT Do
AD CS has no awareness of what happens after issuance:
| Gap | Why It Matters |
|---|---|
| No deployment verification | Certificate issued ≠ certificate deployed |
| No expiry alerting | CA database knows validity period but sends no warnings |
| No inventory across sources | Only sees certs it issued — misses imported, external, self-signed |
| No ownership tracking | No field for “who’s responsible for renewal” |
| No service binding awareness | Doesn’t know which service uses which cert |
| No dependency mapping | Can’t tell you what breaks when a cert expires |
These aren’t bugs. They’re architectural boundaries. AD CS is a CA. A CA issues certificates. It doesn’t manage their lifecycle.
Where CLM Fills the Gap
CLM sits on top of AD CS and adds the operational layer:
| CLM Function | What It Solves |
|---|---|
| Discovery | Finds ALL certificates — AD CS issued, imported, external, self-signed |
| Inventory | Single source of truth for every cert in the environment |
| Expiry alerting | 90/60/30/14-day warnings with escalation |
| Ownership assignment | Every cert has a documented owner |
| Renewal workflows | Automated or prompted renewal before expiry |
| Compliance reporting | Inventory for auditors, algorithm compliance, key length tracking |
| Deployment verification | Confirms cert is actually serving traffic |
The Analogy: Monitoring for Certificates
Think of it this way:
- AD CS = the server. It runs workloads. It does its job.
- CLM = the monitoring stack. It tells you when the server is about to fail.
Nobody argues “we have servers, why do we need monitoring?” The answer is obvious: because servers fail, and you need to know before users notice.
Same logic applies:
- Certificates expire. You need to know before services break.
- Certificates get deployed incorrectly. You need to verify.
- Certificates exist that you don’t know about. You need to discover them.
- Auditors ask for inventory. You need to produce it.
AD CS can’t answer any of these questions alone.
What Happens Without CLM
Environments running AD CS without CLM develop predictable problems:
1. Reactive certificate management. You find out about expiry when something breaks. There’s no warning system.
2. Incomplete inventory. The CA database only shows what AD CS issued. Imported certs, external CA certs, self-signed certs — invisible.
3. No ownership. When a cert expires, who’s responsible? Without CLM, nobody. The on-call engineer figures it out at 2 AM.
4. Audit failures. “Show us your certificate inventory” → “Here’s what our CA issued” → “What about everything else?” → Compliance finding.
5. Duplicate effort. Multiple teams maintaining separate spreadsheets. Different views. Conflicting data. Manual updates that fall behind.
AD CS + CLM: The Complete Picture
| Layer | Tool | Function |
|---|---|---|
| Issuance | AD CS | Sign and deliver certificates |
| Policy | AD CS Templates | Control who gets what |
| Distribution | Auto-enrollment / GPO | Push certs to endpoints |
| Visibility | CLM | See everything deployed |
| Alerting | CLM | Warn before expiry |
| Ownership | CLM | Assign responsibility |
| Compliance | CLM | Report to auditors |
| Verification | CLM | Confirm deployment |
AD CS handles rows 1–3. CLM handles rows 4–8. Neither replaces the other.
When Teams Realize They Need CLM
The realization usually comes from one of four triggers:
- An outage caused by an expired cert — “why didn’t we know this was expiring?”
- An audit finding — “show us your complete certificate inventory”
- A certificate nobody owned — “who was supposed to renew this?”
- Scale — “we have 2,000+ certificates and spreadsheets aren’t working”
By the time you hit any of these, you’re already behind. CLM should be added the moment AD CS goes into production — not after the first outage.
The Bottom Line
AD CS and CLM aren’t competing products. They’re different layers of the same stack:
- AD CS = issuance engine (supply)
- CLM = visibility layer (operations)
You need both. Not either/or.
The question isn’t “AD CS or CLM?” The question is: “How long are you going to run a certificate infrastructure without visibility into what’s deployed, what’s expiring, and who owns it?”
Running AD CS without lifecycle visibility? Talk to us about adding the CLM layer — discovery, alerting, and ownership in one view.