FortiGate - Admin MFA

Yes, this is common and fully supported, and Conditional Access plus ITDR on interactive admin login is the right reason to do it. A few things from running it that are worth knowing before you flip the fleet over.

Break-glass is non-negotiable. SAML covers the GUI login only. Keep at least one local super_admin per device, locked down with trusted hosts, for the cases that will lock you out otherwise: an Entra outage, a token-signing certificate expiry, or an SP/ACS misconfig. The login page keeps the local credential path next to the SSO button. Test that fallback before you rely on it.

SAML is GUI-only, and that is the biggest functional caveat. SSH, console and the API do not use SAML. Those still authenticate locally or via RADIUS/TACACS+. So you cannot fully retire local admin auth, and your CA and ITDR coverage does not extend to CLI, console or API access. Restrict SSH to your management network or trusted hosts to compensate. A clean pattern is SAML plus CA for the GUI, and a FortiToken-protected local break-glass account for the console/SSH path.

Per-device SP sprawl is the real cost at fleet scale. Each FortiGate is its own SAML SP with its own entity ID, ACS URL and certificate, and the SP address is the admin GUI port and has to be reachable from the IdP over the WAN. Administrators have to be present on each SP, so across a fleet that is a lot of enterprise apps and certs to track. Two ways to cut it down: use the wildcard SSO admin approach, "match all users on remote server" with accprofile and adom override driven by SAML attributes, so you are not pre-creating every admin on every box; and at scale, strongly consider putting FortiAuthenticator in front as the SAML IdP and federating it to Entra, so the gates all point at one FortiAuthenticator SP instead of each integrating with Entra directly. You still get Conditional Access because the FAC-to-Entra leg is the Entra authentication. FortiManager can also push the per-device SAML config. Fortinet + 3

Group-to-profile mapping has gotchas. You map Entra groups to FortiGate admin profiles via the group claim, but the group-name attribute on the FortiGate has to match exactly what Entra returns, and you have to explicitly emit the groups claim in the app. Watch the Entra group overage limit: once a user is in more than roughly 150 groups, Entra stops sending the groups claim and sends a Graph link instead, which the FortiGate cannot follow, and the admin silently lands on no-access. Use groups assigned to the application, or app roles, to avoid that. Also keep the username claim stable, it must match the admin username exactly, commonly the UPN, so UPN changes or alias mismatches will lock people out. FortinetFortinet

Operational fragility to plan for: the IdP signing certificate and the SP cert expire, and when they do, admin SSO breaks across every gate at once and you are on break-glass, so monitor cert validity. SAML is also time-sensitive, so the gates need solid NTP or assertions fail on the notBefore/notOnOrAfter window, which shows up as intermittent, hard-to-explain login failures.

Net: worth doing for the CA and ITDR gain on interactive admin access. Just keep a FortiToken-protected local break-glass for the non-SAML paths, and at fleet scale put FortiAuthenticator in the middle rather than standing up one Entra app per FortiGate.