IGA has a conjunction in it. Most programs read it as a preposition.
Say the words out loud: identity governance and administration. Two jobs. One decides who should have access and can prove it. The other grants that access, changes it when the work changes, and takes it away when the person, the contract, or the workload ends. The acronym joins them because neither one is worth much alone.
What I hear in most rooms is a different reading — "the administration of identity governance," as though governance is the product and administration is the clerical work that supports it. That misreading is expensive. It's why organizations buy a platform, run campaigns, pass an audit, and still can't get a new engineer working on day one. It's why others automate provisioning brilliantly and can't answer the only question an auditor actually asks: who decided this person should have this, and when did someone last check?
This is the most consequential misunderstanding in enterprise identity, and it's not a vocabulary problem. It determines what you buy, what you connect to it, who owns it, and whether the money you spend produces speed, proof, both, or neither.
Two jobs, defined
Governance decides and proves. It holds the policy: what a role is, who may hold it, what combinations are forbidden, what has to be reviewed and how often. Its outputs are decisions and evidence — this person should have this, someone accountable said so, here is the record.
Administration executes. It creates the account, grants the entitlement, moves it when the person moves, revokes it the hour a contract ends. Its outputs are changes in the systems people actually log into.
Put crudely: governance is the decision, administration is the door. A decision that never reaches the door changes nothing. A door that opens without a decision is just an unlocked building with good lighting.
Every failure mode I've watched teams struggle with is a version of that split.
Half a program, twice the cost
Governance without administration is compliance theater. The campaign runs. Managers certify. Revocations are recorded. Then the revocation lands in a ticket queue, where it competes with everything else, and three weeks later the entitlement is still live. The organization has a defensible record of a decision nobody executed. The evidence is real, while the change is theory.
I would put it this way: if your review can end in a decision that no system is set up to carry out, you don't have governance; you have a survey.
Administration without governance is speed you can't defend. Provisioning is automated, access lands in minutes, the service desk queue is short — and nobody can say why any of it was granted. Requests were approved by whoever was nearest. Roles are accumulated. When the auditor asks for the basis of an entitlement, the honest answer is "someone clicked approve in 2023."
The second failure is more comfortable than the first, because it feels like progress, but it scales the wrong thing. Speed without a decision record is how an organization ends up over-permissioned at the pace of machines.
The scale of that accumulation is measurable. Palo Alto Networks' Unit 42 analyzed more than 680,000 identities across cloud accounts and found 99% of cloud users, roles and services carried excessive permissions, with some of those permissions unused for 60 days or more. In its incident response work, identity weaknesses were material factors in nearly 90% of investigations. Those permissions were all administered correctly. Each one was granted by a working process. None of them were governed.
Excessive access isn't an administration failure — the access was granted competently. It's a governance failure that administration then executed faithfully, for years.
Why the estate keeps outgrowing the debate
The split matters more every year, because the population needing both jobs is growing in a direction most programs weren't designed for.
SailPoint's Horizons of Identity Security research, based on 375 IAM decision-makers surveyed in June 2025, found 63% of organizations still sitting in the lowest maturity horizons, with 10% reaching the advanced stages — and fewer than four in ten governing AI agents at all. An earlier edition of the same research, across 350 security leaders, found machine identity coverage of 87% among the most mature programs against 28% among early-stage ones. The gap between those two numbers isn't a technology gap. It's a gap in whether machine identities were ever admitted into the scope of the IAM program.
Here is the part I would underline for anyone standing up an IGA program: a service account receives access, so it needs administering. It holds privilege, so it needs governing. An AI agent does both, faster, and can be created by a developer on a Tuesday afternoon. If your definition of IGA is "the administration of identity governance," none of these are inherently in scope, because they're not people and they don't have managers. If your definition is "governance and administration of everything that gets access," they were always in scope, and the only question is when you connect them.
The scope test
This is where the misreading does its most practical damage. An application that's not connected to the platform isn't governed or administered. It's an island with its own admins, its own local accounts, and its own quiet accumulation of former employees and forgotten contractors. You can certify it on a spreadsheet and the certification will mean exactly as much as the spreadsheet can enforce — which is nothing.
I would argue the single most useful diagnostic for an identity program isn't a maturity score. It's a count:
- How many applications does the platform administer — create, change and remove access in, automatically?
- How many does it only report on, with the actual changes made by hand somewhere else?
- How many aren't in it at all?
The first number is your real coverage. Everything else is aspiration with a dashboard.
The same test applies to the populations, not just the systems. Employees are usually in. Contractors are sometimes in. Service accounts are occasionally in. Agents are rarely in. Each exclusion is a place where one of the two jobs silently stops happening.
Roles: the place both halves meet
Role-based access is the clearest example of why the conjunction matters, and the most common casualty of ignoring it.
A role is a governance artifact: a statement that this kind of work needs this set of access, approved by someone accountable for that work. It's also an administration artifact: the thing that gets provisioned on day one and removed on the last day. Build roles in the governance layer without wiring the administration layer, and you get a beautiful model nobody is benefiting from. Provision access without roles, and you get access shaped by whoever asked and got approved — which is the same as having no model at all.
When people tell me their role project failed, the failure is almost always at that seam. The model was designed as a documentation exercise rather than as the instruction set for a machine that grants access.
The mover problem
If you want a single case that proves the two jobs are one system, don't look at joiners or leavers. Look at movers.
Joiners are easy to argue about because the business notices them. Leavers are easy to argue about because auditors notice them. Movers — the people who change teams, get promoted, take on a second responsibility, or rotate off a project — are where the design earns its stripes.
Governance has to decide what the new work needs and what the old work no longer justifies. Administration has to grant the first set and remove the second. Miss the decision and the person accumulates. Miss the execution and the person accumulates. The outcome is identical, and accumulated access from movers is the most defensible-looking risk in an enterprise. Each entitlement was granted legitimately, and the result is an employee of twelve years who can do the job of every team they ever sat on. Then that account gets phished, and the blast radius isn't their current role — it's every role they've ever held.
Separation-of-duties conflicts are the clearest illustration of why the decision has to live where the change lives. A conflict isn't a property of a request; it's a property of the accumulated state. Only a system that holds both the policy and the current reality can see it.
What executives are actually buying
Administration buys speed while governance buys defensibility. Each half has a different business case, and you need to make both.
Administration's number is time-to-yes: how long it takes an employee or a workload to get what the work requires. That's the number the business feels, and it shows up first in onboarding.
Governance's number is the ability to answer, on demand and without a fire drill, who has access to what, who approved it, and when it was last confirmed. That's the number regulators and auditors feel.
The reason IGA is sold as one platform is that these two outcomes come from the same data model. The decision and the change have to live in the same system, or the record and the reality drift apart. That drift is invisible until an auditor or an attacker finds it.
The uncomfortable question
If you're standing up an IGA program or reviewing one you inherited, the diagnostic isn't "are we compliant?" It's two questions, asked separately:
- When governance decides something, does administration carry it out?
- When administration grants something, did governance decide it by policy, against a role someone owns?
Failure of either shows up as the same symptoms: excessive access, slow onboarding, audit findings, and a platform everyone describes as "not quite there yet."
As an IAM professional for over a decade, I think the language has actively hurt us. "IGA" is a category name that hides its own scope, and a decade of buying cycles has trained people to hear one job where two were meant. Practitioners internalize it, so the program's scope quietly shrinks to what governance can review rather than what identity can control. Executives inherit it, so the funding conversation becomes an audit conversation. And applications, machines and agents sit outside a platform that was supposed to cover everything that gets access.
Security that says yes and security that can prove it aren't competing goals. They're the two halves of one system, and they were in the acronym the whole time.
So here is the exercise: count what your IGA platform actually administers. Not what it reports on. Not what's on the roadmap. Count the applications where it creates, changes and removes access itself; count the service accounts and agents in that number; then put the count next to what you spent. That ratio is your identity program's real maturity, and everything else is a claim about the part of the ecosystem that number doesn't cover.