Post-quantum cryptography (PQC) performance overhead refers to the additional computational cost, network bandwidth and storage consumption that arises when replacing classical algorithms such as RSA-2048 and ECDSA P-256 with quantum-resistant alternatives standardised under the NIST 2024 framework. For European organisations operating sovereign infrastructure in regulated sectors, these costs are not abstract: they translate directly into procurement decisions, HSM specifications, network capacity contracts and long-term archival budgets.
Why Size and Speed Matter More in Sovereign Infrastructure
Sovereign deployments cannot offload cryptographic processing to hyperscaler edge networks. Every byte and every millisecond lands on hardware that the organisation owns or contractually controls, which makes rigorous capacity planning a precondition, not an afterthought.
The NIST 2024 standards, specifically NIST FIPS 203 (ML-KEM) for key encapsulation and NIST FIPS 204 (ML-DSA) for digital signatures, increase cryptographic object sizes significantly compared to their classical counterparts. ML-KEM-768 carries a public key of 1184 bytes, compared to 294 bytes for ECDH P-256. ML-DSA-65 produces signatures of 3309 bytes, against 64 bytes for ECDSA P-256. These are not minor rounding differences. They reshape bandwidth budgets, TLS handshake profiles and storage retention calculations in ways that organisations must model before deployment.
Network Capacity Planning for High-Throughput Regulated Workloads
The bandwidth increase from ML-KEM and ML-DSA is concentrated in the TLS handshake, not in the bulk payload. This distinction matters for capacity planning because it affects peak concurrency more than sustained throughput.
At a sovereign API gateway handling 10,000 concurrent TLS session establishments per second, the additional key material in each handshake multiplies across the connection burst. ETSI GR QSC 006, the ETSI performance benchmark reference for post-quantum algorithms, documents that lattice-based PQC key exchange can add between 5 ms and 20 ms of additional processing latency per handshake on constrained hardware platforms. On modern server-grade hardware the figure is lower, but it remains non-zero and must be accounted for in service-level agreements that specify sub-50 ms response times for regulated financial or healthcare APIs.
Organisations should add a PQC handshake bandwidth multiplier to their network capacity model. A practical approach: measure the current TLS handshake volume per second at peak load, calculate the additional bytes per handshake from the chosen algorithm family, and size uplink capacity to absorb that increment with at least a 30 percent headroom margin.
HSM Throughput and Sovereign Key Infrastructure Sizing
Hardware Security Modules certified to FIPS 140-3 are the anchor of sovereign key infrastructure. The migration from classical to post-quantum signing operations creates a throughput challenge that is specific to HSM hardware, because PQC signing algorithms such as ML-DSA are computationally more expensive than ECDSA on the same silicon.
Financial institutions covered by DORA Article 9 must maintain operational continuity of ICT services, including cryptographic signing pipelines for transaction settlement and audit logs. If an HSM cannot sustain the required ML-DSA signing rate under peak transaction load, it creates an operational risk exposure that prudential supervisors can cite during ICT risk assessments. The practical consequence is that existing HSM fleets sized for ECDSA workloads may need supplemental units or hardware upgrades before PQC migration is complete.
Right-sizing sovereign key infrastructure requires three inputs: the maximum signing transactions per second at peak load, the ML-DSA operations-per-second rating of the candidate HSM, and a failover factor (minimum 2x redundancy) to satisfy the availability requirements of NIS-2 Article 21. Organisations should also account for hybrid certificates during the transition period, which carry both a classical and a post-quantum signature and therefore impose a double signing load per object.
TLS Session Performance at Sovereign API Gateways
Reverse proxies and API gateways that terminate TLS for sovereign workloads, such as a Nextcloud-based workspace or a sovereign AI inference endpoint, face a specific challenge: certificate chain size and signature verification cost both increase under PQC standards.
| Algorithm | Public key size | Signature size | Relative handshake overhead vs ECDSA P-256 |
|---|---|---|---|
| ECDSA P-256 (classical) | 64 bytes | 64 bytes | Baseline |
| RSA-2048 (classical) | 256 bytes | 256 bytes | Low |
| ML-DSA-44 (FIPS 204, Level 2) | 1312 bytes | 2420 bytes | Moderate |
| ML-DSA-65 (FIPS 204, Level 3) | 1952 bytes | 3309 bytes | High |
| ML-KEM-768 (FIPS 203, Level 3) | 1184 bytes (public key) | 1088 bytes (ciphertext) | Moderate (key exchange only) |
The hybrid key exchange mechanism defined in RFC 9794 offers a viable transition path. By combining ECDH with ML-KEM in a single handshake, sovereign gateways preserve backward compatibility while immediately providing quantum-safe forward secrecy for connections to PQC-capable clients. The IETF notes in RFC 9794 that hybrid key exchange “gives implementers a practical bridge: classical security is preserved while quantum-resistant algorithms are introduced without disrupting existing interoperability.” The size penalty of hybrid mode is additive, however, so gateway hardware must be benchmarked under hybrid load, not only under pure PQC load.
Storage Overhead in Document Management and Long-Term Archival
Regulated sectors in Europe, including healthcare records under GDPR, legal documents under national procedural law and financial audit trails under DORA, require long-term archival with verifiable signatures. ML-DSA-65 signatures at 3309 bytes each represent a storage overhead that compounds across retention periods of 10 to 30 years.
For a sovereign document management system processing 500,000 signed objects per year, the annual signature storage under ML-DSA-65 exceeds 1.6 GB for signatures alone, before considering the signed documents themselves. Over a 20-year retention period, that accumulates to more than 33 GB of pure signature data, compared to under 640 MB for ECDSA P-256. Organisations must revise storage capacity contracts and retention policy documentation to reflect this overhead before PQC certificates are deployed in production.
Hybrid certificates during the transition period carry both signature types and are therefore larger still. Retention policies should specify the point at which purely classical signatures can be archived or superseded, reducing the duration of the double-storage burden.
Constrained Edge and IoT Infrastructure: Choosing the Right Algorithm
Not all sovereign infrastructure runs on server-grade hardware. Public sector deployments often include edge gateways at border crossings, healthcare monitoring devices and building management systems that connect to sovereign networks. These devices cannot absorb the full overhead of ML-DSA-65 or ML-KEM-1024.
Within the NIST 2024 standard set, ML-KEM-512 (FIPS 203 security level 1) offers the smallest key and ciphertext sizes in the ML-KEM family and is the practical choice for constrained platforms. ML-DSA-44 (FIPS 204 security level 2) is the lower-overhead signing option. In March 2025, NIST selected HQC as its fifth post-quantum algorithm, providing a code-based alternative to lattice algorithms. HQC is designed to function as a diversity hedge: if a structural weakness in lattice-based cryptography were discovered, HQC provides a backup that relies on different mathematical assumptions. For constrained sovereign edge devices, HQC’s key and ciphertext sizes are larger than ML-KEM-512 at equivalent security levels, so ML-KEM-512 remains the default for size-sensitive deployments until HQC implementations mature and hardware acceleration becomes available.
ENISA has stated in its post-quantum cryptography guidance that “migrating to post-quantum cryptography is not just a key swap. It requires organisations to reassess every component that touches cryptographic material, from HSMs and TLS terminators to long-term archives and signing pipelines.” For edge devices, this means firmware update pipelines must be validated for PQC signature verification capacity before any live deployment.
Building a PQC Performance Test Baseline into Procurement
Vendor claims about quantum-safe throughput are not standardised and are frequently reported under favourable conditions that do not reflect production sovereign workloads. Organisations should make independent performance validation a contractual condition of any infrastructure procurement that involves cryptographic processing.
A practical procurement baseline should include the following test conditions, specified in the tender document and verified before contract signature:
- ML-KEM-768 and ML-DSA-65 operations per second under sustained load equivalent to 120 percent of the projected peak workload, measured on the specific hardware configuration being procured.
- TLS handshake completion time under concurrent session load using hybrid mode as defined in RFC 9794, with both classical and PQC key exchange active simultaneously.
- HSM signing throughput for ML-DSA at the FIPS 140-3 certification level claimed, measured independently in the organisation’s own test environment or by a qualified third-party laboratory.
- Storage write and read performance under a workload that includes ML-DSA-65 signature verification for a representative sample of the organisation’s document archive.
ETSI GR QSC 006 provides a structured performance benchmark methodology that procurement teams can reference directly in tender specifications to ensure that vendor responses are comparable and independently reproducible. Citing ETSI GR QSC 006 as the required benchmark methodology also creates a documented audit trail for NIS-2 and DORA compliance reviewers who need evidence that cryptographic infrastructure procurement was conducted with quantified risk awareness.
FAQ
Does deploying ML-KEM and ML-DSA noticeably slow down HTTPS connections for end users?
For users on modern hardware and adequate bandwidth, the additional latency is typically below 20 ms per TLS handshake. The more significant concern is bulk throughput at sovereign API gateways handling thousands of concurrent sessions, where byte-level overhead accumulates and hardware termination capacity must be re-evaluated before deployment.
Which NIST-standardised PQC algorithm is best suited for constrained sovereign edge or IoT devices?
ML-KEM-512 (FIPS 203) offers the smallest key and ciphertext sizes in the ML-KEM family and is the preferred choice for constrained devices. NIST’s March 2025 selection of HQC adds a code-based option, but its implementation maturity on embedded platforms is lower than the lattice-based standards at this stage. ML-KEM-512 remains the practical default for size-sensitive sovereign edge deployments.
How does DORA affect HSM procurement decisions for post-quantum readiness in financial institutions?
DORA Article 9 requires financial entities to maintain ICT risk management controls that include cryptographic key protection. An HSM that cannot sustain the signing throughput required by transaction pipelines under ML-DSA creates an operational risk that prudential supervisors can cite. Organisations should specify minimum PQC operations-per-second in procurement contracts and validate claims against independently tested FIPS 140-3 certified hardware benchmarks, not vendor marketing figures.
What is RFC 9794 and why does it matter for sovereign infrastructure migration?
RFC 9794 specifies hybrid key exchange mechanisms that combine a classical algorithm such as ECDH with a post-quantum algorithm such as ML-KEM within a single TLS handshake. This allows sovereign infrastructure to maintain backward compatibility with existing peers while already providing quantum-safe forward secrecy. It reduces the risk of breaking interoperability during the transition period before full PQC deployment is complete across all connected systems.
How much additional archive storage should a sovereign organisation budget for PQC-signed documents?
ML-DSA-65 signatures are 3309 bytes versus 64 bytes for ECDSA P-256, a factor of more than 50. For a document management system retaining millions of signed objects over decades, this creates a storage multiplier that must be factored into retention policy reviews and capacity contracts. Organisations should audit their annual signing volume, multiply by the size differential, and add a contingency margin for hybrid certificates that carry both classical and post-quantum signature fields simultaneously during the migration period.