FortiManager and FortiAnalyzer Hardening Guide: FGFM Exposure, Admin Access and Logs

FortiManager and FortiAnalyzer hold the keys to every FortiGate they manage and the logs that would show misuse, so a weakly protected manager turns one appliance into a fleet-wide foothold. Hardening the firewalls alone does not cover this: the manager pushes policy, scripts and firmware to devices over the FortiGate-to-FortiManager (FGFM) protocol, and the analyser stores the evidence your SOC relies on. This guide covers the customer-side controls for both products: FGFM exposure, administrator and API access, encryption settings, change control, log integrity and monitoring. It is written for network security engineers, firewall administrators and the SOC teams who depend on Fortinet logs, and it assumes the firewall itself is already hardened as described in the FortiGate Hardening Guide.

This is an independent guide from NHI Mgmt Group, based on Fortinet's public documentation as of November 2026. It is not sponsored or reviewed by Fortinet. Product features change, so confirm settings against Fortinet's current documentation.

Key takeaways

• Treat TCP/541 as a privileged channel. FGFM is how FortiManager controls devices; keep it off the internet where you can, and where you cannot, turn on fgfm-deny-unknown and a custom FGFM certificate.
• Every administrator needs a trusted host. One account without trusted hosts reopens administrative access on every interface where it is allowed, so the control only works when applied to all accounts.
• API administrators are non-human identities. REST API admins with tokens should get a narrow admin profile, read-only rpc-permit where possible, trusted hosts and an owner, never a shared Super_User key.
• Change control belongs in the tool. Workflow mode makes Device Manager and Policy & Objects read-only until a session is approved, which turns policy pushes into reviewable events.
• Logs are only evidence if they are protected. Send FortiGate logs over reliable, encrypted OFTP, turn on log checksums, block unregistered log devices and forward the managers' own event logs off-box.

Why the manager is a different risk from the firewall

A FortiGate controls traffic through one site. FortiManager holds the configuration, policy packages, scripts and firmware images for many FortiGates and can install changes to all of them, which makes it a software deployment tool in the ATT&CK sense (T1072 Software Deployment Tools). FortiAnalyzer receives logs from those devices and from FortiManager itself, so control of it lets an intruder read reconnaissance data or remove evidence.

The exposure points are specific and few, which makes them manageable:

• FGFM listener: FortiGates connect to FortiManager on TCP/541 (IPv4) and TCP/542 (IPv6). This is the device management channel, and it is often exposed to the internet so that branch and remote FortiGates can reach a central manager.
• Administrative interfaces: GUI and JSON API on TCP/443 (and TCP/80 if allowed), SSH on TCP/22, the web service API on TCP/8080 and SNMP on UDP/161.
• Log intake on FortiAnalyzer: OFTP and syslog on TCP and UDP 514, plus management traffic from FortiManager on TCP/541.
• Local FortiGuard service: when FortiManager acts as a local FortiGuard distribution server it listens on extra ports such as TCP/8888, TCP/8890 and TCP/8900 for updates and rating queries.
• Credentials held: administrator accounts, REST API tokens, device credentials and the certificates used for FGFM and OFTP.

Public-facing management services are a recurring initial access route (T1190 Exploit Public-Facing Application, T1133 External Remote Services), and stolen administrator or API credentials map to T1078 Valid Accounts. The Edge Device Security Guide covers this risk class across vendors; the rest of this page is the Fortinet manager and analyser specifics.

Reduce FGFM and network exposure

Fortinet's FortiManager 7.6 hardening guidance gives a clear order of preference: reach FortiManager through a VPN between FortiGates so FGFM uses internal addresses, and if TCP/541 must be exposed publicly, enable the deny-unknown setting. Work through the options below from the strongest down.

FGFM settings that matter

• Deny unknown devices: under config system global, set fgfm-deny-unknown enable makes FortiManager accept FGFM connections only from devices already in Device Manager. Fortinet notes it does not remove devices already in the Unauthorized Devices list, so clear that list as a separate step.
• Serial number check: by default FortiManager requires the FortiGate certificate to contain the device serial number, and Fortinet recommends leaving this on. The option to turn it off, fgfm-peercert-withoutsn, is no longer available from FortiManager 7.6.2, where the check always applies. On older versions, if it has been turned off, Fortinet's guidance is that FortiManager should not be reachable from the internet.
• Exclusive custom certificate: set fgfm-ca-cert with set fgfm-cert-exclusive enable means only FortiGates holding a certificate from your CA can connect. Plan certificate distribution before enabling it, because devices without the certificate are refused.
• Protocol version: set fgfm-ssl-protocol tlsv1.2 (or the version your policy requires) for the FGFM tunnel.
• NAT: where FortiManager sits behind NAT, configure its dedicated public IP so tunnels establish correctly rather than opening broader rules to make them work.

Close what you do not use

• Interfaces: disable unused interfaces and remove HTTP, SNMP, SSH or web service access from interfaces that do not need them (allowaccess per interface).
• Local FortiGuard service: if FortiManager serves updates, set unreg-dev-option ignore under config fmupdate fds-setting so unregistered devices cannot pull updates or rating queries, and set fds-ssl-protocol to TLS 1.2 or later.
• Upstream filtering: place both appliances behind a firewall; Fortinet suggests a FortiGate with antivirus and IPS profiles applied to the management traffic.

Administrator access and API identities

FortiManager and FortiAnalyzer share the same administrator model: local or remote (RADIUS, LDAP, TACACS+, SAML) accounts, each with an admin profile and access to one or more administrative domains (ADOMs). There is no password recovery mechanism from version 5.4.0, so credential custody and a tested break-glass account are part of hardening, not an afterthought.

Human administrators

• Named accounts: one account per person for traceability; disable or rename shared defaults once named accounts exist.
• MFA: require multi-factor authentication for every administrator. Fortinet's guidance references FortiAuthenticator; remote authentication through your identity provider achieves the same aim.
• Trusted hosts: set them on every account. Fortinet's documentation is explicit that if all administrators have trusted hosts the unit does not respond to administrative access from elsewhere, but if even one administrator is unrestricted, access attempts are accepted on any interface with administrative access enabled. Use a single management subnet or a /32 per jump host.
• Lockout and timeouts: admin-lockout-threshold and admin-lockout-duration under config system global (Fortinet's example is 2 attempts and 120 seconds), plus a short idle timeout.
• Password policy: minimum length, character classes and expiry for local accounts, aligned with your wider policy.
• Least privilege by ADOM and profile: give operations staff profiles restricted to their ADOMs and read-only where they only need visibility; keep Super_User for a small, named group.

REST API administrators

From FortiManager 7.2.2, API administrators can authenticate with a token. Fortinet documents creating them under System Settings > Admin > Administrators > Create New > REST API Admin, or with config system admin user, set user_type api, a profileid, an rpc-permit level and trusthost1 to trusthost10. The key is generated with execute api-user generate-key <name> and presented as a bearer token or an access_token URL parameter.

Treat each API admin as a non-human identity with an owner, purpose and review date. See the Secrets Management Guide for storage patterns.

Encryption and transport settings

Both products expose the same global cipher and protocol controls. Fortinet's 7.6 hardening pages give this baseline:

Before tightening, check the oldest FortiOS version in the managed estate supports the protocol you set, or those devices will drop off management. Replace the factory certificate on the GUI with one from your internal CA so administrators can detect interception.

Change control with workspace and workflow modes

A manager that can push policy to every firewall needs the same change discipline as a production deployment pipeline. FortiManager provides this natively:

• Workspace mode: administrators must lock an ADOM or policy package before editing, which prevents concurrent edits and records who held the lock.
• Workflow mode: set workspace-mode workflow (all ADOMs) or set workspace-mode per-adom then enable per ADOM in the GUI. In workflow mode Device Manager and Policy & Objects are read-only until an administrator starts a workflow session, and sessions go to approval groups with email notification. Changing the mode ends your login session, so schedule it.
• Install previews: require reviewers to read the install preview, not only the policy diff, because the preview shows the CLI that will reach the device.
• Script governance: CLI scripts run against many devices at once; restrict who can create and run them, and review them like code.

The approach maps to configuration management practice in NIST CSF 2.0 PR.PS-01 and fits the review cadence in the Firewall Management Guide.

Log integrity and FortiAnalyzer intake

FortiAnalyzer is often the only long-term record of what happened on the firewalls. Protect what arrives and what is stored:

1. Encrypt log transport. By default, Fortinet documents that OFTP control traffic uses TCP/514 with TLS while log traffic uses UDP/514 unencrypted. On each FortiGate, set reliable enable under config log fortianalyzer setting sends logs over TCP with TLS. Fortinet cautions that this reduces logging performance, so size FortiAnalyzer for it.
2. Turn on checksums. set log-checksum md5-auth (or md5) under config system global records a hash for each log file when it rolls or is sent; the default is none. Verify with execute log-integrity.
3. Refuse unknown senders. set detect-unregistered-log-device disable stops FortiAnalyzer (or FortiManager with analyser features) accepting logs from devices it does not know, which blocks log flooding and spoofed records.
4. Forward off-box. Send FortiAnalyzer and FortiManager event logs, especially administrator logins, configuration changes and API calls, to a separate SIEM or log store that the Fortinet administrators cannot alter. See the Log Management and Retention Guide for retention periods.
5. Keep time consistent. Configure NTP on both appliances (config system ntp) so device, manager and SIEM timestamps line up during an investigation.

Where identity fits

Most of the fleet-wide risk in this guide is an identity problem: who can log in, from where, with what profile, and which machine credentials (API tokens, FGFM certificates, device credentials) can act without a human present. Inventory every administrator and API admin on both appliances, link each to an owner and a remote identity source where possible, and review them on the same cycle as other privileged accounts. The Privileged Access Management Guide covers the review model.

Implementation plan

1. Inventory (week 1): list both appliances' versions, interfaces with allowaccess, public exposure of TCP/541, 542, 443, 22 and 514, all administrator and API accounts, and current fgfm-* and log-checksum settings.
2. Apply security updates: bring FortiManager and FortiAnalyzer to a supported release using Fortinet's upgrade path, and subscribe to the FortiGuard PSIRT advisories so future updates are applied promptly.
3. Restrict administrative access: trusted hosts on every account, MFA, lockout, idle timeout; test from a non-trusted host that the GUI and SSH do not respond.
4. Constrain FGFM: move devices to VPN-based management where possible; otherwise enable fgfm-deny-unknown, clear the Unauthorized Devices list and plan the custom certificate rollout in a pilot ring of a few FortiGates first.
5. Tighten crypto: apply the TLS settings in a maintenance window after confirming every managed FortiOS version supports them. Roll back by restoring the previous value if devices lose connection.
6. Re-scope API admins: create least-privilege profiles, regenerate keys, move them into a secrets manager, then delete the old accounts.
7. Enable workflow: start per ADOM with one team, then extend to all ADOMs.
8. Protect logs: reliable OFTP on a pilot group of FortiGates, watch FortiAnalyzer load, then roll out; enable checksums and off-box forwarding.
9. Back up: take configuration backups of both appliances before and after the changes and store them encrypted outside the appliances.

Small vs large estates: a small organisation with one FortiManager and a handful of sites can usually reach the private-management pattern in a day and skip workflow approvals in favour of a second-person review. Large or managed-service estates should prioritise custom FGFM certificates, ADOM separation per customer or region, and workflow mode, because one compromised administrator touches more devices.

Detection and measurement

Watch for these events in FortiManager and FortiAnalyzer event logs, forwarded to your SIEM:

• Administrator activity: logins from outside the jump host range, failed login bursts (T1110 Brute Force), new administrators or API admins, profile changes, and key generation.
• Device registration: new entries in the Unauthorized Devices list or unexpected device additions to Device Manager.
• Fleet changes: policy installs and script runs outside approved workflow sessions or change windows.
• Logging gaps: devices that stop sending logs, sudden drops in log volume, or changes to log settings on FortiGates.
• Appliance behaviour: unexpected outbound connections from the management appliances or unfamiliar files, handled with the Edge Device Compromise Investigation Playbook.

Common failure patterns

• One account without trusted hosts: a legacy or vendor account left unrestricted reopens the GUI and SSH on every interface where access is allowed.
• FGFM published for onboarding and never closed: TCP/541 left open with deny-unknown off after a rollout project, accepting connections from any device.
• Super_User API keys in scripts: integration tokens with full read-write rights across all ADOMs, stored in code repositories or URLs.
• Logs only on the appliance: FortiAnalyzer as the sole copy of firewall and manager logs, so whoever controls it controls the evidence.
• TLS tightened without a version check: older FortiOS devices drop off management after a protocol change, and the change is reverted wholesale rather than fixed.
• Unaudited CLI scripts: scripts that change many devices at once run by anyone with policy rights, with no review.

Framework mapping

Practitioner checklist

• Confirm TCP/541, 542, 443 and 22 exposure from outside, and remove any public administrative access.
• Enable fgfm-deny-unknown wherever FGFM is reachable from untrusted networks, and clear the Unauthorized Devices list.
• Set trusted hosts, including IPv6, on every administrator and API admin account.
• Require MFA for all human administrators and configure lockout and idle timeout.
• Replace Super_User API keys with scoped profiles, read-only rpc-permit where possible, and keys held in a secrets manager.
• Apply the enc-algorithm high and TLS 1.2 or later settings after checking managed FortiOS versions.
• Turn on workflow mode for production ADOMs and restrict CLI script rights.
• Enable reliable OFTP on FortiGates, log-checksum on FortiAnalyzer and block unregistered log devices.
• Forward manager and analyser event logs to a separate SIEM and alert on admin and device registration changes.
• Apply Fortinet security updates promptly and keep encrypted configuration backups off the appliances.

Standards and references

• Fortinet: FortiManager 7.6.0 Best Practices, Security hardening
• Fortinet: FortiAnalyzer 7.6.0 Best Practices, Security hardening
• Fortinet: FortiManager incoming ports
• Fortinet: FortiAnalyzer incoming ports
• Fortinet: FortiManager authentication tokens for API administrators
• Fortinet: FortiAnalyzer Log Integrity and Secure Log Transfer
• Fortinet: FortiManager Enable workflow mode
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: FortiGate Hardening Guide · Edge Device Security Guide · Firewall Management Guide · Log Management and Retention Guide · Secrets Management Guide