Identity has quietly become the control plane for modern security. The network perimeter dissolved a decade ago, the endpoint perimeter never really worked for remote work, and what's left is identity. Who is calling this API, which workload is reading this row, which agent is running this tool. That's the question every access decision comes down to now, and it's why "identity security" has become the umbrella term most security teams are organising their 2026 roadmaps around.
It's also a term that means very different things depending on who you ask. For some teams it's ITDR and threat detection. For others it's IGA, PAM, and access reviews. For the CISO it's usually all of the above plus whatever comes next for AI agents. This post pulls the discipline together, walks through the pillars most vendors cover, and then gets into the part that tends to get glossed over. The runtime authorization layer that quietly decides whether identity security actually works when a request hits a service.
What identity security actually covers
Identity security is the set of controls that protect identities, govern what they can do, detect when they're misused, and keep the whole system auditable. It sits above and around traditional IAM, treating identity not just as an access gate but as a security domain in its own right.
In practice that breaks down into a handful of named capabilities.
Authentication answers "are you who you say you are" and has slowly migrated from passwords to MFA to passkeys. Access management covers session rules, adaptive step-up, and the layer most people think of as "login." Identity governance and administration (IGA) handles joiners-movers-leavers, access requests, entitlement management, and periodic certifications. Privileged access management (PAM) focuses on the accounts that can do the most damage, pushing toward just-in-time access and the elimination of standing privilege.
Then there are the two Gartner-coined categories that have shown up in every 2026 identity security deck. Identity threat detection and response (ITDR) applies detection and response capability to identity infrastructure itself, watching for signs of credential theft, token replay, session hijacking, and privilege escalation. Identity security posture management (ISPM) looks at the configuration side, hunting for stale accounts, unused entitlements, misconfigured federation, orphaned service accounts, and the general hygiene problems that make identity compromise easy.
And sitting underneath all of it is the identity fabric, an architectural idea rather than a product category. Centralised control over policies and standards, decentralised enforcement at the service level, pervasive use of open standards (SCIM, OIDC, SPIFFE, AuthZEN), and a system that treats every identity, human or otherwise, as a first-class object.
That last part is where the conversation has shifted most in the last two years.
The bigger surface area nobody planned for
Identity used to mean employees, customers, and a handful of service accounts kept running by someone's last Bash script. That picture no longer holds. Machine identities now outnumber human identities inside most enterprises by a large margin, and according to CyberArk's 2024 Identity Security Threat Landscape report, machine identities are currently the fastest growing identity type, with the report finding that 93% of organisations experienced two or more identity-related breaches in the prior year.
Workloads talk to workloads, service meshes route traffic between hundreds of microservices, data platforms issue short-lived credentials by the million, and every cloud environment generates thousands of non-human identities that need the same treatment human users get. Most of them don't get it. They have wide permissions that were correct on day one and have been wrong since, sitting in a category between "privileged" and "invisible" that no IGA tool really knows what to do with.
AI agents have accelerated all of this. Enterprise agent deployments went from single-digit percentages to roughly 42% of large organisations actively deploying in just over a year, according to KPMG AI Pulse reporting from Q3 2025. Agents need identities, they inherit permissions from the users they act on behalf of, and they call tools that call other tools, which creates delegation chains most identity systems can't express, let alone audit.
This is the scope identity security now has to cover. Not just people, but workloads, service accounts, agents, and the relationships between them.
Why identity is now the primary attack surface
The attack data explains the urgency behind all of this. The Verizon 2025 Data Breach Investigations Report found that the human element was involved in 60% of breaches, and that 88% of basic web application attacks involved stolen credentials. Credential abuse has been the top initial access pattern for five consecutive years. IBM's 2024 Cost of a Data Breach report put the average breach cost at $4.88 million, with breaches involving compromised credentials among the most expensive and slowest to contain.
Gartner has been forecasting this for a while. Its widely reported prediction, covered in outlets like VentureBeat, is that through 2026, 70% of identity-first security strategies will fail unless organisations adopt context-based access policies that are continuous and consistent. The companion prediction is the optimistic one. Organisations that get it right will suffer 50% fewer identity-related breaches.
The pattern is consistent across every serious threat report. Attackers don't break in anymore, they log in. They abuse tokens, hijack sessions, pivot through service accounts, and escalate through over-permissioned workloads. This is why identity security exists as a discipline in the first place. The perimeter is now the identity, and every control you have depends on whether the identity layer holds up.
Where identity security still breaks
Everything above is well-covered ground. Most identity security vendors will tell you some version of it, and most CISO roadmaps already reflect it. The part that gets less airtime is where this whole picture still has holes.
Three come up again and again in real deployments.
The first is standing privilege. Research across cloud environments has repeatedly found that over 95% of identities use less than 3% of their granted entitlements. The gap between what an identity can do and what it actually does is the attack surface, and it grows on its own unless somebody actively prunes it. JIT and just-enough access are the accepted answer, but most organisations still have standing permissions stapled to service accounts, break-glass roles, and long-forgotten integrations.
The second is visibility. Teams can see who logged in, but they often can't see what each identity actually did, what it was allowed to do, or why the system said yes when it did. Audit logging is treated as a compliance chore rather than a security signal. Without structured, queryable decision logs, ITDR becomes guesswork and incident response becomes archaeology.
The third is the one that rarely gets top billing. Runtime authorization.
The runtime gap
Identity security has two time dimensions. Admin time, where accounts get provisioned, roles get assigned, and access reviews get signed off. And runtime, where an actual request arrives at an actual service and something has to decide in milliseconds whether to allow it.
Most identity security investment lands on the admin side. IGA modernises provisioning, PAM tightens privileged credentials, ISPM cleans up posture, ITDR watches the control plane. All of that matters. None of it decides what happens when a user, a workload, or an agent calls an API at 3am on a Sunday.
That decision is authorization. It's the layer that takes an identity plus a request plus the current context and returns allow or deny. And it's the layer where identity security actually lives or dies at the moment of truth.
The pattern most teams still have is the wrong one. Authorization logic is buried inside application code, duplicated across services, owned by whichever engineering team wrote that microservice first, and rarely audited. When roles and policies change, every service needs a deploy. When a regulator asks "who can do what with customer data" the answer requires reading the codebase. Context-aware, continuous evaluation, the thing Gartner has been predicting is non-negotiable, is effectively impossible in that setup.
This is the underinvested seam. IGA covers the static picture (who is granted what), access management handles coarse-grained session rules, PAM locks down the big accounts, but runtime decisions on fine-grained resources, with current context and attributes, don't have a natural home in most identity stacks. They end up scattered across services, which means identity security ends up scattered with them.
What good identity security looks like
The shape of a mature identity security program is getting clearer. It starts from an identity fabric architecture, standardises on open protocols, treats humans and machines as peers in the identity graph, and gives every part of the stack a proper runtime counterpart.
A few principles show up in almost every serious framework.
Identity covers everything with an identity. Employees, contractors, customers, workloads, service accounts, and AI agents all belong in the same governance model. Gaps in coverage turn into credential leaks and over-permissioned service accounts.
Access is context-aware and continuous. Not "granted once, forgotten forever" but evaluated against current signals on every request. Who, what, when, where, from which device, on behalf of whom, at what risk level.
Standing privilege is the exception, not the default. Access is granted just in time, for the minimum scope, for the shortest useful duration, and logged completely.
Authorization is externalised. Policies live separately from application code, get versioned like code, get tested in CI, and are enforced by a dedicated decision engine at runtime. This is where PBAC, and externalized authorization management stop being acronyms and start being infrastructure.
Observability is built in. Every authorization decision produces a structured, queryable log that feeds both ITDR and compliance. Without this, the rest of the stack is flying blind.
Where Cerbos fits
Most of the identity security stack has clear category leaders. IGA has SailPoint and Saviynt, PAM has CyberArk and BeyondTrust, access management has Okta and Microsoft. The runtime authorization layer is the one that's still missing from most identity architectures, and that's the gap Cerbos was built for.
Cerbos is a dedicated authorization layer - an authorization management platform - that sits between your applications and the identity fabric. Applications ask a simple question, "can this principal do this action on this resource right now", and Cerbos answers. Policies are written in YAML with conditions expressed in CEL, versioned in Git, tested in CI, and distributed to stateless PDPs that run wherever your workloads run. Decisions come back in sub-millisecond latency, with a structured audit log for every call.
The part that makes it fit inside an identity security program rather than alongside one is Cerbos Synapse, the enrichment and orchestration layer. Synapse pulls identity attributes, group memberships, and relationship data from Okta, Entra ID, Auth0, Keycloak, AWS Cognito, LDAP, and your own databases at decision time, so policies evaluate against live identity context rather than stale role claims. It's also how Cerbos plugs into infrastructure layers like Envoy, Istio, Kafka, Kubernetes, and Trino, translating native protocols into policy checks without custom middleware.
For machine and AI identities, Cerbos treats workloads and agents as first-class principals. A Claude Code hook handler intercepts agent tool calls before execution, evaluates them through Cerbos policies, and either allows or blocks them with a full audit trail. The same pattern works for MCP servers, LangChain agents, and any other non-human identity that needs governed access. There's more on that in the NHI security post and the MCP authorization write-up.
Because Cerbos is AuthZEN-compliant and integrates with the major IdPs and IGA tools rather than replacing them, it slots into an existing identity fabric as the runtime decision layer. IGA still handles provisioning. PAM still handles privileged accounts. ITDR still watches the control plane. Cerbos handles the "allow or deny this specific request" decision that all of them ultimately depend on.
The takeaway
Identity security in 2026 is a broader discipline than it was two years ago. It covers humans and machines, admin time and runtime, posture and detection, and it's now the layer most CISOs are organising their program around. The pillars are well-defined, the vendor landscape is mature for most of them, and the strategic direction is settled.
The gap that still trips up otherwise-mature programs is the runtime authorization layer. Identity security only works if the decision at the moment of request is right, and that decision lives or dies on whether you have context-aware, externalised, observable authorization sitting between your identities and your resources.
If you're building out your identity security roadmap for 2026, the runtime layer is worth putting alongside ITDR and ISPM on the priority list, not below them.
Try Cerbos to see how runtime authorization can fit your needs, or book a call to talk through your identity security architecture with the team.
Go deeper:
- The IAM security checklist for 2026 (Checklist) for a pre-flight list of the controls most programs miss
- How to adopt externalized authorization (eBook) for a step-by-step playbook on decoupling authorization from application code
FAQ
Tagged in
