Your Ultimate Guide to Understanding CEP and CES

If you manage a Windows Server Public Key Infrastructure (PKI) environment, certificate enrollment is one of the most operationally critical and most frequently broken processes in your infrastructure. When devices sit outside your domain network, traditional certificate enrollment through Active Directory simply does not work. That is exactly the problem that Certificate Enrollment Policy Web Service (CEP) and Certificate Enrollment Web Service (CES) were designed to solve.

These two Active Directory Certificate Services (AD CS) role services work in tandem to enable secure, automated certificate enrollment for any device, whether it is domain-joined, remotely connected, cloud-hybrid, or completely outside your internal network perimeter. Let us break down each component and understand how the auto-enrollment process works using CEP and CES.

Quick Answer: What Are CEP and CES?

CEP (Certificate Enrollment Policy Web Service) and CES (Certificate Enrollment Web Service) are two Microsoft AD CS role services that extend PKI certificate enrollment over HTTPS to devices that cannot reach Active Directory directly. CEP delivers enrollment policy via MS-XCEP; CES processes certificate requests via MS-WSTEP and forwards them to the issuing CA. Together they enable automated enrollment for remote, cloud, and non-domain-joined devices.

Key Takeaways

• CEP and CES operate as a two-part web enrollment stack: CEP tells clients what they can request (policy, templates, CA targets) via the MS-XCEP protocol, and CES handles the actual certificate request submission via MS-WSTEP. Neither issues certificates directly; the issuing CA remains protected behind both services.
• The choice of authentication method determines which device types can enroll. Kerberos is the most secure option and the correct choice for domain-joined Windows clients with DC connectivity. Username/password (HTTP Basic, RFC 7617) is the correct fallback for non-domain-joined clients, remote devices, and cloud workloads, but requires strict HTTPS enforcement and a dedicated low-privilege service account. Certificate-based authentication is available only in CES and applies only to renewal, not first-time enrollment.
• Constrained Kerberos delegation on the CES service account is not optional. CES must impersonate the client when forwarding the request to the CA. A missing or misconfigured SPN or delegation setting is the single most common cause of CES enrollment failure and produces access denied errors that are difficult to trace without IIS and CA audit logs correlated together.
• As CA/Browser Forum Ballot SC-081v3 reduces public TLS certificate lifetimes to 47 days by March 2029, the renewal cadence for every certificate in scope increases dramatically. Manual certificate management does not scale at 47-day intervals. CEP and CES are the AD CS mechanism for keeping that renewal automated for the devices that cannot use Group Policy autoenrollment.
• In PKIaaS environments, an Enrollment Gateway performs the CEP and CES brokering role between client devices and the managed CA. The device estate experiences no change in enrollment behavior, while the CA infrastructure moves to a managed service model with full lifecycle visibility and compliance-ready audit logging.

Who Should Care About CEP and CES

CEP and CES are primarily a PKI administrator tool, but the deployment decisions and governance requirements touch multiple teams. Every role below has a reason to understand what these services do and where their responsibilities begin.

Role	Why It Matters	Action Item
PKI Admins	Own deployment, configuration, and ongoing operation of CEP and CES: SPN registration, constrained delegation, IIS configuration, template permission assignment, and authentication method selection; responsible for diagnosing and resolving enrollment failures across the web enrollment stack	Audit all active CEP and CES endpoints; confirm constrained delegation is correctly configured on every CES service account; verify that certificate templates published via CEP match the approved template baseline; confirm IIS and CA audit logging is enabled and forwarded to SIEM; connect CEP/CES enrollment data to CertSecure Manager lifecycle tracking
Security Architects	Own the trust boundary design that determines which authentication method applies to which device population; Kerberos vs username/password vs certificate-based renewal is a security architecture decision, not a configuration choice; responsible for ensuring that username/password endpoints do not become a credential-harvesting surface	Define and document the authentication method policy for each CEP/CES endpoint by device type and network zone; require dedicated low-privilege service accounts for all CES application pool identities; include CEP/CES endpoint TLS certificate expiry in the PKI monitoring scope; review CBOM Secure cryptographic inventory to confirm CEP/CES endpoint certificates use approved algorithms and key sizes
Platform and Cloud Teams	Own integration of CEP/CES enrollment into cloud workload provisioning pipelines; responsible for ensuring that cloud-hosted systems and non-domain-joined devices have a reachable and correctly authenticated CEP/CES endpoint at provisioning time; enrollment failures in cloud pipelines are often silent and only surface when the certificate expires	Map all cloud workloads and non-domain-joined devices that require PKI certificates; confirm that each has a reachable CEP endpoint using the correct authentication method (username/password for non-domain, Kerberos for domain-joined cloud VMs); validate enrollment at provisioning time and add CEP/CES reachability checks to infrastructure-as-code validation; evaluate PKIaaS Enrollment Gateway as the enrollment endpoint for cloud-native workloads
Compliance Teams	Must demonstrate that certificate enrollment transactions are logged with requester identity, authentication method, template used, CA response, and timestamp; CEP and CES audit trails are the evidentiary basis for PKI-related compliance controls across SOC 2, ISO 27001, FedRAMP, HIPAA, and PCI DSS	Confirm IIS access logs and CA event IDs 4886, 4887, and 4888 are retained for the required audit period; include CEP/CES enrollment log review in quarterly compliance evidence packages; confirm that username/password authentication endpoints have additional controls documented (dedicated account, HTTPS enforcement, WAF) as compensating controls for the credential-handling risk
CISOs	Certificate expiration is a top-three CISO concern (DigiCert Trust Pulse Survey, July 2025, 56.6 percent); without CEP and CES, devices outside the domain boundary cannot auto-renew, creating silent expiry risk at scale; as lifetimes shrink to 47 days by March 2029 under CA/Browser Forum Ballot SC-081v3, manual processes collapse entirely	Require a complete inventory of devices that currently lack automated enrollment coverage; fund PKI admin training on CEP/CES deployment, authentication method selection, and failure diagnosis; mandate SIEM integration for CEP/CES enrollment events; evaluate whether the operational overhead of self-managed CEP/CES justifies moving to a managed PKI model with a built-in Enrollment Gateway

Authentication Method Decision Matrix for CEP and CES

Choosing the wrong authentication method for a CEP or CES endpoint is the most common configuration mistake in web enrollment deployments. Use this decision matrix to match the correct method to each device type and scenario.

Use Case	Recommended Auth Method	Security Impact	Operational Effort	Automation Fit	Owner
Domain-joined Windows workstations and servers with reliable DC connectivity	Kerberos	Highest: no credential exposure, mutual authentication, time-bound tickets	Low: Group Policy autoenrollment works natively once SPN and delegation are configured	Fully automated via Group Policy; zero user interaction	PKI Admin
Domain-joined Windows machines enrolling across a forest trust	Kerberos (cross-forest)	High: requires a Kerberos forest trust; SPN must be registered in the target forest	Medium: trust configuration and SPN registration across forests require AD team coordination	Automated if Group Policy and trust are configured correctly	PKI Admin + AD Team
Non-domain-joined workstations, contractor devices, BYOD endpoints	Username/Password (HTTP Basic, RFC 7617)	Medium: credentials protected by TLS in transit, but introduces direct credential handling; requires dedicated low-privilege service account and HTTPS enforcement	Medium: requires IIS Basic Auth configuration, dedicated service account, and credential management policy	Automatable via scripting or MDM policy; not silent for first enrollment if credentials must be supplied interactively	PKI Admin + Security Architect
Cloud workloads (Azure VMs, AWS EC2) joined to a domain	Kerberos	High: domain-joined cloud VMs use the same Kerberos path as on-premises; requires DC connectivity via VPN or ExpressRoute/Direct Connect	Medium: network connectivity from cloud to DC must be validated at provisioning time	Automated via Group Policy if DC is reachable; falls back to manual if connectivity fails	Platform Team + PKI Admin
Cloud workloads not domain-joined	Username/Password or PKIaaS Enrollment Gateway	Medium (username/password) or High (PKIaaS Gateway): PKIaaS Gateway avoids direct credential handling for cloud workloads	High for self-managed; Low for PKIaaS: managed enrollment gateway removes infrastructure burden from the cloud team	PKIaaS Gateway provides fully automated enrollment without domain dependency	Platform Team + PKI Admin
Remote workers connecting over internet without VPN	Username/Password or PKIaaS Enrollment Gateway	Medium (username/password); requires WAF and HTTPS enforcement at minimum	Medium: IIS endpoint must be internet-reachable with correct TLS and authentication controls	Automatable but requires credential management; PKIaaS Gateway removes internet-facing exposure of CES	PKI Admin + Security Architect
Certificate renewal for existing certificate holders (any connectivity model)	Certificate-Based (CES only)	High: no password, no Kerberos dependency; existing certificate serves as identity proof	Low once configured: renewal happens automatically using the existing certificate	Fully automated: CES handles renewal silently using the existing certificate as the authenticator	PKI Admin
PKIaaS environment (managed CA outside the network boundary)	PKIaaS Enrollment Gateway	High: CA never exposed to client traffic; Gateway enforces authentication and authorization before forwarding to managed CA	Lowest: no CEP/CES infrastructure to manage; Encryption Consulting manages the Gateway and CA	Fully automated: Enrollment Gateway replicates standard Group Policy autoenrollment behavior for domain and non-domain devices	PKI Admin (configuration); Encryption Consulting (operation)

What Is Certificate Enrollment Policy Web Service (CEP)?

Certificate Enrollment Policy Web Service (CEP) is the AD CS role service responsible for delivering certificate enrollment policy to clients over a secure web interface. It acts as the policy distribution point of your PKI environment.

In a typical domain setup, a Windows computer that is joined to the domain automatically gets certificate-related information from Active Directory without any manual effort. It essentially asks Active Directory what certificates it is allowed to request, which certificate templates are available, and which Certification Authorities (CAs) it should use. Based on this information, the machine can then automatically request and install the certificate. All of this happens in the background, so from a user perspective, the process is invisible.

This traditional approach stops working in modern environments where systems cannot directly talk to Active Directory. For example:

• Remote workers connecting over the internet without a VPN
• Non-domain-joined devices that have no AD connectivity
• DMZ servers isolated from the internal domain
• Cloud workloads in Azure, AWS, hybrid environments, or even partner and vendor systems
• Partner or vendor devices that need organizational certificates

Since they cannot query Active Directory, they cannot discover certificate templates or available CAs, which disrupts the normal auto-enrollment process. This is exactly where solutions like CEP and CES become important, as they provide a secure, web-based way for these external or isolated systems to still request and receive certificates.

CEP fixes this problem by making certificate enrollment policy available through a secure HTTPS web service instead of requiring direct access to Active Directory. This means an authorized client, even if it is outside the internal network or not joined to the domain, can still connect to CEP over the web and ask what certificates it is allowed to request, which templates are available, and which CA it should use. In simple terms, CEP acts like a secure online replacement for Active Directory policy lookup, allowing remote or isolated systems to get the certificate enrollment information they need.

What Information Does CEP Deliver?

When a client connects to CEP, CEP sends back all the certificate enrollment rules and options that apply to that specific client. This includes:

• All certificate templates that the client is permitted to use
• Template-specific settings or restrictions, such as key usage or subject requirements
• The target Certification Authority that the client should direct requests to
• Enrollment policy configuration, including renewal thresholds and validity periods
• Authentication requirements the client must satisfy when submitting a request
• Policy metadata, including the unique enrollment policy identifier

Note: CEP only provides information about certificate enrollment policy; it tells the client what it is allowed to request and under what rules. It does not actually issue certificates, process enrollment requests, talk to the Certification Authority to submit a request, or store certificate data. In simple terms, CEP is only a policy guide; it informs the client but does not perform the actual certificate enrollment.

What Is Certificate Enrollment Web Service (CES)?

The Certificate Enrollment Web Service (CES) is the AD CS role service that handles the actual certificate enrollment and renewal transactions. It picks up exactly where CEP leaves off and acts as a secure, authenticated broker between the client and the backend Certification Authority.

Even after the client learns from CEP which certificate it is allowed to request, it still has to actually send that request somewhere so the certificate can be issued. In a normal internal domain setup, this is done by sending the request directly to the Certification Authority using DCOM/RPC, which works only when the client has direct network connectivity to the CA. That becomes a problem for remote users, internet-based devices, or isolated systems because they usually cannot reach the CA directly.

CES solves this by acting as a secure middle layer: the client sends the certificate request to CES over HTTPS, and CES then forwards it to the client internal CA. This means the client can still enroll for certificates without ever needing direct access to the CA itself.

Role of CES

• Accepts certificate enrollment and renewal requests from clients over HTTPS
• Authenticates the client before processing any request
• Forwards authenticated requests to the internal Certification Authority
• Returns CA responses (issued certificate, pending status, or denial) back to the client
• Handles certificate renewal, including key-based renewal for automated scenarios
• Maintains the full enrollment transaction from submission to response delivery

This design is important because it protects the internal Certification Authority from being exposed directly to outside systems. The CA does not need to have a public IP address or be reachable from the internet, which greatly reduces security risk. Instead, CES sits in front of the CA and acts as a secure gatekeeper. It checks authentication and authorization first, so only valid and approved requests are ever passed to the CA.

In this way, CES becomes a controlled entry point for certificate enrollment, while the CA stays safely hidden behind it. It also improves accountability, because both CES and the CA can log and audit activity separately, giving better visibility into who submitted a request and how it was processed.

Definitive Comparison Between CEP and CES

CEP tells the client what to request. CES helps the client actually request it.

Let us understand the similarities and differences between CEP and CES.

CEP (Certificate Enrollment Policy Web Service)	CES (Certificate Enrollment Web Service)
Provides certificate enrollment policy to clients	Handles certificate enrollment and renewal requests
Tells the client what certificates it can request	Enables the client to actually submit the request
Does NOT communicate with the Certification Authority	Communicates with the Certification Authority
Does NOT issue certificates	Does NOT issue certificates (proxies to CA)
Returns templates, settings, and policy details	Processes and forwards certificate requests
Client-facing service	Client-facing service
Requires IIS	Requires IIS
Requires authentication	Requires authentication
Supports Kerberos and Username/Password authentication	Supports Kerberos, Username/Password, and Certificate authentication
Does NOT support certificate-based authentication	Supports certificate authentication (mainly for renewal)
Used to retrieve policy remotely	Used to perform enrollment remotely
Uses HTTPS (Port 443)	Uses HTTPS (Port 443)

Step-by-Step on How Certificate Auto-Enrollment Works

The following is the complete end-to-end workflow for certificate auto-enrollment using CEP and CES in an enterprise Active Directory environment.

Step 1: Client Initiates Contact with CEP for Enrollment Policy

The workflow begins when a client, such as a Windows workstation, server, or remote device, determines it needs to enroll in a certificate or renew an expiring one. This trigger can come from:

• Group Policy auto-enrollment (scheduled certificate check)
• Manual enrollment initiated by a user or administrator
• Automated renewal triggered by the certificate approaching its expiry threshold
• First-time enrollment on a new device being provisioned

The client reaches out to the CEP endpoint over HTTPS to retrieve the enrollment policy. At this point, no certificate request has been made. The client is simply asking: what am I allowed to request, and what rules apply?

This step is critical for remote and non-domain-joined devices because they have no other mechanism for discovering available certificate templates and CA information.

Step 2: CEP Responds with Applicable Policy Details

When a client contacts CEP, it analyzes who the client is and sends back the exact certificate enrollment policy that applies to it. This response includes:

• Complete list of certificate templates the client is authorized to use
• Template-specific settings, including key size requirements, validity period, renewal threshold, subject name configuration, and key usage flags
• Target Certification Authority information: the CA that the client should submit requests to
• Enrollment policy configuration: auto-enrollment behavior, renewal settings
• Policy ID: the unique identifier that ties the policy to its source

In simple terms, this response acts as a complete instruction manual that the client uses to build a valid and compliant certificate request.

Step 3: Client Builds the Certificate Request

Using the policy response from CEP, the client constructs the certificate request. This involves:

• Generating a cryptographic key pair: public and private key using the algorithm and key size specified in the template (RSA 2048, RSA 4096, or ECC)
• Building the Certificate Signing Request (CSR) in PKCS#10 format
• Selecting the certificate template that matches the client needs
• Populating the Subject field: typically the machine name, user UPN, or custom subject based on template configuration
• Adding Subject Alternative Names (SANs): DNS names, IP addresses, or UPNs as required
• Applying template-defined extensions: Key Usage, Enhanced Key Usage, CDP, AIA

The client uses CEP policy response to ensure the request is perfectly aligned with what the CA will accept.

Step 4: Client Sends Request to CES

Once the certificate request is prepared, the client sends it to the CES endpoint over HTTPS. This request is in PKCS#10 format and includes the required authentication method, such as a Kerberos ticket, username/password, or a client certificate, depending on how CES is configured. At this point, CES takes over as the active processing layer. The client has done its part and now waits while CES handles authentication, forwards the request to the CA, and completes the enrollment process.

Step 5: CES Authenticates Client and Forwards to CA

This is the most security-critical step in the entire workflow. CES performs two operations sequentially:

Authentication: CES validates the client identity using the configured authentication method. For Kerberos, it validates the service ticket. For username/password, it validates the credentials against Active Directory. For certificate-based renewal, it validates the existing certificate. No request moves forward until authentication succeeds.

Forwarding: Once authentication succeeds, CES maps the authenticated identity to the appropriate CA and forwards the certificate request. CES uses its backend service account and CA communication configuration to relay the request securely to the internal CA, which the client has no direct path to.

Step 6: CA Processes the Certificate Request

When CES forwards the certificate request, the Certification Authority (CA) evaluates it using its configured rules and policies, such as:

• Certificate template permissions: is this identity authorized to enroll for this template?
• Issuance requirements: does the request meet all required attributes?
• CA policy: are there any CA-level restrictions that apply?
• Manager approval settings: does this template require manual approval?

Based on these checks, the CA makes a decision: it issues the certificate if everything is valid, pends the request if manual approval is needed, or denies it if the requester is not authorized or the request does not meet the required criteria.

Step 7: CES Delivers CA Response to Client

After the Certification Authority makes a decision, CES sends that result back to the client over HTTPS. The results can be as follows:

• If the request is issued, CES returns the completed, signed certificate, typically in PKCS#7 format, so the client can install and use it.
• If the request is pending, CES sends back a Request ID along with a pending status, which allows the client to check again later for the final result.
• If the request is denied, CES returns the relevant error code and the reason for denial, so the client or administrator can understand why the certificate was not issued.

Step 8: Client Receives and Installs Certificate

Once the certificate request is processed, the client gets the result. If the request is approved, the certificate is automatically installed in the correct Windows certificate store, Local Machine\Personal for computer certificates and Current User\Personal for user certificates, so it is ready to use without manual steps. If the request is still pending (for example, waiting for approval), the system keeps checking CES at intervals until a final decision is made. If the request is denied, the failure is recorded in system logs, allowing administrators to review what went wrong and take action if needed.

Breakdown of Kerberos Authentication in CEP and CES

Kerberos is a secure, ticket-based authentication system used in Active Directory that allows users or machines to prove their identity without sending passwords over the network. It works through a trusted service called the Key Distribution Center (KDC), which runs on domain controllers.

The following are the steps on how Kerberos authentication works:

When a user logs into a domain-joined Windows machine, Kerberos authentication begins automatically in the background:

• The client sends an AS-REQ (Authentication Service Request) to the Key Distribution Center (KDC), which runs on the Domain Controller.
• The KDC verifies the client identity using the stored credential hash (for a user or machine account) in Active Directory.
• If the credentials are valid, the KDC issues a Ticket Granting Ticket (TGT).
• This TGT is encrypted using the KDC secret key, ensuring it cannot be forged or tampered with.
• The client stores the TGT securely in memory within LSASS (Local Security Authority Subsystem Service); it is never written to disk.

When the client needs to contact CEP or CES (for certificate enrollment or policy retrieval):

• The client sends a TGS-REQ (Ticket Granting Service Request) to the KDC.
• It includes its TGT and requests access to a specific service, identified by the Service Principal Name (SPN) of CEP or CES.
• The KDC looks up this SPN in Active Directory and identifies the associated service account running CEP/CES (typically an IIS app pool identity).
• The KDC generates a Service Ticket, which is encrypted using the service account secret key, meaning only that service can decrypt it.
• The Service Ticket is returned to the client and stored temporarily in memory.

When the client actually connects to CEP or CES:

• It sends the Service Ticket as part of the HTTPS request using the HTTP Negotiate/Kerberos Authorization header.
• IIS (hosting CEP/CES) receives the request and attempts to decrypt the ticket using the application pool service account credentials.
• Once decrypted, the ticket reveals: client identity (username or machine account), domain information, group memberships, and session key for secure communication.
• CEP/CES then validates the ticket: ensures the ticket is authentic and untampered, checks the timestamp (must be within the allowed 5-minute clock skew tolerance), and verifies that the ticket is still valid.

Kerberos authentication is designed to be completely transparent for the end user; there are no prompts or manual inputs because authentication happens automatically in the background using the logged-in domain identity.

It works natively for all domain-joined Windows machines and users, where the machine account or user account in Active Directory acts as the authenticating identity. The tickets issued by Kerberos are time-bound, typically valid for around 10 hours (configurable via Group Policy), which balances security and usability.

However, Kerberos relies on strict conditions: the client and server clocks must be synchronized within a small window (usually 5 minutes), and the client must have network connectivity to a Domain Controller to obtain and renew tickets.

When to Use Kerberos?

Deploy Kerberos authentication for CEP and CES when:

• All enrolling clients are domain-joined Windows machines
• You are deploying Group Policy auto-enrollment for computer or user certificates
• Clients have reliable, low-latency connectivity to a Domain Controller
• The primary use case is machine certificate auto-enrollment
• Maximum security posture with zero credential exposure is required
• You want fully silent, zero-interaction certificate lifecycle management
• Your environment is a single forest or has well-established cross-forest Kerberos trusts
• You are deploying across an internal corporate network or an enforced split-tunnel VPN

Breakdown of Username/Password Authentication in CEP/CES

Username/password authentication in CEP and CES is used when the client cannot rely on Kerberos, usually because it is not domain-joined, is connecting from an external network, or does not have direct connectivity to a Domain Controller.

Tip: When Microsoft documentation refers to Username/Password authentication for Certificate Enrollment Policy Web Service (CEP) and Certificate Enrollment Web Service (CES), it is referring specifically to HTTP Basic Authentication, a standardized authentication scheme defined in RFC 7617, operating over an HTTPS transport layer.

In this model, the client manually provides a username and password, and these credentials are sent to the CEP or CES web service over HTTPS for validation. The service then checks those credentials against Active Directory to confirm the identity of the user before allowing access to enrollment policy or certificate enrollment functions.

Following is the step-by-step breakdown of how Username/Password authentication works:

• Client takes the username and password and Base64-encodes them in the format username:password
• Encoded credential is placed in the HTTP Basic Authorization header
• Entire request travels over HTTPS; TLS is the only protection for the credentials in transit. Critical point: Base64 is encoding, not encryption. Without HTTPS, the credentials are completely exposed.
• CEP extracts and decodes the Authorization header. Passes the raw username and password to Active Directory for validation via LDAP bind.
• AD checks: Is the account valid and active? Is the password correct? Is the account unlocked and not expired?
• If the username and password validation fail, CEP immediately rejects the request and returns an HTTP 401 Unauthorized response, meaning the client is not allowed to continue.
• If the authentication succeeds, CEP accepts the identity, evaluates what certificate enrollment policy applies to that user or machine, and then returns the enrollment policy details back to the client.
• When the client sends the certificate request (CSR) to CES, it must provide its credentials again because CES does not rely on or inherit the earlier authentication done by CEP.
• CES performs its independent validation against Active Directory using the same username/password authentication process.
• Once the identity is confirmed, CES checks whether that user or machine has Enroll permission on the requested certificate template and whether the request itself matches the template requirements.
• If any of these checks fail, CES rejects the request. If they pass, CES accepts the request and forwards it to the Certification Authority on the client behalf.

This method is more flexible for remote users, internet-based systems, partner devices, and non-domain-joined machines, but it is also less secure than Kerberos because it depends directly on passwords. Even though the credentials are protected in transit by TLS, the security still relies on strong password practices, secure endpoint handling, and careful IIS configuration. In simple terms, username/password authentication is the practical fallback for CEP/CES when Kerberos cannot be used, but it requires more caution because it introduces direct credential handling into the certificate enrollment process.

When to Use Username/Password?

Deploy Username/Password authentication for CEP and CES when:

• Enrolling clients are not domain-joined: workgroup machines, contractor devices, IoT endpoints
• You need cross-forest or cross-organization enrollment without Kerberos trust
• Clients cannot reliably reach a Domain Controller at enrollment time
• You are supporting internet-facing enrollment for remote and mobile devices
• The deployment is a PKIaaS or managed PKI scenario serving externally managed clients
• You need to support non-Windows platforms requiring certificate enrollment
• Kerberos infrastructure is unavailable or impractical in the target environment

Certificate-Based Authentication: The Third Option for Renewal

Certificate-based authentication is the third authentication option available with CES, and it is mainly used for certificate renewal, not for first-time enrollment. In this method, the client does not authenticate with Kerberos or a username and password. Instead, it proves its identity by presenting its existing valid certificate to CES during the renewal request. CES then validates that certificate by checking whether it is trusted, whether it is still valid, whether it chains to a trusted CA, and whether it matches the identity that is attempting the renewal. If the certificate passes validation, CES accepts that certificate as proof of identity and allows the renewal request to continue.

This approach is useful because it avoids sending passwords and does not depend on the client having Kerberos connectivity to a Domain Controller. It is especially valuable for remote or non-domain-connected systems that already have a certificate and simply need to renew it. However, this method is generally limited to renewal scenarios because the client must already possess a valid certificate to authenticate in the first place. In simple terms, certificate-based authentication lets the existing certificate act as the client identity proof, making it a secure and efficient option for renewing certificates through CES.

Note: Auto-enrollment using CEP and CES works seamlessly when the PKI is deployed on-premises and fully integrated with Active Directory. However, when the PKI is delivered as a managed service, and the Certification Authority resides outside the organization network boundary, the question is: how can devices securely enroll for certificates from a CA that they cannot directly access?

Key Capabilities of the PKIaaS Enrollment Gateway

• Seamless AD Integration: The Enrollment Gateway integrates with your existing Active Directory infrastructure. Your Group Policy auto-enrollment configuration points to the Gateway endpoint rather than an on-premises CES URL. Domain-joined machines continue to enroll using Kerberos authentication; nothing changes from the endpoint perspective.
• Support for Non-Domain and Remote Devices: The Enrollment Gateway supports username/password authentication for non-domain-joined devices, remote endpoints, cloud workloads, and any device that cannot use Kerberos. This gives you a single enrollment gateway that serves your entire device fleet, domain, and non-domain alike.
• Zero Exposure of CA Infrastructure: Because the Enrollment Gateway acts as the broker, your devices never communicate directly with the Encryption Consulting CA infrastructure. The CA remains completely protected behind the Gateway authentication and authorization layer. This is the same zero-exposure principle that makes CES architecturally secure, applied to a fully managed PKIaaS environment.
• Certificate Lifecycle Visibility: Every enrollment transaction through the Encryption Consulting Enrollment Gateway is logged, tracked, and fed into the certificate lifecycle management layer. You get visibility into every certificate issued, every renewal processed, and every enrollment failure, without running any of the infrastructure yourself. CertSecure Manager integrates with this telemetry for complete lifecycle automation across all enrolled devices.
• Scalability Without Capacity Planning: Whether you are enrolling certificates for 500 devices or 500,000 devices, the Enrollment Gateway scales to match demand without requiring your team to provision, size, or manage enrollment infrastructure.
• Compliance-Ready Audit Trail: Every enrollment transaction is logged with full auditability: requester identity, authentication method, template used, CA response, timestamp, and outcome. This supports PKI-related compliance requirements across SOC 2, ISO 27001, FedRAMP, HIPAA, and PCI DSS. For organizations building toward crypto-agility and post-quantum readiness, CBOM Secure provides cryptographic inventory across all enrolled certificates, and PQC Readiness assessment services help organizations plan the migration of CEP/CES enrollment to ML-DSA-based certificates.

The Business Case: Build It Yourself vs EC PKIaaS with Enrollment Gateway

Consideration	DIY CEP/CES On-Premises	Encryption Consulting PKIaaS + Enrollment Gateway
Internal PKI Expertise Required	High, requires deep AD CS and PKI knowledge	Minimal expertise provided by Encryption Consulting
CA Infrastructure Management	Managed by the internal team	Fully managed by Encryption Consulting
HSM Management	Your hardware, your key ceremonies	Managed by Encryption Consulting
Certificate Template Maintenance	Manual and often overlooked	Managed and periodically reviewed
Auto-Enrollment for Remote Devices	Complex CEP/CES setup required	Built-in via Enrollment Gateway
Certificate Lifecycle Visibility	Manual tracking or third-party tools are needed	Included within the PKIaaS platform
Compliance Documentation	Created and maintained internally	Provided and maintained by Encryption Consulting
Scaling	Requires additional infrastructure investment	Elastic and scales automatically
Algorithm Migration (e.g., RSA to PQC)	Manual updates to templates and CA	Proactively managed
Single Point of Accountability	Distributed across IT teams	Centralized, owned by Encryption Consulting

How Encryption Consulting Can Help

With deep hands-on expertise across enterprise PKI design, HSM management, certificate lifecycle automation, and compliance frameworks, Encryption Consulting has built and managed PKI environments for organizations ranging from mid-market enterprises to large-scale regulated industries, including finance, healthcare, and government.

Here is where Encryption Consulting PKIaaS offering addresses the specific technical challenge. The Encryption Consulting PKIaaS Enrollment Gateway is a purpose-built enrollment broker service that operates as the authenticated intermediary between your enrolled devices and the Encryption Consulting-managed CA infrastructure. Functionally, it performs the enrollment brokering role, accepting certificate requests from your devices, authenticating them, and forwarding them to the appropriate CA on your behalf.

Think of it as the enrollment translation layer between your existing Active Directory and Group Policy auto-enrollment infrastructure and the externally managed PKIaaS CA, without requiring you to replace or redesign any of your existing enrollment workflows.

For your devices and your IT team, enrollment works exactly the same way it always has. Domain-joined machines auto-enroll via Group Policy. Non-domain devices enroll using their configured method. Certificates appear in the right certificate stores automatically. Renewals happen silently before expiry.

Behind the scenes, the Enrollment Gateway handles all the complexity: routing requests to the correct Encryption Consulting-managed issuing CA, enforcing authentication and authorization policy, returning results to clients, and feeding telemetry back into the certificate lifecycle management platform. For organizations building a complete cryptographic inventory alongside their PKI modernization, CBOM Secure provides the machine identity and certificate discovery layer that complements CEP/CES enrollment with continuous visibility. As post-quantum cryptography adoption accelerates following the publication of NIST FIPS 203, 204, and 205 (August 13, 2024), EC PKI Services include PQC Readiness assessment to help organizations plan the transition of AD CS certificate templates and enrollment workflows to ML-DSA-based certificates.

Conclusion

CEP and CES are essential components of any modern enterprise PKI, not optional ones. Every organization today has devices operating outside the corporate network boundary, and without CEP and CES, certificate auto-enrollment simply cannot function for those systems.

In domain environments, Kerberos remains the gold standard for authentication, offering secure, seamless access without exposing credentials, supporting mutual authentication, machine identities, and full Group Policy-based auto-enrollment. For domain-joined devices, there is no practical or security-based reason to use an alternative. At the same time, username/password authentication plays a critical and valid role in scenarios where Kerberos cannot be used, such as non-domain devices, cross-forest access, PKIaaS environments, or internet-facing enrollment. The correct approach is not to avoid it, but to implement it securely with strong controls like dedicated low-privilege accounts, enforced TLS, web application firewall protection, and proper monitoring.

While setting up a CA may be straightforward, operating PKI at scale, handling lifecycle management, compliance, algorithm transitions, and seamless enrollment across all device types requires ongoing expertise that many organizations cannot justify maintaining. Encryption Consulting PKIaaS and Enrollment Gateway address this by delivering enterprise-grade PKI with minimal operational burden, ensuring that certificates renew automatically, systems remain highly available, and organizations do not need dedicated PKI specialists to keep everything running smoothly. The DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the past year. CEP and CES, deployed correctly and monitored continuously, are the AD CS mechanism for keeping that number at zero.

Frequently Asked Questions

What is the main takeaway from the Ultimate Guide to Understanding CEP and CES?

CEP and CES extend Microsoft AD CS certificate enrollment to any device, regardless of domain membership or network location, over HTTPS. CEP delivers enrollment policy via the MS-XCEP protocol so clients know what they can request. CES processes the actual certificate request via MS-WSTEP and forwards it to the CA. Together they close the enrollment gap for remote workers, cloud workloads, DMZ servers, and non-domain-joined devices that cannot reach Active Directory directly.

Why does CEP and CES enrollment matter for enterprise PKI teams?

Enterprise PKI teams face a shrinking enrollment window. CA/Browser Forum Ballot SC-081v3 cuts public TLS certificate lifetimes to 47 days by March 2029, and the DigiCert Trust Pulse Survey (July 2025) found that 45 percent of enterprises experienced certificate-related downtime in the prior year. When devices outside the domain boundary cannot enroll automatically, certificates expire undetected. CEP and CES enable automated renewal for every device type, reducing the manual effort and outage risk that come with managing certificates across hybrid and distributed environments.

What risks increase if CEP and CES are handled manually or not deployed?

Without CEP and CES, organizations must rely on manual certificate request and delivery for any device outside the domain boundary. Manual processes introduce missed renewals, expired certificates, and undetected gaps in certificate inventory. Certificate expiration ranked among the top three CISO concerns (56.6 percent) in the DigiCert Trust Pulse Survey (July 2025). In hybrid environments, the absence of automated web enrollment means certificates for cloud workloads and remote endpoints must be tracked and renewed by hand, which does not scale as certificate lifetimes shrink toward 47 days.

Which teams should own CEP and CES deployment and governance?

PKI admins own the deployment, configuration, and ongoing operation of CEP and CES: SPN registration, constrained delegation, IIS configuration, template permissions, and authentication method selection. Security architects own the trust boundary design: which devices use Kerberos, which use username/password, and where certificate-based renewal applies. Active Directory teams own SPN registration and constrained delegation configuration for the CES service account. Platform and cloud teams own CEP/CES integration for cloud workloads and non-domain devices. Compliance teams own audit evidence that enrollment transactions are logged and that certificate lifecycle events are captured.

How do CEP and CES connect to certificate lifecycle management?

CEP and CES are the enrollment transport layer that certificate lifecycle management platforms depend on for automated certificate delivery to devices outside the domain boundary. CLM platforms like CertSecure Manager use the enrollment policy delivered by CEP and the request brokering provided by CES to automate issuance, renewal, and revocation across the full device estate. Without CEP and CES, CLM automation cannot reach non-domain-joined endpoints, cloud workloads, or remote devices, which leaves those certificates outside the managed lifecycle and subject to undetected expiry.

How should organizations measure success for CEP and CES deployments?

Key metrics: percentage of devices successfully auto-enrolling through CEP and CES versus requiring manual certificate delivery (target: 100 percent automated for in-scope device types); mean time to detect and resolve enrollment failures (target: under 4 hours with SIEM alerting on IIS 401 and CA enrollment event ID patterns); and certificate expiry rate on devices served by CEP/CES endpoints (target: zero unplanned expirations). Organizations should also track the authentication method distribution across their CEP/CES fleet: the ratio of Kerberos to username/password endpoints indicates how much credential-handling risk exists in the enrollment path.

What should be audited or monitored regularly for CEP and CES?

Monitor continuously: IIS access logs on CEP and CES endpoints for repeated HTTP 401 responses and unexpected source IPs; CA event IDs 4886 (request received), 4887 (certificate issued), and 4888 (request denied) correlated with CES-sourced requests; and TLS certificate expiry on the CEP and CES endpoint certificates themselves. Audit quarterly: review the certificate templates published via CEP and confirm they match the current approved template baseline; verify SPN registration and constrained delegation configuration on the CES service account; and confirm that username/password endpoints enforce HTTPS and that the CES service account is a dedicated low-privilege account.

How do CEP and CES affect cloud, hybrid, or multi-CA PKI environments?

In cloud and hybrid environments, CEP and CES are the primary mechanism for extending on-premises AD CS enrollment to cloud workloads, containerized systems, and remote endpoints that cannot use Group Policy autoenrollment. In multi-CA environments, each CES instance is paired with a specific issuing CA. Organizations must deploy separate CES instances for each issuing CA they want to expose through web enrollment. For cross-forest scenarios, CES endpoints can serve clients from trusted forests using Kerberos cross-forest authentication, provided that the forest trust is configured and the SPN is registered correctly in the target forest. Where cloud-native certificate delivery is needed, PKI as a Service with a managed Enrollment Gateway removes the need for self-managed CEP/CES infrastructure.

What common mistakes should teams avoid when deploying CEP and CES?

The most frequent mistakes: not configuring Kerberos constrained delegation on the CES service account, which causes every enrollment attempt to fail with an access denied error; using a shared service account rather than a dedicated low-privilege account for the CES application pool identity; deploying CEP or CES without enforcing HTTPS, which exposes credentials for username/password endpoints; configuring Kerberos-only authentication on CES endpoints that serve non-domain-joined clients; and not monitoring the TLS certificate on the CEP/CES endpoint itself, allowing the enrollment gateway to go offline when its own certificate expires.

What should be refreshed quarterly for CEP and CES?

Quarterly: confirm the list of certificate templates published through CEP matches the approved template baseline; review IIS and CA audit logs for anomalous enrollment patterns; verify the CES service account constrained delegation targets are current and match the CA hostnames; and check that the TLS certificate on each CEP and CES endpoint has more than 90 days of validity remaining. Organizations running PKIaaS should confirm that the Enrollment Gateway configuration still reflects current template permissions and authentication method assignments. For organizations preparing for post-quantum migration, check the PQC Center of Excellence for updates on ML-DSA support in AD CS role services and adjust template roadmaps accordingly.