ADCS Open Protocols Specifications: A Complete Technical Guide

The ADCS Open Protocols are Microsoft’s published technical specifications, MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA, and others, that define exactly how Windows clients request certificates, how certificate templates are structured, and how administrators manage a Certification Authority, forming the authoritative reference for securing and auditing an ADCS deployment. Active Directory Certificate Services (ADCS) is one of the most widely deployed Public Key Infrastructure (PKI) solutions in the enterprise world. While most organizations interact with ADCS through the Windows UI or PowerShell, the protocol layer underneath Microsoft’s published Open Specifications is where the real technical story lives. Understanding these protocols is critical for architects, security engineers, developers building PKI-integrated tools, and security professionals assessing vulnerabilities in certificate infrastructure.

This guide provides a comprehensive, practitioner-focused breakdown of every major ADCS Open Protocol specification, how they relate to one another, and what each one means for your PKI security posture.

Executive Summary

Active Directory Certificate Services runs on a defined stack of Microsoft Open Specifications: MS-WCCE and MS-ICPR for enrollment, MS-XCEP and MS-WSTEP for web-services-based enrollment, MS-CRTD for certificate templates, and MS-CSRA and MS-OCSPA for CA and OCSP administration. Nearly every well-known ADCS privilege escalation path, ESC1 through ESC15, traces back to a misconfiguration at one of these protocol layers, most often in certificate templates (MS-CRTD) or the enrollment flow (MS-WCCE). Meanwhile the CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, is compressing public TLS certificate validity to 47 days by March 2029, raising the operational stakes for every certificate this protocol stack issues. This guide maps each protocol to its role, its administrators, and the risks it introduces, then gives PKI, security, platform, and compliance teams a concrete checklist for hardening their ADCS environment.

Quick ADCS Protocol Checklist

Use this checklist to gauge how exposed your ADCS environment is to known protocol-level risks.

• Confirm every certificate template’s Subject Name, EKU, and enrollment-agent settings against MS-CRTD to rule out ESC1, ESC2, and ESC3 conditions.
• Confirm the CA does not have the EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled (ESC6).
• Confirm every MS-WSTEP or CES endpoint requires HTTPS and Extended Protection for Authentication to rule out ESC8 relay attacks.
• Confirm Version 1 schema templates are patched or retired against ESC15 (CVE-2024-49019).
• Confirm CA Administrator and Certificate Manager role assignments are reviewed against MS-CSRA’s administrative surface.
• Confirm your team has modeled what the 47-day TLS certificates schedule does to enrollment volume across this protocol stack.

Owner and Action Matrix by Team

ADCS protocol hardening fails most often when responsibility is unclear. Here is how PKI, security, platform, and compliance teams should divide ownership.

Team	Primary Responsibility	Key Action
PKI Team	Own protocol selection and enrollment architecture	Choose the right enrollment path, MS-WCCE, MS-XCEP/MS-WSTEP, or SCEP/NDES, for each device population
Security Team	Own ESC vulnerability remediation	Audit certificate templates against MS-CRTD and CA configuration against MS-CSRA for ESC1 through ESC15 conditions
Platform and DevOps Team	Own enrollment automation and endpoint hardening	Enforce HTTPS and EPA on all MS-WSTEP and CES endpoints; automate certificate lifecycle management
Compliance Team	Own protocol-level audit evidence	Use MS-CSRA-based inventory and lifecycle logs as attestations for FIPS, Common Criteria, and FedRAMP reviews

ADCS Protocol Decision Table

Use this table to map a situation your team is facing to the recommended action, the owner, and the expected outcome.

Use Case	Recommendation	Operational Owner	Expected Outcome
Certificate templates have not been audited against ESC1 through ESC15	Run a protocol-level audit of every template’s Subject Name, EKU, and enrollment-agent settings against MS-CRTD	Security Team	Privilege-escalation paths are identified and closed before they are exploited
Non-domain or remote devices need certificates	Deploy MS-XCEP and MS-WSTEP (CEP/CES) instead of extending MS-WCCE/RPC access externally	PKI Team	Certificate enrollment works without opening RPC/DCOM ports externally
Network devices such as routers, VPN gateways, or IoT need certificates	Deploy NDES with SCEP rather than attempting native ADCS enrollment	Platform and DevOps Team	Non-Windows devices enroll without custom tooling
CA administration surface has not been reviewed	Audit CA Administrator and Certificate Manager role membership against MS-CSRA’s exposed interfaces	Security Team	Remote CA administration is limited to the accounts that genuinely need it
Preparing for the 47-day TLS certificates shift	Model current enrollment volume across MS-WCCE and MS-XCEP/MS-WSTEP against roughly eight times today’s frequency	PKI Team and Platform/DevOps Team jointly	Enrollment infrastructure is sized correctly before the March 2029 deadline

What to Do Next

• PKI teams: Map every enrollment path currently in use, MS-WCCE, MS-XCEP/MS-WSTEP, and SCEP/NDES, and confirm each is the right fit for its device population.
• Security teams: Run an ESC1 through ESC15 audit against your certificate templates (MS-CRTD) and CA role assignments (MS-CSRA) this quarter.
• Platform and DevOps teams: Confirm every MS-WSTEP and CES endpoint enforces HTTPS and EPA, and pilot automated certificate lifecycle management.
• Compliance teams: Confirm your MS-CSRA-based audit trail already covers the evidence your next FIPS, Common Criteria, or FedRAMP review will ask for.

What Are Microsoft Open Specifications?

In the year 2008, Microsoft launched the Open Specifications program, a publicly accessible documentation library containing detailed technical specifications for Windows protocols and extensions. The goal was to enable third-party developers to build clients and servers that are fully interoperable with Microsoft’s products.

The Open Specifications library contains hundreds of documents covering Windows Protocols, Microsoft Office extensions, and more. For ADCS specifically, these documents represent the most authoritative and actively maintained technical reference available, in many cases superseding older TechNet content that was deprecated during Microsoft’s transition to a unified docs portal around 2015-2016.

The ADCS Open Protocol Landscape

The MS-CERSOD document (Certificate Services Protocols Overview) serves as the master index for all ADCS-related protocol specifications. It organizes ADCS functionality into two distinct groups:

• Certificate Enrollment Protocols: How clients request, receive, and renew certificates
• CA Administration Protocols: How administrators manage and operate the CA

Certificate Enrollment Protocols

1. MS-WCCE – Windows Client Certificate Enrollment Protocol

MS-WCCE is the foundational ADCS enrollment protocol and the one most deeply embedded in domain-joined Windows environments. It defines a set of DCOM (Distributed Component Object Model) interfaces that allow a client to communicate directly with a Certification Authority to:

• Request new X.509 certificates
• Renew existing certificates
• Retrieve CA properties and capabilities
• Obtain revocation status information

Core Architecture.

MS-WCCE is built on two successive DCOM interfaces: ICertRequestD and ICertRequestD2. These interfaces expose a simple request-response model. The client submits a certificate request (in PKCS #10, CMC, or PKCS #7 format) and the CA responds with either a signed certificate or a detailed disposition explaining why the request was denied or placed in pending status.

Transport.

MS-WCCE uses RPC/DCOM over TCP. This means it requires network connectivity to the CA on RPC dynamic ports and is inherently tied to Active Directory domain membership. The policy server in an MS-WCCE enrollment scenario is always a domain controller.

Security Relevance.

Because MS-WCCE leverages DCOM and Active Directory, it is the attack surface for several well-known Enterprise Security Certificate (ESC) privilege escalation techniques. Misconfigurations in certificate templates (template ACLs, EKU settings, enrollment agent permissions) can allow an attacker to abuse the MS-WCCE flow to obtain certificates for highly privileged accounts.

2. MS-ICPR – ICertPassage Remote Protocol

MS-ICPR is closely related to MS-WCCE and also uses DCOM/RPC. It exposes the ICertPassage interface, a simpler, lower-level interface used for direct certificate request submission to a CA without the richer enrollment intelligence built into MS-WCCE.

MS-ICPR is primarily used in programmatic certificate request scenarios, and it surfaces as a distinct DCOM endpoint on the CA. It is also relevant in certificate relay attack scenarios (such as ESC8 and related techniques) because it provides an authenticated channel to request certificates.

3. MS-XCEP – X.509 Certificate Enrollment Policy Protocol

MS-XCEP is the protocol that powers the Certificate Enrollment Policy Web Service (CEP) role in ADCS. It enables clients to retrieve certificate enrollment policy information over HTTP/HTTPS using SOAP-based messaging -without requiring direct DCOM connectivity to the CA.

How It Works.

The client sends a GetPolicies request to the CEP endpoint. The server responds with a GetPoliciesResponse containing: a collection of certificate enrollment policy objects describing available certificate templates, a list of certificate issuers (CES servers) the client should contact for each template, and the authentication method to use for each issuer (Kerberos, username/password, or certificate).

Authentication Options.

• Kerberos (for domain-joined devices)
• Username/Password (for non-domain devices authenticating with domain credentials)
• Certificate-based authentication (when the client already holds a valid certificate)

4. MS-WSTEP – Web Services Trust Enrollment Protocol

Where MS-XCEP handles policy discovery, MS-WSTEP handles the actual certificate issuance. It powers the Certificate Enrollment Web Service (CES) role in ADCS. Together, MS-XCEP and MS-WSTEP form the web-services-based enrollment stack that complements, and in many scenarios replaces, the RPC/DCOM stack used by MS-WCCE.

Protocol Characteristics.

• Based on WS-Trust (a WS-* security standard), extended with Microsoft-specific capabilities
• Communicates over HTTPS using SOAP messages
• Supports certificate requests in PKCS #10 and CMC format
• Enables end-to-end encrypted certificate enrollment without RPC port exposure

Common Deployment Scenarios.

Scenario	Protocol Used	Transport	Role Service
Domain-joined Windows client (on-prem)	MS-WCCE or MS-XCEP + MS-WSTEP	RPC/DCOM or HTTPS	CA / CES
Non-domain device with domain credentials	MS-XCEP + MS-WSTEP	HTTPS/SOAP	CEP + CES
Certificate renewal over the internet	MS-XCEP + MS-WSTEP (cert-based auth)	HTTPS/SOAP	CEP + CES
Network device enrollment (NDES)	SCEP over HTTP/HTTPS	HTTP/HTTPS	NDES
Browser-based enrollment	CAWE (CA Web Enrollment)	HTTPS	CA Web Enrollment

Security Note.

The web-services stack (MS-XCEP + MS-WSTEP) is commonly deployed facing the internet or DMZ segments. Proper authentication hardening, TLS configuration, and network segmentation are critical. ESC8-style relay attacks can also target HTTP-based CES endpoints if they are not configured to require HTTPS and Extended Protection for Authentication (EPA).

5. MS-CAESO – Certificate Autoenrollment Protocol (Archived)

MS-CAESO was the original protocol governing certificate autoenrollment in Windows environments -the automatic enrollment and renewal of certificates for domain users and computers based on Group Policy. This specification has been archived, as its core functionality has been folded into the MS-WCCE and MS-XCEP/MS-WSTEP specifications.

Understanding MS-CAESO is still valuable for organizations running older Windows environments or auditing legacy PKI configurations.

Certificate Template and Policy Specifications

6. MS-CRTD – Certificate Templates Description

Certificate templates are the heart of enterprise ADCS deployments. They define what certificates can be issued, to whom, under what conditions, and with what key usage extensions. MS-CRTD specifies the exact structure, attributes, and encoding of certificate template objects as they are stored in Active Directory.

What MS-CRTD Covers.

• The schema of certificate template objects in Active Directory (object class, attribute names, OIDs)
• The encoding of Extended Key Usage (EKU) policies within templates
• Issuance policies, subject name settings, enrollment permissions, and security descriptors
• Version 1 vs Version 2 vs Version 3 template schema differences
• The relationship between template attributes and the resulting certificate fields

Why This Matters for Security.

Understanding MS-CRTD is foundational for auditing certificate template misconfigurations -the root cause of most ADCS-related privilege escalation attacks (ESC1 through ESC15). The recently disclosed ESC15 vulnerability (CVE-2024-49019) specifically involved exploitation of Version 1 schema template behavior, underscoring why deep knowledge of MS-CRTD is a security prerequisite.

CA Administration Protocols

7. MS-CSRA – Certificate Services Remote Administration Protocol

MS-CSRA defines the DCOM interfaces used to remotely administer a Certification Authority. It is the protocol behind the Certification Authority MMC snap-in, the certutil.exe tool, and programmatic CA administration through Windows APIs.

Administrative Operations Covered.

• Starting and stopping the CA service
• Viewing, approving, denying, and revoking pending certificate requests
• Managing the certificate revocation list (CRL) and CRL distribution points (CDPs)
• Configuring CA properties (key algorithms, CRL schedules, audit settings)
• Backing up and restoring the CA database
• Querying the CA database for issued, pending, failed, and revoked certificates

MS-CSRA exposes several COM interfaces, including ICertAdmin, ICertAdmin2, ICertView, ICertView2, and IEnumCERTVIEWROW. Remote CA administration via MS-CSRA requires membership in the CA Administrator or Certificate Manager roles. Misconfigured CA role assignments represent a significant privilege escalation risk.

8. MS-OCSPA – Online Responder Administration Protocol

The Online Certificate Status Protocol (OCSP) responder is a key component of modern PKI infrastructure. Rather than requiring clients to download and parse large CRL files, OCSP enables real-time certificate revocation checking with a simple request-response mechanism.

MS-OCSPA defines the DCOM interfaces used to administer the Microsoft OCSP responder (the Online Responder role service in ADCS), including configuring OCSP revocation providers, managing OCSP signing certificates and their automatic renewal, monitoring OCSP responder health and cache state, and configuring refresh intervals for revocation data.

Operational Best Practices.

• OCSP responders should be configured with dedicated, short-lived signing certificates (not the CA certificate itself)
• OCSP stapling should be enabled on web servers to reduce OCSP traffic and improve performance
• Multiple OCSP responders behind a load balancer improve availability and eliminate single points of failure

ADCS Enrollment Beyond Open Specs: NDES/SCEP and Modern Protocols

While the Microsoft Open Specifications cover the native Windows enrollment protocols, ADCS also supports enrollment via Simple Certificate Enrollment Protocol (SCEP) through the Network Device Enrollment Service (NDES) role.

NDES and SCEP

The SCEP enables network devices – routers, switches, VPN gateways, IoT devices – that cannot participate in a Windows domain to request certificates from an ADCS CA. NDES acts as a Registration Authority between the device and the CA, validating enrollment requests using a challenge password mechanism. SCEP is defined by an IETF standard (RFC 8894) and is widely supported by network device vendors and MDM platforms.

What ADCS Does Not Natively Support

ACME (RFC 8555): ADCS does not natively implement the ACME protocol. ACME is the standard used by Let’s Encrypt and increasingly required for modern DevOps and cloud-native environments. Third-party solutions can bridge ADCS to ACME-compliant clients.

EST (RFC 7030): Not natively supported in ADCS; EST is a more modern alternative to SCEP for constrained devices and is increasingly deployed alongside IoT PKI programs.

REST/JSON API: ADCS exposes no native REST API. Interaction is through DCOM, SOAP, or the CryptoAPI/CertEnroll COM interfaces.

Security Implications of ADCS Open Protocols

Knowledge of the ADCS protocol layer has become a security prerequisite, not just a developer concern. ESC vulnerabilities have entered mainstream security awareness, with ESC1, ESC2, ESC3, ESC6, ESC8, and ESC15 documented and weaponized. The table below maps each vulnerability to its protocol layer.

These protocol-level risks compound with a broader certificate lifecycle problem. DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage specifically to an expired certificate, outcomes a misconfigured MS-WCCE enrollment flow or an over-permissive MS-CRTD template can just as easily cause through an unplanned revocation or reissuance. Source: digicert.com/news/digicert-survey-finds-manual-processes-expose-organizations.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029, roughly an eightfold increase in enrollment frequency across every protocol in this stack, exactly the shift toward 47-day TLS certificates that MS-WCCE, MS-XCEP, MS-WSTEP, and SCEP/NDES will all need to support at scale. Source: sectigo.com/resource-library/sectigo-cab-reduce-ssl-tls-certificates-lifespan-47-days. ITIC’s 2024 Hourly Cost of Downtime report found that the average cost of a single hour of downtime now exceeds $300,000 for more than 90% of mid-size and large enterprises, underscoring why an ESC-driven certificate incident is a business risk, not just a security one. Source: itic-corp.com/itic-2024-hourly-cost-of-downtime-report.

Vulenrability	Protocol Layer	Root Cause	Notes
ESC1	MS-WCCE + MS-CRTD	Template allows requester to supply arbitrary Subject Name	High-impact; widely exploited
ESC2	MS-WCCE + MS-CRTD	Template has Any Purpose EKU or no EKU restriction	Broad certificate abuse potential
ESC3	MS-WCCE + MS-CRTD	Enrollment agent abuse via Certificate Request Agent EKU	Two-stage attack chain
ESC6	MS-WCCE	EDITF_ATTRIBUTESUBJECTALTNAME2 flag enabled on CA	CA-level flag, not template-level
ESC8	MS-WSTEP / HTTP CES	NTLM relay to HTTP-based CES endpoint	Relay attack; requires HTTP (not HTTPS)
ESC15	MS-CRTD (V1 templates)	Arbitrary application policy injection in V1 schema templates	CVE-2024-49019; patch required

Practical Guidance: Using Open Specifications in Your PKI Program

For PKI Architects

• Use MS-CERSOD as the authoritative reference for designing enrollment architectures, especially in hybrid cloud or internet-facing scenarios
• Use MS-XCEP + MS-WSTEP to design enrollment flows for non-domain devices, cloud workloads, and remote users
• Reference MS-CRTD when designing new certificate templates to ensure attribute settings match your intended security policy

For Security Engineers

• Map your ADCS configuration against MS-CRTD to identify template attribute misconfigurations that correspond to ESC conditions
• Review CA role assignments against MS-CSRA to ensure the CA administration surface is minimally exposed
• Ensure all CES endpoints (MS-WSTEP) require HTTPS and Extended Protection for Authentication (EPA) to prevent relay attacks

For Developers

• Implement custom enrollment clients using the DCOM interfaces defined in MS-WCCE and MS-ICPR for domain environments
• Use MS-XCEP + MS-WSTEP SOAP interfaces for cross-platform or web-based enrollment applications
• Reference MS-CSRA for building CA monitoring, auditing, or lifecycle management tooling

For Compliance and Audit Teams

• The Open Specifications provide protocol-level evidence for compliance attestations (FIPS, Common Criteria, FedRAMP) regarding how certificates are issued and managed
• Use MS-CSRA capabilities to build automated certificate inventory and lifecycle monitoring -critical for audit readiness

How Encryption Consulting Can Help

Encryption Consulting specializes in PKI strategy, ADCS architecture, and certificate lifecycle management for enterprise and government organizations. Whether you are deploying ADCS for the first time, modernizing a legacy PKI, assessing your certificate infrastructure for ESC vulnerabilities, or integrating ADCS with modern DevOps tooling, our team brings deep protocol-level expertise to every engagement.

Hardening ADCS protocols is one piece of a broader crypto agility program. Our CertSecure Manager platform builds on the same certificate discovery and inventory work needed to secure this protocol stack, while our PQC Center of Excellence and PQC readiness assessments extend that same discovery discipline to post-quantum migration, and CBOM Secure turns it into a full Cryptography Bill of Materials. See our guide on turning a CBOM inventory into actionable intelligence for how certificate automation, PQC readiness, and CBOM connect.

• PKI Health Assessments: Protocol-level audits of your ADCS environment against Microsoft Open Specifications and security hardening benchmarks
• ADCS Architecture Design: Enrollment stack design (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), CA hierarchy planning, and certificate template governance
• Certificate Lifecycle Management: Automated discovery, monitoring, and renewal of certificates across your enterprise
• Security Hardening: Remediation of ESC misconfigurations, CA role hardening, and CRL/OCSP infrastructure optimization

Conclusion

The Microsoft Open Specifications for ADCS are far more than developer reference material. They are the definitive technical foundation for understanding how certificates are requested, issued, administered, and revoked across your enterprise. As the ESC vulnerability landscape has made clear, gaps in protocol-level knowledge translate directly into exploitable security weaknesses.

Whether you are designing a new enrollment architecture, hardening an existing CA deployment, building PKI-integrated tooling, or conducting a security assessment, fluency with MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA, and their peers is no longer optional. A well-governed ADCS environment is not just a matter of correct configuration. It requires a deep understanding of the protocols that govern every interaction between clients, CAs, and the certificates they issue. Investing in that knowledge today is the most reliable way to stay ahead of tomorrow’s certificate infrastructure threats.

Frequently Asked Questions

What Is the Main Takeaway From ADCS Open Protocols Specifications: A Complete Technical Guide?

This guide’s main takeaway is that ADCS security depends on protocol-level fluency: MS-WCCE and MS-ICPR govern enrollment, MS-XCEP and MS-WSTEP power web-services enrollment, MS-CRTD defines certificate templates, and MS-CSRA and MS-OCSPA govern CA and OCSP administration. Nearly every ESC privilege-escalation technique traces back to a misconfiguration at one of these layers, most often in certificate templates.

Why Does This Matter for Enterprise Certificate Lifecycle Management?

DigiCert’s Trust Pulse Survey found that 45% of organizations experienced certificate-related downtime in the past year, and 37.5% traced an outage to an expired certificate. A misconfigured ADCS protocol layer, an over-permissive certificate template or an exposed MS-WSTEP endpoint, produces the same outcome: an unplanned revocation, reissuance, or outage, which is exactly what disciplined certificate lifecycle management is built to prevent.

What Teams Are Responsible for Acting on This Guidance?

PKI teams own protocol selection and enrollment architecture. Security teams own auditing certificate templates (MS-CRTD) and CA administration (MS-CSRA) for ESC1 through ESC15 conditions. Platform and DevOps teams own enforcing HTTPS and Extended Protection for Authentication on enrollment endpoints. Compliance teams own using MS-CSRA-based audit trails as evidence for FIPS, Common Criteria, and FedRAMP reviews.

What Risks Increase If This Topic Is Handled Manually?

Without a protocol-level audit, over-permissive certificate templates (ESC1, ESC2, ESC3), an exposed CA flag (ESC6), unpatched Version 1 schema templates (ESC15), or an HTTP-only MS-WSTEP endpoint (ESC8) can sit undetected for years, each one a documented, weaponized privilege-escalation path into your certificate authority.

How Does Automation Reduce Certificate Outage Risk?

Automating certificate discovery and lifecycle management surfaces misconfigured templates, expiring certificates, and unenforced HTTPS or EPA settings before they cause an outage or a privilege-escalation incident, rather than after an ESC technique or an expired certificate has already been exploited.

What Metrics Should Teams Track After Implementation?

Track the number of certificate templates reviewed against MS-CRTD for ESC conditions, the percentage of MS-WSTEP and CES endpoints enforcing HTTPS and EPA, CA administration role assignments reviewed against MS-CSRA, and certificate-related outage or incident tickets per quarter compared against your pre-audit baseline.

How Does This Connect to 47-Day TLS Certificate Readiness?

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days in March 2026, 100 days in March 2027, and 47 days by March 2029, roughly an eightfold increase in enrollment frequency. Every enrollment protocol in this stack, MS-WCCE, MS-XCEP, MS-WSTEP, and SCEP/NDES, will process that volume, making protocol-level automation a prerequisite rather than an optimization.

How Should This Be Handled in Multi-Cloud or Hybrid PKI Environments?

Apply the same template auditing (MS-CRTD), CA administration review (MS-CSRA), and endpoint hardening (HTTPS and EPA on MS-WSTEP) consistently whether the CA is on-premises, hosted in a hybrid configuration, or paired with cloud-native enrollment such as SCEP/NDES for network devices, rather than securing one enrollment path and leaving another exposed.