Code Signing Crisis: Improving Supply Chain Security Before 2030

Type: Technical Briefing
Published: February 2026
Keywords: Code signing, Software supply chain, ML-DSA, ECDSA, Quantum threat, CNSA 2.0, NIS2, SolarWinds, SBOM

Abstract

Code signing is the digital handshake that tells users "this software hasn't been tampered with." But the algorithms underpinning today's signing infrastructure—RSA and ECDSA—will not withstand a cryptanalytically relevant, fault-tolerant quantum computer running Shor's algorithm at scale [1]. This article maps the supply-chain attack surface, reviews real-world incidents that exploited code-signing weaknesses.

Key Points at a Glance

  • Supply-chain attacks are surging: SolarWinds (2020), 3CX (2023), and the xz Utils backdoor (2024) show how build pipelines and software trust mechanisms can be turned into high-leverage attack paths [7][8][9].
  • Code signing relies on quantum-vulnerable crypto: most signing pipelines still use RSA-2048 or ECDSA-P256—both vulnerable to Shor's algorithm on a cryptanalytically relevant quantum computer [1].
  • Regulatory pressure is concrete: NSA CNSA 2.0 recommends using CNSA 2.0 algorithms for new software/firmware signing by 2025 and completing transition by 2030 [4]. A joint statement by authorities from 18 EU member states recommends protecting the most sensitive use cases against “store now, decrypt later” no later than end of 2030 [5].
  • ML-DSA and SLH-DSA are standardized: NIST finalized FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in 2024 [2][3].
  • Hybrid/dual-signature approaches can ease migration: feasibility depends on the signature container and verifier ecosystem; composite (multi-algorithm) signature profiles for PKI are being standardized [10].
  • Acting late is expensive: certificate rotation, revocation, and re-signing across a large software estate is a multi-month, multi-team operation—start before it becomes an incident response exercise.

Why Code Signing Matters More Than You Think

Imagine this: a routine operating-system update lands on your laptop. It looks legitimate, it's signed by the vendor, and your system installs it without a second thought. But behind the scenes, an attacker silently replaced the binary and forged the publisher's signature. Congratulations—you've just been backdoored by a supply-chain attack.

Code signing is supposed to prevent exactly this scenario. A digital signature on a binary, firmware image, container or package provides two guarantees: integrity (the code hasn't been modified since the publisher signed it) and provenance (the signature can be traced back to a trusted publisher). The trust chain runs from a root Certificate Authority through an intermediate CA down to the publisher's signing certificate—and finally to the hash of the artefact your machine checks before installation.

The scope is broader than many realise. Code signing isn't just about Windows .exe files. It protects npm and PyPI packages, Docker container images, Linux kernel modules, firmware blobs, UEFI Secure Boot chains, mobile apps on iOS and Android, and virtually every piece of software that travels from a developer to an end user. If this chain of trust breaks at any point, the consequences ripple across millions of devices.

The Supply-Chain Attack Surface: Real-World Precedents

Supply-chain attacks are no longer theoretical. They are happening at scale, and several of the most devastating incidents in recent years specifically targeted code-signing infrastructure.

🔥 SolarWinds (2020)

Attackers compromised the SolarWinds build pipeline and injected malicious code into the Orion IT management platform. The trojanised update was digitally signed and distributed through normal update channels. Early reporting cited up to ~18,000 customer downloads of affected Orion versions (potential exposure), while confirmed downstream targeting impacted a smaller subset of high-value victims. [7]

📞 3CX (2023)

A cascading supply-chain attack began when a 3CX employee downloaded trojanised trading software. Attackers used the access to compromise 3CX's build environment and ship a trojanised desktop client distributed as a signed installer. The potential reach was large given 3CX's reported customer base (often cited at ~600,000). [8]

🐧 xz Utils (2024)

A multi-year social-engineering and maintainer-infiltration campaign resulted in malicious code being introduced into xz/liblzma (notably versions 5.6.0 and 5.6.1). The incident highlights that supply-chain risk is not limited to stolen signing certificates: trusted maintainership and release engineering can be just as critical. [9]

⚠️ The Common Thread

In every case, the signing infrastructure itself was the target. Keys stored in software HSMs, inadequately rotated credentials, CI/CD secrets exposed in build pipelines, or—most insidiously—trust placed in individuals who maintained critical open-source dependencies. Once the signing key or build pipeline is compromised, the signature becomes a weapon that amplifies the attacker's reach instead of blocking it.

The Quantum Threat to Code Signing

We've written extensively about the harvest-now, decrypt-later threat to encrypted communications. But here's what makes code signing even more urgently affected than key exchange:

🚨 The Scenario We Must Prevent

It's 2032. A well-funded adversary breaks the ECDSA-P256 key behind a major embedded-systems vendor's firmware-signing certificate. They craft a counterfeit firmware update for a widely deployed industrial IoT sensor and push it through the vendor's legitimate update channel. Every device that checks the (now forgeable) signature installs the malicious firmware without complaint. The result? Thousands of compromised devices across critical infrastructure—and no cryptographic trail to detect the forgery.

Estimates for when a cryptanalytically relevant quantum computer could break RSA/ECDSA vary widely. Policy and risk-management guidance therefore focuses on migration timelines rather than predicting a single break date. For high-assurance environments, CNSA 2.0 provides concrete planning milestones for signing workloads (new software/firmware by 2025; full transition by 2030) [4].

What's Available Today: ML-DSA, SLH-DSA, and Hybrid Approaches

The good news? NIST didn't just standardise post-quantum key exchange in 2024—they also finalised two post-quantum signature schemes ready for deployment:

Algorithm Standard Public Key Signature Typical performance Assumption
RSA-2048 PKCS #1 256 B 256 B Slow signing, fast verification (widely optimized) Factoring ❌ quantum
ECDSA-P256 FIPS 186-5 64 B 64 B Fast signing and verification (widely optimized) ECDLP ❌ quantum
ML-DSA-65 FIPS 204 1,952 B 3,309 B Fast verification; larger keys/signatures Module-LWE ✅ quantum
ML-DSA-87 FIPS 204 2,592 B 4,627 B Fast verification; larger keys/signatures Module-LWE ✅ quantum
SLH-DSA-128f FIPS 205 32 B 17,088 B Very large signatures; signing is comparatively slow Hash-based ✅ quantum

Performance varies significantly by implementation and hardware. Note that NIST FIPS 204 defines ML-DSA signature encodings of 3,309 B (ML-DSA-65) and 4,627 B (ML-DSA-87); older references to CRYSTALS-Dilithium often cite 3,293 B and 4,595 B for the corresponding parameter sets. For continuously updated, reproducible measurements, see Open Quantum Safe benchmarking for liboqs [12].

ML-DSA (formerly CRYSTALS-Dilithium) is the leading candidate for most code-signing use cases. Its verification speed—comparable to ECDSA—makes it practical even for constrained devices that need to check signatures on every boot. The trade-off is larger keys and signatures (roughly 50–75× bigger than ECDSA), which impacts certificate chain sizes and bandwidth.

SLH-DSA (formerly SPHINCS+) offers a conservative alternative based solely on hash functions—no lattice assumptions needed. The downside? Signatures balloon to ~17 kB and signing is orders of magnitude slower. It's best suited as a backup algorithm or for scenarios where the extra security margin justifies the cost.

💡 Hybrid / Dual Signing: A Practical Transition Pattern

A common near-term strategy is dual signing: produce a classical signature (e.g., ECDSA) and a post-quantum signature (e.g., ML-DSA) for the same artefact. The operational goal is straightforward—maintain compatibility while enabling quantum-resistant verification—but the details depend on the ecosystem.

Important caveat: “just concatenate signatures” is not universally compatible. Some formats and tools support multiple signatures or multiple signers; others require new containers or metadata. For PKI/X.509 environments, composite (multi-algorithm) signature profiles are actively being standardized [10].

Tooling is catching up fast. AWS KMS supports generating and using ML-DSA keys for signing operations [11]. On the platform side, IBM z16 secure boot uses quantum-safe and classical signatures in parallel to protect the firmware chain of trust [13].

Regulatory Pressure: CNSA 2.0, NIS2, and BSI

Regulators aren't waiting for the quantum threat to materialise—they're setting hard deadlines now. If you handle software, firmware or infrastructure for government or critical-sector customers, these dates are effectively non-negotiable.

Regulatory Timeline: High-Level Planning Milestones for Signing
!
2025 — CNSA 2.0 (NSS)
New software and firmware should use CNSA 2.0 signing algorithms by 2025. [4]
↓
!
2030 — CNSA 2.0 (NSS)
All deployed software and firmware should transition to CNSA 2.0-compliant signatures by 2030. [4]
↓
!
End of 2030 — EU joint statement
Authorities from 18 EU member states recommend protecting the most sensitive use cases against “store now, decrypt later” no later than end of 2030. [5]

The consistent message across guidance and regulation is that long-lived integrity mechanisms (such as software and firmware signing) must migrate on a planning timeline rather than in a last-minute emergency. CNSA 2.0 explicitly includes software and firmware signing and provides concrete milestones [4]. In the EU, NIS2 turns “state of the art” cybersecurity risk management into a legal obligation, with administrative fine ceilings of up to 2% of worldwide annual turnover for essential entities and 1.4% for important entities (member-state implementation may vary) [6].

For a detailed, phase-by-phase migration plan tailored to German SMBs—including funding opportunities—see our Quantum-Safe Roadmap for GmbHs.

Next Step

Code signing is where the quantum threat meets the software supply chain—and both problems are accelerating. The attacks of 2020–2024 exploited procedural weaknesses in signing infrastructure; the attacks of the 2030s may exploit cryptographic ones. The good news is that the algorithms, tooling, and regulatory frameworks to fix this already exist. The bad news? The window to act is closing fast.

For deeper dives into the technologies discussed here, explore our related articles:

References

  1. NIST IR 8105 (Final): Report on Post-Quantum Cryptography. NIST CSRC. https://csrc.nist.gov/pubs/ir/8105/final
  2. NIST FIPS 204 (Final): Module-Lattice-Based Digital Signature Standard (ML-DSA). https://csrc.nist.gov/pubs/fips/204/final
  3. NIST FIPS 205 (Final): Stateless Hash-Based Digital Signature Standard (SLH-DSA). https://csrc.nist.gov/pubs/fips/205/final
  4. NSA: Commercial National Security Algorithm Suite 2.0 (software & firmware signing milestones; document dated Sep 2022, Ver. 1.0). https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
  5. BSI (and partners from 17 other EU member states): Joint statement on transitioning to post-quantum cryptography (27 Nov 2024). https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/PQC-joint-statement.pdf
  6. Directive (EU) 2022/2555 (NIS2) — Official Journal PDF (fine ceilings and enforcement). https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX%3A32022L2555
  7. SolarWinds: An Investigative Update of the Cyberattack (May 2021). https://www.solarwinds.com/blog/an-investigative-update-of-the-cyberattack
  8. Volexity: 3CX Supply Chain Compromise Leads to ICONIC Incident (30 Mar 2023); plus context on reported customer scale. https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/
  9. BSI Cybersecurity Warning: Kritische Backdoor in XZ für Linux (CVE-2024-3094) (Apr 2024). https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2024/2024-223608-1032.pdf
  10. IETF LAMPS: Composite Signatures for use in Internet PKI (draft-ietf-lamps-pq-composite-sigs). https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-sigs/
  11. AWS Key Management Service (AWS KMS): ML-DSA support for post-quantum signatures (announcement and docs). https://aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-post-quantum-ml-dsa-digital-signatures/
  12. Open Quantum Safe: Continuous benchmarking (liboqs signature/KEM performance). https://openquantumsafe.org/benchmarking/
  13. IBM Redbooks: Transitioning to Quantum-Safe Cryptography on IBM Z (secure boot uses quantum-safe and classical signatures in parallel). https://www.redbooks.ibm.com/redpieces/pdfs/sg248525.pdf