New Firewall, Old Rules

This is an early thought, not a fully worked-out position — but it's been nagging at me across enough engagements that I want to write it down.

I keep seeing the same pattern. An organisation buys a best-of-breed next-gen firewall — Palo Alto is the one I see most, simply because it's the platform I know deepest — and six months later, the project is "done." Rulebase migrated, hardware racked, old boxes decommissioned. Leadership gets told the network is more secure now. And technically, none of that is a lie. But in the way that matters, it's often not true.

What Actually Gets Migrated

What usually happens in these projects is a like-for-like port. Someone exports the legacy ruleset — port-based, zone-based, built up over a decade of "just add a rule" — and recreates it on the new platform, rule for rule, object for object. App-ID sits there capable of identifying and controlling traffic by application instead of port, and it's used maybe for the two rules someone had time to redo. User-ID goes unconfigured. Zero Trust segmentation, the entire reason to buy a platform like this instead of a cheaper stateful box, never gets designed, because designing it means understanding what's actually supposed to talk to what — and nobody scoped the hours for that conversation.

The result is a next-generation firewall running in emulation mode. It has all the capability of the platform and none of the behaviour. From a topology diagram, it looks like an upgrade. From an attacker's perspective, it's the same flat, over-permissive ruleset it replaced, just on newer hardware with a nicer UI.

Why I See This Especially in DACH

I don't want to overstate this into a national stereotype, but the pattern shows up more often here than in other markets I've worked, and I have a few working theories on why.

One is procedural: change management in German enterprises is often structured around the migration project itself — scoped, budgeted, signed off — and once cutover happens and the audit trail shows a completed project, the organisational appetite for further change on that system drops sharply. Redesigning the ruleset to actually use App-ID and segmentation isn't part of the migration; it would be a new project, with its own budget cycle and its own risk conversation, and nobody wants to reopen a system that was just declared stable.

Another is cultural — nicht anfassen, was funktioniert, don't touch what's working, isn't wrong as a general engineering instinct. But it quietly conflates "was working" with "is now secure," when the honest answer is that the ruleset was never redesigned, just relocated.

And a third is organisational: the team that runs the migration project is frequently not the team that owns long-term rule hygiene. The first team's success metric is "cutover complete, zero outages." The second team inherits a ruleset nobody wants to touch, on a platform capability nobody trained them to use. Neither team is incentivized to close that gap.

The Gap Between Migrated and Improved

The part that actually concerns me isn't the technical debt — every environment has some. It's the communication gap. Somewhere in every one of these projects, "we migrated to a next-gen firewall" quietly becomes "we're more secure now" in a slide to leadership, and nobody in the room has the technical grounding to ask whether that's actually true. The gap between migrated and improved isn't visible unless you know to look for it — and looking for it is exactly the kind of unglamorous, unbudgeted work that gets skipped.

I don't have a tidy conclusion here yet. Part of what I want to figure out — and maybe write about properly once I've thought it through more — is what actually changes this: whether it's a procurement question (buy the redesign hours up front, not as an afterthought), a reporting question (separate "migrated" from "hardened" as distinct project milestones with distinct sign-off), or just a longer conversation with whoever holds the budget about what they're actually paying for.

If you've seen this pattern too — or have a theory for why it's sharper in some markets than others — I'd genuinely like to hear it.