Navigating IAM Market Evolution

Observations

Identity and access management delivers controls (what happens before, during, and after each access decision) applied across a span of coverage (the people, machines, systems, data, and organizations). This brief calls the complete set of those control-and-coverage combinations (instances) the enterprise’s coverage surface. The observations below frame how the market serves the coverage surface.

• Identity and access management is an infrastructure market where the infrastructure logic and market logic pull against each other. Infrastructure must be complete and coherent across a coverage surface and fails at its weakest point; a market supplies discrete, saleable, fundable products along category lines. The distance between the two is structural, not a temporary immaturity that consolidation will close.
• The market moves by its own supply-and-demand dynamics, not toward any architecture. It consolidates into suites one cycle and spins out new categories the next, and it crowns one dimension at a time. The names in circulation track what is fundable, not necessarily what is structurally required.
• The enterprise is the accountable integrator of the coverage surface, but not always the operator of the underlying infrastructure. It owns the surface and the outcome. How an instance is realized (built, implemented, or blended) and who operates it (the enterprise or a vendor) are two separate decisions. The integration burden is the discipline’s central, under-acknowledged cost.
• Some vendors behave as the infrastructure, not as tools. Especially when a capability is delivered as a cloud service, a converging leader or a focused specialist can be the infrastructure for the instances it covers, which the enterprise then consumes and governs rather than builds and runs.
• There is no universal center of gravity; the critical instance is enterprise-specific. No single capability is the one every organization should address next. Priority is set by where each enterprise’s own coverage is weakest, its risk highest, and its ownership least clear.

Positions

Where CAI stands on the choices a leader will face.

• Read identity and access as an infrastructure market, and use architecture to navigate it rather than predict it. No control architecture, CAI's or a vendor's, is a forecast of where the market is heading. Its purpose is to give a leader a stable instrument for locating work while the market moves underneath. Judge each market move against your own surface, rather than reorganizing your surface to match the market's latest categories.
• Decide two things for every instance: how it is realized, and who operates it. Realization is build, implement, or blend. Operation is the enterprise or a vendor. Both are architecture choices, not a default reflex to purchase a product. Because the two are independent, they yield six combinations rather than three, and each instance should record which one it occupies. Buying is a procurement act that follows those decisions; it is not one of them.
• Evaluate vendors by the coverage they actually deliver and operate against your surface. Judge them category by category and constituency by constituency; where a capability is delivered as a cloud service, evaluate the vendor as infrastructure you depend on. A single blended score across a wide portfolio hides more than it reveals, because strength in one instance says nothing about the next. The honest unit of comparison is the instance, and the honest question is whether the claimed coverage is evidenced.
• Retain accountability, governance, observability, and an exit over every instance, including those a vendor operates. The enterprise owns the surface even where someone else is the infrastructure. Delegating operation transfers the work, not the outcome: an instance a vendor runs still needs a named internal owner, or it is unmanaged. Design the exit at adoption, while it is still cheap, rather than discovering its cost at renewal.
• Prioritize by your own risk and coverage gaps, not by the market’s current headline. Resist single-dimension strategies of every kind. The hard problems are distributed across the whole surface, and which one is decisive is a property of your enterprise rather than of the market. Rank instances by risk, coverage gap, and ownership, and act on the top of that list whatever category is currently ascendant.

Strategic Context

Every transaction, login, service call, data read, and automated action inside a modern enterprise resolves, somewhere, to a decision about identity and access. When that decision layer holds, everything above it works; when it fails, everything that depends on it fails with it. That is the defining property of infrastructure: it is judged not by any single feature but by whether it holds, completely, across everything that rests on it.

The market has begun to describe this reality in its own vocabulary. “Identity control plane,” “identity fabric,” and “converged identity” are now ambient terms, and directionally they are right: identity and access is no longer a set of administrative tools bolted onto the enterprise, but infrastructure the enterprise depends on. The vocabulary, however, conceals the harder truth. It suggests a destination, one fabric or plane or platform, when the reality a leader lives in is an unfinished surface supplied by a market that was never organized to complete it.

CAI View Treat identity and access as an infrastructure the organization is accountable for, complete across its coverage surface, rather than as a set of tools it buys. The ambient “control plane” language is right about the stakes and wrong about the destination: there is no single plane to arrive at, only a surface to keep covered.

Figure 1. completeness and sellability do not align, so an integration burden is permanent

The remainder of this brief follows from that premise. It describes how the market actually moves, offers a stable instrument for navigating it, and works through the decision the premise forces on every enterprise: having accepted accountability for the surface, how it delivers coverage across it.

How the Market Actually Moves

The identity and access market has its own dynamics, independent of any architecture. Four forces are worth naming.

• Consolidation. Large platforms acquire adjacent tools and fold them into suites. Recent years have seen multi-billion-dollar acquisitions absorb privileged access, machine identity, and identity-security capabilities into broader security platforms.
• Fragmentation. New categories spin out faster than they consolidate. Posture management, identity threat detection and response, machine and non-human identity, and now agent identity each arrived as a distinct category with its own vendors and its own analyst label.
• Standardization. Open interfaces increasingly let capabilities from different sources interoperate: shared-signal and continuous-evaluation interfaces¹, a standardized authorization interface², and inter-agent and agent-to-tool protocols³⁴.
• Delivery-model shift. Capability increasingly ships as a cloud service rather than as software to install and run, which changes not only how it is bought but who operates it.

Watch-Out Category momentum is not structural necessity. The serial procession of “next big things” is a marketing sequence, what is currently fundable and saleable, not evidence about where an enterprise’s real exposure lies.

Figure 2. the market crowns one category at a time while consolidating underneath

The pattern beneath all four forces is the same: the market packages capability into what can be sold and funded, along category lines, and reorganizes those lines whenever the commercial logic shifts. That is a legitimate way for a market to behave. It is simply not the same as covering an enterprise’s surface, and it should not be mistaken for it.

The Infrastructure Surface: A Navigation Instrument

If the market cannot be trusted to describe the structure, the enterprise needs its own instrument, one that stays stable while the market moves. CAI’s Control and Coverage Matrix is that instrument: a coordinate system for locating work, not a product to buy and not a taxonomy to adopt.

It has a control axis, a coverage axis, and a substrate. The control axis has three durable categories. Governance is what happens before access: administration, entitlement, certification, and policy. Runtime is what happens at the moment of access: authentication, authorization, session, federation, and enforcement. Observability is what happens after and around access: detection, posture, signals, and analytics that feed back into the other two. The coverage axis has three facets that qualify every access at once: the identity constituency, being human (workforce, customer, partner), machine (device, workload, agent), or organization; the technical environment (channel, infrastructure, data, and application, across on-premises and cloud); and the business environment (unit, subsidiary, and jurisdiction). Beneath both sits a substrate every control depends on: the identity and access data on which decisions are made, and the identity verification and assurance by which a subject is established and trusted.

Each intersection, each control-and-coverage instance, is a discrete unit of accountable work: something to be delivered by a capability, operated by someone, and owned by a named person. An enterprise’s surface is the full set of instances that apply to it, and its posture is how completely those instances are covered and owned.

CAI View The matrix is a navigation instrument, not a fabric or a taxonomy. A taxonomy sorts products into buckets; a fabric is a destination a vendor sells. A navigation instrument does neither: it lets a leader locate where they are, see where coverage is thin, and decide what to do, without adopting anyone’s category scheme or product roadmap.

Figure 3. the surface is a coordinate system over a data-and-verification substrate, not a product

Who Assembles, Who Operates: Realization and Operation

The matrix locates the work; it does not do it. Someone must deliver each instance, and here the market’s structure and the enterprise’s obligation meet. The enterprise is the accountable integrator: it owns the coverage surface and the outcome, and no market packaging maps cleanly onto that surface. But being accountable for an instance is not the same as operating it.

For each instance the enterprise faces two decisions, and they are independent of one another. The first is realization: how the capability comes to exist. It can be built, developed bespoke with the enterprise’s own resources. It can be implemented, meaning an acquired product or service that is deployed, configured, and customized to fit. Or it can be blended, an implemented core with built extensions around it. The second decision is operation: who runs the capability day to day, the enterprise or a vendor. Because the two axes are independent, they yield six combinations rather than three. A built component can be run by the enterprise or handed to a vendor to operate. An implemented product can be self-managed inside the enterprise’s own estate, or consumed as a vendor-operated service, the arrangement usually called a managed service. Where a vendor operates the capability, that vendor is the infrastructure for that instance, and the enterprise consumes, configures, and governs it rather than running it.

Buy is not a third mode. Buying is a procurement act that accompanies implementation, or the acquisition of a service that someone else operates. Treating purchase as an architecture decision is precisely what collapses the two axes into one, and it hides the choice that actually matters: what the enterprise makes, and who runs it.

Watch-Out Customization depth is the hidden variable. An implemented product bent far enough to fit becomes a build in everything but name: it carries build-like cost and upgrade debt without build-like control. Record how deeply each implemented instance is customized, and price the upgrades before, not after, they arrive.

Standards Note How an instance is operated changes how it is governed. In the current discussion of autonomous agents, cloud-managed agents are treated as easier to govern because they inherit the operator’s mature identity controls, while self-hosted agents are the hardest precisely because the enterprise must supply those controls itself.

Watch-Out Consuming a vendor as infrastructure is often correct, but it concentrates dependence. Reduced leverage, migration difficulty, and exposure to the vendor’s continuity are real costs even when they are not billed, and they must be weighed at the point of adoption, not discovered at renewal.

Figure 4. realization (build, implement, blend) and operation (enterprise or vendor) are independent; accountability stays with the enterprise

Realization and operation are therefore not procurement preferences; they are two architecture decisions, taken per instance, with accountability, continuity, and exit in view. Blend is the normal case rather than the exception: most enterprises will build a little, implement a great deal, extend what they implement, operate some instances themselves, let vendors operate others, and stitch the result into one plane they alone are accountable for.

Situational Priority: Locating Your Critical Instances

Given a surface of many instances and a market that supplies them unevenly, the natural question is where to begin. The market answers with its headline, whatever category is currently ascendant. That answer is wrong more often than it is right, because it is the same answer offered to every enterprise, and no two enterprises have the same surface.

CAI View There is no universal center of gravity in identity and access. The hard problems are distributed across the whole surface, and which one is decisive is a property of the enterprise, not of the market. For one organization the weak instance is runtime authorization for workloads; for another, joiner-mover-leaver governance across a sprawling partner population; for another, observability over machine credentials; for another, verification of organizational identity in a business ecosystem. Each is a genuine gap for the enterprise that has it and a solved problem for the one that does not.

The practical method is to rank instances by three factors and act on the top of the list:

• Risk. the consequence if the instance fails.
• Coverage gap. how far current coverage falls short of what the instance requires.
• Ownership. whether a named person is accountable for the instance, or it is quietly unowned.

Instances that score high on all three are the ones to address first, whatever the market happens to be selling.

Figure 5. rank by risk, coverage gap, and ownership, then decide realization and operation

Sequenced this way, an identity and access program becomes defensible to a board, because its priorities are grounded in the enterprise’s own exposure rather than the market’s calendar. It also becomes resistant to fashion: when the next category arrives loud, the question is not whether to buy it but whether it addresses an instance already near the top of the enterprise’s own list.

Programmable Delivery and the Operating Divide

A capability that appears on the coverage map is not yet a capability that operates. The difference is delivery posture. A control that can only be configured through a console, clicked into place screen by screen, can cover a small, slow surface, but it cannot hold a large one that changes continuously. A control that is programmable, expressed as configuration and policy in code, versioned, reviewed, tested, and deployed through pipelines, can. This distinction cuts across realization: an implemented product that can only be clicked into place will fall behind just as surely as a built component that was never automated, whether or not the enterprise wrote the code.

The standardization of externalized authorization is the clearest illustration. With a common interface between the point that asks for a decision and the point that makes it, an enterprise can express policy once and enforce it at many points, including at the network edge, without rewriting each application. Policy becomes an asset that is managed, not a setting that is clicked.

Standards Note Externalized authorization and policy-as-code have moved from aspiration to standard interface. That does not make them universally necessary (many well-configured platforms enforce adequately on their own), but it does make programmable delivery a realistic option across more of the surface than before.

The operating divide is where “coverage on paper” and “coverage in operation” separate. Two vendors may both claim an instance, but the one whose control is console-bound will fall behind as the surface grows, while the programmable one will not. For a leader, delivery posture is not a technical footnote; it is a predictor of whether a capability will still be covering the surface in three years.

Vendor Archetypes in a Fragmented Market

Vendors can be read, without naming any of them, by the shape of the coverage they deliver and operate. Three archetypes recur, and the point of naming them is structural, not evaluative: they describe how the market is organized, not who is best.

The converging platform assembles broad coverage across control categories and constituencies, often delivered as a cloud service, and positions itself as the infrastructure an enterprise can standardize on. Its strength is breadth and operational maturity; its risk is uneven depth beneath the breadth, and the concentration that follows from standardizing on it. The focused specialist owns a narrow set of instances deeply, often a single control category for a single constituency, and can be the best available infrastructure for exactly those instances. Its strength is depth; its risk is the gaps at the edges of its coverage. The substrate or standards-aligned vendor supplies a foundational layer (data, verification, or a standardized interface) that other capabilities build on. Its value is leverage across the surface; its risk is that it solves an enabling problem rather than a whole instance.

Watch-Out A single blended score for a vendor that spans many instances hides more than it reveals. A vendor strong in workforce governance may be weak in workload runtime, or strong in customer authentication and thin in observability. The honest unit of comparison is the instance, and the honest question is whether a vendor’s archetype is coherent and its claimed coverage is evidenced.

Table 1. Vendor archetypes: what each delivers, its strength, and its structural risk.

The Business Case

Reading vendors by archetype clarifies what to buy; it does not price it entirely. The cost that dominates an identity and access program is rarely the one on the invoice. License and subscription price is visible and comparatively small; the larger costs are structural, and four of them decide whether a program succeeds:

• Implementation and customization. Acquiring a product is cheap next to fitting it. Deployment, configuration, customization, and the upgrade debt that deep customization creates are recurring costs the license price never reveals.
• Integration. Assembling complete coverage from fragmentary supply is continuous work, and it is the discipline’s central cost precisely because it never appears as a line item.
• Unowned coverage. An instance with no named owner is not free; it is a deferred incident, priced eventually and at the worst possible time.
• Concentration. Consuming a vendor as infrastructure trades operational burden for dependence, and the cost of that dependence (reduced leverage, migration difficulty, exposure to the vendor’s continuity) is real even when it is unbilled.

CAI View Budget the cost of unowned coverage. A defensible business case for identity and access is not a comparison of product prices; it is an account of coverage delivered, integration sustained, ownership assigned, and dependence consciously accepted.

Organizational Implications

An infrastructure the enterprise is accountable for needs accountable people, and the unit of accountability is the instance. Every control-and-coverage instance should have a single named owner, not a committee and not a title with no occupant. This is where programs most often fail quietly: not because an instance is uncovered, but because it is covered by a capability no one owns, so no one notices when it drifts.

The vendor-operated instance is the subtle case. Consuming a capability as a service transfers operation, not accountability. Someone inside the enterprise still owns the outcome, the governance of the vendor, the monitoring of the service, and the plan for leaving it. The organizational design that follows is not a new tool but a map of instances to owners, maintained as deliberately as the coverage map itself.

Watch-Out A vendor-operated instance with no internal owner is an unmanaged instance. Delegating operation to a vendor does not delegate the enterprise’s accountability for the outcome.

Decisions for the Executive

The brief resolves into a small set of decisions a leader can make now. Each is stated with its realistic options and CAI’s recommendation.

Table 2. The executive decisions, with the options and CAI's recommendation for each.

KPIs and Board-Level Metrics

The metrics that matter are not tool counts. Four measures make the infrastructure legible:

• Coverage completeness. the share of critical instances with an accountable owner and evidenced coverage across all three control categories.
• Ownership. instances with a named owner, set against instances quietly unowned.
• Operability. the share of controls delivered programmably rather than console-bound.
• Vendor-operated assurance and continuity. the health of the parts of the infrastructure the enterprise depends on but does not run.
• Realization and operation mix. the share of instances built, implemented, and blended, and the share a vendor operates; read alongside customization depth.

Standards Note Continuous, standardized signals make some of this measurable rather than anecdotal: shared-signal and continuous-evaluation interfaces turn session and posture change into events an enterprise can count and act on.

Reported this way, identity and access becomes legible to a board as an infrastructure with coverage, owners, and dependencies, rather than as a portfolio of products whose collective effect on risk no one can state.

Communication Frameworks

The hardest part of leading this shift is often explaining it, and two framings carry most of the weight. The first is infrastructure market versus architecture: the market supplies fragments and moves on its own logic, the architecture is how the enterprise navigates it, and the two are not the same. The second is no single next thing: the enterprise does not chase the category of the year, it prioritizes by its own exposure.

Communicated this way, a board funds coverage, integration, and ownership, the things that actually reduce risk, rather than whichever capability is currently loud. The message to the organization is the same, phrased operationally: we know our surface, we know what we own, and we decide deliberately what we operate and what we consume.

Now versus Plan-For

The brief’s recommendations separate cleanly into what to do now and what to architect toward, for the enterprise as accountable integrator and for vendors reading the same market.

Table 3. Now versus plan-for moves, for the enterprise and the vendor.

Figure 6. separate immediate moves from architecture targets, for enterprise and vendor

Conclusion

Identity and access has become infrastructure, but it is still bought from a market, and those two facts do not reconcile on their own. The market will keep moving by its own logic: consolidating into platforms one quarter, spinning out a new category the next, crowning whichever dimension is currently fundable, and increasingly delivering capability as cloud services that operate as infrastructure in their own right. None of that motion tells a leader what to do, because the hard problems are distributed across the whole control-and-coverage surface and the one that matters most is specific to each enterprise.

The leader’s task is therefore not to chase the market’s headline or to buy the fabric a vendor is selling. It is to hold a stable instrument against a moving market: to map the surface, find where coverage is weak, risk is high, and ownership is missing, and decide, instance by instance, how to realize it, by building, implementing, or blending, and who should operate it, while remaining accountable for the whole. Standards are converging the interfaces, and that helps. But standards define interfaces; they do not assemble the infrastructure. That assembly is, and will remain, the enterprise’s work. The organizations that do it well will not be the ones with the most complete set of category labels; they will be the ones that treated identity and access as an infrastructure they were accountable for, and navigated the market instead of being moved by it.

Acronym Key and Glossary

Evidence

This brief pairs CAI’s framing with a review across five kinds of source: academic and research, standards and specifications, vendor, practitioner, and industry-analyst. Sources were weighted so that no market claim rests on a single promotional source. Standards are cited in the footnotes. Market-sizing figures were treated as directional only, given wide divergence across sources, and no single vendor figure is presented as fact. The broader developments the brief refers to (large-scale consolidation, the proliferation of new identity categories, the surge in machine and agent identity, and the movement of capability to cloud delivery) were corroborated across independent sources during research.

Standards and specifications referenced

• OpenID Foundation
  • OpenID Shared Signals Framework 1.0, Continuous Access Evaluation Profile 1.0, and RISC Profile 1.0 — Final Specifications, 2025.
  • AuthZEN Working Group, Authorization API 1.0 — Final Specification, January 2026.
• Agent interoperability and authorization
  • Linux Foundation Agent2Agent project, Agent2Agent (A2A) Protocol 1.0 — March 2026.
  • Model Context Protocol, OAuth 2.1-based authorization specification — introduced in 2025 and evolving through 2026.
• IETF work in progress
  • OAuth 2.1 Internet-Draft; WIMSE workload-identity specifications; OAuth Transaction Tokens; and emerging individual Internet-Drafts concerning AI-agent authentication, identity, authorization and delegation — maturity varies and most are not final standards.
• Government and industry identity frameworks
  • Regulation (EU) 2024/1183 establishing the European Digital Identity Framework and EUDI Wallet ecosystem.
  • NIST SP 800-63-4 Digital Identity Guidelines — final, August 2025; qualifying passkey implementations can meet AAL2 requirements.
  • FIDO Alliance digital-credentials initiative and technical working group — active since December 2025.

Related Reading

• IAM-RD-01 for the Identity and Access Root Document
• IAM-F-GOV-01 for the Identity and Access Governance Controls Foundation Report.
• IAM-F-RTM-01 for the Identity and Access Runtime Controls Foundation Report.
• IAM-F-OBS-01 for the Identity and Access Observability Controls Foundation Report.
• IAM-F-SUB-01 for the Identity and Access Substrate Foundation Report.

Notes

1. OpenID Foundation: Shared Signals Framework 1.0, Continuous Access Evaluation Profile (CAEP) 1.0, and RISC 1.0, approved as Final Specifications (2025).
2. OpenID AuthZEN Authorization API 1.0, final (2026); a standard interface between policy enforcement and policy decision points.
3. Agent-to-Agent (A2A) Protocol 1.0, Linux Foundation (2026).
4. Model Context Protocol authorization (OAuth 2.1 profile) for agent-to-tool access (2026).

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.