The Complete Firewall Rule Audit Checklist for 2026

Firewall rules accumulate like technical debt. A rule added three years ago for a contractor who's long gone, an "allow all" rule someone added during a late-night troubleshooting session, a default deny that was never actually enabled — these aren't hypothetical. They exist on most production firewalls right now.

The problem isn't that teams don't know they should audit. It's that auditing is tedious, manual, and easy to postpone. This checklist makes it concrete.

The 15 Critical Checks

1. Allow-All Rules

Search for any rule where source, destination, and service are all set to "any." A single allow-all rule effectively disables your firewall. This is the most common critical finding in production environments — and the easiest to fix.

What to look for: Rules with source=any, destination=any, service=any, action=permit. On FortiGate, check for set srcaddr "all" with set dstaddr "all".

2. Missing Default Deny

Every firewall should end with an explicit deny-all rule. Without it, any traffic that doesn't match a specific rule is implicitly allowed on some platforms — or silently dropped without logging on others. Either way, you have a visibility gap.

3. Disabled Rules

Disabled rules aren't harmless — they're a sign of policy drift. Someone turned them off instead of removing them, which means nobody is confident enough to delete them. Audit disabled rules quarterly and remove any that have been off for more than 90 days.

4. Duplicate Rules

Two rules that match the same traffic create confusion during incident response. "Which rule is allowing this traffic?" becomes a harder question when the answer is "both." Deduplication also simplifies your policy and improves processing performance.

5. Shadowed Rules

A shadowed rule is one that can never match because a broader rule above it catches all the same traffic first. Shadowed rules are dead weight, but they're also evidence of policy misunderstanding — the person who added the shadowed rule thought it was doing something.

6. No Logging Enabled

Rules without logging are invisible to your SIEM. If an incident occurs, you'll have no record of what traffic was allowed or denied by that rule. Every permit rule should log. Every deny rule should log. No exceptions for production.

7. Insecure Protocols

Telnet (port 23), FTP (port 21), HTTP (port 80 for management), SNMPv1/v2 — these protocols transmit credentials in cleartext. If your firewall rules allow these protocols across trust boundaries, you have a credential exposure risk.

8. Broad Egress Rules

Outbound rules are often more permissive than inbound. An "allow all outbound" rule means any compromised internal host can exfiltrate data to any destination on any port. Lock down egress to known-good destinations and services.

9. Overly Broad Subnets

A rule allowing traffic from 10.0.0.0/8 when only 10.1.5.0/24 needs access is a 65,000x larger attack surface than necessary. Tighten source and destination networks to the minimum required.

10. Stale Rules

Rules that haven't matched traffic in 90+ days are candidates for removal. Most firewalls track hit counts — use them. A zero-hit rule either protects nothing or applies to traffic that no longer exists.

11. Unrestricted Services

Rules that allow "any" service when only specific ports are needed. A rule meant for HTTPS should specify port 443, not "any." Every unnecessary open port is a potential attack vector.

12. Missing Descriptions

A rule without a description is a rule nobody understands six months later. Require a business justification for every rule: who requested it, when, and why. This isn't just good practice — PCI-DSS 4.0 requires it.

13. Rule Complexity

A single rule with 50 source addresses, 30 destination addresses, and 20 services is technically functional but operationally unmanageable. Complex rules should be broken into logical groups with clear naming.

14. Device Hardening

Beyond rules, check the firewall's own configuration: is management access restricted? Are unused interfaces disabled? Is the firmware current? Is the admin password not "admin"?

15. Compliance Mapping

For every finding, map it to the relevant compliance control — PCI-DSS 1.2.1, NIST AC-4, CIS Control 4.4. This turns a technical finding into business risk that stakeholders understand.

How Often Should You Audit?

PCI-DSS requires firewall reviews every six months. But rules change faster than that. Best practice: automated weekly scans for critical issues (allow-all, missing deny), quarterly full audits with compliance mapping, and annual deep review with remediation planning.

Automating the Process

Running these 15 checks manually across multiple firewalls and vendors is a full-day project. Tools like ShieldIQ automate the entire checklist — upload a config, get a scored report with compliance mapping in 60 seconds. The same 15 checks, every time, across 11 vendors.