NSE7 Part 2: Security Fabric at Enterprise Scale

16 August 2026 NSE7Fortinet

NSE4 introduces the Security Fabric as a concept: FortiGates and other Fortinet products registering into a topology, sharing telemetry, and showing up on one map. NSE 7 assumes you already know that and tests something narrower and more specific: can you actually wire the Fabric into the rest of an enterprise’s tooling and make it do something automatically, without a human clicking a button.

The blueprint names four use cases explicitly. All four show up in this post.

Fabric Connectors vs. External Connectors

A Fabric Connector is a first-class integration where the connected product speaks the Fortinet Security Fabric protocol natively and registers as a Fabric member, the same way a downstream FortiGate or a FortiAnalyzer does. It appears on the Security Fabric topology view, participates in root-to-downstream communication, and can both send and receive Fabric events.

An External Connector (sometimes called an SDN connector in the GUI, under Security Fabric > External Connectors) is a narrower integration: FortiGate polls or pushes to a third-party API to keep dynamic address objects current, without that third party being a Fabric member in the full sense. AWS, Azure, VMware NSX, Kubernetes, and generic REST API endpoints all fall into this category. The FortiGate treats the connector as a source of truth for a dynamic address object: a firewall address whose member IPs update automatically as the underlying cloud resource, VM, or pod set changes, rather than an admin editing an address group by hand every time an instance is added.

The distinction matters for the exam because a question describing “FortiGate automatically updates firewall policy as EC2 instances scale” is testing External Connectors and dynamic addressing, not Fabric Connectors and topology.

Automation Stitches

An Automation Stitch is FortiGate’s built-in trigger-action pairing: something happens (the trigger), FortiGate does something in response (the action), with no external orchestration tool required. Configured under Security Fabric > Automation in the GUI, or config system automation-trigger / config system automation-action / config system automation-stitch on the CLI.

Triggers include:

  • Event log: a specific log ID or event type occurring (IPS event, compromised host detected, config change, license expiry, HA failover)
  • Security Fabric event: device down, or a rating downgrade in the Security Fabric audit
  • CPU/memory/session threshold: a resource utilization trigger, evaluated against the FortiGate’s own system stats
  • Scheduled: a cron-style time trigger
  • IOC: a compromised host being flagged via the Indicator of Compromise service (correlating outbound traffic against FortiGuard threat intelligence)

Actions include email, SNMP trap, sending a Slack or Microsoft Teams message via webhook, quarantining an endpoint via FortiClient EMS, executing a CLI script, running a webhook against an arbitrary external system, or triggering a backup.

config system automation-trigger
    edit "high-cpu-trigger"
        set trigger-type event-based
        set event-type high-cpu
        set trigger-frequency high
    next
end

config system automation-action
    edit "run-diag-script"
        set action-type cli-script
        set script "diagnose sys top 5\ndiagnose firewall session list"
    next
end

config system automation-stitch
    edit "high-cpu-response"
        set trigger "high-cpu-trigger"
        set actions "run-diag-script"
    next
end

Use Case: Automated Configuration Backups

A scheduled trigger paired with a config-backup action pushes the running configuration to FTP, SFTP, SCP, or a Fabric-connected FortiManager on a schedule, independent of whatever backup cadence FortiManager itself runs. This is the kind of thing that sounds trivial until you’re the one explaining to an auditor why a change from six months ago has no corresponding backup on file.

Use Case: CLI Script on High CPU

The stitch above is the canonical high-CPU example from the blueprint. The point isn’t that FortiGate can run a script on a threshold trigger. It’s which diagnostic commands are worth capturing automatically before the CPU spike resolves itself and the evidence disappears: diagnose sys top, the session list, and diagnose sys load-balance status on NP-equipped platforms all belong in that action, because by the time a human logs in to investigate, the spike is usually already over.

Use Case: SAML SSO in the Security Fabric

FortiGate can act as a SAML Service Provider (SP) for GUI administrator login, with an Identity Provider (IdP, FortiAuthenticator, Azure AD, Okta, or another SAML 2.0 provider) issuing the assertion. Configured under System > Administrators > Create New > REST API Admin is a different thing entirely; the relevant path here is config system saml plus config system admin entries with set remote-auth enable and set sso-admin-profile.

In a Security Fabric with a root FortiGate and multiple downstream members, SAML SSO can be configured once on the root and inherited by downstream devices via Fabric-wide single sign-on, so an administrator authenticates once against the IdP and gets appropriate access across the whole Fabric rather than re-authenticating against every device individually. This is the enterprise-scale answer to the same identity problem FortiAuthenticator’s RADIUS service solves for network users, the same IdP-fronted pattern, applied to Fabric admin access instead of LAN access.

Use Case: Automated Quarantine with IoC Detection

FortiGate’s IoC service correlates outbound connections against FortiGuard’s threat intelligence feed and flags hosts making connections consistent with active compromise (C2 beaconing patterns, known-bad destinations). On its own, IoC detection just raises an event log entry. The blueprint’s use case is wiring that event into an Automation Stitch whose action quarantines the host, either at the FortiGate itself (banning the source IP or moving it to a quarantine VLAN) or, more usefully in an enterprise deployment, via a FortiClient EMS action that isolates the endpoint at the OS level regardless of which network segment it reconnects to.

The distinction worth holding onto for the exam: IoC detection is a network-side observation (FortiGate sees the traffic pattern), while the quarantine action can be either network-side or endpoint-side depending on what’s wired into the stitch. A question describing “an infected host must be isolated even if it moves to a different VLAN” is pointing at the EMS/endpoint action, not a FortiGate-local one.

Use Case: FortiNAC Dynamic Firewall Addressing

FortiNAC profiles endpoints and enforces access at the switch/AP port level via VLAN assignment and CoA. Wired into the Security Fabric as a Fabric Connector, FortiNAC can also push host group membership to FortiGate as dynamic firewall addresses, so firewall policies can reference “FortiNAC host group: Unmanaged-IoT” as a source object the same way they’d reference a static address group, except the membership updates automatically as FortiNAC’s profiling reclassifies devices.

This closes a gap that port-level VLAN assignment alone doesn’t: VLAN assignment controls which broadcast domain a device lands in, but firewall policy between VLANs still needs to know which addresses within that VLAN are worth treating differently. Dynamic FortiNAC addressing means a policy written once continues to apply correctly as the actual population of “unmanaged IoT devices” on that VLAN changes underneath it.

Use Case: Adding FortiNDR to the Security Fabric

FortiNDR (Network Detection and Response, the current name for what was previously badged FortiAI) applies machine-learning-based traffic analysis to detect anomalies that signature-based IPS misses, particularly novel malware and lateral movement patterns. As a Fabric Connector, FortiNDR’s detections feed into the same Automation Stitch trigger surface as native FortiGate events (via Security Fabric event triggers), and FortiNDR can in turn consume FortiGate’s traffic mirror or tap output as its analysis input.

The exam-relevant point: FortiNDR doesn’t replace IPS or the IoC service, it sits alongside them and is one more trigger source feeding the same stitch mechanism this whole post has been building on top of. An enterprise Fabric with FortiNAC handling access-layer profiling, FortiNDR handling anomaly detection, and Automation Stitches wiring both into quarantine actions is the composed picture the blueprint’s “Implement the Fortinet Security Fabric” task is actually testing, not any one product in isolation.

Where This Sits in the Bigger Design

Every one of these use cases assumes a working Fabric topology and a root FortiGate that downstream members register to. That part is NSE4-level configuration and won’t get re-covered here. What NSE 7 adds on top is the automation layer: turning passive visibility (a device shows up on the topology map, an event shows up in the log) into an active response that doesn’t wait for someone to be watching. That’s also the throughline into Part 3, where the same instinct, don’t wait for a human to react, shows up again in how FGSP session synchronization keeps state consistent across two FortiGates without any orchestration layer at all.