What 280 Enterprise Firewall Migrations Taught Me About Rule Sprawl
After 280 enterprise firewall migrations across Germany, Austria, and Switzerland, I keep seeing the same thing: the firewall itself is fine. The rulebase is a disaster. Rule sprawl — accumulated over years of incidents, vendor changes, and undocumented one-offs — is the single biggest cost multiplier in every migration I have ever run.
This is not a theoretical problem. Every number below comes from real enterprise environments, mostly DACH-region companies in financial services, manufacturing, and critical infrastructure. The patterns are consistent enough that I can predict the state of an estate before pulling a single config.
What the Data Actually Looks Like
The average enterprise firewall estate I migrate has been running for seven to twelve years before the project starts. In that time, rules accumulate. Nobody removes them. The risk of breaking something always outweighs the benefit of cleaning up. So the rulebase grows.
What I typically find in a 10-year-old enterprise rulebase:
- 47%of rules have not matched traffic in over 180 days. Most of these are genuinely dead. Some are disaster recovery paths that only activate during incidents.
- 23%are shadow rules — rules that are never reached because a broader rule above them matches first. They do nothing. They cost nothing in performance terms, but they create false confidence during audits.
- 61%have no business justification on file. The rule exists. The engineer who added it left in 2018. Nobody knows why it is there. Removing it feels too risky.
- 12%were added during incidents and never reviewed afterwards. These are the dangerous ones — emergency rules that opened temporary access, never closed.
These numbers are averages. I have seen estates where 70% of rules are unused. I have seen financial services companies with rules dating back to Windows XP migrations. The age of a rule is not the problem. The absence of documentation is.
The Five Patterns I See in Every Enterprise Estate
Across 280 migrations, the root causes cluster into five patterns. Once I can identify which combination a client has, I can estimate the remediation timeline before opening the management console.
1. The Incident Accumulation Pattern
Rules added under pressure during outages, breaches, or deadline crunches. The thinking is always “open it now, document later, tighten later.” Later never arrives. I have found incident rules from 2009 still active in estates migrated in 2025. One financial services client had 340 rules tagged as “temporary” in the original ticket. None had been reviewed in three years. Several granted access to decommissioned systems that had since been re-used by a different team.
2. The Vendor Transition Hangover
Companies that migrated from Cisco ASA to Palo Alto, or from Check Point to Fortinet, typically ran parallel estates for six to eighteen months. Rules were duplicated across both platforms. Eventually the old platform was decommissioned but the mirror rules stayed on the new platform “just in case.” In multi-vendor environments — which describes roughly 70% of the DACH estates I have worked in — you often find three generations of rule logic coexisting, each reflecting a different network architecture that no longer exists.
3. The Any-Any Rule Hidden in the Middle
This is the one that keeps me awake. In roughly one in five estates I audit, there is a rule somewhere in the middle of the base — not at the top where it would be obvious — that allows any-source to any-destination on a broad port range. It is usually buried after 200 specific rules, which is why nobody noticed it. It was added during a networking project years ago, when the engineer needed to quickly prove that the firewall was not the problem. Proving the negative was successful. Removing the rule was forgotten.
4. The Application Decommission Ghost
Applications get decommissioned. Their firewall rules do not. In KRITIS and manufacturing environments I frequently find rules permitting access to IP ranges that were reassigned to a different VLAN three infrastructure refreshes ago. The original application target no longer exists. The IP now belongs to a production control system. The rule that was supposed to protect an old SAP test environment now permits traffic to an OT network. The access is not actively exploited — yet. But it is there.
5. The Audit-Driven Rule Explosion
This one is counterintuitive. PCI-DSS, ISO 27001, and TISAX audits often generate more rules, not fewer. Auditors flag that certain traffic is not restricted. The fix is a new deny rule, added quickly before the next assessment. Over three or four audit cycles, this produces layers of compensating controls stacked on top of each other, each addressing the specific finding from a specific year. The result is a rulebase that technically satisfies each individual audit finding while the underlying architecture remains fundamentally unclean.
Why Standard Cleanup Approaches Fail
The obvious solution is to review and remove unused rules. In practice, this is harder than it sounds, and most attempts fail for the same reasons.
Traffic data is not enough. A rule can appear unused for 180 days and still be critical. Disaster recovery rules, quarterly batch jobs, annual compliance scans, backup paths that only activate during primary link failure — all of these will show as zero-hit rules under normal operating conditions. I have seen engineers remove rules based on traffic analysis and break disaster recovery procedures that nobody knew existed.
Object naming conventions are inconsistent. In a ten-year-old estate managed by multiple teams, the same host may be represented as an IP address in 40 rules and as an object called “srv-finance-old” in 20 others. Deduplication requires resolving this before you can identify true redundancy. In large environments this takes weeks without tooling.
Application owners are unavailable. The correct answer to “is this rule still needed?” is almost never held by the security team. It requires tracking down the application owner, who may have left, or the business unit, which may have been restructured. In DAX-30 environments, chasing approvals for rule cleanup takes longer than the technical work by a factor of three to five.
The Methodology That Works
After 280 migrations, I have converged on a four-phase approach that consistently reduces enterprise migration timelines by approximately 70% compared to ad-hoc cleanup methods. The key insight is that you cannot clean a rulebase and migrate it simultaneously. They are separate phases with separate teams and separate acceptance criteria.
Forensic Inventory
Pull every rule from every device. Resolve all objects to their current IP assignments. Cross-reference against CMDB to identify decommissioned hosts. Tag rules by last-match age: 0-30 days, 30-90, 90-365, 365+. This phase surfaces the scope of the problem without changing anything.
Shadow and Redundancy Analysis
Automated detection of rules shadowed by broader rules above them, exact duplicates, and rules with overlapping source and destination ranges. These are low-risk removals because they have no traffic impact by definition. Getting these out first reduces the rulebase size by 15-30% before any business decisions are required.
Owner-Driven Recertification
Every rule with no traffic in 90+ days goes into a recertification queue. Each rule is routed to its documented owner for a binary decision: keep with justification, or decommission. Undocumented rules where the owner cannot be determined go to the CISO for disposition. This is the slowest phase, but workflow tooling makes the difference between three months and three years.
Migration with Clean Baseline
Only at this point does the actual platform migration begin. You are moving a documented, validated rulebase — not transporting technical debt to a new platform at significant expense. Every rule that travels to the target platform has a current owner, a business justification, and a last-reviewed date. The first PCI-DSS or ISO 27001 audit after migration becomes routine rather than remediation.
Where AI Changes the Equation
The forensic inventory and shadow analysis phases used to require specialist tooling or weeks of manual work. AI-driven rule analysis changes the cost structure of the first two phases significantly.
Pattern recognition across large rulebases — identifying objects that resolve to the same IP under different names, detecting rules that are functionally identical despite different syntax across vendors, mapping which rules were likely added as incident responses versus planned changes — these are problems where AI performs well because they involve pattern matching across large structured datasets rather than qualitative judgment.
The qualitative judgment — is this rule still needed? who owns this application? what is the business risk of removing this? — still requires human decision-making. That is where the migration timeline actually lives. Automation compresses phases one and two from weeks to hours. The owner-driven recertification in phase three remains bounded by human availability.
In the FwChange whitepaper, I documented the methodology and timing data across 40+ migration projects run using the four-phase approach. The average forensic inventory phase dropped from 18 working days to 2.5 days. Shadow analysis dropped from 8 days to under 4 hours. The recertification phase — which is human-bound — remained at 6-8 weeks, but workflow tooling reduced chasing time by approximately 60%.
The net result is a migration timeline reduction of around 70% for estates of 1,000+ rules. For smaller estates the reduction is less dramatic because the fixed cost of project management dominates.
The Compliance Angle
Rule sprawl is not only a migration problem. For companies under PCI-DSS 4.0, ISO 27001, NIS2, or KRITIS, an undocumented rulebase is a direct audit finding.
PCI-DSS Requirement 1.3 mandates that all inbound and outbound traffic is restricted to only that which is necessary. An estate with 47% of rules generating no traffic and 61% of rules carrying no business justification cannot satisfy that requirement in an audit. The controls may be technically correct. The evidence is not.
KRITIS environments under the IT-Sicherheitsgesetz 2.0 face a stricter version of the same problem. The BSI expects documented change management processes and periodic reviews of firewall configurations. An estate that has not been formally reviewed in three years is a finding before the auditor reads a single rule.
The migration methodology above is also a compliance remediation methodology. Running it produces the documented, owner-assigned, justified rulebase that auditors need to see. The by-product of a clean migration is a clean compliance posture.
What to Do Before Your Next Migration
If you are planning a firewall platform migration in the next 12 months, the single most effective thing you can do is start the forensic inventory phase now, before the migration project begins.
Pull your current rulebase. Run shadow and redundancy analysis. Get the easy wins out first. Start building your recertification queue. By the time the migration project kicks off, you will have a significantly smaller, better-documented rulebase to move — and a project timeline that reflects reality rather than optimism.
The companies that skip this step and migrate rule-for-rule — and most do, because timeline pressure makes it feel like the faster path — spend the first six months post-migration doing the cleanup they should have done before. On the new platform. With the same undocumented problems. At a higher hourly rate because the migration team is still on-site.
Clean before you move. Start with a free rulebase scan to see exactly what you are dealing with — shadow rules, redundancies, unused rules — before committing to a migration timeline.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.