How to implement zero trust network access

Before you start

The NCSC says many ZTNA deployments fail not for lack of technology features but because legacy trust assumptions are carried forward: a new product is installed, but the access model, identity foundations and old routes stay as they were. The NCSC's ZTNA guidance calls this recreating the walled garden. Before choosing a platform, agree three things:

• The goal: usually per-application access, applications hidden from the internet and a remote access VPN retired, rather than "install ZTNA"
• The scope: which users, devices and applications are in the first phase, and which (if any) stay on a tightly restricted legacy route for now
• The owner: someone who can make decisions about access policy, not just the technology

It also helps to read the NCSC zero trust principles, because ZTNA works best as one part of a wider zero trust plan.

The phases of a ZTNA rollout

1. Inventory users, devices and applications. List every application people reach remotely, how they reach it today (VPN, RDP, published web app), who uses it and what protocols it needs. Include contractors and service accounts. *NCSC: checking organisational readiness.*
2. Fix identity and MFA foundations. One authoritative identity provider such as Microsoft Entra ID, single sign-on where possible, MFA for every account and phishing-resistant methods for administrators. Tidy groups and roles, and make sure leavers lose access promptly. *NCSC: identity prerequisites; requirement 3, use multiple signals.*
3. Bring devices under management and define posture. Enrol devices in MDM, set a compliance baseline, deploy EDR, and decide which posture checks each policy will use. Decide how unmanaged devices will be treated. *NCSC: device prerequisites.*
4. Secure internet access. Block known malicious domains and log internet activity centrally, through DNS filtering or a secure web gateway, before or alongside private access. Decide deliberately whether to tunnel web traffic or inspect TLS. *NCSC: internet access controls.*
5. Choose the access method for each application. Client-based ZTNA for most internal apps on managed devices, clientless access for contractors and BYOD, an RDP broker for desktops, and VPN as a service only where an app truly needs it (see the table below). *NCSC: requirement 4, minimise exposure of applications.*
6. Select a platform and pilot. Shortlist two or three platforms, then trial with a small, representative group on real applications, including at least one awkward legacy app. Test re-evaluation, logging and what users see when access is refused. *NCSC: gaining confidence in a product.*
7. Migrate application by application. Install connectors beside each application, write the policy, move a group of users, confirm it works, then move on. Start with simple web apps and leave the hardest until last. *NCSC: requirement 2, enforce policy before granting access.*
8. Close the old VPN and legacy routes. Remove the VPN profile from devices, close the inbound ports, remove static firewall rules and published RDP, and retire VPN address pools from any allow-lists. Anything that must remain is tightly scoped and documented. *NCSC: anti-pattern, maintaining legacy access routes that bypass the policy engine.*
9. Monitor and re-evaluate. Send access logs to your SIEM, review denied requests to tune policy, test the break-glass route, and revisit policies as applications and risks change. *NCSC: requirements 6, 7 and 8.*

Phases 2 to 4 often run in parallel, and phases 7 and 8 repeat for each group of applications. For the project view of retiring a VPN, including what changes for users, see our VPN replacement project guide.

Choosing the access method for each application

No single access method suits every application. A typical mapping:

Which platforms handle which of these is set out on ZTNA providers.

Common pitfalls

These are common ways a ZTNA project falls short, several of which match the NCSC's anti-patterns:

• Lifting and shifting the VPN's access rules. Giving the "staff" group access to a whole subnet through ZTNA recreates the walled garden. Scope by application.
• Leaving the VPN running "just in case". It becomes the route attackers use. Set a date to close it, and restrict anything that must remain.
• Trusting office IP ranges or VPN pools in conditional access or firewall allow-lists. The NCSC calls this trusting network location.
• Skipping device posture because the device estate is untidy. Without it, a stolen password on a personal laptop gets the same access as a managed device.
• Weak MFA. Text-message codes and push approvals are better than nothing, but phishing-resistant methods are what the NCSC's identity prerequisites point to.
• Forgetting resilience. A policy change or provider outage that locks everyone out is a real risk; phase changes and keep a tested break-glass route.
• No one reading the logs. ZTNA produces rich logs; they only help if they reach a SIEM and someone reviews them.
• Ignoring lateral movement. ZTNA controls user-to-app access. Servers talking to each other need segmentation too; see network segmentation vs microsegmentation.

How long it takes and what it costs

Timescales depend mostly on the state of identity and device management and on the number of applications. An organisation with tidy Microsoft Entra ID groups, Intune-managed laptops and a dozen web apps is in a very different position from one with several directories, unmanaged devices and decades-old line-of-business software. A pilot with one group of users and a few applications is a sensible first milestone, and full migration is normally phased. We confirm timescales at quote once we have seen your inventory.

Costs come from three places: platform licences (per user or per device, depending on the vendor), any add-ons such as static IPs or dedicated gateways, and the design and migration work. Against that, you may be able to retire VPN appliances, RDP gateways and their support contracts. Our page on zero trust network access cost explains the drivers; for figures, ask us for a quote.

What we do

We can take a zero trust network access project from inventory to the day the old VPN is switched off, or help with any part of it:

• Scope: inventory of users, devices and applications, and a written plan mapped to the NCSC requirements
• Foundations: identity, MFA and device management work so policies have reliable signals
• Platform choice: a shortlist from the platforms we supply and a structured trial
• Pilot and migration: connectors, policies and clients, moved application by application
• Closure: removing the old VPN, inbound ports and legacy rules, then tuning from the logs

Scope and timescales are confirmed at quote. Contact us to start with a conversation about your current remote access.