# Code Signing PQC Migration Playbook **Source**: https://quantumsequrity.com/blog/code-signing-pqc-migration **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # Code Signing PQC Migration Playbook 12 min read Code signing is the bedrock of software trust. When you download an installer for Windows or run a notarized macOS app, your operating system checks a signature before letting the binary run. The signature proves that the publisher you expect actually shipped the bytes you have, and that nobody has tampered with them in transit. Most code signing today uses RSA or ECDSA, both of which a future quantum computer can break. The migration to post-quantum signatures is one of the more difficult parts of the broader PQC transition because code signing has to support a long tail of legacy operating systems and tools, while still keeping pace with new threats. This playbook walks through the major code signing ecosystems, what their PQC roadmaps look like, and how an organization can migrate without breaking legacy users or rushing into instability. ## Why Code Signing Is a Special Case Most cryptographic operations are short-lived. A TLS connection lives for seconds. An encrypted file might be decrypted within months. A code signature, in contrast, must remain trustworthy for the entire lifetime of the signed software. A driver signed in 2010 may still be running on a Windows 7 machine in some industrial site. The verification of that driver's signature has to keep working. This is why CMS (Cryptographic Message Syntax), the format that wraps most code signatures, supports timestamps. A timestamp from a trusted timestamp authority lets a verifier say "this signature was valid at time T", even if the publisher's certificate has since expired. The post-quantum question for code signing therefore involves both the signature on the binary and the signature on the timestamp. For an introduction to the broader threat, see [why-rsa-2048-will-break](why-rsa-2048-will-break.md). ## Microsoft Authenticode Authenticode is the Windows code signing format. It applies to executables, installers, drivers, scripts, and many other file types. The signature is embedded in a specific location in the binary and the structure follows the PE/COFF format with a Crypto API extension. Authenticode today supports RSA, ECDSA, and several hash algorithms including SHA-256. The chain of trust runs from the publisher's certificate up through a Microsoft-trusted root. Microsoft maintains its own root program separate from the Web PKI, and adding new algorithms to that program requires Microsoft engineering and policy changes. The PQC migration for Authenticode involves several moving parts. The Crypto API itself needs to support ML-DSA. The signing tools, primarily SignTool.exe, need to accept ML-DSA keys and produce valid signatures. The Windows verifier needs to check ML-DSA signatures. The certificate roots need to include ML-DSA-capable issuers. And third-party CAs that issue Authenticode certificates need to support ML-DSA. Microsoft has been publishing guidance on PQC migration through the MSRC and the Windows engineering blog. The general direction is hybrid-first. Hybrid Authenticode signatures would carry both an RSA or ECDSA signature and an ML-DSA signature, satisfying old verifiers and new ones simultaneously. ## Apple Notarization Apple's notarization workflow is different from Authenticode in several ways. The signature on a macOS app is part of the app bundle, but the trust check involves a network call to Apple's notarization service. The service checks the binary against malware signatures and other policy rules, then issues a stapled ticket that confirms the app was reviewed. The cryptographic primitives behind notarization are based on Apple's own PKI, which uses ECDSA today. Apple has not publicly committed to a specific PQC timeline, but Apple's general security engineering direction is to follow NIST standards once they are formalized. Apple already uses ML-KEM for iMessage's PQ3 protocol, which suggests the cryptographic stack is being prepared. For the developer, notarization is a black box in the best sense. The tools (xcrun notarytool, codesign) handle the cryptography and the developer simply submits and ships. When Apple flips the switch on PQC notarization, most developers will not notice except for slight changes in the size of the embedded ticket. ## CA/Browser Forum Code Signing Baseline The CA/Browser Forum publishes baseline requirements for code signing certificates issued by public CAs. These requirements cover key sizes, hash algorithms, certificate lifetimes, and the security of the issuing infrastructure. The baseline is what makes a code signing cert from DigiCert behave consistently with one from Sectigo or GlobalSign. The baseline currently mandates strong RSA and ECDSA configurations. The PQC migration for code signing CAs will go through the CA/Browser Forum process, which is slow but thorough. New algorithm support has to be added to the baseline, vendors have to update their compliance, and audits have to verify the changes. A practical implication for organizations is that the timing of public CA support for ML-DSA code signing certificates depends on this committee process. Some private CAs (organizations running their own internal code signing for in-house tools) can move faster because they are not bound by the public baseline. For CA-related PQC discussion, see [acme-pqc-letsencrypt](acme-pqc-letsencrypt.md). ## Hash Algorithms in Code Signing Code signing depends on hashing as much as it depends on signing. Authenticode uses SHA-256 today, having migrated away from SHA-1 a decade ago. SHA-256 is not broken by Shor's algorithm, but it is weakened by Grover's algorithm. Grover's effective attack on a 256-bit hash gives 128 bits of resistance, which is still beyond practical attack but provides less margin than the classical view. NIST guidance for the post-quantum era recommends SHA-384 or SHA-512 for new applications that need long-term integrity. Code signing applications that produce signatures intended to remain valid for decades should consider migrating to SHA-384 alongside or before the migration to PQC signature algorithms. ## ML-DSA Signature Sizes The single biggest practical concern in code signing PQC migration is signature size. Authenticode signatures with ECDSA-P256 are about 100 bytes for the raw signature, with a few hundred more bytes for the certificate chain. ML-DSA-65 signatures are about 3.3 kilobytes. ML-DSA-87 is around 4.6 kilobytes. For a single executable, this is irrelevant. For a Windows install media that contains thousands of signed binaries, the cumulative size matters. A driver package that ships hybrid signatures (classical plus ML-DSA) is roughly 5 to 6 kilobytes larger per binary, which over a large package can mean tens of megabytes of additional size. For most organizations, this is a tradeoff worth making. The size penalty is manageable in the cloud era. For embedded applications shipping firmware to disk-constrained devices, the calculus is different and may favor SLH-DSA in some cases despite its even larger signatures, because SLH-DSA is hash-based and considered more conservative. For more on the ML-DSA versus SLH-DSA tradeoff, see [mldsa-vs-slhdsa](mldsa-vs-slhdsa.md). ## Stateful Hash-Based Signatures: LMS A separate option for code signing is LMS, the stateful hash-based signature scheme described in RFC 8554. LMS signatures are conservative because their security depends only on the underlying hash function, with no number-theoretic assumptions. LMS is approved by NSA's CNSA 2.0 for software and firmware signing. The catch is that LMS is stateful. Each signature consumes a one-time key from a hash tree, and reusing a key breaks security. The signer must keep state about which keys have been used, and that state must never be lost or rolled back. This makes LMS unsuitable for general-purpose signing where keys are copied across machines or backed up casually, but it is a good fit for code signing where the signing infrastructure is centralized and operates with strict process control. For more on LMS, see [lms-stateful-signatures](lms-stateful-signatures.md). ## Building a Migration Plan A practical migration plan has five phases. Phase one is inventory. List every type of code signing your organization performs. Windows executables, drivers, kernel modules, macOS apps, mobile apps, container images, JavaScript bundles, browser extensions, custom firmware, and internal tools all use different signing systems. The first step is knowing what you have. Phase two is dependency mapping. For each signing system, identify the cryptographic primitives in use, the CA that issues your certificates, the toolchain that produces signatures, and the verifiers that consume them. The verifier set is the most critical part because the slowest verifier on the slowest customer's machine sets the floor for what algorithms you can ship. Phase three is hybrid pilot. For each signing system, set up a parallel pipeline that signs with both classical and post-quantum algorithms. Use this in a test environment where you control the verifiers. Verify that the hybrid signatures are accepted by all current verifiers and that the post-quantum portion verifies correctly with PQC-enabled verifiers. Phase four is rollout. Move production signing to hybrid one product at a time, monitoring telemetry for verification failures. Be prepared to roll back. The rollback path is critical because a verification failure on a customer's machine at install time looks like malware and triggers support calls. Phase five is steady state. Eventually, when classical signatures are no longer needed, switch to pure post-quantum. This phase is years away for most organizations because legacy verifiers persist for a long time. For a more general migration strategy, see [hybrid-migration-strategy-step-by-step](hybrid-migration-strategy-step-by-step.md). ## Internal Code Signing Many organizations sign internal tools and scripts that never leave their infrastructure. The migration story for internal code signing is much faster because the verifier population is controlled. If your CI runs on a fixed set of build machines and your deployment targets are servers you operate, you can move to ML-DSA today using OpenSSL 3.5 or a similar PQC-capable library. The internal case is a useful learning ground. Teams that pilot PQC code signing internally build the operational muscle they need before tackling public-facing migration. Issues like signature size, key management, and timestamp authority compatibility surface in a low-stakes environment. For broader PQC compatibility background, see [what-is-post-quantum-cryptography](what-is-post-quantum-cryptography.md). ## Timestamp Authorities Code signatures rely on timestamp authorities to extend their validity beyond the publisher's certificate lifetime. RFC 3161 defines the protocol. The TSA itself signs with a key, and the TSA's signature must remain trustworthy for the full lifetime that the code signature is expected to remain valid. This creates a chicken-and-egg problem. A code signature signed in 2026 with a TSA that uses RSA-2048 is exposed if a quantum computer arrives in 2040 and breaks the TSA's signature. The TSA's chain becomes invalid retroactively. This is one of the strongest arguments for PQC TSAs, even before the publisher migrates their own signing keys. DigiCert, Sectigo, and other major TSAs have published statements about PQC roadmaps. The migration depends on the same algorithm support across the industry as code signing certificates. ## Frequently Asked Questions **Will my existing signed binaries stop working after a PQC migration?** No. Signatures already produced remain valid as long as the verifier and the timestamp authority chain still verify. The migration is forward-looking. **Should I switch to LMS or ML-DSA for code signing?** For most organizations, ML-DSA is the better default because it is general purpose and stateless. LMS is appropriate where the signing process is highly controlled and state can be reliably maintained, such as kernel signing. **How big is a hybrid Authenticode signature?** A hybrid signature combining ECDSA-P384 with ML-DSA-65 is approximately 3.5 kilobytes larger than the classical version. This is acceptable for most use cases. **Do I need a new code signing certificate from my CA?** Eventually yes. When public CAs begin issuing PQC code signing certificates, you will renew or rekey to obtain one. Until then, your existing certificate continues to be valid. **What about smart cards and HSMs?** Hardware tokens that hold code signing keys need PQC support added. Several HSM vendors have shipped firmware updates that support ML-DSA. Smart card vendors are slower but moving in the same direction. ## Sources - [NIST FIPS 204: Module-Lattice-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/204/final) - [NIST FIPS 205: Stateless Hash-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/205/final) - [RFC 8554: Leighton-Micali Hash-Based Signatures (LMS)](https://datatracker.ietf.org/doc/html/rfc8554) - [RFC 3161: Time-Stamp Protocol (TSP)](https://datatracker.ietf.org/doc/html/rfc3161) - [NSA CNSA 2.0 Cybersecurity Information Sheet](https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSI_CNSA_2.0_ALGORITHMS_.PDF) - [NIST SP 800-208: Stateful Hash-Based Signature Schemes](https://csrc.nist.gov/pubs/sp/800/208/final) ## Related Articles - [Why RSA-2048 Will Break](why-rsa-2048-will-break.md) - [ML-DSA vs SLH-DSA](mldsa-vs-slhdsa.md) - [LMS Stateful Signatures](lms-stateful-signatures.md) - [Hybrid Migration Strategy Step by Step](hybrid-migration-strategy-step-by-step.md) - [Crypto Agility Explained](crypto-agility-explained.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)