Your certificate authority can sign with a post-quantum algorithm now, on Windows Server 2025 with the right update. That is genuinely new and it is worth understanding precisely, because almost everything said about it in the last year has been aimed at a threat it does not address.
This article sits outside the build sequence. Nothing in the hierarchy we built depends on it and nothing in it is urgent. It exists because the question arrives in every PKI conversation now, usually in the form of whether the design we just committed to is about to be obsolete, and the answer deserves better than the two extremes on offer. It is neither a crisis nor a marketing exercise. It is a capability with a specific shape, a real cost measured in bytes, and one structural constraint that determines the entire adoption plan.
The argument everybody makes, and why it is the wrong one
The standard case for post-quantum cryptography is harvest now, decrypt later. An adversary captures encrypted traffic today, stores it, and reads it in fifteen years when the machine exists. It is a good argument and it has nothing to do with this feature.
ML-DSA is a signature algorithm. It cannot encrypt and it cannot perform key exchange. Captured traffic is a key establishment problem and belongs to a different algorithm entirely. Nothing your certificate authority signs protects data at rest or in flight from a future decryption, and a hierarchy that signs with ML-DSA is not one byte more resistant to harvesting than the one you have.
Signatures fail differently. A forged signature is useful at the moment it is presented and generally worthless afterwards, so an adversary who acquires the capability in 2038 gains very little from a handshake you performed last Tuesday. That asymmetry is why signature migration has felt less urgent than key exchange migration to most people paying attention, and they have been broadly right.
There is one class of exception, and it is the one that makes this article relevant to a series about building a private certificate authority. Long-lived signing identities do not enjoy that asymmetry. A root certificate with a twenty-five year life has to remain unforgeable in 2051. Code signing certificates carry the same problem, because the signature has to be trusted for as long as the signed artefact is trusted, which for firmware and installers can be a very long time. And an attacker forging a root does not need anything you have kept secret. They need your public key, which you have distributed with some care to every device in the estate.
The risk is not your traffic. It is the small number of keys you have committed to trusting for longer than anyone can forecast.
That is the honest frame. This is not about the certificates your estate issues by the thousand and replaces every year. Those will be re-signed several times over before any of this matters. It is about the two or three keys at the top that you deliberately chose not to change, and it is a direct consequence of the permanent decisions this series opened with.
What the algorithm is, briefly
ML-DSA is the Module-Lattice-Based Digital Signature Algorithm, standardised by the United States National Institute of Standards and Technology as FIPS 204. It is the production form of the CRYSTALS-Dilithium submission that won the relevant category of the NIST selection process. Its security rests on lattice problems rather than on factoring or discrete logarithms, which is the entire point: the quantum algorithm that dismantles RSA and elliptic curve cryptography does not apply to lattices, and no comparable algorithm is known.
It comes in three parameter sets, and AD CS supports all three. ML-DSA-44 targets NIST security level 2, ML-DSA-65 level 3, and ML-DSA-87 level 5. Higher sets buy a larger security margin and cost proportionally larger keys and signatures. If you have no specific requirement, 65 is the sensible middle and is what most guidance settles on.
One detail surprises people configuring it for the first time. The hash algorithm field reads NoHash, and that is correct rather than a defect. ML-DSA processes the message itself rather than signing a separately computed digest the way RSA and ECDSA do, so there is no hash algorithm to choose. Similarly the key length field reports numbers between 10,496 and 20,736 bits depending on the parameter set, which is not a security claim comparable to an RSA modulus. It is simply the size of a lattice public key expressed in bits.
The cost is size, and the size is not subtle
Everything difficult about deploying this is a consequence of one table.
| Algorithm | Public key | Signature |
|---|---|---|
| ECDSA P-256 | 64 bytes | around 64 bytes |
| RSA 2048 | 256 bytes | 256 bytes |
| RSA 4096 | 512 bytes | 512 bytes |
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | 2,592 bytes | 4,627 bytes |
A signature that was 256 bytes becomes 3,309. A certificate carries a public key and a signature, and a chain carries one of each per link, so a three-certificate chain that cost around two kilobytes costs closer to fifteen. That multiplier lands differently depending on where it lands.
Some places absorb it without complaint. A revocation list is signed once and fetched rarely, so an extra four kilobytes on a file that is already measured in kilobytes changes nothing you can perceive. Web traffic over a modern TCP connection carries the additional handshake bytes without drama, and the extra latency on a first connection is measurable but not interesting.
Network authentication is where I would expect trouble first, and this is engineering judgement rather than a documented failure. RADIUS has a long and unhappy relationship with fragmentation. An EAP-TLS exchange already carries a server certificate, a client certificate and their chains through a transport that was not designed with generous headroom, across access points and supplicants whose fragmentation paths have not been seriously exercised in a decade. Multiply every certificate in that exchange by five and you are testing code that has been quietly working by accident. If you pilot post-quantum signing somewhere, do not make wireless authentication the first place.
The second place worth measuring before committing is anything embedded. Appliances, building systems, industrial controllers and older network hardware frequently carry certificate buffers with fixed sizes chosen when a large certificate meant two kilobytes. Those devices do not fail gracefully and they do not tell you why.
What AD CS gives you, and what it withholds
The capability is broader than the initial announcements suggested. Certificate authorities can sign with ML-DSA across root, subordinate, enterprise and standalone roles, so a full two-tier hierarchy of the shape this series built is supported rather than a laboratory subset. Templates can issue post-quantum certificates for code signing, for server and client authentication, and online responders can sign their revocation responses with it. Each authority in a hierarchy chooses its own parameter set independently, so a root at the highest level signing a subordinate at the middle one is a legitimate and reasonable arrangement.
The platform floor is high and non-negotiable. Authorities need Windows Server 2025 with the May 2026 security update. Clients need Windows 11 on a recent build with the October 2025 update. Anything older in your estate simply cannot validate these certificates, which for most organisations means the population that can participate is smaller than the population that cannot.
Two omissions matter more than the feature list. Enrolment works through the certificates console and the command line only, and the network device enrolment service cannot issue these certificates. Microsoft lists that service among the ones it intends to extend in a later phase, so this is sequencing rather than a closed door. I would still not build a plan around its arrival: for a component that has received no meaningful investment in years and whose remaining users are being steadily absorbed by cloud issuance, an intention with no date attached is thin ground to design on.
And an existing certificate authority cannot be migrated. There is no conversion, no renewal into a new algorithm, no upgrade path. A post-quantum authority is a newly installed authority, which means the adoption plan is not a change to the hierarchy you have. It is a second hierarchy standing beside it.
Pure, and how much work that word is doing
A post-quantum certificate can take one of two forms. A pure certificate carries a single post-quantum algorithm, and every relying party in the chain has to understand that algorithm or validation fails outright. A composite certificate carries a classical signature and a post-quantum signature together, both of which must validate, so the certificate remains secure as long as either algorithm remains unbroken and it degrades gracefully across a mixed estate.
Composite is obviously the better transitional shape, and a great deal of industry effort is going into it. It is also not finished. The specification for using composite ML-DSA in TLS is an active draft rather than a published standard, and AD CS supports the three parameter sets in pure mode today.
That single word governs the deployment plan more than anything else in this article. Pure means there is no gradual rollout inside one hierarchy, no period where old clients fall back and new clients get the stronger algorithm, no hedge. A device either understands ML-DSA or it cannot validate the certificate at all. Combined with the platform floor, the practical consequence is that a post-quantum hierarchy today serves a deliberately selected population and nothing else.
Which makes this a trust distribution problem
Everything above collapses into one observation, and it is the same observation [P 6] Operating a PKI made about rebuilding an authority for any other reason.
The cryptography is the easy part. Standing up a parallel hierarchy is a day of work and this series has already described every step of it, with different algorithm names. The hard part is that a new root is a new anchor, and a new anchor has to reach every domain member, every appliance, every Linux host, every mobile device, every container image built from a base that has never heard of you, and every monitoring system that checks your internal endpoints. That is the standing obligation with no completion date, and adopting post-quantum signing means paying it a second time, in full, while the first hierarchy stays alive.
It also means running both for a long time. The old hierarchy keeps issuing to everything that cannot validate the new algorithm, keeps publishing its revocation lists, and keeps its annual root appointment, until the last certificate it signed has expired. Plan the overlap, not the cutover. That sentence has now appeared twice in this series for two unrelated reasons, which is usually a sign it is the actual lesson.
What I would do this year
Not migrate. Nothing in the current position justifies moving a production hierarchy, and the constraints make it impractical for most estates regardless of appetite.
What I would do is build one in a lab, issue to a controlled set of clients on the required build, and put the resulting certificates through the parts of the estate most likely to object. Measure the chain sizes. Push them through your RADIUS path and watch for fragmentation. Present one to an appliance and see what happens. The output that matters is not a working post-quantum certificate, which is a foregone conclusion. It is a set of numbers and a list of things that broke, both of which you will otherwise be inventing under pressure at some later date.
The other deliverable is more valuable and costs nothing but attention. Write down how long a full trust distribution took the first time, or how long you think it would take now. That figure is the real constraint on any future migration, and it is the difference between an organisation with several years of slack and one that has already run out without noticing.
There is a decision worth revisiting too, and it is uncomfortable because it is one of the permanent ones. A twenty-five year root is a defensible choice and this series argued for it on operational grounds: an annual manual obligation is easier to sustain than a hierarchy rebuild, and pushing the rebuild past most people’s tenure is a feature. A shorter root, renewed and redistributed more often, is a hedge against exactly the situation this article describes. I still take the long root, because I trust an organisation to keep a calendar entry more than I trust it to execute a trust migration on schedule. But it is a judgement rather than an obvious answer, and anyone building a hierarchy this year should make it deliberately rather than inheriting it.
The last thing to say is the least fashionable. Post-quantum signing in a private certificate authority is a capability worth understanding and a poor use of this year’s budget for almost everyone. The hierarchy described in this series, with its distribution points reachable from anywhere, its revocation published redundantly, its templates scoped deliberately and its calendar written down, is protecting you from failures that happen every year. This one is not scheduled and may not arrive in the working life of the authority you just built. Get the first list right. Then keep an eye on this one.
On-Prem PKI
‹ Previous: [P 7.1] Build Sheet: Signing the Cloud PKI CSR
Next: [P 9] A Second Issuing CA: When It Is Availability, When It Is a Boundary, and When It Is Neither ›
