You have a zero trust strategy. The hard part is that "never trust, always verify" has to be enforced by real tools across identity, devices, the network, and the applications themselves, and no single product does all of it. The market is crowded, every vendor now calls itself zero trust, and the categories blur together.
Zero trust rests on one idea, verify every request explicitly and grant only the access it needs, every time, not once at login. NIST's zero trust architecture builds that around a policy decision point that checks each request against policy and a policy enforcement point that carries the decision out. Most tools cover the parts of that model closest to the perimeter, the identity and the network. The part that decides, per request, whether an authenticated principal may take a specific action on a specific resource is the one most stacks leave hardcoded inside each application, outside the security team's view.
Source: NIST's zero trust architecture
This guide breaks a zero trust stack into the layers you actually have to buy for, names the notable tools in each and what they do, and shows which layer most programs under-invest in.
What zero trust actually asks of your stack
Zero trust replaces three assumptions the old perimeter model was built on.
The network is not a trust boundary. Being inside the VPN or on the corporate network no longer means an identity can be trusted, so access has to be earned per request rather than granted by location. That is the shift from implicit trust to continuous verification.
Authentication is the start, not the end. Proving who you are gets you a session. It does not decide what you are allowed to do with it, and a valid session carrying broad standing access is exactly how a single stolen credential turns into a breach. Least privilege has to be enforced on the action, not just at the door.
Not every identity is human. Service accounts, workloads, and now AI agents authenticate and act on their own, usually with broad tokens and no clear owner. Zero trust that only covers people leaves a large and growing set of identities ungoverned, so governing non-human identities is now part of the same problem.
Most zero trust spending goes to the new perimeter, the identity provider and the network access layer. That work matters. But the tenet that every request is verified and least-privileged only holds if something checks each action against policy at the moment it happens. That is the authorization layer, and it is the one most often left inside application code. Keep it in mind as you read the categories below.
The layers of a zero trust stack
1. Identity and access management
This is the front door, and for most teams it is where zero trust starts. IAM platforms handle single sign-on, multi-factor authentication, and conditional access that weighs signals like device and location before granting a session. They establish who an identity is and how strongly it has to prove that, which is the necessary first step. It is not the same as deciding what that identity may then do.
Okta anchors a lot of enterprise zero trust programs through its Workforce Identity Cloud, with phishing-resistant adaptive MFA, a universal directory that consolidates identities, and thousands of pre-built app integrations that keep least-privilege provisioning and deprovisioning manageable.
Microsoft Entra ID is the default where the estate already runs on Microsoft, with conditional access that weighs user, device health, location, and risk before granting a session, and Entra Private Access extending that same model to per-application network access.
Ping Identity is common in large hybrid enterprises with heavy on-prem and federation requirements, with adaptive authentication that adjusts to device, location, and risk, SSO across cloud and legacy applications, and a no-code orchestration engine for building custom sign-on flows.
For smaller teams consolidating tools, JumpCloud combines identity, MFA, and device management in a single console across Windows, macOS, and Linux, with conditional access tied to device compliance.
2. Privileged access management
Privileged accounts, the admin logins, service accounts, and infrastructure credentials, are the ones an attacker wants most, so they get their own layer. PAM tools vault and rotate those credentials, broker just-in-time access, and record privileged sessions so standing access is minimized and every use is accountable. PAM shrinks the blast radius for the most dangerous accounts, but it governs access to systems, not the fine-grained actions an identity takes inside an application.
CyberArk, now part of Palo Alto Networks, is the enterprise standard here, with credential vaulting, isolated and recorded privileged sessions, just-in-time elevation, and secrets management that extends to machines and CI/CD pipelines.
BeyondTrust pairs privileged remote access with endpoint privilege management, removing standing local admin rights and brokering elevation only when a task needs it.
Keeper Security takes a lighter-weight, zero-knowledge approach, with KeeperPAM adding session recording, browser isolation, and automated rotation of API keys and database credentials, which fits teams that want PAM without a heavy deployment.
3. Network access, ZTNA and SASE
Zero trust network access replaces the flat VPN with identity-and-device-aware access to specific applications, so a user reaches only the resources they are cleared for and everything else stays invisible. This has largely folded into secure access service edge and security service edge platforms that bundle network access with web and data controls. This layer decides what an identity can reach on the network. It does not decide what that identity can do once it is inside the app.
Zscaler runs one of the largest security clouds, with its Zero Trust Exchange and ZPA connecting users straight to applications without exposing the network, plus inline inspection of encrypted traffic.
Palo Alto Prisma Access delivers SASE that combines ZTNA, a secure web gateway, and CASB with Palo Alto's threat prevention.
Cloudflare provides ZTNA, DNS filtering, and a secure web gateway on its global edge, with agent or agentless options.
Netskope is strong on inline data protection and SaaS visibility, and Cato Networks delivers single-vendor SASE over its own private backbone.
For teams that want lightweight ZTNA without re-architecting, Twingate offers per-application access managed as infrastructure-as-code with device posture checks, and Appgate applies a software-defined perimeter that opens one-to-one encrypted connections per session.
Alongside these, microsegmentation tools like Illumio and Akamai Guardicore map application dependencies and control east-west traffic between workloads, so a foothold in one service does not become free movement across the data center.
4. Device trust and endpoint security
A zero trust decision is only as good as the signal about the device making the request, so endpoint tooling feeds device posture into access decisions and detects compromise on the machine itself. Device posture is one of the strongest contextual signals an access decision can use, which is why this layer and the authorization layer work best when they are connected.
CrowdStrike Falcon runs a single lightweight agent for antivirus, EDR, and threat intelligence, and increasingly ties endpoint telemetry to identity signals so risky devices can be factored into access decisions.
SentinelOne takes a behavioral approach with automated response and one-click rollback of a compromised endpoint.
Microsoft Defender for Endpoint is the natural fit inside a Microsoft environment, since its device risk score feeds directly into Entra conditional access, so a device that falls out of compliance loses access without a separate integration.
Cisco Duo also sits at this boundary, adding device health checks to its MFA before a session is granted.
5. Authorization and policy enforcement, the decision layer
This is the layer that decides, at the moment an authenticated identity tries to act, whether it is allowed to. In NIST's model it is the policy decision point and policy enforcement point, and it is the most direct expression of verify explicitly and least privilege on every request. It is also the layer most zero trust programs leave hardcoded inside each service, where the security team cannot see or govern it.
Cerbos sits here, as a policy-based authorization layer that runs as its own component rather than living in application code. Cerbos co-founder and CPO Alex Olivier co-chairs the OpenID AuthZEN working group that is standardizing fine-grained authorization, and the engine already evaluates more than 2 billion authorization checks a month across the companies that use it.
A few things make this layer the core of zero trust rather than an add-on:
- The check runs on every request, evaluating the principal, the action, the resource, and context like device posture, tenant, or time, so access is earned per action rather than granted once at login.
- The rules live as policy as code that is versioned, tested, and reviewable, which moves authorization out of scattered application logic and into something the security team can actually see and govern, sometimes called shift down.
- The same policy engine covers non-human identities, service accounts, workloads, and AI agents, alongside human users, so you are not standing up a separate system for each.
- And every decision is logged with the reason it was allowed or denied, which is the evidence a zero trust assessment and an auditor ask for. Cerbos runs stateless next to your services, so this per-request check does not become the bottleneck.
6. Data security and DLP
Zero trust ends at the data, and this layer classifies sensitive data, controls where it can move, and masks or blocks it when a request would expose more than it should. Data controls decide what leaves and what is exposed. They pair with the authorization layer, which decides who was allowed to request the data in the first place.
Varonis focuses on data access governance, mapping who can reach which files and data stores, flagging overexposed data, and catching abnormal access before it becomes an incident.
Microsoft Purview handles classification, data loss prevention, and information protection across the Microsoft estate, so labels and policies follow the data.
Nightfall takes an API-first approach, detecting and redacting sensitive data in SaaS apps and AI pipelines before it spreads.
This layer also reaches into retrieval for AI systems, where authorization-aware retrieval filters results at query time so an agent or user only ever retrieves the records they are permitted to see.
7. Visibility, analytics and audit
Zero trust is a program you have to prove, not a box you check, so this layer collects logs and telemetry across all the others and turns them into detection and evidence. Visibility tells you what happened across the stack, and it is where an assessment or an auditor comes looking.
Splunk is the incumbent SIEM and analytics platform, with broad ingestion and mature detection content.
Microsoft Sentinel is a cloud-native SIEM that leans on tight integration with the rest of the Microsoft security stack.
Elastic Security builds detection on the same search engine many teams already run, which makes it attractive where the Elastic Stack is in place.
The value the authorization layer adds into this tier is a clean record of every access decision, who asked for what and why it was allowed or denied, which is often the hardest evidence to reconstruct after the fact.
How the layers fit together
None of these layers replaces another, and the mistake is treating any single one as your zero trust program.
Identity proves who an entity is and how strongly. Network access and microsegmentation decide what it can reach. Device tooling supplies the posture signal. Authorization decides, per request, what it may actually do, and records the decision. Data controls limit what can be exposed. Visibility ties it together and gives you the evidence.
Zero trust is measured on continuous verification and least privilege, and those two tenets live or die at the authorization layer. NIST 800-207 puts the policy decision point at the center of the architecture, and the CISA Zero Trust Maturity Model grades you on enforcing least privilege across identity, applications, and data, not just at the network edge. Those are the parts an assessment presses on hardest, and they are the parts an authorization layer is built to answer.
Source: CISA Zero Trust Maturity Model
How to prioritize
You will not stand up every category at once, so sequence by where your risk actually sits.
If you have little zero trust in place, start at identity. Single sign-on, strong MFA, and conditional access remove the most common source of compromise, the reused or stolen credential, and everything else builds on knowing who is making the request.
Once identity is solid, the highest-leverage next move is the layer most programs skip. Put an authorization layer in front of what identities can do inside your applications, checking each request against policy, tied to the human or workload behind it, logging every decision. This is where least privilege stops being a slogan and becomes something you enforce, and it is usually the widest gap between a zero trust strategy on paper and one in production.
Network access, device trust, and microsegmentation come in alongside, especially if you still run a flat VPN or have workloads that talk freely to each other. Data controls and visibility round it out, with visibility worth standing up early, since you cannot improve what you cannot measure.
Authentication and network access get most of the budget and the attention, while authorization, the control that actually enforces least privilege on every request and produces the audit trail, is the one most often left inside application code. It is also the one that scales, since a single policy engine can govern human users, service accounts, and AI agents together rather than as separate systems.
Getting started
A zero trust stack is layered, and the fastest way to close the gap most teams have is to make what every identity is allowed to do an explicit, logged decision rather than something buried in each service. If you want to see that layer in practice, our writeups on zero trust authorization and the CISO's guide to implementing zero trust are a good place to start.
Try Cerbos to put a policy-based authorization solution in front of your applications and agents, or book a call to talk through your zero trust rollout with our team.
Go deeper:
- The IAM security checklist for 2026 (Checklist) for the access-control questions an auditor will ask
- Layered security: what aviation safety can teach us about zero trust (Webinar) for seeing why fine grained authorization is the layer that catches what the others miss
FAQ
Tagged in
