Fortinet Secure SD-WAN is a security platform with SD-WAN built into it.
SD-WAN routing and next-generation firewall security run on the same FortiGate hardware under FortiOS. Routing, firewall policy, IPS, application control and SSL inspection operate inside one FortiOS environment rather than split across separate networking and security products. When a link fails and traffic reroutes, routing and security policy update together.
See why the single-process architecture mattersFor Australian multi-site organisations replacing MPLS, consolidating separate firewall and WAN products, improving Microsoft 365 and Teams performance, or building toward SASE, this integration can be the reason Fortinet fits. The trade-off is operational depth. Default FortiGate policies are not production-ready; hardware must be sized per site; SSL inspection requires certificate planning; SD-WAN policy must be designed by application class; and FortiManager, FortiAnalyzer, FortiGuard subscriptions and patch governance all need an operating model before rollout. Fortinet Secure SD-WAN performs when it is designed and operated as an integrated platform, not treated as a hardware supply project.
Fortinet SD-WAN decisions span architecture, rollout and operation.
Fortinet Secure SD-WAN fits best when the operating model can support the platform depth.
Not every multi-site organisation evaluating Fortinet SD-WAN is ready to deploy it well. The signals below distinguish where the platform delivers its value from where preparation work needs to happen first.
- Five or more sites with MPLS contracts approaching renewal
- Separate firewall and WAN products are creating operational complexity
- Microsoft 365 and Teams performance is degraded by MPLS backhaul
- FortiOS engineering capability is available internally or through a managed service
- A platform path from SD-WAN to ZTNA, Secure Web Gateway, CASB and broader SASE is wanted
- Branch firewall, WAN path selection, VPN, inspection and secure breakout need to be one environment
- Centralised policy management across multiple sites is required
- FortiManager and FortiAnalyzer visibility across the branch network is wanted
- A single site with simple connectivity and no multi-site management requirement
- Heavy existing investment in Cisco or Palo Alto WAN infrastructure
- No FortiOS operational capability to own policy, patching and IPS tuning
- MPLS contracts with significant penalty clauses that make early exit unjustifiable
- A light-touch platform is wanted, with minimal policy depth and limited operational capacity
- A simpler cloud-managed model is a better fit for the team that will operate it
- The environment does not need integrated firewall and SD-WAN at the branch edge
SD-WAN and NGFW run in the same FortiOS process.
Most SD-WAN vendors built their platforms as networking products and added security as a bolt-on. Fortinet built FortiGate as a security platform first, then added SD-WAN into the same FortiOS operating system that already handles firewall policy and inspection. The result is that routing decisions and security policy are coordinated natively rather than through an API connection between separate products.
The operational consequence is visible when something changes. When a link fails and traffic reroutes, a split-vendor architecture must push updated routing to the SD-WAN controller and separately update firewall policy. FortiGate handles both in the same process — there is no window during failover where traffic is routed but security policy has not yet followed.
Fortinet's purpose-built Security Processing Unit (SPU) ASIC handles hardware-accelerated inspection, so SSL decryption and deep packet inspection do not reduce throughput at line rate the way software-only inspection can. This matters for sites enabling full SSL inspection on high-bandwidth links, where software-only inspection would create a bottleneck. Fortinet Secure SD-WAN is not a networking product with security added. It is a security platform with SD-WAN built into it — and that distinction determines which operational team owns it and what capability is required to run it well.
Routing, inspection, visibility and cloud path control in one environment.
A Fortinet Secure SD-WAN deployment can provide:
- SD-WAN multi-link routing with application-aware path selection and real-time quality measurement
- NGFW and IPS running inline on the same hardware
- Microsoft 365, Azure and SaaS traffic classified and routed using the Fortinet Internet Service Database
- Direct cloud breakout at each branch, reducing MPLS backhaul latency for cloud applications
- 4G and 5G as primary or failover underlay with automatic path switching before SLA thresholds are breached
- Zero-touch provisioning, with devices self-registering to FortiManager on power-up once templates are configured
- FortiSASE upgrade path, extending ZTNA, Secure Web Gateway and CASB from the same platform without hardware replacement
The value is not only the feature list. The value is that these functions are operated as one environment rather than split between separate WAN, firewall, logging and access products.
A Fortinet SD-WAN deployment runs on an integrated platform, not a single appliance.
The FortiGate at each site is the visible component, but it operates as part of a platform. Deploying FortiGate without FortiManager across multiple sites is not a cost saving — it is a configuration-drift problem waiting to become a security incident.
FortiGate provides the site-level SD-WAN, next-generation firewall, routing, inspection and policy enforcement layer. Hardware should be sized per site based on WAN throughput, concurrent sessions, SSL inspection requirements and application load. A blanket hardware model across all locations adds cost at small sites and can create bottlenecks at larger ones.
FortiManager provides policy packages, configuration templates and firmware updates across all managed FortiGate devices. Zero-touch provisioning configuration is built in FortiManager before hardware ships. It becomes a critical management dependency in a multi-site deployment, so it should be deployed with high availability in any environment where it is operationally critical.
FortiAnalyzer provides centralised log collection from all sites, aggregating link health, application performance, security events and compliance reporting in one view. For Australian organisations, it should be designed with log location, retention and access control in mind where log data includes personal information.
FortiGuard provides the subscription services that keep security and application intelligence current: the Fortinet Internet Service Database for application and cloud classification, IPS signatures, antivirus updates, URL filtering and DNS security. SD-WAN application routing intelligence depends on the ISDB being current, so subscription renewal planning is part of the operational model, not an afterthought.
The deployment sequence determines whether the platform performs from day one.
Most SD-WAN deployments that underperform after go-live were not deployed incorrectly — they were designed incorrectly in the assessment phase. Zero-touch provisioning makes branch deployment fast; the assessment and policy design before any hardware ships determine whether that fast deployment works.
Current WAN topology is mapped. Underlay options are assessed per site: NBN Enterprise Ethernet, standard broadband, 5G and Starlink for remote locations. Security policy is reviewed. FortiGate hardware is sized per site based on WAN throughput and inspection requirements, not a blanket model. FortiManager and FortiAnalyzer environments are designed before rollout.
FortiOS templates are built in FortiManager. SD-WAN performance profiles are configured: Microsoft 365 and Teams traffic prioritised for direct cloud breakout, application classes defined and SLA thresholds set. IPS profiles are tuned to the environment rather than deployed as defaults. Zero-touch provisioning configuration is staged for each site, and hardware is pre-staged and tested before shipping.
The first site is deployed and validated against SD-WAN SLA profiles. Microsoft 365 and Teams performance are confirmed against baseline. MPLS is retained in parallel. Application performance and failover behaviour are validated before rollout proceeds to the remaining sites.
Remaining sites are deployed using zero-touch provisioning. Each site is validated before MPLS is decommissioned for that location. MPLS decommission should be aligned to contract expiry where possible to avoid early termination costs. FortiAnalyzer visibility should be available across all live sites from day one of each site going live.
Policy review cadence is defined. Patch governance is established for FortiGate firmware updates. FortiGuard subscription alignment is confirmed. Monitoring thresholds are reviewed against the real traffic baselines observed during rollout.
Fortinet SD-WAN is the foundation of FortiSASE.
The SASE extension adds ZTNA access proxy, Secure Web Gateway and CASB to the existing FortiGate edge through FortiOS software updates and FortiSASE cloud services. No branch hardware replacement is required — deploying Fortinet SD-WAN now is not an interim step that creates rework later.
Multi-link routing with direct cloud breakout. MPLS exit. Application-aware path selection. Branch NGFW, IPS and application control. This is the baseline deployment and the foundation for all subsequent stages.
Remote user access migrates from SSL VPN to ZTNA through the FortiOS access proxy. Identity and device posture are verified per session; VPN network trust is replaced with application-level access control. Identity remediation, typically via Microsoft Entra ID, should be treated as a prerequisite.
Secure Web Gateway and CASB extend the security perimeter to remote users and branch internet traffic through FortiSASE cloud points of presence, enabling consistent security policy across branch and remote users regardless of location.
User access, branch connectivity and internet traffic operate under a single policy framework. FortiManager becomes the unified management plane; FortiAnalyzer aggregates logs from branch, remote and cloud enforcement points, so policy changes apply consistently across the environment.
Fortinet underperforms when it is treated as hardware supply rather than an engineered platform.
These are five deployment mistakes that produce a Fortinet environment that underperforms the hardware it is running on.
Specifying the same FortiGate model across all sites regardless of WAN throughput, concurrent sessions and SSL inspection requirements adds cost at small sites and creates bottlenecks at larger ones. Fix: drive hardware sizing through a per-site assessment, not a single model applied across the estate to simplify procurement.
FortiGate ships with default policies that are not appropriate for production use. Pushing defaults to all sites creates a security posture that appears complete but has not been assessed against the organisation's application environment, traffic patterns or compliance requirements. Fix: tune IPS profiles and design SSL inspection settings, CA rollout and application exclusions before production rollout.
Template-based SD-WAN policies not designed around the actual application classes route traffic on generic assumptions rather than measured SLA requirements. Microsoft 365 and Teams traffic routed incorrectly can degrade performance in ways attributed to the platform rather than the policy design. Fix: design SD-WAN policy by application class against measured SLA requirements.
Setting a hard MPLS decommission date aligned to the first SD-WAN deployment rather than to validated site performance creates pressure to cut over before problems are identified. Fix: retain MPLS in parallel at each site until SD-WAN performance at that site is stable under production load, not against a fixed calendar date.
Fortinet perimeter devices require active patch governance. The ACSC has issued multiple Fortinet-related advisories, including FortiOS vulnerabilities and exploitation of previously known weaknesses. Fix: define patch workflow, management-plane exposure, credential rotation and post-patch verification before go-live, not after an incident makes the gap obvious.
Deployment is not the end of the Fortinet SD-WAN engagement.
A Fortinet environment deployed correctly but operated without ongoing attention degrades progressively as configurations drift, IPS signatures age, and link characteristics change without policy adjustments. There should be one accountable engineering team for the network perimeter, not a helpdesk queue that responds when something breaks.
FortiGate probes all WAN links continuously; automatic failover triggers before packet loss exceeds application SLA thresholds, with engineering intervention for events needing active response.
A site-affecting outage or security incident, with a documented escalation path, engineering access to FortiManager and clear response ownership.
Security policies, SD-WAN application classifications and IPS profiles reviewed against real traffic on a defined cadence, so routing does not drift from intent over time.
Certificate lifecycle management for the FortiGate CA, application exclusion lists maintained as new SaaS is adopted, and inspection failures reviewed rather than silently bypassed.
FortiAnalyzer reporting covering link availability per site, security events by category, policy changes since last review and FortiGuard subscription status.
Single engineering ownership of the network perimeter, rather than a reactive helpdesk queue that responds only when something breaks.
Fortinet SD-WAN deployment starts with the site assessment, not the hardware order.
Fortinet Secure SD-WAN is the right platform for multi-site Australian organisations that need to consolidate WAN and security. The integration is genuine and the platform is proven — the requirement is an operating model that matches what the platform needs to run correctly. Fortinet is powerful, but it is not a light-touch platform: it suits environments where the team operating it has the depth to manage FortiOS policy, inspection, firmware, logging and security operations properly.
For organisations with five or more sites, an MPLS contract approaching renewal, and a team or managed service with FortiOS operational depth, Fortinet Secure SD-WAN consistently delivers better cost-per-capability than separate WAN and security products. The failure mode is treating this as a hardware supply project. A FortiGate deployed with default policy, blanket hardware sizing and no operational model does not deliver the performance or security that justified the investment. The platform performs when the deployment is designed correctly and operated with discipline — those two things are inseparable.
Platform integration is the benefit. FortiOS operational depth is the trade-off.
The design decisions above are cheaper to make before the first site is ordered than after the tenth is live.
Design before rollout →Questions that come up before choosing Fortinet Secure SD-WAN.
What is Fortinet Secure SD-WAN?
Does SD-WAN replace the firewall?
How does Fortinet SD-WAN differ from other vendors?
How long does a Fortinet SD-WAN rollout take?
Does it work with existing internet connections?
What is the path from Fortinet SD-WAN to SASE?
Has SD-WAN become obsolete?
What happens to security if a WAN link fails?
Review the network architecture before the hardware order.
The assessment and policy-design phases — not the appliances — determine whether a Fortinet deployment performs from day one. A short review covers sizing, underlay, policy and operating model.
Discuss Fortinet SD-WAN