Zero Trust

Zero Trust Without the Hype: What Actually Changes

"Zero Trust" now appears on the marketing page of almost every security product, including several that are simply firewalls with a new colour scheme. That is a shame, because the idea underneath is genuinely useful and fairly simple to state.

The actual idea, in one sentence

Stop granting trust based on network location, and start granting it per request, based on who is asking and what they are asking from.

That is the whole concept. Everything else — the product categories, the maturity models, the reference architectures — is implementation detail layered on top of that single change.

It matters because the assumption it replaces is now demonstrably false. The traditional model held that inside the network meant trusted, and it worked acceptably when "inside" meant a building you controlled. Once staff work from home, workloads run in someone else's datacentre, and half your business processes traverse SaaS platforms, "inside the network" describes almost nothing useful about whether a request should be permitted.

What changes for your users

Less than most people expect, and often for the better.

The visible change is usually that the VPN goes away. Instead of connecting to a network and then reaching applications, users go directly to applications and are authorised per application. For anyone who has waited for a VPN client to reconnect on hotel wifi, this reads as an improvement rather than a security imposition.

Single sign-on consolidates a scattering of passwords into one strong authentication event. Done properly, the number of credential prompts a person sees per day goes down, not up. That matters for adoption: security changes that make daily work harder get routed around, regardless of policy.

The genuine friction is device posture. If access requires an encrypted, patched, managed device, then people using a personal laptop for convenience will be blocked. That is the point, but it needs to be communicated as a deliberate decision well before enforcement day, not discovered by a sales director on a Monday morning.

What changes for your network

The network stops being a security control and becomes plumbing — which is a demotion, and a healthy one.

In a Zero Trust model, being on a particular segment grants you nothing. Every request to every application is authenticated and authorised regardless of source. Segmentation still has value for containment and for limiting blast radius, but it is no longer the primary mechanism deciding who reaches what.

In practice this makes several long-standing headaches disappear. Contractor access no longer requires a network segment and a firewall change; it requires an identity, a device check, and an authorisation rule scoped to the two applications they need. Acquisitions no longer require merging address spaces before anyone can work.

The sequence that works

Zero Trust fails when treated as a single programme with a completion date. It works when treated as a sequence, each step useful on its own:

  • Consolidate identity. One authoritative provider, single sign-on everywhere it is supported. Nothing else works properly until this is true, and it has immediate value: offboarding becomes one action instead of a checklist.
  • Deploy phishing-resistant MFA. Hardware keys or platform authenticators. SMS and push-approval are meaningfully weaker against the phishing kits currently in circulation, which relay codes in real time.
  • Add conditional access. Policies that weigh device posture, location, and risk signals per request. Start in report-only mode, watch what would have been blocked for a fortnight, then enforce.
  • Eliminate standing privilege. Administrative rights become just-in-time and time-boxed. This is the step with the largest reduction in blast radius, because it removes the accounts attackers most want.
  • Replace network access with application access. Only now does the VPN come out, once identity and device trust are solid enough to carry the weight.

Attempting step five first is the most common failure we are called in to unpick. Without strong identity underneath, application-level access just relocates the same weak authentication to a new front door.

What it costs

Less than the product marketing implies, if you already pay for a major productivity suite. Much of what is needed — identity provider, MFA, conditional access, often device management — is included in licence tiers most organizations already hold and have never fully enabled.

The real cost is engineering time: rolling out authentication changes carefully, handling the legacy applications that cannot speak modern protocols, and communicating clearly enough that enforcement day is uneventful. Budget for the rollout, not for a pile of new licences.

Before you buy anything Audit what your existing licences already include. In most assessments we run, at least two of the five steps above can be completed with entitlements the organization is already paying for.

How to tell if it is working

Ignore maturity scores. Ask three questions instead. Can a stolen password alone get anyone anywhere useful? When someone leaves, how long until their access is genuinely gone everywhere? If a laptop is compromised tonight, what can the attacker reach from it without further authentication?

If those three answers are good, you have the benefit of Zero Trust regardless of what your architecture diagram is called. If they are not, no amount of product adoption will fix it.

We walk clients through exactly this sequence in our Zero Trust and identity work — starting with what you already own rather than what we could sell you.

All insights
Work With Us

Find Out What's Exposed Before Someone Else Does

Start with an assessment of your cloud environment. You get a prioritised findings report and a remediation plan you can act on — with us or without us.

[email protected]