Where the whole product can sit
An air gapped deployment of the whole product, tower included, is supported, not an exception you argue for.
Fortinet runs FortiOS across physical, virtualized and cloud deployments, with purpose built ASICs in the hardware and post-quantum key exchange documented in FortiOS 8.0. QS-WAN is one control tower on your own infrastructure and one signed agent. Move if you want fewer planes to operate. Stay if you need their breadth.
Fortinet builds FortiGate, a next generation firewall family running FortiOS, “designed for flexible deployments across physical, virtualized, and cloud environments”, on hardware carrying “purpose built security and networking ASICs”.
Some of that we can’t imitate.
Dedicated silicon in the data path is a hardware decision, and software doesn’t catch it by trying harder.
The catalogue around FortiOS is far wider than ours.
FortiOS applies “Hybrid Key Exchange per RFC 9370” and supports “ML KEM (Kyber), BIKE, HQC and FRODO”, with QKD listed beside it. We ship one KEM family and no QKD screen.
How many control planes does one administrator operate?
FortiOS sits on the gateway. FortiManager is the fleet layer for “network and security management for the Fortinet Security Fabric”, as an appliance, a virtual machine or FortiManager Cloud. FortiClient is the third estate, “a Fabric Agent” managed by FortiClient EMS, either a server you run or “a Fortinet-hosted EMS solution”. That scales. It also means gateway config, fleet policy and endpoints are three products, three upgrade paths.
QS-WAN is one. Gateways, signed policy, certificates and enrolled devices sit in one console, and the tower runs on your infrastructure, on a gateway we ship you, or on our servers. A gateway joins as a local gateway, as software paired with a single use claim code, or as hardware with a serial number. Same console for all three.
The diagram compares two control plane arrangements. On the left sit the same three things an administrator operates in both: gateway config, fleet policy and endpoints. In the first arrangement each of those three reaches a plane of its own, so there are three consoles and three upgrade paths, with a seam marked where each channel meets its plane, and every plane scales on its own. In that arrangement the algorithm is a tunnel setting, chosen one tunnel at a time. In the second, all three channels converge on a single control tower that holds gateways, policy, certificates and enrolled devices, and the algorithm becomes a property of the fleet, so one switch moves the hybrid key exchange of X25519 and ML-KEM-768 and the ML-DSA-87 authentication across every gateway, with certificates re-signed for you. The second arrangement hands you a bill as well: patching, backups and availability of that tower become your job. The diagram compares what one administrator operates and where the algorithm choice lives. It says nothing about silicon in the data path and nothing about how traffic is carried.
Is crypto agility a tunnel setting or a fleet operation?
Both are post-quantum. What differs is what changing the algorithm costs you on a Tuesday.
In FortiOS you set it per tunnel. Their guide says to “choose up to three KE groups in each round of additional key exchanges” in Phase1 VPN settings, with “up to seven rounds”, and that only ML-KEM-512, ML-KEM-768 and ML-KEM-1024 “are standardized by NIST and are FIPS 203 compliant”.
In QS-WAN it’s a property of the fleet. The Vault screen names the layers in use: hybrid key exchange X25519 plus ML-KEM-768, ML-DSA-87 authentication and AES-256-GCM. Beside them sit eight key exchange options, eight certificate authority options and three ciphers, switchable fleet wide or per gateway, with certificates re-signed and redistributed for you. That’s crypto agility over a post-quantum layer.
One limit, up front: certificate authority rotation is scheduled work, not a button you press on a whim, and it needs every gateway online.
The QNova Client is one signed install carrying the tunnel, endpoint protection with EDR, remote support, a password vault and encrypted file transfer. Nothing pairs to a second management server.
Sixteen rules scoped per gateway, user or device, where a device override changes only the ids it sets. USB port blocking is one.
Nine frameworks scored in the console, CIS benchmarks running on real Windows and macOS hosts, and reports carrying aggregates only.
An air gapped deployment of the whole product, tower included, is supported, not an exception you argue for.
Segments are objects you draw on a map. The console runs in 15 languages.
We're not a security operations centre. Nobody of ours watches your traffic.
Not painless, and anybody who says otherwise hasn’t run one. You stand up the tower on your own infrastructure and decide who patches and backs it up, because that job becomes yours.
You put a gateway next to the LANs you already have and enrol a pilot group.
Run both sides in parallel until the new agent survives a patch cycle and one real incident. The slow parts are naming conventions and undocumented firewall exceptions.
Those “purpose built security and networking ASICs” exist because inspection at line rate is a hardware problem. We’re software, and if your bottleneck is a big pipe rather than a busy administrator, dedicated silicon is the honest answer we haven’t got.
FortiOS 8.0 documents “support for hybrid PQC SSL deep inspection in proxy mode”, and Fortinet lists QKD and four KEM families. We protect our own tunnels. We don’t inspect somebody else’s post-quantum session, and QKD isn’t a screen here.
Their catalogue covers ground we don’t, and swapping it for one console you didn’t need is a bad deal.
Replacing appliances that work costs more than a console saves. We put a gateway beside infrastructure you already have rather than pulling boxes from racks, so if your racks are fine, stay.
Windows is the complete column, macOS ships with CIS benchmarks running, and Android is there. Linux has gaps and iOS is next, not now.
One where the gateway form factor is a choice, not a starting point: local, software paired with a single use claim code, or hardware we ship you.
Yes, and pretending otherwise would be easy to catch. FortiOS applies hybrid key exchange per RFC 9370 and supports several KEM families. The argument worth having is where you set it: per phase1 VPN there, fleet wide or per gateway here.
No. This is a product, not a managed service, and that's the cleanest line between us and anything sold with analyst hours.
For those two, yes: tunnel, endpoint protection, remote support, password vault and file transfer in one signed install, managed from the same tower as the gateways. It doesn't replace an email gateway.
We’ll show you where the tower would sit and what it wouldn’t cover, free, with nothing to sign.