What to Ask IAM Vendors Before You Buy

Most IAM RFPs are built around a feature checklist: does the platform support SSO, does it support SCIM provisioning, does it support adaptive MFA. The honest answer from nearly every serious vendor is yes, because the baseline feature set in this market has converged. The checklist does not fail because the questions are wrong. It fails because “does it support X” and “will X actually work the way your organization needs it to” are different questions, and only the second one predicts whether the deployment succeeds.

This is a practical buyer's guide to the second kind of question, organized by the same identity domains a maturity assessment uses, because the gaps a vendor evaluation needs to surface are the same gaps an assessment is built to find. None of the vendor names involved matter as much as the category gaps that keep showing up across all of them; a platform that is strong on workforce authentication and weak on non-human credential management is a pattern, not a company-specific flaw, and the questions below are built to surface the pattern regardless of which vendor you are evaluating.

Ask by Domain, Not by Feature

Privileged access management. Ask how secrets for non-human credentials, service accounts, API keys, CI/CD pipeline tokens, are rotated, not just whether the platform has a secrets vault. A vault that stores a credential nobody rotates is a more organized version of the same problem. Ask how session recording handles a privileged session that spans multiple systems in one workflow, since a recording per system is not the same as a reviewable record of what an administrator actually did end to end.

Identity governance and administration. Ask what happens, concretely, between an HR system marking someone terminated and their access actually being revoked across every connected application, not just the primary directory. The gap between those two events is where deprovisioning risk lives, and it is frequently measured in days for any application the vendor does not have a pre-built connector for. Ask how access reviews surface entitlements that nobody can explain the business justification for, rather than just listing what a user currently has.

Customer identity (CIAM). Ask how the platform handles a user's data deletion request when that user's identity is linked across multiple systems, and whether consent state propagates to every system that consumed it or only to the identity platform's own records. This is where CIAM intersects data security, and it is the category of question a feature checklist never surfaces because “supports GDPR deletion requests” sounds complete regardless of whether it actually is.

Cloud and SaaS IAM. Ask how the platform discovers and governs identities created outside its own provisioning workflow, the SaaS application a business unit connected directly without going through IT, the service identity a developer created in a cloud console rather than through the sanctioned pipeline. “Supports SSO integration” describes the sanctioned path. The actual risk usually lives in everything that did not take that path, and a platform's value here is measured by how much of that unsanctioned sprawl it can actually see, not by how well it governs the identities that were already behaving.

Talk to Customers at Your Scale, Not Any Scale

Reference calls are a standard part of vendor evaluation, and most buyers undercut their value by accepting whichever reference the vendor offers rather than asking for one that matches their own scale and complexity specifically. A platform that performs well at 2,000 identities and a handful of connected applications can behave very differently at 50,000 identities across hundreds of applications, where performance degradation, connector reliability, and the operational burden of the platform itself all change in ways a smaller reference customer never encountered. Ask the vendor directly for a reference at a comparable identity count and application sprawl, not a reference that merely exists in the same industry vertical. If the vendor cannot produce one, that absence is informative on its own, particularly for a platform being sold as enterprise-ready.

Make the Proof of Concept Prove Something

Practitioner guidance on vendor selection consistently converges on one point: a proof of concept run against real data and real integrations is a better predictor of deployment success than any amount of demo-environment feature review, because vendor demo environments are built to make the product look finished. The test that matters is whether the platform handles your actual directory structure, your actual application sprawl, and your actual edge cases, specifically the departed contractor whose account nobody remembers creating and the service account with a name nobody can explain.

A proof of concept that only tests the happy path, a new hire gets access, a manager approves a request, tells you the product works in the condition every vendor demo is designed to show. Structure the test around your worst access-review finding from the last audit instead, and ask the vendor to show how their platform would have caught it or prevented it. If the answer is vague, that vagueness is the actual finding, not a reason to move to the next question.

Set Realistic Timeline Expectations

A 2024 survey of 327 senior cybersecurity professionals by ActualTech Media and the Cybersecurity Marketing Society found most buyers in a six-to-twelve-month purchase cycle, with the vendor evaluation and selection phase alone running three to six months for 44% of respondents. That survey covers cybersecurity purchasing broadly rather than IAM specifically, but the pattern holds for identity platforms for the same reason it holds elsewhere: a rushed evaluation skips exactly the proof-of-concept work described above, because that work takes real calendar time with real stakeholders, not a single product demo. Budgeting that timeline up front, rather than treating it as a delay to be compressed, is what makes the evaluation worth doing.

Ask for Audit Evidence, Not Audit Features

Every serious vendor will say their platform supports your relevant compliance frameworks. Ask instead for a sample report the platform would generate for an auditor asking for proof of access reviews over the last quarter, and look specifically at whether it shows what changed as a result of the review, not just that a review occurred. A platform that can prove reviews happened but not that they revoked anything is proving the wrong thing. The same evidence standard applies whether you are running the evaluation yourself or against the domains and control-level detail covered in AXIS's own control library, which documents what evidence separates each maturity level across all 37 assessment questions.

Ask the same question about integration points specifically: can the platform produce a log entry showing exactly which upstream system triggered a given access change, and how long that log is retained. During an incident, the question is never just “what access did this account have.” It is “what access did this account have on the date of the incident, and what changed it since,” and a platform that only shows current state cannot answer that under pressure.

None of this is a case against any specific platform. The major vendors in this market all cover the baseline feature set capably; where they differ is depth, evidence, and how the implementation actually lands in a specific environment, which a checklist cannot measure and a structured evaluation can. For the broader picture of how these domains combine into a defensible maturity score independent of any vendor, see The IAM Maturity Model, Explained.

Common Questions

How many vendors should we evaluate? Fewer than most RFP processes assume. A long list evaluated shallowly produces less signal than a short list, three or four realistic candidates, evaluated with a real proof of concept against your actual environment.

Should we run the RFP before or after an internal maturity assessment? Before, ideally. An assessment tells you which domain has the worst gap, which tells you what the RFP actually needs to test for instead of a generic feature list every vendor will answer the same way.

Is a longer feature list a reasonable tiebreaker? Rarely. A feature nobody on the implementation team asked about and nobody has a plan to configure is not a capability; it is a checkbox. The tiebreaker that actually predicts success is which vendor's proof of concept handled your hardest real case, not which one listed more capabilities.

What if no vendor passes every test? That is the normal outcome, not a failed search. The point of evaluating by domain and evidence rather than by feature list is to know precisely which gaps you are accepting and why, so the decision is documented rather than discovered the first time that gap matters in production.