Firewall Change Automation: 5 Hard Lessons from 200 Audits
Firewall change automation has been the same unsolved problem across every enterprise security team I have worked with. I have spent the last seventeen years inside other people’s firewalls — two hundred plus enterprise environments, banks, manufacturing, energy, public sector. After that many engagements, you stop blaming the engineers running the systems and start blaming the systems themselves.
FwChange.com is the firewall change automation platform I built when I got tired of writing the same finding for the hundredth time. This post is the long version of why.
The pattern firewall change automation has to solve
The single most common audit finding across every Mittelstand and enterprise firewall I have reviewed is some variation of the same theme: change control that exists on paper but does not exist in practice. This is precisely the gap firewall change automation has to close.
It looks like this. The change advisory board meets weekly. There is a ticketing system. Every change gets a ticket. Every ticket has approvers. Every approver signs off. Yet when you actually trace a sample of real firewall changes through the audit log, somewhere between thirty and sixty percent of them either bypassed the workflow entirely, used a generic emergency-change category that should have applied to a tiny minority, or were approved by an engineer who could not have read the rule diff in the time the timestamps showed.
The auditors knew. The compliance team knew. The CISOs I was reporting to knew. Nobody had a way to fix it without doubling the size of the network team.
The reason is structural. Modern enterprise firewalls — Palo Alto Networks, Fortinet FortiGate, Cisco ASA and FTD, Check Point — make it trivial to add rules. The CLI, the API, the management consoles all optimise for speed of change. What they do not optimise for is the audit trail of why the change was right at the moment it was made. (For broader context on the German Mittelstand audit pressure, see Cybersecurity Consulting in Germany: What Companies Actually Need.)
A senior engineer can review a hundred-line change in fifteen minutes. They can review a ten-line change in two minutes. They cannot review either of those changes properly while also handling tickets, planning capacity, mentoring juniors, and answering vendor escalations. So the review becomes ceremonial. The signature happens; the analysis does not. Firewall change automation done right is what fixes this.
What I tried before firewall change automation
Before building FwChange, I spent two years recommending workflow changes to clients. More structured ticketing. Mandatory peer review. Pre-prod policy testing. Some clients adopted these. Most either could not justify the headcount or did adopt the process but found that compliance with it slipped within six months as operational pressure returned. None of these were firewall change automation in any meaningful sense.
I tried scripts. I wrote bash and Python tools that pulled firewall configurations, diffed them, and emailed the diffs to reviewers. They worked for a quarter and then nobody read the emails. I tried integrations with existing ITSM tools. I built dashboards. None of it changed the underlying problem: the human reviewer was still the bottleneck, and humans optimise for the next emergency, not for the cumulative integrity of policy.
The breakthrough was admitting that the human review was not the right place to enforce quality. The right place was before the change reached the human — analysis that the human could trust and a queue that filtered the changes the human actually needed to see. That is what firewall change automation actually is.
What FwChange actually does as firewall change automation
FwChange sits between the engineer proposing a change and the firewall that will enforce it. Every proposed change goes through structured firewall change automation analysis before it ever reaches a human reviewer. The analysis answers a small set of questions, and it answers them deterministically:
- Is this change shadowed by existing policy? A new rule that overlaps an existing rule with broader scope is almost always either redundant or a sign that the existing policy is wrong.
- Does this change widen the attack surface measurably? A rule that allows a previously-denied service from a previously-denied source is a different risk class than a rule that narrows an existing allow.
- What is the historical pattern for changes of this shape? Across the change history of this firewall, how often have rules of this shape been rolled back? How often have they been linked to incidents?
- What is the blast radius if this change is wrong? Which assets are exposed, what data classifications they hold, and what compensating controls exist downstream.
The firewall change automation analysis runs in seconds. The output is a structured risk score with the reasoning attached — not a confidence percentage, but a list of factors with explanations. The reviewer reads the reasoning, not the diff.
A reviewer who can trust the upstream firewall change automation can review changes properly in two minutes. A team that gets six changes a day instead of sixty can review every one of them.
The methodology is documented publicly on FwChange.com/methodology — I am deliberately transparent about how the analysis works, because the only way this kind of system gets adopted is if security teams can audit the audit tool. (See also enterprise firewall automation ROI metrics for the financial case.)
Why this firewall change automation architecture
I made three architectural decisions about firewall change automation that I have been asked about more than any other:
Self-hosted by default, not SaaS. Firewall configurations contain everything an attacker needs to plan a network compromise. Sending them to a multi-tenant cloud service has been a non-starter for every Mittelstand and regulated client I have spoken to. FwChange runs on the customer’s own infrastructure — Hetzner Germany works for me, but the deployment model supports anything from a single VM to a Kubernetes cluster. The customer’s data never leaves their boundary. (For German Mittelstand NIS2 context, see why German SMEs are unprepared for NIS2.)
Vendor-neutral, not vendor-blessed. Every firewall vendor has its own configuration management story. Palo Alto Panorama, Fortinet FortiManager, Cisco DNA Center. They are good at managing their own gear and bad at the mixed-vendor reality most enterprises actually run. FwChange treats every vendor as a peer and normalises configurations into a common policy model. If a customer migrates from Cisco to Palo Alto in three years, the firewall change automation history does not reset.
Optimise for the audit trail, not for the change. The fastest way to add a rule is direct CLI access. FwChange is deliberately slower for the engineer making the change. Every action generates evidence: who proposed it, when, why, with what supporting analysis, who reviewed it, with what reasoning. After deployment, the historical record is the most valuable thing in the system. Auditors who used to spend weeks reconstructing change history can answer the same questions in minutes.
What firewall change automation has taught me
Building this firewall change automation platform has changed how I think about security automation in general:
Most “automation” is just faster human work. Real firewall change automation removes humans from decisions that do not need them, not from typing they can do themselves. The win is not the tool that runs change scripts faster; it is the system that decides which changes need human review at all.
Trust is the limiting reagent. Security teams will not adopt firewall change automation they cannot audit. Closed-source risk-scoring engines fail this test. Every output of FwChange’s analysis is traceable to specific rules and specific data — no black box, no model that the team cannot interrogate.
The compliance angle is what gets it through procurement. Engineering teams adopt tools because they make their work better. Security teams adopt tools because they make audits go faster. FwChange does both, but the second is what gets the budget signed.
Methodology is the moat. The code can be reproduced; the methodology — eight years of patterns extracted from two hundred audits, structured into a deterministic firewall change automation analysis — cannot. Open-sourcing the methodology and not the implementation has been a deliberate choice and has so far been the right one.
Where firewall change automation goes next
The current focus is two things. First, deepening the firewall change automation analysis on changes that touch high-risk policy categories — outbound rules to the internet, rules that cross trust boundaries between IT and OT, rules that affect crown-jewel asset segments. These are the changes where the cost of a missed review is highest, and they are where automation has the most leverage.
Second, integration with the broader audit ecosystem. ISO 27001, NIS2, BSI-IT-Grundschutz, NIST CSF — every one of them requires firewall-change evidence. The current default is engineers manually compiling that evidence at audit time. The right answer is the firewall change automation evidence already existing, structured, queryable, and provable. (For ROI framing, see security consulting ROI metrics.)
If you are running enterprise firewalls in 2026 and your audit trail still depends on weekly change-board minutes and engineer recall, I would push you to think hard about whether that is actually defensible. Both for the regulator and for the post-incident review you hope you will never run.
FwChange is live at fwchange.com — methodology public, deployment model self-hosted. If you are scoping firewall change automation for a Mittelstand or enterprise environment, get in touch. Also see RogueAI.de for the production AI portfolio.
