Vendor compatibility
Fortinet post-quantum VPN support
FortiGate appliances and virtual machines running FortiOS and terminating site-to-site IPsec, managed standalone or through FortiManager.
Last reviewed
2 compatibility records
Direct answer
Fortinet's post-quantum VPN capability is a FortiOS release question rather than a FortiGate model question, but the model still constrains which FortiOS releases can be installed. Establish the exact FortiOS version on each FortiGate, confirm the model is supported on the target release, and confirm the remote peer's capability before planning any change. Model end-of-support dates are frequently the binding constraint rather than the software itself.
Practical status
What this means in a real estate
In a typical FortiGate estate the software is comparatively uniform and the hardware is not. The migration question usually resolves to which appliances can run the target FortiOS release at all, and whether the performance envelope on older models remains acceptable once the change is applied. Record model, FortiOS version and support status per device; a FortiGate that cannot take the target release is a hardware decision, not a configuration decision.
What to establish about key exchange
Determine per release whether RFC 8784 preshared key mixing, RFC 9370 additional key exchanges, or neither is available, and whether the capability is exposed through the GUI, the CLI only, or through FortiManager. A capability that exists but is not exposed through the estate's actual management path is not usable at scale.
Why authentication is a separate question
Key establishment and authentication must be tracked separately. A FortiGate tunnel that negotiates a hybrid key exchange continues to authenticate its peer with the certificate or preshared key already configured, and gains no post-quantum authentication property from the key exchange change.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| FortiGate appliances and VMs running FortiOS | Post-quantum key establishment: Unsupported |
| FortiGate appliances and VMs running FortiOS | Post-quantum key establishment: Requires exact-version review |
FortiGate appliances and VMs running FortiOS
7.4.xEstablish which IKEv2 mechanism the specific FortiOS build exposes and whether it is reachable from the GUI, the CLI or FortiManager.
Migration implication: In most FortiGate estates the constraint is which models can run the target release, so the hardware refresh plan and the migration plan need to be built together.
Caveats
- Older FortiGate models cannot run newer FortiOS releases
- Throughput can change on models without matching crypto offload
Last reviewed · medium confidence · 1 source
FortiGate appliances and VMs running FortiOS
7.6.xLater FortiOS trains change default proposal behaviour as well as available mechanisms. Confirm both before planning an upgrade-led migration.
Migration implication: Treat a FortiOS train upgrade as a change to every tunnel on the device, not only to the tunnels being migrated, and verify the untouched tunnels afterwards.
Caveats
- Upgrading a train can change negotiated defaults on tunnels that were not touched
Last reviewed · low confidence · 2 sources
Prerequisites
Establish these before assessing migratability.
- FortiOS version and build for every FortiGate in the estate
- Model support matrix for the intended target release
- FortiManager version where configuration is centrally managed
- Confirmation of the device's hardware support lifecycle status
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- Both peers must negotiate the same mechanism, whether the remote end is another FortiGate or a third-party device
- Where FortiManager pushes policy, the peer-side change must be sequenced against the managed push
- Partner-controlled peers require their release to be established before the change window
Operational limitations
Constraints that shape the plan rather than block it.
- Older models may not support the FortiOS release that carries the capability
- Throughput characteristics can change on models without matching crypto offload
- Centrally managed estates need the change modelled in FortiManager before it reaches devices
Migration paths
The routes available when the current state is not the target.
- Upgrade FortiOS to a release carrying the capability where the model supports it
- Replace appliances that cannot run the target release
- Terminate an overlay gateway behind the FortiGate where replacement is deferred
- Defer and track, with the model constraint recorded as a hardware blocker
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated key exchange on the established SA rather than reading the configured proposal
- Verify on both cluster members of an HA pair
- Re-verify after a FortiOS upgrade, because upgrade can change default proposal behaviour
Sources
No primary sources have been recorded for this entry yet. Until they are, nothing here is presented as a confirmed capability.
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual Fortinet estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.