The NIST PQC additional digital signature standards Round 2 process, which advanced 14 candidates in October 2024, is the next frontier of post-quantum standardisation after FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). For sovereign infrastructure operators in regulated European sectors, this process is not an academic curiosity: it directly shapes which cryptographic mechanisms will be available for long-lived certificates, firmware integrity, constrained devices, and high-throughput transaction signing in the decade ahead.
The Round 2 Landscape: 14 Candidates Across Four Mathematical Families
NIST received 40 complete submissions to its additional digital signature schemes call and narrowed them to 14 candidates advancing to Round 2 in October 2024. The candidates are drawn from four distinct mathematical families: hash-based constructions, code-based schemes, multivariate polynomial systems, and isogeny-based approaches.
Each family rests on a different hard mathematical problem. Hash-based signatures such as SPHINCS+ (the basis of FIPS 205 SLH-DSA) derive security from properties of one-way functions rather than algebraic structure. Code-based schemes rely on the difficulty of decoding random linear codes. Multivariate systems build on the hardness of solving systems of polynomial equations over finite fields. Isogeny-based approaches use the difficulty of finding paths between elliptic curve isogenies, though this family has faced significant scrutiny since the 2022 break of SIKE.
The 14 Round 2 candidates include schemes with widely varying performance profiles. Some are optimised for signature compactness, relevant for certificate chains and bandwidth-constrained channels. Others prioritise signing speed, relevant for high-throughput transaction environments. NIST’s evaluation criteria explicitly balance security, performance, and implementation simplicity, and the final selection may advance two or three algorithms rather than a single winner.
How a Cryptographic Bill of Materials and Crypto-Agility Architecture Must Account for This
A cryptographic bill of materials (CBOM) is the prerequisite for any meaningful PQC migration. Without a current inventory of every algorithm, key length, protocol version, and library dependency in production, an organisation cannot assess which systems will be affected when NIST finalises additional signature standards, currently projected for 2027 following planned 2026 draft releases for public comment.
ENISA has stated clearly: “Migrating to post-quantum cryptography is not a one-time event but a continuous process; organisations must build cryptographic agility into their systems from the start.” This framing has concrete architectural implications. A crypto-agile system separates algorithm selection from application logic, exposes negotiation parameters as configuration rather than hard-coded constants, and supports simultaneous operation of multiple algorithm suites during transition periods.
For sovereign infrastructure operators, the CBOM must distinguish three tiers of cryptographic use: classical algorithms still in use (RSA, ECDSA, ECDH); currently standardised PQC algorithms (ML-DSA per FIPS 204, SLH-DSA per FIPS 205, ML-KEM per FIPS 203); and pipeline algorithms (Round 2 additional signature candidates) whose standardisation is expected but not yet final. Each tier requires a different treatment in migration roadmaps and procurement requirements.
| Algorithm tier | Examples | Production status | Action required now |
|---|---|---|---|
| Classical (quantum-vulnerable) | RSA-2048, ECDSA P-256 | Approved but deprecated trajectory | Inventory, plan replacement by 2030 |
| PQC standardised | FIPS 204 ML-DSA, FIPS 205 SLH-DSA | Deploy in hybrid mode | Mandate in new systems and procurement |
| PQC pipeline | Round 2 additional signature candidates | Test environments only | Evaluate in pre-production, prepare CBOM entries |
Use Cases Where Additional Signature Standards Are Expected to Outperform FIPS 204 and FIPS 205
FIPS 204 ML-DSA and FIPS 205 SLH-DSA are not equally suited to every context. ML-DSA offers fast signing but produces relatively large signatures (around 2.4 KB at security level 3). SLH-DSA produces smaller public keys but significantly larger signatures and is slower to sign. The Round 2 candidates are being evaluated partly because different deployment environments have requirements that neither current standard fully satisfies.
Four use cases illustrate where the additional standards are expected to add value:
Long-lived certificates: Root CA certificates may have validity periods of ten to twenty years. The signature algorithm embedded in such a certificate must remain secure across that full period. Some Round 2 candidates offer smaller signature sizes that reduce certificate chain overhead without sacrificing long-term security, which matters for TLS handshake performance in latency-sensitive government services.
Firmware signing: Embedded devices often have constrained storage for firmware images and update packages. Several multivariate and code-based candidates in Round 2 are being assessed specifically for small signature footprints that fit within bootloader verification constraints that neither ML-DSA nor SLH-DSA comfortably meets.
Constrained IoT and operational technology devices: Medical devices, smart meters, and industrial controllers under NIS-2 scope frequently have limited RAM and processing cycles. Some hash-based and code-based Round 2 candidates are optimised for low-memory signing operations, which is architecturally incompatible with ML-DSA’s working memory requirements.
High-throughput transaction signing: Financial market infrastructure covered by DORA may process tens of thousands of signed transactions per second. Round 2 candidates with faster signing speeds than SLH-DSA and smaller signatures than ML-DSA are being evaluated for this context, where signature overhead is a direct operational cost.
The EU PQC Transition Roadmap 2026-2030 and What It Requires Today
The EU PQC Transition Roadmap 2026-2030 sets an expectation that regulated-sector organisations begin procuring PQC-capable systems in the 2026 window and complete migration of critical systems by 2030. The roadmap explicitly acknowledges that standardisation is still evolving beyond the first FIPS publications, which means it anticipates that additional signature standards will emerge during the roadmap period.
For procurement officers and CISOs in public sector, finance, and healthcare, this creates concrete obligations now rather than in 2026. Tender specifications for PKI systems, HSMs, and identity platforms purchased today must include requirements for vendor roadmap commitments covering FIPS 204, FIPS 205, and support for additional signature algorithms as they are standardised. A vendor who cannot articulate how they will deliver algorithm updates is a liability under the roadmap’s migration timeline.
The roadmap also intersects with DORA’s ICT risk management requirements for financial entities and with NIS-2’s supply-chain security obligations. An essential entity under NIS-2 that has not assessed its cryptographic dependencies against the PQC transition timeline is arguably already non-compliant with Article 21’s risk management measures, which require organisations to address “state of the art” security practices.
ENISA, BSI, and ANSSI Guidance on Testing Non-Standardised Candidates Safely
BSI TR-02102 Cryptographic Mechanisms states directly that for systems requiring long-term security, quantum-resistant algorithms should be deployed immediately: “Für langfristig sicher eingestufte Systeme sind quantencomputerresistente Verfahren ab sofort einzusetzen.” BSI’s guidance does not endorse deploying non-standardised candidates in production but supports their evaluation in controlled environments to prepare migration plans.
ENISA’s post-quantum cryptography guidelines similarly recommend that non-standardised candidates be tested in isolated pre-production environments, with findings documented in the organisation’s cryptographic risk register. ANSSI (the French national cybersecurity agency) has published hybrid deployment recommendations that apply the same logic: pair a classical algorithm with a standardised PQC algorithm in production, and use test environments to evaluate pipeline candidates against your specific performance and integration requirements.
The practical structure for a sovereign operator’s test programme should include: a dedicated PKI test hierarchy that mirrors the production hierarchy but uses Round 2 candidate algorithms; automated regression testing to measure signature size, signing latency, and verification latency against application-level SLAs; and a formal process to promote test results into CBOM entries once a candidate reaches standardisation.
Writing PKI Policies and Key Management Procedures for 2027 Readiness
Certificate Policy (CP) and Certification Practice Statement (CPS) documents written today need to anticipate algorithm transitions that will occur before their next scheduled major revision. The key mechanism is an explicit algorithm agility clause that defines rollover procedures for existing certificate hierarchies when new algorithms are approved.
A sovereign PKI policy should specify: which algorithms are approved at each assurance level at time of publication; a named process for emergency algorithm replacement triggered by a NIST or ENISA advisory; maximum certificate validity periods that account for the expected PQC transition timeline (for most regulated-sector issuers, validity periods beyond 2030 should already be scrutinised); and a CBOM update obligation triggered by any new FIPS publication within sixty days of release.
Key rollover for a root CA that currently signs with ECDSA P-384 should be planned in two stages. The first stage, deployable now, introduces a parallel ML-DSA (FIPS 204) root and begins issuing dual-signed (hybrid) subordinate CA certificates. The second stage, triggered by finalisation of relevant Round 2 candidates, evaluates whether the new algorithm offers a material advantage for the operator’s specific use cases before promoting it into the hierarchy. This staged approach avoids the operational risk of a forced cutover while maintaining forward compatibility.
IBM’s 2024 Cost of a Data Breach Report put the average global breach cost at USD 4.88 million, the highest figure in the report’s history. For sovereign infrastructure operators, a cryptographic failure in a PKI hierarchy does not merely expose data: it can invalidate the entire trust chain for digital signatures across an organisation’s services, multiplying the operational and regulatory cost well beyond a single breach event. The investment in CBOM maintenance and algorithm-agile PKI policy is measurably cheaper than that outcome.
FAQ
Which four mathematical families are represented among the 14 NIST PQC additional signature Round 2 candidates?
The 14 candidates span hash-based constructions, code-based schemes, multivariate polynomial systems, and isogeny-based approaches. This diversity is deliberate: if a structural weakness is discovered in one family, the others remain unaffected, giving sovereign operators a credible fallback.
When will NIST publish draft standards for the additional signature candidates?
NIST has indicated it plans to release draft standards for public comment in 2026, with final standards projected around 2027. Organisations should track the NIST CSRC project page directly, as timelines can shift based on cryptanalytic findings during the evaluation period.
Can regulated-sector organisations in the EU use Round 2 candidates in production systems now?
No. ENISA and BSI both advise that non-standardised candidates should be confined to test and pre-production environments. Production systems should rely on FIPS 204 ML-DSA or FIPS 205 SLH-DSA, ideally deployed in hybrid mode alongside classical algorithms such as ECDSA P-384, until additional standards are finalised.
What is a cryptographic bill of materials and why does it matter for PQC transition?
A CBOM is an inventory of every cryptographic algorithm, key length, protocol version, and library dependency used across an organisation’s systems. Without a current CBOM it is impossible to know which systems must be updated when new standards are finalised, making agile migration planning effectively impossible and leaving organisations unable to demonstrate NIS-2 or DORA compliance.
How does the EU PQC Transition Roadmap 2026-2030 affect procurement decisions today?
The roadmap sets expectations that regulated-sector organisations begin PQC-capable procurement in the 2026 window. Procurement officers should already require vendors to demonstrate roadmap support for FIPS 204, FIPS 205, and planned additional standards in tender requirements, so that systems bought today will not need full replacement when the additional signature standards are finalised around 2027.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.
