At 9:02 on a Monday, a claims analyst at a mid-size insurer signs in. She passes MFA on a managed laptop with a clean posture score, connects through the company’s ZTNA gateway, and opens the claims platform. Her role grants read access to the claims database, as it has since she joined three years ago. At 2:15 that afternoon, her session token is stolen through a malicious browser extension, and over the next forty minutes the attacker pulls 38,000 claim records, complete with medical codes and bank details.
Every control in that story worked as designed. Authentication verified her, the device check passed, the network layer allowed the connection, and the role said yes. Each of those decisions happened once, against conditions that were true at 9:02 and stayed frozen for the rest of the day. Nothing evaluated whether a claims analyst should be exporting tens of thousands of records at 2:30 on a Monday, from a session whose behavior no longer matched hers.
The bill arrives in the business, not the SOC: breach notification across several states, a regulator’s inquiry under HIPAA, outside counsel, and a quarter of remediation work that pushes the roadmap back. Static access checks give you zero trust at the front door. Runtime authorization extends it to every request that follows, and that extension is where the financial case for zero trust gets made.
What to use for zero trust access control
Zero trust access control needs four layers working together. Your identity provider verifies who someone is, with MFA and conditional access. Device posture tools confirm the endpoint is managed and healthy. ZTNA and segmentation limit which networks and applications a session can reach. The fourth layer, runtime authorization, decides at each request what that verified identity can do with the specific data or action in front of it, using live context such as role, data sensitivity, time, location, and behavior.
Most programs stop after the third layer. A 2023 Censuswide survey of 200 CISOs and CIOs, run for PlainID, found that only half included authorization in their zero trust program, and just 31 percent reported enough visibility and control over the authorization policies meant to enforce appropriate data access. The full CISO survey findings break down where those programs fall short.
The standards bodies already point to the missing layer. NIST SP 800-207 places a Policy Decision Point and Policy Enforcement Point at the resource itself, and PlainID explains how NIST frames the decision layer in more depth. France’s ANSSI goes further, recommending an authorization infrastructure built on attribute-based access control so access decisions stay dynamic and continuous.
Where static access checks break
A static check evaluates access once and treats the answer as valid until something changes it by hand. Roles get assigned at onboarding and rarely shrink. Conditional access policies run at sign-in and rarely run again mid-session. Application permissions get granted at the feature level, so a user who can open the claims screen can usually see every claim the screen can display.
That model leaves standing privileges everywhere: access that exists independently of any moment someone needs it. An analyst who moved from claims to underwriting six months ago still carries claims access because nobody filed the ticket to remove it. A service account built for a nightly report can query production data at noon. Gartner counts 82 machine identities for every human one, and most of those service accounts, APIs, and AI agents launch with broad, always-on permissions because scoping them by hand takes too long.
Static checks also stop at the application boundary. They answer whether you can reach the claims platform, and they say nothing about which rows, columns, or records you can pull once you’re there. Attackers who steal a valid session inherit everything that session’s role allows, for as long as the session lasts.
The business outcomes of runtime authorization
Runtime authorization evaluates every access request at the moment it happens, against current policy and current context. PlainID’s Runtime Authorization Platform makes those decisions in milliseconds across applications, APIs, data, and AI agents, and the results show up in five places on the business side of the ledger.
A smaller blast radius when credentials are compromised
Zero standing privileges change the math of a breach. When access gets granted per request instead of pre-assigned, a stolen session carries only what each individual request can justify. In the insurer’s scenario, a runtime policy that limits claims analysts to records assigned to their region and blocks bulk exports outside a defined threshold would have stopped the attacker after the first few hundred records. PlainID enforces this down to row and column level, so you can apply row and column controls on sensitive data such as medical codes and bank details without restricting the rest of the record. The difference between a 300-record incident and a 38,000-record incident often decides whether you notify regulators at all.
Audits you can answer in hours
Regulators and auditors want to know who accessed what, when, and under which policy. With access logic scattered across applications and logs, answering that becomes a forensic project that pulls engineers off product work for weeks. PlainID’s Authorization Graph records every decision in one relational view and explains it in business language, which turns audit evidence into a query. PlainID covers cutting the effort behind identity audits with policy-based decisions in more detail.
Lower cost of building and maintaining access logic
Homegrown authorization looks cheap until you count the maintenance. In the same PlainID survey, 41 percent of respondents said they authorize identities with OPA-based homegrown tooling and 40 percent with fully custom code, and 45 percent cited a shortage of technical resources for running enterprise authorization. PlainID reports that moving to dynamic policies cuts development overhead by 30 to 50 percent and role management overhead by up to 90 percent compared with static role management. You can model the savings for your environment with PlainID’s calculator.
Policy changes at the speed of the business
A new regulation, an acquisition, or a reorganization used to mean a development cycle for every affected application. PlainID enforces policy changes globally in under 60 seconds with no code changes, so compliance and security teams adjust access themselves through a no-code builder while engineers keep a policy-as-code path in CI/CD. Product teams keep their release dates because access rules no longer ride along in the code.
AI adoption without new exposure
AI agents are the fastest-growing source of standing privileges in most enterprises. PlainID applies the same runtime policies to agents through Full-Flow AI Guardrails at the prompt, data retrieval, MCP tool, and output stages, and its composite identity authorization evaluates the agent and the human it acts for in a single decision. Security teams approve AI projects faster when they can show exactly what each agent can reach, and PlainID’s guide to removing always-on access for agents walks through the model.
How runtime authorization fits the zero trust stack you already own
Runtime authorization extends your existing investments rather than replacing them. PlainID consumes identity data from Okta, Microsoft Entra ID, and Ping Identity, so every decision inherits the trust signals your IdP already collects. Network-layer tools gain a decision layer too, and PlainID documents extending Zscaler ZPA with policy decisions as one example.
Enforcement runs where the access happens. Pre-built PlainID Authorizers sit in API gateways, service meshes, data platforms such as Snowflake and Databricks, and AI frameworks such as LangChain, while you manage every policy from one central control plane. That split keeps decisions fast enough for production traffic: PlainID processes billions of context-aware decisions at request time every day under a 99.99 percent uptime SLA.
PlainID secures more than 35 million identities for enterprises including Cisco, Citibank, Samsung, and EY, and KuppingerCole recognizes it as Product Leader and Market Leader in Policy-Based Access Management. Its approach to identity-aware zero trust brings these pieces together.
Where to start
Start with the data whose exposure would cost you the most: PHI, cardholder data, nonpublic financial records, or client-confidential documents. Map which identities, human and machine, can reach that data today, and compare the result against who needs it. The gap between those two lists is your standing-privilege exposure, and it gives you a number to take to the board.
Place runtime enforcement in front of that one domain first, at the gateway or data layer, so no application code has to change. Run the new policies in simulation beside existing controls, cut over once they match, and expand domain by domain. PlainID deployments can reach enterprise-wide coverage in under two weeks once the first patterns are proven, and you can benchmark your authorization maturity before you begin.
Frequently asked questions about zero trust access control
What is the difference between authentication and authorization in zero trust?
Authentication confirms who an identity is, using MFA, device checks, and conditional access at sign-in. Authorization decides what that verified identity can do with each resource it requests. Zero trust needs both, and most programs invest heavily in the first while leaving the second static. PlainID adds the authorization layer on top of Okta, Entra ID, or Ping Identity, evaluating every request after sign-in instead of trusting the session.
Is ZTNA enough for zero trust access control?
ZTNA controls which applications and network segments a session can reach, which removes broad network trust. It doesn’t decide which records, fields, or actions a user can access inside those applications. A stolen session that passes ZTNA still carries everything the user’s role allows. Runtime authorization closes that gap by checking each request against policy at the resource, and PlainID can extend tools such as Zscaler ZPA with those decisions.
What does runtime authorization mean?
Runtime authorization means access decisions get made at the moment of each request, using current context such as role, data sensitivity, location, time, and behavior, instead of permissions assigned in advance. Enforcement continues for the length of the session, so access can be cut off when conditions change. PlainID makes these decisions in milliseconds across applications, APIs, data platforms, and AI agents.
