Post-quantum code signing explained
Code signing is how a device or user knows software is authentic and unaltered before running it. The signature applied to a firmware image or software release must remain unforgeable for the artifact’s entire lifetime — which for embedded and industrial devices can be 10 to 20 years, overlapping the arrival window of quantum computers that would break classical signing.
The lifetime mismatch
A release signed today with ECDSA or RSA is verified every time the software or update runs, potentially for decades. If a quantum computer breaks that scheme during the artifact’s life, an attacker can forge a valid signature and deliver malicious code that passes verification. Because the verification logic is often baked into hardware or secure-boot chains, it cannot be swapped later — the post-quantum scheme must be in place at signing time.
Choosing the scheme
ML-DSA (Dilithium, FIPS 204) is the general-purpose choice: reasonable signature sizes and fast verification, well suited to frequent releases. SPHINCS+ (SLH-DSA, FIPS 205) is the conservative choice for root-of-trust and very long-lived keys, trading larger signatures for a security assumption based only on hash functions. Many secure-boot designs use hybrid signing — classical plus post-quantum — during transition so nothing regresses while PQC support propagates.
Honest scope
Post-quantum code signing ensures an artifact’s authenticity and integrity survive the quantum transition. It does not vouch for the code’s correctness or freedom from vulnerabilities, and it depends on sound key management — a compromised signing key defeats any scheme. The algorithms are resistant to known classical and quantum attacks per NIST, not unbreakable. Prioritize signing chains embedded in long-lived hardware first.
Try it yourself — live, free, verifiable in 30 seconds:
Add post-quantum code signing →