From ADCS to Enterprise-Grade PKI: Where Microsoft Stops and Your Reality Begins
Why We’re Launching This Blog Series
ADCS’ limitations are not flaws - they’re design boundaries. To build a modern certificate infrastructure, you need something that complements ADCS, not necessarily replaces it. That is why we’re launching this blog series. We’ll explore several real-world use cases where organisations extend, adapt, and struggle with ADCS - cases drawn from community forums, GitHub projects, customer discussions, and industry conversations. This is not a closed list. We will add use cases as they emerge, evolve, or are brought to our attention. For each one, we’ll point you to original resources if we think it is appropriate so you can review scripts, modules, and approaches yourself - and decide whether they fit your strategy or whether a professional, specialised Certificate Lifecycle Management solution (CLM) like CEMA ([[LINK:index]]link to CEMA product page) is a better choice.
Microsoft world... and beyond! For organisations running Windows-based services, remains one of the most common ways to establish trust. It is deeply integrated into the Windows ecosystem, provides smooth auto-enrollment, and helps IT teams deploy zero-trust principles without friction. If your entire infrastructure lived inside Active Directory, ADCS would be a perfect fit. Auto-enrollment is the Windows-native feature that automatically requests, installs, and renews certificates for domain-joined devices. But that’s precisely the point: Microsoft built ADCS for Microsoft environments. Modern IT reality is something else entirely. Modern IT infrastructure relies on various Operating Systems and ADCS is lacking the tools to manage certificates across the board.
An IT Security Manager said it perfectly during a workshop we ran recently: “I’m not running a Microsoft island. I’m running an archipelago.”
Why doesn’t ADCS support Linux servers or infrastructure beyond Microsoft? ADCS was designed for Windows-based PKI workflows and does not provide native certificate enrollment methods for Linux, containers, or non-domain devices. Linux servers, containers, mobile devices, network appliances, cloud workloads, platform services, DevOps pipelines - none of them belong to this Microsoft “island,” yet all of them need certificates. They need automation. They need renewal before expiry. They need governance, visibility, security, and long-term maintainability. And that’s where the cracks begin to show.
“We scripted it for now… we’ll fix it properly later.”
Nobody plans to run their certificate infrastructure using dozens of scripts. Yet nearly every IT Operation Manager, at some point, reaches that stage. Why? Because ADCS covers Windows systems brilliantly - and leaves everything else to you. A senior IT Ops engineer told us recently: “We started with one Bash script for a Linux web server. Now we’re maintaining a Python script, a PowerShell script, two ACME gateways, a wrapper around NDES, and a cron job nobody remembers creating.”
It always starts small. It rarely stays small.
Why Teams Build Their Own ADCS Extensions
When ADCS does not provide automated enrollment and renewal for non-domain systems, three options remain:
- Manual work: generating CSRs, submitting them through web enrollment, downloading certificates, installing them, restarting services.
- Scripting or open-source tooling: to mimic what Windows auto-enrollment does natively. Or custom policy or exit modules coded in-house, but these are nothing more than larger, more complex scripts packaged as DLLs.
- Use a professional CLM (Certificate Lifecycle Management) solution like CEMA to do the heavy lifting for you.
Across forums, GitHub projects, and administrator discussions, you will find hundreds of examples where teams built their own solutions to compensate for ADCS’ limited platform coverage. Here are three that perfectly illustrate the pattern:
- Automating renewal for Linux servers: Linux machines do not have native auto-enrollment with ADCS. So system administrators rely on certmonger, SCEP, scripts that call /certsrv, or ACME gateways to request and renew TLS certificates. These tools work - but require significant configuration, ongoing patching, and deep ADCS knowledge.
- Enforcing certificate policies outside the Microsoft world: ADCS policy enforcement is excellent for domain-joined Windows devices. For everything else, teams rely on custom validation scripts or open-source policy modules like TameMyCerts. These plug gaps around SAN validation, naming rules, and template restrictions - but they are maintained by individuals, not enterprise vendors. A mature CLM like CEMA will provide a policy module.
- DevOps and ACME automation for cloud workloads: Modern workloads expect certificates to be delivered via ACME, APIs, or GitOps processes. ADCS does not natively support this. So teams deploy gateways that translate ACME into ADCS requests, often written in PowerShell or Go. They are elegant, clever - and fragile.
A Certificate Lifecycle Management solution (CLM) like CEMA ([[LINK:index]]link to CEMA product page) will provide a professional solution to solve the ADCS limitation problems. Depending on the maturity of the software, you will be able to solve more or less complex enterprise problems.
A DevOps lead told us: “Our ACME-to-ADCS gateway works great, but if the author stops maintaining it, we’re stuck.” This is a perfect illustration of the long-term risk.
Why the “Script First” Approach Makes Sense… Until It Doesn’t
Let’s be fair: scripting often starts as the smartest move. It solves the immediate problem, requires no budget approval, and gives teams the flexibility they need right now. Many IT Operation Managers admit, “We just needed something that worked today.” But what begins as a temporary fix quietly becomes a permanent dependency. Months later, the team is maintaining critical automation written by someone who has moved on, relying on tools with no roadmap, and carrying operational risk they never intended to own. Scripts are great accelerators - just not great foundations. Scripts are the duct tape of IT. They hold things together remarkably well, but duct tape is not a building material and over time, organisations discover exactly that. Here are the one hidden risks that come up most frequently in our discussions:
- Maintenance risk – Open-source modules and internal scripts often have no roadmap, no support, and no replacement if maintainers leave
- Security risk – Legacy protocols (SCEP, SOAP), weak validation, and inconsistent controls introduce vulnerabilities.
- Operational complexity – What starts as a small helper script becomes a mission-critical component nobody dares to touch.
- Lack of visibility – No unified dashboard, no audit history, no inventory, no lifecycle analytics.
- Compliance challenges – Hard to demonstrate governance when renewal is handled by cron jobs spread across the estate.
ADCS Remains a Solid Foundation - But It’s Not Enough Alone
Let’s be clear: ADCS is good software! Microsoft built it to secure Windows environments, and in that domain it performs exceptionally well. But Microsoft’s focus is, understandably, Microsoft. Your focus is your entire, heterogeneous, evolving infrastructure.
What to Do Next
If you face the pains described above, you are not alone - and you are not doing anything wrong. You’ve simply reached the natural limits of Microsoft ADCS in a heterogeneous infrastructure. To overcome those limits safely and sustainably, you need
- Certificate automation across all platforms
- Strong policy enforcement
- Lifecycle visibility
- Integration with modern protocols like ACME
- A maintained and supported system
This is exactly what we built with CEMA Certificate Lifecycle Management.