Key Points
- AD CS was designed for domain-joined Windows endpoints, not for Wi-Fi infusion pumps, contractor laptops, or Epic-managed devices.
- Healthcare AD CS replacement migrates Microsoft Active Directory Certificate Services to a cloud PKI built for clinical fleets, IoMT, and vendor systems.
- Cloud PKI removes the on-premises CA from the patch cycle and the audit boundary, with 99.999% availability for clinical Wi-Fi.
- A phased migration runs the legacy and cloud CAs in parallel, so EHR Wi-Fi never goes dark during cutover.
A hospital’s Active Directory Certificate Services (AD CS) server fails on a Tuesday morning.
Workstations on wheels stop authenticating to Wi-Fi, barcode medication administration freezes at the bedside, and the on-call admin restores a certificate authority (CA) database from tape.
Healthcare AD CS replacement is a patient safety project, not a modernization project.
Most hospital IT teams are running out of road on the legacy CA they inherited a decade ago.
This blog explores why Active Directory Certificate Services (AD CS) is no longer sufficient for modern hospitals, the benefits of replacing it with cloud public key infrastructure (PKI), and a phased AD CS replacement plan.
What Is Healthcare AD CS Replacement?
Healthcare AD CS replacement is the migration from Microsoft Active Directory Certificate Services to a cloud-based or managed public key infrastructure (PKI).
AD CS is a Windows Server role that allows hospitals to create and manage their own public key infrastructure (PKI). Acting as an internal Certificate Authority (CA), AD CS issues, renews, and revokes digital certificates.
Because AD CS was not built to secure modern hospital endpoints, many healthcare organizations are replacing it with cloud PKI solutions.
The PKI issues, renews, and revokes certificates for clinical workstations, medical devices, Internet of Medical Things (IoMT) endpoints, and 802.1X Wi-Fi authentication without depending on legacy domain-joined infrastructure.
Why AD CS Fails in Modern Hospitals
AD CS was designed in the early 2000s for Windows environments where every endpoint joined the domain. However, the endpoints in a hospital rarely look like the corporate desktops AD CS was built for.
Workstations on wheels move between medical-surgical units and the intensive care unit (ICU). Infusion pumps and smart beds connect over Wi-Fi but never join Active Directory. Contractors and traveling nurses need access for hours, not years.
Here are some of the reasons why AD CS fails in modern hospitals:
Clinical-Device Fleets Do Not Join Active Directory
Workstations on wheels, vital-sign monitors, and bedside tablets are managed by Mobile Device Management (MDM) platforms (Intune, Jamf, Workspace ONE), not Group Policy.
AD CS has no native enrollment path for non-domain-joined devices. Teams rely on Network Device Enrollment Service (NDES) or manual exports, each of which adds an outage point.
IoMT and OT Live on Segmented Networks
Infusion pumps, telemetry gateways, and imaging carts connect to Wi-Fi but cannot run a domain-joined agent. AD CS was not built to issue and rotate certificates for fleets of headless medical devices.
Besides, the Food and Drug Administration (FDA) premarket cybersecurity guidance now recommends certificate-based device identity, not pre-shared keys.
Vendor Systems Need Certificate Trust Without Joining the Domain
Electronic health record (EHR) platforms such as Epic and Cerner, along with imaging systems from GE Healthcare and Philips, integrate through the following technologies:
- Transport Layer Security (TLS)-protected application programming interfaces (APIs)
- Fast Healthcare Interoperability Resources (FHIR) endpoints
- Digital Imaging and Communications in Medicine (DICOM) services
They need to trust the hospital CA chain but will not join Active Directory. The standard AD CS workaround (a separate offline issuing CA for vendor trust) adds complexity and audit risk.
BYOD Clinicians Have No Clean Enrollment Path
AD CS has no self-service enrollment for unmanaged devices, so hospitals fall back to pre-shared key (PSK) Wi-Fi or Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2) with shared credentials.
Both violate fall short of the unique-identification and transmission-security safeguards laid out in theHealth Insurance Portability and Accountability Act (HIPAA).
The Hidden Total Cost of Ownership Is Large
A robust AD CS deployment demands:
- Hardware security module (HSM) hardware
- An offline root CA
- Two or more issuing CAs
- Online Certificate Status Protocol (OCSP) responders
- Certificate revocation list (CRL) distribution points
In addition, AD CS deployment requires staff who can recover the private key when the database corrupts at 3 a.m.
The skill is rare and the labor is constant.
What Cloud PKI Changes for Hospitals
Cloud PKI delivers the same X.509 certificates AD CS issues, but as a managed service. The root and issuing CAs run in a hardened cloud, enrollment uses modern protocols, such as:
- Automated Certificate Management Environment (ACME)
- Simple Certificate Enrollment Protocol (SCEP) over Hypertext Transfer Protocol Secure (HTTPS)
- Enrollment over Secure Transport (EST)
Integration is application programming interfaces (API)-driven rather than relying on Group Policy Objects (GPO). The shift matters most in three places.
Enrollment Reaches Every Endpoint, Not Just Domain-Joined Windows
A cloud PKI that integrates with Intune, Jamf, Workspace ONE, and Google Workspace delivers certificates to clinical iPads, traveling-nurse laptops, and contractor MacBooks through MDM.
SecureW2 JoinNow MultiOS extends self-service enrollment to BYOD clinicians. Vendor systems and IoMT fleets enroll through SCEP or Automated Certificate Management Environment endpoints over HTTPS.
The CA Leaves the Patch Cycle and the Audit Boundary
A managed cloud CA is not a Windows server the hospital patches and rebuilds when a disk fails.
The vendor handles HSM key protection, redundancy, and uptime.
SecureW2 JoinNow Cloud RADIUS, paired with Dynamic PKI, targets 99.999% availability that on-premises AD CS plus Network Policy Server (NPS) rarely match.
Certificate Lifecycle Automates End to End
Cloud PKI platforms automate enrollment, renewal, and revocation through ACME, dynamic SCEP, and identity-provider-driven policies.
When a clinician account is disabled in Okta or Entra ID, the certificate is revoked at next authentication, not at quarterly cleanup.
CertIQ ML Anomaly Detection, an additional monitoring layer on the SecureW2 platform, watches for certificate anomalies (cloned certs, devices authenticating from unexpected locations) that AD CS cannot detect natively.
EHR and Epic Wi-Fi Compatibility Considerations
When it comes to healthcare AD CS replacement, the first question every hospital Chief Information Officer (CIO) asks is whether a PKI swap will break Epic. The answer is no, but it requires planning.
Epic’s Medical Device Integration platform secures EHR-to-device traffic with TLS.
EHR servers, ancillary applications, and connected devices must all trust the same CA chain.
During migration, the new CA root and issuing certificates must reach:
- Epic application servers
- Hyperspace and Hyperdrive clients
- Devices integrated through Bridges or Rover
- Workstations on wheels running Haiku or Canto
- TLS-protected ancillary systems
The cleanest approach is to publish the new cloud PKI root and issuing CA into the same trust stores AD CS already populates (Active Directory NTAuth and Trusted Root).
Domain-joined endpoints pick up the chain through Group Policy refresh; non-domain endpoints get it through MDM profiles.
Run both CAs in parallel during cutover.
For 802.1X Wi-Fi, the RADIUS server certificate must chain to a CA trusted by supplicants; a migration that skips this trust update takes EHR Wi-Fi down.
A Phased Healthcare AD CS Replacement Plan That Does Not Break Clinical Operations
A safe healthcare AD CS replacement runs in five phases, with the legacy CA and cloud PKI operating side by side until the cutover is verified.
Phase 1: Inventory and Dependency Mapping (4 to 6 Weeks)
Catalog every certificate AD CS issues today. Sources include the CA database, Active Directory, RADIUS logs, MDM platforms, biomed asset inventories, and the Epic interface engine.
Tag each certificate with subject, template, issuance protocol, renewal cadence, and consuming application.
Flag endpoints that pin a specific issuing CA (some imaging systems and infusion pumps do).
Phase 2: Stand Up the Cloud PKI In Parallel (2 to 3 Weeks)
Provision the cloud PKI with a new root and issuing CA.
Publish the new chain into every endpoint trust store before issuing a single production certificate.
Connect the PKI to the identity provider and the MDM platforms. Issue test certificates to a small pilot covering each endpoint class.
Phase 3: Migrate Non-Clinical Endpoints First (4 to 8 Weeks)
Move corporate workstations, BYOD clinicians, and contractor laptops to the cloud PKI before touching the clinical environment.
This validates enrollment paths and helpdesk runbooks under low patient-safety risk.
Phase 4: Clinical Fleet and IoMT In Waves (8 to 16 Weeks)
Migrate workstations on wheels, bedside tablets, and clinical workstations one unit at a time.
Coordinate with biomed for IoMT.
Keep the legacy AD CS issuing CA active so any device that fails against the new CA can fall back while the team troubleshoots.
Phase 5: Decommission AD CS (4 to 6 Weeks)
Once every certificate is re-issued and no endpoint authenticates against the old chain, revoke remaining AD CS certificates, remove the legacy CA from trust stores, and decommission the on-prem CA servers.
Keep the CA database and CRL archive for the audit retention window.
Based on our experience, the full migration runs 22 to 39 weeks for a typical 500-bed hospital, with cloud PKI in production from week 7.
How Cloud PKI Supports Healthcare Compliance
The push toward cloud PKI is not just operational. The compliance frame is shifting.
- HIPAA Security Rule (45 CFR 164.312): Technical safeguards require unique user identification, audit controls, integrity, and transmission security. Certificate-based authentication maps onto each; PSK and PEAP-MSCHAPv2 do not.
- HITRUST CSF v11: The comprehensive framework includes controls on certificate lifecycle management and IoT identity, both difficult to demonstrate with manual AD CS
- FDA 2023 premarket cybersecurity guidance: Manufacturers are advised to support certificate-based device identity for connected products, so hospital PKIs should be able to issue and rotate certificates at IoMT scale.
Replace AD CS with SecureW2 Dynamic PKI and Cloud RADIUS
The SecureW2 JoinNow platform gives you the solutions you need to replace legacy AD CS with a cloud PKI.
SecureW2 Dynamic PKI issues certificates to every endpoint type hospitals have, integrates with Epic-adjacent systems, and runs alongside the legacy CA during a phased migration.
JoinNow Cloud RADIUS pairs with Dynamic PKI for 99.999% Wi-Fi authentication uptime, JoinNow MultiOS handles BYOD enrollment, and CertIQ ML watches for certificate anomalies the legacy CA cannot see.
To see the migration plan applicable to your environment, schedule a demo.
Frequently Asked Questions
What is replacing Active Directory Certificate Services?
Cloud PKI services are the most common AD CS replacement in healthcare. They issue X.509 certificates as a managed service, integrate with MDM and identity providers, and remove the on-premises CA from the patch cycle and audit boundary.
Can Microsoft Cloud PKI replace AD CS in a hospital?
Microsoft Cloud PKI is an Intune add-on. It issues certificates to Intune-enrolled devices but does not cover non-Intune endpoints, IoMT fleets, vendor systems, or BYOD clinicians. Most hospitals need a broader cloud PKI that supports MDM-agnostic enrollment.
How long does an AD CS migration take in a hospital?
A typical 500-bed hospital migrates in 22 to 39 weeks, with the cloud PKI in production by week 7. Larger systems with multiple campuses run longer.
Does Epic require certificates for Wi-Fi?
Epic does not mandate a specific Wi-Fi authentication method, but Epic-connected workstations, Hyperspace clients, and Bridges-integrated devices need to trust the same CA chain the RADIUS server and 802.1X supplicants use.
A PKI swap that skips the trust-chain update will break Wi-Fi for Epic users.
How do hospitals manage certificates for medical devices?
Hospitals manage IoMT certificates through automated enrollment protocols (SCEP, EST, ACME), MDM platforms where the device supports them, and biomed-coordinated rotation.
Cloud PKI services automate this lifecycle in a way AD CS cannot.
