Zero Trust

• What do we mean by zero trust?
• What do we mean by zero trust architecture?
• Zero trust is a different security model
• Zero trust is not a quick fix
• Zero trust is not a product
• Zero trust means more security controls, not fewer
• Zero trust doesn’t mean no trust
• Zero trust and a VPN are not mutually exclusive
• You do not ‘complete’ zero trust
• Key takeaways

ZT is a modern security approach – or philosophy – that challenges the traditional assumption that anything inside an organisation's network can be trusted by default. It reduces the risk of compromise by eliminating inherent trust in the network through continuous validation of identity, context and risk signals before granting access to any resource or service.

It aims to reduce the risk of unauthorised access, lateral movement, and data compromise by limiting access only to what is required, and closely monitoring activity.

A ZT architecture describes how the ZT security approach is realised in the design of your systems and networks. The architecture follows a framework that maps to the ZT philosophy, combining multiple security controls, technologies, and design principles so that each user, device and service is continuously authenticated, authorised and validated before accessing any resource, regardless of where they are on the network.

The NCSC’s Zero trust architecture design principles provide detailed guidance on the components and approaches you can use to design an architecture that delivers ZT outcomes.

It's useful to contrast the ZT security model with the traditional 'castle and moat' security model. In the latter, the ‘moat’ represents perimeter defences such as firewalls protecting the ‘castle’ – that is, your organisation’s networks and data – from anyone trying to enter. If you're allowed across the moat (having been authenticated at the perimeter) you can usually move freely inside. Once you are past the boundary, most of the network is accessible.

 The ZT security model is different from this, and a useful analogy is an airport. At each stage of your journey through the airport, you must prove your identity in different ways, often more than once, before you can proceed.

You’re only allowed onto the specific aircraft you have permission to access - which equates to the system or resource in a network. Continuous monitoring detects suspicious activity, for example checking if your name is on a no-fly list. And if you leave and return to the airport, you must verify again who you are and where you want to go.

This approach uses granular controls throughout, rather than relying on authentication at a single point of entry.

ZT can be a powerful approach to strengthening your security. It encourages better identity controls, and continuous verification and segmentation, which can significantly reduce risk when applied well. However, it should be adopted deliberately, not just because it’s the latest industry trend.  It’s a strategic commitment – not something you simply ‘turn on’. It represents a significant shift in how you design, build and operate your systems.

The first thing to understand is your organisation's specific security challenges. ZT can be costly, disruptive and resource-intensive. If pursued without a clear understanding of specific risks and objectives, it can lead to a wasted effort or even reduced effectiveness.

Organisations should define the threat scenarios they are trying to address, assess existing capabilities, and consider whether a ZT approach is warranted or if targeted controls could deliver similar benefits.

Think of ZT as an architectural approach, and not a product you can buy off the shelf. It's a collection of security controls and designs that work together to give you a modern way of managing your systems and networks.

Just as you wouldn't buy a single cyber security product and expect it to meet your organisation's disparate prevention, detection, response and recovery needs, the same is true of your approach to ZT. Achieving ZT involves:

• understanding the risks you want to manage
• designing the right security controls
• defining priorities
• planning how to implement them

ZT is not a one off solution. The NCSC believes that full migration may require rearchitecting many of your systems over several years. The NCSC's Zero trust architecture design principles highlight the many steps required, including choosing a range of vendors, products and services.

Implementing ZT should strengthen the security of your network. A well-designed approach applies the principle of defence in depth, ensuring that multiple layers of protection are in place. If, after implementation, the network architecture lacks segmentation and allows unrestricted movement, this indicates that the design or configuration needs to be reviewed and strengthened.

 ZT may allow you to replace certain security controls, but ‘replace’ is the key word. The new controls may look entirely different, but they still need to manage the existing risks.

Make sure existing security controls remain in place until your ZT architecture is mature enough to provide equivalent or stronger protections. Migrating away from existing controls too quickly can create gaps in your security.

As a term, ZT can be misleading, as there is actually plenty of trust required throughout a ‘zero’ trust architecture. The key principle is don’t inherently trust any user or service requesting access to systems or data. This means building up trust using the many different signals a ZT architecture provides, until you’re confident that the user or service is authorised and genuine.

In this way, you can build up trust to a level commensurate with the amount of confidence you need in the user or service making the access request and their authority level in that context. For example, a user wanting access to a word document would require fewer and/or weaker signals than a user requesting access to change another user's password.

Finding a replacement for your VPN should not be the goal of adopting ZT, and the decision to keep or remove your VPN will depend on your organisation's goals and risk appetite. While a ZT approach allows for alternatives to traditional self-hosted VPNs, it is still possible to operate a ZT architecture that leverages the benefits of both ZT and a VPN.

Over time, a VPN may become less essential, but VPNs provide specific security controls that ZT alone may not. You should review and consider everything your VPN currently offers, identify any controls you depend on, and only remove your VPN once those controls have been replaced. The NCSC provides guidance on the security controls VPNs deliver and how to assess whether you should remove them.

If you choose to implement ZT with a VPN, do not inherently trust the traffic that comes via the VPN. The ZT mindset still applies: use a mix of signals to built trust in users, devices and services.

If someone told you they had ‘completed cyber security’ instant alarm bells would sound – because security isn’t something that gets ‘finished’. It must continuously adapt to new technologies, vulnerabilities and threats – and ZT is no different.

You should have a structured plan for progressing towards ZT, but accept that it will always be a moving target. Technology changes, vulnerabilities emerge, and threats evolve – meaning your architecture must continually adapt. It’s worth bearing in mind that some ZT controls are still theoretical and may not yet exist, so your implementation will need to grow as new capabilities become available.

At points, you'll reach milestones where your network more closely aligns to ZT, and may have achieved as much as you’re able to with current tools. That's a positive step, but it isn't the end of your journey. As new security controls are released, as technology advances and new risks emerge, you should update your roadmap and take action to further strengthen and evolve your ZT architecture.