Evaluating Systemically Critical IAM Vendors as Infrastructure

Observations

A feature-RFP asks whether a product has a capability. An enterprise that depends on an IAM vendor needs to know which identity populations the vendor holds, which controls it delivers over each, how the identities beneath those controls are bound, and who builds and runs each part. The observations below explain why that shift has become urgent.

Breadth hides depth. In CAI’s assessment of three leading converging platforms, every one holds devices, workloads, and organizations in some form. Yet device governance sits in endpoint management, workload identity rests largely on stored credentials, and organizations are configured tenants rather than verified legal entities. A feature checklist scores holding a population and governing it the same way.
The decisive questions are the ones every leading platform answers weakly. Cross-application segregation of duties, shared signals that cross the vendor’s own boundary, and verification of organizations as legal entities scored low at every converging platform CAI assessed. Protocols are standard everywhere, but the authorization, shared-signals, federation-trust, and workload-identity standards that would make policy portable and evaluation continuous remain absent or partial,¹ so “do you support standards” hides the cost of exit. A vendor that can answer these questions well is the outlier, and public evidence is thinnest exactly where systemic risk concentrates.
Criticality follows position and operation, not category. A specialist that sits in the authentication, privilege, or authorization path can stop as much of the estate as a converging platform. When the vendor operates the service, responsibility for the configuration and identity data inside the tenant usually stays with the enterprise, and few RFPs ask how that configuration is recovered.

Position

Where CAI stands on how an enterprise should evaluate the IAM vendors it depends on.

Classify every IAM vendor by systemic criticality, and decide realization, operation, and exit before signing. Scale scrutiny to the share of your coverage surface the vendor holds, anchors, and operates, not to its size, market share, or category. For every vendor-operated instance, name the internal owner, the controls the enterprise retains, and the cost of leaving.
Evaluate fit instance by instance, binding first. Record for each instance whether the vendor delivers it natively, with your build, or with a complementary capability, qualified by your enterprise profile. Ask how identities are bound before asking what controls do, because no control is more correct than the identity beneath it. Reject blended scores.
Require an evidence class for every answer. Score announced, preview, and roadmap capabilities as not delivered, whoever or whatever wrote the response.

Strategic Context

Some IAM vendors have become infrastructure. Their position, not their category, decides how deeply they must be evaluated.

A vendor that holds the workforce directory, decides requests at runtime, brokers privileged sessions, or issues workload credentials sits beneath many control-and-coverage instances at once. When such a vendor fails, is compromised, or is replaced, the effect does not stay inside a product category; it propagates to every instance that depends on it.

Regulators have started to name this kind of concentration, but at a different altitude. The European Supervisory Authorities published their first list of critical ICT third-party providers under the Digital Operational Resilience Act in November 2025, assessing each provider on systemic importance, support for critical or important functions, and substitutability.² HM Treasury made the first designations under the United Kingdom’s critical third parties regime in July 2026.³ Both regimes designate at provider and sector level, from the supervisor’s vantage point. Neither tells an enterprise which of its own IAM vendors is critical to it.

Supplier-risk frameworks do not close the gap either. NIST SP 800-161r1 and CISA’s Secure by Demand guidance give buyers sound questions about a supplier’s security practice, such as how it authenticates, develops software, discloses vulnerabilities, and manages its own supply chain.⁴ Those questions belong in every IAM procurement, but none asks whether the vendor’s coverage fits the buyer’s control architecture. That is the question this brief addresses.

CAI View A systemically critical IAM vendor is one whose failure, compromise, degradation, or exit would propagate across a material share of an enterprise’s coverage surface, because it holds, operates, or anchors identity infrastructure that many control-and-coverage instances depend on. Criticality is a property of the vendor’s position in a particular enterprise’s architecture, not of its size, market share, or category.

Five drivers set a vendor’s criticality (Table 1). They borrow the logic of the regulatory regimes, with substitutability and support for critical functions carried over directly, and add what those regimes cannot see from outside the enterprise: where the vendor sits in the binding and decision path, and who can recover its configuration.

Table 1. Drivers of systemic criticality

Driver	What it measures	What raises it
Breadth	Share of the enterprise’s control-and-coverage instances the vendor holds or delivers	More constituencies held as subjects; more control categories delivered over each
Position	Whether the vendor sits in the binding or decision path	Authentication, runtime authorization, privileged access, identity data, or proofing for many instances
Operation	Who operates the capability, and who can recover it	A vendor-operated service whose configuration the enterprise cannot restore independently
Substitutability	Cost and time to replace the vendor	Proprietary policy language; console-only configuration; no standard signal or authorization interface
Blast radius	Reach of an outage or compromise	One administrative plane across constituencies; dependent systems that fail closed, or fail open without notice

The drivers resolve into three levels, and each level sets how much of the question set a vendor must answer (Table 2 and Figure 1).

Table 2. Criticality levels and the questions each requires

Level	When it applies	Questions the vendor must answer
Systemically critical	Failure or exit would propagate across a material share of the coverage surface	All ten every-vendor questions; every constituency row the vendor claims; the estate questions your profile triggers. Recovery, revocation, and export are tested before signing, not only answered.
Significant	Failure would degrade several instances, with workable fallbacks	All ten every-vendor questions; the constituency rows for the instances the vendor will carry
Contained	Failure is confined to one instance with a tested fallback	Questions V1 to V6; the constituency rows in scope

Watch-Out A specialist is not contained because it is small. An authorization decision point that every request crosses, or a vault that every privileged session depends on, can stop more of the estate than a converging platform’s portal. Criticality follows the dependency path, not the invoice.

Figure 1. Vendor criticality tiers, showing how the five drivers set the level and how the level sets the depth of scrutiny

Evaluating Vendors by Control Coverage

The approach in brief. The IAM Root Document (IAM-RD-01), Navigating IAM Market Evolution (IAM-LB-MS-01), and the Foundation Reports set out the method in depth.

Evaluating a vendor as infrastructure means placing it on the enterprise’s control-and-coverage matrix rather than on a feature list (Figure 2).

Figure 2. The feature question and the coverage questions, showing how two identical feature answers resolve to different outcomes for one instance

The unit of evaluation is the instance: one control category applied to one identity constituency. The control categories are governance (admin-time), runtime (request-time), and observability (after-the-fact). The constituencies are workforce, customer, partner, device, workload, AI agent, and organization (Figure 3). Six ideas carry the evaluation.

Held or acted on. A vendor holds a constituency when it manages that population as a first-class subject, with its own identity object, lifecycle, and binding. It acts on a constituency when it brokers access for it, consumes attributes about it, or asserts trust for it without holding it. Breadth counts the populations held, not how well they are controlled.
Three outcomes per instance. An instance is delivered natively, by configuring the product; with your build, where enterprise-authored parts complete it; or with a complementary capability, where another product must be sourced alongside.
Profiles qualify the outcome. The same platform earns different outcomes in different estates. Four enterprise profiles (baseline; regulated and complex; hybrid estate; high assurance) qualify each outcome without changing what the vendor delivers.
Binding sets the ceiling. Each identity reaches the platform unbound, asserted, sourced, evidenced, or sustained (Identity and Access Substrate, IAM-F-SUB-01). No control can be more correct than the identity beneath it, and configuration does not fix a weak binding.
Realization and operation are separate decisions. Each instance is built, implemented, or blended, and is operated by the enterprise or by a vendor (Navigating IAM Market Evolution, IAM-LB-MS-01). Accountability stays with the enterprise whichever way the instance is delivered.
Posture and evidence decide how far to trust the answer. Controls authored as code in the enterprise’s repository can be reviewed, tested, and reproduced; console-bound controls cannot. Every answer carries an evidence class (demonstrated, documented, or claimed) and a status (generally available, preview, or announced).

Figure 3. The control-coverage map for an illustrative vendor, with a fit outcome for each instance and the binding, realization, operation, and delivery posture around it

The output is a coverage map, not a score: for each instance the vendor will carry, an outcome, its qualification by profile, and the evidence behind it. These questions test what a vendor can deliver. Whether the enterprise then operates the resulting controls well is a different measure, set out as operability bands in the Identity and Access Governance Controls (IAM-F-GOV-01), Runtime Controls (IAM-F-RTM-01), and Observability Controls (IAM-F-OBS-01) Foundation Reports. The two should never be read against each other.

The New Reality: AI in Vendor Evaluation

AI now sits on both sides of the RFP, and inside the estate being evaluated.

Proposal teams now draft RFP responses with generative AI as a matter of routine, and procurement teams increasingly use the same tools to read them.⁵ The cost of a plausible, complete-sounding answer to any feature question has fallen close to zero. A checklist that once separated vendors by the effort of answering it now returns uniform, confident prose from all of them.

The evaluation side compounds the problem. Research on language models used as evaluators documents position, verbosity, and self-enhancement biases,⁶ and finds that evaluators score text more favorably when it is more familiar to them, measured as lower perplexity.⁷ An AI-drafted answer screened by an AI evaluator is structurally advantaged whether or not it is true.

In CAI’s assessment, the response is not to keep AI out of evaluation but to change what is being evaluated.

Ask for artifacts, not assertions. Every question in this brief names the evidence that would settle it, such as a configuration file, a conformance result, a documented boundary, or a tested restore.
Use AI to grade evidence, not prose. AI is well suited to checking whether an answer cites an artifact, whether the artifact says what the answer claims, and whether a capability is generally available. It should never score fluency, tone, or length.
Treat announced, preview, and roadmap capabilities as not delivered. A model will summarize a roadmap as capability unless it is instructed otherwise.
Count agents as a constituency. The same shift brings AI agents into the estate, acting with delegated authority across tools. Every vendor should now answer for them (questions AG1 to AG5).

CAI View The fluent answer has lost its value as a signal. For vendors, evidence becomes the differentiator: a vendor that can show a conformance result, a code-authored policy, or a tested recovery separates itself from one that can only describe them. For enterprises, an evaluation that rewards prose now rewards the model that wrote it.

Questions Every Vendor Must Answer

Ten questions that apply whatever the vendor’s archetype or the constituencies it claims.

Each table in this section and the next gives the question and the evidence that would settle it. The feature-RFP and the supplier-security questionnaire stay in place; these questions add what those instruments miss.

Table 3. Questions every vendor must answer

ID	Question	Evidence to request
V1	For each constituency that you claim, do you keep it as a subject with its own lifecycle and binding? Or do you only give access for it, use attributes about it, or trust what another system says about it? Which production customers show this?	The data model and lifecycle documentation for each constituency. Named production references.
V2	For each constituency, what is the strongest binding that you support? Is it a record that a person typed? Is it a link to an authoritative system? Is it evidence that you capture at binding? Or do you confirm the binding again over time and keep the evidence?	The binding flow for each constituency. The proofing or attestation formats. How frequently you confirm the binding again.
V3	For each control bundle, which parts does your product supply? Which parts must we build? Who operates each part, you or us?	A shared-responsibility matrix for each bundle. A list of the components that the customer must write.
V4	Which controls can we write, test, and deploy again from our repository, as the source of truth? Which controls can we only export? Which controls are only in the console? Include your newest capabilities.	Infrastructure-as-code coverage for each bundle. A list of the controls that are only in the console. How you find drift.
V5	For each standard that you claim, is it first-class, supported, emerging, or on your roadmap? Which roles do you implement: issuer, consumer, transmitter, or receiver? Which conformance or interoperability result shows this?	Conformance certificates. Interoperability results. The event types and profiles that you support.
V6	For each capability, is it available now, in preview, or only announced? What is the evidence: a demonstration, code, published documentation, or only your statement? For each gap, what is necessary to close it: a configuration change, a dated roadmap item, or an architecture change?	Dates of general availability. Release notes. A demonstration. For each gap, the type of change that closes it.
V7	Which source is authoritative for each attribute that your decisions use? How do you correlate identities across sources? Does your data model prevent or find duplicate identifiers, orphaned accounts, identifier collisions, and reused identifiers?	A map of attribute authority. Correlation rules. Reports of duplicate and orphaned accounts.
V8	Which of our instances stop or degrade if your service is not available? Can you operate as a broker, or as a secondary provider, with another provider?	A map of dependencies and failure modes. The design of the degraded mode. Root-cause reports for past incidents.
V9	If our configuration becomes corrupt, or if someone changes it with malicious intent, can you restore it to a point in time? Do the object identifiers stay the same? Is this your responsibility or ours?	The restore procedure. The date and result of the last restore test. A statement of responsibility.
V10	Which standards carry your policy and your signals, not only your protocols? If we leave, what can operate on another platform, and what must we write again?	Export formats. Policy portability. A migration reference.

Questions by Control Coverage

Thirty-one questions across the seven identity constituencies, each tagged by the control area it tests: governance, runtime, observability, or the binding beneath them.

Only questions that separate vendors appear here. Capabilities every leading platform delivers at par (such as single sign-on, multifactor and phishing-resistant authentication, adaptive authentication, and session management) are left to the feature-RFP.

Workforce

Workforce is where vendors are strongest and checklists least useful. In the platforms CAI assessed, segregation of duties stopped at each platform’s own entitlements, and shared signals were partial or absent. The differentiating questions concern what happens across applications and after sign-in.

Table 4. Workforce questions

ID	Question	Control area	Evidence to request
WF1	Can your segregation-of-duties rules include applications that are not in your platform? Do you find conflicts at the entitlement level and at the transaction level? Do you find them at request, at provisioning, and at review? Do you record mitigating controls, and do you show which conflicts users actually caused?	Governance	The rule set across named applications. The level of detail. Records of mitigating controls. Analysis of actual use.
WF2	Do applications call your decision point for each request, through a standard interface? Can we test the policy before we deploy it? Or does your policy stop at sign-in?	Runtime	The decision-point API. AuthZEN conformance. A local test harness for policy.
WF3	Can a system that you do not own revoke a session that you issued? Can you revoke its sessions? Do you transmit and receive shared-signals events, and which event types?	Observability	The transmitter and receiver configuration. The list of event types. The revocation latency, as tested.
WF4	At which events do you verify the person again: onboarding, authenticator enrollment, help-desk recovery, or privileged elevation? What assurance level do you get at each event?	Binding	A map to an assurance framework. The design of the recovery flow.
WF5	Do you show indirect escalation paths across systems that you do not manage? Do you broker and record privileged sessions with no standing privilege?	Governance, runtime	Analysis of escalation paths across directories and clouds. Session recordings. Just-in-time grants.

Customer

Customer runtime is mature across vendors; governance and evaluation after sign-in are not. In CAI’s assessment, customer entitlement review remains a process most enterprises design and run themselves.

Table 5. Customer questions

ID	Question	Control area	Evidence to request
CU1	How do you review customer entitlements over time? What evidence does a review give?	Governance	The review workflow for customer populations. Sample evidence from a review.
CU2	After sign-in, can an external signal revoke a customer session? Which customer risk events do you send out? Which types, and with what latency?	Observability	A catalog of events with their latency. The path for external revocation.
CU3	Do you supply fine-grained authorization inside customer applications as a service? Can its model and policies operate on another engine?	Runtime	The authorization model. Policy export. An open evaluation engine.
CU4	Do you supply high-assurance verification of customers, or does another provider supply it? Can you issue, present, selectively disclose, and revoke the result as a verifiable credential?	Binding	The verification integration. The flows to issue, present, and revoke credentials.⁸

Partner

Federation is the most mature partner capability and the least differentiating. The questions that matter concern the organization behind the partner users and the lifecycle of its people.

Table 6. Partner questions

ID	Question	Control area	Evidence to request
PA1	Can you bind a partner organization to a verifiable legal-entity credential and verify it again over time? Can its representatives prove their official role?	Binding	Verification of legal-entity credentials. Verification of role credentials.
PA2	Can the authoritative source of the partner send joiner, mover, and leaver events for its people? When a person leaves the partner, does their access here stop?	Governance	The lifecycle design for partner sources. An offboarding test.
PA3	Do you set partner trust one partner at a time, or through a multilateral federation standard? How does it scale past hundreds of partners?	Runtime	Support for a federation standard. Automatic trust onboarding.
PA4	During your outage, how do partners keep their access? What evidence do you give for this?	Observability	The resilience design for partner access. Continuity evidence.

Device

Device binding to hardware is strong at the leading platforms; governance of the device as an identity subject usually lives in endpoint management. The questions test where the platform’s responsibility ends.

Table 7. Device questions

ID	Question	Control area	Evidence to request
DE1	Which device entitlement, review, and lifecycle operations do you do yourself? Which do you get from endpoint management?	Governance	Documentation for the device lifecycle and for device reviews.
DE2	Can a device be the subject of an authorization decision, not only a condition in it? Does this apply to operational-technology and IoT devices?	Runtime	Examples of policy with the device as the subject. Registration of things.
DE3	When device posture changes, how quickly do you revoke active sessions in applications that you do not own?	Observability	The revocation latency across applications, as tested.
DE4	Is the device key bound to hardware and attested at enrollment? When a person replaces a device, do you verify the person again before you bind the new device?	Binding	Attestation formats. The flow for a replacement device.

Workload

In the public evidence CAI reviewed, most workload identity is a secret or certificate given to a service, not an identity tied to verified facts about the running workload. Cloud-managed identities are the exception. Workload-identity standards remain in development, so the questions test both what is issued today and what can be consumed.⁹

Table 8. Workload questions

ID	Question	Control area	Evidence to request
WL1	When you issue a workload identity, do you attest where the workload operates? Or is the identity a stored credential? Can you accept identities that another system attested, and check that attestation?	Binding, governance	The design for issuance and attestation. The token-exchange configuration.
WL2	Do your policies and risk detection apply to all types of workload identity that you issue? Does federated workload identity work with all resource APIs?	Runtime	A coverage matrix by identity type and by resource.
WL3	Can you show the effective, transitive permissions of a workload across clouds? Can you replace standing privilege with just-in-time grants?	Governance	Analysis of effective permissions. The design for just-in-time grants.
WL4	When a request moves across services and trust domains, do you keep the identity and authorization context of the original caller? Or do you lose it at the first hop?	Runtime	Support for transaction tokens or identity chaining.
WL5	Does continuous evaluation for workloads go beyond your own resources?	Observability	Signal coverage by resource type.

AI Agent

Registering agents with accountable owners is now common across the leading platforms. What separates vendors is whether delegation is evidenced, whether each tool call is authorized against enterprise policy, and whether audit follows the agent wherever it acts.¹⁰

Table 9. AI agent questions

ID	Question	Control area	Evidence to request
AG1	How do you show that a person gave authority to an agent? If the person removes that authority, how quickly do all active agent sessions and tokens stop?	Governance	The delegation record. The revocation path and its latency, as tested.
AG2	Do you authorize each call from an agent to a tool against enterprise policy? Or does each tool server decide, based on a consent that the user gave one time?	Runtime	The configuration for enterprise-managed authorization. Logs of the decision for each call.
AG3	Can policy make a distinction between autonomous, delegated, and supervised operation? Do you enforce human-in-the-loop checkpoints at runtime? Can we write, version, and test agent registrations and policies as code?	Governance, runtime	Policy for each operating mode. Enforcement of checkpoints. The code interface for agent policy.
AG4	Does your audit record every surface where agents act, also for agents from other platforms? Does it attribute each action to the person who delegated the authority?	Observability	A map of audit coverage by surface. The attribution record.
AG5	How do you find agents: with connectors to known platforms, by observation on endpoints or browsers, or only by registration? What does each method miss?	Governance	Discovery coverage for each method.

Organization

Organization identity had the weakest controls and the thinnest evidence of any constituency in every platform CAI assessed. It no longer has to: the verifiable Legal Entity Identifier (vLEI), standardized as ISO 17442-3 and governed by GLEIF, lets a counterparty verify cryptographically the legal entity, the person acting for it, and the official role that person holds.¹¹ The questions ask whether a vendor can use it.

Table 10. Organization questions

ID	Question	Control area	Evidence to request
OR1	Do you verify each organization record against an authoritative legal-entity source, and verify it again over time? Or is the organization only a tenant that someone configured?	Binding	The flow to verify a legal entity. The trigger to verify it again.
OR2	At sign-in, can you use cryptography to verify the official role of a person at a legal entity? Can you translate the result into the protocols that your platform uses?	Binding, runtime	Verification of role credentials. Protocol translation.
OR3	Can you show entitlements and audit evidence at the legal-entity level, across tenants and subsidiaries?	Governance, observability	Reports of entitlements and audit at the entity level.
OR4	When a legal entity changes, which changes go to access automatically? Examples are a merger, a deregistration, or a revoked credential.	Governance	The design for change propagation. A revocation test.

Applying the Questions by Archetype and Estate

The questions do not change by archetype; their emphasis does.

Navigating IAM Market Evolution (IAM-LB-MS-01) describes converging platforms, focused specialists, and substrate and standards-aligned vendors. For evaluation, this brief separates established suites from converging platforms, because a broad, console-bound estate raises different questions from a broad, programmable one. Table 11 shows the most important questions for each group, and where its capability often stops.

Table 11. The most important questions for each archetype group

Archetype group	Most important questions	Where the capability often stops
Converging platforms	V1, DE1, WL1, OR1; WF1, WF2, WF3; V4, V8, V9	The platform keeps many constituencies as subjects. For some constituencies, such as devices, workloads, and organizations, the governance controls (entitlements, reviews, and segregation of duties) are partial or come from another product. Signals usually stay inside the platform. The newest capabilities are often only in the console.
Established suites	V4, V10; AG1 to AG5; WL1; WF3	Many controls are configured only in the console. Agents and workloads are often modeled as user accounts or service accounts. The vendor often does not give dates for the modernization of each component.
Focused specialists	WF2, WF3, V5, V8; WF1 or WF5, as applicable to the specialty	The controls are strong in the specialist’s own control area. The interfaces to other platforms are often not standard. When the specialist and the platform control the same entitlement or session, it is often not clear which system has authority.
Substrate and standards-aligned vendors	V2, V7, WF4, DE4, WL1, OR1, OR2, WL2	The vendor often does not state the assurance level of its verification or how current its data is. Some vendors operate in only one cloud or one ecosystem.
Frontier innovators (within specialists)	AG1 to AG5, V6; FR1, FR2	Few customers use the capability in production at large scale. After an acquisition, the product and its roadmap can change.

Frontier innovators get two more questions (Table 12).

Table 12. Frontier innovator questions

ID	Question	Evidence to request
FR1	How many customers use this capability in production at our scale?	Named production references at a similar scale. Volume figures.
FR2	If someone acquires your company, or if you stop the product, what happens to our instances, our data, and your roadmap commitments?	Contract terms for continuity, export, and escrow. Commitments that continue after a change of ownership.

Two modifiers apply to every group.

Delivery posture. For a console-bound vendor, press V4 on the controls that exist only in the console, and on the date each becomes authorable as code.
Operation. For a vendor-operated instance, press V9 and V3: who restores the configuration, and who owns the instance internally. For an enterprise-operated instance, press V3 and ES1: what it takes to run, patch, and keep available.

Enterprise profiles add a final set (Table 13). The high-assurance profile adds no questions of its own; it raises the bar on the binding questions V2, WF4, CU4, DE4, WL1, OR1, and OR2.

Table 13. Estate questions triggered by enterprise profile

ID	Profile	Question
ES1	Hybrid estate	Which controls operate with no internet connection to your cloud, for example on-premises, air-gapped, or sovereign? Which controls degrade?
ES2	Hybrid estate; regulated and complex	Do your controls apply fine-grained authorization to data resources? Or do they stop at the application?
ES3	Regulated and complex	Can you set policy, consent, and data residency for each jurisdiction? Where do you process identity data and log data?
ES4	Regulated and complex	Can we add and remove subsidiaries as isolated identity domains? After an acquisition or a migration, do you examine the bindings again, or do you inherit them?

Putting the Questions to Work

How to add the questions to an internally built RFP, and what to report upward.

Tier each vendor by the five drivers in Table 1 before the RFP is issued.
Assemble the question set: the every-vendor questions, the constituency rows for the instances the vendor will carry, the archetype emphasis, and the estate questions your profile triggers.
Append, do not replace. Keep the feature-RFP and the supplier-security questionnaire, and add these questions as a separate, weighted section.
Require an evidence class for every answer, and score claimed-only answers as unverified.
Record an outcome per instance: native, with your build, or with a complementary capability, qualified by your enterprise profile.
Test before signing for systemically critical vendors: restore a configuration, revoke a session across systems the vendor does not own, export a policy.
Report a coverage map, not a score (Figure 4).

Figure 4. From questions to a coverage map, showing the five evaluation steps and the per-instance output that replaces a blended score

Table 14 gives examples of common feature-RFP lines and the questions that carry their real weight. It is not a complete list.

Table 14. Examples: from feature question to control-coverage question

Typical feature-RFP line	What it misses	Ask instead
Do you support SSO and MFA?	Which populations you keep as subjects, and how you bind each one and verify it again	V1, V2, WF4
Do you support fine-grained authorization?	If applications call a decision point for each request, through a standard interface	WF2, CU3
Do you support SCIM?	Which source is authoritative, and if the source of a partner controls the lifecycle of its people	V7, PA2
Do you support zero trust?	If signals from outside the vendor’s platform can revoke sessions	WF3, CU2, DE3
Do you offer access certifications?	If segregation of duties includes all applications, and if the vendor reviews customers	WF1, CU1
Do you support AI agents?	If the vendor shows evidence of delegation and authorizes each tool call	AG1, AG2, AG4
Do you support standards?	Which standards carry policy and signals, in which roles, and with which results	V5, V10
What is your uptime SLA?	What stops when the vendor stops, and who restores the configuration	V8, V9

The decisions to bring to the executive table follow from the map, not from a ranking:

Which vendors are systemically critical, and who owns each of them internally.
Which instances will be carried natively, built, or sourced alongside, and at what cost.
What the enterprise retains for each vendor-operated instance: break-glass access, logs, configuration export, and a tested restore.
What leaving would cost, decided before signing.

Four measures show whether the discipline is holding:

Share of instances carried by systemically critical vendors with evidence-graded answers.
Share of vendor-operated instances with a named internal owner and a tested restore.
Share of critical instances whose policy can be exported in a form another engine can run.
Tested time to revoke a session across systems the vendor does not own.

Re-tier vendors annually and whenever a vendor’s share of the coverage surface grows. Expect the AI agent, workload, and organization rows to carry more weight in each cycle as their standards mature and as those populations grow.

For vendors, the same questions describe what to build and what to publish. In CAI’s assessment, the vendors that publish their boundaries, demonstrate conformance, and make configuration recoverable by the customer will be easier to select for systemically critical roles than vendors with broader claims and thinner evidence. The gaps these questions expose (authorization-policy and shared-signals standards, attested workload identity, verified organizations, and agent policy authored as code) are, in effect, the roadmap the most critical buyers will hold vendors to.

Conclusion

Some IAM vendors are now infrastructure, and they are still selected with instruments designed for tools. A feature-RFP cannot tell holding a population from governing it, a supported standard from a portable policy, or a plausible answer from a true one, and AI has removed the effort that once made those answers expensive to fake. The questions that separate vendors are the ones about control coverage: which populations a vendor holds, which controls it delivers over each, how the identities beneath are bound, who builds and runs each part, what evidence stands behind each claim, and what leaving would cost.

An enterprise that classifies its vendors by systemic criticality, asks these questions in proportion, and reports a coverage map rather than a score will know where it depends on a vendor and what it would take to stop. That knowledge is the difference between buying a platform and building infrastructure on one.

Acronym Key and Glossary

Term	Meaning
A2A	Agent2Agent, a protocol for communication and task delegation between AI agents.
AuthZEN	OpenID Foundation Authorization API; a standard interface between policy enforcement points and policy decision points.
CAEP / SSF / RISC	Continuous Access Evaluation Profile, Shared Signals Framework, and Risk Incident Sharing and Coordination; OpenID Foundation standards for exchanging session and account-state events.
CISA	Cybersecurity and Infrastructure Security Agency (United States).
GLEIF	Global Legal Entity Identifier Foundation, which governs the LEI and vLEI systems.
IAM	Identity and access management.
ICT	Information and communications technology.
IGA	Identity governance and administration.
IoT	Internet of Things.
ISO	International Organization for Standardization.
ITDR	Identity threat detection and response.
LEI / vLEI	Legal Entity Identifier; verifiable LEI, a digital credential for a legal entity and for persons acting in official roles on its behalf.
MCP	Model Context Protocol, for AI agents to discover and call tools.
MFA / SSO	Multifactor authentication; single sign-on.
NIST	National Institute of Standards and Technology (United States).
PDP / PEP	Policy decision point and policy enforcement point.
RFP	Request for proposal.
SCIM	System for Cross-domain Identity Management, a provisioning standard.
SLA	Service-level agreement.
SPIFFE / WIMSE	Secure Production Identity Framework for Everyone; IETF Workload Identity in Multi-System Environments. Standards for workload identity.
Instance	One control category (governance, runtime, or observability) applied to one identity constituency; the unit of evaluation.
Held / acted on	A constituency is held when the platform manages it as a subject with its own lifecycle and binding; acted on when the platform only brokers access, consumes attributes, or asserts trust for it.
Native / with your build / with a complementary capability	The three outcomes for an instance: delivered by configuring the product; completed by enterprise-authored parts; requiring another product sourced alongside.
Binding	How an identity is linked to a real subject: unbound, asserted, sourced, evidenced, or sustained.
Realization / operation	How an instance comes to exist (built, implemented, or blended) and who runs it (the enterprise or a vendor).
Delivery posture	Whether controls are console-bound or programmable, authored as code with the repository as source of truth.
Evidence class	Demonstrated, documented, or claimed; with status generally available, preview, or announced.
Control area	The part of the control-and-coverage frame a question tests: governance, runtime, observability, or the binding beneath them.
Enterprise profile	One of four fixed estate conditions (baseline; regulated and complex; hybrid estate; high assurance) that qualify an outcome without changing it.
Question identifiers	V: every vendor. WF, CU, PA, DE, WL, AG, OR: workforce, customer, partner, device, workload, AI agent, and organization. ES: estate, triggered by enterprise profile. FR: frontier innovators.
Systemically critical IAM vendor	A vendor whose failure, compromise, degradation, or exit would propagate across a material share of an enterprise’s coverage surface.

Evidence

This brief pairs CAI’s framing with a review across five kinds of source: standards and specifications, regulatory and government guidance, academic research, practitioner and vendor documentation, and CAI’s own assessments. Market-adoption figures were treated as directional. Standards are cited in the footnotes.

Standards, specifications, and guidance referenced

OpenID Foundation: Shared Signals Framework 1.0, CAEP 1.0, and RISC 1.0, Final Specifications, 2025; Authorization API 1.0, Final Specification, January 2026; OpenID Federation 1.0, Final Specification, February 2026; OpenID for Verifiable Credential Issuance 1.0, Final Specification, September 2025; OpenID for Verifiable Presentations 1.0, Final Specification, July 2025.
IETF work in progress: OAuth 2.1; Transaction Tokens; OAuth identity and authorization chaining across domains; WIMSE architecture.
Model Context Protocol specification, 2026-07-28 release, Enterprise-Managed Authorization extension.
ISO 17442-3:2024, verifiable Legal Entity Identifiers; GLEIF vLEI Ecosystem Governance Framework.
Regulation (EU) 2022/2554 (DORA), critical ICT third-party provider designations, November 2025; United Kingdom critical third parties regime, first designations, July 2026.
NIST SP 800-161 Rev. 1; CISA Secure by Demand Guide and Software Acquisition Guide for Government Enterprise Consumers.

Navigating IAM Market Evolution (IAM-LB-MS-01): archetypes, realization, and operation.
IAM Root Document (IAM-RD-01): the control-and-coverage matrix.
Identity and Access Substrate (IAM-F-SUB-01): binding and the identity layer beneath the controls.
Identity and Access Governance Controls (IAM-F-GOV-01), Runtime Controls (IAM-F-RTM-01), and Observability Controls (IAM-F-OBS-01): operability of the controls an enterprise runs.
AI Agent Identity and Access (IAM-CAP-AI-01).

Notes

OpenID Foundation: Shared Signals Framework 1.0, Continuous Access Evaluation Profile 1.0, and RISC Profile 1.0, Final Specifications, 2025; Authorization API 1.0 (AuthZEN), Final Specification, January 2026; OpenID Federation 1.0, Final Specification, February 2026. IETF WIMSE Working Group, Workload Identity in Multi-System Environments (WIMSE) Architecture, draft-ietf-wimse-arch-08, July 2026, work in progress.
European Supervisory Authorities (EBA, EIOPA, ESMA), first list of designated critical ICT third-party providers under Regulation (EU) 2022/2554 (Digital Operational Resilience Act), 18 November 2025.
HM Treasury, first designations under the critical third parties regime established by the Financial Services and Markets Act 2023, 10 July 2026.
NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, update 1, November 2024; CISA, Secure by Demand Guide, 2024; CISA, Software Acquisition Guide for Government Enterprise Consumers, 2024.
Vendor-side adoption: proposal-software industry surveys, 2025 to 2026. Buyer-side adoption: research on generative AI use by procurement executives, 2025. Figures are treated as directional and not reproduced.
L. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023.
K. Wataoka, T. Takahashi, and R. Ri, Self-Preference Bias in LLM-as-a-Judge, arXiv:2410.21819, October 2024.
OpenID Foundation, OpenID for Verifiable Credential Issuance 1.0, Final Specification, September 2025; OpenID for Verifiable Presentations 1.0, Final Specification, July 2025; W3C Verifiable Credentials Data Model 2.0, W3C Recommendation, May 2025.
IETF WIMSE Working Group, WIMSE Architecture, draft-ietf-wimse-arch-08, July 2026; SPIFFE, Cloud Native Computing Foundation graduated project; IETF OAuth Working Group, OAuth 2.1, draft-ietf-oauth-v2-1-15, March 2026; Transaction Tokens, draft-ietf-oauth-transaction-tokens-08; OAuth Identity and Authorization Chaining Across Domains; all work in progress.
Model Context Protocol specification, 2026-07-28 release, Enterprise-Managed Authorization extension, stable since June 2026; the underlying Identity Assertion JWT Authorization Grant remains an IETF Internet-Draft.
ISO 17442-3:2024, Financial services, Legal entity identifier (LEI), Part 3: Verifiable LEIs (vLEIs); GLEIF, vLEI Ecosystem Governance Framework.

Disclaimer

© 2026 Control Architecture Institute Inc. All rights reserved. Control Architecture Institute Inc. (Control Architecture Institute or CAI) is a research institute. The Library, of which this report is a part, consists of the opinions of CAI’s research team, which should not be construed as statements of fact. While the information contained in this publication has been obtained from sources believed to be reliable, CAI disclaims all warranties as to the accuracy, completeness, or adequacy of such information. Although CAI research may address legal and financial issues, CAI does not provide legal or financial advice and its research should not be construed or used as such. Your access and use of this publication are governed by CAI’s terms of use. CAI prides itself on its independence and objectivity. Its research is produced independently by its research team without input or influence from any third party. This publication may not be reproduced or distributed in any form without CAI’s prior written permission. CAI research may not be used as input into, or for the training or development of, generative artificial intelligence, machine learning, algorithms, software, or related technologies.