Protecting the FortiGate itself is a domain-one skill, and it turns on four independent controls: admin profiles, trusted hosts, multi-factor authentication and a password policy. Each answers a different question, and the exam often gives you a scenario and asks which one applies. Keeping them straight is the whole battle.
An administrator profile (also called an access profile) controls what an admin may do. It grants read, read-write or no access per feature area: System, Firewall, Log & Report, Security Profile, VPN, and so on. The built-in super_admin profile grants full read-write everywhere and cannot be edited. For an auditor who must see logs but change nothing, you create a custom profile with read-only access to Log & Report and assign it to that account. Profiles control what, not where.
Trusted hosts control where an admin may log in from. Each account can list up to a small number of source subnets (for example 10.10.99.0/24); once any trusted host is set, logins from any other source are refused, even with the correct password. This is the most direct way to enforce a rule like 'admins may only manage from the management subnet'. If every entry is left at 0.0.0.0/0, the account can log in from anywhere, which is the risky default to watch for.
Multi-factor authentication (MFA), sometimes called two-factor, adds a second proof beyond the password, typically a FortiToken one-time code or an email code. It defends against stolen or guessed passwords but does not restrict source networks, so it is not the answer to a 'from which subnet' question.
The password policy sets complexity and lifetime rules, minimum length, required character classes, and expiry, applied to admin passwords (and optionally IPsec pre-shared keys). It raises the cost of guessing but again says nothing about source or authorization.
A strong build combines all four: least-privilege profiles, trusted hosts locking management to a jump network, MFA on every admin, and a password policy. In a lab you will create a read-only Log & Report profile, add a trusted host to your own account, and enable a token, then confirm each control does exactly what its name says.
Key terms
- Admin profile (access profile)
- Per-feature read/read-write/none permissions that define what an administrator can do; super_admin is the full built-in profile.
- Trusted hosts
- A per-account list of allowed source subnets; once set, logins from any other address are refused.
- MFA / two-factor for admins
- A second login factor (such as a FortiToken code) that protects against stolen passwords but does not limit source networks.
- Password policy
- Rules for admin password length, complexity and expiry.
An auditor needs to read logs but must not change anything, so you assign a custom profile with read-only Log & Report access, add a trusted host for the audit subnet, and require a FortiToken at login.
Check yourself
Which control lets you require that admins log in only from 10.10.99.0/24?
Trusted hosts on each admin account; other source addresses are then refused regardless of the password.
An admin must view reports but change nothing. What do you create?
A custom admin profile with read-only access to Log & Report, assigned to that account.
Does MFA restrict which network an admin can log in from?
No. MFA adds a second authentication factor but does not limit source addresses; trusted hosts do that.