Windows Server 2025 AD CS ML-DSA Guide: Post-Quantum PKI Setup, Limits and Signature Size

A recent technical comparison published by Shattered examines how moving from a 256-byte RSA-2048 signature to a 2,420-byte ML-DSA-44 signature (or a 4,627-byte ML-DSA-87 signature) alters bandwidth calculations, certificate chain sizes, and Public Key Infrastructure (PKI) migration timelines. For Windows Server administrators and enterprise security architects, this is no longer an abstract cryptographic exercise. With native support in OpenSSL 3.5+, edge-to-origin deployment options in Cloudflare, and Microsoft's official rollout of ML-DSA support in Windows Server 2025 Active Directory Certificate Services (AD CS), the tools to test and deploy lattice-based signatures are already in production.

Why RSA's Clock Is Ticking—And Why Signatures Differ From Encryption​

Classical RSA relies on the computational difficulty of factoring the product of two large prime numbers. While that mathematical hurdle remains secure against today's conventional servers, a sufficiently powerful, fault-tolerant quantum computer running Shor's algorithm could solve integer factorization in polynomial time.

No currently known quantum computer can break RSA-2048 at a cryptographically relevant scale, and security researchers still debate when such hardware might arrive. However, enterprise defenders face two distinct quantum timelines:

1. Key Establishment and Confidentiality (ML-KEM): Encrypted traffic is vulnerable to "harvest now, decrypt later" attacks, where adversaries record encrypted sessions today and wait for quantum hardware to decrypt them in the future. NIST standardized ML-KEM (FIPS 203) to address key exchange.
2. Digital Signatures and Authentication (ML-DSA): Signatures cannot be "decrypted later" in the same way, unless an artifact relies on a signature remaining trustworthy decades from now. Once quantum attacks become practical, an attacker could forge RSA signatures on root certificates, firmware updates, OS patches, or long-term legal documents. NIST standardized ML-DSA (FIPS 204), along with the hash-based SLH-DSA (FIPS 205) as a non-lattice backup, to secure authentication.

Rather than prime factorization, ML-DSA bases its security on module-lattice problems—specifically, finding short vectors in high-dimensional structured lattices. Because Shor's algorithm offers no known efficient shortcut for these lattice problems, ML-DSA resists both classical and quantum attacks.

It is critical for IT teams not to conflate post-quantum key exchange with post-quantum signing. Many widely publicized deployments—such as hybrid post-quantum TLS key agreement or secure messaging protocols—use ML-KEM to protect session confidentiality while still relying on classical RSA or ECDSA certificates for authentication. Moving signatures to ML-DSA requires separate PKI, certificate authority (CA), and client trust store upgrades.

The Dilithium Compatibility Caveat​

Before NIST finalized FIPS 204, ML-DSA was developed and evaluated under the research name CRYSTALS-Dilithium. While they share the same mathematical lineage, IETF RFC 9881 (published in October 2025 to define ML-DSA algorithm identifiers and conventions for X.509 certificates and Certificate Revocation Lists) explicitly notes that standardized ML-DSA and pre-standardization Dilithium are not compatible. Organizations that experimented with early Dilithium prototypes must regenerate keys and certificates using finalized FIPS 204 implementations.

Section Summary: RSA remains safe against classical hardware today, but long-lived certificates and code-signing pipelines need protection against future quantum forgery. ML-DSA provides lattice-based signature security under FIPS 204, though administrators must ensure they use finalized ML-DSA rather than incompatible pre-standard Dilithium builds.

Byte for Byte: Comparing RSA and ML-DSA Specifications​

Why are ML-DSA signatures so much larger? An RSA signature compresses its mathematical proof into a single modular exponentiation result whose byte length matches the modulus size. ML-DSA, by contrast, must encode multiple polynomial vectors to prove authenticity without leaking the private key.

In FIPS 204 Table 2, NIST defines three fixed parameter sets for ML-DSA—44, 65, and 87—which correspond to internal matrix dimensions and map to NIST security categories 2, 3, and 5. Unlike RSA keys, whose file sizes fluctuate depending on whether they are stored as raw values, PKCS#1, PKCS#8 DER, or Base64-wrapped PEM files, raw ML-DSA public keys, expanded private keys, and signatures have exact byte lengths defined by the standard.

Seed vs. Expanded Private Keys​

One detail from FIPS 204 and RFC 9881 that every PKI administrator should know involves private key storage. While an expanded ML-DSA private key ranges from 2,560 to 4,896 bytes, FIPS 204 also specifies a compact 32-byte seed format ($\xi$) across all three security levels. Both the expanded private key and the public key can be deterministically derived from this 32-byte seed.

Because expanding a key from its seed is a one-way operation, RFC 9881 recommends retaining and exporting the seed format (or a combined seed-plus-expanded format). As we will see below, some production platforms—including Cloudflare's origin certificate upload endpoints—strictly require the seed-only format and reject expanded private keys.

Section Summary: Switching from RSA-2048 to ML-DSA increases raw signature payloads from 256 bytes to between 2,420 and 4,627 bytes. While public keys and signatures grow substantially across the wire, private keys can be stored compactly using FIPS 204's 32-byte seed format.

Network Overhead and Performance Trade-Offs​

What happens when a 256-byte signature expands to 3.3 KB or 4.6 KB? The impact appears almost entirely on the network wire and in certificate-parsing appliances rather than on local disk storage.

Consider the raw payload arithmetic relative to a 256-byte RSA-2048 baseline:

• ML-DSA-44 adds 2,164 bytes per signature.
• ML-DSA-65 adds 3,053 bytes per signature.
• ML-DSA-87 adds 4,371 bytes per signature.

If a system transmits one additional ML-DSA-65 signature across one million operations, that equates to roughly 3.05 GB of extra signature payload bytes (or 4.37 GB for ML-DSA-87), before accounting for X.509 certificate wrappers, multiple certificates in a chain, or TLS protocol framing. In a full PKI hierarchy where the root, intermediate, and leaf certificates—plus the TLS 1.3 CertificateVerify handshake message and Online Certificate Status Protocol (OCSP) responses—all carry ML-DSA signatures and public keys, a single handshake can easily grow by 10 KB or more.

While modern broadband and data center links can absorb several gigabytes of daily overhead without blinking, the real operational friction shows up in three places:

• Packet Fragmentation and Middleboxes: Larger certificates and key shares push TLS handshakes across multiple TCP packets, which can trigger bugs or timeouts in older firewalls, load balancers, and deep-packet inspection appliances.
• ASN.1 Parser Limits: Legacy applications or embedded systems with hard-coded buffer limits for X.509 fields may choke or truncate oversized keys and signatures.
• Constrained Links: Satellite, narrowband IoT, and tactical connections face genuine latency penalties when exchanging multi-kilobyte authentication payloads.

On the compute side, Shattered's analysis of liboqs and industry benchmarks highlights an interesting shift in CPU dynamics. Classical RSA is famously lopsided: RSA signature verification is extremely fast, while RSA signing is computationally heavy and slows down sharply as modulus sizes climb toward 3,072 or 4,096 bits. ML-DSA exhibits a much more balanced performance profile, where signing and verification speeds sit closer together, and signing throughput often matches or beats larger RSA key sizes depending on hardware vectorization (such as AVX2 or AVX-512). Because benchmark numbers vary wildly across CPU architectures and compilers, teams should test throughput on their own production hardware.

Section Summary: Larger ML-DSA signatures add several kilobytes to certificate chains and authentication handshakes. While raw bandwidth is rarely a blocker for modern servers, middlebox packet splitting and legacy ASN.1 buffer limits require careful testing.

Windows Server 2025 AD CS: Microsoft's Enterprise PQC Path​

For Windows Forum readers managing enterprise networks, the most actionable development in the ML-DSA ecosystem is Microsoft's native integration into Active Directory Certificate Services (AD CS).

According to Microsoft Learn documentation updated in May 2026, Windows Server 2025 AD CS supports all three FIPS 204 parameter sets (ML-DSA-44, ML-DSA-65, and ML-DSA-87) in pure mode across the entire internal certificate lifecycle:

• CA Hierarchy: Root, Subordinate, Enterprise, and Standalone CAs.
• Code Signing: Issuing internal ML-DSA code-signing certificates.
• TLS and Authentication: Web Server, User, and Computer certificate templates.
• OCSP Response Signing: Configuring Online Responders with ML-DSA signing certificates.

Mandatory Windows Patch and Platform Requirements​

Before spinning up a test lab, Windows administrators must verify exact operating system and cumulative update levels across both servers and endpoints:

Critical AD CS Deployment Constraints​

Microsoft's documentation establishes strict rules for deploying ML-DSA in a Windows environment:

1. No In-Place CA Migration: You cannot upgrade an existing RSA or ECDSA Certification Authority to ML-DSA in place. Administrators must install new ML-DSA CAs and build a parallel PKI hierarchy alongside their classical infrastructure to test issuance without disrupting production.
2. CNG Key Storage Provider Only: Certificate templates must be configured to use a Cryptography Next Generation (CNG) Key Storage Provider. Legacy Cryptographic Service Providers (CSPs) are not supported. To make CNG providers selectable in the template console, set both the Certification Authority and Certificate Recipient compatibility settings to Windows Server 2008 or later.
3. Signature-Only Key Usage: Because ML-DSA is strictly a digital signature algorithm and cannot encrypt data or establish shared keys, template Request handling - Purpose must be set to Signature. Furthermore, Key Usage must not include Key Encipherment or Key Agreement (a requirement enforced by RFC 9881 as well), and Application Policies (EKU) must not include Encrypting File System (EFS) or Secure E-mail.
4. Enrollment Tooling: Certificate enrollment is currently supported via the Certificates Microsoft Management Console (MMC) snap-in and the certreq.exe command-line utility. Enrollment via the Network Device Enrollment Service (NDES) is not currently supported.

Section Summary: Windows Server 2025 supports full ML-DSA PKI hierarchies once patched with KB5087539, paired with Windows 11 24H2/25H2 clients running KB5067036 or later. Because in-place CA upgrades are impossible and NDES is unsupported, enterprises must build parallel CNG-backed CA hierarchies for testing.

Real-World Tooling: OpenSSL 3.5+ and Cloudflare Origin TLS​

Outside of Windows Server AD CS, two major infrastructure milestones have made hands-on ML-DSA testing straightforward for DevOps and security engineers.

OpenSSL 3.5+ CLI Workflows​

Since the release of OpenSSL 3.5.0 in April 2025, native ML-DSA, ML-KEM, and SLH-DSA implementations have been included directly in the OpenSSL default and fips providers. Engineers no longer need to compile third-party liboqs or oqs-provider plugins just to generate keys or sign artifacts.

According to OpenSSL's official documentation and Cloudflare's deployment guides, you can test the exact signature size difference on any workstation running OpenSSL 3.5.0 or later:

# Generate a classical RSA-3072 private key
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa3072.key

# Generate an ML-DSA-65 private key (using seed-only format for portability)
openssl genpkey -algorithm ML-DSA-65 -provparam ml-dsa.output_formats=seed-only -out mldsa65.key

# Sign a sample payload with both keys
openssl pkeyutl -sign -inkey rsa3072.key -in message.txt -out rsa.sig
openssl pkeyutl -sign -inkey mldsa65.key -in message.txt -out mldsa.sig

# Inspect the resulting signature byte counts (384 bytes vs 3,309 bytes)
ls -l rsa.sig mldsa.sig

Notice the -provparam ml-dsa.output_formats=seed-only flag. While optional for local testing, including it ensures OpenSSL writes the 32-byte FIPS 204 seed rather than the expanded private key.

Cloudflare Edge-to-Origin Authentication​

While public browsers and commercial Certificate Authorities do not yet universally trust pure ML-DSA certificates for public-facing websites, operators can deploy ML-DSA today on private and origin paths where they control both endpoints.

Cloudflare's SSL/TLS documentation confirms that, since mid-2026, its edge network supports ML-DSA signatures across two origin-facing features over TLS 1.3:

• Authenticated Origin Pulls (AOP): Cloudflare presents an ML-DSA client certificate during the mTLS handshake so your origin server can verify traffic comes genuinely from Cloudflare.
• Custom Origin Trust Store (COTS): Cloudflare trusts your private ML-DSA CA when validating your origin server's certificate under Full (strict) encryption mode.

Cloudflare emphasizes two critical operational rules for this setup:

1. Seed-Only Key Uploads: When uploading an ML-DSA private key to Cloudflare, it must be generated with -provparam ml-dsa.output_formats=seed-only. Expanded private keys are rejected.
2. Preventing Classical Downgrades: Presenting a post-quantum certificate provides no real quantum resistance if the verifier still accepts classical certificates. To prevent on-path downgrade attacks, administrators using COTS must upload only ML-DSA CAs to the custom trust store, and origin servers using AOP must be configured to strictly reject classical client certificates.

Section Summary: OpenSSL 3.5+ provides built-in EVP commands for ML-DSA key generation and signing, while Cloudflare allows operators to lock down edge-to-origin TLS 1.3 connections using seed-encoded ML-DSA certificates.

CNSA 2.0 Milestones and Migration Strategy​

How urgently does your organization need to act? That depends heavily on your regulatory environment and the lifespan of what you sign.

For U.S. National Security Systems (NSS) and the defense industrial base, the National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) designates ML-DSA-87 for digital signatures and ML-KEM-1024 for key establishment. According to the NSA's draft Commercial Solutions for Classified (CSfC) Post-Quantum Cryptography Guidance Addendum, the target milestones for applicable national security systems include:

• January 1, 2027: CNSA 2.0 algorithms required in new NSS acquisitions, products, and services.
• December 31, 2030: Replacement of legacy equipment that does not support CNSA 2.0.
• December 31, 2031 (and through 2033 under broader CNSA 2.0 transition guidance): Full enforcement of CNSA 2.0 across applicable systems, subject to formal program waivers.

While these NSA milestones govern National Security Systems rather than ordinary commercial businesses by statute, hardware vendors, cloud providers, and enterprise software makers—including Microsoft—build their commercial roadmaps around CNSA 2.0 requirements so their products remain eligible for federal procurement.

Where to Deploy RSA vs. ML-DSA Today​

Rather than treating the RSA-to-ML-DSA transition as an overnight switch, Windows and enterprise IT teams should segment their infrastructure by use case:

1. Public-Facing Websites and Consumer TLS: Keep using RSA-2048/3072 or ECDSA certificates for public web servers, paired with hybrid ML-KEM (such as X25519MLKEM768) for post-quantum key exchange. Until public root programs and browsers establish universal trust for post-quantum leaf certificates, pure ML-DSA on public web ports will break client connections.
2. Internal Enterprise PKI and Origin Links: Start piloting ML-DSA-65 (or ML-DSA-44 where bandwidth is tight) in parallel lab hierarchies using Windows Server 2025 AD CS (with KB5087539) or Cloudflare edge-to-origin mTLS. Because you control both the CA and the relying clients, you bypass public browser trust bottlenecks.
3. Code Signing, Firmware, and Long-Term Archives: Implement dual-signing or hybrid workflows now, pairing classical signatures with ML-DSA-65 or ML-DSA-87. An OS image, driver package, industrial firmware binary, or 30-year legal contract signed in 2026 may still need to be verified in the 2030s.
4. National Security and Defense Contractors: Standardize immediately on ML-DSA-87 and verify FIPS 140-3 validation timelines with your Hardware Security Module (HSM) vendors ahead of the January 2027 acquisition milestone.

The 256-byte RSA signature has served the industry remarkably well, and its tiny footprint ensures it will remain part of legacy and public-facing TLS handshakes for years to come. Yet with FIPS 204 finalized, RFC 9881 published, and native support live in Windows Server 2025 and OpenSSL 3.5+, the foundation for post-quantum authentication is ready. The smartest move for Windows administrators this quarter is to patch a Windows Server 2025 lab with KB5087539, spin up a parallel ML-DSA Certification Authority, and see firsthand how their network appliances and applications handle a 3,309-byte signature.