The server nobody owns
Most organisations issue more certificates than they realise. Wi-Fi authentication, VPN, internal websites, device identity, Entra certificate-based authentication, Windows Hello for Business. Trace them back and they usually arrive at one Active Directory Certificate Services server, built years ago by someone who has since left.
That server is rarely patched. It often has no clear owner. And it holds your root private key on the disk of a domain-joined Windows box.
Two things go wrong with it. The ordinary failure is a certificate nobody was tracking, which expires and takes out Wi-Fi or an internal application on a Monday morning. The serious failure is a compromised certificate authority, where an attacker can mint trusted certificates for anything on your network. The first costs you a day. The second is an incident you report.
If you have moved email, files, identity and device management to the cloud, the CA is often the last thing still running in the server room.
What PKI as a service means
The certificate authority runs as a platform rather than a server you build. Keys are generated inside cloud hardware security modules validated to FIPS 140-3, and they cannot be exported. Administrators sign in with Entra ID, so the MFA, Conditional Access and Privileged Identity Management policies you already run apply to the CA the same way they apply to everything else.
Nothing gets installed in your domain. No CA server, no database, no connector.
The platform we work with most often is Keytos EZCA. Microsoft names Keytos in its list of third-party certification authorities that support Intune, which matters more than it sounds. It means the Intune integration is a documented path, not something you assemble and then own forever.
What changes day to day
- Intune issues the certificates. SCEP profiles hand out user and device certificates automatically, renew them before they expire, and revoke them when a device is retired. Nobody raises a request. Nobody diarises an expiry date. For network hardware that Intune cannot manage, static SCEP covers access points, switches and printers.
- Internal web services renew themselves. ACME is the protocol Let's Encrypt made familiar, and ordinary ACME clients work against an internal CA. win-acme and simple-acme are the documented pair on Windows; certbot and acme.sh are in use too. Once they are pointed at it, the internal certificate that expires at two in the morning stops being a category of outage.
- Administration runs on identity. Who may issue a certificate is an Entra ID role, not a local group on a server. Elevation can be just in time through PIM. Every action is logged, and the log exports to your SIEM.
- The bill stops tracking your headcount. Licensing is per certificate authority with unlimited certificates, rather than per user or per device. Doubling your device count does not change what you pay.
- Domain controllers are covered. You can issue domain controller certificates for LDAPS and hybrid Windows Hello for Business without keeping AD CS alive for that one job. The CA still has to be published to your NTAuth store, the same as any CA issuing those certificates.
Where it actually lives
Data residency is a real question for local government, and for anyone with contractual obligations about where data sits.
EZCA runs an Australian instance in the Azure Australia East and Australia Central regions. CA keys, HSM backups and logs stay in Australia, with daily backups replicated to the second Australian region.
Read the edges of any sovereignty claim, including that one. Transactional notification emails and the licensing and billing metadata are processed in the United States. That is normal for SaaS, but it is the sort of thing a procurement team would rather read in a response than find in an audit.
What it does not do
This is not a drop-in replacement for AD CS, and anyone who tells you otherwise has not run the migration.
- There is no Group Policy auto-enrolment. Devices in Intune are straightforward. Servers that are not need ACME, or the platform's certificate client for Windows, macOS and Linux. Either way it is a small amount of work per server, and it belongs in the scope before you start.
- You cannot take the keys with you. CA private keys cannot be exported, which is the point of the HSM. It also means leaving the platform means re-issuing certificates rather than migrating keys. In practice Intune and ACME do that re-issuing for you, but it is a different exit plan to the one you may be used to.
- Some decisions are permanent. Key algorithm and extended key usages are fixed when a CA is created, and the choice is real: RSA 2048 or 4096, ECDSA P-256 or P-384. Design the hierarchy properly before you build it.
- Internal-only hostnames need help. A public CA cannot validate a name that does not resolve on the internet. You either run a small ACME validation agent on one server inside the network, which validates only and holds no keys, or you use DNS-01 validation where your DNS provider has an API.
Who it suits
The fit is good if you are already cloud-first: Entra ID joined devices, Intune management, a programme to retire on-premises servers, and a need for EAP-TLS Wi-Fi, certificate-based VPN or Entra certificate-based authentication.
It is also worth a look if your AD CS server is past its supported Windows Server version, or if you asked who owns the PKI and the room went quiet.
It suits you less well if most of your estate is still domain-joined servers outside Intune. The certificates can still be automated, but you are doing more of the work per machine, and that should be in the business case rather than discovered in week three.
What the work looks like
We start with a design workshop, because the decisions that are hard to undo all happen there. CA hierarchy, usually one root with separate issuing CAs for device certificates and web certificates. Extended key usages. Key algorithm. CRL validity.
Then we build it and validate against test devices before anything touches production. Documentation and administrator training come with it, so your ICT team can run the platform rather than ring us every time somebody needs a certificate.
After that, enrolment moves at whatever pace suits you, with us behind it. Most of these are a few weeks of work, not a project that runs for two quarters.
The short version
Your certificate authority is a security system that most organisations treat as furniture.
Moving it to a cloud certificate authority gets the root key off a Windows disk and into an HSM, puts issuance and renewal on autopilot through Intune and ACME, and removes the last server standing between you and a cloud-only estate. The trade-offs are real but they are known, and they are mostly about servers outside Intune.
If you are not sure what your current CA issues, or who owns it, that is the thing to find out first. We run a PKI health check that answers it, and a design workshop for organisations ready to replace AD CS. Have a look at our cyber security services, or get in touch.