I have spent seventeen years inside other people’s firewalls — two hundred-plus enterprise environments, banks, manufacturing, energy, public sector — and I kept writing the same finding. After that many engagements you stop blaming the engineers and start blaming the systems they are forced to work in.
FwChange.com is the firewall change automation platform I built when I got tired of writing that finding for the hundredth time. This post is the long version of why.
The pattern firewall change automation has to solve
The most common finding across every Mittelstand and enterprise firewall I have reviewed is one theme: change control that exists on paper but not in practice. That gap is what the whole thing 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. Then you trace a sample of real changes through the audit log and find that thirty to sixty percent of them bypassed the workflow, used a generic emergency-change category that should have covered a tiny minority, or were approved by an engineer who could not have read the rule diff in the time the timestamps show.
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 and the management consoles all optimise for speed of change. None of them optimise for 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 and a ten-line change in two. They cannot review either one 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. Done right, automation is what fixes that.
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 adopted them. Most could not justify the headcount, or adopted the process and watched compliance slip within six months as operational pressure returned.
I tried scripts — bash and Python tools that pulled configurations, diffed them and emailed the diffs to reviewers. They worked for a quarter, then nobody read the emails. I tried integrations with existing ITSM tools. I built dashboards. None of it touched 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 the human review was the wrong place to enforce quality. The right place is before the change reaches the human — analysis they can trust, and a queue that filters down to the changes they actually need to see.
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 analysis before it 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 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 that upstream analysis reviews a change properly in two minutes. A team that sees 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 a system like this 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
Three architectural decisions have come up 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 vendor has its own configuration management story — Palo Alto Panorama, Fortinet FortiManager, Cisco DNA Centre. They manage their own gear well and the mixed-vendor reality most enterprises run badly. 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 change history does not reset.
Optimise for the audit trail, not for the change. The fastest way to add a rule is direct CLI access, and FwChange is deliberately slower than that for the engineer making the change. Every action generates evidence: who proposed it, when, why, with what supporting analysis, who reviewed it and on what reasoning. After deployment, that historical record is the most valuable thing in the system. Auditors who used to spend weeks reconstructing change history answer the same questions in minutes.
What firewall change automation has taught me
Building this platform has changed how I think about security automation in general:
Most “automation” is just faster human work. The real win is removing humans from decisions that do not need them, not from typing they can do themselves. It 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 a tool they cannot audit, and closed-source risk-scoring engines fail that test. Every output of FwChange’s analysis traces back to specific rules and specific data — no black box, no model 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 analysis — cannot. Open-sourcing the methodology and not the implementation was a deliberate choice, and so far the right one.
Where firewall change automation goes next
The current focus is two things. First, deepening the 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 where the cost of a missed review is highest, and 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. Today engineers compile that evidence by hand at audit time. The right answer is for it to already exist: 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, ask yourself whether that is defensible — to the regulator, and to the post-incident review you hope you never have to run.
FwChange is live at fwchange.com — methodology public, deployment 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.