Zero Trust

There are a couple of options to consider as you start your zero trust migration journey. Are you implementing zero trust architecture principles into an existing system, or starting from scratch? If the former, creating a plan to do so in a methodical phased approach is essential. Set milestones along the way to ensure you are on track, and so you don’t bring any of those loose security rules along for the ride that we often see from a more traditional architecture.

You may be in a flexible-enough position to have the luxury of implementing zero trust architecture in parallel to your existing IT estate. Or perhaps this is a new system, and you can build from the ground up in a greenfield approach. Either way, you will still need to use our principles to plan your architecture.

Starting with our first principle, I always like to start with an inventory; what do my existing users, devices, services, and data look like? Create or utilise existing tooling to automate your inventory where possible. What do my users currently have access to, and what should they have access to? This is the perfect time to document and scope the least privileges possible for users to carry out their duties. This will also help you identify inactive accounts, because people have left the organisation for example, which should be removed.

Our second principle states that your organisation should use a definitive user directory, with accounts linked to individuals. This could be in the form of a virtual directory or through directory synchronisation. The important part to consider here is giving the appearance of a single user directory. A first step could be to consolidate your identities into one central identity store, with permissions set on a granular basis scoped to the least privilege possible. Enabling multi-factor authentication is a key zero trust principle, and can be enabled with minimal disruption to the end users. A username and strong password, plus a second factor of authentication are the minimum you should aim for. This could be a good opportunity to look at other options like password-less authentication which is becoming increasingly prominent.

What sort of devices are in use across your estate? Careful planning and consideration for different operating systems in use at this early stage will make it much easier to configure and monitor devices throughout their lifecycle. A mobile device management (MDM) solution is an important consideration for your zero trust architecture, it forms one of the key signals into the zero trust policy engine (PE). We would expect to see the MDM provide a unique identity to each of your devices.

Not all MDMs are created equal, you should assess the operating systems and devices within your estate and future roadmap, and select an MDM that gives you the level of granular control to configure inline with our device security guidance. Policies should be configured within your MDM to continually evaluate compliance against those defined policies, as we describe in our MDM guidance.

It is important to know the services your users are connecting to. As part of your zero trust strategy, a service discovery phase will help you map existing or desired services within your environment. Your directory will need to be compatible with all existing or desired services within your architecture, no matter where they are accessed from. This will provide a single source of identity and sign-on for users, which allows for a better user experience, but also permit a single strong identity for all services.

Do you allow any bring your own device (BYOD) scenarios? For most scenarios, it is already assumed that there is little or no trust in the device itself. This is because it is very difficult for your organisation to gain assurance in the configuration and management of devices you do not own. Removing trust in the devices moves the focus to trust in your controls over your data, services, authentication controls and policies. Our BYOD guidance can help further with deploying these types of devices.

Conducting a risk assessment at an early stage will help you identify what can and cannot be mitigated as part of your zero trust architecture. It can also help you to validate any existing security measures. Conducting a risk assessment at an early stage is essential as there may be risks to your environment that can't be mitigated with a zero trust architecture.

Taking a repudiation-related threat as an example, we might be concerned that a user could dispute changes to our finance spreadsheet. Using a cloud-based file service, we can easily implement logging to capture the access request and make that user action non-repudiable. This will ensure we have the evidence to demonstrate changes users have made to our finance spreadsheet, that cannot then be disputed. In this example, the service we want to utilise in our zero trust architecture provides this requisite security functionality.

Your risk assessment will likely highlight the need for additional controls over and above any native functionality your chosen service provides. For example, taking an availability-related threat to services, such as a DDoS attack, may not be mitigated by zero trust. It’s appropriate therefore to choose services with additional controls that can mitigate this.

Before you start implementing your zero trust plan, conducting a risk assessment can help you pick services that have already been designed to include functionality that meets your security requirements. If the risks identified cannot be mitigated using zero trust Architecture, some of your existing security controls may need to stay in place.

Now you’ve completed your discovery phase, start to think about how to move through the rest of the zero trust principles - zero trust is an iterative approach, and technologies are changing all the time.

It may be that for the time being you introduce legacy on-premise applications to your zero trust network via an application proxy (an upcoming blog topic). However, as part of your strategy, aim to use native cloud SaaS applications or look to rebuild legacy services using modern technologies.

The important point here is how you achieve your zero trust strategy, your roadmap, is not set in stone and allows you to take advantage of upcoming technology and improved security features.

Here is a list of the key considerations when starting your zero trust journey:

• identify your users and required permissions and use this to design your identity and access management solution making use of MFA, and considering other authentication mechanisms (such as password-less authentication)
• identify the devices and services you require to help inform your decisions on services such as MDMs and identify zero trust compliant services
• identify services through a discovery phase to map existing or desired services.
• threat model your proposed architecture to understand the threats posed to your organisation and infrastructure to help you build in mitigations
• don't forget your existing security measures, but don't simply re-implement them!

Hopefully this blog post sets out a starting point to begin to define your zero trust strategy. Our next blog in this series will cover connecting to a system that can’t support zero trust natively.

16/01/2026: This content was first published as a blog and has been updated to amend links.