Zero Trust Access Diagram
How a single request gets authorised when the network is not the boundary — the identity, device and policy checks in order, the signals each one uses, and what happens after access is granted.
SVG. No sign-up, no email.
"Zero trust" is a badly named idea with a simple meaning: being on the network proves nothing. Every request is authorised on its own merits, using what is known about the identity, the device and the resource at that moment. The diagram below is that decision, drawn as it actually happens.
The order matters#
Identity first. Not a shared account, not an IP range — a person or a service with credentials that cannot be replayed. Phishing-resistant MFA is the meaningful step here; codes over SMS are better than nothing and are defeated routinely.
Device posture second, and this is the first shaded box because it is where most implementations stop short. A valid credential on a compromised laptop is a compromised session. The check does not need to be elaborate: is the device managed, encrypted, and patched within policy? Answering that for every request is what distinguishes zero trust from an MFA rollout.
Policy decision third — the second shaded box. This is where who meets what: this identity, on this device, in this context, asking for this resource. The failure mode here is a policy that only understands the identity. Access to a customer database and access to the lunch menu are not the same decision, and a system that cannot tell them apart is not making one.
Then access is granted — least privilege, and time-boxed. Standing access to everything is what turns one phished account into an incident that takes a week to describe.
The signals#
Drawn as a set rather than a sequence, because they are evaluated together. Each one is cheap on its own; the value is in combining them. An authenticated user, on a managed device, at a normal hour, requesting an ordinary resource is a low-risk request. Change any two of those and it is not, and a policy that only reads the first signal cannot see the difference.
After access is where the value is realised#
Granting access correctly is half of it. The bottom lane is what turns a good decision into a system that can recover from a bad one.
Log the access — who, what, when — because an incident is reconstructed from these records or it is not reconstructed at all.
Detect anomalies against a baseline of normal. Not clever behavioural analytics: a service account that has never read this data reading all of it is the shape of alert that actually matters.
Revoke fast, and revoke the session. Resetting a password while an active session token keeps working is one of the most common gaps between "we responded" and "we stopped it".
Review privilege on a schedule with the people who own the data. Access accumulates silently — through role changes, projects that ended, and access granted for one afternoon three years ago.
Using this diagram#
Trace one real request through it — a contractor opening a customer record from an unmanaged laptop, say. Most organisations find they stop after identity, and that everything past that box is answered by "they are on the VPN". That is precisely the assumption this model exists to remove.