Skip to main content
    My-SSL LogoMy-SSL
    Security

    Post-Quantum Code Signing: What You Can Actually Buy in 2026

    No public CA sells a post-quantum code signing certificate yet. What ML-DSA, LMS and CNSA 2.0 require, and what to do before Windows shifts in 2027.

    MS
    My-SSL Team
    ·
    15 min read
    ·
    Published September 9, 2026
    ·
    Last updated September 9, 2026

    The short answer

    As of September 2026 you cannot buy a post-quantum code signing certificate from any publicly trusted certificate authority. The algorithms exist — NIST published ML-DSA as FIPS 204 in August 2024 — and the hardware exists, but the CA/Browser Forum's Code Signing Baseline Requirements have not been amended to permit them, so no CA can issue one and stay inside the rules its root programs audit against. The same forum already opened that door for S/MIME with ballot SMC013 in August 2025. Where post-quantum signing does work today is inside your own infrastructure: LMS and XMSS from NIST SP 800-208 for firmware, ML-DSA from a private CA, both supported in current HSM firmware, and both on the CNSA 2.0 clock that ends in 2030.

    That answer has a practical consequence worth stating before the detail: there is nothing to wait for. Deferring a code signing purchase until a quantum-safe version appears means going unsigned through 2027, and the OV and EV code signing certificates available today are the only ones any operating system will accept from a third-party publisher for the foreseeable future. What you can act on now is everything around the certificate — where the key lives, whether you timestamp, and whether your own verification code survives an algorithm change.

    Diagram comparing three certificate rulebooks — publicly trusted code signing, publicly trusted S/MIME, and private or firmware signing — showing which ones currently permit post-quantum signature algorithmsThree columns share one heading, which states that the algorithms are standardised and the hardware ships, so the rulebook is what decides. The first column is publicly trusted code signing, marked as the reader's lane. Its rulebook is the CA/Browser Forum Code Signing Baseline Requirements. No post-quantum ballot has been adopted into it, and the working group's ML-DSA ballot was still awaiting an endorser in 2026, so no public certificate authority can issue an ML-DSA code signing certificate. The second column is publicly trusted S slash MIME. Its rulebook is the S slash MIME Baseline Requirements, and ballot SMC013 was adopted on the twenty second of August 2025, adding ML-DSA and ML-KEM so that certificate issuers may experiment with post-quantum email certificates. The third column, highlighted, is a private certificate authority or firmware signing, where no CA/Browser Forum rulebook applies at all; NIST FIPS 204 and SP 800-208 already approve ML-DSA, LMS and XMSS, hardware security modules from the major vendors ship them, and the CNSA 2.0 clock runs to 2030. A bar across the bottom states the conclusion: the block is not the mathematics and not the hardware, it is which rulebook a certificate has to satisfy.The algorithm is standardised. The hardware ships. The rulebook decides.YOUR LANEPublic code signingRulebook: CA/B ForumCode Signing BRsNo PQC ballot adopted.The ML-DSA ballot wasstill one endorser shortwhen last minuted, 2026.What you can buy:RSA-3072 or ECDSANothing post-quantum,from any public CA.Public S/MIMERulebook: CA/B ForumS/MIME BRsBallot SMC013 adopted22 August 2025, addingML-DSA and ML-KEM forissuer experimentation.What you can buy:The door is openSame forum, same year,a different committee.Private CA / firmwareRulebook: none of theabove appliesFIPS 204 and SP 800-208approve ML-DSA, LMSand XMSS. Major HSMsship them in firmware.What you can do:Start todayCNSA 2.0 asks forexclusive use by 2030.Nothing here is blocked by the mathematics, and nothing is blocked by the hardware.What differs between the three columns is which rulebook a certificate has to satisfy.
    Two of these lanes have somewhere to go this year. If you sell software signed with a publicly trusted certificate, you are standing in the one that does not.

    Can you buy a post-quantum code signing certificate today?

    No. As of September 2026 no publicly trusted CA issues a code signing certificate keyed to ML-DSA, SLH-DSA or any other post-quantum algorithm, and none can. A public CA issues under the CA/Browser Forum's Code Signing Baseline Requirements, which enumerate the permitted signature algorithms and key sizes. Nothing post-quantum is on that list. Issuing outside it is a misissuance, with the audit and root-program consequences that implies.

    This trips people up because the surrounding evidence points the other way. FIPS 204 and FIPS 205 have been final standards since August 2024. Thales, Entrust and Utimaco all ship ML-DSA in current HSM firmware. Microsoft has been publishing post-quantum roadmaps for Windows. From the outside it looks like the parts are on the shelf and somebody just needs to assemble them, and in a private PKI that is roughly true. Public trust is the part that has not moved, and public trust is the entire reason you buy a code signing certificate rather than generating one.

    Worth separating from this: the hardware key requirement that has applied to every publicly trusted code signing certificate since June 1, 2023 is not a post-quantum measure. It exists because exportable signing keys kept ending up in malware. It does, though, mean the migration has one problem already solved — your key is in a token or HSM, and the hardware you chose for it is where any future algorithm will have to run.

    Why is code signing behind S/MIME on this?

    Because they are governed by different working groups moving at different speeds, and S/MIME's got there first. The CA/Browser Forum adopted ballot SMC013 on August 22, 2025, adding ML-DSA and ML-KEM to the S/MIME Baseline Requirements so that issuers could begin experimenting with post-quantum email certificates. The Code Signing Certificate Working Group has discussed the equivalent change and reached consensus to support all three ML-DSA parameter sets, but when it last minuted the ballot in 2026 the text was still short of the endorsements needed to go to vote.

    There is a second gate behind the ballot, and it is the slower one. Even a ratified requirement only permits a CA to issue; it does not make anything trust the result. A post-quantum code signing certificate has to chain to a root that Windows, macOS and Java already carry, which means a root program has to accept a new PQC root and ship it in an operating system update. The Microsoft position discussed in the working group during 2026 was that there were no current plans to accept PQC roots for code signing. Root distribution is measured in years even when everyone agrees, because a root is only useful once it is on the machines that will verify against it.

    The comparison with TLS is instructive here. A browser talking to a server can negotiate: both ends are online, both can be upgraded, and a failed negotiation falls back. Code signing has no negotiation. You sign once, and the signature has to satisfy a verifier you will never meet, running a Windows build that may be a decade old by then. That asymmetry is why post-quantum TLS could deploy through hybrid key exchange years before any of this, and why code signing will be one of the last things to move.

    Which algorithms are actually on the table?

    Three, with different jobs. ML-DSA (FIPS 204) is the general-purpose replacement for RSA and ECDSA and the one proposed for code signing certificates. SLH-DSA (FIPS 205) is a stateless hash-based scheme held in reserve as the conservative fallback, since its security rests only on the hash function. LMS and XMSS (NIST SP 800-208) are stateful hash-based schemes approved specifically for software and firmware signing, and they are what the NSA points firmware at.

    Comparison panel of five signature algorithms for code signing, showing signature size, whether the scheme is stateful, and whether a publicly trusted certificate can be bought for it todayFive rows compare signature algorithms across three columns: signature size, whether the key is stateful, and whether a public certificate authority can issue for it as of September 2026. ECDSA P-256 produces a signature of about sixty four bytes, is stateless, and is available from public certificate authorities today. RSA-3072 produces a 384-byte signature, is stateless, and is likewise available today; it is the current baseline minimum. ML-DSA-44 produces a 2,420-byte signature and is stateless, but no public certificate authority may issue it. ML-DSA-65, the middle parameter set most often proposed for certificates, produces a 3,309-byte signature and is also unavailable publicly. LMS and XMSS, from NIST SP 800-208, produce signatures of roughly one to three kilobytes depending on parameters, are stateful so each key can sign only a fixed number of times, and are used for firmware signing in private infrastructure rather than sold as public certificates. A highlighted note explains that the jump from 384 bytes to several kilobytes is the practical cost of migration.What each algorithm costs you, and whether you can buy itAlgorithmSignature sizeStateful?Public CA, Sept 2026ECDSA P-256~64 bytesNoYes — available nowRSA-3072384 bytesNoYes — baseline minimumML-DSA-44 (FIPS 204)2,420 bytesNoNo — not permitted yetML-DSA-65 (FIPS 204)3,309 bytesNoNo — not permitted yetLMS / XMSS (SP 800-208)~1–3 KBYesPrivate / firmware onlyThe migration cost is not compute. It is the jump from a 384-byte signature to several kilobytes,multiplied by every certificate in the chain and every signature you store or ship.
    The stateful row is the one that changes how you operate rather than what you buy: an LMS key can only sign a fixed number of times, so a restored backup that replays state is a key compromise.

    The number that matters operationally is the signature size. An RSA-3072 signature is 384 bytes. ML-DSA-44 is 2,420 bytes, ML-DSA-65 is 3,309, ML-DSA-87 is 4,627. Multiply that by every certificate in the chain, every signature stored in a catalog file, every verification record in an update system, and the migration cost shows up as bandwidth and storage rather than CPU. Signing itself is fast.

    Statefulness is the other operational surprise. An LMS or XMSS key can produce only a fixed number of signatures, decided at key generation, and the state that tracks which one-time keys are spent must never be reused. Restore an HSM from a backup taken an hour ago and you have just rolled the state back, which can leak the private key rather than merely wasting signatures. SP 800-208 handles this by requiring signature generation to happen inside hardware that manages the state itself, which is also why an HSM that merely stores an LMS key is not enough — it has to generate and count.

    Who has a real deadline right now?

    Firmware and embedded vendors selling into US National Security Systems, and nobody else yet. CNSA 2.0 puts software and firmware signing on the earliest clock of any category the NSA schedules: begin transitioning immediately, support and prefer the suite by 2025, use it exclusively by 2030. The reasoning is specific to firmware rather than general — a root of trust burned into a device is the hardest thing in any estate to replace after it ships, so it has to be the first thing to change.

    For that category the tooling is genuinely ready. LMS with SHA-256/192 is the NSA's preferred parameter set, HSMs from the major vendors support LMS and ML-DSA key generation with state management, and because the verifier is your own bootloader rather than an operating system trust store, no CA/Browser Forum ballot is involved. You control both ends. That is exactly why this half of the problem can be solved today and the publicly trusted half cannot.

    If you sell commercial software into ordinary channels, CNSA 2.0 is not binding on you. It is still the most useful schedule available, because it tells you what the people with the longest device lifetimes concluded about timing. Treat 2030 as the date by which signing infrastructure should be able to switch algorithms without a rebuild, not as a date on which anything you sell stops working.

    What is Microsoft actually changing in Windows code signing?

    Microsoft is changing how it signs Windows itself, not what it accepts from you. Its August 2026 guidance sets out three things: the Windows Production PCA 2011 expires on October 19, 2026 and is being replaced; Windows production signing moves to stronger configurations later in 2026, including RSA-3072 and SHA-384; and post-quantum signing is expected to arrive in Windows during 2027. None of those is a deadline for a certificate you buy.

    Timeline of post-quantum code signing milestones from August 2024 to 2030, separating standards work, certificate authority rules, and Microsoft Windows changesA horizontal timeline runs from August 2024 to 2030 with seven marked events on three rows. On the standards row: NIST published FIPS 204 and FIPS 205 in August 2024, and the NSA's CNSA 2.0 asks for exclusive post-quantum software and firmware signing by 2030. On the certificate authority row: the CA/Browser Forum adopted ballot SMC013 for S slash MIME on the twenty second of August 2025, and ballot CSC-31 capped newly issued code signing certificates at 460 days from the first of March 2026, while the code signing post-quantum ballot remains unadopted as of September 2026. On the Microsoft row: the Windows Production PCA 2011 expires on the nineteenth of October 2026, Windows production signing moves to RSA-3072 and SHA-384 later in 2026, and Microsoft expects post-quantum signing in Windows during 2027. A note beneath states that the two nearest dates on the chart are both about Microsoft signing Windows, not about certificates sold to software vendors.The dated runway, and who each date belongs toSTANDARDSCA RULESMICROSOFTAug 20242025202620272030Aug 2024FIPS 204 + FIPS 2052030CNSA 2.0 exclusive22 Aug 2025SMC013: PQC S/MIME1 Mar 2026CSC-31: 460-day cap19 Oct 2026Windows PCA 2011 ends2027PQ signing in WindowsThe two nearest dates are both about how Microsoft signs Windows — not about the certificate you buy to sign your own software.
    Read the rows separately. Mixing the Microsoft row into the CA row is how teams end up believing there is a purchasing deadline in October.

    The instruction aimed at software vendors is narrower and easier to miss. Microsoft asks that applications not depend on a specific certificate name, thumbprint, issuer, key size or digest algorithm when they validate signatures, and that they delegate those checks to the platform APIs instead. The warning behind it is concrete: an application can break when Microsoft's signing certificates or algorithms change even though Windows itself considers the file perfectly valid and trusted.

    That is the part worth auditing this quarter, and it is not usually in the signing pipeline. It is in installers that pin a Microsoft thumbprint before applying an update, licence checks that assert an issuer name, and self-update routines that hard-code SHA-256 as the only acceptable digest. Code like that has been quietly correct for a decade and stops being correct in October. Anyone who lived through a root certificate expiring has seen this failure shape before.

    Does a timestamp survive a quantum computer?

    Not on its own, because a timestamp is a signature too. An RFC 3161 timestamp is produced by a timestamp authority signing your signature's hash with the authority's own RSA or ECDSA key. Whatever breaks your key breaks that one, which means the mechanism that keeps a signature valid after its certificate expires inherits the same weakness — and it belongs to somebody else's infrastructure, so you cannot migrate it yourself.

    Schematic of the three cryptographic parts of a signed executable — the file digest, the publisher signature, and the RFC 3161 timestamp — showing which parts a quantum computer threatensA signed executable is broken into three cryptographic parts, drawn left to right. The first is the file digest, computed with SHA-256 or SHA-384; Grover's algorithm gives only a quadratic speedup, so SHA-256 retains roughly 128 bits of effective preimage resistance and SHA-384 roughly 192, and the digest survives. The second is the publisher signature, made with the RSA or ECDSA private key held in a token or hardware security module; Shor's algorithm breaks this outright, and it is the part that a post-quantum code signing certificate would replace. The third, highlighted, is the RFC 3161 timestamp, which is itself a signature made by the timestamp authority using the timestamp authority's own RSA or ECDSA key; it is therefore vulnerable to exactly the same attack, which means the mechanism that keeps an old signature valid after the certificate expires inherits the weakness of whichever algorithm the timestamp authority used. A bar across the bottom states that replacing your own signing algorithm fixes one of the three boxes, and that a signature intended to verify in 2035 depends on the timestamp authority migrating too.Three cryptographic parts of one signed file1. File digestSHA-256 or SHA-384Grover gives a quadraticspeedup, not anexponential break.SHA-256 → ~128-bitSHA-384 → ~192-bitSURVIVES2. Publisher signatureYour RSA or ECDSA keyHeld in a token or HSMsince June 2023. Shorrecovers the private keyfrom the public one.This is the box ML-DSAwould replace.BREAKS3. RFC 3161 timestampThe TSA's own keyA timestamp is itself asignature, made with thetimestamp authority'sRSA or ECDSA key.Not yours to migrate.BREAKS TOOSwapping your own signing algorithm fixes one box out of three.A signature you expect a machine to still accept in 2035 also depends on the timestamp authority migrating.
    The third box is the one nobody puts on a migration plan, because it belongs to somebody else's infrastructure.

    None of this changes the advice to timestamp everything. A timestamped signature outlives its certificate, which is the difference between software that keeps working after renewal and software that starts warning users on a fixed date. The point is narrower: a timestamp is a claim about when, backed by cryptography with the same shelf life as everything else, so it is not a way of making a signature permanent. Long-lived archives handle this by re-timestamping periodically with current algorithms, which is a pattern worth knowing about if you are signing something expected to verify in 2040.

    The file digest is the one part that comes through intact. Grover's algorithm offers a quadratic speedup against a hash rather than the exponential break Shor's algorithm offers against RSA and ECC, so SHA-256 retains roughly 128 bits of effective preimage resistance and SHA-384 roughly 192. Both stay workable, which is why nobody proposes replacing your digest and why Microsoft's move to SHA-384 reads as ordinary strengthening rather than a response to quantum risk.

    What should you do with the certificate you have now?

    Buy and renew normally, and spend the effort on crypto-agility instead. A certificate issued today already expires within 460 days under ballot CSC-31, so the cryptography in your current certificate is not a long-term commitment — you will replace it two or three times before any of the post-quantum rules land. What lasts is the pipeline around it, and that is what to build so it can change algorithm without a rewrite.

    Do this nowWhy it pays off later
    Strip hard-coded thumbprints, issuer names, key sizes and digest algorithms from your own verification codeThis is the only item with a date attached, and the date is October 19, 2026
    Timestamp every signature, and record which timestamp authority signed itYou need that inventory to know what has to be re-signed if a TSA's algorithm is ever deprecated
    Keep the signing step behind one interface rather than scattered signtool callsChanging algorithm becomes one change instead of one per build pipeline
    Confirm your token or HSM has a firmware path to ML-DSAA device that cannot be upgraded becomes the migration's long pole, and it is procurement rather than engineering
    Keep an inventory of what you have signed and where it is deployedEvery migration plan starts by asking what would need re-signing, and almost nobody can answer

    One thing not to do: buy a longer certificate hoping to sit out the transition. That option no longer exists anyway, since 460 days is the maximum for anything issued from March 2026. A shorter cycle is genuinely better here — a pipeline that renews every fifteen months is a pipeline that has proved it can swap a certificate, and swapping the algorithm is the same operation with a different input.

    If you want the underlying mechanism rather than the schedule, Shor's algorithm explained covers what actually breaks RSA and ECC and how many qubits it would take, and our code signing overview covers what the certificate itself is doing.

    FAQ

    Frequently Asked Questions

    Get instant answers to common questions about SSL certificates and our services.

    Still Have Questions?

    Our SSL experts are available 24/7 to help with any questions about certificates, installation, or technical issues.

    Signing software between now and the transition

    Until the Code Signing Baseline Requirements change and a post-quantum root ships in the trust stores, an RSA or ECDSA certificate from a publicly trusted CA is what Windows, macOS and Java will accept. My-SSL issues through Certum, a publicly trusted certificate authority whose roots ship in the major browser and operating system trust stores, with the private key held in a hardware token or in SimplySign cloud signing as the requirements have demanded since June 2023. The OV and EV code signing options and what each one validates set out which is worth the extra verification for your situation.