Firewalls are often bought on datasheet throughput, then disappoint when TLS inspection and intrusion prevention are switched on, when the logs cannot answer an incident responder, or when the platform keeps appearing on known exploited vulnerability lists. The market now spans hardware next-generation firewalls (NGFW), unified threat management (UTM) appliances for smaller sites, virtual firewalls, cloud-native firewalls and firewall as a service (FWaaS). Labels overlap, so the deployment model, the performance you get with inspection enabled, and the vendor's security track record decide whether a product fits. This vendor-neutral guide is for architects, procurement teams and CISOs running a refresh, replacement or RFP. It covers requirements, scoring criteria, vendor questions and a four to six week proof of concept. For day-to-day rule hygiene see the Firewall Management Guide.
Key takeaways
- Size on inspected throughput, not datasheet numbers. Ask for results with TLS inspection, IPS, anti-malware, application identification and logging enabled, measured against a traffic mix like yours, as RFC 9411 describes.
- The firewall is an edge device and a target. Firewalls and VPN gateways are routinely exploited for initial access (MITRE ATT&CK T1190). Score the vendor's vulnerability history, disclosure practice and patch speed as hard as features.
- Forensic visibility is a buying criterion. The February 2025 Five Eyes forensics and protective monitoring specification sets out the logging and data acquisition a device should support.
- Management is where the long-term cost sits. Central management, policy as code, an API with scoped credentials and a clear support lifecycle matter more over five years than an extra security subscription.
- Admin access and API keys are privileged identities. Require phishing-resistant MFA for administrators, no default credentials, and short-lived, scoped credentials for automation that reads or writes policy.
Define requirements
Write these down before the first vendor meeting and put them in the RFP.
- Where enforcement is needed: internet edge, data centre core and east-west segments, branch offices, cloud virtual networks, operational technology boundaries and remote users. Each may need a different form factor. See the Network Segmentation Guide.
- Traffic profile: peak and 95th percentile bandwidth per site, encrypted share, new connections per second, concurrent sessions and growth over the term, measured from current firewall or flow logs.
- Inspection policy: which traffic you will decrypt, which categories are exempt for privacy or pinning reasons, and whether intrusion prevention runs in blocking or alerting mode. This drives sizing more than anything else. See the TLS Inspection Guide.
- Remote access: whether the firewall also terminates VPN or remote access moves to zero trust network access. See the VPN Security Guide and the ZTNA Guide.
- Availability: the outage you can tolerate, active-passive or active-active pairs, session synchronisation during failover, and whether upgrades can be done without dropping sessions.
- Operations: who writes and approves rules, the ticketing and CI/CD tools to integrate, and where logs go and for how long. See the Log Management and Retention Guide.
- Control obligations: NIST SP 800-53 SC-7 (boundary protection) and SA-22 (unsupported components), CIS Controls v8.1 Control 12 (network infrastructure management) and ISO/IEC 27001:2022 Annex A 8.20 to 8.22. SA-22 is why the support lifecycle belongs in the requirements.
Choosing a deployment model
| Model | Best fit | Trade-offs to test |
|---|---|---|
| Hardware NGFW | Internet edge and data centre with high throughput, dedicated acceleration, on-premises control of keys and logs | Capacity is fixed at purchase; hardware end-of-life forces refresh; you patch it |
| UTM appliance | Small offices and branches that want firewall, VPN, IPS, web filtering and anti-malware in one box with simple management | Performance drops sharply as services are stacked; check inspected throughput per enabled service |
| Virtual firewall | Private cloud, hypervisor and public cloud instances where you need the same policy model as on-premises | Licensed by vCPU or throughput tier; performance depends on host sizing; you still own patching and HA design |
| Cloud-native firewall | Filtering inside one cloud provider's virtual networks, managed scaling and HA | Feature depth varies (TLS inspection, IPS, application identification); policy model differs from on-premises; cost scales with traffic processed |
| FWaaS | Distributed branches and remote users, often delivered with web gateway and ZTNA from the same cloud service | Traffic must reach the provider's points of presence; latency, data location and the provider's own security become your risk |
A small organisation with a few sites usually gets more from a UTM or FWaaS service with good defaults than from a high-end appliance it cannot staff. A large enterprise runs several models and should weight consistent central policy above any single box. UTM against a best-of-breed stack is mostly a staffing decision: fewer consoles versus stronger individual functions that need integration.
Evaluation criteria
Weight the criteria to your requirements. An illustrative split is 25% inspected performance and security efficacy, 20% management and automation, 20% vendor security and lifecycle, 15% logging and visibility, 10% availability, 10% commercial terms; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Inspected performance | Third-party or your own test results for throughput, connections per second, concurrent connections, TLS handshake rate and latency with TLS inspection, IPS, anti-malware, application identification and logging on, fail-open off | Only stateful throughput with large packets; inspected figures without traffic mix or cipher suites |
| Security efficacy | Published methodology for IPS and malware testing; evasion resistance; timely signature updates; application and user identification | Efficacy claims with no test conditions; signatures delivered weeks after public exploits |
| Central management and policy as code | One console for every form factor; full API coverage; declarative configuration that can live in version control and be applied through CI/CD; rule usage and shadowed-rule analysis; staged commits and rollback | Features configurable only in the GUI; API that cannot read or write the full policy; no rollback |
| Logging and forensic visibility | Admin logins, config changes with old and new values, updates and log tampering all logged; UTC timestamps with milliseconds; TLS-protected remote logging in a documented format; volatile data collection for investigators | Logs only on the device; changes without before and after values; running state collectable only by the vendor |
| Secure by design and vulnerability track record | Published vulnerability disclosure policy; CVEs with accurate CWE; few repeat bug classes; integrity-checking tools; signed firmware and secure boot; no default passwords | Repeated critical flaws in management or VPN interfaces; slow or partial disclosure |
| Support lifecycle | Published end-of-sale, end-of-software and end-of-support dates for hardware and software trains; long-term support releases; security fixes for every supported train | Lifecycle dates available only under NDA; fixes only on the latest train, forcing major upgrades in an emergency |
| High availability | Stateful failover with session sync; hitless upgrades; tested failover times; config sync | Failover drops VPN and inspected sessions; upgrades need a maintenance window per pair |
| Admin access | SSO with phishing-resistant MFA for every administrator; role-based admin with read-only and change-approval roles; dedicated management interface; local break-glass account vaulted | MFA only through an add-on; one shared admin role; management plane reachable from the data interfaces |
| Commercial terms | Clear licence model (appliance, vCPU, throughput tier or user); bundles listed by feature; renewal caps; portability between form factors | Logging or IPS sold separately; licences tied to one serial; features that stop when a subscription lapses |
Where identity fits: admin and API credentials are privileged non-human identities
Policy as code, orchestration tools, SIEM integrations and backup scripts all authenticate to the firewall management plane with API keys or tokens. A key with write access can open the perimeter or disable logging (ATT&CK T1686.002 Disable or Modify System Firewall: Network Device Firewall). Require per-integration credentials with scoped roles (read-only by default), expiry, rotation without downtime, an inventory of issued keys and an audit log of API calls. Configuration backups hold pre-shared keys, certificates and password hashes: treat them as secrets. The Salt Typhoon telecom intrusions showed how stolen credentials and network device secrets kept attackers inside for years. See the API Key Management Guide and the Privileged Access Management Guide.
Questions to ask vendors
- Give us inspected throughput, connections per second and TLS handshake rate for the proposed model with TLS inspection, IPS, anti-malware, application identification and logging enabled. Which traffic mix, object sizes and cipher suites were used, and who ran the test?
- How many critical or high-severity vulnerabilities affected your management interfaces and VPN components in the last three years, how many were exploited before a fix existed, and how quickly were fixes released for every supported software train?
- Which classes of vulnerability have you eliminated, and what is your roadmap for the rest? Do your CVE records include accurate CWE identifiers? (Both questions come from the CISA Secure by Demand Guide.)
- Does the device ship without default passwords, is SSO with phishing-resistant MFA available for administrators at no extra cost, and do you provide a firmware SBOM in a standard machine-readable format?
- Which events do you log against the NCSC-led forensic monitoring specification: admin logins, configuration changes with old and new values, firmware updates and log clearing? Can we collect volatile state without your support team?
- Show the full policy exported, changed in version control, applied through your API and rolled back.
- What are the published end-of-support dates for the hardware and software we are buying, and how much notice do you give?
- Which features need separate subscriptions, and what happens to the device if a subscription lapses?
Red flags
- Sizing based only on stateful firewall throughput, or a refusal to quote figures with inspection on.
- Repeated exploited zero-days in the same component, with integrity checks published late. The Ivanti Connect Secure exploitation shows what follows when an edge device is compromised before a fix exists.
- Management interfaces that must be exposed to the internet for cloud management or licensing to work.
- Logs that stay on the box, or a forensic capability that only the vendor can operate.
- Lifecycle dates that are not published, or hardware close to end-of-sale offered at a discount. ASD's edge device practitioner guidance is blunt: "Organisations should not use EOL edge devices."
- An API with a single all-powerful key type and no per-key audit trail.
Proof of concept
- Agree pass criteria first: weights, minimum inspected throughput at 95th percentile load plus growth, maximum added latency and failover time.
- Replay realistic traffic: use a test harness or a mirrored segment with your encryption ratio and application mix. Enable TLS inspection, IPS in blocking mode, anti-malware and full logging, then measure throughput, connections per second, TLS handshake rate and time to first byte as RFC 9411 defines them.
- Test efficacy: run recent exploits and evasion techniques at a test server behind the device; record what is blocked and logged.
- Migrate a real rule base: import a copy of a production policy, measure conversion errors and how many rules need manual rework, then apply a change through the API from version control and roll it back.
- Exercise investigation: make an unauthorised config change with a test admin account, clear a log and trigger a failed login. Confirm each event reaches your SIEM with UTC timestamps, actor and before and after values, and that alerts fire. Collect volatile state with the vendor's tooling.
- Break it on purpose: fail the active unit under load, upgrade a pair, and confirm sessions survive within your tolerance.
- Check identity controls and roll back: enforce SSO and MFA for administrators, issue a read-only API key for the SIEM and a scoped write key for automation, revoke both, confirm they stop working, and remove the trial devices from your network with their keys and certificates destroyed.
After go-live, track inspected throughput headroom at peak, share of traffic inspected, mean time to apply critical vendor fixes, share of changes delivered through reviewed API commits, and devices within 12 months of end-of-support.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Firewall Management Guide · VPN Security Guide · ZTNA Guide · TLS Inspection Guide · Zero-Day and Exploited Vulnerabilities Guide