Post-Quantum readiness

Post-quantum readiness is the ability of a system to remain secure and trustworthy in the presence of large scale quantum computers. A strategy for post-quantum readiness should build on top of existing frameworks without requiring disruptive design changes when quantum attacks become practical.

Practically speaking, systems must ensure:

• Confidentiality is protected against Harvest Now, Decrypt Later (HNDL) attacks

• Authentication and trust do not solely depend on traditional methods that can be broken, such as RSA and ECC

• Multiple cryptographic paths can inter-operate together

Harvest Now, Decrypt Later (HNDL) attacks can capture encrypted VPN traffic today, and decrypt it later once quantum computers become viable and available for breaking current public-key cryptography. This could enable attackers to recover session secrets by breaking key exchange mechanisms and retroactively decrypt stored traffic. It may also allow the recovery of private keys used for authentication.

In IKEv2-based VPN, post-quantum readiness requires adhering to new standards around key establishments and authentication. Traditionally, IKEv2 relies on Diffie-Hellman (DH) for key exchange and RSA or ECDSA for authentication. Post-quantum readiness requires that DH be replaced or augmented with Post Quantum Cryptography (PQC) or Quantum Key Distribution (QKD). Additionally, traditional signature authentication algorithms are replaced with PQC-based signatures.

In terms of RFCs, the following enables post-quantum readiness in IKEv2:

RFC	Security Property	Effect
RFC 9370	Quantum‑safe secrecy	Introduce Key Encapsulation Mechanisms (KEMs) to IKEv2, allowing post-quantum algorithms such as ML-KEM to participate directly in the IKE_SA_INIT exchange. This effectively prevents future decryption of captured traffic. This aligns with NIST FIPS 203 (ML-KEM).
RFC 9242	Hybrid Key Exchange	Migrate to defense-in-depth by allowing multiple key exchange methods to be combined in a single IKEv2 exchange. This is typically applied using classical DH and post-quantum KEM together, effectively ensuring interoperability during migration but protecting against weaknesses of a single algorithm.
RFC 8784	Out‑of‑band entropy	This allows IKEv2 to mix an external preshared key (PPK) into the key derivation process, adding entropy and enabling integration of offline secrets or QKD-derived keys.
RFC 7427	Quantum‑safe authentication	Modernize IKEv2 signature authentication making it algorithm-agnostic rather than based on RSA or ECDSA. This effectively allows certificates with PQC public keys to be used, and post-quantum signature algorithms like ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) to be used in IKE_AUTH.

FortiGate’s post-quantum strategy for IPsec VPNs is a layered and modular approach based on the aforementioned standards. It ensures that both key establishment and authentication are protected against future quantum exploits. Furthermore, it preserves current IKEv2 interoperability, allowing companies to continue using IKEv2-based VPNs while adopting new emerging standards.

Administrators can consider a progressive adoption of the features in phases:

Phase	What administrators deploy	Standards anchor
Near term	IKEv2 + Hybrid PQC key exchange	RFC 9242, RFC 9370, FIPS 203
Authentication upgrade	PQC‑based VPN authentication	RFC 7427, FIPS 204/205
Advanced environments	QKD‑backed IPsec keys	ETSI GS QKD 014
Target state	Full hybrid (DH + PQC + QKD + PQ signatures)	Combined

For more information:

Post-Quantum Cryptography for IPsec key exchange	Explore applying PQC with classical DH for a hybrid key exchange.
Signature authentication for VPNs using Post Quantum Cryptography	Modernize IKEv2 authentication by decoupling from RSA/ECDSA and enabling post‑quantum signature algorithms for VPN authentication.
IPsec key retrieval with a QKD system	Retrieve keying material from an external QKD system, bypassing computational key exchange entirely for IPsec SAs.
Applying hybrid QKD and PQC in IPsec key establishment	Apply both PQC in hybrid key exchange and QKD together.