Zero trust means proving every access. Here's how to start, and what to do if someone's already in.

Every vendor deck says zero trustdefinitionA security model where nothing is trusted just because of where it sits. Every request gets checked against current evidence about the user, the device and the context., but very few deployments can answer the question that matters: for this access, right now, what's your evidence? No product answers that for you. Clean up who has access first, then switch the checks on one at a time.

In a network that trusts anyone already inside, one stolen password can be enough. Someone phishes a member of staff, signs in over the VPN, and can then reach file shares, old admin accounts and finance systems nobody thought to lock down. How bad it gets depends on what that one login could reach. In a flat network, that's often a lot.

The second cost comes round every year. If your controls don't record why access was granted, audit prep turns into weeks of screenshots and spreadsheets someone pulls together by hand. Auditors write findings when nobody can explain why a person has the access they have, and those findings land on the owner's desk.

NIST's zero trust guide, SP 800-207, sets the rule out plainly. No account or device gets trust just because of where it sits on the network, and each session is checked for who and which device before it starts. Vendors sell tools that do parts of that checking. The evidence about your own users still has to come from you.

For engineers, here's where each check sits. Device posturedefinitionWhether the laptop or phone asking for access is in good shape. A policy might refuse one that IT doesn't manage, or that's behind on patches or has encryption off. would flag an unmanaged laptop at step 2. Automated leaver processes and access certification take away the orphaned accountsdefinitionAn account with nobody active behind it. Usually it's a former employee's or contractor's login that nobody switched off, and it still works. step 3 relies on. Conditional accessdefinitionThe rules your sign-in follows. A login from a managed laptop in the office might go straight through, while the same login from an unknown phone abroad gets asked for more proof or blocked. on the finance app adds a fresh check at step 4, and policy logs answer the question at step 5.

We named the company after the code hash. Careful engineers check a downloaded file's hash before they run it, and if the hash can't be checked, they don't trust the file. We treat every access request the way we'd treat that file, which gives us three rules.

Rule 1: identity is the perimeter, so govern it like one. Most zero-trust programs stall because nobody trusts the identity data. Old accounts nobody switched off and access that's piled up for years are usually why, along with roles nobody can explain. Conditional access policies mean little until provisioning and certification are automated and auditable. Do that groundwork first. The security payoff comes after it.

Rule 2: every access decision needs a signal, and every signal needs a source. Adaptive access only knows what you feed it. A sensible order is device posture first and behavioral baselines second. Network context can wait until both are working. Wire each one in on its own. Run monitor modedefinitionRunning a new policy so it records what it would have blocked without actually blocking anything, before switching it to enforce. first and enforce second, and treat each policy like a deploy you can roll back.

# every access policy ships like software
policy: finance-prod-access
version: v14 // reversible
mode: monitor → enforce
signals: [device, behavior, network]
✓ tested · ✓ versioned · ✓ evidence-emitting

Rule 3: evidence should be a byproduct of the controls. If audit prep is an event on the calendar, the architecture is wrong. The controls that enforce access should produce their own proof as they run, in session records, certification trails and policy logs. Then the audit is just a report someone generates.

The attack above worked because one login could reach everything and nobody could show why. The fixes below each take away one of those steps. We'd do them in this order, since each one depends on the data the one before it cleaned up.

We start with the identity data, because that's where most programs stall. An identity and access management assessment maps who has access to what, finds the accounts nobody owns and ends in a ranked, costed roadmap. Our zero trust page covers how we roll policies out after that, and the SailPoint page covers the governance platform. If you'd rather start small, book an assessment.