FortiGate Address Object Cleanup: Audit and Remove Stale IP and FQDN Definitions
FortiGate configurations accumulate unused address objects for years, creating policy noise and audit risk. This checklist walks operators through identifying zero-reference objects, safely purging them, and preventing future bloat.
FortiGate configurations grow in one direction. Firewall engineers add address objects for projects, migrations, and one-off exceptions, but deletions rarely follow decommissions. After two or three years on a busy FortiGate, it is common to find 40% or more of all address objects referenced in zero active policies. That dead weight complicates audits, slows policy reviews, and creates confusion when engineers misread an old object as authoritative.
This checklist covers the full cleanup cycle: discovery, validation, removal, and prevention. It applies to FortiOS 7.x running on any hardware or VM platform. All CLI commands assume an admin account with read-write access to the firewall policy and object tables.
Before You Start
Take a configuration backup before touching anything. Run execute backup config ftp or pull the backup through FortiManager if you manage at scale. Confirm the backup restores cleanly in a lab or staging unit before proceeding on production.
The Cleanup Checklist
-
Export the full address object list. Run
show firewall addressandshow firewall addrgrpfrom the CLI and redirect output to a file. If you manage multiple VDOMs, repeat per VDOM withconfig vdom / edit <name>context active. This gives you the raw inventory you will cross-reference against policy usage. -
Identify zero-reference objects using the built-in unused-objects report. In FortiOS 7.2 and later, navigate to Policy & Objects > Addresses, then use the column filter "Referenced" and set it to 0. In the CLI,
diagnose firewall iprope lookupcan help spot objects missing from compiled policy tables. For FortiOS versions below 7.2, export the policy table withshow firewall policyand write a diff against the address list manually or via a script. -
Check references beyond firewall policies. An address object showing zero firewall policy references may still be active in VPN phase-2 selectors, SSL-VPN split tunnels, traffic shaping policies, or SD-WAN rules. Before marking any object for deletion, run:
grep -i "<object-name>" <full-config-export>against a full
show full-configurationexport. Objects appearing only in comment fields are safe to remove; objects appearing in any non-policy stanza are not. -
Validate IP and FQDN currency. For IP-type objects, cross-reference against your IPAM or cloud console. For FQDN-type objects, resolve each hostname. FQDNs that no longer resolve, or that resolve to IPs outside your managed ranges, are strong candidates for removal regardless of reference count. A stale FQDN object that still appears in a policy is more dangerous than an unused one, because FortiOS will silently match nothing rather than raise an error.
-
Stage deletions in a change window, not ad hoc. Batch your confirmed removals into a single change window. Use
config firewall address / delete <name>for individual objects or prepare a script using the FortiGate REST API (DELETE /api/v2/cmdb/firewall/address/<name>). Run deletions in a maintenance window with traffic monitoring active so you can catch any unexpected drops within the first 15 minutes. -
Remove or flatten stale address groups. After removing individual objects, audit address groups with
show firewall addrgrp. Groups that now contain zero members, or groups whose only members were just deleted, must be removed explicitly. FortiOS does not automatically dissolve an address group when its last member is deleted; it leaves an empty group that can cause policy compilation warnings. -
Document the baseline. Record the pre-cleanup object count, the post-cleanup count, and the date. Export the cleaned configuration as your new baseline. Retrievy's FortiGate hygiene checks can track object count drift against this baseline on a scheduled cadence, flagging net-new objects that go unreferenced for more than 30 days.
-
Establish a creation gate going forward. Require a naming convention that embeds a ticket or project identifier (for example,
PROJ-4821_webserver-dmz). Set a calendar reminder or automated check to review objects older than 90 days with zero references. The naming convention makes the next audit take minutes instead of hours.
What This Does Not Cover
This checklist addresses address objects and address groups only. Service objects, schedule objects, and application signatures accumulate the same kind of bloat and deserve their own pass. Treat this cleanup as the first phase of a broader FortiGate configuration hygiene programme, not a one-time fix.
Keep reading in Articles