Zero Trust is not a SKU.

A product can enforce access decisions. It cannot decide which resources your organisation should trust, who should reach them or what evidence should change that decision. Calling a renewal a Zero Trust programme does not make those questions disappear.

Zero Trust is an architectural discipline. Buying tools may be part of the work. It is not the acceptance test.

The resource matters more than the network label.

NIST SP 800-207 describes an approach centred on users, assets and resources. It rejects implicit trust based solely on network location or asset ownership, and treats authentication and authorization as decisions made before access to a resource is established. Read Zero Trust Architecture.

That has practical consequences. An internal address is not an authorization rule. A managed laptop is not permission to reach every service. Authenticating to a VPN is not equivalent to authorizing access to payroll, source code and production administration.

Start with a resource and a legitimate workflow. Identify the subject, device, requested action and relevant context. Then decide where policy is evaluated, where it is enforced and what happens when the evidence changes.

“Implemented” is not an outcome measurement.

Gartner's April 2024 release reported that 63% of organisations had fully or partially implemented a Zero Trust strategy. It described a fourth-quarter 2023 survey of 303 security leaders from organisations that had implemented or planned to implement one. The same release emphasised the need to define scope and warned against treating Zero Trust as coverage for the entire environment. Read the survey context.

This is an adoption survey, not a controlled measurement of security effectiveness. “Partially implemented” can cover very different scopes. A board report should say which workflows changed, which resources remain outside the programme, and what testing established.

The enforcement device is still software.

An access gateway does not become exempt from patching, restricted administration or monitoring because it enforces policy. Its management plane, integrations and privileges are part of the architecture you must evaluate.

CISA's official Known Exploited Vulnerabilities data is one source for checking whether deployed products and versions require attention. A catalogue entry is evidence about a particular vulnerability; it is not a verdict on every product from a vendor, nor a complete list of exploitable weaknesses.

Turn the programme into testable changes.

• Reduce standing privilege. Define which administrative actions need approval, time limits and a record of use.
• Protect high-value authentication. Evaluate phishing-resistant methods for administrators and sensitive workflows, including recovery paths.
• Constrain management access. Verify who can reach administrative interfaces and what privileges each integration receives.
• Test resource boundaries. Use an authorised test to check that an unrelated user, device or workload cannot reach a protected resource merely because it is on the same network.
• Exercise policy changes. Confirm that revoked access and changed device state affect real sessions as designed.

Record the expected decision, the observed decision and the evidence. Keep exceptions visible, with an owner and a reason. These are assessment questions we recommend; they are not claims about a particular customer's environment.

You cannot buy the principle. You can buy useful components, build the architecture around them and test whether it behaves as intended.