Access governance buyer's guide: choosing IGA without over-buying

where buyers go wrong

There are two common mistakes, and they are mirror images of each other. Both show up at every size, just with different price tags.

The first is buying an enterprise IGA suite you cannot staff. These platforms are built for organizations with a dedicated identity team, a defined set of business roles, and the appetite for a six-month rollout. Drop one into a 200-person company with a two-person IT function and it sits half-configured. The provisioning engine never gets wired to your real apps. The access reviews run, but nobody trusts the data, so they get rubber-stamped. The same trap catches large companies too, just on a bigger budget: a suite scoped for a global enterprise lands in a 2,000-person firm with one identity engineer, and the gap between what the license can do and what the team can run becomes the project's whole story.

The second mistake is expecting a tool to fix a process that does not exist yet. If you have no written joiner-mover-leaver flow, no tool will invent one for you. It will automate whatever you tell it, including your gaps. A platform that provisions access fast also deprovisions slowly if you never defined what leaving looks like. Software encodes process. If the process is missing, you are paying to encode a blank.

Both mistakes come from the same root: treating governance as a purchase rather than a practice. The purchase can help. It comes second. The reason nobody owns access at most companies is organizational, not technical, and no tool reassigns ownership for you.

before you evaluate: two things first

Two pieces of work come before any vendor call, and you can do both without spending a cent. They also tell you where you sit, which decides what you should even be shopping for.

write down your joiner-mover-leaver process

Not the aspirational version. The real one. When someone joins, who creates their accounts, in which systems, based on what? When someone changes role, who removes the access they no longer need, and does that ever actually happen? When someone leaves, what gets shut off, how fast, and who checks? Write it as it works today, gaps included. Most teams discover the mover step does not exist at all. People accumulate access as they move around and never shed it.

see who has access today

Pull the user lists from your identity provider, your core apps, your admin consoles. Match them against your current headcount. You are looking for accounts belonging to people who left, accounts nobody can explain, and admin rights that spread further than anyone expected. This is the same exercise a periodic access review does, and doing it once by hand teaches you more about your environment than any vendor demo. It also tells you the size of your problem, which is the only honest input to a buying decision.

In one survey, 83% of employees said they still had access to at least one account from a previous employer (Beyond Identity, 2022, self-reported). When you run your own count, you find out whether you are better or worse than that. Either way you know, and knowing changes what you should buy.

size yourself by headcount and app estate

Headcount is a rough proxy. The number that really decides your answer is how many distinct apps hold access that matters, and how many of those sit behind single sign-on. A 60-person company with eight SaaS apps, all behind the identity provider, has a small problem. A 300-person company with forty apps, a dozen of them niche or on-premise and outside single sign-on, has a much bigger one even though it is only five times the headcount. Count your apps and split them into two piles: behind single sign-on, and not. That split predicts most of what comes next.

the category in depth

The category has four parts. They overlap, vendors blur the lines, and one constraint runs underneath all of them. It helps to separate them.

full IGA platforms

These do the most. Automated provisioning and deprovisioning, joiner-mover-leaver automation, access certification and reviews, role management, and segregation-of-duties checks that flag toxic combinations like one person who can both create a payment and approve it. They wire hire-and-fire signals from your HR system through to account creation and removal, run certification campaigns on a schedule, and enforce policy. They fit large or multi-entity organizations, high turnover that makes manual joiner-mover-leaver unsustainable, or a regulator requiring segregation of duties and recertification at scale. They do not fit a small or mid-market team with a clean app estate behind single sign-on, where the platform's strengths assume roles defined, owners assigned, and people to run them.

lightweight access-review and certification tools

These do just the periodic review. They pull access data together, route it to the right reviewer, and record who approved what. No provisioning engine. They answer the audit question, who has access and who signed off, without trying to automate granting and removing. They fit growing mid-market teams that have outgrown manual reviews but do not yet need provisioning automation, or anyone who needs evidenced certifications for an auditor. If your identity provider's built-in reviews already cover your connected apps, you may own this capability already.

the governance built into the IdP you already own

If you run Microsoft Entra, Okta, or Google Workspace, you likely already have governance features available. Entra ID Governance and Okta's governance add-on cover access reviews, access requests, and lifecycle workflows. Plenty of teams pay for these and have never switched them on. This is essentially always the first thing to turn on. It is the cheapest tool you will ever deploy, because you have already bought it. Before you evaluate anything external, find out what your current contract includes. It runs out of room when your app estate grows past what the identity provider can connect, or when you need segregation of duties and recertification it does not offer.

identity threat detection and response (ITDR)

This sits next door. Governance decides who should have access. ITDR watches for that access being misused: a dormant account waking up, a privilege escalating, a login from somewhere it should not be. The two reinforce each other. Detecting misuse matters more when you cannot perfectly prevent it, which is always. You do not need this on day one, but governance alone does not tell you when something goes wrong in real time.

the constraint underneath all of it

One thing decides whether any of this works: connector coverage for the apps you actually run. A governance tool governs the systems it can connect to. Your identity provider, your big SaaS apps, your directory, those have mature connectors. Your niche industry app, the on-premise system finance refuses to retire, the tool one team adopted last quarter, those may have no connector at all. Anything outside single sign-on stays manual no matter what you buy. The glossy platform and the lightweight tool both fail at the same wall, and it is a wall made of your own app list.

what is right for your size and situation

The honest answer scales with you.

• Lean or small (under ~50, clean app estate) · What usually fits: A written joiner-mover-leaver process, the IdP's built-in governance, and periodic manual reviews · Why: Most risk lives in the leaver gap and drifted access. Process plus built-in features close both for connected apps at near-zero new cost.
• Growing mid-market (50 to 500) · What usually fits: IdP governance plus a lightweight review tool · Why: You have outgrown manual reviews but not yet manual provisioning. The review tool answers the audit question without a heavy rollout.
• Larger or multi-entity (500 to 2,000) · What usually fits: A dedicated IGA platform · Why: Scale, multiple directories, and central role management justify automated provisioning and a real platform.
• Enterprise or heavily regulated (2,000+) · What usually fits: Full IGA with segregation of duties and recertification at scale · Why: Auditors and regulators demand evidenced, repeatable certification and toxic-combination checks that only a full platform runs well.

Read the table as a starting point rather than a verdict. Three special cases bend it:

• Many niche or homegrown apps. If a large share of access lives in apps with no connector, your real constraint is coverage, not category. The biggest platform will not govern an app it cannot reach. Size your "no connector" pile first; it may make a lighter tool plus a documented manual process the more honest answer regardless of headcount.
• Finance under DORA. Financial entities carry specific obligations around least privilege, leaver controls without undue delay, and access recertification. That can pull a mid-market firm toward stronger tooling than its size alone would suggest.
• Audit-heavy environments. If you face frequent external audits, the value of evidenced, repeatable reviews rises sharply, which can justify a certification tool earlier than the headcount table implies.

sourcing models: four ways to get there

There are four honest ways to put governance in place, matched to where you are rather than ranked against each other.

Process plus the IdP's built-in governance. Run it yourself with what you already own: a documented joiner-mover-leaver flow, periodic reviews driven by a checklist and the identity provider's features, and an owner who cares. For many small and mid-market companies this is the right answer for longer than vendors would like you to believe. It is also the foundation under every other model. A clean IT offboarding process does more for your real exposure than most software.

A lightweight review tool. Add this when manual reviews stop scaling but you do not need provisioning automation. It answers the certification question and keeps the evidence an auditor wants.

A full IGA platform. Choose this when scale or compliance forces it: high turnover, an auditor with specific demands, an app estate the identity provider cannot cover, or segregation-of-duties requirements. Buy the lightest tool that solves the actual trigger, not the broadest one in the category.

A co-managed identity-governance service. When you need the practice working and do not have the hands to set it up, a partner can design the joiner-mover-leaver flow, run the first real review, configure the governance you already own, and tell you honestly whether you need a platform at all. This is often the fastest route from a messy state to a controlled one, and it does not lock you into a license you will outgrow or under-use.

The order matters more than the choice. Process, then your existing identity provider's governance, then a tool only if a trigger demands it.

decision criteria in depth

When you do evaluate, these are the questions that separate a good fit from an expensive mistake. Score each shortlisted option out of 5, weight the ones that matter most to you, and let the table do the arguing.

• Connector coverage for your real apps · What to look for: Native connectors for the apps you actually run, honesty about what stays manual. The make-or-break. · Weight: High
• Mid-market fit vs enterprise bloat · What to look for: Built for your scale rather than an enterprise product with a smaller price tag and the same configuration burden. · Weight: High
• Time to value · What to look for: Useful output in weeks, not after a six-month implementation. · Weight: Medium to high
• Automates joiner-mover-leaver, or only reviews · What to look for: Provisioning automation versus review-only. Different products wearing similar names. · Weight: High
• Integration with your IdP · What to look for: Builds on your Entra, Okta, or Google Workspace setup. Does not become a second source of truth for identity. · Weight: High
• Segregation of duties and recertification · What to look for: Supports toxic-combination checks and recurring certification, if you need them. · Weight: High if regulated, low if not
• Data residency and EU · What to look for: Clear answer on where access and identity data is processed and stored, and under whose jurisdiction. · Weight: Medium to high in the EU
• Pricing model · What to look for: Per-identity, per-connector, or platform tiers, and how that scales as you grow. · Weight: Medium

Bring your real app list to every vendor. Ask which connect natively, which need custom work, and which cannot be governed at all. Know whether you are solving provisioning automation or review-only before you pay for the other. And if you are not regulated and have no toxic-combination risk, segregation of duties and recertification add weight you will not use.

how it is priced and the true total cost

Three pricing models dominate, and the headline number is rarely the real one. Per-identity pricing is predictable and scales with headcount, though service accounts and external users can inflate the count. Per-connector pricing is cheap if your estate is small and standard, expensive if you have many apps or need custom connectors built. Platform tiers bundle feature sets at rising price points, and the feature you need often sits one tier above the one you were quoted.

The license is the part vendors quote. The total cost has three drivers they tend to quote later, or not at all: connector build for apps without an off-the-shelf connector, which is custom engineering; professional services for rollout, which can dwarf the software for a heavy suite at mid-market scale; and the ongoing review effort, the recurring human cost of designing campaigns, chasing reviewers, and acting on results. Get the first-year total in writing, license plus services plus connector work, before you fall in love with the dashboard.

how to run the evaluation

A disciplined evaluation costs less than a wrong purchase. Run it in four steps. First, shortlist: use the size table and the scorecard to cut the field to two or three options that fit your scale and your app estate, and drop anything built for ten times your size. Second, send the same RFP questions to each and weigh the answers, especially the ones that arrive slowly: which of our actual apps connect natively, what deployment looks like at our size, whether the tool automates provisioning or only reviews, how it works with the governance already in our identity provider, where our data is processed, and the total first-year cost including implementation and connector work. Third, run a proof of concept with success criteria you define in advance: automate a joiner and a leaver across your top apps, and run one real access review with real reviewers on real data. If the connector to a core app does not exist, you find out now, for free, instead of after signing. Fourth, check references with a customer your size who deployed with a team your size, and ask what the services bill came to and what they would do differently.

traps and red flags

The demo shows the happy path. The pain lives off it.

The connector that does not exist. The platform handles your big apps beautifully. Then you ask about the niche tool your operations team lives in, and there is no connector. That app stays manual forever, which means your governance has a permanent blind spot in exactly the system that runs your core work. Find this out before signing.

The review that becomes a rubber stamp. A tool can route a thousand access decisions to a manager who clicks approve on all of them in two minutes because the data means nothing to them. Now you have certified, evidenced, audit-passing reviews that govern nothing. The tool did not cause it, but it can industrialize it. Design the review so the reviewer can actually judge.

The services bill. The implementation, connector work, role design, and ongoing tuning arrive as a services engagement that can dwarf the software. Get it in writing before you commit.

A suite that needs a dedicated administrator you do not have. Some platforms assume a full-time identity engineer to keep them healthy. If you do not have that person and are not hiring them, the platform decays into a half-configured liability. Match the tool to the hands you actually have.

There is a related trap in the pitch itself. You will hear that the tool delivers least privilege at scale. In practice, least privilege is mostly a process discipline rather than a setting you toggle. A tool can enforce roles you have defined and flag access nobody uses. It cannot decide what each person should have. That is your judgment, encoded, and the work of deciding does not go away.

where this maps to regulation

Two EU frameworks turn access governance from good hygiene into an obligation.

NIS2 sets access control expectations for in-scope organizations. Knowing who has access to what, removing it when people leave, and being able to show that you do, all sit inside its requirements. A working joiner-mover-leaver process and periodic reviews are most of the evidence you would be asked for.

DORA is sharper for financial entities. It expects least privilege, leaver controls applied without undue delay, and access recertification on a defined cadence. The phrase "without undue delay" is why the leaver step of your process cannot be a manual afterthought, and why recertification is one of the cases that justifies stronger tooling earlier than headcount alone would suggest.

In both, the regulator is asking for the same practice that should come before any platform anyway: a working joiner-mover-leaver flow and real reviews, written down and evidenced. Third-party involvement was present in 48% of breaches, up from 30% a year earlier (Verizon DBIR 2026), and a real grip on who can reach what, including the vendors and contractors in your estate, is a large part of how you keep that number from being your story.

a sequenced path: crawl, walk, run

You do not have to do everything at once. Sequence it.

Crawl. Write down the real joiner-mover-leaver process. Pull the access lists and find the accounts that should be gone. Turn on the governance features your identity provider already includes and run one manual review by hand. This costs configuration time, not a contract, and it closes the largest gaps first.

Walk. When manual reviews stop scaling, add a lightweight review tool and let the identity provider handle lifecycle for connected apps. Tighten the mover step so access sheds when people change roles, not just when they leave.

Run. When a real trigger arrives, high turnover, a regulator, an app estate the identity provider cannot cover, or segregation-of-duties requirements, evaluate a full IGA platform using the scorecard and the proof of concept above. Buy the lightest thing that solves the trigger, and only then.

Each stage is useful on its own. You can stop at any of them and still be in a better place than the platform-first buyer who skipped the first two. The one thing to take from here: get the process and the reviews working before you buy a platform. Most teams already own more governance than they use, and most have a joiner-mover-leaver gap no tool will close until it is defined.