‘Zero Trust’ is perhaps the most overused term in the cybersecurity lexicon. You’ll find it in almost every vendor presentation and on every conference slide; but if you then ask a CISO or an IT manager what they’re actually doing to put it into practice, they’ll often give a vague answer or change the subject.
The point is that for years, Zero Trust has been marketed as a product, whereas it is primarily a different way of designing security. And you can’t buy an architecture off the shelf: you build it piece by piece, with a few clear ideas and some hard work.
What does it actually mean?
The standard definition is that provided by NIST in publication 800-207. In a nutshell, Zero Trust shifts defences away from the old network perimeters towards what really matters: users, devices and resources. Put another way, you stop trusting someone simply because ‘they’re inside the network’ and verify every access attempt, every single time.
No more automatic trust based on location (internal network or the internet) or the device’s owner (company-owned or personal). The person requesting access and the device they are using are authenticated and authorised before a session with a resource is opened – and the process starts afresh every time.
That’s why “you can’t just buy it”. A more robust firewall or MFA tacked onto a VPN isn’t enough: you need to rethink the way you decide who accesses what, when and under what conditions. The reassuring thing is that this is a journey, not a complete overhaul — you almost never need to throw away the technology you already have. In fact, most companies already have the building blocks to implement Zero Trust in-house, and will coexist with a hybrid setup for quite some time during the transition. And that’s perfectly normal.
Why is there so much talk about it at the moment?
The old corporate perimeter – that imaginary line between the ‘secure inside’ and the ‘dangerous outside’ – is no longer so clear-cut. The cloud, mobile devices and the IoT have blurred many boundaries. Hybrid working is the norm; applications are spread across on-premises, the public cloud and SaaS; and even suppliers and partners access the network from outside, sometimes sharing the same accounts.
NIST puts it this way: the entire private corporate network should be treated as a zone of implicit trust, and it is best to act as if an attacker were already inside.
The figures help to explain why. According to the IBM report, in 2024 a data breach cost an average of 4.88 million dollars. And the ZTA market exceeded 29 billion in 2024, with estimates suggesting it will reach over 113 billion by 2033: a sign that the driving force behind this growth stems primarily from the threat landscape.
The seven NIST principles
NIST lists seven basic assumptions – known as ‘tenets’ – upon which a Zero Trust architecture is built. In summary:
- Every data source and every computing service is an asset that must be protected.
- All communications are secured, wherever they take place.
- Access is granted on a per-session basis, not once and for all.
- Decisions are based on dynamic policies that take into account identity, application and device status.
The health of assets is continuously monitored. - Authentication and authorisation are dynamic and take place before access is granted.
- As much data as possible is collected on systems and communications to enable continuous improvement.
In practice, this boils down to a few fairly simple rules.
Always verify identity
It doesn’t matter where the request comes from — the office, home or the airport: it must be authenticated. And the person’s credentials alone are not enough, because the device must also be verified.
Give everyone only what they need
This is the principle of least privilege: no one should have more access than their job requires, and being able to access one resource does not mean they can access others as well.
Monitor internal traffic as well
Lateral movement within the network has always been the preferred route for attacks once the first barrier has been breached.
Assume you’ve already been breached
Designing as if a breach has already occurred changes priorities: internal traffic is viewed with the same suspicion as external traffic.
Where the real action is: between on-premises and the cloud
The interesting aspect of Zero Trust is not so much ‘controlling access’ as maintaining the same level of security whilst people, devices and applications are constantly moving between the organisation’s infrastructure and that of third parties.
Here too, NIST is quite clear. Assets and processes moving from one environment to another must retain the same level of protection. This applies to a laptop taken out of the office and connected via home Wi-Fi, and it applies to a workload migrating from an on-premises data centre to a cloud instance. In neither case should security be compromised simply because the network location has changed.
A second, more operational point concerns the VPN: a remote device should be able to access corporate resources without first having to ‘re-enter’ the organisation’s network. Making the user reconnect via the VPN before routing them to a cloud service — even if it’s just email — forces the traffic to take a long and unnecessary detour, slows everything down and concentrates the risk at a single point of transit.
The same applies across different clouds: NIST describes the multi-cloud scenario as one of the most suitable for Zero Trust. If an application on one provider needs to communicate with data on another, the most sensible approach is to place control points (Policy Enforcement Points) in front of each service and each data source. This way, you continue to manage access even when resources are located off-premises.
All this also has implications for the tools used. It is worth asking, as NIST suggests, whether the solution requires an agent on every device: if so, it becomes cumbersome to cover BYOD scenarios or external collaborations. Furthermore: does it work when resources are all on-premises, or does it assume everything is in the cloud? The choice should be guided by where the resources to be protected actually reside, not the other way round.
One final point regarding configuration across different providers: each does the same things in its own way, and the designer must know how to adapt the architecture to each one. The real risk is becoming too tied to proprietary formats and interfaces, only to find that switching providers is costly and fraught with difficulties. It is better to evaluate providers as a whole — security, migration costs, supply chain — and not just on the basis of price and performance.
Five steps to get started for real
Let’s try to put this into practice, whilst keeping an eye on the line between on-premises and cloud solutions.
A robust IAM system, with MFA across the board
Identity becomes the new perimeter. NIST calls for dynamic authentication, which is re-evaluated throughout the session rather than granted just once upon login. In practice: MFA for all critical access points, without exception. And in a hybrid environment, that same identity must be subject to the same rules for both internal resources and SaaS services.
Network segmentation and micro-perimeters
A flat network is a dream for attackers: once inside, they can go wherever they like. Micro-segmentation isolates workloads and brings controls closer to the resources. It is best to start with the most critical elements and expand gradually. The tricky part, in a hybrid environment, is achieving equivalent segmentation between data centres and the cloud, where the native tools differ.
Visibility into endpoints and unusual behaviour
It’s a cliché, but it’s true: you can’t protect what you can’t see. You need to know which devices are connecting, where they’re coming from and how they’re behaving. NIST recommends a system that continuously feeds decisions with the real-time status of assets — versions, patches, known vulnerabilities. Be careful, though: in the cloud and with unmanaged devices, visibility can be sporadic, and certain models only detect the device when it connects.
Assume you’ve already been breached
Designing as if a breach has already occurred changes priorities: internal traffic is viewed with the same suspicion as external traffic.
Want to understand how to practically apply Zero Trust principles within your organization?
Contact us for a discussion with our experts.