Skip to content
Posted in

Microsoft Introduces Powerful Enhancements to Active Directory Certificate Services (ADCS) in 2025 

Powerful Enhancements to ADCS

Microsoft has unveiled substantial updates to Active Directory Certificate Services (ADCS), delivering critical improvements in scalability, performance, auditability, and security. These enhancements mark a significant evolution in enterprise certificate management, especially vital for organizations that rely on ADCS to support identity assurance, secure communications, and protect sensitive data through Public Key Infrastructure (PKI) services. 

Our blog explores the major features introduced in recent releases, offering a technical breakdown of their capabilities and implications for enterprise environments.

CRL Partitioning for Efficient Revocation at Scale 

Traditionally, managing Certificate Revocation Lists (CRLs) in large-scale environments has been inefficient and bandwidth-heavy. Clients validating a certificate were forced to download the entire CRL, even when only one revoked certificate needed verification. This legacy design posed scalability challenges for environments with high certificate turnover or limited network resources. 

The New Approach

Microsoft addresses this with CRL Partitioning, a long-requested feature that introduces smarter, more granular revocation handling: 

  • Partitioned CRLs: The monolithic CRL can now be divided into multiple partitions based on certificate serial numbers. 
  • Targeted Downloads: Clients request only the relevant partition of the CRL necessary for validating a certificate. 
  • Reduced Bandwidth and Latency: Significant improvements in performance for validation operations, particularly in environments with constrained bandwidth or high-frequency validations (e.g., load balancers, VPNs, or large user bases). 

CRL Partitioning is backward compatible and designed to coexist with existing mechanisms like Online Certificate Status Protocol (OCSP). Microsoft enables dual publishing, where both the monolithic CRL and its partitions are simultaneously available, ensuring seamless transition and operational continuity. 

Step-by-Step guide to enable CRL Partitioning

To enable CRL partition refer to the following steps: 

  1. Run the following command to enable the CRL partitioning flag:
    certutil -setreg ca\CRLFlags +0x00400000
  2. Set the maximum number of partitions:
    This command defines how many CRL partitions you want to maintain (e.g., 10):
    certutil -setreg ca\CRLMaxPartitions 10
  3. Restart the CA Service:
    Run the following commands to apply the changes:
    net stop certsvc
    net start certsvc

The following image presents the properties of a partitioned CRL, showing the configured CRL distribution point for a specific partition, validating that clients can locate and download the appropriate CRL files.

The following image displays the Certification Authority management console, highlighting how issued certificates are now assigned to different CRL partition indexes, confirming the CRL partitioning feature is active.

Removal of 4KB Extension Limit: Unlocking Policy Flexibility 

Earlier versions of ADCS imposed a 4KB size limit on certificate extensions, restricting the complexity of certificate metadata and policy information that could be embedded within the certificate. 

4kb-extension limit

With the removal of this limitation, organizations can now: 

  • Define complex certificate policies that reflect nuanced security or business requirements. 
  • Embed custom extensions, including advanced identity attributes or hardware-specific markers. 
  • Align with changing standards and future-ready cryptographic schemes, such as those needed for post-quantum cryptography. 

This enhancement brings ADCS in line with the capabilities of modern Certificate Authorities and paves the way for increased adoption in hybrid, cloud-native, and IoT-driven infrastructures. 

Run the following commands to add 0x1000 to the DBFlags registry key value and then restart ADCS:  

certutil -setreg DBFlags +0x1000  

net stop certsvc && net start certsvc  

Now, to verify the limit settings, run the following commands and check the MaxLength property of ExtensionRawValue in the output:  

16kb-limit

ADCS Audit Logging Enhancements for Deeper Insight on Security Operations 

Security teams require detailed audit trails for digital certificate operations to support compliance, incident response, and forensic investigations. Recognizing this need, Microsoft has introduced enhanced audit logging in Windows Server 2025 for ADCS. 

Event ID  Event Summary  
4886 Certificate Services received a certificate request.
Request ID: %1   Requester: %2   Attributes: %3  
4887 Certificate Services approved a certificate request and issued a certificate.
Request ID: %1   Requester: %2   Attributes: %3   Disposition: %4   SKI: %5   Subject: %6  
4888 Certificate Services denied a certificate request.
Request ID: %1   Requester: %2   Attributes: %3   Disposition: %4   SKI: %5   Subject: %6  
4889 Certificate Services set the status of a certificate request to pending. Request ID: %1   Requester: %2   Attributes: %3   Disposition: %4   SKI: %5   Subject: %6  

New Fields in Event ID 4886 – Certificate Request Received  

Field Name  Description  
Subject (from CSR)  Represents the subject value extracted from the Certificate Signing Request (CSR), if available.  
SAN (from CSR)  Refers to the Subject Alternative Name (SAN) extension obtained from the CSR, if present.  
Requested Template  Specifies the certificate template name as provided in the request—either as a version 2 template extension or a version 1 template property/attribute.  
RequestOSVersion  Indicates the client’s operating system version using the szOID_OS_VERSION attribute. Refer to Section 2.2.2.7.1 of [MS-WCCE] for details.
Note: Provided by the client; not used for making security decisions.  
RequestCSPProvider   Details the Cryptographic Service Provider (CSP) used to generate the key pair, identified via the szOID_ENROLLMENT_CSP_PROVIDER attribute. Refer to Section 2.2.2.7.2 of [MS-WCCE].
Note: Client-provided; not intended for security decision-making.  
RequestClientInfo  Captures supplementary client details through the szOID_REQUEST_CLIENT_INFO attribute. Refer to Section 2.2.2.7.4 of [MS-WCCE]. Note: Provided by the client; not used for security decisions.  

New Fields in Event ID 4887 – Certificate Issued   

Field  Description  
Subject Alternative Name  Contains the SAN extension values in the issued certificate, if present.  
Certificate Template  Indicates the name of the certificate template used during issuance.  
Serial Number  Shows the unique serial number assigned to the issued certificate.  

New Fields in Event IDs 4886 through 4889 – Common Enhancements  

Field  Description  
 
Authentication Service  
Specifies the authentication service used in the request. Values may include “NTLM”, “Kerberos”, and “Schannel”, as defined by RPC authentication service constants.  
Authentication Level  Represents the level of authentication applied in the request. Logged values can be “Default”, “None”, “Connect”, “Call”, “Packet”, “Integrity”, or “Privacy”, based on RPC standards.
DCOM or RPC  Indicates whether the request was made using “DCOM” or “RPC”. “RPC” is used for requests via protocols like [MS-ICPR]; otherwise, “DCOM” is recorded.  

These expanded logs significantly boost visibility and enable:  

  • Anomaly detection, such as spotting suspicious SAN values or unauthorized issuance of high-privilege templates (e.g., Domain Controller certificates) 
  • Correlation of events across systems for root-cause analysis 
  • Audit readiness for frameworks like ISO 27001, NIST, PCI DSS, and others 

Security teams can now proactively monitor and build baselines for certificate issuance patterns, helping detect insider threats and misconfigurations early. 

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Microsoft’s Updated ADCS Hardening Guidance 

Certificate Authorities (CAs) represent Tier 0 assets within an enterprise network, making their protection a top priority. Microsoft’s hardening guidelines for ADCS have been updated to reflect modern threat vectors and attack techniques. 

Key Recommendations for Securing Certificate Authorities

  1. Protect the CA’s private key with a Hardware Security Module (HSM)
    • Use FIPS 140-2 Level 3 compliant HSMs to enforce key isolation
  2. Minimize CA attack surface
    • Remove unused certificate templates
    • Enforce least privilege for template enrollment
    • Disable Supply in Request unless strictly controlled
  3. Harden network access
    • Enforce HTTPS for web enrollment services
    • Apply Extended Protection for Authentication
    • Implement mitigations from KB5005413 to reduce NTLM relay risk 
  4. Audit and rotate credentials
    • Regularly review the ACLs on templates and CA objects
    • Monitor enrollment activities for anomalies

Even minor missteps such as over-permissive templates or unmonitored role access can lead to privilege escalation or compromise of the CA. 

Key Recommendations for Securing Certificate Templates

Restrict Enroll and AutoEnroll Permissions  

Overly permissive certificate templates act as one of the easiest ways to move laterally in a domain and exploit. This is because templates that allow ‘any authenticated user or domain user’ to enroll can be misused to gain higher privileges. Therefore, the following points should be implemented:  

  1. Remove broad groups such as “Authenticated Users” or “Domain Users” from Enroll or AutoEnroll permissions.  
  2. Certificate permissions are to be assigned to only a specific set of security groups or specific accounts, such as the IT security team or certain devices.   

Publish only the “necessary ones”  

Some certificate templates created for old projects or tests tend to pile up over time as they are never used. But every published certificate template acts as a potential attack vector. This is because unused templates may have outdated settings or weak permissions, providing attackers an entry. Therefore, the following practices are recommended:  

  1. The regular auditing of templates to understand the purpose and need of the templates.  
  2. For high-sensitivity templates like Enrollment Agent or Key Recovery Agent, publish them only when needed, then disable them afterward.  
  3. During CA setup, use LoadDefaultTemplates=0 in the CAPolicy.inf file to prevent the default templates from auto-publishing.  

Securing the templates with the “Supply in request” option  

The “supply in request” option allows users to mention the subject name they want on their certificate. However, it may also allow an attacker to provide any name, resulting in them requesting a certificate for someone like a domain admin or a domain controller and then using it to impersonate the identity. Therefore, to prevent this, the following settings must be implemented:  

  1. Allow this permission only for the high-privilege accounts.
  2. Enforce additional controlling layers, including the following: 
    • Manager approval workflows,
    • Authorized signatures,
    • Tight monitoring and review
  3. Implement enhanced auditing processes to keep track of who is requesting what, especially in the case of sensitive certificates.  

Operational Considerations for Enterprises

Organizations should begin planning now to adopt these enhancements. Key steps include: 

  • Update monitoring and SIEM tools to parse new audit events and fields 
  • Review certificate templates and remove or tighten access to sensitive ones 
  • Plan and test CRL partitioning in lab environments before production rollout 
  • Implement key storage policies aligned with hardware-backed trust models 
  • Audit NTLM usage in certificate issuance and authentication to prepare for deprecation 

How Encryption Consulting Can Help

Upgrading and hardening ADCS is complex but essential. At Encryption Consulting, we specialize in helping organizations like yours identify and mitigate security risks through tailored PKI Assessments. Our team of experts can provide a customized strategy to protect your PKI architecture from emerging threats, ensuring your data and infrastructure remain secure. Our full range of Public Key Infrastructure (PKI) services helps you safeguard your digital assets and enhance your organization’s overall security posture.  

For those seeking a hands-off solution, our PKI as a Service (PKIaaS) delivers all the benefits of PKI without the burden of in-house management. We ensure to provide four parameters:  

  • Scalability: We will help your PKI infrastructure grow as your business expands.   
  • Cost Efficiency: We reduce overhead by offloading infrastructure maintenance.   
  • Security: We ensure your organization stays compliant and secure with up-to-date PKI management.   
  • Compliance: We ensure your solution meets all regulatory requirements.   

With Encryption Consulting’s PKIaaS, you can focus on your core business while we handle the complexities of PKI management.   

Let us provide the peace of mind that comes from knowing your digital trust and security needs are in expert hands. Reach out today at [email protected] to explore how we can help your organization stay secure against cyber threats.  

Ready to Secure and Modernize Your ADCS Environment?

Let us help you take full advantage of the latest ADCS advancements. Reach out to encryption consulting by dropping an email at [email protected] to explore how we can elevate your certificate infrastructure to meet the demands of today’s zero-trust world. 

Discover Our

Related Blogs

Public vs. Private Keys: Your Guide to Online Security and Privacy 

Read More

Event ID 74 in AD CS – Decoded

Read More

Microsoft’s Strong Certificate Mapping Enforcement — What It Means for Your PKI and How to Prepare

Read More

Explore

More Topics