2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Managed firewall services: what the provider should own, which failures the service must prevent, and how to evaluate one
Almost every internal penetration test we run ends up walking through a firewall rule that nobody remembers approving. Managed firewall services exist to stop that: a provider owns the rule lifecycle, the patching, the monitoring and the evidence, so your firewalls enforce the policy you think they enforce.
What managed firewall services are
Managed firewall services are an outsourced operating model in which a security provider takes day-to-day responsibility for your firewalls: designing the policy, implementing and documenting every rule change, patching firmware and software, monitoring health and traffic, feeding logs into a SIEM, reviewing the rule set on a fixed cadence, and producing the evidence that auditors ask for under PCI DSS, HIPAA, SOC 2 or NIS2. The hardware or cloud instance may be yours or the provider's. What changes is that a named team is accountable for the firewall enforcing a written policy every day.
The need has grown for two reasons. First, the firewall estate is no longer three appliances at the data center edge; it is next-generation firewalls at sites, virtual firewalls in AWS, Azure and Google Cloud, host-based rules, and a firewall-as-a-service layer for remote users, each with its own console and rule syntax. Second, the edge device itself has become a primary target. Internet-facing firewalls and VPN concentrators featured heavily in CISA's Known Exploited Vulnerabilities catalogue through 2024 and 2025, and an unpatched management interface is one of the most reliable ways into a network. Firewall management is therefore both a hygiene problem and a patching problem.
What a managed firewall service includes
Six responsibilities. A proposal that covers only monitoring and ticket handling is a help desk, not a managed service.
Policy design and segmentation
Translating business requirements into a zone model and a default-deny policy: which networks may talk to which, over which services, with the cardholder, patient or OT environment isolated from everything that does not need it.
Rule lifecycle and change management
Every rule enters through a request with an owner, a business justification, a risk review and an expiry date; is implemented in a change window; is documented; and is removed when the justification ends. No rule exists without a reason you can show an assessor.
Patching, firmware and hardening
Tracking vendor advisories and CISA alerts for your platforms, testing and applying updates within an agreed window, hardening management access (MFA, dedicated management network, no internet exposure) and maintaining tested configuration backups.
Monitoring and incident handling
Watching device health, throughput, VPN tunnels, high-availability state and denied-traffic patterns 24/7, with a path into your incident response process when a firewall event is part of something larger.
Logging into the SIEM and reporting
Forwarding allow and deny logs, with the right verbosity, into your SIEM so firewall data can be correlated with identity and endpoint events, plus monthly service reports and audit evidence packs per framework.
Periodic rule-set review and clean-up
A structured review at least every six months: unused rules, shadowed and redundant rules, overly broad rules, expired exceptions and undocumented NAT, each with a decision recorded.
NGFW, legacy firewall, cloud firewall and FWaaS compared
Most organizations run three of these four at once. A managed service should cover all of them under one policy and one change process.
| Aspect | Legacy stateful firewall | Next-generation firewall (NGFW) | Cloud-native firewall | Firewall as a service (FWaaS) |
|---|---|---|---|---|
| Where it sits | Network perimeter or between segments, physical or virtual appliance | Perimeter, data center and site edges, physical or virtual | Inside AWS, Azure or Google Cloud as a managed service or marketplace virtual appliance | In the provider's cloud, between users or branches and the internet or private apps |
| What it inspects | IP addresses, ports, protocols and connection state | Applications, users, URLs, decrypted TLS, files, with intrusion prevention and threat feeds | Cloud network flows, security groups and network ACLs, often with layer 7 rules and DNS filtering | User and device identity, application, content, usually combined with secure web gateway and zero-trust access |
| Typical management surface | Rule table per device, little central management | Central management console, policy objects, device groups | Cloud console, infrastructure as code, per-account or per-VPC policies | Single cloud policy applied to all users and sites |
| Failure pattern most often seen in testing | Thousands of accumulated rules nobody dares delete | Rich features licensed but never enabled; decryption off | Security groups opened wide during a deployment and never narrowed | Private app access granted broadly; policy drift between identity and network teams |
| Where a managed service adds most | Rule clean-up, migration planning, logging | Policy design, tuning of prevention features, patching, decryption strategy | Governance of who may change what, drift detection, logging to SIEM | Identity-to-policy alignment, exception control, reporting |
| Best fit | Legacy segments awaiting migration | Sites, data centers, OT boundaries, PCI environments | Cloud-first workloads, multi-account estates | Distributed workforce, branch offices without local hardware |
The firewall failures a managed service must prevent
These are the patterns our testers find most often in internal and external penetration tests. Each is described here as a control the service must keep in place, not as a technique.
1. Permit-any rules and overly broad objects
A rule allowing any source to any destination on any service, or an address group called 'servers' that contains half the network, turns a firewall into a router. The service must enforce least privilege per rule, with explicit sources, destinations and services, and must flag any rule whose scope exceeds its documented justification.
2. Stale, shadowed and expired rules
Rules for projects that ended years ago, rules that can never match because an earlier rule already catches the traffic, and 'temporary' exceptions without an end date. The service must track hit counts and expiry dates and remove or re-justify rules at each review.
3. Flat segmentation
Workstations that can reach every server, servers that can reach domain controllers on every port, OT networks bridged to the office network. The service must own a zone model, enforce it with deny-by-default between zones, and test it, which is where our network penetration testing comes in.
4. Exposed management interfaces
A firewall administration page or SSH service reachable from the internet, or from the general user network, is the single most consequential misconfiguration we see. The service must restrict management access to a dedicated management network with MFA, and must verify that restriction from the outside.
5. No egress filtering
Most firewalls are configured to stop traffic coming in and let everything out. Attackers rely on that for command-and-control and data exfiltration. The service must implement outbound policy by destination and service, with DNS and web traffic forced through inspected paths.
6. Unpatched platforms and weak administrative hygiene
Firmware years behind, shared administrator accounts, default credentials left on a secondary interface, configuration backups stored unencrypted. The service must own the patch cadence, enforce named accounts with MFA, and protect the configuration as a sensitive asset.
7. Logging switched off or never collected
A firewall that logs only denies, or logs to a local buffer that rotates every few hours, cannot support an investigation. The service must ship allow and deny events for the rules that matter into your SIEM, and must detect when that log stream stops.
Rule-review cadence, PCI DSS Requirement 1 and NIST SP 800-41
The clearest external standard for firewall management is PCI DSS v4.0.1 Requirement 1, Install and Maintain Network Security Controls. It requires that all services, protocols and ports allowed through the controls are identified, approved and have a defined business need (1.2.5); that configurations of network security controls are reviewed at least once every six months to confirm they are relevant and effective (1.2.7); that network access to and from the cardholder data environment is restricted (1.3); that connections between trusted and untrusted networks are controlled, with inbound traffic from untrusted networks limited to what is necessary (1.4); and that risks from devices connecting to both untrusted networks and the cardholder environment are mitigated (1.5). A managed firewall service built around a six-monthly documented review with owners and decisions satisfies the hardest of these by design.
NIST SP 800-41 Revision 1, Guidelines on Firewalls and Firewall Policy, remains the reference most US assessors cite. Its guidance maps directly onto the service: write the firewall policy before you write rules, default to denying traffic not explicitly permitted, protect the management plane, log and review, and plan deployments in phases with rollback. NIST SP 800-207 on zero trust architecture extends the thinking: the firewall becomes one policy enforcement point among several, and its rules must align with identity-based access decisions rather than replace them. Other frameworks point the same way: NIST SP 800-171 Revision 3 (and therefore CMMC 2.0 Level 2) requires monitoring and controlling communications at external and key internal boundaries and denying network traffic by default; ISO 27001:2022 controls A.8.20 to A.8.22 cover network security, network services and segregation of networks; NIS2 Article 21(2) requires security in network and information systems maintenance and access control policies; and DORA Article 9 requires network security management including segmentation.
How managed firewall fits segmentation and zero trust
A firewall is not a zero trust strategy, but zero trust does not work without one. Whatever the maturity model, the practical first steps are still network segmentation and egress control, both of which live in the firewall estate. A managed firewall service gives you the discipline to run those steps: a zone model that the identity team, the cloud team and the network team all agree on, enforced consistently across NGFW, cloud firewall and FWaaS, and verified by testing.
Verification is the part most programs lack. A segmentation policy that looks correct in the console can be undone by a single forgotten rule, a dual-homed host or a cloud security group. That is why segmentation testing is a standard component of our internal penetration tests, and why PCI DSS v4.0.1 Requirement 11.4.5 requires segmentation controls to be tested at least annually (every six months for service providers under 11.4.6). The managed service closes the loop: findings from the test become rule changes, and the next test confirms them.
Questions to ask a managed firewall provider
The answers tell you whether you are buying accountability or a ticket queue.
- Which platforms do you manage (NGFW vendors, cloud-native firewalls, FWaaS) and under one policy model or several?
- How does a rule request flow: who approves, what risk review is applied, how is the expiry date enforced, and what is the change window?
- How often is the full rule set reviewed, what does the review document, and can we see a sample review report?
- What is your patching commitment for critical firewall vulnerabilities, and how do you handle an emergency advisory outside the normal window?
- How is management access secured: dedicated management network, MFA, named accounts, session logging, and can you prove it from the outside?
- Which logs are forwarded to our SIEM, at what verbosity, and how do you detect that the log stream has stopped?
- What is the escalation path when a firewall event is part of a wider incident, and how do you work with our MDR provider or incident response retainer?
- Which compliance evidence is standard: PCI DSS Requirement 1 review records, change history, segmentation test results?
- How is the service priced (per device, per rule change, per site) and what happens to policy documentation and change history at exit?
Where HackersHub fits: testing the firewall and watching its logs
HackersHub is an Amsterdam-based offensive-security firm that also runs managed security for enterprise clients in the EU and the US, delivered remotely with on-site work where an engagement requires it. We do not operate your firewalls. Our role sits on either side of it: network penetration testing that validates the rule set and the segmentation from the attacker's position, and managed security (24/7 monitoring, SIEM and EDR management) that consumes the logs your firewalls produce and turns them into detections. The managed SIEM explainer and the MSSP contract checklist cover those adjacent decisions.
What we bring is the attacker's reading of a rule set. Our testers hold at least OSCP, with OSWE and CREST-certified testers on the team, and the seven failure patterns above come from their engagement notes, not from a vendor brochure. In a network penetration test every rule that matters is read against one question: what does this let me reach that I could not reach before? The findings go back to your firewall team or your managed firewall provider as concrete rule changes, and the next test confirms they landed.
Frequently asked questions
Related guides on managed security and network testing
- Managed security services by HackersHub
- Managed SIEM: what the service includes and how to buy it
- Network penetration testing: verify your segmentation
- MSSP contract checklist: what to get in writing
- What is SOC as a service?
- External vs internal penetration testing
- PCI DSS penetration testing: Requirement 11.4 explained
- Managed detection and response by HackersHub
Do your firewalls enforce the policy you think they do?
We test your rule sets and segmentation from the attacker's side, and our managed security team turns the logs your firewalls produce into detections. Talk to an expert.