Most FortiGate deployments I've inspected aren't insecure because of a missing feature — they're insecure because of policy drift. Rules get added under pressure, nobody removes the ones that are no longer needed, and six months later the rulebase is a record of every incident response ever done rather than a deliberate security posture. This is the checklist I actually run through.
Start with the policy list, not the dashboard
FortiOS's dashboard makes everything look healthy. The rulebase tells the real story. Pull the full policy list and look for:
- "Any" as a source, destination, or service. Every broad rule should have a name that explains why it's broad, and an owner. If nobody can explain it, it's a candidate for removal.
- Disabled-but-present rules. They accumulate for years. If a rule has been disabled for more than a quarter, delete it — Git history (or your change log) is a better place for it than the live config.
- Rules with zero hit count over a real observation window. FortiGate tracks hit counters per policy. A rule with no hits in 90 days is either dead or something you should be worried about.
Least privilege on outbound, not just inbound
Inbound rules get the scrutiny; outbound rules get rubber-stamped. That's backwards for ransomware and data-exfiltration scenarios, where the outbound leg is the one that matters. Segment by VLAN or address group, and write outbound policies that name the destinations and services a segment is actually allowed to reach, rather than a blanket "internal to internet, all services" rule.
IPS and application control aren't "set and forget"
Enabling an IPS profile on a policy is the easy part. The part that gets skipped:
- Set the profile to block, not just log, for signatures rated high and critical against server-facing policies.
- Review IPS sensor logs monthly, not just when something breaks. A sensor that never triggers is often a sensor that isn't actually inline on the traffic you think it's inline on.
- Pair IPS with application control on your general internet-egress policy — signature-based detection alone misses a lot of the traffic that matters.
VPN configuration: the two things that go wrong most
IPsec. Phase 1 and Phase 2 proposals left at their defaults tend to include weaker DH groups and ciphers than you'd choose deliberately. Pin the proposal list down to what your actual peer requires, and disable the rest — a shorter, deliberate list is easier to audit than a long compatibility list nobody re-reads.
SSL VPN. If you're still running SSL VPN in web-mode or tunnel-mode for remote access, two settings matter more than people think: enforce MFA at the portal (not just at the identity provider downstream), and restrict the portal to the source IP ranges you actually expect users to connect from, where that's feasible. SSL VPN portals are one of the most scanned and most exploited surfaces on the internet — treat the attack surface as hostile by default.
High availability doesn't mean high resilience
An HA pair in active-passive gives you failover for hardware faults. It does not, by itself, protect you from a bad config push, a corrupted policy, or an upstream ISP issue — those replicate to both members. A few habits that close that gap:
- Keep a config backup that's independent of the HA sync, on a schedule, off the cluster.
- Test failover deliberately, on a maintenance window, at least twice a year — not just when you're forced to during an actual outage.
- Monitor session count and CPU on the passive unit too. A cluster where only the active member is monitored is a cluster where you find out about a problem on the standby unit exactly when you need it most.
Log everything you'd need during an incident, and confirm it's actually landing somewhere
FortiAnalyzer or an external SIEM is only useful if the logs are actually arriving and retained long enough to matter. A quarterly check I run: pick a policy, confirm hits are logging, confirm those logs are visible in FortiAnalyzer, and confirm retention covers the window your incident response process assumes it does. Assuming logging works because it was configured correctly two years ago is how you discover gaps during the incident you actually needed them for.
The habit that matters most
None of the above is exotic. The FortiGate has supported all of it for years. The gap in most environments isn't capability — it's the recurring discipline of reviewing the rulebase, retesting failover, and confirming logging actually works, on a schedule, rather than only after something breaks.