Zero Trust is a set of decisions.

Zero Trust becomes useful when it can answer a practical question: should this person, on this device, be able to perform this action on this resource, under these conditions?

That question gives architecture a starting point. It names the decision before naming the products. It also exposes the information the decision depends on: identity, device state, the sensitivity of the resource, and the context of the request.

Describe the decision

Start with one meaningful access path. Write down who is using it, what they need to do, and what would make the request unacceptable. Keep the description concrete enough that an engineer and a service owner can discuss the same thing.

A sentence such as “administrative access requires stronger verification and a managed device” can be examined. The team can ask how verification happens, how device state is known, and what to do when that information is unavailable. Each answer turns a broad principle into an architectural choice.

Connect the signals

Identity, endpoint protection and monitoring provide different pieces of evidence. The architecture needs to explain how those pieces inform access and what happens when they disagree. A successful sign-in alone says little about whether a particular action should be allowed.

Keep the lifetime of the decision visible too. A session may outlast the conditions under which it was approved. Decide which changes should trigger another check and how access can be withdrawn. These are operational questions as much as technical ones.

Design the exception

Exceptions deserve a place in the design. A device may be unavailable, a service may fail, or an urgent recovery action may be necessary. Define who can authorise an exception, how it expires, and what evidence remains afterwards.

A clear exception path helps people act deliberately under pressure. It also gives the organisation something it can review and improve, instead of leaving recovery to an undocumented workaround.

Keep it understandable

The useful test is whether the people operating the system can explain why access was granted and how that answer could change. Products support the decision. The architecture connects the signals, responsibilities and actions into something the organisation can maintain.