Identity and Access Management

Observations

Identity and access management (IAM) has changed more in shape and stakes over the past three years than it did in the previous fifteen. The discipline now needs a single, coherent reference for the practitioners and executives who must build, operate, and own it. This document presents an analytical organizing model for IAM: a Control and Coverage Matrix that addresses IAM requirements through the capabilities that fill each matrix instance.

• IAM is best understood as infrastructure that delivers controls across coverage areas, rather than as a security tool. Every digital action (every transaction, API call, data read, action by a human or workload or AI agent) depends on identity and access. When IAM fails, every dependent control fails with it. CAI's framing organizes IAM around two compositional dimensions: controls (Governance, Runtime, Observability) applied to coverage areas (identity constituencies, technical environments, and business environments). Together they form a matrix in which each control and coverage instance is accountable to a named owner and delivered through specific capabilities.
• IAM is the foundation of business enablement, not a brake on it. Workforce productivity, customer experience, partner integration, AI deployment, M&A, divestiture, market expansion, and regulatory navigation all rest on IAM working well. The argument for IAM investment is not the argument against breach risk alone; it is the argument for the digital activity IAM makes possible. Programs that frame IAM as a cost center systematically underinvest; programs that frame IAM as enablement infrastructure systematically deliver more business value.
• The coverage surface is expanding on three independent facets simultaneously. Identity constituencies are multiplying: humans (such as workforce, customers, and partners); machines (such as devices, workloads, and AI agents); and organizations (such as legal entities involved in trust frameworks, federation, and B2B authorization). Technical environments are diversifying across channel, infrastructure, data, and application surfaces, each spanning on-premises and cloud deployments. Business environments are fragmenting across operating units, subsidiaries, and multiple jurisdictions. As coverage expands, the underlying matrix of control and coverage instances grows large quickly, and a structured response is required: each instance named, each instance owned, each instance delivered.
• The IAM-related standards landscape is in motion across every layer of the stack. OAuth 2.1, modern OAuth extensions (PAR, RAR, DPoP), GNAP, AuthZEN, FIDO2 and passkeys, SPIFFE and WIMSE, OpenID4VCI and OpenID4VP, the Shared Signals Framework: each is consequential, several are stabilizing in the same window, and decisions made now will determine whether an enterprise is on the right side of the curve a few years out. Practitioners with deep experience in earlier-generation standards (such as SAML and traditional RBAC) will need to become familiar with the modern stack to keep pace with the discipline.
• Identity is now an attack surface in its own right, not just a defense. Identity-centric attacks (credential theft, session hijacking, federation abuse, identity provider compromise) are the dominant initial-access vector. The mature response is identity threat detection and response, identity posture management, and identity resilience as first-class capabilities, peers to network and endpoint security and collectively referred to in some quarters as identity security. In CAI's control framing, these capabilities together populate the observability category.
• Identity intersects with every regulatory regime that touches digital systems. Privacy regulation (GDPR, CCPA, and successors), AI regulation (the EU AI Act, evolving NIST guidance), financial services regulation, healthcare regulation, and sector-specific regimes all assume an identity foundation that can answer questions about who did what, when, on whose authority, and in which jurisdiction. Enterprises that cannot answer those questions cleanly across the matrix are exposed regardless of how strong any single technical control is.

Positions

CAI's positions on what an IAM program is for, how this reference supports it, and how to use it:

• Organize the IAM program around the Control and Coverage Matrix, not around tools or projects alone. Controls (Governance, Runtime, Observability) crossed with coverage (identity constituencies, technical environments, business environments) is the right unit of analysis. Programs that organize around the matrix are forced to confront the control and coverage instances that have weak controls or lack of ownership and accountability; programs that organize around tools accumulate capability without ensuring coverage.
• Treat IAM as a business enablement function, not as a control overhead. The IAM program's success measures should include business activity enabled (productivity unlocked, customers onboarded, partner integrations delivered, AI initiatives launched safely) alongside the traditional risk and compliance measures. Funding cases that lead with enablement, with risk reduction as a co-benefit, are more durable than the reverse.
• Modernize controls to be programmable: authored as code, deployed through pipelines, adaptive at runtime. Controls that live in vendor consoles are only as auditable as the console's change log, only as testable as the administrator's recollection, and only as portable as the vendor allows. Programmable controls (policy-as-code substrate plus runtime adaptiveness) are how the matrix becomes operational at scale. The shift is from controls administered to controls engineered.
• Make every control and coverage instance accountable to a named individual. Committee ownership and title-only ownership are the failure modes that produce the appearance of accountability without the substance. A working accountable owner is a named individual with the authority to direct the work, the visibility to see the state of the instance, and the consequences attached to its outcomes. Unowned instances are the ones that mostly fail audits and produce breaches.
• Adopt the modern standards stack deliberately, and plan migration off earlier-generation protocols. The standards landscape is moving across every layer at once, and several specifications are stabilizing in the same window. Programs that decide now which protocols to adopt (and which to retire) stay on the right side of the curve; programs that defer the decision inherit whatever their incumbent vendors default to. Treat standards selection as an explicit architectural choice, not a byproduct of procurement.
• Defend identity as an attack surface, not only as a defense. Identity-centric attacks are now a dominant initial-access vector, so identity threat detection and response, identity posture management, and identity resilience belong in the program as first-class capabilities, peers to network and endpoint security. In CAI’s control framing these populate the Observability category, and a program that under-resources them cannot detect or recover from the compromises that target identity directly.
• Build the matrix so it can answer the regulator’s questions across every coverage area. Every regulatory regime that touches digital systems assumes an identity foundation that can say who did what, when, on whose authority, and in which jurisdiction. Design controls and observability so those questions can be answered cleanly for any control and coverage instance; an enterprise that cannot answer them is exposed regardless of how strong any single technical control is.

The CAI Control and Coverage Approach

Everything here serves a single goal: build and operate IAM infrastructure that delivers access controls enabling business, spanning every business process, every business environment, every operating environment, and every identity type (Figure 1).

Figure 1. The CAI Control & Coverage approach: IAM infrastructure delivers controls across coverage areas, filled by capabilities, owned by named individuals, in service of business enablement.

The goal has three verbs: build, operate, and deliver. Build and operate are the means; deliver is the end. “Deliver” is not a separate late-stage phase that follows the other two. The controls are delivered through build and operate.

• Build produces the infrastructure such as directories, identity providers, authorization platforms, vaults, pipelines, and observability platforms.
• Operate sustains that infrastructure such as provisioning, certification, monitoring, and incident response.
• Deliver is the outcome such as enforced access controls that let the business run securely and safely.

The Control and Coverage Matrix

The goal resolves into a single organizing structure: a matrix. Each row is a control category (Governance, Runtime, Observability), each column is a coverage area (a specific combination of identity constituency, technical environment, and business environment), and each control and coverage instance at the intersection is a discrete piece of accountable work. The sections that follow develop the structure in turn: Controls and Coverage define the matrix; Capabilities fill its instances; Accountability owns them. This section introduces the structure they populate (Figure 2).

Figure 2. The Control and Coverage Matrix: three control categories crossed with the three coverage facets. Each cell is a control and coverage instance.

An illustrative control and coverage matrix for identity constituency

The full matrix is large: three control categories crossed with the cross-product of identity constituency, technical environment, and business environment facets yields on the order of hundreds of control and coverage instances when fully enumerated. The illustrative matrix below shows control categories crossed with the identity-constituency facet alone, to demonstrate the structure.

Table 1. Illustrative control and coverage matrix for the identity-constituency facet.

	Governance	Runtime	Observability
Workforce	Joiner / mover / leaver provisioning; entitlement design; access certification; SoD enforcement	Workforce SSO; MFA; phishing-resistant authentication; runtime authorization	Workforce identity threat detection; behavioral analytics; certification anomaly review
Customer	Registration governance; consent management; profile lifecycle; data retention	Customer authentication (passwordless / passkeys); adaptive authentication; session management	CIAM fraud detection; account takeover protection; abuse signal correlation
Partner	Partner onboarding governance; federation trust agreements; entitlement delegation	Federated authentication; B2B SSO; partner authorization with delegation	Partner activity monitoring; cross-organization signal sharing
Device	Device enrollment governance; device attestation policies; trust policy authoring	Device authentication; mTLS; posture-aware access; device-bound credentials	Device posture monitoring; compromise detection; lost / stolen response
Workload	Workload identity issuance governance; trust domain design; workload entitlement design	Workload authentication (SPIFFE / WIMSE); workload-to-workload mTLS; transaction tokens	Workload behavior monitoring; anomalous call-pattern detection; service-to-service traffic analysis
AI Agent	Agent registration; agent ownership assignment; operating-mode governance; tool-permission scoping; delegation grants	Agent identity issuance; agent-to-tool authorization; delegation token verification; human-in-the-loop checkpoints	Agent action attribution; behavioral monitoring; audit trail of tool invocations and decisions; oversight escalation
Organization	Trust framework participation; federation agreement governance; B2B entitlement design	Federation trust enforcement; cross-organization SSO; verifiable credential verification	Federation trust monitoring; cross-organization incident sharing

Each instance in the illustration is a coherent body of work: an accountable owner, a set of capabilities that deliver it, the processes those capabilities run, the tools those capabilities use, the data those capabilities consume and produce. The full matrix expands the constituency axis to the cross-product of all three coverage facets. A partner accessing an application channel of a cloud-hosted SaaS application from an international subsidiary is a different control and coverage instance than a partner accessing the application channel of a legacy on-premises system from a domestic business unit, and the controls that cover them differ accordingly.

CAI View The Control and Coverage Matrix is the right unit of analysis for an IAM program. Programs that organize around tools ("the IGA project," "the SSO project") accumulate capability without ensuring coverage. Programs that organize around the matrix are forced to confront the control and coverage instances that have weak controls or lack of ownership and accountability, precisely the instances where breaches and audit findings concentrate.

Controls

A control is how IAM enforces a decision about who can do what. Controls are organized in three categories that correspond to when the control operates and what it does. The categories together are the IAM Control Architecture: every IAM control fits in one or more, and a complete IAM program has all three.

The three control categories

Table 2. The three control categories and the capabilities that deliver them.

Category	What it does	Capabilities that deliver it
Governance	Decides who should have access to what, under what conditions, and on what authority. Operates at administrative time, before the access happens. Where policy is authored, roles are designed, access is requested and approved, certifications are run, and segregation-of-duties is enforced.	Identity governance and administration; policy management; privileged access governance; access certification; entitlement management
Runtime	Enforces the access decision at the moment of action. Operates at request time. Authenticates the subject, evaluates policy, issues or denies the action, and emits the events that downstream layers consume.	Authentication; runtime authorization; session management; federation; workload identity issuance; API access enforcement
Observability	Knows what happened, with the systematic capacity to interrogate, detect, and respond. Operates after the fact and feeds back into governance and runtime decisions over time. Collects identity events, correlates them, detects anomalies, supports forensics, and provides the evidence that audits and incident responses depend on.	Identity threat detection and response; identity posture management; shared signals and continuous evaluation; identity analytics; SecOps and DevOps integration

The three categories are not optional. A program that is strong in two but weak in the third has a predictable failure:

• Strong governance and runtime but weak observability: the program cannot detect compromise.
• Strong runtime and observability but weak governance: the program accumulates entitlement debt.
• Strong governance and observability but weak runtime: the program is policy without enforcement.

Programmable Controls

Traditional IAM controls live in vendor consoles. An administrator clicks through screens to assign a role, configure an authentication policy, define a certification campaign, or set a fraud-detection threshold. The control is real, but it is only as auditable as the change log of the console it lives in, only as testable as the administrator’s recollection of how it was configured, and only as portable as the vendor allows. Modernizing IAM means moving controls out of consoles and into code.

“Programmable controls” is the term for this modernization shift. A programmable control is one whose definition lives as a version-controlled, peer-reviewed, machine-readable artifact, and whose enforcement adapts at runtime based on context. The two halves reinforce each other: declarative policy makes runtime adaptiveness tractable, and runtime adaptiveness makes declarative policy worth the investment.

The two halves of programmable

• Programmable as code. The control is expressed in a policy language (Cedar, Rego, IDQL, AuthZEN, XACML) or as declarative identity-as-code (Terraform-style provisioning, GitOps for entitlements, pipeline-deployed role definitions). Controls are committed to repositories, peer-reviewed in pull requests, tested in CI, deployed through pipelines, observed in production, and rolled back when wrong. The discipline is the discipline of software engineering applied to identity controls.
• Programmable at runtime. The same control evaluates context at the moment of enforcement (risk signals, device posture, time, location, prior behavior, shared signals from other systems), and produces a decision shaped by inputs that did not exist when the control was authored. Continuous Access Evaluation, adaptive authentication, context-aware authorization, and risk-based session management are runtime-programmable controls in production today.

Why this is a modernization argument, not a vendor-feature argument

Most vendors offer some programmability: a policy editor, an API, a webhook. The question is not whether programmability exists in the toolset; the question is whether the IAM program operates as if its controls were code. CAI distinguishes three postures.

Table 3. The three programmability postures, from console-native to programmable.

Posture	How it works	Operational character
Console-native	Controls authored, modified, and audited inside the vendor console. Change history exists in vendor logs but is not version-controlled outside the vendor. Testing is manual. Rollback is reactive. Most enterprises operate here on most controls.	Functional but fragile. Survives slow change; fails under audit pressure or rapid response.
Console-with-export	Controls authored in the console but periodically exported to a repository for backup, audit, or migration. Better than console-native, but the repository lags the console rather than driving it.	Common transitional posture. Provides audit trail without operational benefit of code-driven changes.
Programmable	Controls authored as code in a repository, peer-reviewed, tested in CI, deployed through pipelines to the policy enforcement points. The console becomes a read-only view; changes that bypass the pipeline are anomalies to be detected and reverted.	The target posture. Required for high-confidence operation at scale and for the runtime adaptiveness that follows.

How programmable controls cross the matrix

Programmable controls is not a coverage area or a separate control category. It is a property the controls themselves can have. Every control and coverage instance in the Control and Coverage Matrix can be filled by a console-native control or a programmable control. The matrix does not change shape; what changes is the operational character of the controls inside it.

The shift from console-native to programmable is uneven across the matrix. Three patterns are typical in enterprises:

• Workload coverage is programmable first. Workload identity, workload authentication, and workload authorization are usually deployed and operated by platform engineering teams that already work in code. Programmability arrives here naturally.
• Workforce governance is programmable late. Joiner / mover / leaver, certification, role design all often live deep in IGA platforms whose console-first design assumed administrative workflows rather than pipeline workflows. Programmability arrives here last.
• Customer authentication is programmable in the middle. CIAM platforms vary widely. Adaptive authentication and risk-based decisioning are often programmable; consent management and customer profile lifecycles are typically not.

Authoring controls in policy languages

The programmable-as-code shift depends on policy languages that can express IAM controls precisely. The following are five first-class examples:

Table 4. Policy languages and contracts for authoring programmable controls.

Language / contract	Description
Cedar	AWS-originated authorization policy language. Strong tooling for testing and analysis; growing ecosystem outside AWS.
Rego	Open Policy Agent's policy language. The dominant open-source choice; strong community; mature tooling. Used widely for workload, infrastructure, and Kubernetes authorization.
IDQL	Identity Query Language, the IDQL/Hexa initiative for cross-platform identity policy. Younger than Cedar and Rego; closer to a policy interchange format than a deployment language.
AuthZEN authorization API	OpenID Foundation's standardization of the authorization API surface. Less a policy language than a contract between policy enforcement and policy decision; allows policy languages to be substitutable.
XACML	The historical authorization policy standard. Less used in new builds; still widely deployed in regulated industries.

Runtime adaptiveness: what programmable controls can decide on

A programmable control evaluates inputs at the moment of enforcement. The following are inputs commonly observed feeding runtime decisions:

• Identity attributes: role, group membership, employment status, customer tier, partner relationship.
• Device posture: managed-device status, OS version, patch level, EDR signal, jailbreak detection.
• Risk signals: login pattern anomalies, impossible travel, behavioral analytics, account takeover indicators.
• Resource sensitivity: data classification, data lineage, regulatory tag, business criticality.
• Action context: time of day, location, network, action type, prior actions in the session.
• External signals: Shared Signals Framework events, CAEP feeds, threat intelligence, fraud signals from adjacent systems.

The control's job is to compose these inputs into a decision: allow, deny, step up, prompt for additional consent, log and continue, terminate the session. Continuous Access Evaluation extends the model from one-time decisions at session establishment to ongoing decisions throughout the session lifetime, in which a signal changes, the decision is re-evaluated.

The infrastructure that makes programmable controls work

Programmable controls do not run on console-shaped infrastructure. The build phase of an IAM program produces specific platform components for programmable controls such as:

• An identity pipeline. The CI/CD-style pipeline that ingests identity-as-code and policy-as-code from repositories, runs validation and tests, and deploys to runtime enforcement points.
• Externalized policy decision points. PDPs that consume programmable policy and serve runtime decisions to enforcement points across the matrix. Authorization Management Platforms are the dominant vendor category.
• An identity and access data platform. The substrate that produces the signals that runtime decisions depend on: identity events, behavioral analytics, device posture, shared signals. Without it, runtime adaptiveness has nothing to adapt to.
• Policy orchestration. The capability that keeps policy consistent across multiple enforcement points and across the boundary between in-house and vendor-managed PDPs.

CAI View An IAM program with strong matrix coverage but console-native controls is solving the right problem with the wrong instrument. Coverage on paper is not coverage in operation when every change requires manual administration, every audit requires console screenshots, and every incident response is bounded by how fast an administrator can click. Programmable controls are how the matrix becomes operational at scale.

Coverage

Coverage is what the controls apply to. CAI’s coverage model has three composite facets that together describe the full surface IAM must protect: identity constituency, technical environment, and business environment. A control without coverage is theory; coverage without controls is exposure. The two together (controls applied to coverage areas) are what an IAM program actually delivers.

Coverage is composite, not three independent dimensions.

Any specific access (a customer reading data from an application channel in a cloud-deployed customer-facing system in a domestic subsidiary, an AI agent calling a data environment hosted on-premises from a workload running in an international business unit) is qualified by all three facets simultaneously. CAI's framing follows that reality: a coverage area is named by the combination of facets that locate it.

Facet 1. Identity Constituency

This facet asks whose or what identity is being authenticated and authorized. CAI distinguishes three constituencies: Human, Machine, and Organization. Human and Machine each have substructure. Humans are split by their relationship to the enterprise, and Machines by what kind of machine they are. Organization stands alone as a constituency in its own right. For trust frameworks, federation agreements, and B2B authorization, the organization itself is the identifiable subject, not just a container for users.

Table 5. The identity-constituency facet: constituencies and their sub-structure.

Class	Constituency	Description
Human	Workforce	Employees and contractors. Identity is sourced from HR systems for employees and contractor-management or vendor-management systems for contractors. Lifecycle is driven by joiner / mover / leaver events. The most mature constituency in most enterprises. Contractors and employees are treated as variants of one constituency because their controls are largely the same; differences are well documented.
Human	Customer	External users of the enterprise's products and services. Identity sourced from registration and progressive profiling. Subject to consent and privacy regulation. CIAM is the dedicated capability domain. The constituency where user-experience design is most consequential to identity design.
Human	Partner	External users from a partner organization who require access to the enterprise's systems. Often federated. The constituency where federation, B2B lifecycle management, and trust frameworks matter most.
Machine	Device	Endpoints and equipment with identity (phones, laptops, IoT, OT). Identity often bound to certificates and posture signals. Device posture is increasingly an input to runtime authorization decisions across the matrix.
Machine	Workload	Software running on infrastructure (services, containers, virtual machines, functions, batch jobs). Identity sourced from the workload identity infrastructure (SPIFFE, WIMSE). The fastest-growing machine constituency by raw count.
Machine	AI Agent	A distinct type of workload that perceives context, makes decisions, and takes actions with non-deterministic behavior, often using tools dynamically. Treated as a distinct constituency rather than as a generic workload because operating modes (autonomous vs. delegated), action attribution, oversight, and audit requirements differ in kind. The fastest-growing constituency by stakes; agent identity decisions made now have multi-year consequences.
Organization	Organization	Other organizations as identifiable subjects in their own right. Used in federation agreements, trust frameworks, B2B authorization, and supply-chain identity. Treated as a constituency because the unit of decision ("is this organization permitted to assert this claim about this user?") is at the organization level, not the user level.

AI Agent is named as a distinct constituency rather than absorbed into Workload because the controls that cover it differ enough to warrant separate treatment. An AI agent acting in delegated mode on behalf of a human user produces different audit requirements, different authorization patterns, and different observability needs than a deterministic workload. Where workloads are treated in general, AI agents inherit unless explicitly distinguished; where AI agents are treated specifically, the AI Agent constituency is the unit of analysis.

Facet 2. Technical Environment

Where the resources sit and how subjects encounter them. CAI organizes the technical environment into four sub-facets (Channel, Infrastructure, Data, and Application), each of which can be deployed on-premises, in the cloud, or in hybrid combinations. The four sub-facets are inhabited by different resources, defended by different controls, and integrated into the identity system through different patterns; treating them as separate is what allows the matrix to express the differences.

On-premises and cloud are not parallel categories of equal substance; they are deployment modes that qualify each sub-facet. A subject encounters an application channel that is hosted on-premises or in the cloud; the subject's machine workload runs on infrastructure that is on-premises or in the cloud; the data being accessed is stored on-premises or in the cloud. Cloud further subdivides into IaaS, PaaS, and SaaS where the distinction matters for control design.

Table 6. The technical-environment facet: four sub-facets and their deployment range.

Sub-facet	Description and deployment range
Channel	The user-facing surfaces (web, mobile, native applications, API, voice, conversational interfaces). Where humans encounter resources and where customer authentication, consent, and progressive interaction live. Channel resources can be hosted on-premises (rare in modern deployments) or delivered through cloud infrastructure or SaaS.
Infrastructure	The platforms, runtimes, and substrates beneath everything else (networks, hosts, hypervisors, clusters, container platforms, service meshes). Where workloads run and where machine-to-machine communication is established. Infrastructure spans on-premises data centers, cloud IaaS (virtual machines, networks, storage), and cloud PaaS (managed databases, container platforms, serverless runtimes).
Data	The information surfaces (databases, data lakes, warehouses, files, streams). Where access is governed by classification, lineage, purpose, and retention as well as by subject identity. Data resources span on-premises databases and file systems, cloud-native databases and lakes, and SaaS-managed data.
Application	The business systems, services, and APIs that subjects act through. Where authorization is most often expressed as application-specific permissions and where most of the runtime authorization work happens. Applications span on-premises (custom enterprise applications, legacy systems), cloud (custom applications hosted on IaaS or PaaS), and SaaS (third-party applications consumed as a service, the fastest-growing application surface in most enterprises).

The four sub-facets compose. A specific access (a customer accessing a banking application through a mobile channel, with the application running in cloud PaaS, reading from a cloud-hosted data warehouse) is qualified by all four. The matrix in the next section uses the technical environment as a coverage axis; the cross-product of the four sub-facets and the on-premises/cloud deployment range is the full surface.

Most enterprises operate hybrid environments (on-premises and cloud, usually with multiple cloud providers), and most are likely to continue doing so. CAI's control treatments cover the full deployment range rather than assuming a target end-state.

Facet 3. Business Environment

Whose business is being supported and where it operates. Coverage is not only technical. IAM operates inside a business structure with operating units, subsidiaries, and geographies, and the controls must work across all of them. Mergers, acquisitions, divestitures, and international expansion all show up here, as do regulatory regimes that vary by jurisdiction.

CAI View In a federation agreement, the relevant decision is often not “is this user allowed?” but “is this organization trusted to assert this claim, under this agreement, for this transaction?” Trust frameworks, verifiable-credential issuers, B2B authorization, and supply-chain identity all make the organization itself the subject of trust rather than a container for users. That is why Organization is a first-class constituency in the coverage model, not a grouping attribute.

Table 7. The business-environment facet: dimensions and sub-environments.

Dimension	Sub-environment	Description
Operating Unit	Business unit	Internal organizational divisions. Often have distinct application portfolios, governance requirements, identity sources, and operating tempos. Cross-business-unit access is a recurring source of audit findings.
Operating Unit	Subsidiary	Legally separate entities under a common parent. Often have distinct HR systems, distinct directories, distinct regulatory exposure, and constraints on cross-entity data sharing. The IAM challenge in subsidiaries is balancing autonomy with consistency.
Location	Domestic	Operations within the enterprise's home jurisdiction. The default regulatory regime; the assumed legal framework; the simplest baseline.
Location	International	Operations in other jurisdictions. Subject to data residency, privacy, sectoral, and trade regulations that often differ from the home jurisdiction. Multi-jurisdiction operation is the norm rather than the exception in CAI's customer base. The most consequential variations are around customer data, employee data, cross-border data transfer, and AI regulation.

Business environment is the facet most often overlooked in technically-led IAM programs. CAI flags it as a first-class facet because the consequences of overlooking it (opaque cross-subsidiary access, regulatory misalignment, divestiture entanglement, and surprise audit findings) are large and recurring. A control that works in the parent entity but breaks across a subsidiary boundary, or works in the home jurisdiction but violates a foreign data residency rule, is not a control that covers the matrix.

Capabilities

Capabilities are how control and coverage instances get filled. A capability (identity governance and administration, privileged access management, runtime authorization, identity threat detection, and so on) is the bundle of processes, tools, and data that delivers a specific control to a specific coverage area, or to several at once.

What a capability is made of

Every capability has three components. The components are how a capability is bought, built, and operated to deliver the intended controls.

Table 8. The three components of a capability: processes, tools, and data.

Component	Description
Processes	The defined sequences of work the capability performs. Documented, repeatable, owned.
Tools	The platforms, systems, and software the capability runs on. Bought from vendors, built in-house, or some combination.
Data	The information the capability consumes and produces. The data is what makes the capability auditable, observable, and improvable over time.

Capabilities cross multiple instances

A single capability typically delivers controls to several coverage areas. Identity Governance and Administration delivers governance controls to the workforce, partner, and (often) customer constituencies, across all technical environments and all business environments. Privileged Access Management delivers governance and runtime controls to the workforce constituency, focused on the on-premises infrastructure environment but increasingly extending to cloud.

Control and coverage instances are the unit of accountability and coverage; capabilities are the unit of delivery. The matrix is the way to verify that every instance has at least one capability behind it.

Figure 3. Control and coverage instances are the unit of accountability; capabilities are the unit of delivery. The relationship is many-to-many.

Accountability

Every control and coverage instance in the matrix has an accountable owner. The owner is the person, by role, accountable for ensuring the relevant control is applied to the relevant coverage area. Without named accountability, instances drift: nobody updates the policy, nobody reviews the certification, nobody responds when the observability signal fires. CAI considers explicit ownership of every control and coverage instance a non-negotiable property of a working IAM program.

Who owns what

Accountability for a control and coverage instance is an organizational role, not a functional task within the IAM team. The owner may delegate the work; the owner cannot delegate the accountability. Common ownership patterns CAI observes:

Table 9. Coverage areas and their typical accountable owners.

Coverage area	Typical accountable owner
Workforce constituency	IAM Director or Identity Program Lead, accountable to CISO or CIO. Often partnered with HR for the lifecycle source of truth.
Customer constituency	CIAM Owner, often a product or business role rather than a security role, partnered with the security team. Accountable to the head of digital, head of customer experience, or chief product officer.
Partner constituency	Federation Lead or B2B Identity Owner, often shared accountability between IAM and the business sponsor of the partner relationship.
Device constituency	Endpoint or device team, partnered with IAM for identity issuance and posture binding. Accountable to the head of IT operations.
Workload constituency	Platform engineering or infrastructure team, partnered with IAM. Accountable to the head of platform or engineering.
AI Agent constituency	Often a hybrid arrangement in current practice: AI platform owner partnered with IAM for identity issuance, with security oversight for delegation and behavioral monitoring. The accountable owner is increasingly being formalized as a dedicated role ("Head of AI Identity" or similar) as the constituency grows.
Organization constituency (trust frameworks, federation)	IAM Director or external relations, accountable to the CIO or general counsel for legal aspects of trust agreements.
Channel sub-facet	Digital channel owner (often a product or marketing role for customer channels and an IT operations role for workforce channels), partnered with IAM.
Infrastructure sub-facet	Infrastructure or platform team, partnered with IAM for workload identity and infrastructure access controls.
Data sub-facet	Data Governance Owner or Chief Data Officer, partnered with IAM for the identity-related controls (purpose-based access, consent enforcement, lineage-aware authorization).
Application sub-facet	Application owner per major application portfolio, partnered with IAM for application-specific entitlements and runtime authorization.
Business unit / subsidiary coverage	Business unit IAM lead or local IAM partner, accountable to the local CIO or local CISO. Federated to the central IAM organization for standards.
Geographic / regulatory coverage	Regional IAM lead or regional compliance partner, accountable to the regional CIO or general counsel.
Programmable-controls posture (across the matrix)	IAM Architect or IAM Engineering Lead, accountable to the IAM Director. The owner of the policy-as-code substrate, the identity pipeline, the runtime enforcement points, and the standard for what programmability means in this enterprise.

The patterns are starting points, not prescriptions. The right ownership map for a specific enterprise depends on its structure, regulatory exposure, and the maturity of its IAM organization.

Accountability without ownership is decoration

CAI has observed two failure modes that produce the appearance of accountability without the substance. The first is committee ownership: a steering group is named, no individual is, and decisions go unmade. The second is title-only ownership: an executive is named for organizational reasons but the work and the data flow elsewhere. A working accountable owner is a named individual with the authority to direct the work, the visibility to see the state of the instance, and the consequences attached to its outcomes.

Watch-Out When asked to identify the accountable owner of a control and coverage instance, an IAM organization that names a committee, a department, or a vacant role is signaling that nobody is accountable. The honest answer ("this instance is currently unowned") is more useful than the polite one. Unowned instances are the ones that fail audits and produce breaches.

Conclusion

This Root Document develops CAI's analytical frame for identity and access management. The frame is a single argument: build and operate an IAM infrastructure that delivers controls (Governance, Runtime, Observability) across coverage areas that span every identity constituency, every technical environment, and every business environment. The Control and Coverage Matrix that results is the practical artifact the analysis produces. Every control and coverage instance is accountable to a named owner, delivered through capabilities with their own processes, tools, and data, and increasingly authored as programmable code that adapts at runtime. Programmable controls are the modernization shift that lets the matrix become operational at scale.

Acronyms 

Table 10. Acronym key for terms used in this report.

Acronym	Expansion
ABAC	attribute-based access control
A2A	agent-to-agent (protocol family)
AuthZEN	Authorization Engine specification (OpenID Foundation)
CAEP	Continuous Access Evaluation Profile
CIAM	customer identity and access management
CIEM	cloud infrastructure entitlement management
DID	decentralized identifier
DPoP	Demonstrating Proof of Possession
FIDO	Fast IDentity Online (Alliance and standards)
GNAP	Grant Negotiation and Authorization Protocol
IAM	identity and access management
IdP	identity provider
IGA	identity governance and administration
ITDR	identity threat detection and response
MCP	Model Context Protocol
mDL	mobile drivers license (ISO/IEC 18013-5)
NIST	National Institute of Standards and Technology
OAuth	Open Authorization
OBAC	ontology-based access control
OIDC	OpenID Connect
OPA	Open Policy Agent
PAM	privileged access management
PAR	Pushed Authorization Requests
PBAC	policy-based access control
PDP	policy decision point
PEP	policy enforcement point
PKI	public key infrastructure
RAR	Rich Authorization Requests
RBAC	role-based access control
ReBAC	relationship-based access control
SAML	Security Assertion Markup Language
SCIM	System for Cross-domain Identity Management
SIEM	security information and event management
SOAR	security orchestration, automation, and response
SoD	segregation of duties
SPIFFE	Secure Production Identity Framework for Everyone
SSF	Shared Signals Framework
SSO	single sign-on
SVID	SPIFFE Verifiable Identity Document
UEBA	user and entity behavior analytics
VC	verifiable credential
VP	verifiable presentation
WIMSE	Workload Identity in Multi-Service Environments
XACML	eXtensible Access Control Markup Language
ZTA	Zero Trust Architecture
ZTNA	Zero Trust Network Access

Evidence

CAI’s observations and positions in this document draw on the author’s independent research: publicly available information, industry standards, academic papers, and insight from discussions with end-user organizations across the public and private sectors in a range of industries, together with vendor briefings, interviews, and product demonstrations.

Standards and specifications referenced

The principal standards and specifications this document refers to, with their issuing bodies and identifiers, are:

• OAuth 2.0 and its modern extensions. IETF RFC 6749 (2012), with Pushed Authorization Requests (RFC 9126, 2021), Rich Authorization Requests (RFC 9396, 2023), Demonstrating Proof of Possession / DPoP (RFC 9449, 2023), and Mutual-TLS client authentication (RFC 8705, 2020); the OAuth 2.1 consolidation is in progress at the IETF.
• GNAP. Grant Negotiation and Authorization Protocol, IETF RFC 9635 (2024).
• OpenID Connect and AuthZEN. OpenID Connect Core 1.0 and the AuthZEN Authorization API 1.0, both from the OpenID Foundation; AuthZEN standardizes the policy-enforcement-to-policy-decision interface.
• Shared Signals Framework and CAEP. The Shared Signals Framework and the Continuous Access Evaluation Profile, OpenID Foundation (Shared Signals Working Group).
• Verifiable credentials. OpenID for Verifiable Credential Issuance (OpenID4VCI) and OpenID for Verifiable Presentations (OpenID4VP), OpenID Foundation.
• SAML 2.0 and XACML 3.0. OASIS Standards (2005 and 2013), the earlier-generation federation and authorization standards still widely deployed in regulated environments.
• SCIM 2.0. System for Cross-domain Identity Management, IETF RFC 7643 and RFC 7644 (2015).
• FIDO2 and passkeys. W3C Web Authentication (WebAuthn) and the FIDO Alliance Client to Authenticator Protocol (CTAP), with passkeys as the consumer profile.
• Workload identity. SPIFFE / SPIRE (Secure Production Identity Framework for Everyone, CNCF) and the IETF WIMSE (Workload Identity in Multi-System Environments) work, currently in progress.
• Policy languages. Open Policy Agent and its Rego language (CNCF), Cedar, and the IDQL / Hexa initiative for cross-platform identity policy.

Related Reading

The Root Document is the entry point to a larger library that is published incrementally rather than all at once. Over time, further reports will treat specific parts of the frame in the depth this document cannot: individual capability domains, each control category, and the coverage facets the matrix defines, together with the patterns and practices that recur across them. Those reports are released as they are completed, so the library grows steadily.

• 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.

Methodology

This Root Document rests on CAI’s continuing research into identity and access management practice, including direct engagement with enterprises across financial services, healthcare, technology, manufacturing, retail, and the public sector. Observations about recurring patterns come from those engagements; judgments about direction combine them with structured review of standards-body activity, vendor roadmaps and briefings, and the public record of identity-related incidents. The frame is held to one test throughout: whether it organizes what practitioners actually encounter.

CAI’s positions are research outputs and reflect its editorial judgment. Where CAI’s reading of an issue departs from the prevailing market view, the difference is stated plainly rather than smoothed away. Readers are invited to disagree on substance; CAI treats sustained, substantive disagreement as a signal worth examining and a prompt to revisit the frame.

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.