Next generation firewall (NGFW) proposals quote headline throughput with every inspection feature switched off, and the firewall you buy is also one of the most attacked devices on your network. This template gives you a ready-to-issue request for proposal for NGFW appliances, virtual firewalls and central management, with numbered requirements written so each answer can be tested in a proof of concept and scored. It covers throughput under realistic inspection, policy and application control, threat prevention, TLS inspection, remote access, management and logging, and the security of the device itself, which recent edge device exploitation has made a first-order requirement. It is vendor-neutral and written for network architects, security engineers, procurement and evaluation panels. Read the Firewall Buyer's Guide first for the market and the trade-offs; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [SIEM], [identity provider] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example FW-PERF-02) and a type: M mandatory (pass or fail), S scored (weighted 0 to 5) or I informational. Keep M items few, or every bidder fails something.
- Throughput figures, retention periods and weights in brackets are illustrative. Take your own peak and sustained traffic per site from at least four weeks of interface statistics, including backup and patch windows, and add growth for the contract term.
- Complete Appendix A (sites and deployment points) yourself. Bidders must size and price against it, which makes quotes comparable.
- Issue sections 1 to 8 and Appendix A to bidders. Implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID.
1. Purpose and scope
[Organisation] invites proposals for next generation firewalls, central management and associated services to enforce network security policy at internet edges, between internal zones, in data centres and in [cloud] environments.
- In scope: physical and virtual firewalls for the deployment points in Appendix A; high availability; central management and logging; threat prevention and URL filtering subscriptions; [remote access VPN]; migration of the existing rule base; training.
- Out of scope: [web application firewall, separate procurement]; [secure access service edge, unless offered as an option]; [network detection and response].
- Contract term: [five] years for hardware support and subscriptions, with an option to extend by [two].
- Drivers: [end of support of current platform on date]; [segmentation programme]; [audit finding]; [remote access replacement].
2. Current state
| Item | [Organisation] value |
|---|---|
| Current firewall estate | [number] appliances, [number] virtual; product generation and end of support dates |
| Rule base size | [number] rules across [number] policies; [percentage] unused in last 90 days |
| Sites and internet breakouts | [number] sites, [number] direct internet breakouts, [number] data centres |
| Peak and sustained throughput | Largest site [Gbps peak / Gbps sustained]; aggregate [Gbps] |
| Encrypted share of traffic | [estimate]; TLS inspection today [none / outbound only / full] |
| Remote access users | [number] concurrent, [client VPN / clientless / other] |
| Identity and logging | [identity provider], [SIEM], [SOAR], [change management tool] |
| Change model | [central team / per site], [number] changes per month |
3. Instructions to bidders
- Timeline: RFP issued [date]; questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Contact: [name, email]; other contact about this RFP may lead to disqualification.
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless contractually committed.
- Evidence: link the product documentation page supporting each "available now" answer and provide a bill of materials for every Appendix A deployment point, with model, licences and high availability pair.
- Performance claims: every throughput figure must state the test traffic mix, packet sizes, features enabled and whether the result is independently tested.
4. Functional requirements
4.1 Performance and sizing
| ID | Requirement | Type |
|---|---|---|
| FW-PERF-01 | For each proposed model, state throughput with firewall only, with application control, with full threat prevention, and with TLS inspection enabled, using a stated enterprise traffic mix. | M |
| FW-PERF-02 | Each Appendix A deployment point is sized for its peak traffic with threat prevention and [TLS inspection] enabled, at no more than [60%] utilisation in year one. | M |
| FW-PERF-03 | State maximum concurrent sessions, new connections per second and VPN tunnel capacity per model. | M |
| FW-PERF-04 | Active/passive or active/active high availability with stateful failover, stating failover time and session preservation for TLS-inspected and VPN traffic. | M |
| FW-PERF-05 | Describe behaviour under overload: which inspection is bypassed or dropped, whether this is configurable (fail open or fail closed) and how it is alerted. | S |
4.2 Policy, segmentation and application control
| ID | Requirement | Type |
|---|---|---|
| FW-POL-01 | Default deny for all traffic not explicitly permitted, on every interface and zone. | M |
| FW-POL-02 | Rules can match on application identity independent of port, on user and group from [identity provider], and on dynamic objects (cloud tags, address feeds). | S |
| FW-POL-03 | Zone-based policy for internal segmentation, including virtual systems or contexts with separate administration where required. | S |
| FW-POL-04 | Reports rule hit counts, shadowed, redundant and unused rules, and supports rule expiry dates and mandatory comments or ticket references. | S |
| FW-POL-05 | Native IPv6 policy with feature parity to IPv4, stating any inspection features that do not support IPv6. | S |
| FW-POL-06 | Outbound (egress) filtering by application, destination category and country, with default deny for server zones. | S |
See the Firewall Management Guide and the Zero Trust Network Segmentation Playbook for Flat Networks.
4.3 Threat prevention
| ID | Requirement | Type |
|---|---|---|
| FW-THR-01 | Intrusion prevention with signature and protocol anomaly detection, stating update frequency, how emergency signatures are delivered and how false positives are tuned per rule. | M |
| FW-THR-02 | Malware inspection of files in permitted traffic, stating supported file types, sandbox location (on box, cloud, on premises) and data residency of submitted files. | S |
| FW-THR-03 | URL and DNS filtering by category, with newly registered domain handling and custom block and allow lists. | S |
| FW-THR-04 | Ingests external threat intelligence feeds (IP, domain, URL) in standard formats and applies them to policy without a full commit. | S |
| FW-THR-05 | State which threat prevention functions continue if the subscription lapses or cloud services are unreachable. | M |
See the IDS and IPS Guide.
4.4 TLS inspection
| ID | Requirement | Type |
|---|---|---|
| FW-TLS-01 | Outbound TLS inspection supporting TLS 1.2 and TLS 1.3, stating behaviour for unsupported ciphers, certificate pinning and QUIC. | M |
| FW-TLS-02 | Category and destination based exemptions (for example health, banking, certificate-pinned applications) configurable without disabling inspection globally. | M |
| FW-TLS-03 | Validates upstream server certificates and blocks or warns on invalid, expired or revoked certificates rather than re-signing them as trusted. | M |
| FW-TLS-04 | Inspection signing keys can be held in a hardware security module or protected key store, and key access is logged. | S |
TLS 1.3 (RFC 8446) removed static RSA key exchange, so inspection must act as an active proxy; passive decryption with a server key is not possible. See the TLS Inspection Guide.
4.5 Remote access and VPN
| ID | Requirement | Type |
|---|---|---|
| FW-VPN-01 | Site-to-site IPsec with IKEv2, stating supported cipher suites and Diffie-Hellman groups, and the ability to disable legacy options. | M |
| FW-VPN-02 | Remote access users authenticate through [identity provider] with SAML or OIDC and phishing-resistant multi-factor authentication; local VPN user databases can be disabled. | M |
| FW-VPN-03 | Device posture checks before access, and per-application access policy rather than full network access. | S |
| FW-VPN-04 | The remote access portal can be restricted by source, rate limited and protected against credential stuffing, with lockout and alerting. | M |
See the IPsec Security Guide.
4.6 Management, logging and automation
| ID | Requirement | Type |
|---|---|---|
| FW-MGT-01 | Central management of policy, objects, software versions and licences for all proposed firewalls, with role-based administration and staged rollout. | M |
| FW-MGT-02 | Every configuration change logged with previous and new values, administrator, method (CLI, API, web) and time; changes can be compared and rolled back. | M |
| FW-MGT-03 | Traffic, threat, system and audit logs forwarded in near real time to [SIEM] over TLS in a documented, machine-readable format, with timestamps in UTC and alerting when forwarding fails. | M |
| FW-MGT-04 | A documented REST API covering policy, objects and status, with scoped API tokens, token expiry and audit of API use. | S |
| FW-MGT-05 | Configuration export in a documented format suitable for migration and for policy analysis tools. | S |
See the VPN and Firewall Log Detection Guide.
5. Device security and non-functional requirements
Firewalls and VPN gateways are internet-facing and widely exploited. In February 2025 the UK NCSC, with CISA, the FBI and the Australian, Canadian and New Zealand agencies, published forensic and logging specifications for producers of network devices. The requirements below draw on that guidance and on CISA's Secure by Demand questions. See the Edge Device Security Guide.
| ID | Requirement | Type |
|---|---|---|
| FW-SEC-01 | No default or hard-coded credentials; first boot forces creation of unique administrator credentials. | M |
| FW-SEC-02 | Administrative access supports multi-factor authentication and single sign-on, and management interfaces can be bound to a dedicated management network and disabled on internet-facing interfaces. | M |
| FW-SEC-03 | Logs authentication attempts, configuration changes and exports, firmware updates (with versions and signature checks), log clearing attempts and process activity on the device, and sends heartbeat messages with software version and a configuration digest. | S |
| FW-SEC-04 | Supports collection of volatile state (running processes, connections, active sessions) and full storage images for investigation by [Organisation] or its responders, without voiding support. | S |
| FW-SEC-05 | Firmware is signed and verified at boot and at update, with secure boot on physical appliances. | M |
| FW-SEC-06 | Publishes a vulnerability disclosure policy, issues CVE records with accurate CWE fields, and states its target time to release fixes for critical vulnerabilities in internet-facing services. | M |
| FW-SEC-07 | Provide the list of security advisories affecting the proposed product family in the last [36] months, with dates of disclosure and fix, and whether each was exploited before a fix was available. | I |
| FW-SEC-08 | Cryptographic modules validated under FIPS 140-3, and any Common Criteria certification, stated with certificate numbers. [Delete if not required.] | I |
| FW-SEC-09 | Provides a software bill of materials for the firewall operating system on request. | S |
| FW-SEC-10 | Published end of sale, end of software support and end of life policy, with at least [five] years of security fixes after end of sale. | M |
See the Edge Device Exploitation by Threat Actors Guide and the Edge Device End of Life Replacement Playbook.
6. Services and support
- Migration: describe the method and tooling for converting the existing rule base, how unused and overlapping rules are identified before migration, and the cutover and rollback plan per site.
- Support: severity definitions, response times, hardware replacement times per site in Appendix A, and access to engineers who can analyse device forensic data.
- Security notifications: how and how quickly customers are told about vulnerabilities, exploitation and indicators of compromise, including out-of-hours notice.
- Training: administrator training for [number] staff, and documentation for hardening and secure configuration.
- Exit: configuration and log export at end of contract in documented formats.
7. Pricing
| Line | Year 1 | Years 2 to 5 | Notes required |
|---|---|---|---|
| Hardware or virtual licences per Appendix A point | [ ] | [ ] | Model, high availability pair, spares |
| Threat prevention, URL and sandbox subscriptions | [ ] | [ ] | What stops working if not renewed |
| Central management and logging | [ ] | [ ] | Log volume and retention included |
| Remote access licences | [ ] | [ ] | Concurrent or named users |
| Support and hardware replacement | [ ] | [ ] | Level and response times |
| Migration and professional services | [ ] | Not applicable | Days, fixed or time and materials |
State renewal price caps, the cost of moving to the next hardware generation if a model reaches end of sale during the term, and any feature that requires an extra licence.
8. Evaluation method and proof of concept
| Criterion | Weight |
|---|---|
| Performance under inspection and sizing (4.1) | [20%] |
| Policy, threat prevention and TLS inspection (4.2 to 4.4) | [20%] |
| Device security and vendor security record (5) | [20%] |
| Management, logging and automation (4.6) | [15%] |
| Remote access (4.5) | [5%] |
| Five-year total cost | [15%] |
| Services, support and migration (6) | [5%] |
A bidder failing any M requirement is excluded. Score S requirements 0 (not met) to 5 (fully met, demonstrated), multiply by weight, and record the evidence for each score. Shortlisted bidders run this proof of concept:
- Replay a [24-hour] capture or generated traffic mix matching section 2 through the proposed model with full threat prevention and TLS inspection, and record throughput, latency and CPU.
- Import [a sample of 200 rules] from the current rule base and review conversion accuracy and the unused or shadowed rule report.
- Run a curated set of benign test files and known test signatures through permitted applications and record which are blocked and logged.
- Authenticate a remote access user through [identity provider] with multi-factor authentication, then attempt repeated failed logins and confirm lockout and alerting.
- Fail the active unit of a high availability pair during an inspected file transfer and a VPN session, and record failover time and session loss.
- Make a configuration change through the API and the console, confirm both appear in the audit log in [SIEM] with old and new values, then roll back.
- Collect a volatile state snapshot and a configuration digest from the device and check what an investigator would see.
Appendix A: sites and deployment points
| Deployment point | Role | Peak / sustained | Inspection required | High availability |
|---|---|---|---|---|
| [Head office internet edge] | Perimeter | [Gbps / Gbps] | [Threat prevention, TLS] | [Yes] |
| [Data centre core] | Internal segmentation | [ ] | [ ] | [ ] |
| [Branch type A, quantity] | Branch edge | [ ] | [ ] | [ ] |
| [Cloud VPC or VNet] | Virtual | [ ] | [ ] | [ ] |
| [Remote access] | VPN gateway | [concurrent users] | [ ] | [ ] |
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Measure before you write: FW-PERF-02 is only fair if Appendix A holds real peak figures. Sizing from datasheet figures with inspection off is a common way to end up replacing hardware early.
- Weight the security record: the firewall is an attack target. Ask for FW-SEC-07 history, read each advisory, and score how fast fixes and customer notices arrived, not the number of advisories alone.
- Clean the rule base first: migrating thousands of unused rules carries old risk into new hardware. Use the Firewall Rule Review Checklist before cutover.
- Protect proof of concept access: give bidders time-limited, named accounts with multi-factor authentication, keep test devices off production management networks, and revoke API tokens afterwards.
- Treat admin and API accounts as privileged identities: firewall service accounts used by orchestration, backup and SIEM integrations hold broad network power. Vault their credentials and review them with other non-human identities.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE |
|---|---|---|---|
| Policy and segmentation (4.2) | SC-7, SC-7(5), AC-4 | PR.IR-01 | D3FEND D3-ITF, D3-OTF |
| Remote access (4.5) | AC-17, IA-2(1) | PR.IR-01 | ATT&CK T1133 |
| Management and logging (4.6) | CM-3, CM-6, AU-9 | PR.PS-04, DE.CM-01 | ATT&CK T1686 |
| Device security (5) | SI-2, SA-4 | GV.SC-05 | ATT&CK T1190 |
Standards and references
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NCSC: Digital forensics and protective monitoring specifications for producers of network devices and appliances
- CISA: Secure by Demand Guide
- CISA: Secure by Design Pledge
- IETF: RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Firewall Buyer's Guide · Firewall Management Guide · Security Vendor Evaluation and RFP Guide · NDR RFP Template · SASE and SSE RFP Template