Identity Governance and Administration (IGA)

Identity governance and administration is the layer of identity management that decides what access should exist, who approves changes to it, and how the organization proves later that those decisions were made on purpose. It sits above authentication, which is the job of the identity provider and single sign-on. Authentication asks whether this is the right person. Governance asks whether this person should have this access at all.

A working IGA program can answer four questions at any moment, without anyone opening an admin console. Who has access to what. Why they have it. Whether it is still appropriate. How that would be shown to an auditor. When answering those questions means digging through admin panels and spreadsheets, the governance layer is missing or has stopped working, whatever the org chart says.

what the company already runs             what governance adds on top
--------------------------------------    ------------------------------------------
HR system     who works here              who SHOULD have access, and why
directory     the accounts                who approved it, and when
SSO and MFA   can this person log in?     is it still appropriate? (reviews)
SCIM          create and deactivate       every app, SCIM or not
              accounts in the apps        prove it to an auditor (evidence)
              that support it

What does IGA include?

The components are stable across vendors, even when the marketing emphasis moves around. Each one answers a different part of the four questions above.

Provisioning and deprovisioning

Access is granted when a person joins, changed when they move and removed when they leave. The same machinery has to cover contractors and non-human identities such as service accounts, API keys and AI agents, because an auditor samples accounts, not employees. Provisioning is the part of IGA most often automated first, and the part most often assumed to be finished when it only covers the applications behind SSO.

Access requests

The flow that runs when someone needs something beyond their default bundle. A request names the resource and the reason, routes to an approver who can judge it, and leaves a record of both the decision and the grant. Without a request flow, access is granted in chat messages and never recorded, and the audit trail starts with a gap.

Access reviews and certifications

The periodic or continuous check of who holds what, with an explicit keep-or-remove decision per entitlement. Reviews are the control that catches what the lifecycle missed: the mover who kept an old role, the contractor whose end date passed, the account nobody can name an owner for. They are also the control most often performed as theater, with a spreadsheet approved in bulk.

Policy enforcement

The rules that shape access before anyone requests it. Role-based access control maps a job to a bundle. Attribute-based policies add conditions such as department, location or employment type. Separation-of-duties constraints keep one person from holding two permissions that together allow fraud, such as creating a vendor and approving its invoices.

The audit trail

The timestamped record of every grant, change and revocation, each mapped to the policy or approval that authorized it. Frameworks do not ask for good intentions. They ask for this record, and for proof that what it says matches what the systems show.

A practitioner in a regulated business described the same list from the buyer's side, in a thread about an open-source identity server:

Onboarding - birthright provisioning of accounts across many systems. Email, directory, etc. Termination - automatically remove application level access across the business, not just the user's sso access. Approval - the ability to request access to a system, have it go through a series approvals (which are audited) and then if approved, provision the correct level of access in the end system. Certification - the ability to do periodic access reviews of users. This is typically run yearly or quarterly.

How does IGA differ from IAM and SSO?

The three terms are nested, and the nesting is where most confusion starts.

The one-line test

SSO answers whether this person can log in. IGA answers whether they should have this access at all, who decided that, and how the organization proves the decision was made on purpose. The two questions are settled by different systems, and a company can pass the first cleanly while failing the second for eighteen months without noticing.

Why the nesting matters at purchase time

Most companies run IAM and SSO first, through their identity provider, and face a separate decision about governance later. The identity providers now sell governance add-ons of their own, which makes the decision look like a checkbox on a renewal rather than a category choice. Two things separate those add-ons from a governance layer. The first is reach: a bundled add-on tends to see the applications that support SCIM on the plan the company pays for, and no others. The second difference is the object each one governs. An identity provider governs its own directory, so a person removed there looks fully offboarded even when three local accounts survive in applications the directory never touched.

Does IGA depend on SCIM?

No, although most tools behave as if it does.

What SCIM actually reaches

SCIM is one way to provision and deprovision accounts, and it works only where two conditions hold at once. The application has to implement the protocol, and it has to expose it on the plan tier the company already holds. In a typical mid-market stack that intersection is a minority of applications, and the applications outside it are not the marginal ones. Finance tools, design tools, internal admin panels and anything bought by a single team before IT heard about it all tend to sit outside. Governance has to cover the whole stack: the standard-plan SaaS, the internal tools, the legacy systems, the contractors and the service accounts.

What governing the rest requires

The applications outside SCIM still need the same four answers. That means connecting to each one directly, over its API where one exists and through its admin console where one does not, and reading its real account list rather than the identity provider's view of it. The distinction is not academic, because the two lists disagree in predictable ways. An identity provider reports the assignments it made; the application reports the accounts that exist, including the ones created by an admin inside the product, invited by a colleague, or left behind when a trial converted. Reconciling those two lists is the work, and it is the part that gets done by hand until it stops fitting in a week. Someone who has taken companies through SOC 2 described the manual version:

When does a company need dedicated IGA?

The signal is usually one of a handful of events rather than a headcount. Five recur often enough to be worth naming.

Scale crosses the manual line

The company passes 50 employees and 30 SaaS applications, with more of both arriving every quarter. The number that matters is the product of the two, because the work is accounts rather than people, and accounts grow on both axes at once.

A compliance date lands

Compliance pressure arrives with a date attached: SOC 2, ISO 27001, HIPAA, NERC CIP, ITAR or an FDA inspection. A date turns governance from a good idea into a deliverable, and the deliverable is evidence rather than intent.

A near-miss surfaces

A former employee still has live credentials, a contractor's access outlasts the contract, or a service account turns up with no owner. Near-misses are the cheapest signal available, because they cost nothing but attention, and they reveal the shape of the gap rather than its size.

Someone asks in writing

A board member or an enterprise customer sends a questionnaire that asks about access governance by name. The question is usually answerable, and answering it with evidence, on the timeline a deal runs on, is what exposes whether a program exists.

The list cannot be produced

The IT manager is asked for a current list of who can reach a particular system and cannot produce one inside an hour. This is the operational definition of the gap, and it holds whatever the tooling diagram says.

Before those signals, manual identity work is usually adequate: spreadsheet access reviews, access requests in Slack, offboarding from a runbook. After them, the manual approach fails quietly, and the gaps it leaves accumulate into audit risk.

How do IGA tools compare?

Three categories of product get confused with one another, and the confusion is expensive.

Legacy enterprise IGA

Legacy IGA does the job for the organizations it was built for. Depth is the product: per-application connectors written to a customer's own schema, role models maintained by dedicated administrators, and workflow engines that can express a bank's approval chain. That depth arrives with the implementation cost that produces it, which is measured in quarters and in named staff rather than in a subscription line.

SCIM-first IGA

SCIM-first tools deploy in days and read cleanly, because the protocol does the integration work. Their coverage is bounded by which applications expose SCIM on the plan the customer holds, and the boundary is invisible from inside the product. Everything past it degrades into a ticket for a human, which means the governance record for those applications is a note saying someone was asked.

Full-coverage IGA

Full-coverage tools treat the protocol as one connection method among several, and govern SCIM, API-only and admin-console-only applications from the same place. The test of the category is not how many connectors a vendor lists. It is whether the account list the tool shows for an application matches the list an administrator sees inside that application on the same morning.

Iden is the full-coverage layer this page describes, built for companies of 50 to 2,000 people. The Identities screen is the single list the definition asks for: every person and every non-human account, the team each belongs to, and the applications each can reach, whether or not the application has SCIM. The feature behind it is Access reviews with a decision on every row.

433 Identitäten, 321 davon human, 112 nicht. cc_github und das MCP-Token stehen in derselben Tabelle wie Amy Lee, mit denselben Spalten und denselben Offboarding-Zuständen.

The gap between an identity provider's SSO and an enterprise IGA suite is where most mid-market teams operate today, often without realizing that the IGA work is already being done, by hand.

Which terms get confused with IGA?

Several adjacent terms are used as if they were synonyms, and they are not. The differences fall into three groups, and naming them prevents most of the confusion. A component is part of IGA, a neighbor is a separate control that touches the same accounts, and a different discipline shares the vocabulary while governing a different population.

Why the confusion is expensive

Vendor comparisons go wrong when a component is priced against the whole. A provisioning tool quoted against a governance platform will always look cheaper, because it is solving one of five problems, and the other four stay on someone's desk at a cost that never appears on the quote. The same error runs the other way at renewal, when a governance line item is cut on the grounds that the identity provider already does provisioning.

What does a working IGA program look like?

The test is operational, not architectural. A program is working when the following hold on any given day.

• Every account in every application maps to a current person or to a non-human identity with a named owner.
• A new hire has the access their role requires on the first morning, and nothing else.
• A departure closes every account the person held within the hour, including the ones outside SSO, and the record of each closure exists without anyone assembling it.
• An access review shows the reviewer what each entitlement grants and when it was last used, and a rejection removes the access in the application.
• The answer to who can reach a given system takes minutes, and it comes from the systems rather than from memory.

Where programs stop short

A program that meets those five is governing. A program that meets them for the SCIM applications only is governing the easy fifth of the stack, and the samples an auditor draws are not weighted toward the easy fifth. Two partial states are common enough to name. The first covers the lifecycle but not the review, so access is granted correctly and never revisited. The second covers the review but not enforcement, so decisions are recorded and the access survives them.