A real-life situation
Northgate Ceramics, a fictional company, has grown from one office to six. Each site has a FortiGate, and each is configured by hand. Policies drift apart, logs disappear when a small FortiGate reboots, and when a laptop is infected nobody notices until the helpdesk does. The IT lead must decide which Fortinet products solve which of these problems, and how they would work together. That needs a clear picture of the product family, which is large and full of similar names. This lesson gives that picture, then shows how the Security Fabric connects the pieces.
Why there are so many products
A FortiGate decides and inspects at the network boundary. Some jobs are better done elsewhere: managing hundreds of firewalls, keeping a year of logs, protecting a laptop on hotel Wi-Fi, filtering email before it reaches the mail server, or protecting a web application from attacks the firewall can't interpret. Each Fortinet product covers one of those jobs. Knowing the job is the quickest way to remember the name.
The products, one by one
Network security and management
| Product | What it is | Form |
|---|---|---|
| FortiGate | Next-generation firewall running FortiOS: routing, policies, NAT, VPN, SD-WAN, security profiles | Hardware, VM, cloud |
| FortiManager | Central configuration management for many FortiGates: policy packages, objects, device settings, firmware and scripts | Hardware, VM, cloud |
| FortiAnalyzer | Central log collection, search, reporting and event correlation | Hardware, VM, cloud |
| FortiSwitch | Ethernet switches that a FortiGate can manage directly over FortiLink | Hardware |
| FortiAP | Wireless access points managed by a FortiGate (or by a cloud service) | Hardware |
Identity and endpoints
| Product | What it is |
|---|---|
| FortiClient | Endpoint software: VPN client, ZTNA agent, and endpoint protection and telemetry, depending on licence |
| FortiClient EMS | Enterprise Management Server: deploys and manages FortiClient on endpoints, and reports each endpoint's posture to FortiGates |
| FortiAuthenticator | Identity server: RADIUS and LDAP services, single sign-on (FSSO), two-factor authentication, certificates and guest portals |
| FortiToken | One-time-password tokens for two-factor authentication: a mobile app or hardware tokens, validated by a FortiGate or FortiAuthenticator |
| FortiEDR | Endpoint detection and response: watches endpoint behaviour, blocks malicious activity and supports investigation |
Applications, email and advanced threats
| Product | What it is |
|---|---|
| FortiSandbox | Runs suspicious files in isolated virtual machines to see what they do, and returns a verdict to the device that submitted them |
| FortiMail | Email security gateway: spam, phishing and malware filtering for inbound and outbound mail |
| FortiWeb | Web application firewall (WAF): protects web applications and APIs from attacks such as SQL injection and cross-site scripting |
Behind all of them is FortiGuard Labs, Fortinet's threat research organisation. Its research becomes the signatures, ratings and threat feeds that products download through FortiGuard services, such as antivirus and IPS signatures, web categories and IP reputation. A FortiGate's inspection is only as current as these updates. Fortinet sells many more products (for example for network access control, SIEM and SASE); the ones above are those you meet first around a FortiGate.
Learn more: FortiOS Architecture and FortiGuard Services
Which product answers which problem
| Problem | Product |
|---|---|
| Control and inspect traffic between networks and to the Internet | FortiGate |
| Keep policies consistent across many FortiGates | FortiManager |
| Keep logs for months, search them, produce reports | FortiAnalyzer |
| Manage switches and Wi-Fi from the firewall | FortiSwitch, FortiAP |
| Know whether a laptop is patched and protected before allowing it | FortiClient with FortiClient EMS |
| Add two-factor authentication to VPN logins | FortiToken (with FortiGate or FortiAuthenticator) |
| Central RADIUS, single sign-on and certificates | FortiAuthenticator |
| Analyse unknown files that signatures don't recognise | FortiSandbox |
| Stop phishing and malware in email | FortiMail |
| Protect a web shop or API from application attacks | FortiWeb |
| Detect and stop attacker activity on endpoints | FortiEDR |
For Northgate Ceramics: FortiManager answers the policy drift, FortiAnalyzer the lost logs, and FortiClient with EMS (or FortiEDR) the infected laptop that nobody noticed. The Security Fabric is what lets them act together.
How the Security Fabric works
- 1. Updates: FGT1 downloads signatures and ratings from FortiGuard.
- 2. Logging: FGT1 sends its logs to FAZ1.
- 3. Management: FMG1 installs policies on FGT1.
- 4. Access layer: FGT1 manages FSW1 and, through it, FAP1.
The Fabric has a few building blocks:
- Root FortiGate. Usually the edge FortiGate at the main site. The Fabric is enabled there first, and it holds the view of the whole Fabric.
- Downstream FortiGates. Other FortiGates, such as an internal segmentation firewall, join by pointing at their upstream FortiGate and being authorised by the root. They form a tree.
- Managed access devices. FortiSwitches (over FortiLink) and FortiAPs managed by a Fabric FortiGate appear in the Fabric automatically.
- Fabric connectors. Links to other products: core ones such as FortiAnalyzer logging, FortiClient EMS and FortiSandbox, and external ones such as public cloud and threat-feed connectors that supply dynamic addresses.
- Topology view. A physical and a logical map of the Fabric, with devices, links and endpoints.
- Security Rating. Checks the Fabric's configuration against recommended practices and scores it, with links to fix each finding. Some checks need a FortiGuard subscription.
- Automation stitches. A trigger (an event) connected to one or more actions.
A logging destination is part of a working Fabric: a FortiAnalyzer, or a Fortinet cloud logging service. The topology, the Security Rating and several automation triggers depend on the logs it collects.
Building it: the root and a downstream FortiGate
In the GUI, the Fabric is set up from Security Fabric › Fabric Connectors, by editing the Security Fabric Setup connector. On the CLI, the root is enabled like this:
config system csf
set status enable
set group-name "NORTHGATE"
endRun on the root FortiGate. The group name identifies the Fabric. The interface facing downstream FortiGates must also allow Security Fabric connections (the fabric option in its administrative access).
config system csf
set status enable
set upstream "10.0.1.1"
endRun on a downstream FortiGate: upstream is the address of the FortiGate above it in the tree. The root administrator then authorises the new device, from the GUI notification or by pre-authorising its serial number.
⚠ Join devices to a Fabric in a planned change
Joining a Fabric changes how the downstream FortiGate is logged and, depending on settings, which objects it receives from the root. Back up both configurations first, and join production firewalls in a change window.
The Fabric concepts in this lesson are the same in FortiOS 7.4 and 7.6. Field names under config system csf have changed between major releases (older releases used upstream-ip), and connector names and options change from release to release. Check the CLI reference and the Security Fabric section of the administration guide for your build.
Automation stitches
New Automation Stitch
- Name
- Admin-login-failed-alert
- Status
- On
- Trigger
- FortiOS Event LogFires when a matching event log entry is written.
- Event
- Admin login failed
- Action
- EmailNeeds a working email server setting on the FortiGate.
- To
- netops@example.com
Trigger
Action
The "Fabric" value of a stitch shows when the trigger and the action come from different products: for example, FortiAnalyzer correlates logs and reports a compromised host, and the FortiGate quarantines that endpoint through FortiClient EMS or blocks it at the FortiSwitch port.
Integration examples
FortiAnalyzer: central logging
config log fortianalyzer setting
set status enable
set server "10.0.1.30"
set upload-option realtime
endThe FortiGate sends logs to FAZ1 in real time. The FortiGate must then be authorised on the FortiAnalyzer before logs are stored.
execute log fortianalyzer test-connectivityChecks whether the FortiGate can reach the FortiAnalyzer and whether it has been authorised. Read-only.
FGT1 # execute log fortianalyzer test-connectivity FortiAnalyzer Host Name: FAZ1 FortiAnalyzer Adom Name: root ... Connection: Allow ...
Learn more: Logging and Monitoring
FortiManager: central policy
config system central-management
set type fortimanager
set fmg "10.0.1.31"
endPoints the FortiGate at FMG1. On the FortiManager, the device is then added (or authorised) in Device Manager, and its configuration imported into a policy package.
From then on, policies and objects are edited on FortiManager and installed to the FortiGate. Local changes made directly on a managed FortiGate make the two copies differ, which FortiManager reports and you must resolve. FortiManager has its own course on RouteLearn, listed on the Fortinet courses page, mapped to the NSE 6 FortiManager 7.6 exam, the current FortiManager certification (it moved from NSE 5 to NSE 6 on 15 July 2026).
FortiSwitch through FortiLink
A FortiGate interface is configured as a FortiLink interface, and FortiSwitches connected to it are discovered and authorised. VLANs, switch port settings and port security are then configured on the FortiGate, and each VLAN appears as a FortiGate interface that policies can use. That makes segmentation at the access layer part of the firewall configuration, and lets an automation stitch act on a single switch port.
FortiClient EMS: endpoint posture in policies
A Fabric connector to FortiClient EMS lets EMS tell the FortiGate about each endpoint: who is logged in, which operating system and patch level, whether antivirus is running. EMS turns those facts into tags, and a firewall policy can use a tag as a source, for example "allow the finance server only from endpoints tagged compliant". This is the device check behind zero-trust access.
These tags have been called ZTNA tags, and in more recent releases EMS or security posture tags, and the GUI location has moved between releases. Check the administration guide for your FortiOS and EMS versions.
Verifying the Fabric
- Security Fabric › Physical Topology (and Logical Topology): every expected FortiGate, FortiSwitch and FortiAP appears, with its links.
- Security Fabric › Fabric Connectors: each connector shows its status; a connector that isn't up is flagged.
- Security Fabric › Security Rating: run the checks and review the failed items.
show system csf
show system central-management
show log fortianalyzer settingShows what is configured for the Fabric, FortiManager and FortiAnalyzer. Read-only: compare it with what you expect before troubleshooting the connection itself.
What can go wrong
A downstream FortiGate doesn't appear in the Fabric
Its upstream is set, but the root's topology doesn't show it.
Show the fix
Check, in order: the root has Security Fabric connections allowed on the interface the downstream device connects to; the path between them allows the Fabric connection (TCP 8013 by default); and the device has been authorised on the root. An unauthorised device waits for approval and is not part of the Fabric.
FortiAnalyzer receives no logs
The FortiGate is configured to log to FAZ1, but FAZ1 shows nothing.
Show the fix
Run execute log fortianalyzer test-connectivity. The usual causes are that the FortiGate hasn't been authorised on the FortiAnalyzer yet, or that a firewall between them blocks the logging connection (TCP 514 by default). Authorise the device on FAZ1 and check the path.
A FortiManager install overwrites a change
An administrator fixed a policy directly on the FortiGate; the next install from FortiManager undid it.
Show the fix
With central management, FortiManager holds the intended configuration. Make the change on FortiManager, or retrieve the FortiGate's configuration into FortiManager before the next install. Agree that managed FortiGates are changed through FortiManager only, except in emergencies that are recorded.
An automation stitch doesn't fire
A "Compromised Host" stitch exists, but nothing happens when a host is infected.
Show the fix
Some triggers depend on another product: a compromised-host trigger needs FortiAnalyzer to detect the host, and an EMS quarantine action needs the EMS connector. Check that the stitch is enabled, that its components are connected, and test it with a trigger you can produce yourself, such as a failed admin login.
Design guidance
- Start with logging. A FortiAnalyzer (or cloud logging) gives the Fabric its view; add it before anything else.
- Add FortiManager when manual changes stop scaling. Typically once several FortiGates share most of their policies.
- Keep management traffic on a management network. FortiManager, FortiAnalyzer and EMS belong in a protected segment, not on the user LAN.
- Buy for a requirement, not a logo. Each extra product brings licences, upgrades and skills to maintain.
- Plan versions together. FortiManager and FortiAnalyzer must run a release that supports the FortiOS version they manage; check the compatibility matrix before upgrading any part.
Best practices
- Learn each product by the problem it solves, and use the "which product" table when a requirement arrives.
- Make the edge FortiGate the Fabric root, and authorise every downstream device deliberately.
- Review the Security Rating regularly and fix the high-severity findings first.
- Test every automation stitch with an event you can trigger safely before relying on it.
- Upgrade in a supported order: managers and analysers first, then FortiGates, then access devices, following the release notes.
🛠 Practical exercise: map requirements to products and draw the Fabric
On paper, take these requirements for a fictional company with a head office and three branches: one-year log retention, consistent policies at all four sites, two-factor authentication for remote access, blocking access to the finance server from unpatched laptops, and an alert when a branch VPN goes down. For each requirement, name the product (or FortiGate feature) that meets it. Then draw the Fabric: which FortiGate is the root, which are downstream, which connectors exist, and one automation stitch with its trigger and action. If you have a FortiGate VM, open Security Fabric › Fabric Connectors and Security Fabric › Automation and identify which of your choices you can see there.
Key takeaways
- Each Fortinet product covers one job: FortiManager configures, FortiAnalyzer logs, EMS manages endpoints, and so on.
- FortiGuard Labs research reaches products as FortiGuard signatures and ratings.
- The Security Fabric has a root FortiGate, downstream devices and Fabric connectors to other products.
- Automation stitches link a trigger to actions, often across products.
- Integrations such as EMS posture tags let FortiGate policies use what other products know.
Check yourself
A company has 40 branch FortiGates whose policies have drifted apart. Which product addresses this directly?
A policy must allow the finance server only from laptops with up-to-date antivirus. Which combination provides that information to the FortiGate?
A downstream FortiGate has the root's address set as its upstream, but doesn't appear in the topology. The root shows a notification about a new device. What is missing?
execute log fortianalyzer test-connectivity reports that the FortiGate is not authorised. What do you do?
Which describes an automation stitch?