Zero trust security for UK SMEs: what it actually means and where to start

What zero trust actually means (and what it isn't)

Zero trust is a security philosophy built on a single principle: never trust, always verify. Every request for access – to a file, an application, a system – is verified before it's granted, regardless of where the request comes from. That includes requests from inside your own network.

That last part is what distinguishes it from the traditional approach. In a perimeter-based model, a firewall protects the edge. Anything inside the perimeter is assumed to be legitimate. Once someone is on the network – through a VPN, a site-to-site connection, or by walking into the office – they can generally access most of what's there. The logic is: if you got past the gate, you must be allowed in.

Zero trust discards that assumption entirely. It treats every access request as potentially hostile, regardless of network location. Verification happens at the point of access, every time.

It's also worth being clear about what zero trust is not. It's not a product you can buy. Any vendor selling "zero trust in a box" deserves scepticism. Zero trust is an approach – a set of principles applied progressively across your identity, devices and network. You don't implement it all at once, and you don't need to rebuild everything to start.

Why the old perimeter model doesn't work anymore

The perimeter model made reasonable sense when everyone worked from a single office, on company-owned machines, connected to on-premise servers. The network edge was a real boundary. Defending it was the primary job.

That picture no longer reflects how most businesses operate. Staff work remotely – from home, from client sites, from coffee shops. They use personal devices alongside managed laptops. Applications have moved to the cloud: Microsoft 365, SharePoint, line-of-business tools hosted by third-party providers. The "inside" of the network is no longer a meaningful concept when the data lives in Azure and the person accessing it is at home on their home broadband connection.

The other problem is what happens when an attacker gets inside. A phishing email that captures a user's credentials, or malware that establishes a foothold on one machine, can travel laterally through a flat network with relative ease. If you're trusting everything inside the perimeter, a single compromised account can become a much larger incident.

Zero trust assumes the network is already compromised. That's not pessimism – it's an accurate basis for design. Build controls that limit the damage any single compromised credential or device can do, rather than building everything around keeping attackers out of the perimeter entirely.

The three starting points for a UK SME

Zero trust as a complete architecture involves identity, devices, networks, applications and data. That's a significant undertaking. The practical approach for an SME is to start with the controls that reduce the most risk for the least complexity.

MFA everywhere. Multi-factor authentication is the single most effective identity control available. It means that even if an attacker has a user's password – through phishing, credential stuffing or a data breach – they still can't authenticate without the second factor. MFA across all accounts – not just cloud services, not just admin accounts, but all accounts – is the foundation zero trust is built on. If you've not yet deployed MFA universally, that's where to start. Everything else is secondary.

Device trust. Verifying identity isn't sufficient on its own if the device doing the authenticating is unmanaged, unpatched or running outdated software. Device trust means only allowing known, managed devices to access corporate resources. Microsoft Intune combined with Entra ID (formerly Azure Active Directory) is the standard toolset for Microsoft 365 environments: it lets you enforce device compliance policies as a condition of access, so a device that isn't enrolled, patched or configured correctly is blocked before it reaches your data. This is more involved to set up than MFA, but it closes a significant gap – particularly for teams that use a mix of company and personal devices.

Least-privilege access. Users should only have access to the systems and data they actually need for their work. In practice, many organisations accumulate permissions over time: someone is granted access to a shared drive for a project, the project ends, the access stays. Admin rights are handed out because it's easier than configuring something more granular. Least-privilege means reviewing what access exists, removing what isn't needed, and making the default answer to access requests "no, unless there's a clear reason." It's unglamorous work, but excessive permissions are consistently one of the most exploited weaknesses in an incident.

Microsoft 365 and zero trust: what Entra ID enables

For most UK SMEs, the Microsoft 365 stack is the practical environment in which zero trust gets implemented – and it has capable tooling for it. Entra ID's Conditional Access policies are the most direct implementation available: they let you define the conditions under which access is granted, and block or step up authentication when those conditions aren't met.

A Conditional Access policy can enforce that a user must be on a compliant, Intune-managed device to access SharePoint. It can require MFA for any sign-in from outside your usual locations. It can apply risk-based authentication – prompting for additional verification when Microsoft's identity protection signals detect unusual behaviour, like a sign-in from an unfamiliar location or a known compromised IP range.

None of this requires a separate zero trust platform. If your business runs on Microsoft 365 Business Premium, you have Intune, Entra ID P1 and Defender for Business included. The tools are already licensed. The work is in configuring them correctly – which is more nuanced than it sounds, because poorly configured Conditional Access policies can lock users out or create gaps that defeat the purpose – but the capability is there.

How zero trust connects to Cyber Essentials compliance

Cyber Essentials is the UK government's baseline cybersecurity certification, and several of its requirements directly express zero trust principles – even if the scheme doesn't use that language.

The v3.3 update introduced mandatory MFA for accounts accessing cloud services and remote access. The upcoming 2026 Danzell update extends that to all user accounts. That's zero trust's identity verification principle, applied as a compliance requirement. Device scoping – requiring that devices accessing in-scope systems meet defined configuration standards – aligns with device trust. User access control, one of the five Cyber Essentials technical controls, maps directly to least-privilege.

The NCSC's own guidance makes the connection explicit. Their "10 Steps to Cyber Security" framework and their dedicated zero trust architecture guidance both point in the same direction: verify identity, enforce device health, limit lateral movement and restrict access to what's needed.

If you're working towards Cyber Essentials certification – whether because a contract requires it or because you want the baseline assurance – implementing zero trust controls isn't a parallel track. It's the same work. MFA, device management and access reviews are both good security practice and certification requirements.

Where to start without starting over

The most common barrier we encounter isn't technical – it's the belief that zero trust requires a full infrastructure rebuild before anything useful can happen. It doesn't. Incremental progress is real progress.

Start with identity. Get MFA deployed across every account – all users, all services. Use an authenticator app rather than SMS where possible. That single change removes the majority of credential-based attack risk.

Then tackle devices. Enrol managed devices into Intune. Set a baseline compliance policy – OS up to date, disk encryption enabled, endpoint protection active – and use Conditional Access to enforce it. You don't need to solve personal devices on day one; start with company-owned hardware and address BYOD once the foundation is in place.

Then review access. Export your user list and the permissions attached to each account. Remove anything that isn't actively needed. Review admin rights in particular – admin accounts should be separate from day-to-day accounts, and the number of people holding admin rights should be as small as possible.

Network segmentation – separating systems so that a compromised device can't reach everything else on the network – comes later, and requires more infrastructure work. But by the time you've covered identity, devices and access, you've addressed the controls that matter most in the majority of real-world incidents.