Quantum-Safe FortiGate: A Practical Guide to Post-Quantum Cryptography in FortiOS

The cryptography that protects your VPN traffic today was not designed with quantum computers in mind. RSA and elliptic-curve cryptography rely on math problems that classical computers cannot solve in a reasonable time, but a sufficiently powerful quantum computer running Shor’s algorithm would break them quickly. The exact arrival date of such a machine is unknown, with industry estimates pointing somewhere in the next decade or so, but the threat is already here in a quieter form.

Attackers do not need a working quantum computer to start causing damage. They can simply record encrypted traffic now and store it until quantum hardware becomes available. This is the “Harvest Now, Decrypt Later” (HNDL) attack, and it puts any long-lived sensitive data at risk today: customer financial records, health information, intellectual property, government communications, and anything else that still needs to be confidential five or ten years from now.

Fortinet has responded by building quantum-safe capabilities directly into FortiOS. This post explains what FortiGate supports, when to deploy it, when to hold off, the limitations you should plan around, and how it interoperates with the rest of your environment. It closes with three practical configuration walkthroughs covering site-to-site VPN, remote access VPN, and clientless (agentless) VPN.

Two strategies, one platform

Fortinet’s quantum-safe story rests on two distinct technologies, plus the ability to combine them.

Post-Quantum Cryptography (PQC) is a software-based defense. It replaces or supplements the vulnerable key exchange with new algorithms built on math problems believed to resist both classical and quantum attack. PQC scales easily because it needs no special hardware, and it is the approach most organizations will adopt first.

Quantum Key Distribution (QKD) takes a different route. It uses the laws of physics rather than mathematical hardness, distributing keys over dedicated hardware, often fiber-based, in a way that makes eavesdropping physically detectable. QKD provides very strong guarantees but requires specialized infrastructure and is therefore reserved for the highest-sensitivity environments.

FortiGate supports both, and it also supports a hybrid mode that mixes keys from PQC, QKD, and traditional Diffie-Hellman in a single security association. The hybrid philosophy is the most important design choice to understand, so it is worth pausing on.

Why hybrid is the safe default

The PQC algorithms standardized by NIST are new. ML-KEM, the lattice-based key encapsulation mechanism standardized as FIPS 203, has had significant cryptanalytic scrutiny, but it has nowhere near the decades of battle-testing that RSA and elliptic-curve cryptography enjoy. Other candidates such as BIKE, HQC, and FRODO are even less mature.

Hybrid key exchange solves this trust problem elegantly. Instead of betting everything on a single new algorithm, FortiGate performs the classical Diffie-Hellman exchange and one or more post-quantum key exchanges, then combines the resulting secrets. The tunnel is secure as long as at least one of the methods holds. If a future weakness is found in ML-KEM, the classical exchange still protects you against a classical attacker. If a quantum computer breaks the classical exchange, the post-quantum component still protects you. You lose security only if every method fails at once, which is a far stronger position than relying on any one algorithm.

This is why, for almost every deployment, the recommendation is to run PQC in hybrid mode rather than in a pure post-quantum configuration.

How FortiGate implements PQC for IPsec

PQC for IPsec key exchange was introduced as a new feature in FortiOS 7.6.1 and has carried forward through the 7.6 train and into 8.0. The implementation follows current IETF standards rather than a proprietary scheme, which matters for interoperability.

The mechanism is hybrid key exchange per RFC 9370, which extends IKEv2 so that a single IKE security association establishment can carry multiple key exchanges. RFC 9242 supplies the IKE_INTERMEDIATE exchange used to carry the extra key exchanges during initial SA setup, and IKE_FOLLOWUP_KE handles additional key exchanges when the IKE SA is rekeyed or when additional child SAs are created in IKEv2 Phase 2.

In addition to the classic Diffie-Hellman group, FortiOS lets you add one or more post-quantum Key Encapsulation Mechanisms (KEMs). The supported families are ML-KEM (the standardized algorithm formerly known as Kyber), BIKE, HQC, and FRODO. You configure these as “additional key exchanges,” and FortiOS gives you considerable room to layer them: you can choose up to three KE groups in each round, and up to seven rounds total, exposed in the CLI as the parameters addke1 through addke7.

A practical note on standards compliance: while FortiOS lets you select any of the supported mechanisms, only the ML-KEM groups are NIST-standardized and FIPS 203 compliant. ML-KEM comes in three parameter sets, ML-KEM-512, ML-KEM-768, and ML-KEM-1024, which trade performance against security level. If regulatory compliance is a requirement, build your design around ML-KEM and treat BIKE, HQC, and FRODO as optional experimental additions rather than primary protection.

How FortiGate implements PQC for SSL and clientless VPN

PQC for the SSL VPN path, including the agentless (clientless) browser-based VPN, arrived later, in FortiOS 7.6.5. This enhancement upgraded the underlying OpenSSL library to version 3.5, which is what enables post-quantum algorithm support in the TLS 1.3 handshake.

For the TLS path, FortiOS exposes a configurable list of TLS groups. The supported groups span three categories: traditional elliptic curves (P-256, P-384, P-521), finite-field Diffie-Hellman (FFDHE2048 through FFDHE8192), pure PQC groups (ML-KEM512, ML-KEM768, ML-KEM1024), and hybrid combinations such as X25519-MLKEM768 and P-384-MLKEM1024. The hybrid groups are the ones to favor, for the same defense-in-depth reasons described earlier, and they also align with what modern browsers negotiate by default.

There is an important constraint here. The PQC TLS groups are currently unavailable in FIPS-CC mode, pending FIPS 140-3 validation of the relevant algorithms. If you run a strict FIPS-CC deployment, you cannot yet use PQC on the SSL VPN path. This is a temporary state tied to certification timelines, not a permanent limitation, but it must be accounted for in regulated environments today.

QKD and full hybrid

QKD integration was introduced earlier than PQC, in FortiOS 7.4, allowing FortiGate to retrieve IPsec keys from a QKD system through standardized interfaces so that it can interoperate with various QKD technology providers.

FortiOS 7.6.3 brought the pieces together. From that release, FortiGate can apply QKD, PQC, and Diffie-Hellman together, mixing all three key types when establishing the IKE SA and IPsec SA. The same release added configuration support for combining QKD with Digital Signature Algorithm and PQC. The practical result is that an organization with QKD infrastructure can layer it on top of PQC and classical key exchange for maximum resilience, with the tunnel remaining secure as long as any single method holds.

Version timeline at a glance

FortiOS version	Quantum-safe capability introduced
7.4	QKD integration for IPsec key retrieval
7.6.1	PQC for IPsec key exchange (hybrid KEM, RFC 9370)
7.6.3	Combined QKD, PQC, and DHE hybrid; QKD and DSA-PQC configuration
7.6.5	PQC for SSL and agentless VPN (OpenSSL 3.5, ML-KEM TLS groups)
7.6.6 and 8.0	Capabilities carried forward and maintained

A clear takeaway from this timeline: the IPsec path is the most mature and should be your starting point, while the SSL VPN path is newer and still working through FIPS validation.

When to use FortiGate PQC

There is rarely a strong reason to delay enabling PQC, because the hybrid design means it adds protection without removing the classical security you already trust. That said, some scenarios make it a clear priority.

Deploy PQC when you handle data with a long confidentiality lifetime. If traffic intercepted today would still be damaging if decrypted in 2035, the HNDL threat applies directly to you. This covers financial services moving account numbers and card data, healthcare organizations handling patient records, legal and M&A work, defense and government communications, and any custodian of intellectual property or trade secrets.

Deploy it when you have compliance momentum. Regulators and standards bodies are steadily moving toward quantum-readiness expectations, and several national security agencies have published migration timelines. Enabling PQC now positions you ahead of mandates rather than scrambling to catch up.

Deploy it on site-to-site tunnels first. These are typically gateway-to-gateway between equipment you control on both ends, which removes client-side compatibility concerns and makes them the lowest-risk place to gain operational experience.

Deploy it when both tunnel endpoints support the feature. Because PQC for IPsec depends on RFC 9370, both peers must understand the hybrid key exchange. Two FortiGates on a recent FortiOS release are an ideal pairing.

When to be cautious or hold off

PQC is not free of trade-offs, and a few situations call for a measured approach.

Be cautious in strict FIPS-CC SSL VPN deployments. As noted above, PQC TLS groups are not available in FIPS-CC mode yet. If you are bound to FIPS-CC for your clientless or SSL VPN, you will need to wait for FIPS 140-3 validation or confine PQC to the IPsec path.

Account for interoperability with non-FortiGate peers. If the device on the other end of an IPsec tunnel is from another vendor, or runs an older FortiOS, it may not support RFC 9370 hybrid key exchange. In that case the tunnel will fall back to classical key exchange, or fail to negotiate if you have configured PQC too rigidly. Always verify the far-end capability before committing.

Plan for larger handshakes. Post-quantum KEMs have substantially larger public keys and ciphertexts than elliptic-curve cryptography. This inflates the size of IKE and TLS handshake messages. The negotiation phase uses more bandwidth and can be more sensitive to network path issues, particularly UDP fragmentation on the IKE path. Bulk data throughput is generally unaffected because the symmetric encryption of the tunnel itself does not change, but the connection setup deserves testing.

Test before mass client rollout. Remote access and clientless VPN involve endpoints and browsers you may not fully control. Pilot with a representative group before enabling PQC broadly, and confirm that your client software, FortiClient version, or browser negotiates the post-quantum groups as expected.

Treat non-standardized algorithms as experimental. BIKE, HQC, and FRODO are supported, but they are not NIST-standardized. Use ML-KEM as your primary algorithm and add the others only with a clear, deliberate reason.

Limitations and design considerations

A few points are worth keeping on a checklist as you plan a rollout.

PQC for IPsec requires IKEv2. IKEv1 is not supported for the hybrid key exchange, so any tunnel you want to protect must be migrated to IKEv2 first.

Both endpoints must support the feature. This bears repeating because it is the single most common cause of failed PQC negotiation. A PQC-configured FortiGate talking to a peer that does not understand RFC 9370 will not get post-quantum protection on that tunnel.

Larger packets can expose path problems. Where IKE messages were previously small, post-quantum handshakes can push them well past common MTU thresholds. FortiOS supports IKE fragmentation per RFC 7383, and it is enabled by default, but environments with intermediate firewalls or ISPs that mishandle fragmented UDP can still see tunnels fail to establish. If you see negotiation failures after enabling PQC, fragmentation handling is the first thing to investigate.

FIPS validation is still in progress for parts of the stack. ML-KEM is FIPS 203 standardized, but the broader FIPS 140-3 module validation that gates FIPS-CC mode is ongoing. Regulated deployments should track Fortinet’s validation status rather than assume current availability.

The classical components remain in place. This is a feature, not a flaw, but it is worth stating plainly: hybrid mode does not remove RSA, elliptic-curve, or classical Diffie-Hellman. Your tunnels keep their existing security and gain a new layer on top.

Compatibility with the rest of your environment

FortiGate’s PQC implementation was deliberately built on open IETF standards (RFC 9370, RFC 9242, RFC 7383) rather than a proprietary protocol. The benefit is that any other vendor’s equipment implementing the same RFCs can negotiate hybrid post-quantum key exchange with a FortiGate. The practical caveat is that support across the industry is uneven and still maturing, so real-world interoperability must be verified per peer rather than assumed.

For the SSL and clientless VPN path, FortiGate’s reliance on TLS 1.3 with standard PQC and hybrid groups means it aligns with the direction major browsers are taking. Recent versions of mainstream browsers already negotiate hybrid groups such as X25519-MLKEM768, which is what makes clientless PQC viable without any software install on the user’s machine.

Within the Fortinet ecosystem, the quantum-safe features are available across FortiGate NGFW and Fortinet Secure SD-WAN at no additional licensing cost, because they ship as part of FortiOS. SD-WAN overlays are built on IPsec, so the same PQC configuration applies to SD-WAN tunnels. FortiManager can be used to push consistent PQC configuration across a large fleet of FortiGates, which is the realistic way to roll this out at scale.

The general interoperability rule is simple. FortiGate to FortiGate on a recent FortiOS release is the smoothest path. FortiGate to another standards-compliant vendor is possible but should be lab-tested. FortiGate to a legacy or non-compliant peer will fall back to classical cryptography, so plan those tunnels accordingly.

Use case and walkthrough 1: Site-to-site VPN for a financial institution

Scenario. A regional bank runs an IPsec VPN between its data center and a disaster-recovery site. The tunnel carries account numbers, card data, and other records that must stay confidential for many years. Both ends terminate on FortiGate firewalls running a recent FortiOS 7.6 release. This is the ideal first PQC deployment: both endpoints are controlled, both are FortiGates, and the data has a long confidentiality lifetime.

Goal. Add hybrid post-quantum protection to the existing tunnel without removing the classical key exchange.

Approach. Configure a standardized ML-KEM group as the first additional key exchange round, keep a classical Diffie-Hellman group in the proposal, and apply matching settings on both peers. The example uses ML-KEM as the post-quantum component and keeps a strong classical group so the result is genuinely hybrid.

You can configure this in the GUI by going to VPN > IPsec Tunnels, editing the tunnel, and scrolling to the Post Quantum Cryptography Additional Key Exchanges section, where you click Create new, set the transform type, and select up to three KE groups per round. The CLI is shown below because it is precise and easy to replicate on both peers. KE group ID numbers vary slightly between FortiOS releases, so confirm the correct ML-KEM group IDs against the administration guide for your exact version before applying.

Phase 1 on the HQ FortiGate:

config vpn ipsec phase1-interface
edit "ipsec-HQ-Branch"
      set interface "BlogVLAN"
      set ike-version 2
      set local-gw 12.1.1.1
      set authmethod signature
      set net-device disable
      set proposal aes256gcm-prfsha384 aes256-sha384
      set dhgrp 21
      set addke1 36 37
      set addke2 1083
      set childless-ike enable
      set transport auto
      set remote-gw 12.1.1.2
      set certificate "fgt-hq-vpn"
      set peer "peer-branch-cert"
   next
end

What each line does

• edit "ipsec-HQ-Branch" creates a route-based IPsec tunnel interface with that name. The same name will appear under config system interface after this command completes.
  • Note: We are using the previous tunnel from the  previous certificate-based IPsec Tunnel article.
• set interface BlogVLAN binds the tunnel to the port5 interface. Phase 1 traffic (UDP 500/4500) will source from this interface’s IP.
• set local-gw 12.1.1.1 forces the local gateway to use a particular IP
• set ike-version 2 forces IKEv2. PQC hybrid key exchange is only defined for IKEv2; IKEv1 will reject the new transform types.
• set peertype any allows the remote peer to identify itself by IP rather than requiring a specific certificate DN or user-FQDN.
• set net-device disable uses the modern interface-based tunnel model where one logical interface represents the tunnel, simplifying routing.
• set proposal aes256gcm-prfsha384 aes256-sha384 defines the symmetric ciphers and integrity algorithms for the IKE SA itself. AES-GCM-256 with SHA-384 PRF is FIPS-aligned and post-quantum-aware (AES-256 keeps 128-bit security under Grover).
• set dhgrp 21 specifies the classical Diffie-Hellman groups used in IKE_SA_INIT. Group 21 (NIST P-512 ECDH) is preferred (The Gold Standard).
• set addke1 36 37 first round of post-quantum Additional Key Exchange. Group 36 is ML-KEM-768 (preferred) and 37 is ML-KEM-1024 (fallback if the peer prefers it). FortiOS will negotiate the highest mutually supported option.
• set addke2 Frodo-l1 (on FortiOS 8.0 however on 7.6.6 its 1083) second round of PQ key exchange using a different KEM family (a Fortinet-assigned identifier for a code-based or alternate lattice KEM). This is what gives the tunnel crypto-agility: if a future cryptanalytic result weakens ML-KEM, this round still contributes secure keying material.
• set childless-ike enable creates the IKE SA without immediately creating a child SA. This is required when using IKE_INTERMEDIATE for additional key exchanges, because child SAs are established later via CREATE_CHILD_SA.
• set transport auto automatically selects UDP 500 and switches to UDP 4500 if NAT is detected (NAT-Traversal).
• set remote-gw 12.1.1.1 the public IP of the branch FortiGate.
• set certificate "fgt-br-vpn" – This defines the certificate for remote certificate I am expecting.
• set peer "peer-hq-cert" defines the CA certificate that should have signed the above certificate.

Phase 2 on the same FortiGate:

config vpn ipsec phase2-interface
   edit "p2-HQ-Branch"
      set phase1name "ipsec-HQ-Branch"
      set proposal aes256gcm
      set dhgrp 20 21
      set addke1 36 37
   next
end

What each line does

• edit "p2-HQ-Branch" names the Phase 2 selector. Each tunnel can have multiple Phase 2 selectors for different subnet pairs.
• set phase1name"ipsec-HQ-Branch ties this Phase 2 to the Phase 1 we created in step 2.
• set proposal aes256gcm the ESP encryption proposals. AES-GCM provides authenticated encryption in a single pass; no separate integrity algorithm is needed.
• set pfs enable enables Perfect Forward Secrecy. Every time the Phase 2 SA is rekeyed, a fresh DH and KEM exchange occurs, so compromise of one session key never compromises others (only visible with the show full command)
• set dhgrp 21 classical DH groups for the Phase 2 PFS exchange.
• set addke1 36 post-quantum KEM for Phase 2 PFS. Using ML-KEM-768 here ensures each child SA rekey injects fresh quantum-safe keying material into the data SA

Phase 1 on the BRANCH FortiGate:

config vpn ipsec phase1-interface
   edit "ipsec-Branch-HQ"
      set interface "port5"
      set ike-version 2

      set peertype any
      set local-gw 12.1.1.2
      set authmethod signature
      set net-device disable
      set proposal aes256gcm-prfsha384 aes256-sha384
      set dhgrp 20 21
      set addke1 ml-kem-768 ml-kem-1024
      set addke2 frodo-l1
      set childless-ike enable
      set transport auto
      set remote-gw 12.1.1.1
      set certificate "fgt-br-vpn"
      set peer "peer-hq-cert"
  next
end

What each line does

• edit "ipsec-Branch-HQ" creates a route-based IPsec tunnel interface with that name. The same name will appear under config system interface after this command completes.
  • Note: We are using the previous tunnel from the  previous certificate-based IPsec Tunnel article.
• set interface port5 binds the tunnel to the port5 interface. Phase 1 traffic (UDP 500/4500) will source from this interface’s IP.
• set local-gw 12.1.1.2 forces the local gateway to use a particular IP
• set ike-version 2 forces IKEv2. PQC hybrid key exchange is only defined for IKEv2; IKEv1 will reject the new transform types.
• set peertype any allows the remote peer to identify itself by IP rather than requiring a specific certificate DN or user-FQDN.
• set net-device disable uses the modern interface-based tunnel model where one logical interface represents the tunnel, simplifying routing.
• set proposal aes256gcm-prfsha384 aes256-sha384 defines the symmetric ciphers and integrity algorithms for the IKE SA itself. AES-GCM-256 with SHA-384 PRF is FIPS-aligned and post-quantum-aware (AES-256 keeps 128-bit security under Grover).
• set dhgrp 21 specifies the classical Diffie-Hellman groups used in IKE_SA_INIT. Group 21 (NIST P-512 ECDH) is preferred (The Gold Standard).
• set addke1 36 37 first round of post-quantum Additional Key Exchange. Group 36 is ML-KEM-768 (preferred) and 37 is ML-KEM-1024 (fallback if the peer prefers it). FortiOS will negotiate the highest mutually supported option.
• set addke2 Frodo-l1 (on FortiOS 8.0 however on 7.6.6 its 1083) second round of PQ key exchange using a different KEM family (a Fortinet-assigned identifier for a code-based or alternate lattice KEM). This is what gives the tunnel crypto-agility: if a future cryptanalytic result weakens ML-KEM, this round still contributes secure keying material.
• set childless-ike enable creates the IKE SA without immediately creating a child SA. This is required when using IKE_INTERMEDIATE for additional key exchanges, because child SAs are established later via CREATE_CHILD_SA.
• set transport auto automatically selects UDP 500 and switches to UDP 4500 if NAT is detected (NAT-Traversal).
• set remote-gw 12.1.1.1 the public IP of the branch FortiGate.
• set certificate "fgt-br-vpn" – This defines the certificate for remote certificate I am expecting.
• set peer "peer-hq-cert" defines the CA certificate that should have signed the above certificate.

Phase 2 on the same FortiGate:

config vpn ipsec phase2-interface
    edit "p2-HQ-Branch"
       set phase1name "ipsec-HQ-Branch"
       set proposal aes128-sha1 aes256-sha1 aes128-sha256 aes256-sha256                  aes128gcm aes256gcm chacha20poly1305
       set dhgrp 20 21
       set addke1 36 37
    next
end

On the disaster-recovery FortiGate, apply an identical configuration, changing only the tunnel-specific values such as remote-gw, the interface name, and any local identifiers. The dhgrp 20 line keeps a classical elliptic-curve Diffie-Hellman exchange in play, while addke1 adds the ML-KEM post-quantum exchange on top, producing the hybrid result. The childless-ike enable setting supports the intermediate-exchange behavior the hybrid handshake relies on.

Verification. Bring the tunnel down and back up, then run the IKE debug to confirm the post-quantum group is negotiated:

diagnose debug application ike -1
diagnose debug enable

In the output, look for the negotiated proposal to include both a classical DH_GROUP value and an ADDKE1 value showing an ML-KEM group. Seeing both confirms the exchange is genuinely hybrid. Turn debugging off afterward with diagnose debug disable.

Result. The disaster-recovery tunnel now resists both classical attackers and the harvest-now-decrypt-later threat, with no change to bulk throughput and no loss of the bank’s existing classical protection.

Use case and walkthrough 2: Remote access (dial-up) VPN

Scenario. An enterprise provides remote employees with IPsec VPN access into the corporate network. The remote access tunnel is a dial-up (dynamic) IPsec configuration on the FortiGate, and the client side uses a current FortiClient version that supports hybrid key exchange. The company wants quantum-safe protection for remote sessions, which carry the same sensitive internal traffic as on-site users.

Goal. Enable hybrid PQC on the dial-up IPsec tunnel while keeping classical key exchange, and roll it out carefully because the client population is larger and less uniform than a site-to-site pair.

Approach. The dial-up phase 1 is configured as a dynamic type that accepts incoming clients. PQC is added the same way as for site-to-site, with addke1 carrying the ML-KEM group, but the rollout sequence matters more here. The FortiGate must support the post-quantum group, and so must every client; mismatched clients will either fall back or fail to connect, so a pilot group comes first.

Phase 1 (dial-up server side) on the FortiGate:

config vpn ipsec phase1-interface
    edit "remote-access"
        set type dynamic
        set interface "wan1"
        set ike-version 2
        set peertype any
        set net-device enable
        set mode-cfg enable
        set proposal aes256-sha256 aes256gcm-prfsha384
        set dhgrp 20
        set addke1 <ML-KEM-768 group id for your FortiOS version>
        set childless-ike enable
        set ipsec-interface-mtu 1400
        set psksecret <pre-shared-key>
    next
end

Phase 2 (dial-up server side):

config vpn ipsec phase2-interface
    edit "remote-access"
        set phase1name "remote-access"
        set proposal aes256-sha256 aes256gcm
        set addke1 <ML-KEM-768 group id for your FortiOS version>
    next
end

On the client side, the FortiClient profile must use IKEv2 and be a version that supports hybrid post-quantum key exchange. Where FortiClient exposes the additional key exchange settings, select the matching ML-KEM group so the client offer aligns with the FortiGate. If FortiClient negotiates the post-quantum groups automatically, simply confirm it is a current release.

Rollout sequence. Because remote endpoints are diverse, stage the change. First, enable PQC on a test phase 1 used only by a pilot group, and confirm those users connect cleanly. Second, watch for negotiation failures, paying particular attention to clients on networks that mishandle fragmented UDP, since the larger post-quantum handshake is more likely to fragment. The ipsec-interface-mtu setting and FortiOS’s default IKE fragmentation help here, but path problems still surface in the field. Third, once the pilot is stable, extend the configuration to the production dial-up phase 1.

Verification. From the FortiGate, inspect an established dial-up session and confirm the negotiated proposal includes an ADDKE1 ML-KEM value alongside the classical DH_GROUP. The same diagnose debug application ike -1 approach used for site-to-site applies, filtered to the remote-access tunnel.

Result. Remote employee sessions gain post-quantum protection. The staged rollout contains the risk that a subset of clients cannot negotiate the new groups, and the classical Diffie-Hellman component guarantees that even a client that only partially supports the configuration is no worse off than before.

Use case and walkthrough 3: Clientless (agentless) VPN

Scenario. An organization offers browser-based access to internal web applications for contractors and partners who cannot install VPN software. This is the FortiGate agentless VPN, which terminates a TLS 1.3 session from the user’s browser. The organization wants quantum-safe protection on these sessions but is not bound by strict FIPS-CC mode, which is the necessary condition for using PQC on this path today.

Goal. Enable post-quantum TLS groups on the agentless VPN so that browser sessions negotiate a hybrid handshake, with no software install required on the user side.

Prerequisites. The FortiGate must run FortiOS 7.6.5 or later, since that release added PQC for agentless VPN and the OpenSSL 3.5 upgrade that makes it possible. The deployment must not be in FIPS-CC mode, because PQC TLS groups are unavailable there pending FIPS 140-3 approval. Users should be on a current browser version that supports hybrid groups such as X25519-MLKEM768, which recent mainstream browsers negotiate by default.

Approach. Agentless VPN PQC is configured through the SSL settings, where you specify the list of TLS groups the FortiGate will offer. Include hybrid groups so the handshake is defense-in-depth, and you may include pure PQC and classical groups for broad client compatibility. The FortiGate will pick the strongest group both sides support.

config vpn ssl settings
    set tls-groups X25519-MLKEM768 P-384-MLKEM1024 P-256-MLKEM768 X25519 ML-KEM768 ML-KEM1024
end

Listing the hybrid groups first expresses a preference for hybrid key exchange, while keeping a classical group such as X25519 in the list ensures that an older browser which does not understand the post-quantum groups can still connect over a classical handshake. This graceful fallback is what makes the change low-risk for a mixed contractor and partner audience.

Verification. From a current browser, connect to the agentless VPN portal and inspect the TLS handshake. In a packet capture or the browser’s security panel, the negotiated key share should show a hybrid group such as X25519MLKEM768. On the FortiGate side, the server hello reflects the group it selected. Seeing a hybrid group confirms the browser session is quantum-safe.

Result. Contractors and partners reach internal applications over a post-quantum-protected TLS session, with nothing to install. Older browsers fall back to classical groups automatically, so the rollout does not lock anyone out. When the organization later needs FIPS-CC mode, it will need to revisit this configuration once Fortinet completes FIPS 140-3 validation for the PQC groups.

Putting it together: a recommended adoption path

For most organizations, a sensible sequence looks like this.

Start with site-to-site IPsec tunnels between FortiGates you control on both ends. This is the most mature path, has no client-side variables, and lets your team gain operational experience with hybrid key exchange in a low-risk setting.

Move next to remote access IPsec, but stage it. Pilot with a small, representative group, watch for handshake and fragmentation issues, and only then expand to the full client population.

Add clientless VPN PQC if you are not constrained by FIPS-CC mode and your FortiOS release supports it. The browser-side fallback behavior makes this safer than it might first appear, but a pilot is still wise.

Throughout, keep everything hybrid. Pair ML-KEM, the FIPS 203 standardized algorithm, with a strong classical group, so you never depend on a single algorithm. Use FortiManager to keep configuration consistent across a fleet, and track Fortinet’s FIPS 140-3 validation progress if you operate in a regulated environment.

The quantum threat does not require a working quantum computer to be real today, because data harvested now can be decrypted later. The encouraging part is that the migration is primarily a cryptographic configuration change rather than a hardware replacement, and FortiGate’s hybrid approach lets you adopt post-quantum protection gradually, without giving up the classical security you already rely on. The cost of starting early is low. The cost of starting late could be every sensitive packet an attacker has been quietly recording.