The firewall question every board eventually asks
Every few weeks another "best firewalls" ranking lands in my inbox. The most recent one from Cyber Magazine lined up the usual names, Microsoft, Palo Alto, Check Point, Fortinet, NTT DATA, and framed the decision the way most of these lists do: pick a product that combines strong network defence with easy administration. That framing is not wrong, but it quietly skips the part that actually decides whether the box protects anything. In twenty-five years of building and assessing networks, I have almost never seen a serious incident traced back to a firewall that failed to do its job. I have seen plenty caused by a firewall that was doing exactly what a bad rule told it to.
Gartner put a number on this years ago and it has held up: the overwhelming majority of firewall breaches come from misconfiguration, not from a flaw in the product. That single fact should change how a growing business approaches the whole exercise. The brand on the chassis matters far less than the architecture it sits inside, the discipline of the team that runs it, and how its logs feed the rest of your security stack. This article walks through how we think about firewalls at Aydahwa when a client asks us to choose, deploy, or clean up one, and what separates a firewall that reduces risk from one that just adds latency and a false sense of safety.
What a firewall actually has to do in 2026
The word "firewall" still makes people picture a wall between the internet and the office. That mental model retired somewhere around the time the office stopped being a single building. A modern enterprise firewall, next-generation or NGFW in vendor language, is really a policy engine that has to answer a much harder set of questions than "is this port open."
The first is encrypted traffic. The large majority of web traffic is now TLS-encrypted, which means a firewall that only reads packet headers is blind to most of what crosses it. Deep inspection requires terminating and re-encrypting TLS sessions, and that is a genuine engineering decision with real trade-offs. It costs throughput, it breaks certificate-pinned applications, and it raises privacy and legal questions you need answered before you switch it on, not after. We have walked into environments where SSL inspection was licensed, paid for, and never enabled because nobody wanted to own the fallout. The malware walked straight through the encrypted channel the firewall was bought to inspect.
The second is identity. Filtering by IP address made sense when a machine's address told you who was using it. With DHCP, roaming laptops, VPN pools, and cloud workloads that spin up and die in minutes, an IP is a temporary label at best. A firewall worth deploying today ties policy to user and group identity from your directory, and increasingly to workload identity as well, so a rule can say "the finance group may reach the ERP database" instead of "this subnet may reach that subnet and we hope the mapping still holds."
The third is application awareness. Port 443 is now the front door for thousands of distinct services, sanctioned and unsanctioned. Being able to distinguish your approved collaboration suite from a personal file-sharing account riding the same port is the difference between a policy that reflects your business and one that just waves everything through on a common port.
Remote access is the fourth, and it is where a lot of 2020-era architectures are quietly falling apart. The classic model backhauls remote users through a VPN concentrator into the corporate network, then out through the perimeter firewall. It works, but it puts every remote device one credential away from the flat internal network. More on the alternative below.
Deployment models, and where each one earns its place
"Which firewall" is two questions wearing one coat. The second question, often the more important one, is where the enforcement happens. The same vendor will happily sell you a physical appliance, a virtual instance, and a cloud-delivered service, and the right answer usually involves more than one of them working together.
ModelBest fitStrengthsWatch-outs
Physical NGFW appliance
Data centre and branch perimeters, high-throughput sites
Predictable performance, hardware acceleration for TLS inspection, mature HA
Capacity is fixed at purchase; refresh cycles; a single site becomes a choke point if undersized
Virtual / cloud firewall
Public cloud VPCs, virtualised data centres
Scales with the workload, deploys as code via Terraform, follows the app to the region
Throughput ties up compute you pay for; east-west visibility inside the cloud needs deliberate design
Firewall-as-a-service (SASE)
Distributed and remote workforces, SaaS-heavy businesses
Inspection at the edge near the user, no backhaul, identity-driven access baked in
You inherit the provider's outage; egress control and data residency need contractual clarity
Host-based firewall
Server and endpoint segmentation, zero-trust east-west control
Follows the workload anywhere, enforces microsegmentation the network cannot see
Only as good as your central management; unmanaged hosts drift into inconsistency fast
For most of our mid-market and enterprise clients in the UAE and wider GCC, the sensible pattern is a hardened NGFW at each physical perimeter, cloud-native firewalling inside every VPC or subscription, a SASE or ZTNA layer for remote and mobile users, and host-based controls for the workloads that matter most. That sounds like a lot of moving parts because it is. The payoff is that no single failure or misconfiguration opens the whole estate.
Segmentation is where a firewall stops being decoration
A perimeter firewall with a soft, flat interior is a hard shell around a runny yolk. Once an attacker gets a foothold through a phishing email or an exposed service, a flat network lets them move sideways to anything they can reach, and in a flat network that is everything. The 2013 Target breach, still one of the most studied, is the classic example: entry through an HVAC vendor's access, then lateral movement to the payment systems because nothing internal stood in the way.
Segmentation is the discipline of dividing the network into zones and forcing traffic between them through an enforcement point. Done at a coarse level it separates the card-processing environment from the guest Wi-Fi. Done well, as microsegmentation, it puts a policy boundary around individual workloads so that a compromised web server cannot open a database connection it never legitimately needs.
This is also where firewalls intersect directly with compliance. PCI-DSS explicitly requires segmentation to limit the cardholder data environment, and getting it wrong does not just weaken security, it drags every connected system into audit scope and multiplies the cost of assessment. We have taken clients from a flat network where the entire company was in PCI scope down to a tightly bounded segment, and the reduction in both risk and audit effort paid for the project on its own.
The diagram below shows the zoned architecture we typically design toward, with north-south traffic controlled at the perimeter and east-west traffic controlled between internal zones, everything logging to a central SIEM.
The operations problem no datasheet mentions
Buy the top-ranked firewall on any list, install it, and walk away, and within a year you will have a rulebase nobody fully understands. This is the quiet failure mode behind that Gartner misconfiguration statistic. Firewalls degrade through entropy, not through defect. Rules get added for a project and never removed. "Temporary" any-any rules to unblock a go-live become permanent. A rule that once pointed at a decommissioned server now points at whatever took over that IP.
Running a firewall properly is an operational commitment, and it looks like this. Every rule change goes through a change-management process with a business justification, a requester, and an expiry date where possible. The rulebase gets reviewed on a schedule, quarterly at minimum, to find and remove shadowed, redundant, and unused rules. The default posture is deny, with explicit allows, including egress filtering so that a compromised host cannot freely call out to a command-and-control server. And the logs go somewhere they will actually be read.
That last point deserves weight. A firewall log sitting on the appliance is forensic evidence you will read after the incident. The same log streamed into a SIEM, correlated with endpoint and identity events, becomes detection you can act on during the incident. When we run a SOC engagement, the firewall is one of the highest-value log sources we onboard, precisely because it sees the traffic that endpoint tools miss.
A practical selection and hardening checklist
When we help a client choose and stand up a firewall, this is the shortlist we work through before anyone signs a purchase order.
- Size for inspected throughput, not marketing throughput. Datasheet numbers are measured with inspection features off. Ask for figures with TLS inspection and threat prevention enabled, then add headroom for growth.
- Confirm identity integration with your actual directory, Entra ID, Active Directory, or your IdP, and test it before committing.
- Decide your TLS inspection policy up front: what you will decrypt, what you will bypass for privacy or legal reasons, and how you will handle certificate-pinned apps.
- Require high availability as standard. A firewall is an inline single point of failure; an active-passive or active-active pair is not a luxury.
- Plan the logging pipeline into your SIEM on day one, not as a later phase.
- Write the segmentation model before you write the rules, so rules express an architecture rather than accreting into one.
- Establish the change and review process, including who owns rule expiry, before the first production rule is added.
- Validate against a benchmark. The CIS Benchmarks and your vendor's own hardening guide give you a concrete baseline to audit against.
How the compliance frameworks actually treat firewalls
Clients often ask which framework "requires a firewall." Most of them do, but they care about outcomes rather than boxes. The NIST Cybersecurity Framework treats network defence under its Protect function and expects you to demonstrate that boundaries are defined and controlled. ISO 27001 Annex A covers network security controls and segregation of networks, and an auditor will ask to see not just the device but the rule review evidence behind it. PCI-DSS is the most prescriptive, mandating network segmentation and regular rulebase reviews for any environment touching cardholder data. The CIS Controls give you the tactical detail underneath all of them, down to the configuration line.
The pattern across every one of these is the same: the technology is assumed, and the assessor's attention goes straight to whether you can prove the thing is configured, reviewed, and monitored. A firewall you cannot produce a change history and a review log for is, from an auditor's chair, barely better than no firewall at all.
How Aydahwa Enterprise can help
We are an IT infrastructure and cybersecurity firm based in Dubai, working with organisations across banking, telecom, and critical national infrastructure where a network mistake is not a theoretical risk. Our team holds the certifications that back this work, including Microsoft Cybersecurity Architect Expert, and we build to the standards above, ISO 27001, PCI-DSS, SOC 2, NIST CSF, and the CIS Benchmarks, rather than treating them as afterthoughts.
If the firewall conversation in your organisation has stalled at "which brand," we can help you answer the questions that come after it: designing the segmentation model, sizing and deploying the enforcement layer across your data centre and cloud, wiring the logs into a SOC, and putting the operational discipline in place that keeps the rulebase honest a year from now. That work sits across our cybersecurity services and our cloud security and migration practice, backed by ongoing managed IT support.
If you would rather start by understanding where you stand, our free cybersecurity self-assessment and readiness checklist are a fast way to surface the gaps, including the segmentation and firewall-hygiene ones this article is about. When you are ready to talk specifics, get in touch and we will walk your architecture with you.
