Digital Signatures in the Post-Quantum Era: A Non-Technical Explainer

Every time you sign a contract digitally, download a software update, or visit a website over HTTPS, a digital signature is working in the background. You probably never think about it. But the mathematics underpinning those signatures has a problem: a future quantum computer will be able to break it. This is not a distant theoretical concern. NIST published its transition timeline in November 2024, and the clock is now running.

This article explains what digital signatures actually do, why quantum computers threaten the current ones, which use cases face the greatest urgency, and what post-quantum replacements are now standardised and ready. No mathematical background is required.

What a digital signature actually does

A digital signature performs two functions simultaneously: it proves who produced a document, message, or piece of software (authentication), and it proves that the content has not been changed since the signature was applied (integrity). These two properties together are what give digital signatures their legal and operational weight.

Consider three contexts you almost certainly rely on. When a solicitor sends you a qualified electronic signature on a contract, that signature confirms both their identity and that the document has not been altered in transit. When you download software and your operating system quietly verifies it before installation, a code signature is doing the same work. When your browser shows the padlock next to a website address, a digital certificate signed by a certificate authority is confirming that the server is who it claims to be.

Under EU law, qualified electronic signatures have the same legal effect as a handwritten signature (eIDAS Regulation, No. 910/2014, as updated by eIDAS 2, Regulation (EU) 2024/1183 of May 2024). In the UK, the Electronic Identification and Trust Services Regulations 2019 (SI 2019/1361) carry this framework forward, supplemented by the Data Protection and Digital Information Act 2024 (DPDIA 2024) and the Digital Identity and Attributes Trust Framework (DIATF) published by the UK government on GOV.UK. In the US, the ESIGN Act (2000) and the Uniform Electronic Transactions Act establish equivalent legal validity. None of these legal frameworks specify which cryptographic algorithms must be used. They specify the security requirements the underlying cryptography must satisfy. When those algorithms become insecure, the legal framework requires the cryptography to be updated.

This article provides general information about the regulatory landscape and does not constitute legal advice. Organisations should seek qualified legal counsel regarding the specific implications of post-quantum cryptography transitions for their signed documents and compliance obligations.

Why quantum computers threaten RSA and ECDSA signatures

The two signature algorithms used in almost every digital signature system today are RSA and ECDSA. RSA signatures rely on the difficulty of factoring very large numbers. ECDSA signatures rely on the difficulty of solving the elliptic curve discrete logarithm problem. Both of these mathematical problems are extremely hard for classical computers, including the most powerful supercomputers. RSA-2048 is effectively unbreakable by any computer that exists today.

The threat is from future quantum computers. In 1994, mathematician Peter Shor published an algorithm showing that a quantum computer with sufficient qubits and error correction capability could solve both of these problems efficiently. A cryptographically relevant quantum computer (CRQC) running Shor's algorithm could produce valid-looking RSA or ECDSA signatures on any document, purportedly from any entity, without access to the original private key. Signature forgery, at scale.

For a technical explanation of how Shor's algorithm attacks RSA and elliptic curve cryptography, see Shor's Algorithm: Why RSA and ECC Are Quantum-Vulnerable.

This threat is not symmetrical across all cryptography. Symmetric encryption, such as AES-256, and hash functions, such as SHA-256, are affected only by Grover's algorithm, which provides a quadratic speedup and can be countered by doubling key length. AES-256 remains quantum-safe at its current key size. NIST IR 8547 (November 2024) confirms this: AES-256 and SHA-384 are retained without change. RSA and ECDSA are listed for deprecation, specifically because they are asymmetric algorithms vulnerable to Shor's algorithm. Digital signatures use asymmetric cryptography. They are precisely the category most at risk.

No CRQC capable of running Shor's algorithm against real-world key sizes exists today. The Global Risk Institute's 2024 quantum threat timeline report estimates a roughly 50% probability of a CRQC by approximately 2033 to 2035. That estimate gives a planning window of approximately seven to nine years from now.

Where the threat is most serious and where it is less urgent

Not all digital signatures face the same urgency. The key variable is how long the signature must remain trustworthy.

The most serious concerns involve long-lived signatures:

Code signing and firmware signing. A signed firmware image for an industrial control system, a medical device, or an automotive ECU may be in deployment for ten to fifteen years after release. NSA's CNSA 2.0 advisory explicitly identifies code signing as a high-priority use case. NIST FIPS 205 (SLH-DSA) was designed specifically with long-lived signature contexts in mind. If a CRQC can forge signatures on firmware images, it could produce modified firmware that passes verification on devices already in the field.

Certificate infrastructure. Every HTTPS website, every S/MIME email server, and every VPN using certificates relies on a chain of signatures from a certificate authority. CA root certificates can have validity periods of fifteen to twenty-five years. If a CA's signature algorithm is broken, every certificate in the chain it signed becomes untrustworthy. Replacing embedded root certificates in operating systems, browsers, and applications requires industry-wide coordination measured in years. For more on this infrastructure layer, see What is PKI and Can Quantum Computers Break It?

Legal and archival documents. Digitally signed property records, regulatory filings, wills, and long-term contracts that must remain legally valid for decades present an emerging challenge. Whether ECDSA signature forgery could retrospectively challenge an archived document's legal validity is an area that legal and compliance teams should be evaluating now, not after a CRQC arrives.

Two categories where urgency is lower:

Short-lived TLS certificates. The CA/Browser Forum Baseline Requirements limit TLS certificate validity to approximately 398 days (the current maximum under the Baseline Requirements). An organisation that migrates its certificate infrastructure to post-quantum signatures before a CRQC exists will issue certificates carrying ML-DSA or SLH-DSA signatures that are not vulnerable to forgery. The migration window is manageable if planning starts now.

Short-lived authentication tokens. JWT tokens, SAML assertions, and OAuth tokens with validity periods of minutes to hours have negligible practical value as retrospective forgery targets.

The concept sometimes called "forge later" is less pressing for signatures than "harvest now, decrypt later" is for encrypted data, because a forged signature on a past contract does not retroactively change the contract's legal validity under current law. The exception is long-lived signed assets where future forgery could create new false documents that appear legitimate.

The post-quantum replacements: what ML-DSA and SLH-DSA are

In August 2024, NIST published two post-quantum digital signature standards. FIPS 204 standardises ML-DSA (Module-Lattice Digital Signature Algorithm), the primary replacement for RSA and ECDSA in general-purpose applications. FIPS 205 standardises SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), designed for high-assurance contexts where long-lived signatures and conservative security are required. In October 2024, NIST published FIPS 206, standardising FN-DSA for applications where compact signature size is the priority.

These algorithms are based on mathematics that no known quantum algorithm can efficiently break. ML-DSA uses lattice-based mathematics. SLH-DSA relies entirely on hash functions, which makes it the most conservative choice: its security rests only on the difficulty of breaking SHA-2 or SHA-3, not on any new mathematical assumption.

The signature sizes are larger than RSA and ECDSA:

For most document signing and email signing applications, the size difference is not significant. A digitally signed PDF is already many kilobytes or megabytes. Where size matters, such as TLS certificates transmitted with every HTTPS connection, the ecosystem is adapting.

Crucially, the migration is a software upgrade, not a hardware replacement. The same servers, laptops, and devices that run RSA and ECDSA today can run ML-DSA and SLH-DSA. The complexity lies in coordinating the migration across the entire ecosystem: every entity that creates signatures must upgrade, and every entity that verifies signatures must be able to verify the new format. That coordination takes years for widely deployed infrastructure like TLS certificates. It does not happen by itself.

Document signing, code signing, and identity: what changes for each

The migration implications differ by use case.

Document signing. For PDF electronic signatures, email signatures using S/MIME, and contract execution platforms, the migration depends on the platform provider. Users do not change their own workflows: the platforms update their underlying cryptographic algorithms and issue new signing certificates. Organisations should ask their document signing vendors whether they have a post-quantum migration roadmap that includes ML-DSA support, and when it will be delivered. For qualified electronic signatures under eIDAS and eIDAS 2 (Regulation (EU) 2024/1183), the migration to post-quantum trust service providers will require standards updates. ETSI and ENISA are working on post-quantum requirements for qualified electronic signatures under the ETSI TS 119 312 framework; the specific work item reference should be verified directly with ETSI at time of reading, as the work programme was active at knowledge cutoff August 2025. [ASSUMED — ETSI work item number: resolve by verifying ETSI TS 119 312 current publication status]

Code signing. Software publishers who sign their code must migrate their signing keys to ML-DSA or SLH-DSA before a CRQC makes the existing RSA or ECDSA signing keys forgeable. NSA CNSA 2.0 includes code signing as a required migration use case. A signed software release distributed in 2026 may still be in use in 2033 and beyond. Organisations distributing software with long deployment lifetimes should plan to re-sign existing releases with post-quantum signatures and to use post-quantum algorithms for all new releases. NIST FIPS 205 (SLH-DSA) is specifically designed for this long-lived use case.

Identity certificates (PKI). Every HTTPS website relies on a certificate signed by a certificate authority. When browsers and operating systems can verify ML-DSA-signed certificates issued by post-quantum CAs, the web's certificate ecosystem has migrated. This requires CA software upgrades, browser and operating system trust store updates, and the issuance of new ML-DSA certificates to replace existing RSA and ECDSA ones. The CA/Browser Forum, browser vendors, and operating system vendors are all active participants in migration planning. The transition is happening; it will not be complete overnight.

For a fuller picture of how the certificate infrastructure layer works and why it matters for quantum migration, see What is PKI and Can Quantum Computers Break It?

When to act: the timeline and three practical steps

NIST IR 8547 (November 2024) sets 2030 as the point after which RSA and ECDSA should not be used in new digital signature deployments. Any new signing infrastructure being designed or procured in 2026 should be planned with ML-DSA as the target algorithm, not built on RSA that will need replacement within four years.

Different parts of the signature ecosystem have different urgency:

• TLS certificates (reissued approximately every 398 days under CA/Browser Forum Baseline Requirements): migration planning should begin now so that certificates issued in 2028 carry post-quantum signatures and are clear of the 2033 to 2035 risk window.
• Long-lived firmware and code signatures: higher priority. Firmware signed in 2026 under RSA may still be running in 2033 when a CRQC could emerge.
• Document archives and legal records: evaluate whether the long-term legal validity of archived signatures could be challenged and consult legal counsel on archival re-signing strategies.

Three steps any organisation can take now, regardless of size:

1. Identify where you rely on digital signatures. Start with an inventory covering website certificates (TLS), email security (S/MIME, DKIM), document signing, software distribution, and employee identity (smart cards, PKI-based authentication). This is the equivalent of a cryptographic inventory, focused specifically on signature use cases.

2. Ask your vendors about their post-quantum roadmap. Certificate authorities, document signing platforms, code signing infrastructure providers, email security vendors, and PKI software providers all need to migrate to ML-DSA. Ask for a concrete delivery timeline before 2030. If a vendor cannot answer the question, that is significant information.

3. Plan for long-lived signatures first. Firmware images, software releases, and archival documents that will be in use past 2033 are the highest priority. Confirm when ML-DSA signing becomes available in your toolchain and plan the migration accordingly.

This migration has a clear endpoint. The target algorithms are standardised (FIPS 204, 205, 206). The transition timeline is published (NIST IR 8547). The technology is proven: Cloudflare, Google Chrome, and AWS have all deployed post-quantum cryptography in production. Organisations that begin the signature migration now will reach compliance with margin to spare and time to address complications. Those that wait for 2029 will discover that the runway was shorter than it looked.

Sources verified 2026-05-18

Sources: NIST FIPS 204 (ML-DSA), August 2024, https://doi.org/10.6028/NIST.FIPS.204; NIST FIPS 205 (SLH-DSA), August 2024, https://doi.org/10.6028/NIST.FIPS.205; NIST FIPS 206 (FN-DSA), October 2024, https://doi.org/10.6028/NIST.FIPS.206; NIST FIPS 186-5, Digital Signature Standard, https://doi.org/10.6028/NIST.FIPS.186-5; NIST IR 8547, November 2024, https://doi.org/10.6028/NIST.IR.8547; Shor, P.W., FOCS 1994, https://doi.org/10.1109/SFCS.1994.365700; Grover, L., STOC 1996, https://doi.org/10.1145/237814.237866; NSA CNSA 2.0, September 2022, https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF; Global Risk Institute 2024 Quantum Threat Timeline Report, https://globalriskinstitute.org/publication/2024-quantum-threat-timeline-report/; Regulation (EU) No 910/2014 (eIDAS); Regulation (EU) 2024/1183 (eIDAS 2, May 2024); UK SI 2019/1361 (Electronic Identification and Trust Services Regulations 2019); Data Protection and Digital Information Act 2024 (DPDIA 2024); UK Digital Identity and Attributes Trust Framework (DIATF), GOV.UK; ESIGN Act, 2000; ETSI TS 119 312; CA/Browser Forum Baseline Requirements; NIST NCCoE SP 1800-38B; NCSC March 2025.