Microsoft ADCS PKI Hardening: What IT Teams Should Fix Now

Active Directory Certificate Services (ADCS) is easy to treat as background infrastructure. That is a mistake. A Certification Authority can issue certificates that represent users, computers, and services, so compromise of the CA can become a persistence path across the identity plane.

Microsoft Detection and Response Team researcher Ron Arestia’s September 6, 2026 practical PKI guidance is a useful prompt for an infrastructure review. The defensive message is direct: protect the root of trust, keep issuing CAs single-purpose, separate administrative roles, and remove the CA configurations that make certificate abuse easier.

This is not a recommendation to change production certificate services in a rush. It is a prioritized checklist for finding unsafe assumptions, planning the changes, and proving that authentication, enrollment, revocation, and recovery still work afterward.

The hardening priorities at a glance

1. Protect the root CA as the organization’s root of trust

The root CA signs subordinate CA certificates and certificate revocation lists. If the issuing tier is compromised while the root remains trusted, an organization can revoke the affected subordinate certificates and rebuild the issuing infrastructure without replacing every trusted root across the estate. That is a recovery advantage, not just a configuration preference.

Microsoft’s position is unambiguous: an enterprise-joined root CA should be moved toward an offline design. If the current root is also the primary issuer, assess the impact of introducing a two-tier hierarchy rather than accepting a permanently online root. Protect offline keys with controlled custody and hardware security where the organization’s risk model supports it.

• Document whether the root CA is truly disconnected from production and internet networks.
• Verify who can access the root host, its private key, backups, and removable media.
• Test that the team can publish a CRL and recover an issuing CA without improvising the procedure.
• Record the certificate, CRL, and key-validity periods so recovery decisions are made before an outage.

2. Make issuing CAs single-purpose Tier 0 systems

An issuing CA should issue certificates—not host unrelated workloads. Microsoft recommends keeping the ADCS Certification Authority role isolated and specifically warns against installing a CA role on a domain controller. Additional Windows roles, third-party agents, APIs, and convenience tooling expand the attack surface and the number of administrators who can reach a Tier 0 system.

Start with an honest inventory rather than an idealized diagram. List every root, issuing, registration, web-enrollment, NDES, and connector server; record its operating system, installed roles, network paths, local administrators, service accounts, and monitoring coverage. Classify the servers as Tier 0 and bring their controls up to the standard used for domain controllers.

Assume a stolen CA private key is a domain-persistence event even when there is no evidence that the key was exfiltrated. The response plan should therefore include certificate revocation, CA rebuild, credential review, and a hunt for certificates issued during the suspected compromise window.

3. Replace default administration with role separation

ADCS commonly starts with broad access through Domain Admins or Enterprise Admins. That is convenient during installation but creates an unnecessary path from a compromised identity to the PKI. Define a small, documented group for each function instead:

Keep the groups single-purpose and avoid overlapping membership unless there is a deliberate, documented exception. This narrows the attack path for ESC7 and creates evidence that privileged certificate actions were performed by the intended role.

4. Test role separation before enforcing it

ADCS includes a role-separation setting that can enforce one CA role per account:

Certutil -setreg CA\RoleSeparationEnabled 1

Microsoft cautions that the setting is global. An account that belongs to more than one configured role may lose the ability to perform either action once role separation is enabled. That can lock administrators out of the PKI and interrupt certificate operations.

Use a staging CA or a tightly controlled maintenance window. Export the current role assignments, validate a break-glass path, enable the setting, and exercise issuance, approval, revocation, backup, and recovery. If the organization is not ready for strict enforcement, retain the single-purpose groups and improve the identity controls first; role separation is one tool, not a substitute for sound administration.

5. Close the CA configuration paths attackers look for

Microsoft’s article maps several CA misconfigurations to the Exploitation of Certificate Services (ESC) framework. The following checks are defensive configuration reviews, not a license to run attack tooling in production.

Remove arbitrary request-attribute SAN behavior

The EDITF_ATTRIBUTESUBJECTALTNAME2 EditFlags setting can allow a requester to submit a Subject Alternative Name that the certificate template did not intend to permit. Review the CA’s policy\EditFlags value and remove that behavior following Microsoft’s documented procedure. Validate the effect on every template that legitimately needs subject information in the request before changing a production CA.

This is associated with ESC6 and can interact with other certificate-mapping weaknesses. Microsoft notes that a threat actor with another CA-administration path could reintroduce the setting, so monitor the configuration and the ADCS service for unexpected changes.

Require signed and encrypted RPC requests

ESC11 uses NTLM relay against the ICertPassage RPC interface on a vulnerable CA. Microsoft’s hardening guidance enables encrypted certificate requests:

Certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST

That setting forces the CA to accept only RPC connections that are signed and encrypted. Test enrollment from every supported connector, device, and management workflow after the change, and document the service restart and rollback steps.

Check for a disabled security extension

ESC16 can arise when the CA policy module disables the SID security extension identified by OID 1.3.6.1.4.1.311.25.2. Review the current list:

Certutil -getreg policy\DisableExtensionList

If the OID is present, remove it using the documented change procedure and validate certificate issuance for the templates and authentication scenarios that depend on the extension. Capture the before-and-after values as change evidence.

A practical 30-day hardening sequence

Days 1–5: establish the baseline

• Draw the CA hierarchy and label every CA, enrollment service, connector, and dependency.
• Export CA rights, template ACLs, EditFlags, InterfaceFlags, disabled extensions, local administrators, and service accounts.
• Identify certificates used for domain authentication, device enrollment, VPN, Wi-Fi, web services, and smart cards.
• Open a change record that names the business owners, maintenance windows, rollback steps, and evidence to retain.

Days 6–15: remediate the highest-risk paths

• Move the root toward an offline operating model or document the approved exception and recovery risk.
• Remove unrelated roles and services from issuing CAs; move tools to dedicated management or monitoring hosts.
• Replace broad administrator access with the three single-purpose groups and review nested memberships.
• Review the SAN, RPC, and disabled-extension settings against Microsoft’s guidance before enforcing changes.

Days 16–25: pilot and prove

• Use a representative issuing CA or lab hierarchy to test role separation and configuration changes.
• Issue and renew certificates for the most important authentication and device-enrollment scenarios.
• Verify CRL and AIA publication, revocation checking, monitoring, alerting, and helpdesk escalation.
• Run a recovery exercise that rebuilds an issuing CA while preserving the trusted root.

Days 26–30: make the controls durable

• Move approved settings through change control and retain command output, screenshots, and validation results.
• Schedule recurring reviews of privileged group membership, template permissions, CA configuration, and certificate issuance.
• Connect ADCS events and service-health changes to the organization’s security monitoring workflow.
• Give the service desk a short recovery runbook that explains what to check before renewing or reissuing certificates.

Pilot acceptance checklist

What this means for Microsoft 365 teams

ADCS is not a Microsoft 365 admin-center feature, but it often underpins Microsoft 365 identity and device workflows in hybrid organizations. Certificate-based authentication, device enrollment, Wi-Fi and VPN access, smart-card sign-in, and connector services can all fail—or become unsafe—when the CA hierarchy is poorly governed.

Bring the PKI owner into identity, Intune, and Entra change planning. When an authentication or enrollment incident occurs, ask not only whether the user or device is compliant, but also whether the issuing CA, template, certificate chain, and revocation path are healthy. That shared operating model prevents a local fix from creating a broader trust problem.

Frequently asked questions

Why does Microsoft treat a CA as Tier 0? A CA can issue certificates that represent privileged identities. Treat it with the same protection level as domain controllers and treat a stolen private key as a domain-persistence event.

Does an offline root eliminate PKI risk? No. It protects the root of trust and improves recovery, but issuing CAs, templates, enrollment services, keys, and administrator accounts still need hardening and monitoring.

Can we keep Domain Admins as the CA administrators? Microsoft’s guidance recommends replacing that default with narrowly scoped CA Admins, Certificate Managers, and Certificate Template Managers groups. Use broad roles only as a documented, temporary exception.

Should we copy the certutil commands directly into production? No. Capture the current values, compare them with the official article and your certificate dependencies, test in a representative environment, and schedule a reversible change.

How often should PKI permissions and settings be reviewed? At minimum, review them on a recurring schedule and after administrator, template, CA, or connector changes. Tie the review to the same evidence and access-governance cycle used for other Tier 0 systems.