Skip to main content

Zero Trust: the hurdles for implementation

Gemma Moore, director at Cyberis, explores the challenges in moving from traditional corporate architectures to Zero Trust

Homeworking at an unprecedented scale has been enforced by the pandemic and created a new disparate landscape for technology security. This perimeter-less, distributed corporate environment built around the cloud, lends itself to a Zero Trust model.

Zero Trust is essentially an approach to IT security that requires strict identity verification for every person and device trying to access private resources, regardless of whether the requestor is sitting within, or outside, of a network perimeter and regardless of the location of the resource.

Traditional architectures relied on a strong perimeter which was closely monitored – the inside of the perimeter was a “trusted” zone where those inside enjoyed various privileges by virtue of being inside, and the outside of the perimeter was “untrusted”.  Even before the pandemic, as businesses have adopted cloud-based services to a greater or lesser extent, that perimeter had become increasingly porous.  In a true Zero Trust environment, the perimeter does not exist at all – there is no zone of trust and all requests for access to resources are assessed on their own merits.

Implemented correctly, a true Zero Trust architecture lends itself to flexibility, agility and extensibility, but Zero Trust deployments are easiest to implement as greenfield developments, where the model is built in at the early design phases.  When retrofitting Zero Trust onto existing networks, there are some considerable challenges you might encounter.

Understanding your business

At heart, the Zero Trust model is about living and breathing the ‘least privilege’ principle – you have no internal zone of trust.  Every time somebody wants to access a resource, an application or a data asset – you check and verify that request and grant or deny access as appropriate.  Done properly, people only have the user rights necessary to do their day-to-day work, whilst they need them, and they have no access to resources or applications that they don’t need.

For enterprises looking to migrate to Zero Trust, this throws up their first hurdle: How well can you define what people actually do?

We need to know how business processes and job roles map on to existing systems – who accesses the data, why, when and how.  That might sound like a straightforward task, but in any business which has been around for a while mapping data paths and processes can be a herculean task requiring a huge investment of time.

Mapping your processes involves nuance.  Even a concept such as ‘a user’ is complex for most enterprises these days.  Users aren’t just employees – they will also encompass customers accessing your services, members of the supply chain and service providers.  All of these relationships need to be considered. 

Devices that would be accessing your resources might be owned by you, but they might also fall within Bring Your Own Device paradigms, or be owned by suppliers.

You could have hundreds or thousands of applications being used within your organisation in different ways by different user populations.

Making sure you get the definition of a business right is important. If not, you might enable access for people who don’t need it, thus reducing the security benefits of the architecture, or hinder productivity by preventing people from working as you restrict their access.

Realising what can’t be done

Whatever your business, technical debt tends to build up.  There’s a finite amount of time available and over time, resources tend to become focused on maintaining BAU operations rather than implementing new projects.  The result is that when new functions need to be considered, they are often implemented as quick fixes, or as add-ons to legacy systems to reduce the up-front investment needed on a project.  Technical debt can be a real problem when moving to Zero Trust.

Even if you understand completely how your users work and your internal processes operate, you may find that you have custom applications or systems that simply don’t lend themselves to a Zero Trust approach, or where the investment needed to convert or replace these would be disproportionate to the return the business would achieve.

These applications might rely on peer-to-peer communications inside a trusted enclave, or explicitly rely on internal trust relationships existing.  They might have no API that would facilitate the authorisation checks needed for true Zero Trust capabilities.  It might be that they lack the security parameters that would help you to identify individual users in the first place – perhaps they have never even had the concept of a ‘user’.

Zero trust: Is it going to be worth it?

A Zero Trust architecture beings huge security benefits when implemented correctly.  You gain added resilience because your users are operating with least privilege.  Lateral movement becomes very tricky for an adversary.  Because you can track the exercise of rights and access to resources in real time, you have added visibility.  Where your solutions are well-architected, you also gain agility through the centralised management of privileges so that these can be granted and revoked in real time.  This makes Zero Trust an attractive goal.

However, add together the complexity of fully understanding your user population and use-cases, and the impact of accumulated technical debt, and the effort involved in migration from a traditional architecture to a Zero Trust approach can be significant.

The chances are that you will need to purchase, implement and maintain several different solutions or components to make a Zero Trust approach work as you want it to, and that implementation requires careful planning.  You will also need to plan to maintain the solutions you choose.

It might even prove to be cost-prohibitive.

Where you have legacy components and applications, you may find that you need to compromise your approach and create islands of traditional infrastructure without your key authentication and access control mechanisms, and therefore find your visibility of activities within these areas compromised.  Inside these ‘legacy silos’, you will remain vulnerable to traditional types of lateral movement attacks and therefore you won’t realise the full security benefits of Zero Trust.

As with every business decision, it comes down to a cost/benefit analysis – is investment in the redevelopment of systems or applications to support Zero Trust going to be worth the potential security improvements you will see?  That will obviously depend on your threat environment and your risk appetite.

Gemma Moore is a highly experienced penetration tester and co-founder and director of the information security consultancy, Cyberis. She is also a member of the CREST GB Executive

Main image courtesy of


All rights reserved Teiss Recruitment Ltd.