The Vendor Risk Brief Your CTO Needs to See

Last updated: September 2026

Identity vendor risk comes down to three questions a decision maker can answer in five minutes: what happens to the bill as you grow, what it would cost to leave, and whether you can produce access evidence when somebody asks. If your answer to any of them is “I would have to check,” that is the finding. The ask at the end of this brief is small and specific: approve a half-day review, or decline it on the record.

This is written to be forwarded. If you are the engineer who sees the problem day to day and has no budget authority, the useful move is not building a thirty-page evaluation. It is putting one page in front of the person who signs, with a yes or no at the bottom. If you are that person, the rest of this takes about four minutes.

Why is this a one-page brief and not a research project?

Because the alternative does not get read, and because a vendor risk assessment does not need a research project to start. The three risks below are structural. They are decided by the vendor’s pricing model, their export capability, and their logging, none of which require a proof of concept to look up. A full evaluation is worth doing later, once somebody has decided it is worth doing at all.

There is a specific failure pattern this brief exists to interrupt. An engineer notices identity costs climbing, or notices there is one provider nobody fully controls, and raises it. The response is “write it up.” The write-up takes three weeks, arrives as a document, and dies in a tab. Meanwhile the renewal auto-renews. A one-page brief that ends in a decision beats a comprehensive document that ends in a reading assignment.

What are the three risks worth a CTO’s five minutes?

Pricing model risk: what happens when you double?

The question is not whether your provider is expensive today. It is which number on your growth curve the bill is attached to. Monthly active users, total users, tenants, and connections all grow at different rates than revenue, and the gap between them is the risk. A per-monthly-active-user model is comfortable at 5,000 users and a line item at 500,000, and the growth that gets you there is the growth you were hoping for.

Two specifics worth checking before a renewal. First, whether enterprise-only features you already depend on, SAML connections, audit log retention, tenant isolation, sit behind a tier you have not reached yet, which turns a feature request from your biggest customer into an upgrade negotiation. Second, whether your contract prices the next tier, or leaves it to be quoted at the moment you have the least leverage. We went through how this reads from the engineering side in our guide to whether self-hosting Keycloak is worth it in 2026.

Lock-in risk: how hard is it to leave?

Four exportable things decide this, and each is a yes or no: users including password hashes, your full configuration in a documented format, your audit logs, and a written retention window for your data after termination. One caveat before you read a refusal as bad faith: most mainstream identity platforms will not export password hashes at all, and they have defensible security reasons for that. Azure AD B2C, for one, does not export them through any API. A no there is normal, and it still costs you a forced password reset for every user on the day you move. What you are testing is whether the answers come back at all, in writing, rather than getting routed to a conversation.

The precedent worth knowing is not a horror story, it is a planning story. Microsoft closed Azure AD B2C to new customers effective 1 May 2025 and has said it will support the service until at least May 2030 (Microsoft, “Azure Active Directory B2C FAQ,” Microsoft Learn, 2026). Nothing broke. Existing tenants kept running. What changed for those customers was optionality: they now maintain a platform rather than build on one, and the teams who had mapped their configuration had three choices while the teams who had not had one. That is what lock-in risk actually looks like in practice, a roadmap decision made elsewhere that costs you flexibility rather than uptime. We worked through the full timeline and what Microsoft actually said in our Azure AD B2C end-of-sale writeup. The full checklist is in our identity provider exit plan.

Compliance-readiness risk: can you produce the evidence?

The test is simple enough to run this week: ask for a dated list of who had access to production last quarter, who approved it, and what was revoked. If producing that takes an engineer a day of clicking, you do not have an evidence problem at audit time, you have an evidence problem every time an enterprise prospect sends a security questionnaire.

ISO/IEC 27001:2022 Annex A control 5.18 expects access rights to be reviewed periodically, and SOC 2’s CC6 series covers logical access without naming a tool. Neither requires a product. Both require records that exist before somebody asks for them. The practical dependency is whether your identity provider lets audit events leave the platform into your own log retention, which is a question with a one-word answer that most teams have never asked. The event listener that makes export possible is part of core Keycloak, but how a given vendor exposes it, and on which plan, is a question worth putting to any provider including us. Our own audit log and SIEM export starts on the Launch plan, which is the sort of detail you want in writing rather than inferred.

What is the one question to put to your vendor this week?

Ask them, in writing: “Can you send us a complete export of our users including password hashes, our full configuration, and our audit logs, in a documented format, and confirm how long you retain our data after termination?”

Send it as a support request rather than asking your account manager, because you want the answer the product can actually produce rather than the answer sales would like to give. Three things can come back. A clear yes with documentation means your lock-in risk is low and you can stop worrying about this category. A partial yes, usually configuration but not password hashes, tells you a migration means every user resets their password, which is a real cost you should now know rather than discover. Silence, or a redirect to your account team, is itself a finding, and it is the cheapest one available to you.

What does a “yes, let’s review it” actually cost in engineering time?

Half a day for the first pass, and that is the whole ask. One engineer inventories which applications authenticate through the provider, which features you depend on, and what the export answer was. That produces a one-page picture of where you stand, which is enough to decide whether a real migration evaluation is warranted.

If the answer turns out to be yes, a migration is a quarter of work rather than a week, and it is worth budgeting honestly. For reference on the upper end, our Beaulieu Canada case study covers an enterprise SSO deployment with Entra ID federation that landed in under four months, which is the shape of a serious identity project with a real directory integration in it. Most reviews never reach that stage, because most reviews end with “our pricing exposure is fine and our exports work,” which is a good outcome and worth knowing for certain.

The decline is also a legitimate answer. Declining on the record, with a date to revisit before renewal, is better than an open question that resurfaces as an emergency the week a large customer asks for SSO and SOC 2 together. Our B2B SaaS readiness guide covers what that particular week looks like when you are not ready for it.

FAQ

What is a vendor risk assessment for an identity provider?
A structured check of what a provider costs as you grow, how hard it would be to leave, and whether it produces the access records your auditors and enterprise customers ask for. For identity specifically, the export question carries the most weight, because users and password hashes are the hardest thing to recreate elsewhere.

How do I know if we are locked into our identity provider?
Test it rather than reason about it. Request a full export of users with password hashes, configuration, and audit logs, in writing. Password hashes are the one most vendors refuse on security grounds, which is normal rather than a warning sign. It still means a migration forces every user to reset their password, which is the largest hidden switching cost in identity and worth pricing before you need it.

Who should own identity vendor risk, engineering or security?
Whoever owns the renewal decision, which is usually neither. The pattern that works is engineering supplying the three findings, security confirming the evidence requirement, and the budget owner deciding. The brief is short because the decision maker is usually not the person who spotted the risk, and has less context to work from.

Is open source automatically lower vendor risk?
Lower lock-in risk, not lower risk overall. Upstream Keycloak means your configuration and user data are portable and no vendor controls the roadmap. It moves the risk to operations: patch cadence, upgrade testing, availability. That trade between roadmap control and operational load is the decision worth spending a half day on.

Sources

• Microsoft, “Azure Active Directory B2C FAQ,” Microsoft Learn, retrieved 2026-09-23, https://learn.microsoft.com/en-us/azure/active-directory-b2c/faq
• Microsoft, “Microsoft Entra External ID for customers FAQ,” Microsoft Learn, retrieved 2026-09-23, https://learn.microsoft.com/en-us/entra/external-id/customers/faq-customers
• ISO/IEC 27001:2022, “Information security, cybersecurity and privacy protection: Information security management systems,” Annex A control 5.18 Access rights, retrieved 2026-09-23, https://www.iso.org/standard/27001
• AICPA, “Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy,” common criteria CC6 series, retrieved 2026-09-23, https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022