ADCS CRL Partitioning: Architecture and Implementation Guide

CRL partitioning is the AD CS feature most teams have heard mentioned and almost none have actually implemented. We’ve covered it as part of our broader roundup of Microsoft’s 2025-2026 AD CS changes and in our implementation checklist, but partitioning is genuinely complex enough, with real one-way-door decisions baked into it, that it needs its own dedicated architecture reference. This is that reference: prerequisites, partition design decisions, the exact registry configuration, publication mechanics, validation, monitoring, and, critically, why rollback isn’t as simple as flipping the feature back off.

For the broader context of what shipped when, see ADCS Changes in 2025 and 2026: What PKI Teams Need to Implement. For migration-specific guidance, see The Ultimate Windows ADCS Migration and Modernization Guide.

TL;DR: Key Takeaways

CRL partitioning splits one large revocation list into multiple smaller files: each certificate is assigned to a specific partition at issuance time, and its revocation entry, if it’s ever revoked, lands only in that partition’s CRL rather than in one ever-growing monolithic file.
This requires Windows Server 2019, 2022, or 2025 with the October 2025 update or later: and it fundamentally requires HTTP-based CDP publication, LDAP URLs are explicitly not supported for partitioned CRLs.
Partition assignment is permanent once made: a certificate bound to a partition at issuance stays bound to that partition for its entire lifetime. You can increase your partition count later, but you cannot decrease it, and you cannot reassign existing certificates to different partitions.
Rollback is the detail every other guide skips: once even one certificate has been issued with a partition assignment, disabling partitioning breaks revocation checking for that certificate permanently unless you keep generating its partition’s CRL or force reissuance. This is not a reversible toggle after go-live.
Partition zero has two distinct behavior modes: aggregated (acting as a complete, full CRL for compatibility with systems that aren’t partition-aware) or exclusive (acting as just another partition, reserved for the CA’s own use). Getting this choice wrong affects every external system that consumes your CRL.

Why CRL Partitioning Exists

A Certificate Revocation List grows for the entire operational lifetime of a CA, which can span decades. High-volume issuing CAs, especially those supporting short-lived certificate programs or large device populations, can accumulate revocation lists large enough to create real client-side performance problems: slow downloads, timeout failures on constrained networks, and unnecessary bandwidth consumption for clients that only ever need to check a handful of specific certificates.

The IETF’s own CRL specification allows for partitioning by revocation reason code through the CRL Distribution Points and Issuing Distribution Point extensions, but this approach has a structural weakness: reason-code partitions are wildly uneven in size (key compromise revocations might be 2% of your total, while superseded or affiliation-changed revocations might be 98%), and a client that cares about all revocation reasons still ends up downloading essentially the full CRL anyway, just split across multiple requests.

AD CS’s partitioning approach works differently: you define a fixed number of partitions, and each certificate is assigned to one at the moment its request is submitted, using either random or round-robin allocation. When a certificate is later revoked, its revocation entry goes into the one partition it was already bound to. Clients validating a specific certificate only need the one partition CRL that certificate references, not the entire revocation history of the CA.

Prerequisites

Confirm your CA’s OS and patch level: partitioned CRL support requires Windows Server 2019, 2022, or 2025 with the 2025-10B update (October 14, 2025) or later installed. Verify this on every CA in your hierarchy you intend to partition, not just one representative server.
Confirm you’re publishing at least one HTTP CDP URL: this is a hard requirement, not a preference. LDAP URLs cannot be used with partitioned CRLs at all, if your CDP configuration is LDAP-only today, you need to add HTTP publication before partitioning is even an option.
Confirm that HTTP URL is included in the Issuing Distribution Point (IDP) CRL extension: this is a separate checkbox from simply including the URL in the CDP extension of issued certificates, and it’s easy to miss since it doesn’t affect anything until you actually enable partitioning.
Confirm your actual need for this feature before implementing it: partitioning adds real configuration complexity and a permanent architectural decision to your CA. It’s specifically valuable for CAs with genuinely high revocation volume or CRL size; a low-volume internal CA with a small, stable certificate population may not benefit enough to justify the added complexity.
Audit your relying party and client population for IDP extension support: older or non-updated clients that don’t correctly interpret the IDP extension may not handle partitioned CRLs the way you expect, test against your actual client fleet, not just current-generation Windows systems, before committing.

Partition Design

Three decisions here are effectively permanent once you’ve issued certificates under them, so they deserve more deliberation than the registry configuration itself.

How many partitions: the practical upper limit is 65,535, but that’s not a target. If your revocation volume is unknown, starting with somewhere between 5 and 10 partitions is a reasonable baseline. If you can estimate your revocation volume with more confidence, size toward a partition count that keeps each individual partition file comfortably small, common choices land around 20 to 50 for higher-volume environments. You can increase your partition count later if volume grows, but you cannot decrease it, so err toward a conservative starting number rather than an aggressive one.
Assignment algorithm: round-robin or random: round-robin cycles through partitions sequentially as requests arrive, producing predictable, even distribution. Random allocation is less predictable but avoids any risk of a request pattern correlating with partition assignment in a way that creates uneven load. Round-robin is the more common and easier-to-reason-about choice for most environments.
Partition zero’s behavior mode: AD CS supports two distinct strategies. In the aggregated model, partition zero acts as a complete CRL containing every revoked certificate across all partitions, which keeps compatibility with any external system, monitoring tool, or relying party that isn’t partition-aware and just wants "the CRL." In the exclusive model, partition zero behaves like any other partition, containing only its own subset of revocations, and gets reserved for CA-specific uses such as auto-generated cross-certificates on a root CA or certificates that were already revoked before partitioning was enabled. For most organizations, the aggregated model is the safer default specifically because it preserves compatibility with systems you haven’t audited for partition awareness.
Understand that partition assignment happens once, at request submission, and never changes: a certificate’s bound partition is fixed at the moment its CSR arrives at the CA. If it’s later revoked, that revocation lands in the partition it was already assigned to, there’s no mechanism to move a certificate to a different partition after the fact.

Registry and Configuration

The core configuration lives in the CA’s registry settings, applied through certutil -setreg and requiring a Certificate Services restart to take effect.

Enable the partitioning flag: certutil -setreg ca\CRLFlags +CRLF_ENABLE_CRL_PARTITION This is a global switch, enabling it alone doesn’t change anything else about your CA’s behavior until the other settings below are also configured.
Define your maximum partition count: certutil -setreg ca\CRLMaxPartitions 10 Set this to the number you settled on during partition design, remembering this value can be increased later but never decreased.
Optionally set the partition zero exclusivity flag, if you’ve chosen the exclusive model rather than the default aggregated behavior: certutil -setreg ca\CRLFlags +CRLF_PARTITION_ZERO_EXCLUSIVE Leave this unset if you want the default aggregated (complete CRL) behavior on partition zero.
Update your CDP publication URL templates to include the new <CRLPartitionIndex> variable, in every file, UNC, and HTTP path: certutil -setreg ca\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3<CRLPartitionIndex>%8%9.crl\n65:\\fileserver\CertData\%3<CRLPartitionIndex>%8%9.crl\n134:http://cdp.example.com/CertEnroll/%3<CRLPartitionIndex>%8%9.crl" At runtime, this variable is substituted with _PartitionXXXXX (a zero-padded, five-digit partition number) for every partition except partition zero, which substitutes to an empty string, behaving exactly like the existing <CRLNameSuffix> variable does for CA key rollover.
Restart Certificate Services for the configuration to take effect: Restart-Service CertSvc
Trigger and verify publication: certutil -CRL Confirm partition-specific CRL files are actually generated in each configured publication location before moving further.

Publication

Once configuration is applied, publication behaves according to the strategy you chose during partition design, but a few mechanics are worth understanding directly rather than treating as a black box.

Every publication location needs the partition variable, not just your primary one: file system paths, UNC share paths, and HTTP URLs all need <CRLPartitionIndex> included in their template, missing it on even one location means that location won’t correctly generate per-partition files.
The numeric prefixes in CRLPublicationURLs control publication behavior, encoding flags like whether the location is included in the CDP extension of issued certificates, whether it’s included in the CRL itself, and which protocol it represents, these aren’t arbitrary numbers, they’re a bitmask you should understand rather than copy blindly from an example.
Partition zero’s published file name has no partition suffix, by design, this preserves backward compatibility with any tooling or relying party expecting the CA’s traditional, unpartitioned file naming convention to keep working for at least the aggregate or zero partition.
Confirm HTTP publication is actually reachable from your relying parties, not just from the CA server itself, a partition file that publishes successfully to a local file path but fails to sync to your actual HTTP endpoint produces a CDP reference in issued certificates that resolves to nothing.

Validation

Confirm the IDP extension is present and correctly populated on certificates issued after partitioning was enabled, this is what allows a compliant client to correctly scope its CRL retrieval to the right partition rather than assuming it needs the full revocation history.
Issue a test certificate against a representative template and inspect its CDP extension directly, confirming it references the specific partition URL it was assigned to, not a generic or unpartitioned CDP location.
Revoke that test certificate and confirm the revocation appears in the correct partition’s CRL, and only that partition, using certutil -dump against the specific partition file to verify contents directly rather than assuming correct behavior from a lack of errors.
Test end-to-end validation from an actual client, using certutil -urlfetch -verify against the test certificate to confirm the full chain-building and revocation-check path works, not just that the file exists on the server.
Test against your actual client population’s OS versions, not just current-generation systems, since IDP extension handling and partition-aware CRL retrieval depend on client-side support that varies by OS version and patch level.

Monitoring

Partitioned CRLs introduce new programmatic visibility that standard CRL monitoring doesn’t cover, and it’s worth building this into your ongoing operations rather than treating go-live validation as sufficient.

Use the new ICertRequest2/ICertAdmin2 API properties for per-partition status, specifically CR_PROP_CRLPARTITIONCOUNT (PropID 0x2E) to confirm the configured partition count, and CR_PROP_PARTITIONED_BASECRL (PropID 0x2F) and the delta CRL equivalent to retrieve and verify individual partition CRLs directly through PowerShell or scripted monitoring rather than only checking the file system.
Monitor publication status per partition, not just in aggregate, a monitoring approach that only confirms "a CRL was published somewhere" can miss a specific partition silently failing to update while the rest of your partitions continue publishing normally.
Watch for the dedicated Windows events tied to partition misconfiguration, these are new event types specific to this feature and won’t be covered by monitoring rules built for pre-partitioning CRL publication alone.
Track partition assignment distribution over time, confirming your chosen algorithm (round-robin or random) is actually producing the distribution you expected, a skewed distribution can indicate a configuration problem worth investigating before it becomes a capacity issue in one specific partition.

Rollback

This is the section every other piece of coverage on this feature treats too lightly, and it’s the one that should shape your entire rollout approach.

Disabling the partitioning flag is only clean before any certificate has been issued under it: certutil -setreg ca\CRLFlags -CRLF_ENABLE_CRL_PARTITION is a valid command at any point, but its consequences depend entirely on whether certificates already reference partition-specific CDP URLs.
Once at least one certificate has been issued with a partition assignment, disabling partitioning breaks its revocation checking path: the CA stops generating and updating partition-specific CRLs once the flag is disabled, but certificates already issued still have partition-specific URLs baked into their CDP extension. Relying parties trying to check those certificates will fail to retrieve a CRL that no longer gets updated, effectively breaking revocation checking for every certificate issued while partitioning was active.
There is no supported path to reassign an issued certificate to a different partition, or back to an unpartitioned state: the only ways to fully unwind this once certificates are in circulation are to continue generating and publishing the relevant partition CRLs indefinitely for the life of those certificates, or to force reissuance of every affected certificate under a non-partitioned configuration.
Suspending a partition is a softer, safer alternative to disabling the whole feature: rather than reverting partitioning entirely, you can freeze specific partitions so the CA stops assigning new certificate requests to them while continuing to maintain and publish their existing revocation data. This lets you halt further partition growth without breaking revocation checking for certificates already bound to existing partitions.
Treat the initial rollout as effectively permanent from day one: given how limited genuine rollback is, your lab testing and pilot phase before enabling this in production needs to be more rigorous than for a typical reversible configuration change, because "we’ll just turn it off if it doesn’t work" is not an accurate assumption here.

How Encryption Consulting Can Help

Partition design decisions, particularly partition count, assignment algorithm, and the aggregated-versus-exclusive choice for partition zero, are effectively permanent once certificates start flowing through them, which makes this exactly the kind of architecture decision worth getting reviewed before implementation rather than learning from in production.

Encryption Consulting’s PKI Services team supports CRL partitioning specifically:

Partition design review: working through partition count, assignment algorithm, and partition zero strategy against your actual CA hierarchy, revocation volume, and relying party population before you commit to a configuration you can’t fully reverse.
Prerequisite and readiness assessment: confirming your CDP infrastructure, patch levels, and client population are actually ready for partitioned CRLs, including the HTTP-only requirement and IDP extension support.
Configuration and lab validation: implementing and testing the registry configuration, publication URLs, and end-to-end validation in a non-production environment before any production rollout.
Monitoring setup, building per-partition publication monitoring using the new API properties, so a single failing partition doesn’t go unnoticed inside an otherwise-healthy CRL publication process.
Rollout sequencing guidance, including how to use partition suspension as a controlled brake rather than discovering mid-rollout that full rollback isn’t available.

If you’re considering CRL partitioning, or already rolled it out without fully working through the rollback implications, our PKI Services team can review your design and help you implement or correct it safely.

Conclusion

CRL partitioning solves a genuine scalability problem for high-volume CAs, but it’s an architecture decision with real permanence built into it, not a configuration toggle you can casually experiment with in production. Get your prerequisites confirmed, your partition design decisions deliberated rather than defaulted, and your rollback understanding accurate before you enable this on a live CA. The registry configuration itself is a handful of certutil -setreg commands; the decisions behind those commands are what actually matter.

Weighing whether CRL partitioning is right for your CA, or need a design review before rollout? Talk to our PKI Services team about planning your partitioning architecture. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

Can CRL partitioning work with LDAP-published CRLs? No. Partitioned CRLs require at least one HTTP CDP URL, and that URL must be included in the Issuing Distribution Point extension. LDAP URLs are not supported for this feature at all.

Can I reduce the number of CRL partitions after enabling the feature? No. You can increase your maximum partition count later if revocation volume grows, but you cannot decrease it once set. Choose a conservative starting number based on your best estimate of revocation volume rather than an aggressive one.

What happens if I disable CRL partitioning after certificates have already been issued? Certificates issued while partitioning was active have partition-specific CDP URLs embedded in them. Disabling the partitioning flag stops the CA from generating and updating those partition CRLs, which breaks revocation checking for every certificate already issued under partitioning, unless you continue publishing those partitions or reissue the affected certificates.

Should partition zero be aggregated or exclusive? For most organizations, the aggregated model, where partition zero acts as a complete CRL, is the safer default because it preserves compatibility with monitoring tools, relying parties, or other systems that aren’t partition-aware and simply expect a full CRL. The exclusive model is better suited to environments that have specifically audited every consumer of their CRL for partition awareness.

How many CRL partitions should I start with? If your revocation volume is unknown, 5 to 10 partitions is a reasonable starting baseline. If you can estimate volume with more confidence, size toward a count that keeps each partition file comfortably small, commonly in the 20 to 50 range for higher-volume environments. Since you can increase but never decrease this number, start conservatively.