How to choose an IAM implementation partner

Identity programs rarely fail in production. They fail months earlier in the selection meeting, when someone picks a partner off a slide deck. The vendor logo on the proposal tells you very little. The single best predictor of a governance program that works is whether the people who will actually build your system have built one like it before, and can prove it. Everything else in this guide follows from that one test.

A caveat before the checklist: sometimes the right answer is not a boutique partner at all. If you have a standing identity team with product-certified engineers and a multi-year roadmap, in-house delivery keeps knowledge where it belongs. If your program spans forty countries and needs an army, a large SIdefinitionShort for systems integrator. It's a large consulting firm that builds and connects technology for clients, and usually has a big bench of staff.'s bench is a genuine advantage. This guide is for the majority in between: buyers who need deep product expertise for a defined program and can't afford to discover, twelve months in, that they bought shelfwaredefinitionSoftware that was bought and paid for but never put to real use..

Every partner page lists the same vendor logos. What you want is certified, named staff on the specific products you're deploying (SailPoint, CyberArk, Entra, whatever your stack is), and confirmation that those named people are the ones on your engagement. The oldest trick in services procurement is resume padding. The principal architect wins the deal and rotating juniors deliver it. Ask, verbatim: "Which of the people in this proposal will be on the project in month six, and what is your substitution policy?" A good partner answers with names and a contract clause. A bad one answers with an org chart.

References work the same way. "We have done fifty implementations" is marketing. "Call this identity lead at a company your size, on your product, and ask what went wrong" is evidence. Insist on at least two named references that you pick from a list, rather than the two happiest clients somebody pre-selected for you. Be skeptical of the partner-of-every-vendor firm, too. A consultancy that resells eight competing identity suites has a commercial reason to recommend whichever one carries the best margin this quarter, whether or not it fits your estate.

The most expensive words in identity are "we'll size it during the project." ConnectordefinitionThe integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app. counts, authoritative-source quality and role-model maturity vary so much between organizations that any implementation quote produced before a structured discovery is fiction. Usually it's optimistic fiction, corrected later by change orders. The clean pattern is a short, fixed-price discovery: inventory the applications, profile the source data, sketch the role modeldefinitionThe set of business roles and the access each one grants, used to assign access by job instead of one permission at a time., and only then price the build. It costs weeks and saves quarters. If a partner resists (if the license order and the implementation SoWdefinitionShort for statement of work. That's the contract document that says what a partner will deliver, by when, and for how much. arrive stapled together), that is the clearest red flag in this business.

Discovery is also where you learn who actually shows up after the sale. Watch who the partner sends to the discovery workshops: if it is the same architects proposed for delivery, the firm is serious. If discovery is delegated to a sales engineer while "the delivery team forms later," you have already met the substitution policy in action.

The goal of a good implementation partner is to become unnecessary, and that has to be in the contract. Make runbooks and design docs deliverables with acceptance criteria. Use paired delivery so your engineers commit code alongside the partner's. Name the handover milestones, and write exit terms that survive a mid-project dispute over who owns the configuration, the pipelines and the custom connectors. Ask, verbatim: "Describe the last engagement you exited. What did the client's team run without you on day one?" Partners who profit from permanent dependency can't answer that specifically. The ones worth hiring have the story ready, because the exit was the plan all along.

Exit terms are also where you find out who shows up after go-live. Governance doesn't stop there. Connectors break when applications upgrade, certification campaigns need tuning, and joiner-mover-leaverdefinitionThe work of granting access when people start, changing it when they move roles, and removing it when they leave. exceptions pile up. Ask what the post-sale model actually is: a named support engineer who worked on your build, or a ticket queue routed to whoever is free. Ask what happens when a connector fails during a certification campaign, and get the answer as an SLA instead of an assurance. Plenty of firms deliver well and support badly. You rarely see that in the proposal, but you always see it in the contract's support schedule, so read that before the pricing page.

# score each 0-2 · below 8 total, keep looking
named_certified_staff: on YOUR products, contractually locked
references: 2+ named, chosen by you
discovery: fixed-scope, before license spend
quote_before_role_model: red flag: walk
partner_of_every_vendor: red flag: ask whose margin wins
exit_terms: runbooks, paired delivery, handover milestones
✓ verify the people · ✓ price after discovery · ✓ plan the exit