Zero Trust · NIST SP 800-207
For years, being inside the network was treated as proof you belonged. It never really was. Zero Trust drops that assumption: every request is checked on who is asking, what they are reaching for, and whether it still adds up, wherever it comes from. The slogan is the easy part. Turning it into an architecture your engineers can build and your auditors recognise, on NIST SP 800-207, is the work, and we do it from the first assessment to the running service.
The shift
The old approach was simple: build a strong boundary, then trust whatever sits behind it. Then the work moved to the cloud, the staff moved home, and half your suppliers got a login. There is no clean boundary left, and anyone who gets a foot inside tends to have the run of the place. Zero Trust drops the assumption. Nothing is trusted for being in the right spot, and access is decided one request at a time, on identity, device, and what is actually going on.
The perimeter model
Zero Trust
How the work runs
Nobody finishes Zero Trust. You get it to a good place and then keep it there. We work in four stages, and each one ends on a decision that stays yours: carry on with us, take it in-house, or stop where you are.
We score you against the CISA maturity model and go looking for the soft spots: the flat networks, the admin accounts no one has reviewed in years, the laptops that never check in. You get a straight read on where you stand and a ranked list of what to fix first.
We design the architecture you are going to live with: where access decisions get made and enforced, how people and machine identities are handled, where the network gets segmented, and a route there from where you are now that does not break everything on the way.
Then we build it: multi-factor and conditional access, device checks, segmentation, and the controls on your apps and data, all wired into the points that enforce the decision. And we test it, so done means it works, not that a ticket was closed.
Access rules go stale. People switch roles, new systems appear, and exceptions quietly pile up. We keep the policy current, check that enforcement is still holding, and re-test on a schedule, so the whole thing does not drift back to trusting by default.
What it covers
Zero Trust is not a switch you flip. It stands on five pillars, each one maturing from traditional to optimal, with three capabilities holding the whole thing up underneath. That is the structure the CISA Zero Trust Maturity Model uses. The usual mistake is to run them as separate projects, with separate owners and tools that never quite meet. We design them as one control set, so they line up, and so the same work counts towards ISO 27001, SOC 2, and the Essential Eight.
Prove who, or what, is asking, every single time. Least privilege, strong authentication, and no shared logins.
Check the device before it gets in, whether you own it or a contractor does.
Segment the network, so one compromised machine cannot reach everything else.
Authorise each request to an app, and give services their own identities instead of a shared key everyone copies.
Know what is sensitive, encrypt it, and gate access by how sensitive it is, wherever it ends up.
The foundation underneath
Architecture-led
You can spend a fortune on products with Zero Trust on the box and still not have it. What ties it together is the design: one clear set of rules for who reaches what, mapped to the standards you report against. Get that right and the tools just do their job. Get it wrong and you have bought expensive shelfware.
Maybe you want the honest assessment first. Maybe the design is done and you just need it built. Tell us where you have got to, and we will scope it in writing before anyone starts work.