Zero trust is not a product you can buy. NIST SP 800-207 describes it as moving defences away from static network perimeters and towards users, assets and resources. In practice, being on the office network or the VPN should stop counting as evidence that a request is legitimate. Each access decision gets made on who is asking, from what device, for which resource.

That idea is sound. The trouble starts when it becomes a procurement category. Our view is that the order of the work matters more than the choice of vendor, and that most organisations should do the following four things in this order.

1. Identity first

Every later control depends on knowing who is making the request, so a weak identity layer undermines everything built on it.

  • Put every workforce application you can behind one identity provider, and keep a list of the ones you can't.
  • Require phishing-resistant MFA, such as passkeys or FIDO2 security keys, for administrators first and then everyone else. Codes sent by SMS can be intercepted or talked out of people.
  • Turn off legacy authentication protocols that bypass MFA.
  • Give administrators separate privileged accounts, and grant elevated rights for a limited time where your platform supports it.
  • Review service accounts and API keys. They often hold broad rights, never expire and belong to nobody.

2. Device posture

A valid login from a compromised laptop is still a compromise. Once identity is under control, make the device part of the decision. Start with a small set of checks you can actually enforce: the device is managed, its disk is encrypted, its operating system is within a supported patch level, and endpoint protection is running.

Run the policy in report-only mode first. You will find contractors, personal phones and forgotten kiosks, and it is better to find them in a report than through a flood of support calls. Decide what unmanaged devices may reach, because "nothing" is rarely the honest answer. A browser-only path to low-risk applications is often a workable compromise.

3. Segmentation where it counts

Network segmentation is where zero trust programmes tend to stall, usually because someone tries to map every flow in the company before enforcing anything. Start with what would hurt most instead.

  • Pick one to three critical systems, such as the finance database, the identity provider or the backup platform.
  • Record which systems legitimately talk to them, watching real traffic for a few weeks.
  • Block everything else, and require administrative access to pass through a controlled path.
  • Stop ordinary workstations from talking directly to each other. Few businesses need it, and attackers use it to move sideways.

4. Logging you can use

Each access decision should leave a record: who, which device, what resource, allowed or denied, and which policy decided. Send identity, endpoint and network logs somewhere an attacker with administrator rights on a single system can't alter them, and keep them long enough to investigate an intrusion you discover weeks after it began.

Then test them. If nobody can answer "what did this account access last Tuesday?" within a few minutes, you have storage rather than logging.

What the slogan hides

  • Exceptions accumulate. Every legacy application that can't do modern authentication becomes a permanent carve-out unless each exception has an owner and an expiry date.
  • Your identity provider becomes a critical dependency. If it goes down or is misconfigured, nobody works. Keep tested break-glass accounts, stored securely and monitored for any use.
  • Policies need owners. Someone has to approve access rules and maintain them as teams change. That is an ongoing operating cost, not a project that ends.
  • Users notice. Badly tuned prompts teach people to approve anything. Fewer, better-placed checks serve you better than constant friction.

Don't expect to reach a finished state. Treat the goal as a steady reduction in how far one stolen credential can get an attacker.

What to do this week

  1. List every account with administrator rights, and check how each one authenticates.
  2. Find out which applications sit outside your identity provider.
  3. Check whether legacy authentication is still enabled, and see who is using it.
  4. Choose the one system you would least like an attacker to reach, then write down what can connect to it today.
  5. Ask for the access log of one named account over the last 30 days, and time how long it takes to arrive.

The answers will give you a more honest plan than any maturity assessment.