Introduction
Consider the possibility that your program now has a digital signature that reads, “I’m authentic and safe.” However, that identical signature can have no relevance in five years. It’s similar to leaving a wax seal on a letter, only to find out later that a machine has been created that can accurately duplicate it.
Quantum computing isn’t science fiction anymore. What used to be tucked away in academic papers is inching toward machines powerful enough to rip apart the math behind the cryptography we rely on, RSA, ECC, the works. When that happens, the guarantees behind “trusted” software updates and signed binaries start to unravel.
And here’s the kicker: attackers don’t need to wait. They can collect signed software today, stash it away, and patiently bide their time. This tactic has a name: Harvest Now, Decrypt Later (HNDL). Once quantum machines catch up, those carefully stored signatures become entry points. Imagine malware wearing a “valid” digital certificate mask, ready to walk straight through defences because the old math gave out.
Enterprise code signing solution, defined: a signing platform that protects private keys in certified hardware, integrates signing into CI/CD as a policy-enforced step rather than a manual one, and supports a migration path to post-quantum signature algorithms (ML-DSA, LMS/XMSS), evaluated on named platform versions, documented format support, and evidence you can verify independently rather than on marketing claims alone.
Key Takeaways
- RSA and ECDSA signatures are vulnerable to harvest-now-forge-later: an attacker who records a signed artifact today can forge new signatures once a cryptographically relevant quantum computer exists, regardless of how the artifact was distributed.
- Long-lived signed artifacts, firmware, industrial control software, medical device software, carry the highest exposure, since they can’t always be re-signed or patched once deployed.
- Verifier support for post-quantum signature algorithms (ML-DSA, LMS, XMSS) is not yet universal; confirm the specific platforms in your deployment path actually verify the algorithm before treating it as your sole signature.
- For the deeper technical comparison between LMS, XMSS, and SLH-DSA, and the full CNSA 2.0 migration architecture, see Comparing SLH-DSA, LMS, and XMSS and Architecting the CNSA 2.0 Transition Strategies.
Why Code Signing is Especially Exposed?
At its core, code signing is about one thing: trust. When you download an update or install a new app, the signature on that software is supposed to prove two things: who it came from and that it hasn’t been tampered with along the way. It’s like the digital version of checking the seal on a medicine bottle.
The problem is that today’s code signing almost always leans on RSA or ECC keys. Both of these depend on math problems that are tough for normal computers to crack but easy targets for a quantum computer. Once that barrier falls, the signature isn’t proof anymore, it’s just decoration.
And the risks aren’t abstract. Imagine a fake software update that looks perfectly legitimate because its forged signature checks out. Or malware dressed up with your company’s certificate, spreading under your name. Beyond the technical mess, the bigger hit is trust: customers, partners, and even regulators won’t care if you explain “quantum broke our crypto.” They’ll just see your brand on something unsafe.
The Countdown to Post-Quantum
NIST has been running the world’s biggest crypto bake-off for the past few years, testing, breaking, and finally picking the algorithms that are strong enough to survive quantum attacks. The first set of standards is already here, and the rest are on the way. That’s not theory anymore, that’s the clock ticking.
Most experts agree we’ve got a 3–5-year window before quantum machines start putting serious dents in today’s crypto. Sounds like plenty of time, right? The catch is that software doesn’t disappear when you release the next version. Signed code lives on in embedded devices, IoT sensors, industrial control systems, and medical gear, places where “just patch it” isn’t realistic.
This is why waiting is a losing strategy. A signature you generate today might still need to hold up a decade from now. If it can’t, then all that carefully built trust in your supply chain can evaporate overnight. The question isn’t whether you’ll need quantum-safe signing, it’s whether you’ll be ready before your attackers are.
Preparing for Quantum-Safe Code Signing
Getting ready for the post-quantum world isn’t about hitting a switch one day; it’s about laying the groundwork now. A few concrete steps make all the difference:
- Cryptographic Inventory: You can’t fix what you don’t know about. Start by mapping out where your signing keys actually live, what algorithms they use, and which systems depend on them. Think of it as taking attendance. Every key, every cert, every signing process should raise its hand.
- Crypto Agility: Hard-coding one algorithm into your setup is like pouring concrete over your lock and key. You want flexibility, so when new standards arrive, you can swap algorithms without tearing your systems apart. Build your signing processes in a way that supports change instead of dreading it.
- Hybrid Approaches: Since PQC standards are still being fine-tuned, a smart interim move is to pair them with today’s algorithms. That way, you get the best of both: the trust people already rely on plus a hedge against quantum threats down the road.
- Policy & Governance: Even the strongest algorithms are useless if keys are lying around unprotected. Lock them down with proper storage (think HSMs or secure services), enforce who can use them, and rotate them before they turn stale. Good rules and oversight keep mistakes and misuse in check.
Where CodeSign Secure Fits
Preparing for the transition above requires signing infrastructure that supports it. Here’s specifically what CodeSign Secure provides, and what to verify before relying on it for a given use case:
- Post-quantum signature support: CodeSign Secure v3.02 supports ML-DSA (FIPS 204, at the ML-DSA-44, ML-DSA-65, and ML-DSA-87 security levels) and LMS (NIST SP 800-208) as detachable signatures alongside classical RSA and ECDSA, including dual/hybrid signing where an artifact carries both a classical and a post-quantum signature during transition.
- HSM-backed key storage: Private keys are stored in FIPS 140-2 Level 3 certified HSMs, integrating with Thales Luna, Entrust nShield, Utimaco, Securosys, and cloud HSMs from AWS and Azure, exceeding the CA/Browser Forum’s FIPS 140-2 Level 2 minimum for publicly trusted code signing certificates.
- CI/CD integration: Native integration with Jenkins, Azure DevOps, GitLab, Bamboo, and TeamCity, enforcing signing as a policy-gated pipeline stage rather than a manual step.
- Format coverage: Windows executables and drivers (SignTool, Mage, NuGet, ClickOnce, HLK/HCK), Java/Android (JAR, WAR, APK via JarSigner and APKSigner), macOS (.dmg, .ipa, .pkg), Linux (RPM, GPG), Docker images, and firmware binaries (.bin, .img, .hex, .fw, .dfu).
- Audit trail: Every signing event logs the artifact hash, key identifier, certificate used, approving identity, and RFC 3161 timestamp, with SIEM integration via OpenTelemetry (Grafana, Loki, Splunk).
What to Verify Before Relying on This for Production
Two things are worth confirming independently rather than taking on faith, from any vendor: first, verifier support for ML-DSA and LMS signatures is still uneven across platforms, so confirm the specific bootloaders, update clients, or OS verifiers in your deployment path actually recognize the algorithm before treating it as your production signature, hybrid signing exists specifically to cover this gap during transition. Second, HSM firmware support for a given PQC algorithm and parameter set varies by vendor and model; check directly with your HSM vendor for the exact parameter set you plan to use, since general PQC-readiness claims don’t guarantee support for a specific scheme. Neither of these limitations is unique to CodeSign Secure, they apply to any signing platform adopting post-quantum algorithms ahead of universal verifier support, but they’re worth confirming for your specific environment rather than assuming from a product datasheet.
For independent, non-vendor confirmation of the standards referenced here, see NIST’s FIPS 204 (ML-DSA) and SP 800-208 (LMS/XMSS) publications, and the CA/Browser Forum’s Code Signing Baseline Requirements for the HSM and revocation rules that apply regardless of which signing platform you use.
Conclusion
Quantum computing capable of breaking RSA and ECC isn’t guaranteed on any specific date, but the harvest-now-forge-later risk doesn’t require it to arrive soon to matter: any artifact signed today and expected to remain trusted for years, firmware, industrial control software, long-lifecycle embedded devices, carries that exposure now, regardless of when a cryptographically relevant quantum computer actually materializes.
The practical response isn’t a single migration event. It’s building the cryptographic inventory, crypto agility, and hybrid signing capability described above, so that when verifier support for post-quantum signatures matures, the switch is a configuration change rather than a rebuild. CodeSign Secure supports that path with HSM-backed key storage, ML-DSA and LMS signing alongside classical algorithms, and CI/CD-integrated policy enforcement, but the underlying work, inventory, agility, testing against your specific verifiers, applies regardless of which signing platform an organization uses.
Frequently Asked Questions
Does CodeSign Secure require replacing classical signatures immediately?
No. It supports dual signing, an artifact carrying both a classical and a post-quantum signature, so systems that don’t yet verify the new algorithm still trust the classical one while updated systems gain quantum-resistant verification.
What HSM vendors does CodeSign Secure support?
Thales Luna, Entrust nShield, Utimaco, and Securosys, plus cloud HSMs from AWS and Azure. Confirm with your specific vendor which PQC algorithms and parameter sets their firmware supports, since this varies by model.
Which post-quantum signature algorithms does it support today?
ML-DSA (FIPS 204) at the 44, 65, and 87 security levels, and LMS (NIST SP 800-208), as detachable signatures alongside RSA and ECDSA.
Is verifier support for these algorithms universal yet?
No. Confirm the specific bootloaders, update clients, and OS verifiers in your deployment path recognize ML-DSA or LMS before relying on either as a sole signature; this is exactly the gap dual signing is designed to cover during transition.
The software you sign today may still need to be trusted a decade from now. Building cryptographic inventory and agility now is what makes that possible.
