Ask ten identity leaders where IAM should report and you'll get two answers and a reorg story.

One camp says identity belongs to cybersecurity. Identity is the control plane now; attackers log in rather than break in; the people accountable for that risk should own the thing that creates it. The other camp says identity belongs to infrastructure. It's a service with uptime, a directory, an integration backlog, and a support queue, and services belong with the people who run services.

Both cases are good. That's the problem. The argument is winnable from either side, which is why organizations keep re-winning it; moving identity into security, then back out to platform engineering, then into a standalone group reporting somewhere new after the next incident.

And a year after each move, ask what actually improved. Deprovisioning is still slow. Applications still onboard at the speed of a favor. Contractors still keep access they stopped needing in March. The names on the org chart changed. The program didn't.

My view: the box isn't the program. Where identity reports determines the default answers to five questions. The argument is worth having. It's just far less decisive than the energy spent on it suggests.

What's actually being placed

Before you can place something, you should be able to say what it is.

Identity gets either filed as a control or as plumbing, and it's neither. It behaves like a platform with consumers; every application team, HR, the service desk, the audit function, and every new hire who needs to work on day one. It has a roadmap, because the things it needs to build are years long and can't be delivered by a ticketing system. It has an outage surface that takes the whole company down with it. It also has a mandate it can't enforce on its own: identity depends on application owners choosing to integrate, on HR sending clean data, and on managers making real decisions during access reviews.

That last property is the one both towers underestimate. Identity is responsible for outcomes it doesn't directly control. Which means the only thing that matters about its placement is how much of that gap the placement closes.

Each tower closes a different half.

Under security, the mandate is real and the delivery capacity is thin. Identity gets board attention, a risk narrative, and budget that arrives when something goes wrong. It also gets treated as a control to be evidenced rather than a platform to be built. Priorities come from the risk register and the audit calendar. Engineering capacity is whatever is left after the security operations center is staffed. Over a few years, the program becomes a gate — good at saying what shouldn't happen, slow at making the right thing happen.

Under infrastructure, the delivery is strong and the decision record is missing. Provisioning works. Integrations ship. There's an on-call rotation and a real SLA. What there isn't is a funded reason to take access away, because removal has no ticket behind it and no customer asking for it. Governance becomes a project that gets funded after an audit finding and defunded after the finding closes.

That also shows up in the data. Palo Alto Networks' 2026 Identity Security Landscape found 96% of respondents report human identities operating with access far beyond what their roles require. Every one of those permissions was administered correctly. Each was granted by a working process, by a competent team, or in response to a legitimate request.

I wrote recently that IGA is two jobs joined by a conjunction: governance decides who should have access and proves it, administration grants and removes it. The org chart is where that conjunction gets cut. Security inherits the deciding. Infrastructure inherits the doing. Both halves are staffed, however neither is whole.

Ultimately neither placement is wrong, and that's exactly why the reorg could disappoint. You're not fixing an incomplete program. You're trading one incompleteness for the opposite one, and paying a year of re-explaining yourself for the privilege.

The seam is the expensive part

Look at what actually lives at the boundary between the two towers, and you find the work nobody owns: joiner-mover-leaver, contractors and third parties, service accounts and machine identities, and the quality of the HR feed everything else depends on.

This isn't the exotic part of identity. It's the majority of it, and it's consistently the part that breaks.

Cisco Duo's 2026 CISO Perspectives report, built on interviews with more than two dozen CISOs and security executives, found 86% of leaders concerned about inadequate controls for contractors and third-party access, and more than half specifically worried about handling leavers. These aren't unsolved technical problems.

Service accounts and non-human identities are the purest seam artifact there is. They're created by infrastructure for an operational reason, governed by nobody, owned by whoever left the company three roles ago.

The third box

The obvious response to a seam is to remove it: make identity its own function, with both halves inside it, reporting to the CIO or the CISO or occasionally straight to a COO. I have a lot of sympathy for this answer. It's the only one of the three that starts from what identity actually is rather than from which existing tower is least bad.

It also works, when two conditions hold true. The first is a funding line of its own - not an allocation carved out of a security or infrastructure budget each year, which recreates the split with extra steps. The second is a sponsor senior enough that the standalone function's standards survive escalation.

That second condition is where most standalone identity groups quietly fail. A separate vertical carries political weight that a function doesn't. When identity sat inside security, a refusal came with the CISO's implied signature behind it; when it sits on its own, the refusal comes with the identity director's, and an application team facing a launch date will test the difference within a quarter. A standalone function has to win every escalation on merit, repeatedly, forever. Some do. The ones I would bet on are the ones whose sponsor has said out loud, in front of other executives, that identity's standard is the company's standard.

So the third box isn't an escape from the question. It removes the seam between governance and administration, which is real progress, and then hands you the mandate problem in a more concentrated form. Which is the pattern with all three placements: each one solves a different subset, and none of them can solve the set.

Five questions that predict more than the box does

If the reporting line only sets defaults, what should you actually judge a placement on? I'd argue there are five questions, and a placement is good exactly to the extent that each one has a name attached to it.

1. Where does the money come from? One funding line, or two half-funded ones? Split funding is how you end up with a program that can pass an audit but can't integrate an application, or one that integrates beautifully and can't tell you why anyone has anything. If governance work and administration work compete for different budgets held by different executives, the org chart has already decided which half of your program gets cut in a lean year.

2. Who can tell an application team no, and make it stick? Every identity program has a standard. The question is whether the standard survives contact with a launch date. If an application team can escalate past identity to a sponsor who outranks the standard, you don't have a mandate; you have a strong recommendation.

3. Who gets paged? An identity outage is a company outage. If the people carrying the pager aren't the people who set the roadmap, you've created on-call without authority. That's the fastest way I know to lose your best identity engineers.

4. Who owns the authoritative source? Almost every identity failure traces back to the joiner-mover-leaver feed. If the data quality belongs to HR and the consequences belong to identity, no single person owns the outcome, and the conversation after each failure is a negotiation rather than a fix.

5. Who signs the exception, and when does it expire? Exceptions are where governance quietly dies. A program with no exception process grants them informally and forever. A placement that leaves exception authority ambiguous will discover that the person granting them is whoever is most senior in the room at the time.

When you answer those five with names, the reporting line becomes a detail. Leave any of them blank and no box on the chart will save you.

Placement is a phase, not a permanent truth

The other thing the debate gets wrong is the tense. The right placement isn't a fact about identity; It's a fact about your program's stage.

Standing up a program needs a mandate, urgency, and executive coverage more than it needs engineering throughput. It needs budget that doesn't compete with an infrastructure refresh, and a sponsor who can compel application teams to participate. Security placement usually wins this phase, because that's where the compelling force lives.

Running a program at scale needs the opposite (integration throughput, product management, release discipline, an SLA, engineers who want to build platforms rather than write findings.). Platform or infrastructure placement usually wins this phase, because that's where delivery capacity and engineering culture live.

Rescuing a failed program needs neither by default. It needs someone who can force decisions across both towers and reallocate money in-year - so it belongs with whoever has that authority, regardless of which tower they sit in, understanding it would move again once the rescue is done.

The tells are easy to read once you know to look for them. If every roadmap conversation turns into a risk conversation and nothing has been integrated in two quarters, you've outgrown a security placement. If your backlog is entirely ticket work and your last governance improvement was an audit finding, you've outgrown an infrastructure placement.

My view is that each move costs the program the better part of a year in relationship rebuilding and re-established credibility, which is an argument for moving deliberately, not for never moving. The organizations that suffer most are the ones that treat a placement chosen during a crisis as the permanent answer, and then spend five years explaining why identity behaves strangely in a tower that it outgrew.

If you can't move the box

Most people reading this don't have the decision rights to reorganize. That's fine. Four of the five answers can be secured without moving a single line on the chart:

  • Name one owner for both halves - governance and administration - even if that person's authority is delegated rather than structural.
  • Run one backlog. If the review campaign and the revocation that follows it live in two systems owned by two teams, you've automated the decision and left the execution to hope.
  • Publish the onboarding standard with an exception path and a named approver. Remember, a written standard loses fewer escalations than an unwritten one.
  • Keep an exception register where every entry has an expiry date. Exceptions that expire are a control.
  • Write a data contract with HR: what the feed contains, when it lands, who's accountable when it doesn't, and what identity is permitted to do with a record that arrives late or wrong. Most organizations have this agreement informally, which means the relationship is perfect until the first disagreement.

The fifth answer of who gets paged is the one that usually needs intentional structure, because on-call follows the org chart whether or not a roadmap does. If you can't move it, at least make the mismatch explicit to whoever owns both towers. An escalation path that has been named in advance is worth more than a path negotiated at two in the morning.

Once your questions are answered, make the answers visible upward; The people who will eventually settle the org chart argument are currently doing it blind. Omada's State of Identity Governance 2026, a study of 577 identity and security leaders at US enterprises, found more than 40% of executives lack visibility into core identity risk indicators such as privileged access and access revocation. An executive who can't see whether revocation works, will decide where identity reports on the basis of personalities and last quarter's incident.

The argument worth having instead

Identity is the invisible infrastructure the business runs on, and infrastructure doesn't get better because it changed managers. It gets better when someone owns the decision at the door.

So have the reporting-line argument: it sets your defaults, and defaults matter. Just don't mistake it for the work. The next time someone proposes moving identity, ask which of the five questions the move actually answers. If the honest answer is none of them, you're about to spend a year producing a different org chart and the same program.