General · 3 min read
How to Choose an Identity Integration Partner
Short answer
Choose an identity integration partner on demonstrated experience with your platform and scenario, depth in the underlying standards, a clear plan for knowledge transfer, verifiable references and independence from product sales targets; and keep architecture ownership in-house.
Key takeaways
- Ask for references from projects like yours, and call them.
- Test standards knowledge with a concrete scenario, not a slide deck.
- Contract for documentation and handover from day one.
Identity projects often need outside help. A federation rollout, a CIAM migration or a move to a new access management platform touches every application and every user, and few internal teams have done it before. The partner you pick shapes the result for years. Here is what to look for and what to keep for yourself.
What experience should a partner have?
Recent, hands-on work with your target platform and with a scenario close to yours, at a similar scale.
"We do IAM" covers a lot of ground. Workforce SSO for 2,000 employees and customer identity for 5 million users are different projects. Ask for:
- Two or three projects of the same type in the last few years.
- The names of the people who would actually work on yours, and their roles on those projects.
- What went wrong on a past project and how it was handled. A partner with no answer has either not done much or is not being candid.
How can I test a partner's depth?
Give them a concrete scenario and ask them to talk it through.
A few useful prompts:
- "Our mobile app uses the implicit flow. What would you change and why?" A good answer mentions PKCE, RFC 9700 and the system browser.
- "An app needs the user's department but our IdP doesn't release it. Options?" Listen for attribute release policy, claims mapping and provisioning, not just "add a claim".
- "How would you rotate the SAML signing certificate with 300 connected apps?" Look for metadata publishing, overlap periods and a communication plan.
- "Show me how you'd validate this token." Hand them a test JWT and see whether they check signature, issuer, audience and expiry. Our JWT Decoder is handy for the conversation.
What should the contract include?
Clear deliverables, documentation, knowledge transfer and ownership of all configuration and code.
| Item | Why it matters |
|---|---|
| Architecture and design documents | You will maintain this after they leave |
| Configuration as code where possible | Repeatable environments, reviewable changes |
| Runbooks for certificate rollover, outages, onboarding apps | The tasks that cause midnight incidents |
| Pairing with internal staff | Knowledge transfer happens by doing |
| Exit and handover terms | Avoid lock-in to one consultancy |
What are the red flags?
Guaranteed outcomes, reluctance to name people, product recommendations before requirements, and no written test plan.
Also be wary when a partner's revenue depends heavily on reselling one product. That does not make their advice wrong, but it is worth knowing. Ask directly how they are paid.
How do I compare proposals fairly?
Score every proposal against the same scenarios, staffing plan and handover terms.
Proposals are written to look complete, so compare them on a short list of things that predict success:
- Does the plan start with your scenarios, or with the product's feature list?
- Who exactly will do the work, and how much of their time is committed?
- How are risks such as certificate rollover, migration of existing users and application onboarding handled?
- What testing is included, and who signs off?
- What will your team be able to do alone at the end?
A slightly higher price for a plan that answers these clearly is usually the cheaper option over the life of the platform.
What should stay in-house?
Architecture decisions, risk acceptance, the application onboarding process and the relationships with application owners.
A partner can design and build, but your team will live with the platform, so make sure someone internal owns each decision and understands why it was made. Our guide to choosing an IAM platform helps frame the requirements before you talk to anyone.
Questions
Should the product vendor's own services team do the implementation?
Sometimes. Vendor teams know the product deeply but may be less candid about its limits. Independent integrators can be more neutral but vary widely in depth. Ask either kind the same scenario questions.
How big should the first engagement be?
Small. A short discovery or proof of concept with a fixed scope shows you how a partner works before you commit to a long implementation.
Sources
Tagged: Integration partners, Identity, IAM