Ask that question in a company with five hundred engineers and you will get three answers and no owner. The customer identity team owns login and issues tokens. The security identity team administers the corporate identity provider and enterprise sign-on. Architecture has looked at parts of the problem but has no mandate to fix it. Each of them is interested. None of them is allowed to prioritize it, because it is not theirs, and so the thing everyone agrees is broken stays broken.
That picture is a composite, and every detail in it will be familiar to anyone in a regulated enterprise. A valid token from the identity provider means access to every platform endpoint. The only enforcement is a tenant ID the API gateway injects from a client certificate. Downstream services trust each other completely. The accumulated gap runs to years of permissions debt, and the sharpest part of it is not technical at all. Lots of people are interested in it, but because they do not own it, they do not get the time to look at it properly, and they are not allowed to go and fix it.
It is a common enough shape that the analyst frameworks describe it, and it has come up in a handful of our own conversations with enterprises, each with a different org chart.
There is no default owner for authorization, and any article that tells you there is one is guessing. This one covers why the decision falls between teams, what that costs, the places ownership usually lands and what each cannot cover, and how to decide who owns which layer without a big-bang program.
Why authorization falls between identity, security and architecture teams
Authorization is the decision about whether this principal may take this action on this resource, and that decision draws on data every team owns a piece of. The identity team knows who the principal is. The application team knows what the resource is and what the actions mean. Security knows what the policy should say. Nobody owns the decision itself, because the decision was never a component. It was a line of code in whichever service happened to need it.
Conway's law explains why the org chart produces this.
Three identity-adjacent teams that rarely talk produce three identity-adjacent systems that do not compose. The analysts have been describing the result for years. KuppingerCole's Identity Fabric reference architecture opens with it. "In many environments, IAM domains such as IGA, PAM, CIAM and access management have evolved separately, creating siloed architectures, duplicated capabilities, inconsistent governance, and complex integrations." Governance, privileged access, customer identity and workforce access each grew their own tools and their own teams, and the decision about what a signed-in principal may do to a specific resource belongs to none of them. Rogério Rondini, principal IAM architect at PwC, said at EIC 2026 that the traditional domains are usually siloed, that a new operating model organized by capability rather than by domain is required, and that buying new tools will not solve the problem.
Heather Flanagan's read of the RSAC and Identiverse 2026 vendor floors is the most useful framing for this discussion. Identity, signals, policy, enforcement and execution are five layers that together form a decision system, and the decision is assembled across them. No single tool owns the outcome, and the assembly is treated as an implementation detail even though it is where the gaps surface. Swap tools for teams and you have the enterprise ownership problem exactly. The decision is assembled across three teams, and the assembly has no owner.
Unowned authorization is paid for in incidents and blocked roadmaps
The cost arrives from two directions.
The first is the incident. In March 2026 a software defect in the API handling transaction data at Lloyds Banking Group meant up to 447,936 customers could see other people's transactions over four and a half hours. That incident is the right frame for any internal deck on why this matters. A defect that breaks isolation between accounts only becomes an incident if the API trusted the caller in the first place. When every service checks for a valid token and nothing else, that trust is the design, not a bug.
The second cost is quieter, and it is often what finally moves budget. Engineering wants logical multi-instance deployment, spinning up another tenant as configuration rather than as infrastructure, to cut cloud spend and speed up releases. That plan stalls at the first question. Where is the tenant boundary enforced? If the answer is a header the gateway sets from a certificate, then multi-tenancy is blocked on authorization, and the cloud bill keeps paying for the gap. Scaling multi-tenant authorization is an authorization project before it is an infrastructure one. Agent adoption stalls on the same decision. An agent calling internal APIs with a service identity that a valid token admits everywhere is a standing privilege problem, and the non-human identity work cannot start until someone owns the rule the agent is checked against.
Duplication is the surest sign that a capability has no owner. When seven or eight product teams each build their own one-time-passcode service because no identity platform exists to provide one, the organization is paying for the same thing eight times and governing it zero times. Authorization checks scattered across services are the same pattern with higher stakes, and we have described the engineering cost in why external authorization.
Where authorization ownership usually lands, and what each place cannot cover
When a large organization does assign authorization somewhere, it usually lands in one of three places. Each covers part of the decision and leaves the rest unowned.
The first is that the identity team owns it as an extension of the identity provider. This works for coarse access, who can reach which application, because that is what the IdP already answers. It breaks at the application layer. The identity team does not know what a customer account, a claim or a payment run is, so the policies that matter most stay in code the identity team cannot see or govern. Their remit ends at the token, and the gap after authentication is where the incidents live.
The second is that each product team owns its own. This is the default in most engineering organizations, and it is what fifty teams with no shared platform will do. At Utility Warehouse, a FTSE 250 company running over 4,500 internal services, the principal engineer who led their centralization described it directly. Their 200 plus engineers were doing their own thing, and there was no standard way of doing authorization. Every team makes a locally reasonable decision, none of them compose, and security has no single place to look.
The third is that a platform or security architecture team owns the decision layer as a service, product teams own their rules, and security owns the standard. This is the shape the analyst frameworks converge on. Gartner describes a machine IAM working group, usually led by cybersecurity or IAM, that sets the architecture and governs the tooling without owning every tool, while developers and application owners own their workloads and, in some organizations, platform engineering owns the access tooling for its own domain. Patrick Teichmann of KuppingerCole made the same argument at EIC 2026 in a session on staffing the identity fabric. Every IAM capability, he argued, has to be allocated along three axes, who designs it, who executes it day to day, and who supplies the input data, and each of those can sit centrally or in the business. His worked example for entitlements puts design with a central IAM team, execution with business units, and input with application owners. Shared accountability, in his words, is usually a problematic thing. Somebody has to be named.
In Team Topologies terms, the decision layer is a platform product. It is the policy decision point, the service every application asks for an allow or deny, plus the policy repository, the test suite in CI and the audit pipeline, consumed by stream-aligned product teams as a service. Those product teams own the resource policies for what they build, because they are the only people who know what the actions mean. Security owns the standard and the review gate. The identity team owns the inputs, the principal attributes and claims the decision consumes. Nobody owns everything, and the layers meet in a policy file that is reviewed like code. What this pattern cannot do is decide itself into existence. Someone senior has to allocate the layers, and in the three-team situation this article opened with, the missing allocation is the whole problem.
Split authorization ownership by layer, not by team
The practical version is a short table, built on Teichmann's design, execution and input split and on Gartner's working-group model. Treat it as a starting template. Every organization we have talked to allocates these rows differently, depending on whether a platform team exists, how senior the identity function is, and whether security architecture has a mandate to run infrastructure rather than only review designs.
The table is the thing to take into the meeting where the three teams argue about whose problem this is, so the argument is about which row moves, not about whether the rows exist.
| Layer | Usual owner | Accountable for |
|---|---|---|
| Identities, claims and attributes | Identity teams (customer and workforce) | Supplying the inputs. Who the principal is, what the token asserts, and keeping the directory data the decision depends on accurate |
| Decision point, policy repository, CI, audit pipeline | Platform team, or security architecture where no platform team exists | Designing and running the service. The policy decision point, policy distribution, testing before it ships, decision logs collected in one place |
| Resource policies | Product teams | Executing day to day. What the actions on their resources mean and who may take them, written as policy in their own repository path |
| Policy standard, review and recertification | Security and GRC | Designing the standard. The rules policies must follow, the review gate, and the periodic check that policies still say what the business intends |
The rows move in practice. Organizations without a platform team put the second row under security architecture or enterprise architecture, which works as long as it comes with the budget to run a service and not only to review designs. Organizations with a strong central IAM function sometimes take the fourth row into IAM governance. Smaller estates collapse the second and third rows into one team for a while. None of those is wrong. Leaving a row with two names on it is.
Recertification changes shape under this model. Heiko Klarl of Nexis made the point at EIC 2026 that the per-identity access review does not survive at the scale agents bring, and what replaces it is recertifying the policy. The business owner reviews whether the policy still expresses the intent, not whether each individual identity holds the right grants. He also noted that DORA, NIS2 and ISO 27001 already require regular recertification of who is allowed to do what, and none of them carve out non-human identities. Under a layered model that review has a named owner and a single artifact to review, which it does not have when the rules are spread across fifty codebases.
The identity team's role in this model is often the one that needs the most reassurance. They are not being asked to write application policy. They are being asked to make the data the decision needs available and correct, which is the job they already have. When the decision point can pull group membership, directory roles and profile attributes from Entra ID at request time, the identity team's work feeds every authorization decision without the identity team owning any of the policy.
How to establish authorization ownership without a big-bang program
The ownership model is the easy part to draw and the hard part to make real, because the honest objection from engineering is that nobody had to think about permissions before. The way through is not a program that asks every team to model everything at once. It is one visibly broken use case, owned end to end, that the second team then asks to copy.
Pick the path where the pain is already visible. A support workflow that needs production write access, a tenant boundary that rests on a certificate subject, an internal tool where a valid token means everything. Write the roles and actions matrix for that path on one page. Put a policy decision point in front of it in development, then in production, and let the first team feel the difference between a permission change that takes a code deploy and one that takes a policy commit. Whoever you named for the decision layer owns the decision point from day one. The product team owns the one policy file. Security reviews it. That is the whole allocation, at the scale of one use case, and it is enough to find out whether the split you chose is the right one before you apply it to fifty teams.
Two forcing functions make the timing easier. A multi-tenancy initiative cannot proceed until the tenant boundary is a policy decision, so it brings engineering to the table with a cost saving attached. And agents arriving in the estate turn non-human identity from a topic nobody had time for into one the CISO is asking about, which we covered in dimmer switch, not kill switch. Neither needs to be sold as an authorization project. Both are blocked on one.
Policy as code is what makes ownership legible afterwards. When every rule lives in a repository, the question of who owns authorization has a literal answer in the code owners file, the review history shows who approved each change, and the CI pipeline proves the policy was tested before it shipped. Ownership stops being an org chart argument and becomes a property of the repository.
What the owning team needs from the platform
Once ownership is split by layer, the platform has to make the split workable, and this is where the choice of authorization platform stops being a developer preference and becomes an organizational one.
The identity team needs the decision to consume the data they already govern, without writing integration code. The product teams need a policy language they can read and test, a playground to try changes safely, and a distribution path that gets a policy commit to every decision point without a redeploy. Security needs one policy model across customer, workforce, partner and service identities, so the standard they write applies everywhere, and one place where every decision from every service is logged. The platform team needs all of that to run as a fleet, with policies propagating from Git to every decision point and audit logs flowing back to one store.
That is the shape of the Cerbos authorization management platform. The policy decision point makes the decision. Cerbos Hub distributes policy, runs the tests, and collects the decision logs from every instance. Cerbos Synapse fetches identity, resource and relationship data at decision time so the identity team's directory and the product team's data both reach the policy without either team building the plumbing. One policy model covers the API gateway, the services behind it, and the agents that will call them next. Authorize every identity. Govern every action. Prove every decision.
Authorization needs an owner before it needs a tool
The three teams this article opened with do not lack skill or interest. They lack a place where the authorization decision lives, and so it lives nowhere. Giving it a place, a decision point run by whichever team you name, policies owned by the people who understand the resources, a standard owned by security, and inputs owned by identity, is what turns years of permissions debt into a backlog someone is allowed to work on. Start with one path. The second team will ask for it.
Try Cerbos to see what one policy model across customer, workforce and service identities looks like in practice, with a decision log your security team can hand to an auditor, or book a call to talk through how the ownership split would map onto your teams.
Go deeper:
- How to adopt externalized authorization (eBook) for the step-by-step path from scattered checks to a decision layer with an owner
- A CISO's benchmark for authorization maturity (eBook) for where ownership sits on the maturity curve and a 30, 60 and 90 day plan to close any authorization gaps
FAQ
Tagged in
