Most VPN replacement projects stall not because the zero trust network access (ZTNA) product fails, but because the RFP never asked how it would handle the awkward 20 percent of applications that keep the VPN alive. This template is a ready-to-issue request for proposal for a standalone ZTNA service whose stated goal is to retire a remote access VPN. Every numbered requirement is written so the answer can be tested in a proof of concept and scored, and the appendices force bidders to price and design against your real application inventory and user populations. It is vendor-neutral and written for network and identity architects, security engineers, procurement and evaluation panels. If you are buying a full security service edge with web gateway and CASB as well, use the SASE and SSE RFP Template instead; for the market view read the ZTNA Buyer's Guide first.
How to use this template
- Replace text in square brackets, such as [Organisation], [identity provider], [MDM], [EDR], [SIEM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example ZT-APP-03) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational. Keep M items to the ones that genuinely decide whether the VPN can be switched off.
- Complete Appendix A (application inventory) and Appendix B (user populations) before issue. They are the most valuable part of the document: bidders who must say how each listed application will be published cannot hide behind feature lists.
- Percentages, user counts and weights in brackets are illustrative. Take application and user figures from at least 30 days of VPN gateway and firewall logs, not from the CMDB alone.
- Issue sections 1 to 8 and the appendices to bidders. Implementation guidance is for the evaluation panel only. Ask for responses in a spreadsheet, one row per requirement ID, with a documentation link for every "available now" answer.
1. Purpose and scope
[Organisation] invites proposals for a zero trust network access service that gives [employees, contractors and third parties] per-application access to private applications in [data centres, IaaS and OT DMZ], and that allows [Organisation] to decommission its remote access VPN by [target date].
- In scope: agent-based and agentless (browser) access to private web and non-web applications; application connectors or gateways; policy engine and administration; integration with [identity provider], [MDM] and [EDR]; logging to [SIEM]; migration services; VPN coexistence during transition.
- Out of scope: [secure web gateway and CASB, separate procurement]; [SD-WAN]; [site-to-site VPN between data centres]; [privileged session recording, covered by PAM].
- Contract term: [three] years with an option to extend by [two].
- Drivers: [VPN appliance end of support on date]; [internet-facing VPN exposure]; [flat network access for contractors]; [audit finding on remote access]; [merger integration].
- Design basis: requirements follow the zero trust tenets in NIST SP 800-207, in particular per-session, least privilege access decided by dynamic policy using identity, device state and context, with no implicit trust from network location.
2. Current state
| Item | [Organisation] value |
|---|
| Current VPN | [product and version], [number] gateways, end of support [date]; full tunnel or split tunnel |
| Concurrent and named VPN users | Peak [number] concurrent; [number] named; [percentage] contractors and third parties |
| Private applications reached over VPN | [number] identified from logs; [number] web; [number] non-web (see Appendix A) |
| Hosting locations | [number] data centres, [cloud regions], [OT DMZ], [branch servers] |
| Identity and device signals | [identity provider], MFA method [phishing-resistant / other], [MDM], [EDR], certificate authority [name] |
| Managed and unmanaged devices | [percentage] managed corporate; [percentage] BYOD; [percentage] third-party devices |
| Operating systems | [Windows, macOS, Linux, iOS, Android, ChromeOS] with counts |
| Logging and operations | [SIEM], [SOAR], [ITSM]; remote access support tickets per month [number] |
| Regulatory and residency constraints | [for example: logs and traffic must stay in UK or EU points of presence] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: available now; available with configuration; requires third-party product (name it); custom development; roadmap (committed date); not offered. Roadmap answers score zero unless the date is contractually committed.
- Appendix A response: for every application row, state the access method you propose (agent tunnel, browser access, other), the connector placement and any change [Organisation] must make to the application.
- Architecture: state the deployment model as NIST SP 800-207 describes it (device agent and gateway, enclave gateway, resource portal, or a combination) and where the policy decision and enforcement points run.
- Licensing: state the licence metric (named user, concurrent user, application, bandwidth, connector) and which requirements below need an additional licence or edition.
4. Functional requirements
4.1 Application access and protocol coverage
| ID | Requirement | Type |
|---|
| ZT-APP-01 | Users reach only the applications their policy permits. No network-level route, subnet visibility or port scan reach to other hosts is created on the client. | M |
| ZT-APP-02 | Supports TCP and UDP applications, including [SSH, RDP, SMB, database ports, thick-client ERP, VoIP and softphone, Kerberos and LDAP for domain-joined devices]. | M |
| ZT-APP-03 | Supports server-initiated and bidirectional flows needed by [helpdesk remote control, device management, patch distribution to remote endpoints], stating how each is configured. | M |
| ZT-APP-04 | Applications are defined by fully qualified domain name, wildcard domain or IP and port, and private DNS resolution works for split-horizon names without exposing internal DNS to the client. | M |
| ZT-APP-05 | Clientless browser access to web, SSH and RDP applications for unmanaged devices, with controls on download, upload, clipboard and print per application. | S |
| ZT-APP-06 | Application discovery: from an initial broad rule, reports which internal destinations users actually reach so least privilege policy can be built from evidence. | S |
| ZT-APP-07 | Explain how overlapping private IP ranges (for example after a merger) and IPv6 destinations are handled. | S |
| ZT-APP-08 | List any application types that cannot be published (for example multicast, some VoIP signalling, legacy protocols) and the recommended alternative for each. | M |
ZT-APP-08 is the requirement that decides whether the VPN can actually be switched off. See the ZTNA Guide for the access models.
4.2 Identity, device posture and policy
| ID | Requirement | Type |
|---|
| ZT-POL-01 | Authenticates users through [identity provider] using SAML 2.0 or OpenID Connect, with group and attribute mapping for policy, and supports SCIM for user and group provisioning. | M |
| ZT-POL-02 | Policy can require phishing-resistant multi-factor authentication per application and can force step-up authentication for sensitive applications. | M |
| ZT-POL-03 | Device posture is evaluated before access and continuously during the session, using [MDM] compliance, [EDR] status, OS version, disk encryption, device certificate and firewall state. | M |
| ZT-POL-04 | A change in user or device risk (account disabled, EDR alert, posture failure, session revoked in [identity provider]) terminates or restricts active sessions within [five] minutes. State the measured time and the mechanism. | M |
| ZT-POL-05 | Policy can use context including location, time, network type and risk score from [identity provider] or [EDR], with explicit precedence rules and a policy simulation or "what if" tool. | S |
| ZT-POL-06 | Separate policies and portals for employees, contractors and third parties, with time-bound access grants and sponsor approval workflows. | S |
| ZT-POL-07 | Policy is exportable and manageable as code through a documented API, with versioning and rollback. | S |
ZTNA decisions are only as good as the identity and device signals behind them. See the Phishing-Resistant MFA Guide and the Conditional Access vs ZTNA.
4.3 Connectors and gateways
| ID | Requirement | Type |
|---|
| ZT-CON-01 | Application connectors make outbound connections only. No inbound listener on the internet is needed to publish an application. | M |
| ZT-CON-02 | Connectors authenticate to the service with credentials or certificates that are unique per connector, can be rotated on a schedule [Organisation] sets, and can be revoked immediately from the console and API. | M |
| ZT-CON-03 | Connectors run as [virtual appliance, container, Linux package] with documented hardening, automatic or staged updates controlled by [Organisation], and no shell access by the bidder without [Organisation] approval. | M |
| ZT-CON-04 | Connector groups provide high availability and load balancing, and each connector can be restricted to the application segments it serves. | M |
| ZT-CON-05 | State connector sizing (users and throughput per instance) and the behaviour when a connector or its upstream service is unavailable. | S |
| ZT-CON-06 | Option for self-hosted or private enforcement points for [sites with data residency or latency constraints]. | S |
4.4 Client and user experience
| ID | Requirement | Type |
|---|
| ZT-CLI-01 | Clients for [operating systems in section 2], deployable silently through [MDM or software distribution], with tamper protection and no local administrator rights required for users. | M |
| ZT-CLI-02 | Coexists with the current VPN client during migration, stating any conflicts with routing, DNS or other security agents. | M |
| ZT-CLI-03 | Always-on and pre-logon connectivity options so domain authentication, device management and password changes work before user sign-in. | S |
| ZT-CLI-04 | Staged client update rings controlled by [Organisation], with the ability to pin and roll back versions. | S |
| ZT-CLI-05 | User-facing diagnostics and an administrator view of per-user connection health to reduce support tickets. | S |
4.5 Logging, monitoring and integration
| ID | Requirement | Type |
|---|
| ZT-LOG-01 | Every access decision is logged with user, device identifier, posture result, application, destination, policy matched, decision and reason, in a documented machine-readable format with UTC timestamps. | M |
| ZT-LOG-02 | Logs are streamed to [SIEM] in near real time, with alerting when forwarding fails, and retained by the service for [90] days at no extra cost. | M |
| ZT-LOG-03 | Administrator actions (policy, connector, client and tenant settings) are logged with previous and new values and cannot be deleted by tenant administrators. | M |
| ZT-LOG-04 | An API allows [SOAR] to revoke a user's or device's sessions and block a device, with scoped API credentials and audit of API use. | S |
See the VPN and Firewall Log Detection Guide for the detections these logs should feed.
5. Security of the service
A ZTNA service becomes the front door to every private application, so its own security is a first-order requirement. Several items below draw on the February 2025 NCSC guidance, co-sealed by ASD, CISA, the Canadian Centre for Cyber Security, the FBI and NCSC-NZ, on forensic and logging features that producers of network devices and appliances should build in. See the Securing the ZTNA and VPN platform guide.
| ID | Requirement | Type |
|---|
| ZT-SEC-01 | Tenant administration requires single sign-on through [identity provider] with phishing-resistant MFA, supports role-based administration with least privilege roles, and allows break-glass accounts to be controlled by [Organisation]. | M |
| ZT-SEC-02 | Bidder staff access to [Organisation]'s tenant or data requires [Organisation] approval, is time-limited and is logged in the tenant audit log. | M |
| ZT-SEC-03 | No internet-facing service at [Organisation] sites is required for user access (connectors are outbound only; see ZT-CON-01). | M |
| ZT-SEC-04 | Connector and any self-hosted components send heartbeat messages including software version and a configuration digest, support collection of running state for investigation, and log update and configuration change events. | S |
| ZT-SEC-05 | Provide current independent assurance reports (for example ISO/IEC 27001 certificate and scope, SOC 2 Type II) covering the proposed service and regions. | M |
| ZT-SEC-06 | Publishes a vulnerability disclosure policy and security advisories, states target times to fix critical vulnerabilities in connectors and clients, and notifies customers of security incidents affecting their tenant within [24] hours of confirmation. | M |
| ZT-SEC-07 | State where traffic is decrypted, if at all, which points of presence handle [Organisation]'s traffic and logs, and how encryption keys are managed. | M |
| ZT-SEC-08 | State the service availability commitment, the history of major outages in the last [24] months, and the user experience if the cloud control plane is unreachable (fail open, fail closed or cached policy). | M |
6. Migration, coexistence and services
| ID | Requirement | Type |
|---|
| ZT-MIG-01 | A migration plan in waves (for example: web applications for employees, then contractors and third parties, then non-web applications, then remaining VPN users), with entry and exit criteria per wave. | M |
| ZT-MIG-02 | A method to convert current VPN access groups and firewall rules into per-application policies, using application discovery (ZT-APP-06) to remove unused access. | S |
| ZT-MIG-03 | A rollback approach per wave so users can return to VPN access within [one] business day if a wave fails its exit criteria. | M |
| ZT-MIG-04 | Defined VPN decommission criteria the bidder will help evidence, for example zero VPN sessions for [30] days except approved exceptions, and an exception register with owners and end dates. | S |
| ZT-MIG-05 | Support: severity definitions, response times, named technical contact, and administrator training for [number] staff. | M |
| ZT-MIG-06 | Exit: export of policies, application definitions and logs in documented formats at contract end, and deletion certificate for [Organisation] data. | M |
See the ZTNA vs VPN for the migration logic and the SASE Migration Guide if the project later extends to web security.
7. Pricing
| Line | Year 1 | Years 2 to 3 | Notes required |
|---|
| User licences per Appendix B population | [ ] | [ ] | Named or concurrent; contractor and third-party pricing |
| Clientless and third-party access | [ ] | [ ] | Whether included or separately licensed |
| Connectors and self-hosted enforcement points | [ ] | [ ] | Any limit on number or throughput |
| Log retention and streaming | [ ] | [ ] | Retention included; cost of extension |
| Migration and professional services | [ ] | Not applicable | Days per wave; fixed or time and materials |
| Support | [ ] | [ ] | Level and response times |
State renewal price caps, the cost of user growth of [20%], and any feature in sections 4 to 6 that needs a higher edition. Include the period during which [Organisation] must run VPN and ZTNA in parallel in your total cost.
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|
| Application coverage against Appendix A (4.1) | [25%] | Proof of concept with real applications |
| Identity, posture and session revocation (4.2) | [20%] | Measured revocation time |
| Security of the service and connectors (4.3, 5) | [20%] | Assurance reports, advisories, design review |
| Migration plan and VPN decommission support (6) | [10%] | Wave plan, references |
| Client experience and operations (4.4, 4.5) | [10%] | Pilot user feedback, logs in [SIEM] |
| Three-year total cost including parallel running | [15%] | Pricing schedule |
A bidder failing any M requirement is excluded. Score S requirements 0 (not met) to 5 (fully met and demonstrated), multiply by weight and record the evidence for each score. Shortlisted bidders run this proof of concept over [two to four] weeks:
- Publish [ten] applications from Appendix A, including at least two non-web, one server-initiated flow and one legacy thick client, through connectors in [two] locations.
- Confirm with a test client that no other hosts in the connector's network are reachable or discoverable.
- Give a pilot group of [25] employees and [five] contractors access, with contractors on unmanaged devices using browser access only.
- Disable a pilot user in [identity provider], trigger an EDR alert on a pilot device, and fail a posture check. Measure the time until each active session ends.
- Rotate and then revoke a connector credential and confirm the connector stops serving traffic and the event is logged.
- Stop one connector in a group during an active RDP session and a file transfer, and record failover behaviour.
- Confirm access decisions and admin changes arrive in [SIEM] with the fields in ZT-LOG-01 and ZT-LOG-03, then use the API to revoke a session from [SOAR].
- At the end, remove proof of concept connectors, tenant admin accounts and API credentials, and record that they are gone.
Appendix A: application inventory
| Application | Protocol and ports | Location | User populations | Flow direction | Criticality | Bidder access method |
|---|
| [Intranet portal] | [HTTPS 443] | [DC1] | [All employees] | [Client to server] | [Medium] | [ ] |
| [ERP thick client] | [TCP 3200-3299] | [DC1] | [Finance] | [Client to server] | [High] | [ ] |
| [Linux servers SSH] | [TCP 22] | [Cloud region] | [Engineers, supplier X] | [Client to server] | [High] | [ ] |
| [Helpdesk remote control] | [vendor ports] | [DC2] | [IT support] | [Server to client] | [Medium] | [ ] |
| [Softphone] | [SIP, RTP UDP range] | [DC2] | [Contact centre] | [Bidirectional] | [High] | [ ] |
| [OT historian replica] | [HTTPS 443] | [OT DMZ] | [Process engineers] | [Client to server] | [High] | [ ] |
Appendix B: user populations
| Population | Count | Device type | Access method | Notes |
|---|
| [Employees, managed laptops] | [ ] | [Windows, macOS] | [Agent] | [Always-on] |
| [Employees, BYOD] | [ ] | [Mixed] | [Browser] | [Web and RDP only] |
| [Contractors] | [ ] | [Unmanaged] | [Browser] | [Time-bound] |
| [Third-party support] | [ ] | [Supplier devices] | [Browser] | [Sponsor approval, session limits] |
| [Developers and administrators] | [ ] | [Managed] | [Agent] | [Consider PAM for privileged sessions] |
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Build Appendix A from logs, not memory: export 30 or more days of VPN session and firewall logs, group destinations by host and port, and confirm owners. The applications nobody listed are the ones that keep the VPN alive after go-live.
- Score ZT-APP-08 honestly: a bidder that lists its limits is more useful than one that answers "available now" everywhere. Test every claimed non-web and server-initiated flow in the proof of concept.
- Measure revocation, do not accept a claim: ZT-POL-04 separates services that re-evaluate sessions from those that only check at login. Record the measured seconds per bidder.
- Treat connectors as non-human identities: each connector holds a credential with reach into a network segment. Record connectors in your identity inventory with an owner, rotate their credentials and remove unused ones. See the Service Account Security Guide.
- Do not let the new front door repeat the old one: ZTNA policies copied wholesale from VPN groups recreate broad network access. Start broad only with discovery on, then narrow to per-application rules before each wave closes.
- Plan the VPN switch-off as a deliverable: set a date, an exception register and an owner for each exception. Harden and monitor the VPN while it remains; see the Edge Device Security Guide and the ZTNA and remote access VPN health check.
- Keep third-party access separate: map supplier access to the Third-Party Access Guide and route privileged supplier sessions through PAM where session recording is required.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|
| Application access and connectors (4.1, 4.3) | AC-17, SC-7, AC-6 | PR.IR-01 | T1133 External Remote Services |
| Identity, posture and policy (4.2) | IA-2, AC-6 | PR.AA-05 | T1078 Valid Accounts |
| Logging and monitoring (4.5) | AU-6 | DE.CM-01 | Supports detection of T1078 and T1133 |
| Security of the service (5) | SA-4, SI-2 | GV.SC-05 | T1190 Exploit Public-Facing Application |
The CISA Zero Trust Maturity Model describes progress from traditional through initial and advanced to optimal stages; a completed ZTNA rollout with continuous posture checks is a large step for its networks and devices pillars, but not the whole model.
Standards and references
Related NHI Mgmt Group resources: ZTNA Buyer's Guide · ZTNA vs VPN · ZTNA Guide · Security Vendor Evaluation and RFP Guide · Workforce SSO and Access Management RFP Template