Home Resources FortiGate vs Palo Alto SD-WAN
FortiGate vs Palo Alto SD-WAN: the branch decision
Your customer has forty sites and a refresh due. The licensing difference between these vendors is real and it is the smaller half of the decision. The other half is whether the WAN and the firewall should share a failure domain.
The short answer
Fortinet includes Secure SD-WAN in FortiOS. Palo Alto licenses SD-WAN as a separate subscription on each participating appliance. Across a large branch estate that difference is material to the total.
Whether it should decide the architecture is a separate question. Convergence buys a smaller footprint and costs a larger failure domain, and that trade is about the customer's tolerance for a branch outage rather than about either vendor.
Decide the architecture first. Then price it. Reversing that order lets a licensing line item choose a design.
The licensing difference
Secure SD-WAN is a feature of FortiOS. It is configurable on a FortiGate without a separate SD-WAN license and without a separate orchestrator product, and the path selection and self-healing logic runs on the appliance itself.
Palo Alto licenses SD-WAN as one of its named subscriptions. It is required on each physical appliance participating in the SD-WAN deployment and depends on a supported PAN-OS release. Orchestration runs through Panorama, which carries its own device management and support licensing.
Two qualifications keep this honest. Fortinet recommends central management for any estate of scale, so FortiManager belongs in a realistic FortiGate design and in its price. And on both platforms the security subscriptions are priced per site regardless of which vendor supplies the SD-WAN function, so the SD-WAN line is one component of a per-site number rather than the whole of it.
SD-WAN inclusion in FortiOS is from Fortinet's Secure SD-WAN documentation and ordering guide. The Palo Alto SD-WAN subscription requirement and its Panorama orchestration model are from Palo Alto Networks SD-WAN activation documentation. Both checked 8 August 2026.
How it compounds by site
The per-site structure is the same on both platforms. The values are not, and they come from your own quotes rather than from any published figure.
Complete this once per vendor for a representative site, then multiply by the site count and by the term. Sites are rarely uniform, so build it for each site class the customer has rather than for an average site.
| Per-site line | Converged | Separate |
|---|---|---|
| Appliance or appliances | ||
| Security subscriptions | ||
| SD-WAN licensing | ||
| Support, per device | ||
| Central management, per managed device | ||
| Installation and commissioning | ||
| Rack space, power and remote hands | ||
| Operating labor, per site per year | ||
| Per-site total × site count × term |
A worksheet rather than a price list. We publish no per-site figures for either vendor, because the numbers that belong here come from your own quotes at your own partner tier. See the pricing page for why a published figure would be a guess.
Two lines are commonly missing. Central management is licensed per managed device on both platforms, so it scales with the estate rather than sitting as a fixed cost. Operating labor scales with device count rather than with site count, which is the argument the separate design has to answer.
The case for one appliance
Convergence is the default for branch estates and it earns that position.
One device per site means one thing to install, one thing to power, one thing to monitor and one thing to replace. Field installation is shorter and can more often be done by a non-specialist. Spares inventory is a single model. A site with a comms cabinet the size of a shoebox has a physical constraint that decides this on its own.
One vendor means one support path. When a branch is down and the WAN and the firewall belong to different vendors, the first hour goes to establishing which one owns the fault. A single vendor removes that hour.
Path selection informed by application identity is architecturally cleaner when the same device performs both functions. The device already knows what the traffic is, so steering it requires no second classification.
The case for two
Separation is the argument that gets omitted, and it is the reason to read a page written by an operator rather than by a vendor.
The failure domain covers both functions
A converged appliance that fails takes the WAN and the security enforcement at the same moment. The site is not degraded, it is off. Where a site has revenue attached to its connectivity, the customer should price that outage before choosing the smaller footprint.
Firmware upgrades carry double risk
An upgrade on a converged branch appliance changes the routing behaviour and the inspection behaviour together. The change window is harder to secure, the test plan is longer, and a rollback affects connectivity as well as security. Across two hundred sites, that difference decides how often the estate can be patched, which decides how current it stays.
Capacity planning gets harder
Inspection and path selection draw on the same hardware. A site whose encrypted traffic share rises will consume inspection capacity, and on a converged appliance that pressure appears in the same place as the WAN function. Sizing therefore has to account for growth in two dimensions at once, and the failure mode is a WAN problem caused by a security workload.
Replacing either layer is harder later
A converged design couples the WAN refresh cycle to the security refresh cycle. Changing the firewall vendor means changing the WAN edge, and changing the WAN approach means revisiting the security estate. Separation keeps those two decisions independent, which has a value that appears at the next refresh rather than at this one.
| Event | Converged | Separate |
|---|---|---|
| Firmware upgrade | WAN and security change together | Each layer changes on its own schedule |
| Appliance failure | Site loses connectivity and enforcement | Site loses one function, degraded rather than down |
| Circuit failure | Handled by path selection on the appliance | Handled by path selection on the WAN device |
| Inspection saturation | Path selection competes for the same resource | Contained in the security layer |
| License lapse | May affect inspection and steering together | Affects one layer |
| Vendor change at refresh | Both layers move at once | Either layer moves alone |
Failure-domain behaviour described here follows from the architecture rather than from a vendor claim, and applies to converged designs on either platform. Specific outcomes depend on the customer's redundancy design, which is worth confirming per site class.
What changes past a hundred sites
Past roughly a hundred sites the question stops being about the appliance and becomes a question about the management platform.
Provisioning time dominates the program. Both vendors support zero-touch provisioning through their management platforms rather than through the firewall alone, which makes the management platform a required component rather than an optional one. Budget it in the first quote, because it is the item most often absent from a first quote and most often needed by the second wave of sites.
Template management becomes the real design work. The question is which parts of the configuration are common across all sites, which vary by site class, and which are genuinely per site. Getting that hierarchy wrong is recoverable at ten sites and expensive at two hundred.
Configuration drift becomes a standing operational cost. Every direct change made on a device during an incident is a future inconsistency between the device and the central template. The platform's behaviour when the two disagree is a property worth understanding before the estate is built, and it is covered in the central management comparison.
From the operations side
The recurring incident in converged branch estates is not a product failure. It is a site that was sized against a headline throughput figure, then had TLS inspection enabled a year later during a security review. Inspection consumes the capacity the WAN function was relying on, and the branch reports intermittent slowness that no single component explains. Size branch appliances with decryption accounted for at the start, even where inspection is not enabled on day one.
Making the recommendation
Three questions decide this in a customer meeting.
- What does an hour of branch downtime cost this customer, at their busiest site and at their quietest one?
- Who patches these appliances, how often, and what change window do they get?
- What share of this customer's branch traffic will be inspected in three years, rather than today?
A customer who cannot secure a monthly change window is describing a converged estate that will run old firmware. A customer with revenue attached to every site is describing a case for separation that survives a licensing difference. A customer with neither constraint is describing a converged design, and at that point the licensing difference is a reasonable tiebreaker.
Forty sites, one pager
A branch estate generates its ticket volume at the sites furthest from your engineers. We run firewalls and branch estates that MSPs have already sold, under their brand, across Fortinet, Palo Alto and six other platforms, from $29 per firewall per month. Converged or separate, the rota is the same one.
Get your rateCommon questions
What customers ask when a multi-site refresh comes up. Something missing? Tell us and we will add it.
Does Palo Alto require an SD-WAN license?
Yes. Palo Alto licenses SD-WAN as a subscription, required on each physical appliance that participates in the deployment, and the feature depends on a supported PAN-OS release. Fortinet includes Secure SD-WAN in FortiOS, so it is configurable on a FortiGate without a separate SD-WAN license. Central management is a separate purchase on both platforms and is where most of the orchestration lives at scale.
Should security and SD-WAN run on the same appliance?
It depends on how much the customer values a small site footprint against a small failure domain. One appliance means fewer devices, one support path and a simpler per-site deployment. It also means a firmware upgrade carries both WAN risk and security risk, and inspection load and path selection compete for the same hardware. Sites with a single circuit and modest inspection needs favor convergence. Sites where a WAN outage stops revenue favor separation.
How many branches does it take for the licensing difference to matter?
The difference is a line item at one site and a program-level number at two hundred. There is no threshold that applies generally, because it depends on the appliance tier at each site, the subscriptions attached and the discount negotiated. Build the per-site structure once, multiply it by the site count, and compare the totals across the full term rather than the first year.
What breaks most often in a converged branch estate?
Firmware upgrades and configuration drift. An upgrade at a converged site is a WAN change and a security change at the same moment, so the change window is harder to get and the rollback is more consequential. Drift appears where an engineer makes a direct change on a device to resolve an incident and the central template later overwrites it. Both are management problems rather than product faults, and both scale with site count.
Does either platform support zero-touch provisioning?
Both do, through their management platforms rather than through the firewall alone. That makes the management platform a required part of any estate large enough to care about provisioning time, on either vendor. Include it in the design and in the quote from the start, because it is the component most often absent from a first quote and most often needed by the second wave of sites.