NSE7 Part 6: Central Management, ZTP and SD-WAN Manager on FortiManager

16 August 2026 NSE7Fortinet

The NSE5 series covers FortiManager fundamentals in depth: ADOMs, device registration and provisioning, device-level templates, and policy packages. This post assumes all of that and picks up exactly where the NSE 7 blueprint’s “Central management” domain actually starts: provisioning a branch with zero manual configuration, and the SD-WAN-specific tooling that turns a single hub-and-spoke design into a repeatable template applied across hundreds of spokes.

Zero-Touch Provisioning

ZTP solves a specific operational problem: an SD-WAN rollout to dozens or hundreds of branches can’t depend on a network engineer configuring each FortiGate by hand before shipping it, or even connecting to each one remotely on day one. ZTP means a FortiGate, out of the box, with only power and an internet-reachable WAN port, discovers its management FortiManager, authenticates, and pulls its full configuration automatically.

ZTP Basics

The discovery mechanism depends on deployment context. FortiGate units registered to a FortiCare account with FortiDeploy enabled discover their assigned FortiManager automatically via FortiGate Cloud’s provisioning service: the device phones home, FortiCare tells it which FortiManager (by serial number or IP/FQDN) to register to, and it does so without any local CLI input at all. For on-premises FortiManager without cloud-based FortiDeploy, the equivalent is DHCP option 138 or a pre-configured factory default pointing the FortiGate at a discovery FQDN, achieving the same “no console cable needed” outcome.

Once discovery succeeds, the branch FortiGate submits a registration request. On FortiManager, this shows up as an unauthorized device awaiting approval (Device Manager > Unregistered Devices), or, if a device blueprint was pre-staged against that unit’s expected serial number, the device is recognized and auto-assigned its configuration without manual approval at all.

Device Deployment with ZTP

The practical flow:

  1. Pre-stage a device blueprint on FortiManager: a template describing what a new device of a given role (branch type, region) should receive, covering interface mapping, SD-WAN template assignment, IPsec template assignment, and policy package assignment.
  2. Ship hardware to the branch, addressed by serial number to a blueprint if the rollout is large enough to warrant bulk pre-staging.
  3. Branch technician (non-networking staff, by design) racks and cables the unit, powers it on. No console access required.
  4. FortiGate discovers FortiManager, registers, and if a blueprint was pre-matched to its serial number, receives full configuration automatically.
  5. FortiManager pushes the install, and the branch is live.

Device Blueprints and CSV Import

For a handful of branches, matching blueprints to serial numbers by hand in the GUI is fine. For a genuine enterprise rollout (the scale this domain is actually testing for), FortiManager supports CSV import of the full device-to-blueprint mapping: serial number, hostname, assigned blueprint, and any per-device metadata variable overrides (a specific branch’s WAN IP, a specific branch’s site ID) all in one file, imported in bulk before a single unit ships. This is the mechanism that makes a 200-branch rollout operationally identical to a 5-branch rollout from FortiManager’s side: the same blueprint, replicated across every row of a spreadsheet.

SD-WAN Manager and Overlay Orchestration

Once devices are enrolled, FortiManager’s SD-WAN Manager (a dedicated module, distinct from ordinary Device Manager templates) is where the actual overlay design lives and gets pushed out.

Metadata Variables

The mechanism underneath everything else in this section: a metadata variable is a placeholder in a template ($sitename, $wan1-ip, whatever the design calls for) that resolves to a per-device value at install time, defined either per-device in Device Manager or per-row in the ZTP CSV import above. This is what makes one IPsec template or one SD-WAN overlay template describe the shape of every spoke’s configuration without describing any single spoke’s actual values, the same templating principle behind this site’s own Jinja-based SD-WAN orchestrator built outside FortiManager, applied here as FortiManager’s own native mechanism instead.

SD-WAN Core Settings on FortiManager

FortiManager’s SD-WAN templates configure the same zones/members/rules architecture covered in Part 5, but as a template object assignable to multiple devices rather than a single device’s local config. A core settings template defines the zone structure and member roles that every spoke of a given type shares; per-device metadata variables fill in what differs (actual WAN circuit IPs, actual ISP-assigned gateways).

Planning an SD-WAN Deployment with FortiManager

The blueprint calls out two distinct starting points, and the exam expects you to know which applies to a given scenario:

New SD-WAN deployments with a dedicated FortiManager (greenfield): FortiManager is stood up specifically for this rollout, ADOM structure and templates are designed from scratch against the target topology, and every device is enrolled fresh via ZTP as described above.

Converting an existing topology for SD-WAN with FortiManager (brownfield): devices already exist, already managed by FortiManager, running traditional (non-SD-WAN) routing. Converting means building the SD-WAN templates and metadata variable scheme to match the existing fleet’s actual per-site values, then migrating each device from its current config to the templated SD-WAN config, typically site by site rather than all at once, since a routing-architecture change against a live fleet is exactly the kind of change that benefits from a rollback plan.

Templates and Template Groups

Individual templates (SD-WAN core settings, IPsec, CLI templates for anything outside the GUI’s template coverage) can be bundled into template groups, assigned to a device or device group as a single unit rather than individually. A branch type (“small retail spoke,” “large distribution center hub”) maps to one template group, and every device of that type gets the whole bundle in one assignment, keeping the design’s actual complexity in the template group definition rather than repeated per-device configuration.

IPsec Templates

FortiManager ships purpose-built IPsec templates specifically for hub-and-spoke VPN deployment, distinct from hand-building config vpn ipsec phase1-interface on each device individually:

  • Describing available IPsec templates: FortiManager distinguishes single hub-and-spoke, dual hub-and-spoke (redundant hubs), and full-mesh topology templates, each generating the appropriate phase1/phase2 configuration set for every spoke automatically based on the template’s topology choice.
  • Using IPsec templates to configure hub-and-spoke VPN: assign the template to the hub device and the spoke device group; FortiManager generates the correct phase1 peer configuration on each side without an admin hand-writing matching phase1 blocks on dozens of spokes.
  • Configuring IPsec interfaces as SD-WAN members: the generated IPsec tunnel interfaces are automatically eligible for inclusion as SD-WAN zone members, which is the mechanical link between “an IPsec template built the tunnel” and “SD-WAN steers traffic across it,” covered from the SD-WAN side in Part 5 and from the routing side in Parts 8, 9, and 12.
  • IPsec template autorouting and metadata variables in IPsec templates: autorouting means the template can also push the routing configuration (static routes, or BGP neighbor statements where the template supports it) needed to actually use the tunnel, not just the tunnel itself; metadata variables here work the same as in SD-WAN templates, letting one template describe every spoke’s phase1 configuration with only the peer IP and PSK/certificate reference varying per device.

The SD-WAN Overlay Template

The SD-WAN overlay template is FortiManager’s higher-level object that combines IPsec template output with SD-WAN core settings into one coherent design: it’s the artifact that actually says “spokes tunnel to these hubs, using this IPsec design, and here’s how SD-WAN zones and rules treat the resulting tunnel interfaces,” rather than requiring the IPsec template and the SD-WAN template to be reasoned about as separate, manually-reconciled pieces. Dual-hub options within the overlay template (covered in more depth in Part 11) are where a redundant-hub design gets expressed once, at the template level, rather than replicated by hand across every spoke’s individual configuration.

Why This Domain Matters More Than Its Weight Suggests

Central management is 15-25% of the exam by the blueprint’s own numbers, lighter than routing or IPsec. But every mechanism in this post is what makes the routing and IPsec domains in Parts 8 through 12 operationally viable at the scale the exam’s scenario questions assume. A hub-and-spoke ADVPN design with BGP route reflection across fifty spokes is a reasonable design on a whiteboard; without metadata variables, device blueprints, and IPsec/overlay templates doing the actual replication, it’s fifty nights of hand-configuration. The exam’s routing and IPsec questions assume this domain’s tooling did the heavy lifting, which is worth keeping in mind when a scenario question seems to skip straight to “design the BGP topology” without mentioning how it got deployed.

Part 7 is the lightest domain by weight, security profiles, but it’s where the exam tests judgment about tradeoffs (SSL inspection strategy, performance cost) rather than configuration mechanics, a different kind of question from anything in this post.