Home / Knowledge hub / Zero trust
Knowledge hub
Zero trust
Assuming the network proves nothing, and checking every request.
What it means
Zero trust means designing on the assumption that sitting inside the network proves nothing. Each service authenticates and authorises every request on its own merits, whoever sent it and wherever it came from.
The older model was a hard shell around a soft interior. Get past the perimeter and everything inside cooperates. Remote work and cloud services left that shell with very little to enclose.
Why it matters
It is why one foothold should not reach everything else. When each service asks who is calling and what they may do, a stolen laptop or a compromised container stays a contained problem.
For the business it is mostly a spending argument: less on the perimeter, more on identity, permissions and logging. It is a direction rather than a product, whatever a vendor tells you. NIST describes it as an architecture, and the NCSC writes it up as design principles rather than a purchase. Expect years rather than a quarter, with the identity work as the slow part.
How it shows up
In application terms, zero trust is the argument for checking permissions at every route rather than once at the front door. An internal service that trusts any caller able to reach it is exactly the assumption zero trust removes.
Hunt the leftovers. An admin API reachable from the office network with no login. A service-to-service call carrying no identity. A database that trusts anything inside the private network. Start with the highest value path rather than the whole estate. One sensitive service verifying every caller properly beats a partial rollout everywhere.
Questions people ask
Zero trust, answered
Is zero trust just a marketing term?
The marketing is heavy, the underlying idea is not. Stripped of the sales material it says one thing: stop treating network position as proof of identity.
That is a real design change with real consequences, whatever the brochures have done to the phrase.
Can we buy zero trust?
No. You can buy products that help, such as identity providers, policy engines and proxies. None of them makes your application check permissions on each request.
The work is mostly ordinary: identities for services, permissions written down, and checks that run every single time.
What does zero trust mean for an application rather than a network?
It means every route verifies who is calling and what they may do, instead of one gate at the entrance deciding for everything behind it.
In practice that is short-lived credentials, an identity attached to service-to-service calls, and authorisation checked per request and per resource.
Do we have to get rid of our VPN?
Not immediately, and framing it that way usually stalls the project. The change is that being on the VPN stops being sufficient proof on its own.
Keep it as one signal while services learn to verify callers themselves, then decide later whether it still earns its keep.
Where do we start without redoing everything?
Pick the one service whose compromise would hurt most and make it verify every caller properly, including internal ones.
A single path done thoroughly teaches you more, and protects more, than a shallow rollout across the estate.
Sources
Where this comes from
Related
Terms that sit next to this one
Least privilege
Giving every person and service the minimum access the job requires.
Authorization
Deciding what a proven user is then allowed to do.
Access control
The rules deciding which person can see or do which thing in your app.
MFA
A second proof beyond the password, usually a code or a hardware key.
Need to know
Limiting information to the people whose work actually requires it.
Checked once or checked every route?
Authorisation is one of the ten classes Cyberlop tests: one account per role, every route, every resource. Ask to see the matrix for one of your own applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.