Zero trust architecture

Teams move to zero trust because the network perimeter stopped meaning anything. Staff work from anywhere, applications run in several clouds and one phished password on the “trusted” network reaches everything. Zero trust moves the checkpoint to the front of every resource.

What are the principles of zero trust?

• Verify explicitly. Every request is authenticated and authorized using everything available: identity, device health, location, time and the resource’s sensitivity.
• Least privilege. Access is granted to one resource for one task, scoped as narrowly as possible and for as short a time as possible.
• Assume breach. Design as if the network is already hostile. Segment so a compromise stays small, encrypt internal traffic and log everything.
• Never trust the network. Being inside the office, the VPN or the VPC earns nothing. A request from a desk is treated like one from a cafe.
• Continuous evaluation. A decision at login is not a decision for the day. Policy is re-evaluated during the session, and access is withdrawn when the signals change.

What are the components of a zero trust architecture?

NIST SP 800-207 describes the architecture in terms of a few logical components. In plain language:

• Subject and device. The user, service or device making the request, which must prove who it is and what state it is in.
• Policy enforcement point. The gate in front of each resource that lets a request through or blocks it. In practice an identity-aware proxy, an API gateway, a service mesh sidecar or an agent on the host.
• Policy decision point. The brain, split into a policy engine that decides and a policy administrator that tells the enforcement point what to do. The engine applies rules to the signals it has.
• Policy information sources. Everything the engine consults: the identity provider, the device management system, threat intelligence, activity logs and the data classification of the resource.
• Resource. The application, API, database or file being protected. Each has its own enforcement, so reaching one grants nothing toward the next.

The diagram at the top of this page folds decision and enforcement into one region to keep it readable. In a real deployment the three checks are separate services the enforcement point calls.

How do you read a zero trust architecture diagram?

Follow the request from left to right. A user on a device asks for something. Before any resource sees the request, three checks run: identity is verified through single sign-on with MFA, the device is checked for management, encryption and patch level, and the policy engine evaluates the user’s role, the risk signals and the resource being asked for.

The result is not one answer. The same request is allowed for the HR app and the code repository and denied for the customer database, because that resource’s policy requires a role the user lacks. The note under the checks is the heart of the model: this happens for every request, not once a day.

Compare the inset. In the perimeter model the user logs in once at the VPN or firewall, and once inside the trusted network, every resource is reachable. One stolen credential or one compromised laptop gets the whole estate.

How do you adopt zero trust in stages?

Nobody switches an organization to zero trust in a quarter. A workable order:

1. Inventory identities and resources. List who needs what, and draw the current state as an architecture diagram with a data flow diagram for sensitive data. Most teams find services calling each other with shared passwords nobody knew about.
2. Strengthen identity. Put every application behind one identity provider with MFA, and give services their own identities instead of shared secrets.
3. Add device signals. Enroll laptops and phones in device management and feed their health into the identity provider’s policy.
4. Put one application behind a policy enforcement point. Pick a web app, place an identity-aware proxy in front of it and let users reach it without the VPN.
5. Segment the network. Replace the flat internal network with small segments and explicit allow rules, drawn on a network diagram so the paths are known.
6. Extend to service-to-service traffic. Mutual TLS or a service mesh, so services verify each other the way users are verified.
7. Retire the implicit paths. Shrink the VPN to the legacy systems that still need it, then migrate those.

What are common zero trust misconceptions?

• “Zero trust is a product.” It is an architecture. Any single product covers one component of it.
• “It means MFA everywhere.” MFA is one signal. Without device posture and per-resource policy, it is strong authentication, not zero trust.
• “It replaces the network perimeter entirely.” Firewalls and segmentation stay. They become one layer of defense in depth instead of the only one.
• “Once it is done, it is done.” Policies, device signals and resource classifications keep changing. Zero trust is an operating model as much as a design.

How does zero trust compare with related approaches?

Approach	Trust is based on	Granularity	Decision made
Network perimeter	Being on the network	Whole network	Once, at the edge
VPN	Login at the VPN gateway	Network segment	Once, per session
Zero trust architecture	Identity, device and context per request	One resource	Every request
Cloud security architecture	Layered controls in an account	Account and workload	Designed up front, enforced continuously

Zero trust is the access model; cloud security architecture is the wider set of controls it sits inside, and threat modeling is how you find the implicit trust that zero trust removes.

What tools help with zero trust architecture?

• Identity providers and device management. The sources of the two strongest signals, user identity with MFA and device health, and where most policy is written.
• Identity-aware proxies, API gateways and service meshes. The enforcement points, which sit in front of web apps, APIs and service-to-service calls and ask the policy engine before passing a request.
• AI diagramming tools. Tools like Eraser turn a description of your users, enforcement points and resources into an architecture diagram you can keep editing, the fastest way to show where implicit trust remains.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions