Hybrid Post-Quantum Cryptography RFC 9794 Sovereign Deployment

Hybrid post-quantum cryptography, as formally defined by the IETF in RFC 9794 (June 2025), is the deliberate combination of at least one classical cryptographic algorithm with at least one post-quantum algorithm in a single scheme, constructed so that security holds as long as either component remains unbroken. For sovereign infrastructure operators across Europe’s public sector, finance, healthcare and legal domains, this definition is not academic: it is the practical bridge between today’s classical infrastructure and a post-quantum world, and the only technically credible response to the “harvest now, decrypt later” threat that foreign intelligence services and organised cybercriminals are already exploiting.

What RFC 9794 actually specifies and why the terminology matters

RFC 9794 does more than coin phrases. It establishes normative construction rules that prevent operators from accidentally building schemes that offer weaker guarantees than either component alone.

The document defines two structural families. In a composite scheme, the classical and post-quantum components are bound under a single algorithm identifier; they cannot be negotiated or stripped independently, which eliminates algorithm-substitution attacks at the authentication layer. In a non-composite scheme, each component keeps its own identifier and the combination is specified at the protocol layer, which is how hybrid key exchange currently works in TLS 1.3 with groups such as X25519MLKEM768. RFC 9794 also mandates that the combined shared secret be derived by feeding both component outputs into a single key derivation function, so a break in one component does not expose the other’s contribution.

For sovereign operators, precise terminology matters for a concrete reason: procurement contracts, audit reports and regulatory submissions that reference “post-quantum encryption” without specifying whether the scheme is composite or non-composite, or which KDF binds the outputs, cannot be verified by a supervisory authority. RFC 9794-aligned documentation closes that gap.

Prioritising protocol layers: where to deploy hybrid schemes first

Not every protocol layer carries equal risk, and sovereign operators have finite engineering capacity. The sequencing decision should be driven by data longevity, exposure surface and the maturity of available implementations.

NIST IR 8547 frames this clearly: data whose confidentiality must hold for more than ten years is at immediate risk from harvest-now, decrypt-later collection. That category includes patient records under the European Health Data Space (EHDS), notarial documents, long-term financial records subject to DORA retention rules, and classified government communications. The protocol layers carrying this data should move to hybrid schemes first.

TLS and SSH move first because OpenSSL 3.5, released in 2025, ships production-grade ML-KEM support and because these layers protect the widest continuous data flow. Code-signing pipelines, which determine the trustworthiness of software running on sovereign infrastructure for years, deserve early attention precisely because firmware and embedded systems cannot be patched quickly. Encrypted email is technically harder, as standardised certificate profiles for ML-DSA (FIPS 204) authentication are still being finalised through the CA/Browser Forum process.

Key management and certificate lifecycle under hybrid operation

Running hybrid ML-KEM plus X25519 key exchange in parallel with classical ECDHE across a sovereign estate creates overlapping lifecycle requirements that most existing PKI tooling was not designed to handle simultaneously.

For key exchange, no new X.509 certificates are required immediately. ML-KEM operates at the encapsulation layer, and server authentication still uses the classical certificate chain. This is operationally convenient but architecturally temporary: once ML-DSA certificate profiles are integrated into browser trust stores and CA/Browser Forum baseline requirements, sovereign operators will need to issue or migrate to dual-algorithm certificates or composite certificates as defined in RFC 9794.

NIST CSWP 39 on cryptographic agility is directly relevant here. It recommends that operators maintain a living cryptographic inventory, documenting every key type, its algorithm, its expiry, and the protocol contexts where it is used. Without this inventory, the second migration cycle from hybrid to pure-PQC will be as disruptive as moving from SHA-1 to SHA-256 was for organisations that had no asset register. Sovereign operators should treat the hybrid deployment phase as the moment to build that inventory, not a reason to defer it.

Performance implications for financial systems and clinical data exchange

A common objection from IT decision-makers in latency-sensitive environments is that post-quantum algorithms are computationally heavier than classical alternatives. The reality for ML-KEM is more nuanced.

ML-KEM-768 (the parameter set recommended for most sovereign deployments) adds approximately 1,100 bytes to a TLS handshake compared to X25519 alone, due to larger public keys and ciphertexts. On modern server hardware, the additional CPU cost is negligible: benchmarks from the OQS project show ML-KEM-768 encapsulation completing in under one microsecond on a standard x86-64 core. The network latency from the larger handshake payload is measurable but typically under five milliseconds on LAN connections, and under ten milliseconds on typical WAN links.

For financial transaction systems operating under DORA Article 9 resilience requirements, this overhead is acceptable in bulk settlement and clearing workflows. Real-time trading systems with sub-millisecond latency requirements may need to evaluate whether application-layer session resumption can reduce the frequency of full handshakes. For clinical data exchange under the EHDS, where the bottleneck is almost always application logic rather than cryptographic overhead, ML-KEM adds no practical latency concern.

The IBM Cost of a Data Breach Report 2024 recorded the global average breach cost at USD 4.88 million, the highest in the report’s history. Against that figure, the engineering cost of hybrid PQC deployment is straightforwardly justified in any formal risk treatment.

Building a regulatory evidence package for GDPR, NIS-2 and DORA

NIST’s Dustin Moody, who leads the post-quantum cryptography standardisation project, has stated plainly: “Organizations should not wait for the threat of quantum computers to become imminent before taking action. The time to prepare is now.” Supervisory authorities in the EU are beginning to echo that position.

Under GDPR Article 32, controllers must implement “appropriate technical measures” taking into account “the state of the art.” After FIPS 203 and FIPS 204 were finalised in August 2024 and after RFC 9794 was published in June 2025, hybrid PQC has become part of the state of the art for organisations handling sensitive personal data. A CISO presenting a GDPR Article 32 audit package should include: a cryptographic inventory aligned with NIST CSWP 39, a documented threat model quantifying harvest-now, decrypt-later risk per data category, evidence that deployed hybrid schemes conform to RFC 9794 construction rules, and performance test results demonstrating no degradation in availability.

NIS-2 Article 21 requires essential and important entities to implement “state-of-the-art” security measures covering encryption and incident handling. DORA Article 9 imposes specific ICT security requirements on financial entities, including resilient encryption for data in transit and at rest. ENISA has stated in its PQC guidelines that “the hybrid approach provides a security safety net: if the post-quantum algorithm turns out to have weaknesses we have not yet discovered, the classical component still protects the data.” That statement, from a body whose guidance directly informs NIS-2 supervision, supports hybrid deployment as a risk-reducing measure rather than experimental change.

NIST IR 8547 frames the timeline risk: a cryptographically relevant quantum computer could exist within ten to fifteen years. For data that must remain confidential for that duration, waiting is not a conservative choice; it is an unmanaged risk that supervisory authorities will increasingly scrutinise.

Aligning with NIST 2026 guidance and the ENISA PQC roadmap

NIST has indicated it will publish dedicated hybrid cryptography guidance, expected in 2026, covering recommended hybrid combinations, interoperability profiles and migration sequencing. ENISA’s PQC roadmap calls for EU critical infrastructure operators to have completed hybrid deployments for high-risk protocol layers by 2026 to 2027, with a transition to pure-PQC algorithms beginning thereafter.

Sovereign operators who deploy hybrid schemes now, following RFC 9794 construction rules and building the cryptographic agility infrastructure described in NIST CSWP 39, will avoid the second migration cycle. Those who wait for the 2026 NIST publication before acting will find themselves deploying hybrid schemes at exactly the moment the industry is beginning to move to pure PQC, compressing two transitions into one rushed project. The ENISA position makes clear that member state supervisory authorities will treat early hybrid deployment as evidence of proactive risk management, not gold-plating.

The practical instruction is therefore sequential and concrete: deploy OpenSSL 3.5 with X25519MLKEM768 on all internet-facing TLS endpoints this year; extend to SSH administrative access and internal service meshes within twelve months; build the cryptographic inventory now so that certificate migration to ML-DSA composite certificates can be executed without a discovery phase when CA/Browser Forum rules permit it; and document every step against RFC 9794, FIPS 203, FIPS 204 and NIST CSWP 39 in a format that a data protection authority or financial supervisor can audit without specialist interpretation.

FAQ

Is RFC 9794 mandatory for EU sovereign operators, or is it optional guidance?

RFC 9794 is an IETF standards-track document, not an EU regulation. However, ENISA references IETF standards in its PQC roadmap, and supervisory authorities under NIS-2 and DORA expect operators to follow recognised standards when implementing encryption. Adopting RFC 9794 terminology and construction rules therefore strengthens a compliance posture and is directly citable in audit evidence, even though the document is not itself enforceable.

Can OpenSSL 3.5 be used to implement RFC 9794-compliant hybrid TLS in production today?

Yes. OpenSSL 3.5 ships with production-grade ML-KEM support and enables hybrid key exchange groups such as X25519MLKEM768 in TLS 1.3. Operators should test interoperability against all client types before full rollout, because older TLS stacks that do not support hybrid groups will fall back to classical ciphers, which is acceptable behaviour but should be monitored and reported in the cryptographic inventory.

Does running hybrid ML-KEM plus X25519 require issuing new PKI certificates?

For key exchange, no new certificates are required immediately. ML-KEM operates at the encapsulation layer; server authentication continues to use classical ECDSA or RSA certificates. New composite or dual-algorithm certificates using ML-DSA (FIPS 204) will be needed when CA/Browser Forum baseline requirements are updated, which is expected to align with the NIST 2026 hybrid guidance publication.

How should a CISO document hybrid PQC deployment for a GDPR Article 32 audit?

The documentation package should contain: a cryptographic inventory mapping each data flow to its current and target algorithm (per NIST CSWP 39), a risk assessment quantifying harvest-now, decrypt-later exposure for each personal data category, evidence that deployed hybrid schemes use RFC 9794-compliant construction including a single KDF over both component outputs, and performance test results demonstrating no reduction in availability. This directly addresses the “state of the art” and “appropriate technical measures” language in Article 32.

What is the difference between a composite and a non-composite hybrid scheme under RFC 9794?

In a composite scheme, the classical and post-quantum components are bound under a single algorithm identifier and cannot be negotiated or stripped independently, which prevents algorithm-substitution attacks. This is preferred for authentication, where an adversary stripping the PQC component must not be able to downgrade to the classical signature alone. In a non-composite arrangement, each component retains its own identifier and the combination is defined at the protocol layer, which is how hybrid TLS 1.3 key exchange currently operates. RFC 9794 specifies valid construction rules for both families.