Fortinet Secure SD‑WAN
We design and run Fortinet Secure SD-WAN, where routing, next-generation firewall, application control, segmentation and inspection all run on FortiGate under FortiOS. Security policy follows traffic when SD-WAN changes the path, and the same architecture supports branch security, local cloud access and a path into Fortinet SASE.
- SD-WAN routing & path selection
- NGFW + IPS (inline)
- SSL inspection
- App control + Fortinet ISDB
Routing and security on the same FortiGate
One platform at the site edge
FortiGate handles SD-WAN path selection and next-generation firewall enforcement at the site edge. Application control, IPS, segmentation, web security and inspection run as security profiles on the relevant FortiOS policies, so routing and security decisions stay on one platform as traffic moves between WAN paths.
Security policy follows traffic during failover
SD-WAN routing and firewall enforcement run together on FortiGate under FortiOS. When traffic moves to another eligible WAN path, the configured security policies and inspection controls continue to apply. We test those controls during failover, including any dependencies on the original path. Policy packages and application rules stay centrally governed, giving distributed sites local enforcement with central control.
Local cloud breakout with branch security
Microsoft 365, Teams, Azure and SaaS services often have efficient internet paths straight from the branch. Secure SD-WAN uses those paths while the FortiGate at the site applies the required inspection and application policy.
Several links, chosen on measured quality
Fibre, nbn, broadband, 4G and 5G can be used together at a site. Latency, jitter and packet loss are measured continuously, and traffic moves to another eligible path when a link crosses the Performance SLA thresholds set for that application.
Applications identified before they're routed
The Internet Service Database identifies Microsoft 365, Azure and other cloud services, so the same identification drives the routing decision and the security policy applied to that traffic.
Provisioned from FortiManager templates
Once templates are built in FortiManager, new FortiGates are provisioned through the agreed Fortinet provisioning method and validated before production.
Where it fits, and where it may not
Fortinet suits environments where the team running it, internal or managed, can look after FortiOS policy, inspection, firmware and logging properly. The integration is the advantage, and the operational depth of FortiOS is what it asks in return.
- Separate firewall and WAN products are adding operational complexity
- Backhaul through head office is slowing Microsoft 365 and Teams
- Branch firewall, path selection, VPN, inspection and secure breakout belong in one environment
- You need central policy management across sites
- You want a path to ZTNA, Secure Web Gateway, CASB and broader SASE
- FortiOS skills are available internally or through a managed service
- MPLS contracts are coming up for renewal
- You want FortiManager and FortiAnalyzer visibility across the branches
- A single site has simple connectivity and no multi-site management need
- There is heavy existing investment in Cisco or Palo Alto WAN infrastructure
- FortiOS policy, patching and IPS tuning have no clear owner
- MPLS penalty clauses make an early exit hard to justify
- The team running it would be better served by a lighter, cloud-managed model
- The branch edge doesn't need integrated firewall and SD-WAN
From Secure SD‑WAN into SASE
Fortinet Secure SD-WAN provides the branch edge for a broader Fortinet SASE architecture. FortiSASE extends Secure Web Gateway, CASB and other cloud-delivered security controls to users outside the branch. Fortinet ZTNA provides application-level access using identity and device posture.
Identity preparation remains part of the work. Microsoft Entra ID, Conditional Access, device compliance and application dependencies need to be considered before ZTNA is introduced. Suitable FortiGate hardware remains part of the branch design as the environment moves into SASE.
Secure SD-WAN
Multi-link routing, direct cloud breakout, branch NGFW, IPS and application control. The baseline for each later stage.
ZTNA
Remote access moves from SSL VPN to ZTNA through the FortiOS access proxy, with identity and device posture checked for each session. Microsoft Entra ID remediation comes first.
Secure Web Gateway and CASB
FortiSASE extends web and SaaS controls to remote users and branch internet traffic through cloud points of presence.
One policy framework
Branch connectivity, remote-user access and internet security operate under a coordinated policy framework. FortiGate and FortiSASE have their own management capabilities, and we design their configuration, monitoring and logging together.
Shadow AI, DLP and AI traffic visibility in FortiOS 8.0
FortiOS 8.0 introduces greater visibility into AI application use, including sanctioned and unsanctioned tools, and visibility into Model Context Protocol (MCP) and agent-to-agent (A2A) activity. Fortinet has also expanded its data loss prevention capabilities, including DLP that reads sensitive information in images.
These controls give network and security teams more context around which AI services are being used and how data is moving through them.
For organisations deploying AI agents into business workflows, that connects network security with AI governance. Agents, tools and AI-enabled applications introduce traffic and data flows that the security layer increasingly needs to identify and control. See our AI and automation work.
We assess hardware compatibility, licensing and inspection requirements before introducing these controls into a production FortiGate environment.
One morning at a branch, as FortiOS 8.0 sees it. Switch between visibility and an agreed policy to see what changes.
- Microsoft 365 Copilot Staff, all sites Sanctioned AI Identified Allowed
- Public AI chat service Finance team, Sydney Unsanctioned AI Identified Blocked, users pointed to Copilot
- AI browser extension Design workstation Unsanctioned AI Identified Blocked
- MCP calls from an operations agent Azure workload Agent traffic · MCP Detected Allowed to approved MCP servers
- Unknown MCP server Developer laptop Agent traffic · MCP Detected Blocked and logged for review
- Agent-to-agent request Procurement agent Agent traffic · A2A Detected Allowed and logged
- Image upload with card numbers To a public AI chat service Sensitive data DLP match flagged Stopped by DLP
With visibility on, FortiOS identifies which AI services are in use, by whom and from which site, including agent traffic over MCP and A2A. Nothing is blocked yet, which is how most rollouts start: you see the real picture before anyone writes a rule. Once a policy is agreed, the same identification drives enforcement. Approved tools carry on, unsanctioned ones are blocked, agents reach only approved MCP servers, and DLP stops sensitive data leaving in images and files.
Detection and enforcement depend on FortiGate model, firmware, licensing and inspection settings.
How a Fortinet Secure SD-WAN rollout runs
Zero-touch provisioning gets FortiGates into branches quickly. What makes that speed worth having is the assessment and policy design done before any hardware ships.
We start with the current WAN and security policy
We map how each site connects today and look at the underlay options available, from nbn Enterprise Ethernet and broadband to 5G and Starlink. We review the existing security policy, size each FortiGate on throughput and the inspection it will carry, and plan FortiManager and FortiAnalyzer before rollout, with high availability where the estate depends on them.
Templates and policy are built before anything ships
FortiOS templates are built in FortiManager, with application classes and Performance SLA thresholds defined so Microsoft 365 and Teams break out directly at the branch. IPS profiles and SSL inspection are tuned to your environment, including certificate rollout, and each site's provisioning is staged and its hardware tested before it ships.
One site proves the design
The first site goes live against the SD-WAN SLA profiles, and we confirm Microsoft 365 and Teams against the baseline. Existing connectivity, including MPLS where it's in place, stays available while we validate, and failover is tested before the wider rollout starts.
The remaining sites follow the proven pattern
Remaining sites are provisioned through the agreed Fortinet method, with production cutovers after hours. Each site is validated before its legacy services are retired, with carrier contract dates and rollback planned in, and FortiAnalyzer gives visibility from each site's first day live.
Then it moves into day-to-day running
We agree the policy review cadence, the firmware patch process and FortiGuard subscriptions, and adjust monitoring thresholds against the real traffic seen during rollout.
What holds a Fortinet estate back
One FortiGate model across the estate
Using the same model at each site can add cost at small sites and create bottlenecks at larger ones.
Fix: Size each site on WAN throughput, concurrent sessions and SSL inspection.
Default policies pushed to production
Default FortiGate policies are not production-ready, and an estate built on them only looks complete.
Fix: Tune IPS profiles and design SSL inspection, certificate rollout and application exclusions before rollout.
SD-WAN templates without application classes
Generic templates route traffic on assumptions, and Teams or Microsoft 365 problems get blamed on the platform.
Fix: Design SD-WAN policy by application class against measured SLA requirements.
A fixed MPLS cut-off date
A calendar date creates pressure to cut over before problems show.
Fix: Where MPLS is in use, keep it available during migration until the new paths are validated under production load. Plan its retirement around site requirements and carrier contracts.
Patching left until later
The ACSC has issued multiple advisories on FortiOS vulnerabilities, including exploitation of known weaknesses.
Fix: Set the patch workflow, management-plane exposure, credential rotation and post-patch verification before go-live.
These decisions are cheaper to make before the first site is ordered than after the tenth is live.
Running the platform after go-live
A Fortinet environment that's deployed well but left alone degrades over time: configurations drift, IPS signatures age and link behaviour changes without the policy keeping up.
Policy review on a set cadence
Security policies, SD-WAN application classifications and IPS profiles are reviewed against real traffic, so routing stays aligned with the design.
SSL inspection upkeep
The FortiGate CA certificate lifecycle is managed, application exclusions are updated as new SaaS is adopted, and inspection failures are reviewed when they occur.
Reporting
FortiAnalyzer reports cover link availability by site, security events by category, policy changes since the last review and FortiGuard subscription status. Log retention, access and hosting are set in the design, with particular care where logs include personal information.
Incident response
Site-affecting outages and security incidents follow a documented escalation path, with engineering access to FortiManager and clear ownership.
Firmware and FortiGuard
Firmware updates follow Fortinet's PSIRT advisories, with management-plane exposure reviewed and each update verified afterwards. FortiGuard renewals are planned ahead, because the Internet Service Database, IPS signatures and URL filtering depend on them.
Network and security handled together
Our network and security engineers manage the FortiGate environment together. Your IT team can contact them directly for troubleshooting, policy changes and incidents, and we coordinate with carriers when connectivity faults are involved.
See what we’ve delivered for our clients
Common questions about Fortinet Secure SD-WAN
What is Fortinet Secure SD-WAN?
An architecture where SD-WAN routing and next-generation firewall security run on the same FortiGate under FortiOS, so routing and security inspection are designed and managed on one platform.
Does Secure SD-WAN replace the firewall?
FortiGate is the firewall and runs SD-WAN within FortiOS. The SD-WAN and NGFW functions operate together on the same platform, and firewall policy, IPS, application control and SSL inspection all sit on it.
Can it improve Microsoft 365 and Teams performance?
It improves the network path where central backhaul or poor path selection contributes to the problem. Application performance still depends on the underlay, local network, firewall inspection and the application itself.
How does Fortinet SD-WAN differ from other SD-WAN products?
Many SD-WAN products started as networking platforms and connect to a separate firewall for security. Fortinet runs SD-WAN inside FortiOS on the FortiGate firewall, so routing and security policy are designed, managed and investigated together. Whether that suits you depends on the firewall estate, inspection needs and the team that will run it.
What happens to security if a WAN link fails?
Because SD-WAN and firewall enforcement run within FortiOS, traffic that fails over to another eligible path is handled by the same security policy and inspection profiles. We test this during the pilot, including inspection, segmentation and any remote-access dependencies on the failover path.
What is the path from Fortinet SD-WAN to SASE?
Secure SD-WAN establishes the branch network and security foundation. FortiGate ZTNA can then provide application-specific remote access, while FortiSASE adds cloud-delivered security capabilities such as secure web gateway and CASB for users outside the branch, according to the selected services.
We assess identity, licensing, hardware and application requirements before recommending each stage.
Has SD-WAN become obsolete with SASE?
No. SD-WAN is the network layer within SASE. SASE builds on SD-WAN by adding cloud-delivered security and identity-based access for users wherever they connect.
Talk to us before your next Fortinet network or security change
The assessment and policy design decide whether a Fortinet deployment performs once it's live. A short review covers sizing, underlay, policy and the operating model.