A buyer's guide to modern identity and access management

before you evaluate: see your current state, place yourself in a tier

See your current identities and access. Not a vendor's projection of what they would find. The actual list. Pull every human and non-human account from your identity provider. Match it against your HR roster. Look for accounts belonging to people who left. Beyond Identity's 2022 survey found 83% of employees said they still had access to at least one account from a previous employer, self-reported, which tells you the gap is normal, not exceptional. Then list your most-used applications and check which ones actually sit behind single sign-on versus which ones people log into directly with a password. Note where admin rights live. Note the service accounts, API tokens, and OAuth grants nobody owns.

You do not need a tool to start this. A spreadsheet and read-only access to your directory will reveal more than most demos. Every decision after this gets easier once you can name your gaps.

placing yourself in a size and maturity tier

Two readers can be the same headcount and need very different things. A 400-person company with one IdP, clean HR data, and a security hire is in a different position than a 400-person holding company stitched together from four acquisitions, each with its own directory. Size sets the rough bracket. Maturity, how much of your foundation is actually deployed, decides what you do inside it.

The brackets that follow are lean or small (under roughly 50 people, or no dedicated security hire), growing mid-market (50 to 500), larger or multi-entity (500 to 2,000), and enterprise or regulated (2,000 and up, including finance firms under DORA). Special situations cut across all of them: multi-cloud footprints, companies built by acquisition, and software houses that run heavy machine identity. Placing yourself wrong is how a small team ends up with enterprise machinery, or a large one keeps patching with process long after it needed a platform.

the category, in depth

The acronyms make this market sound more complicated than it is. Here is what each layer means, the problem it solves, when you need it, when you do not, and where it overlaps the others.

IdP and SSO. Your identity provider is the directory that holds your users and decides who they are. Single sign-on is the part that lets one login open many applications. If you run Microsoft Entra, Okta, or Google Workspace, you already own an IdP, and SSO is included. This is the foundation. Almost everything below either builds on it or duplicates a feature it already has. You need this from day one, at any size. You never outgrow it, you extend it.

MFA. Multi-factor authentication asks for a second proof beyond the password. It works. Microsoft reported in 2023 that MFA blocks more than 99.2% of account-compromise attacks. Not all factors are equal, though. SMS codes are the weakest, vulnerable to SIM swaps and interception. Authenticator app codes are better but can still be phished or relayed in real time. Phishing-resistant methods, meaning passkeys and hardware keys built on the FIDO2 standard, bind the login to the device and the legitimate site, so a fake page cannot harvest anything reusable. Everyone needs MFA. The answer should bend toward FIDO2 for admins and anyone with access to sensitive data, and your IdP almost certainly supports the stronger methods already. The work is turning them on, not buying them.

PAM. Privileged access management controls your admin accounts: who can become an administrator, for how long, and with what approval. Done well, an admin holds no standing power and instead requests elevated access for a defined window, which is then logged and revoked. You need this once admin sprawl becomes a real risk, which for most companies is sooner than they think and later than a vendor will claim. For a smaller company it can start as a process rather than a product. It overlaps the IdP, which can already do conditional access and time-bound roles in its higher tiers.

IGA. Identity governance and administration is the lifecycle layer: provisioning a new joiner's access, adjusting it when they change roles, and removing it when they leave, plus the periodic access reviews where someone confirms each person still needs what they hold. This is joiner-mover-leaver discipline made into a system. You need the discipline early. You need a full IGA suite much later, usually when headcount, app count, and audit pressure together outrun what your IdP and a quarterly review can carry.

ITDR. Identity threat detection and response watches for identity attacks in progress: a login from an impossible location, a sudden privilege escalation, a flurry of failed MFA prompts. It is the monitoring layer for identity. You need it once your foundation is solid enough that an alert means something. Buy it before the basics are in place and you get noise, not signal.

CIEM. Cloud infrastructure entitlement management right-sizes permissions inside cloud platforms like AWS, Azure, and Google Cloud, where entitlements multiply fast and quietly. If your cloud footprint is small, this is not yet your problem. If you run significant infrastructure, especially across more than one cloud, it becomes one quickly.

Machine and non-human identity. Service accounts, API keys, OAuth grants, workload identities, and the credentials your AI agents use to act. These now vastly outnumber people. CyberArk's 2025 research put machine identities at roughly 82 to 1 against human ones, with nearly half holding privileged access. Any identity decision that only counts humans is counting a fraction of the real surface. Software houses and cloud-heavy companies hit this earlier than anyone else.

The honest part the category labels hide: these layers overlap heavily, and the IdP you already pay for includes more of them than you have switched on. Many "IAM purchases" turn out to be features sitting dormant in a license you already hold. Knowing which is which is why the spreadsheet comes first.

what is right for your size and situation

• Lean or small (under ~50, or no security hire) · What to do first: Turn on MFA everywhere, prefer FIDO2 for admins. Put your core apps behind SSO. Run joiner-mover-leaver as a checklist. · What to buy: The IdP tier that includes conditional access, if you do not have it. Hardware keys for admins. · What to skip for now: Standalone IGA, ITDR, CIEM, PAM products. Process and the IdP cover you.
• Growing mid-market (50 to 500) · What to do first: Finish deploying the IdP. Formalize quarterly access reviews. Tighten leaver controls. · What to buy: A focused access-review or lightweight PAM tool once reviews and admin sprawl outgrow spreadsheets. · What to skip for now: A full IGA platform until app and headcount growth genuinely demands it.
• Larger or multi-entity (500 to 2,000) · What to do first: Consolidate directories where you can. Make provisioning and recertification systematic, not manual. · What to buy: An IGA platform, PAM as a product, and ITDR once the foundation is solid. · What to skip for now: Buying every layer at once. Sequence it.
• Enterprise or regulated (2,000+, finance under DORA) · What to do first: Map controls to the regulation. Make least privilege, recertification, and leaver controls auditable. · What to buy: IGA, PAM, ITDR, and CIEM as a coordinated program with an owner for each. · What to skip for now: Nothing structural. The risk here is fragmented tools, not too few.

special situations

Multi-cloud. If you run real workloads across two or more of AWS, Azure, and Google Cloud, CIEM matters more and earlier than your headcount suggests. Each cloud's native tools see only their own platform. The cross-cloud picture, where the over-permissioned roles and forgotten access keys hide, needs a layer that sits above all of them.

Built by acquisition or a holding structure. Multiple IdPs are the defining feature here, and the temptation is to rip them all out and standardize. That is a multi-year program. The pragmatic move is federation first: connect the directories so identity is visible and policy is consistent across entities, then consolidate where the business case is clear. A 600-person holding group can have more identity complexity than a 3,000-person single company.

Software houses. Machine and workload identity arrives earlier here than anywhere else. Service accounts, CI/CD pipeline credentials, API tokens, and the secrets that wire services together often outnumber the humans many times over before the company feels large. Treat non-human identity as a first-class concern from the start.

sourcing models

How you acquire a capability matters as much as which capability. There are four honest paths and most companies use a mix.

Use what you already own. For a lot of identity work, the right answer is to deploy your existing IdP properly and run lifecycle and reviews as internal process. No new vendor. This is the cheapest and often the most durable option, and it is the default when your IdP is underused. It is almost always the first move for lean and mid-market teams.

Point tools. A focused product that does one thing, MFA, PAM, or access reviews, when a specific gap genuinely outruns what your IdP and a spreadsheet carry. Point tools fit growing mid-market and larger companies that have one clear gap rather than a broad governance problem.

An IGA platform. A broad governance suite that handles provisioning, reviews, and policy across many applications. This fits larger and enterprise organizations with the app count, the headcount, and the team to operate it. Below that scale it tends to become shelfware.

Managed or co-managed identity service. An MSSP or VAR runs or co-runs identity for you. This fits companies of any size that lack the in-house team to operate the tooling they need, or that want the implementation done by people who have done it before. The deciding factor is team capacity as much as size. A capable 80-person team can self-manage more than an understaffed 800-person one.

the decision criteria, in depth

When you do evaluate a tool, these criteria predict whether it earns its keep. Score each shortlisted product against them. A simple scale, say 0 to 3, surfaces the trade-offs a feature list hides.

• Integration with your IdP · What good looks like: Treats your Entra, Okta, or Google Workspace as source of truth, builds on it, does not become a second directory
• Connector coverage · What good looks like: Supports your actual applications, including the long-tail and on-premise ones, confirmed in writing
• Deployment model · What good looks like: Matches your constraints, whether SaaS, self-hosted, or hybrid
• Data residency and EU · What good looks like: Data stored and processed where your GDPR and procurement rules require, clear DPA
• Pricing model · What good looks like: Predictable, matches how you grow, no surprise tiers behind core features
• Admin overhead · What good looks like: A small team can run it day to day without a dedicated specialist
• Time to value · What good looks like: First real findings from your own environment in weeks, not quarters
• Machine identity coverage · What good looks like: Service accounts, OAuth grants, and tokens in scope, not quietly excluded
• Vendor viability and support · What good looks like: Funded, stable, responsive support, a real exit path for your data

A few of these deserve a line. Integration outweighs almost everything: a tool that fights your IdP costs more in confusion than its best feature returns. Connector coverage is where demos mislead. Deployment model and data residency are procurement gates for European buyers, cheaper to ask before signing than to discover after. Admin overhead and time to value are really questions about whether the tool fits your team, which is the difference between a working control and shelfware.

how IAM tools are priced, and the true cost

Pricing in this market follows the layer. Knowing the model tells you where the meter runs and where the surprises hide.

• IdP and MFA: per-user per-month, often with the stronger features gated behind a higher tier. Cost driver: user count and which tier you need.
• PAM: per-privileged-user, or per-vault or per-managed-secret. Cost driver: how many admins and secrets you bring under management.
• IGA: per-identity, and per-identity often means every identity governed, human and sometimes machine. Cost driver: total governed identities and connected applications.
• CIEM: per-resource or per-cloud-account. Cost driver: the size of your cloud footprint, which scales fast.
• Platforms and suites: a base platform fee plus modules. Cost driver: how many modules you light up.

The license is the visible number. The real cost adds the parts that do not appear on the quote: connectors that are charged for or simply not included, professional services that can rival the first-year license on an IGA rollout, training, ongoing admin time, and year-two and year-three renewal uplift. A cheaper license with heavy services and a steep learning curve can cost more over two years than a higher sticker with neither. Total cost of ownership, not list price, is the number to compare.

how to run the evaluation

Once you know your gap and your criteria, run a disciplined process rather than collecting demos.

build a shortlist

Two or three products, no more. Use the criteria table to cut the field before you take a single demo. A tool that fails an integration or data-residency gate does not belong on the list regardless of how well it presents.

send RFP questions in writing

Get the answers on paper, not just in a demo where the comfortable narrative wins. Ask which capabilities your existing IdP already provides and what theirs adds on top; to show findings from an environment like yours, not a curated demo tenant; how long from contract to first real output; what full deployment requires from your team in people and hours; the full connector list and what happens to accounts in unsupported apps; the total first-year cost including implementation, services, and training; where your data is stored and processed and what the DPA covers; whether service accounts, tokens, and OAuth grants are in scope; and what happens to your data when you leave. The answers, and the comfort with which a vendor gives them, tell you as much as the product.

design a proof-of-concept with explicit success criteria

A POC without a pass-fail definition is just a longer demo. Write down what success means before you start. A strong test runs a real workflow end to end: provision a test joiner and confirm they get exactly the right access, change their role and confirm access adjusts, then offboard them and confirm every account is revoked, with the whole sequence visible in an audit trail. If a governance tool cannot cleanly do the joiner-mover-leaver loop on a test identity, it will not do it for your real ones. Run it in an environment that resembles yours, including a few of your awkward applications.

check references

Ask the vendor for customers near your size and situation, then ask those customers what the vendor will not tell you: what broke during deployment, what the services bill actually came to, how responsive support is when something fails at an inconvenient hour, and whether they would buy it again.

traps and red flags

A demo is a controlled environment. The cost lives in the parts it leaves out.

Connector coverage gaps. The demo shows the integrations that work beautifully. Your environment has the long-tail applications, the on-premise system, the niche tool one department depends on. Coverage gaps mean accounts the tool cannot see, which means the visibility you bought has holes you only discover after deployment. Get the full connector list in writing and check it against your real stack.

The services bill on IGA. Some products are inexpensive to license and expensive to deploy. With IGA especially, the implementation, configuration, and integration work arrive as a professional services line that can dwarf the subscription. Ask for the services estimate before you anchor on the license price.

Shelfware. The most expensive outcome is a tool that is bought, partly deployed, and then abandoned because nobody had the time to finish or run it. It still renews. This is the predictable end state of buying above your operating capacity.

Lock-in. A tool that becomes a second source of truth, or that makes your data hard to export, raises the cost of ever leaving. Confirm the exit path before you enter.

MFA exceptions that hollow out the control. Every standing exception, the executive who finds it inconvenient, the legacy app that cannot support it, the break-glass account left unguarded, is a door left open while you believe the building is locked. An MFA deployment is only as strong as its smallest gap.

where this maps to regulation

For European buyers, two frameworks turn these criteria into obligations.

NIS2. Article 21 names access control and multi-factor authentication among the baseline measures essential and important entities must put in place. In practice that means you can show who has access to what, that access is controlled, and that strong authentication is in force, the exact discipline the foundation work above produces.

DORA. For financial entities, DORA and its regulatory technical standards set specific identity and access expectations: least privilege, leaver controls, periodic recertification of access rights, and MFA on privileged and remote access. These are testable controls an examiner can ask you to evidence. A clean joiner-mover-leaver process and an auditable recertification cycle are how you answer that, which is why the POC above tests exactly those.

Both frameworks reward the same groundwork. The companies that struggle at audit are usually the ones that bought tools before they could see their access, then could not produce the evidence the tools were supposed to generate.

a sequenced path: crawl, walk, run

You do not arrive at mature identity in one purchase. You sequence it.

Crawl. See your current state. Turn on MFA everywhere, prefer FIDO2 for admins. Put your core applications behind SSO. Run joiner-mover-leaver as a written checklist. This is mostly configuration and discipline, not new contracts, and it closes the gaps that generate the most audit findings and orphaned access.

Walk. Formalize access reviews on a regular cadence. Bring privileged access under control, as process first, then as a product if admin sprawl demands it. Add visibility into OAuth grants and service accounts. This is where a first focused tool usually earns its place, picked against the criteria above.

Run. Make governance systematic with an IGA platform if your scale justifies it. Add identity threat detection once the foundation is solid enough for alerts to mean something. Bring cloud entitlements under CIEM if you run serious or multi-cloud infrastructure. Coordinate the layers under clear owners rather than letting separate teams buy overlapping tools.

Most companies are somewhere in the walk stage and being sold run-stage machinery. Knowing which stage you are in is half the buying decision. Modern identity comes down to three things: a current state you can see, a set of gaps in a sensible order, and the smallest set of moves that closes them. The tools are real and some are excellent. They are also the last decision you make, after you have mapped what you own and finished deploying it.