FortiManager and FortiAnalyzer: enterprise design that lasts (2026 guide)

A single FortiGate scales to a handful of devices. FortiManager (FMG) and FortiAnalyzer (FAZ) are the difference between dozens of firewalls and hundreds operated as one fleet — provided you size them, design the ADOMs, and wire the logs correctly from day one. This guide is the 2026 playbook we use in real deployments and in TechLeague tournaments.

When you actually need FortiManager and FortiAnalyzer

Rule of thumb that holds in production:

• ≤ 5 FortiGates, single site → FortiGate native GUI + free FortiCloud is enough.
• 6–25 FortiGates, multi-site → FMG starts paying for itself in change-window time alone.
• 25+ FortiGates, regulated or multi-tenant → FMG + FAZ are mandatory; not optional.

FMG centralizes configuration (policies, objects, VPN, SD-WAN, FortiAP/FortiSwitch). FAZ centralizes telemetry (traffic, threat, system, UTM logs and reports). They are two products on purpose: change management and forensics have different RPO/RTO requirements.

ADOM strategy: the single decision that defines your next 5 years

An ADOM (Administrative Domain) is a logical container for devices, policy packages, objects and admins. Get this wrong and every future merger, acquisition or audit hurts. Patterns that survive:

• Per business unit (preferred for enterprise): one ADOM = one BU = one policy package family. Maximises object reuse, simplifies RBAC, matches how the business is audited.
• Per region (preferred for global MSPs with regulatory zones): EU-ADOM, US-ADOM, APAC-ADOM, each with its own data-residency story for FAZ logs.
• Per tenant (MSP / colo): one ADOM per customer; combine with VDOMs on the FortiGate so a single chassis serves many tenants without leaking objects.
• Avoid per-site ADOMs. They look clean on day one and become unmaintainable by site 40 — duplicated objects, drifted policies, impossible global searches.

Enable Workflow Mode on every production ADOM. Every change becomes a session that must be approved before install. This is what turns FMG from a "GUI for the firewall" into actual change management.

Policy packages: header, footer and dynamic objects

The policy package is your unit of deployment. Two patterns that scale:

• Header / footer policies for global guardrails — deny-any-any to RFC1918 management, allow NTP/DNS to corporate resolvers, block known-bad GeoIPs. Centrally enforced; impossible for a site admin to disable.
• Per-site difference via dynamic objects (Per-Device Mapping). One obj-internal-net resolves to 10.10.0.0/16 in São Paulo and 10.20.0.0/16 in Madrid. Same policy package, different rendered config per device.

Keep policy package count low (target < 20 per ADOM). One package per topology archetype (HQ, branch, DMZ, OT zone), not one per site.

FortiAnalyzer sizing — the number nobody wants to compute

The sizing question is "how many GB/day of logs do I generate?". The honest formula:

• Average 400 bytes per traffic log, 1–2 KB per UTM/IPS event.
• A mid-size enterprise FortiGate (1 Gbps inspected) typically produces 5–15 GB/day of logs with web-filter and IPS enabled.
• Multiply by device count. Add 30% headroom. Multiply by retention window in days.

For 50 FortiGates × 10 GB/day × 365 days hot + 30% headroom = ~238 TB of usable disk. That is why FAZ-3700G and FAZ VM clusters exist. Compliance frameworks (PCI-DSS 12 months, HIPAA 6 years, LGPD 5 years) drive this more than traffic volume.

FAZ topology: collector + analyzer, not a single box

At scale, split the role:

• FAZ Collector receives raw logs from FortiGates at the edge / per region. Cheap disk, fast ingest, minimal analytics.
• FAZ Analyzer pulls aggregated/forwarded logs from collectors. Heavy CPU/RAM for reports, ML, SOC dashboards, FortiSoC playbooks.

This pattern keeps WAN log traffic local, gives you data-residency control per region, and lets you scale storage independently of analytics horsepower.

High availability that survives a real outage

• FMG HA: active-passive cluster, up to 5 nodes. Configuration database synced; one node owns writes. Place secondaries in a different fault domain (different rack, different AZ, different DC).
• FAZ HA: active-passive primary/secondary with full log sync. Plan disk identically — the secondary is useless if it can't hold the same retention window.
• Backups out of the cluster. Daily encrypted backup of FMG database to S3-compatible storage outside the Fortinet fabric. If a misconfiguration corrupts the cluster, HA replicates the corruption to the secondary; only an out-of-band backup saves you.

Log forwarding and SIEM integration

FAZ is not a SIEM replacement — it is the best front-end to a SIEM you will find for Fortinet fabrics. Wire it like this:

• syslog or CEF from FAZ to Splunk / QRadar / Sentinel / Chronicle. Forward only what your SIEM licence justifies — usually IPS, AV, web-filter, login events, admin actions.
• FortiSoC playbooks consume FAZ logs natively for automated containment (quarantine endpoint, block IOC across fleet, kick VPN session).
• FortiAnalyzer Fabric Connectors push enriched events to ServiceNow, Jira, MS Teams for ticketing.

For deeper SOC patterns see passkeys and modern auth and our FortiAnalyzer reports and SOC views guide.

Pitfalls we see every audit

• One ADOM per site (already covered — it is the #1 mistake).
• FAZ disk full on day 380 because nobody computed retention × growth.
• FMG cluster split-brain after a WAN flap — always use heartbeat over a dedicated path, never over the management interface that also carries config installs.
• No backup outside the cluster. HA is not a backup.
• Mixing FortiOS major versions across managed FortiGates without a tested FMG upgrade path. FMG must be at or above the highest managed FortiOS version.

A 90-day rollout that works

1. Days 0–15: design ADOM model, draft policy packages, size FAZ disk, build lab.
2. Days 15–45: onboard 10% of the fleet (one BU or one region). Validate workflow mode, dynamic objects, header/footer policies.
3. Days 45–75: onboard the rest. Cut over log forwarding from FortiGates direct → via FAZ.
4. Days 75–90: enable FortiSoC playbooks, wire SIEM, document runbooks, run a tabletop incident.

Train multi-vendor security operations and FMG/FAZ design under time pressure in a TechLeague tournament — it is the fastest way to turn this checklist into instinct.

Related reading

• FortiGate on Azure with GWLB
• FortiEDR architecture
• FortiDeceptor for early detection
• FortiDDoS appliance design
• FortiGate VDOMs: multi-tenant design
• FortiManager templates and ADOM design
• FortiAnalyzer reports and SOC views
• Passkeys overview