What to Ask Any Identity Vendor Before You Sign

Ask about the moment things break, not the moment things work

Every identity vendor's demo works. That's not a useful signal, because a demo is, by construction, the one scenario the vendor has rehearsed and controlled for. The questions that actually separate a mature platform from a well-rehearsed one are all about behavior under failure: what happens when a query is malformed, a dependency times out, a key needs rotating mid-session, or someone forgets to include a filter that should have been there. What follows is what's worth asking before a contract is signed, organized around where the answers tend to reveal the most.

None of these questions require deep technical expertise to ask, and that's deliberate: you don't need to be able to evaluate the answer against a specification to notice whether the person answering is specific and confident or vague and reassuring. A vendor's sales engineer fumbling a question about failure behavior, or redirecting to a generic security page instead of answering directly, is itself informative. The people who build a system tend to be able to describe how it breaks; the people who only sell it tend to describe how it's supposed to work.

Isolation: what happens when a boundary is forgotten

Ask directly what happens when a piece of code (a new endpoint, a background job, an internal tool built in a hurry) queries data without specifying a tenant. If the honest answer involves code review catching it, that's a human backstop, real but fallible. If the isolation is enforced independent of the query, forgetting should produce nothing or an outright failure, not a silent leak into another tenant's data. This is worth asking even if the vendor's marketing already says 'isolated': that word is close to universal and tells you nothing about the mechanism behind it.

Credential storage: what's actually kept, and how

Ask exactly what's stored when a user sets a password, and insist on a plain answer: credentials should never be stored in a form that can be reversed back into the original value, only as the output of a one-way function designed to resist offline guessing. A vendor that can retrieve or display a user's original password at any point, for any reason, has already failed this question regardless of what else they say. It's also worth asking what the vendor's breach notification commitment actually is: not whether they've had one, but what triggers a notification, and how quickly it's promised to happen once something is confirmed.

Key rotation: does it need a maintenance window

Ask how signing keys rotate, and specifically whether rotation requires coordinated downtime or a maintenance window. A system that needs to pause to rotate a key is telling you rotation was designed as an exceptional event rather than a routine one, which usually means it happens less often than it should, because every rotation is expensive. Rotation with bounded, predictable overlap between old and new keys (so verification never has a gap) should be routine enough that a vendor can describe the cadence without checking.

Session and token lifetime: does revocation actually reach the client

Ask what happens when a session needs to end right now: a stolen device reported, an employee offboarded, a credential known to be compromised. The important distinction is whether revocation is enforced centrally, independent of what the client holds, or whether it depends on a token simply expiring on its own schedule. A system where 'revoke' really means 'wait for the token to expire on its own' is not revocation in any meaningful sense during the window that token remains valid, and that window is exactly when a stolen credential does the most damage.

Rate limiting and abuse protection: per what, exactly

Ask how login, password reset, and one-time-code delivery endpoints are protected against automated abuse, and specifically whether protection is per-IP only. Per-IP limits are trivially bypassed by any attacker with access to a botnet or a residential proxy pool, which describes most credential-stuffing operations running today. Protection that also applies per-account or per-identifier (so an attacker can't just spread the same attack across enough addresses to stay under any single IP's limit) is a meaningfully different guarantee, and it's worth asking the vendor to be specific about which one they actually run.

Retention and deletion: what happens when data should be gone

Ask what happens to a user's data after an account or a tenant is deleted, and get a specific timeline rather than a general assurance. 'We take data handling seriously' answers a question nobody asked; 'deletion requests are processed within this many days, and here's what remains in backups until they roll off on their own schedule' answers the one that matters. It's also worth asking about the records a vendor is likely to want to keep regardless of a deletion request (security and audit logs, typically) and whether that retention is itself bounded and disclosed, or open-ended by default. A vendor that has thought about deletion in advance can describe the mechanism without hesitation. A vendor that hasn't will answer in policy language instead of specifics, which is itself the answer.

Incident communication: what you'll actually be told

Ask what happens on the vendor's worst day, from your side of the relationship. What's the process for notifying you if something goes wrong that could affect your tenant specifically, versus a general status update everyone gets? Is there a named channel for security disclosures, and does reporting an issue yourself get a human response, or a ticket number and silence? A vendor's incident communication commitment is easy to overlook while everything is working and is the single thing you'll care most about the one time it doesn't. It's worth asking to see the actual process documented, not just hearing that one exists.

What they won't promise, and why that's a good sign

This one is counterintuitive: ask what the vendor refuses to commit to, and pay attention to whether they have an answer. A vendor with a published ceiling on something (a session lifetime, a rate limit, a retention window) and a stated reason for where that ceiling sits has clearly thought about the trade-off involved. A vendor that claims no limits anywhere, or answers every capacity question with 'as much as you need,' either hasn't examined the question or doesn't want to commit to an answer that could later be used against them. Neither is reassuring. The vendor with a number and a reason is the one that's actually done the analysis.

Get the answer in the product, not just the deck

Wherever possible, ask to see the behavior instead of hearing it described. Can you trigger a forced session revocation in a sandbox and watch propagation happen? Can you see a rate limit actually fire against a test account? Can the vendor show you, concretely, what a cross-tenant access attempt does, rather than tell you it's prevented? A sales conversation can describe any architecture convincingly. A sandbox either behaves the way it's described or it doesn't, and that gap (between the description and the demonstrated behavior) is where the real evaluation happens.

Bring the list, don't wait for it to come up

In practice, none of these questions come up unprompted in a sales process, because none of them are flattering to lead with. A vendor is going to walk you through what the product does well; it's not going to volunteer what happens when its own dependency goes down, unless asked directly and specifically. That asymmetry is normal and not a sign of bad faith: it just means the burden of asking sits with the buyer. Bringing a written list into an evaluation call, and going through it item by item rather than accepting a general answer to the first one, changes the conversation from a pitch into an actual technical review, which is the only kind of conversation that reveals whether a vendor's security claims are backed by architecture or by confidence.

None of this is exotic

None of these questions are exotic, and a mature identity vendor should be able to answer all of them specifically, quickly, and without needing to check with an engineer first. The vendor that can't is telling you something true about how well they understand their own system, regardless of what their security page says.