Identity and access management (IAM) is the system that decides who can sign in and what they can do once they are in, while identity governance and administration (IGA) is the layer on top that records who should have access, who approved it, and proof that it was removed when it stopped being needed. IAM answers “can this person authenticate and be authorized right now?”, and IGA answers “should this person still have this access, and can we show someone why?”. For a SaaS company with 10 to 500 people, most of what IGA delivers can be reached with a well-run identity provider (IdP) and a quarterly routine, and a dedicated IGA product becomes worth buying when the number of apps, auditors or access requests outgrows that routine.
This post defines both terms in plain language, lists the building blocks that make up IGA, compares the two side by side, and then gets practical: when a growing team needs an IGA product, when good hygiene is enough, and how to do a light version of IGA on managed Keycloak, the open-source identity server behind our identity management as a service. It is written for the engineer or IT lead who has been handed a question like “who has access to production, and how do we know?” and needs to decide what to build or buy.
What is identity governance and administration (IGA), and how is it different from IAM?
IAM is the day-to-day machinery of identity. It stores user accounts, authenticates people (passwords, MFA, passkeys, SSO), issues tokens to applications, and enforces which roles or groups can reach which resources. If you have read our explainers on what an identity provider is and what identity management as a service (IDaaS) is, you already know the IAM side: it is the thing that sits in front of your apps and says yes or no to a sign-in.
IGA is the management and evidence layer around those decisions. The “governance” half is about policy and oversight: who is supposed to hold which access, and whether what exists matches that intent. The “administration” half is about the work of changing access: creating accounts, assigning entitlements (the specific permissions an account holds in an application), and removing them. In one line each:
- IAM answers who can sign in and with what.
- IGA answers who should have access, who approved it, and whether there is proof it was removed.
Analysts and vendors define IGA in slightly different words, but the definitions above line up with what the products in this category actually sell: lifecycle automation, request and approval workflows, access certification campaigns, policy checks and audit reporting.
What are the building blocks of IGA?
Most IGA products, and most homegrown versions of it, are made of the same five parts. Knowing them helps you judge which ones you need.
Joiner, mover, leaver lifecycle
A joiner is someone who starts, a mover is someone who changes role or team, and a leaver is someone who departs. The lifecycle part of IGA makes access follow those events automatically: a new engineer gets the engineering baseline on day one, a person who moves from support to finance loses support entitlements and gains finance ones, and a leaver loses everything on their last day. The mover case is the one most often missed, because nobody files a ticket to remove access that a person no longer needs. Our user provisioning explainer covers how accounts get created and removed, and JIT provisioning versus SCIM explains why creating an account at first login is not the same thing as managing its whole life.
Access requests and approvals
When someone needs access beyond their baseline, there should be a record of the request, the reason, the approver and the date. A good workflow routes the request to the right owner (the application owner or the person’s manager), applies an expiry where that makes sense, and applies the change automatically after approval so that nobody has to remember to do it.
Access reviews and certification
An access review, also called a certification or recertification, is a recurring check in which a named person confirms or revokes each permission held by the people they are responsible for. It is the control that catches accumulated access: the contractor who still has production read, the manager whose old team’s folder was never removed. Our post on access certifications for AI agents on Keycloak walks through how a review works on the objects Keycloak already has, and the same approach applies to human users.
Separation of duties and policy checks
Separation of duties (SoD) is a rule that certain combinations of access should not sit with one person, for example the ability to both create a payment and approve it. IGA products let you write those rules once and flag or block assignments that break them. Smaller teams usually express the same idea as a short written list of forbidden role pairs that a reviewer checks by eye.
Audit evidence
The last block is the record itself: who requested what, who approved it, when it was granted, when it was removed, and the outcome of each review. Auditors and enterprise customers usually want to see evidence that a policy was carried out, not only the policy document, and producing that evidence without a scramble is a common reason teams adopt IGA.
IAM vs IGA: how do they compare?
| IAM | IGA | |
|---|---|---|
| Question it answers | Can this person sign in, and what may they do right now? | Should this person have this access, who approved it, and was it removed on time? |
| Typical owner | Platform or security engineering | Security, IT or compliance, often with engineering support |
| Main data | Accounts, credentials, sessions, tokens, roles and groups | Entitlements across apps, approval records, review outcomes, policy rules |
| Typical tools | Identity provider, SSO, MFA, directory | Governance workflows, certification campaigns, connectors to many apps, reporting |
| Runs | In real time, on every sign-in | On a schedule or on events: requests, reviews, joiners and leavers |
| When you need it | From your first customer-facing login or internal app | When access decisions must be provable across many apps and people |
The two are not alternatives. IGA depends on IAM for enforcement, because an approval only matters if it results in a change in the IdP. IAM depends on IGA, or a manual substitute, for confidence that the access it enforces is still the right access.
When does a SaaS team need an IGA product?
For a 10 to 500 person company the answer depends on how many apps you run and how often an auditor or enterprise customer asks for access evidence, and these signals tend to push a team toward a dedicated product:
- Many apps without a central IdP. If access is granted separately inside dozens of tools, there is no single place to review it, and you need connectors that read entitlements from each app.
- Frequent access requests. When approvals arrive weekly or daily and a spreadsheet or chat thread has become the system of record, a workflow tool saves real time.
- Formal audit pressure. Reviews that must be run quarterly, with evidence for every reviewer decision, are tedious by hand once headcount and app count grow.
- Regulated data or SoD requirements. If your rules forbid certain combinations of access, you want automated checks rather than reviewers’ memory.
- Contractors, agents and service accounts that change often and have no HR record to trigger offboarding.
The signals pointing the other way are just as common in a team under 100 people: a single IdP behind most apps, a small number of roles, a manager who can name everyone’s access, and an audit scope that a quarterly review of a few exported lists can cover. In that situation, good IAM hygiene gets you most of the benefit, and the cost of an IGA product (typically licensed per identity, see the pricing section below) buys features you would not use yet.
What does good IAM hygiene look like before you buy IGA?
Treat the identity provider as the foundation. Four habits do most of the work:
- Put SSO in front of every app you can. Access that is visible in one place is easier to review, and apps outside SSO are the likeliest place for forgotten accounts to build up.
- Grant access through groups and roles, not individual exceptions. A group named for a team or function, mapped to roles in each app, turns “what can Priya reach?” into “which groups is Priya in?”. Our role-based access control feature page describes the model.
- Use SCIM for the account lifecycle. SCIM (System for Cross-domain Identity Management) is the standard protocol by which an HR system or upstream directory creates, updates and disables accounts in another system. It makes leavers disappear from the IdP when they are marked as leavers at the source, so offboarding does not depend on someone remembering. See SCIM provisioning for how that works with us.
- Keep the event stream. Sign-in events and administrative change events are the raw material of audit evidence, and they only help if they are switched on, retained and exportable before you need them. The audit logs feature and our complete guide to Keycloak auditing and event logging cover the practical side.
With those four in place, a quarterly review usually becomes a routine task and not a project, which is the point at which you can judge fairly whether a product would save enough time to justify its price.
Can you do light IGA on managed Keycloak?
Yes, for the parts that depend on your own identity provider and a modest number of apps. Here is how each building block maps onto what Keycloak 26.x provides, and where the gaps are.
| IGA building block | What Keycloak 26.x gives you | What you add yourself |
|---|---|---|
| Joiner, mover, leaver | Native SCIM API, supported since Keycloak 26.8 and inbound only | A source of truth (an HR system or upstream directory) that pushes changes |
| Access requests and approvals | Groups, roles and the Admin REST API as building material | A workflow, since Keycloak ships no request and approval UI |
| Access reviews | Group membership and role mappings you can list through the Admin REST API | A recurring routine and a place to record reviewer decisions |
| Separation of duties | Roles and groups you can inspect | A written rule and a check against exported role mappings |
| Audit evidence | User events and admin events, with retention and event listener options | Export to storage you control, and a habit of keeping review records |
Groups and roles. Model access by function. Create groups per team, attach realm or client roles to those groups, and avoid assigning roles directly to individual users except for documented exceptions. That keeps the review question simple, and you can list members of any group through the Admin Console or the Admin REST API.
Admin events. In the Admin Console, open Realm settings, then the Events tab, and use Admin events settings to save admin events. Admin events record changes made through the console or the Admin REST API, such as a user being added to a group or a role mapping being created, which is the “who granted this and when” half of the evidence. The Include representation toggle stores the full body of each changed resource, which helps reconstruct what changed but increases storage, so enable it with an export target in mind. Admin events are separate from user events, which record sign-ins, and each has its own retention setting.
SCIM. Keycloak 26.8.0 promoted the native SCIM API from preview to supported and enabled the feature by default, but each realm still has its own SCIM API toggle under Realm settings. It lets an upstream system such as Entra ID, Okta or an HR platform create and update users and groups in Keycloak. It receives changes and does not push them to other applications, so it covers the “identity provider is correct” side of the joiner, mover, leaver lifecycle and not the deprovisioning of accounts inside downstream apps that sit outside SSO. We cover the details and limits in Keycloak 26.8 SCIM API: supported and on by default.
Access request workflow. Keycloak does not include an approval workflow, but it exposes everything you need to build one with custom required actions, group membership changes and the Admin REST API. Our tutorial on identity governance workflows with automated access request and approval shows the pattern end to end, including how admin events become the audit trail for each approved change.
This setup is deliberately light. It will not discover entitlements inside applications that manage their own permissions, it will not run reviewer campaigns with reminders and escalation, and it will not evaluate separation of duties automatically. It does cover the large share of a small company’s governance needs that live in the IdP, which is where an access review spends most of its time.
How does IGA pricing work, and why does it matter?
We will not quote vendor prices, but the pricing model is useful to know when you compare options. IGA products are commonly licensed per identity (per employee, contractor or sometimes per account) and often add charges per module such as lifecycle, access requests or certification. The cost therefore rises with headcount and with each capability you switch on, and a company that grows from 100 to 400 people sees the governance bill move with it.
Identity provider pricing varies as well, and some plans are per monthly active user. Whatever you choose, check which identities count toward the bill (customers, employees, service accounts), because IGA mostly governs the workforce and an IdP often serves customers as well, and the two counts can differ a great deal for a B2B SaaS company.
Frequently asked questions
Is IGA part of IAM?
Usually yes, as a broader category. IAM is the umbrella term for managing identities and their access, and IGA is the governance and administration discipline within it, focused on policy, approval and proof. In purchasing terms they are often separate products, because an identity provider handles authentication and access enforcement while an IGA tool handles reviews, requests and reporting across many systems.
Do I need IGA for SOC 2?
Not necessarily as a product. SOC 2 is an attestation against the AICPA Trust Services Criteria, and it expects your logical access controls (how access is granted, reviewed and removed) to operate and to leave evidence, but it does not prescribe a particular tool. Many small companies satisfy this with SSO, a group-based access model, offboarding steps and a dated quarterly access review, and our post on choosing SOC 2 Type 1 or Type 2 first explains how auditors test those controls. Ask your auditor what evidence they will sample before you decide.
What is the difference between IGA and PAM?
Privileged access management (PAM) controls and records the use of high-risk accounts such as administrators, root credentials and production database access, typically through vaulting, session recording and time-limited elevation. IGA governs the broader question of who should hold access of every kind and whether that access was approved and reviewed. The two overlap, since privileged access is something you also want reviewed, but PAM focuses on how powerful access is used and IGA focuses on whether it should exist.
Is IGA the same as an access review?
No. An access review is one building block of IGA, the periodic check that confirms or revokes existing access. IGA also includes lifecycle automation, request and approval workflows, policy rules and the audit record that ties them together.
What should you do next?
Start by writing down where your access decisions live today: which apps sit behind your IdP, which groups map to which roles, and who approves exceptions. Turn on admin events and retain them somewhere you control, put leavers on an automated path with SCIM or a checklist tied to the HR record, and run your first dated access review on the group list for your most sensitive application. If those habits stay manageable as you add people and apps, you probably do not need an IGA product yet, and if they start to take more time than the product would cost, you will have the data to choose one based on your real workload.