> ## Content Index > Fetch the complete content index at: https://research.controlarch.org/llms.txt > Use this file to discover other available public pages before exploring further. # Identity and Access Governance Controls - URL: https://research.controlarch.org/identity-and-access-governance-controls/ - Published: 2026-07-30T16:32:20.000Z - Updated: 2026-08-27T13:47:41.000Z - Description: Identity and access governance is the oldest, least-defined part of IAM, and enterprises keep buying the product category while believing they have acquired the control. This report separates the two: the admin-time control that decides who or what gets access, on whose authority, before runtime. - Author: Homan Farahmand - Tags: Foundation Report, IAM, Governance, IGA, PAM, Authorization, Admin-time [Identity and Access Governance ControlsThe admin-time control: what access is decided, and on whose authority, before runtimeIdentity and Access Governance Controls.pdf2 MBdownload-circle](https://research.controlarch.org/content/files/2026/08/Identity-and-Access-Governance-Controls-1.pdf "Download") ## Observations Identity and access governance is the oldest part of identity and access management and the least well defined. The market treats it as a product category: the identity governance and administration platform (IGA), the certification campaign, the access request form. The effect is that the enterprise buys the category and believes it has acquired the control. This report separates the two. The five observations below describe the landscape as CAI finds it. - **Governance authority is fragmented across control planes by coverage.** The admin-time decision is made today in the identity governance platform, the privileged access platform, cloud entitlement management, application administration, the data governance stack, the deployment pipeline, and now the agent registry. The governed object is not the same in any two of them. A declared entitlement, a computed effective permission, a purpose-bound classification, and a chain-of-trust credential are different things, and no single governance model holds them all. Authority fragments because each object arrived with its own owners and vocabulary before anyone tried to govern them together. The abstract access binding is common to every case. What differs by constituency and environment is its authorization basis, its resolution mechanism, its evidence, its lifecycle, and the point at which it takes effect. - **The key failure is loss of access binding integrity across the lifecycle, not the absence of an approval workflow.** Approval workflow is common in the enterprises that run an IGA platform. The failures that produce audit findings and breach paths sit elsewhere: weak authoritative source data, entitlements no reviewer can interpret, missing resource and role ownership, exceptions granted and never recorded, provisioning that fails silently, deprovisioning that lags the leaver event, and remediation that is approved and never executed. The requirement to provision, modify, review, and remove access is already written into the control standards. What is missing is not the requirement but the verification that it was carried out. - **The field cannot effectively measure the quality of an access review.** The critique of periodic certification is that it measures completion rather than justification. But the statistics offered in its support do not resolve to independent primary research. They circulate through vendor and practitioner publication without traceable attribution. A professional body proposed concrete review-quality measures years ago1, and the field still quotes unsourced figures. An enterprise that redesigns its review program today cannot prove the redesign worked, only that it ran. - **Roles remain a useful compression, but a measurably better role model can be no better governed.** The role-mining literature is mature and its objective functions are explicit: it optimizes structural complexity and, in its more advanced form, alignment to organizational structure and business process. The measures reviewed for this report do not encode who is accountable for a role, whether a policy conflict has been adjudicated, whether an exception was recorded, or whether a reviewer could defend a decision made against it. A role model can score well on every published measure of quality and leave the governance questions unanswered. - **Workloads and agents did not create a new governance category; they removed the timing slack that hid the old failures.** Human lifecycle processes tolerate latency because the population changes slowly. Workload and agent populations remove that tolerance: they are created and destroyed at machine tempo, ownership and delegation must be explicit because no manager relationship supplies them, and an agent that inherits a person’s entitlements destroys attribution. Recent NIST and IETF-community work on the problem generally begins with existing identity, credential, delegation, and authorization mechanisms, while identifying where those mechanisms may need extension for agents. ## Positions CAI takes five positions on what identity and access governance is and how an enterprise should build and operate the key controls. - **Define governance by the authority it establishes, not by the product category that implements it.** Governance is the admin-time system that decides and maintains who or what should have access to which resource and action, under which policy and conditions, for what purpose and duration, and on whose authority. IGA platforms, privileged access management (PAM) platforms, approval workflow, certification, role management, and policy administration are capabilities that deliver parts of it. - **Govern complete access bindings and control-and-coverage instances, not just isolated accounts, roles, requests, or campaigns.** Every material assignment must resolve to a subject, an identity or account, a resource, a permitted action, an entitlement or policy basis, an authority, an owner, a lifecycle state, conditions, and evidence. The policy-basis element is constituted differently in each coverage area: it may be declared, computed, classified, consented, or attested. A governance model that assumes a declared entitlement will fail wherever the object is something else. - **Move the center of governance from certification to lifecycle, evidence, and verified closure, and measure its effectiveness.** Periodic certification keeps its place where regulation or residual risk requires it. It must stop compensating for poor lifecycle data, uninterpretable entitlements, absent ownership, and failed revocation. Because the industry’s circulating measures of review quality are supplied by the parties selling the remedy, an enterprise must define and own the measure by which it judges its own program effectivness. - **Keep roles as a compression and delegation mechanism; abandon the stable enterprise-wide role model as the end state.** Combine business and technical roles with attributes, relationships, purpose, risk, time, policy, direct assignment, and recorded exceptions. Judge a role model by interpretability to the person who must decide against it, by ownership, maintenance cost, coverage, exception load, and resulting decision quality. Do not judge it by the share of entitlements forced into roles, or by the structural measures the mining literature optimizes. - **Engineer governance controls as versioned, testable artifacts while keeping authority named.** Source-of-truth policy and configuration as code, automated testing, simulation, controlled deployment, rollback, event processing, and drift detection are the target posture. An interface, export, script, or model recommendation layered over a console-controlled source of truth is not equivalent. Automation may execute or recommend a decision; it never removes the requirement to identify the person, organizational role, or approved policy the authority derives from. ## The Control and Coverage Matrix in Brief This report is one of a set that share a single organizing instrument, the CAI Control and Coverage Matrix. The matrix is described in full in the Root Document; the summary here is the canonical short form carried by every Foundation Report so that each reads standalone. The matrix has a control axis, a coverage axis, and a substrate beneath both. 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. This report treats the Governance category. The coverage axis has three facets that qualify every access at once. - **Identity constituency:** human (workforce, customer, partner), machine (device, workload, agent), or organization. - **Technical environment:** channel, infrastructure, data, and application, each across on-premises and cloud. - **Business environment:** operating unit, subsidiary, and jurisdiction. Beneath both axes sits the 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. Each intersection of a control category with a coverage area is a control-and-coverage instance: a discrete unit of accountable work, 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; its posture is how completely those instances are covered and owned. Capabilities are the unit of delivery, and one capability typically serves several instances. Instances are the unit of accountability, and each has exactly one accountable owner. > **CAI View** A governance program organized around its platforms produces a coverage map shaped like its purchase history. A program organized around the matrix has to address the instances with weak controls or no owner, and that is where breaches and audit findings concentrate. ## What Governance Is, and What It Produces Begin with a digital action and reason backward. At runtime, a subject attempts an action on a resource. Runtime enforcement can decide that attempt only if the authoritative state it needs already exists: an identity, an entitlement or policy, a delegation, a set of conditions. That state did not appear on its own. It was created, justified, approved or derived from policy, recorded, provisioned, changed as circumstances changed, and eventually removed. Governance is the control category responsible for deciding and maintaining that intended state before the action occurs. Runtime decides whether the attempt is allowed at the moment it is made. Observability records what actually happened and returns evidence that may change the next governance decision. A concept that cannot be placed somewhere in that chain is either out of scope for this report or not yet properly defined. What governance produces is therefore not a document, a workflow record, or a completed campaign. Governance produces and maintains an intended, authoritative access state: the set of access bindings that say, at any moment, who or what is supposed to be able to do what, on whose authority, under what conditions, and until when. Runtime consumes that state. Observability measures the distance between the intended state and the actual one. The value of the governance category is that the intended state is correct, current, owned, and evidenced, not that a process ran to produce it. This is why the report defines the category by its authority rather than by its tooling. Identity governance and administration, privileged access management, access certification, role management, and policy administration are real capabilities that deliver parts of the category. But an enterprise can hold all of them and still have no coherent answer to the question the category exists to answer, because the capabilities were bought as products and the question is architectural. > **CAI View** A completed workflow is evidence that a process ran. It is not evidence that the resulting access is correct, live only where intended, or removed when it stopped being justified. The report treats those as different claims because the enterprise must. ## The Admin-Time Control Point It is common to describe administration as the setup phase and enforcement as the real control. That framing is wrong in a way that matters. Admin-time is itself a control point, with its own inputs, its own outputs, and its own failure modes, and in CAI’s assessment most governance failures originate here rather than at runtime. The inputs to the admin-time control point are the authoritative sources of truth about subjects and resources, the policies that govern assignment, the ownership records that establish who may decide, and the evidence that informs a decision. Its outputs are the bindings that runtime will later enforce and that observability will later measure. Its failure modes are specific and well understood: - a source that is stale or wrong - an entitlement that no human can interpret - an owner who does not exist - an exception granted outside the record - a provisioning action that does not complete - a deprovisioning action that never fires Each of these is an admin-time failure that surfaces, if it surfaces at all, as a runtime or observability event much later. The established control frameworks already treat admin-time as a control surface, even if they do not use the term. The federal control catalog places account management, separation of duties, least privilege, and the periodic review of privileged access in its access-control family, and its audit family requires that the actions taken at this control point be recorded and reviewable. The information security management standard splits the same surface across four controls: the access-control policy that sets the rules, identity management that governs how an identity is created, authentication information, and the access rights that are provisioned, reviewed, modified, and removed against those rules.2 ## Boundaries and the Feedback Loop Governance, runtime, and observability form a closed loop, and the value of keeping them distinct is precisely that each remains separately auditable. Governance establishes the intended access state. Runtime resolves that governed intent against a specific attempted action and the current context; the exact subject-resource-action relationship may be evaluated only at that moment, but the authority and policy it draws on were governed beforehand. Observability produces evidence about actual use, drift, abuse, failure, and control performance, and that evidence feeds the next governance decision. The loop is real and the enterprise should build it. What the enterprise must not do is collapse the three points into one. The temptation to collapse them is strongest at the two adjacencies. On the runtime side, a sufficiently dynamic authorization system can appear to make the governance decision at the moment of access, and the distinction between deciding who should have access and deciding whether to allow this attempt begins to blur. On the observability side, an analytics platform that recommends and even executes access changes can appear to be governing. In both cases the boundary is what preserves accountability: a decision made and recorded at admin-time can be reviewed against the authority that made it, whereas a decision dissolved into runtime evaluation or observability automation leaves no admin-time record to review. > **Watch-Out** Feeding observability evidence back into governance is correct and valuable. Letting observability make the admin-time decision is not. Quietly adjusting entitlements because usage analytics suggested it, with no governed record of who authorized the change, dissolves the boundary that makes either category auditable. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-1-8.png) **Figure 1.** Governance, runtime, and observability as three control points on one timeline, joined by an evidence loop that does not merge them. Terms used precisely throughout this report are collected in the Definitions at the end of this report. ## The Governed Access Binding The object of governance is not an identity record, an account, a role, a request, a certification campaign, or a governance product. It is the governed access binding: the authoritative relationship that says a particular subject may perform a particular action on a particular resource, under a particular policy and set of conditions, for a stated purpose and duration, on a named authority, under a named owner, with evidence to support the decision and a lifecycle state that records where the relationship currently stands. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-2-6.png) **Figure 2.** The governed access binding as a single object with its named elements, any one of which can be the element that is missing or wrong. Stating the object this way changes what counts as a governance failure. A completed access request that produced a live entitlement with no recorded owner is a defective binding, even though the workflow succeeded. An entitlement that is still provisioned after the subject changed roles is a binding whose lifecycle state is wrong, even though nothing failed visibly. Sustained non-use weakens some access justifications and should trigger reassessment, though it is not by itself proof that an access is unjustified. In each case the workflow record looks clean and the binding is defective, and it is the binding, not the workflow, that runtime will enforce. The elements are not equally likely to be the one that fails. In practice the recurring defects are a missing or unusable entitlement definition, a missing owner, a lifecycle state that lags reality, an unrecorded exception, and evidence that was never captured or never consulted. A governance program that tracks requests and approvals but not these elements is measuring the part of the object least likely to be wrong. **Finding the defects.** Finding defective bindings does not require new tooling, only the discipline to look for the elements the workflow does not check. Four queries surface most of them, and each is computable from data the enterprise already holds: - entitlements with no recorded owner - entitlements still provisioned to a subject whose role changed after the grant - grants with no last-use evidence in a stated window - removals a review approved but no system confirms were executed Each returns a list an owner can act on this week. > **CAI View** A completed workflow is evidence that a process ran. It is not evidence that the resulting access is correct, live only where intended, or removed when it stopped being justified. ## Coverage: One Assumption, Many Objects The governed binding is not for the same object across the coverage surface, and this is the central architectural fact of the category. Governance products are typically built for one object: a declared entitlement held by a person sourced from a human-resources feed. They extend outward from it. Every step away from that assumption changes what is being governed, and coverage degrades in proportion to the distance. This is why authority fragments. Each object arrived with its own owners, its own vocabulary, and its own tooling before anyone tried to govern them together. **A coverage self-test.** A short test reveals how far an estate’s governance reaches beyond the workforce object. For each coverage area, ask three questions: is the governed object stored or computed, does it have a named owner, and where does its lifecycle event come from. Where the answers are computed, unowned, and no clear event source, as they commonly are for cloud effective permissions, service accounts, and agents, the estate has a coverage gap it may never have counted, because the tooling built for a stored, owned, feed-driven entitlement quietly reports the gap as empty rather than as uncovered. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-3-7.png) **Figure 3.** The coverage areas and their several distinct governed objects against one product assumption, with governance coverage falling as distance from that assumption grows. Illustrative CAI model; values and relative positions are not derived from an industry dataset. ### The identity constituency The constituency facet asks whose or what identity is being governed. The governed object, the source of authority, and the meaning of certification all change as the facet changes. **Table 1.** The governed object, authority and lifecycle, and coverage state for each identity constituency*.* | **Constituency** | **Governed object** | **Authority and lifecycle** | **Coverage state** | | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Workforce** | A declared entitlement held by a person. | Human-resources feed is authoritative. Joiner, mover, and leaver events are generated upstream. Manager or resource owner approves. | Established. The case every product is built for. | | **Contractor and contingent (a workforce subtype, governed differently)** | The same object, frequently outside the authoritative feed. | Often no authoritative source. Sponsorship substitutes for employment; the end date is the control most often missing. | Uneven. Governed by workforce tooling without a workforce source. | | **Customer** | Consent and purpose as much as entitlement. | No human-resources equivalent. Identity is self-asserted; registration, activation, dormancy, and closure replace joiner-mover-leaver. | Uneven, and governed by a different discipline. Workforce-style certification has no natural reviewer. | | **Partner and third party** | An entitlement inside the enterprise, on an authority outside it. | Delegated administration inverts the model: the partner’s own administrator manages users in the enterprise’s systems. Federation is the control boundary. | Uneven. Needs an organizational hierarchy the workforce model lacks; multi-hop delegation is unsolved. | | **Device** | A cryptographic credential: issued, rotated, revoked, expiring. | Enrollment and decommissioning replace lifecycle events; ownership is often assumed rather than recorded. | Thin and split across teams. The failure surfaces as an outage at certificate expiry. | | **Workload and service account** | An effective permission, computed rather than declared, plus the credential. | Deployment and decommissioning at pipeline tempo. The creating engineer often leaves before the workload does. | Uneven. Governed by cloud-native and secrets tooling rather than identity governance. | | **AI agent** | Delegated authority: whose authority, for what purpose, in what scope, until when. | Registration, retraining, rotation, retirement at machine tempo. Owner and backup owner must be explicit. | Emerging. Commonly treated as a generic service account today. | | **Organization** | A credential in a chain of trust, and the agreement that governs it. | The one constituency where admin-time authority is explicitly modelled and interoperable. | Established in specific ecosystems, absent from enterprise governance. | The organization constituency deserves particular attention because it is the most under-recognized cell in the matrix and because it disproves an easy assumption. The verifiable legal-entity-identifier ecosystem has built a working admin-time authority model: a root of trust, delegated identifiers issued to qualified issuers, an entity credential issued to a legal entity, and role credentials issued to the people who represent that entity, with an authorized representative instructing issuance and revocation. Authority is named, delegation is explicit, revocation is a first-class operation, and the whole chain is cryptographically verifiable across organizational boundaries. Enterprise identity governance does not reference this work, and it should. The vLEI ecosystem establishes legal-entity and representative authority. It does not by itself determine whether a representative may perform a particular action on an enterprise resource. The hypothesis worth testing is that it could become the substrate for the partner constituency, and for the federation agreements that are today governed by legal documents and bilateral configuration rather than by verifiable credentials. Connecting representation authority to enterprise resource-authorization policy is the work that remains.3 ### The technical and business environments The same two questions, what is the governed object and who holds authority, reshape the binding again as the technical environment changes. - **Infrastructure.** The object stops being a declared entitlement and becomes an effective permission, computed across policy layers, inherited group membership, and cross-account role assumption. An entitlement catalog cannot hold it, because it is derived rather than stored. - **Data.** A parallel governance stack already exists, built from catalogs, classification, lineage, policy tags, and purpose, and overseen by data owners and stewards. Purpose is a governed dimension here that has no workforce counterpart. - **Application.** Native permission models rarely map cleanly to the enterprise catalog, so the catalog holds a coarse proxy. Enterprise resource planning is the mature case, where separation of duties is genuinely operationalized, and software-as-a-service administration is where shadow governance concentrates. - **Channel.** The thinnest of the four. Most entitlement catalogs carry no channel dimension, and the one channel governed explicitly, the interface or API channel under open banking pressure, is governed separately from the workforce catalog, by different people, with its own approval and revocation path. Two of the four technical environments deserve a closer look, because they are where the declared-entitlement assumption breaks most completely. In the infrastructure environment, the thing an enterprise most needs to govern is the actual reach of an identity across cloud services, and that reach is not written down anywhere as an object. It is the net result of policies attached to the identity, policies attached to the groups and roles it belongs to, permissions inherited through resource hierarchies, and roles it can assume in other accounts. A separate product category, cloud infrastructure entitlement management, exists precisely because that effective reach must be computed rather than read. But that category discovers and reports. It does not decide or own. Where its findings are not wired into the governance decisions of review and removal, the same excess turns up on every scan, faster each time and no less present. The lesson is not that the enterprise needs another analytics tool. It is that the governed object here is derived, and a governance model built on stored entitlements cannot hold it. The application environment shows the opposite failure: not a computed object but a mistranslated one. Application-native permission models rarely map cleanly onto the enterprise catalog, so the catalog holds a coarse proxy, a role name that stands in for a set of application permissions the catalog cannot see inside. The mature exception is the enterprise resource-planning system, where separation of duties is genuinely operationalized down to the transaction level. It is worth asking why that environment succeeded where others have not. The answer is that the permission model, the conflict rules, and the ownership were built together as one governed system rather than bolted on afterward. Among the fast-growing and least governed application surfaces is software-as-a-service administration. There, each application’s own administrative rights are granted inside the application by a business owner, outside any central workflow. That is shadow governance the enterprise catalog does not know exists. The business environment adds the last reshaping. In CAI’s assessment, the multi-tenant estate is now the default. - **Operating units and subsidiaries.** Acquisitions arrive with their own directory, their own tenant, and their own governance; divestitures leave tenants behind; residency requirements create more. - **Jurisdiction.** Location becomes a property of the binding rather than a deployment detail, so the same entitlement can be lawful in one jurisdiction and not another, and most entitlement models carry no jurisdiction qualifier. - **Merger, acquisition, and divestiture.** In CAI’s assessment, among the most reliable generators of governance failure in the category. Two role models collide and produce separation-of-duties conflicts that neither estate had alone, and divestiture requires proving that access was removed rather than granted, a negative far harder to evidence than a grant. > **Watch-Out** An entitlement catalog cannot hold a computed effective permission. Reviewing the catalog and believing the cloud estate has been reviewed is among the most consequential false assurances in the category. ## Authority, Accountability, Ownership, and Delegation Every material access decision resolves to a named authority. This is the property that distinguishes a governed binding from a merely existing one, and it is the property most easily lost as governance automates. Automation may execute a decision or recommend one; it does not become the authority for it. A governance record that cannot name the person, organizational role, or approved policy behind a material decision is incomplete regardless of how well the automation performed. Accountability and execution are different roles and should be recorded separately. The accountable owner of a control-and-coverage instance is the person answerable for the control being applied to the coverage area. The operator is whoever runs the process. Conflating them produces the appearance of ownership without the substance: an instance that a team collectively runs but no individual answers for. Two authority questions belong here and are often left implicit. - Who may accept the residual risk of an exception or a known gap. - How a conflict between two authorities is resolved when they disagree. A governance model that cannot answer both has not said who is in charge. Delegation is where authority most often crosses an organizational boundary, and the category contains three such crossings that share a shape. In all three the accountable authority sits outside the enterprise that bears the consequence, and in all three the multi-hop case, a delegation of a delegation, is only partially addressed. Current mechanisms handle portions of delegation and impersonation, but CAI has found no broadly adopted end-to-end model that preserves authority provenance, attenuation, expiry, revocation, and accountability across multiple hops. - **Partner delegated administration.** The partner organization’s own administrator holds authority over access inside the enterprise. - **Supplier-provided devices.** Identity responsibility sits with the supplier unless the contract assigns it otherwise. - **Agent delegation.** An agent acts on a human’s or an organization’s authority. In all three the accountable authority sits outside the enterprise that bears the consequence, and in all three the multi-hop case, a delegation of a delegation, is only partially addressed. Current mechanisms handle portions of delegation and impersonation, but no broadly adopted end-to-end model preserves authority provenance, attenuation, expiry, revocation, and accountability across multiple hops. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-4-4.png) **Figure 4.** The authority chain, marking the three points where it crosses an organizational boundary: partner delegated administration, supplier-provided devices, and agent delegation. > **CAI View** Automation may execute a decision or recommend one. It does not become the authority for it. A governance record that cannot name the human, organizational role, or approved policy behind a material decision is incomplete regardless of how well the automation performed. ## Lifecycle Across Constituencies There is one lifecycle model in the category, and it runs at different tempos with different authoritative sources. The workforce case is the familiar one: a joiner event from the human-resources system creates the identity, mover events adjust it, and a leaver event retires it, with the feed as the authoritative trigger throughout. The mistake is to assume that model everywhere. For three constituencies the authoritative source is not a human-resources feed, and it is often authoritative only for existence. Each source knows the object exists. Few know who owns it, why it exists, or what business justifies its access, and governance designs that assume a single feed carrying all of that will silently fail. The provisioning-side standards that exist, the cross-domain identity management protocol and its recent event profile, address the mechanics of propagating a lifecycle change, not the authority to make one.4 - **Customer.** Registers, activates, lapses, and closes on behavioral events recorded in a customer master or CIAM store. - **Device.** Enrolls and decommissions in a device-management platform or PKI inventory. - **Workload.** Deploys and is destroyed at pipeline tempo, recorded in a cloud control plane, pipeline, or service catalog. Each source knows the object exists. Few know who owns it, why it exists, or what business justifies its access, and governance designs that assume a single feed carrying all of that will silently fail. The provisioning-side standards that exist, the cross-domain identity management protocol and its recent event profile, address the mechanics of propagating a lifecycle change, not the authority to make one. Underneath every lifecycle event sits a quieter dependency: correlation and reconciliation. A lifecycle event is only as good as the enterprise’s ability to connect it to the accounts it should affect. When a subject holds several identities and many accounts across disconnected systems, a leaver event that fires cleanly in the authoritative source still leaves access live wherever the correlation is broken: the orphaned account no one connected back to the departed subject, the shared account that belongs to no one, the local account created outside the joiner process. These are not exotic edge cases. They are the ordinary residue of an estate assembled over years, and they are why lifecycle responsiveness is scored as a distinct operability dimension. An enterprise can have a fast, clean event pipeline and still fail to remove access, because the pipeline acts on the accounts it knows about and the risk lives in the ones it does not. The tempo difference is not cosmetic, though it is not simply human versus machine. Permissible revocation latency is set by privilege, blast radius, threat state, and reversibility rather than by whether the subject is a person or a process. A terminated privileged administrator or a compromised executive may require revocation within minutes, while some durable low-risk workloads tolerate far longer. What machine populations remove is the slack that made slow processes tolerable for ordinary access. They are created and destroyed at machine tempo, and the failures always latent in the workforce case, the leaver whose access lingers and the owner who has left, become acute when the population turns over in minutes and no manager relationship supplies the ownership. This is the mechanism behind the fifth observation: the machine constituencies did not introduce a new kind of failure, they removed the slack that hid the old one. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-5-4.png) **Figure 5.** One lifecycle model running at four tempos, from human-resources-driven months to pipeline-driven seconds. Illustrative CAI model; values and relative positions are not derived from an industry dataset. > **Watch-Out** Customer, device, and workload constituencies usually do have authoritative sources: customer masters, device-management platforms, PKI inventories, cloud control planes, deployment pipelines. But those sources are authoritative for existence, not for ownership, purpose, or business justification. Governance designs that assume a single human-resources-style feed carrying all four will silently fail. ## Entitlements, Roles, Policy, and Exceptions A role is a compression mechanism: it groups recurring access so that assignment and delegation stay manageable at scale. That is a real and durable benefit, and roles are not going away. What should go away is the belief that a stable, enterprise-wide role model is the destination, and that the measure of a governance program is the share of entitlements it has forced into roles. The role-mining literature is mature and worth reading precisely because it reveals the limit. The earliest role engineering was top-down and expensive; mining arose to derive roles bottom-up from existing assignments, optimizing structural measures such as the number of roles and the total complexity of the model. The more advanced work added business meaning, quantified as alignment to organizational structure and business process. But even the business-meaning measures stop short of the governance questions: none of the published measures CAI reviewed encodes who owns a role, whether a policy conflict within it has been adjudicated, whether an exception was recorded, or whether a reviewer could defend a decision made against it.5 The practical consequence is that a role model can improve on every published measure and leave the governance of access no better. CAI’s position is to judge a role model by interpretability to the person who must decide against it, by ownership, maintenance cost, coverage, exception load, and the resulting quality of decisions. Combine roles freely with attributes, relationships, purpose, risk, time, direct assignment, and recorded exceptions rather than forcing everything into the role structure. There is a standards reason the market’s hybrid models are all proprietary. The only standardized role model is more than a decade old and describes roles alone, not the hybrid of roles, attributes, relationships, and policy that practice has moved to. No standard describes the combined model, so every vendor’s version is its own.6 Two failure modes of the role model are worth naming because they are predictable and because they are consequences of using roles well, not badly. Neither is solved by mining a better model once; both require ongoing ownership and maintenance, which is why role model quality is scored as an operability dimension rather than assessed once at design time. A role catalog is a living control surface, and an unowned one decays into the very entitlement sprawl it was created to prevent. - Role explosion: as the enterprise pursues precise least privilege, the number of roles grows until the catalog is itself unmanageable, and a model designed to compress access instead multiplies the objects to be governed. - Role decay: organizations, applications, data, and responsibilities change continuously, and a role that was meaningful when it was engineered drifts out of alignment with the work it was meant to describe. Neither is solved by mining a better model once; both require ongoing ownership and maintenance, which is why role model quality is scored as an operability dimension rather than assessed once at design time. A role catalog is a living control surface, and an unowned one decays into the very entitlement sprawl it was created to prevent. > **Standards Note** The only standardized role model has not been substantively revised since 2012 and describes roles alone. Every hybrid assignment model in the market is therefore proprietary, and portability between them is correspondingly limited. ## Request, Approval, and Policy-Derived Assignment Not every justified access needs a bespoke human approval at the moment it is granted. The real design decision is where authority is pre-committed, and how that commitment is recorded. A per-transaction approval commits authority at the moment of the request; a policy-derived assignment commits it earlier, when the policy was authored and approved. Both are legitimate; the error is to treat the second as though no approval occurred. Policy-derived assignment does not remove the approval. It moves the approval to the authoring of the policy, where it should be recorded with the same rigor as a per-transaction approval, with a named authority, a version, and a test. The long-standing policy-language standard made the policy administration point an explicit architectural element, and its current draft revision moves the language toward being syntax-agnostic. That is the same programmability shift this report argues for at the level of governance as a whole.7 The governance requirement is the same in both cases. A material access must resolve to a named authority, whether that authority approved the specific request or approved the policy that produced it. What an enterprise must not accept is a policy-derived grant whose governing policy has no owner, no version, and no test. That is not automation of a decision. It is the absence of one. > **CAI View** Policy-derived assignment does not remove the approval. It moves it earlier, to the authoring of the policy, where it should be recorded with the same rigor as a per-transaction approval. ## Certification, Separation of Duties, and Closure Periodic access certification has become, in many enterprises, the center of the governance program. It should not be. Certification earns its place where regulation or residual risk requires a periodic attestation, but it cannot compensate for poor lifecycle data, uninterpretable entitlements, absent ownership, and failed revocation. When it is asked to, it produces the appearance of control without the substance. The widely repeated critique of certification is that reviewers approve most of what they see, spend little time per decision, and rubber-stamp under volume. It is almost certainly right in direction. CAI does not rely on it, because the figures offered in its support do not resolve to independent primary research. They recur across vendor and practitioner publication without traceable attribution, and the measurement instruments are owned by the parties selling the remedy. A professional body proposed concrete review-quality measures years ago, the proportion of users adjusted and the proportion of entitlements removed per campaign, and the field still quotes unsourced percentages instead. > **Watch-Out** The statistics most often cited to prove that certification fails do not resolve to primary sources. The critique is probably right; the evidence for it is not independent, and an enterprise cannot demonstrate improvement against a measure it does not own. The practical consequence is a CAI recommendation. An enterprise should define and own the measure by which it judges its own review program, rather than importing a vendor’s. A defensible measure set is available and cheap to compute from data the enterprise already holds. Three measures provide a practical starting point. Yield must be interpreted, not maximized. High yield can signal weak preventive controls, and reviewers can inflate it by revoking harmless access, so it is paired with verified-revocation latency and with the recurrence rate of access that a prior review already removed. None of these measures the completion of a campaign, and all of them measure what certification is supposed to achieve. - Remediation-closure rate: of the accesses a review decided to remove, what proportion were verifiably removed, and how quickly. - Decision-context coverage: the proportion of reviewed items shown to the reviewer with ownership, last-use evidence, risk, and policy basis attached, since a decision made without context is not a decision. - Targeted-review yield, read with care: the rate at which reviews scoped by risk and uncertainty produce changes, compared with broad calendar reviews. Yield must be interpreted, not maximized. High yield can signal weak preventive controls, and reviewers can inflate it by revoking harmless access, so it is paired with verified-revocation latency and with the recurrence rate of access that a prior review already removed. None of these measures the completion of a campaign, and all of them measure what certification is supposed to achieve. The redesign the measures point toward is a shift from the broad calendar campaign to event- and risk-triggered review. A calendar campaign reviews everything on a fixed cycle, which guarantees that most of what is reviewed did not need reviewing and that consequential changes wait for the next cycle. An event-triggered review fires when something happens that should prompt a look: a mover event, a privilege elevation, a role change, an anomaly in usage. A risk-triggered review concentrates reviewer attention on the accesses whose consequence or uncertainty is highest. Neither abolishes the periodic campaign where regulation requires one. Both reduce the volume of low-value decisions that produce reviewer fatigue in the first place. The lifecycle-event standards make the event-triggered model newly practical, and the operability bands score an enterprise higher for driving review from events and risk than for completing a larger calendar campaign on time. Separation of duties is the one place where certification’s discipline is genuinely load-bearing, because the object being controlled is a combination rather than a single grant. The control standards treat it as both preventive and detective, and mature enterprise-resource-planning implementations show that it can be operationalized. They also show that it breaks at organizational boundaries. A merger produces separation-of-duties conflicts that neither estate held alone, because the combination that is toxic in the merged entity was split across two entities before. Closure is the test that matters throughout: a conflict identified and not remediated, or a remediation approved and not executed, is a control that ran without controlling anything. ## Privileged and High-Impact Access Governance Privileged access governance is not a separate discipline. It is the same governed binding with a shorter tolerance for error, and treating it as a distinct product category is part of why the authority for privileged decisions fragments away from the rest of governance. The governed object is the same, namely a subject, a resource, an action, an authority, an owner, and a lifecycle state, but the consequence of a defective binding is larger. So the governance must be tighter: eligibility rather than standing grant, time bounds, named approval, and certification at a higher frequency. The strategic destination often stated for privileged access is zero standing privilege, realized through just-in-time elevation. That is a sound direction, but it is worth being precise about what is a control and what is a destination. Zero standing privilege is a property of the end state. The control is the governed decision about who is eligible, for how long, and on whose approval, that produces each temporary elevation. The federal control catalog requires privileged access to be reviewed at an organization-defined frequency and least privilege to be reassessed periodically. That is the same instinct, expressed as governed review rather than as elimination of standing rights.8 > **CAI View** Zero standing privilege is a destination, not a control. The control is the governed decision about eligibility, duration, and who may approve the elevation. That decision is the same governed binding as any other, held to a shorter tolerance. ## From Workflow to Event-Driven and Programmable Governance The direction of travel for the category is from periodic, console-bound, workflow-centric administration toward event-driven, evidence-bound, programmable governance. This report endorses that direction. It also insists on a distinction the market blurs: the enterprise must architect this shift itself, because no enterprise standard confers admin-time authority, and much of what is presented as standards-enabled progress is progress in adjacent categories. Consider the interface standards that matured in the last eighteen months. The cross-domain event profile carries lifecycle state as notification and is explicit that receivers decide their own follow-up. The shared-signals framework and its continuous-access-evaluation profile govern live sessions. The authorization API standardizes the runtime enforcement-to-decision interface. Each is genuinely useful, and none of them confers admin-time authority. Two of the three are runtime instruments, and the third is a notification profile.9 The gap is specific and worth naming precisely. No broadly adopted enterprise standard transports a complete governed authorization decision between governance systems: its authority provenance, policy basis, scope, purpose, conditions, expiry, exception status, and supporting evidence. Provisioning standards move accounts and entitlements, and the cross-domain event profile moves lifecycle notifications. Neither carries the authority semantics. There is a standardized way for a runtime system to ask for an authorization decision, and no adopted way for one governance system to tell another that authority was granted, on what basis, by whom, and until when. That gap is the strongest single argument for treating programmable governance as an enterprise architecture commitment rather than a purchase. The gap is one of adoption and scope rather than of possibility, and the proof is in the organization constituency. The verifiable legal-entity ecosystem demonstrates the kind of interoperable admin-time authority model that enterprise governance lacks: named authority, explicit delegation, first-class revocation, verifiable across boundaries, though its credentials establish legal representation rather than authorization to a particular enterprise resource. Policy frameworks and regulation are increasingly imposing oversight, logging, traceability, and accountable-deployment obligations that will shape agent governance. An agentic-AI governance framework treats verifiable agent identity and an authority audit trail as emerging best practice, and high-risk-AI rules place human-oversight and record-keeping duties on the deploying enterprise. They do not yet establish a generally applicable agent-identity or delegated-authority standard.10 The programmable posture has a consequence the enterprise should plan for deliberately: orchestration across multiple control planes, and the portability that orchestration requires. A governance estate that spans identity governance, privileged access, cloud entitlements, software-as-a-service, data, and agent registries will not be served by a single product, and the enterprise that waits for one is waiting for a convergence that relocates its integration problem rather than removing it. The durable design is composable: authoritative policy and configuration held as versioned source of truth the enterprise owns, deployed into whichever control planes enforce it, with the enterprise retaining the provenance, the portability, and the exit. This is also the honest reading of the vendor-operated governance option. An enterprise may legitimately have a vendor operate its governance infrastructure, but accountability does not transfer with operation; the enterprise remains the accountable integrator, and portability and exit must be designed in at the start rather than discovered at renewal. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-6-2.png) **Figure 6.** Where each current standard sits against the admin-time boundary, and the shape of the gap that no standard fills. > **CAI View** The verifiable legal-entity credential ecosystem has built a working admin-time authority model with named authority, explicit delegation, and first-class revocation. CAI found limited evidence that mainstream enterprise identity governance has incorporated it. The admin-time interoperability gap is one of adoption, not of possibility. ## Governance Operability Bands The category needs a way to describe how well an enterprise operates its governance controls, reusable across the three control-category Foundation Reports so that governance, runtime, and observability can be assessed on commensurable terms. The Governance Operability Bands are that schema. They measure an enterprise control system in operation. They do not measure a product, and they must never be read against a vendor capability score. **Table 2.** The governance operability bands, G0 through G5, and the entry condition that defines each*.* | **Band** | **Entry condition** | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **G0 Uncontrolled** | Relevant access state is absent, unknown, unowned, or cannot be reliably reconstructed. Material decisions depend on local administrators, shared accounts, inherited access, or undocumented exceptions. | | **G1 Recorded** | Some identities, accounts, entitlements, owners, approvals, and policies are inventoried. Coverage is partial, records are not consistently authoritative, and work is manual and reactive. | | **G2 Workflow-governed** | Lifecycle, request, approval, certification, role, separation-of-duties, and privileged-governance processes are repeatable and workflow-supported. Operation is batch-oriented, console-centric, and dependent on human follow-through. | | **G3 Evidence-bound** | Material decisions carry policy basis, ownership, business context, risk, usage evidence, expiry where appropriate, and verified remediation. Critical lifecycle events drive timely action. Decision quality is measurable against an instrument the enterprise controls. | | **G4 Programmable** | Policy and material configuration are versioned, reviewable, testable source-of-truth artifacts. Changes pass validation and simulation and deploy through controlled pipelines. Standardized interfaces and events support orchestration, rollback, drift detection, and multi-system closure. | | **G5 Adaptive** | Access state is maintained continuously across relevant constituencies using bounded, risk- and event-responsive automation. Controls scale to workload and agent tempo. Human or organizational authority stays explicit, reviewable, and able to override or halt the automation. | Each band is scored across eight dimensions, and the score is taken separately by identity constituency and, where material, by technical and business environment. The dimensions are: 1. coverage completeness and named accountability 2. authoritative source and data integrity 3. lifecycle responsiveness, including expiry and revocation 4. entitlement, role, policy, delegation, and separation-of-duties model quality 5. decision context, evidence, explanation, and authority provenance 6. remediation, exception, and conflict closure 7. programmability, testing, interoperability, and drift control 8. multi-constituency scalability, including workload and agent tempo **Scoring in practice.** Each dimension has an observable test, so a score is an evidenced reading rather than an impression. The tests below are the ones CAI uses; an enterprise may substitute its own, provided the score still rests on something it can point to. **Table 3.** The eight operability dimensions and the observable test that scores each*.* | **Dimension** | **One observable test: what you look at to score it** | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Coverage and accountability** | The share of critical control-and-coverage instances that resolve to exactly one named owner, not a team or a title. | | **Source and data integrity** | The reconciliation exception rate between authoritative sources and the accounts they should govern. | | **Lifecycle responsiveness** | Median time from a leaver or decommission event to verified removal of the access it should end. | | **Model quality** | Exception load per role, and the share of live grants no reviewer can interpret from their names. | | **Decision context and provenance** | The share of reviewed items presented with owner, last-use evidence, risk, and policy basis attached. | | **Remediation and closure** | Remediation-closure rate, and the recurrence rate of access a prior review already removed. | | **Programmability and drift** | Whether the source of truth is versioned and pipeline-deployed, and how much of the estate has drift detection. | | **Multi-constituency scalability** | Whether workloads and agents carry an explicit owner, delegation, and expiry, or inherit a human’s. | Four rules govern scoring. - A dimension marked not-applicable must be deliberate non-scope, never a disguised failure. - Every material score carries an evidence reference and a confidence of high, medium, or low. - A critical weak dimension or weak constituency is never averaged away; the result is presented as a profile, not a single number. - A programmability ceiling applies: a console-native or console-with-export source of truth cannot exceed G3 on the programmability dimension, and a control whose native source of truth is not versioned, testable, and pipeline-controlled is not G4 merely because an interface, provider, export, or script exists alongside it. There is a third case beyond scored and not-applicable, and the device constituency makes it necessary. Constrained devices cannot support uniform control depth, so an enterprise may deliberately govern a constituency to a lower depth as a risk-tiered choice. That is neither a failure nor non-scope; it is deliberate reduced depth, and the profile records it as such so that a lower score in a constrained constituency is not read as a gap. The bands apply a deliberate evidence discipline: a zero-to-five progression, per-constituency analysis, a not-applicable rule, an evidence-and-confidence requirement, and a programmability ceiling. One distinction must not be smoothed over: these bands measure an enterprise control system in operation, not vendor capability quality or market posture. An advanced product score is not evidence of advanced enterprise operation, and the two must never be read against each other. ![](https://storage.ghost.io/c/58/9d/589d195a-911d-45c2-9e6d-105a3db2389f/content/images/2026/07/figure-7-1.png) **Figure 7.** A governance operability profile across the eight dimensions and several constituencies, showing why a single overall number would destroy the finding. Illustrative CAI model; values and relative positions are not derived from an industry dataset. If a single overall band is required, it is the highest band whose entry conditions are all satisfied across the critical scope, not an arithmetic average. CAI recommends presenting the profile as the primary result and offering the overall band only as a secondary read, stated plainly: the schema is designed so that most enterprise estates operating console-based sources of truth would, in CAI’s estimation, report at G3 today, and that is an assessment of the state of the category rather than a defect in the measure. ## Common Misconceptions Four beliefs recur, and each is worth stating plainly and correcting. - That a governance platform is the same thing as governance. It is one set of capabilities delivering part of the category. - That a completed certification campaign shows access is appropriate. It shows that a campaign completed. - That a converged platform removes the enterprise’s integration and accountability obligation. It relocates the obligation. - That continuous or automated governance removes the need for named authority. It makes named authority more important, not less, because the automation must act on someone’s behalf. ### A worked example A manufacturing group with a finance shared-service center completes an acquisition. The acquired entity operates in a second jurisdiction and arrives with its own directory, its own tenant, and its own role model. Follow one person, a treasury analyst in the acquiring entity, through vendor-payment approval, and then follow an agent that later performs invoice matching under her delegated authority. - She joins from a human-resources feed and her entitlement has a named owner. The acquired entity has no equivalent feed for its contractors, and the equivalent entitlement has no owner. - Her access is role-derived in one estate and directly assigned in the other, with a recorded exception in neither. - The merger creates a separation-of-duties conflict that neither estate held alone: she can now both create and approve a payment. - Emergency access is granted to the payment run during cutover. - The payment data is classified and jurisdiction-bound, so the same entitlement is lawful in one entity and not the other. - Certification retains her access because the reviewer cannot interpret the acquired estate's entitlement names. - The removal that a later review finally decides is approved and never executed, so the binding survives the decision to remove it. - Then an agent is registered to perform invoice matching under her delegated authority. It inherits her entitlements, and attribution is destroyed. - Runtime enforces at the moment of each payment, and observability later shows the disputed entitlement was never used before the incident. Both hand the evidence back to governance, and neither substitutes for it. Every failure in the scenario is a defect in a governed binding: a missing owner, a wrong lifecycle state, an unrecorded exception, an uninterpretable entitlement, an unexecuted remediation, a destroyed attribution. Every one of them passed through a workflow that completed successfully. **The scenario as a diagnostic.** Read as a table, the scenario becomes a diagnostic an architect can run against a real estate. For each event it names the binding element that failed, the control that would have caught it, the evidence that control produces, the role accountable for it, and the operability dimension it belongs to. Running the same five columns against your own critical instances turns the model into a worklist. **Table 4.** The worked example read as a diagnostic, mapping each failure to the control, evidence, accountable role, and operability dimension that address it*.* | **Event in the scenario** | **Binding element at fault** | **Control that would have caught it** | **Evidence it produces** | **Accountable role** | **Operability dimension** | | ------------------------------------------------- | ------------------------------ | -------------------------------------------------------- | --------------------------------------- | -------------------------- | ------------------------------- | | **Acquired-side joiner provisioned** | Owner | Owner required at provisioning time | Every grant carries a named owner | Resource owner | Coverage and accountability | | **Role-derived vs direct, no recorded exception** | Policy basis | Exception register reconciled to live grants | Exceptions match grants | Entitlement owner | Model quality | | **Create-and-approve conflict after merger** | Conditions (toxic combination) | Cross-estate separation-of-duties ruleset run at cutover | Conflict list with dispositions | Control owner | Model quality and closure | | **Emergency access during cutover** | Lifecycle state (temporal) | Time-bound grant with automatic expiry | Elevation expires on schedule | Privileged-access owner | Lifecycle responsiveness | | **Same entitlement across two jurisdictions** | Conditions (jurisdiction) | Jurisdiction qualifier on the binding | Grant carries a lawful-region tag | Data owner | Decision context and provenance | | **Certification retains uninterpretable access** | Evidence and context | Decision-context coverage on the review | Reviewer sees owner, use, risk, basis | Review-program owner | Decision context and provenance | | **Approved removal never executed** | Lifecycle state (effective) | Remediation-closure verification | Removal confirmed downstream | Operator and control owner | Remediation and closure | | **Agent inherits the analyst’s entitlements** | Authority and provenance | Explicit delegation record per agent | Agent carries owner and delegated scope | Agent owner | Multi-constituency scalability | ### What each audience takes away Each audience takes a different first step from this report. What helps is not a description of the decision, but the decision itself, together with a way to tell whether it worked. **Table 5.** What each audience takes away: a first move and the test that tells them it is done*.* | **Lens** | **First move** | **You are done when** | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **IAM leader** | Map your critical control-and-coverage instances and give each one named owner. | Every instance in the top risk tier resolves to a person, not a team or a title. | | **Control architect** | Fix the admin-time control point and its interfaces to runtime and observability before designing anything downstream. | Runtime and observability can be specified against your boundary without renegotiating it. | | **Control engineer** | Trace one lifecycle-to-closure chain end to end and mark every point where it can fail silently. | You can name, for one high-risk access, exactly where a leaver event stops propagating. | | **Solution designer** | Take one console-bound control and move its source of truth to a versioned, testable artifact. | A change to it passes a test and deploys through a pipeline rather than a console. | | **Market analyst** | Separate built capability from demonstrated adoption for your top three vendors. | Each claim is labelled built, roadmap, or adopted, with evidence for the label. | | **Academic or assurance** | Define the review-quality measure you will own before the next campaign. | You can state last cycle’s remediation-closure rate from your own data. | | **Consultant** | Run the worked-example table against the client’s estate. | Each row maps to a real binding, a real owner, and a real operability score. | ## Conclusion Identity and access governance is the admin-time control system that decides and maintains authoritative, accountable, lifecycle-managed access state before runtime. It is moving from periodic, workforce-centric, console-bound administration toward event-driven, evidence-bound, programmable governance across every identity constituency. The enterprise must architect that shift, because no enterprise standard confers admin-time authority. And the shift never dissolves the two things that make the category a control at all: a named authority behind every material decision, and a boundary that keeps governance out of the runtime decision. Everything above comes down to one idea: governance governs a binding, not a record. A record is a static entry, a line that says a subject has some access. A binding is the living relationship behind that line: who the subject is, what they may do, on whose authority, and under what conditions, kept accurate for as long as the access exists. That relationship differs from one part of the enterprise to the next, and it changes constantly. Once this is clear, almost every failure in the category looks the same: the binding changed, and the tooling assumed it had not. The response is three things. Govern the binding that is actually there, not the workforce entitlement most tools were built to handle. Put a named authority behind every decision that matters. And measure the program with a metric the enterprise owns, not a vendor's score. Do those three things, and governance becomes what it is meant to be: the control plane that every runtime access decision rests on. ## Acronym Key and Glossary Acronyms and terms used in this report. | **Term** | **Expansion or definition** | | --------------------------- | ---------------------------------------------------------------------------------------------------- | | **ABAC** | Attribute-based access control. | | **CAEP** | Continuous Access Evaluation Profile, an OpenID shared-signals profile for live sessions. | | **CIAM** | Customer identity and access management. | | **CIEM** | Cloud infrastructure entitlement management. | | **Governed access binding** | The authoritative, lifecycle-managed relationship that is the object of governance; see Definitions. | | **IGA** | Identity governance and administration. | | **JML** | Joiner, mover, leaver: the workforce lifecycle events. | | **PAM** | Privileged access management. | | **PAP / PDP / PEP** | Policy administration, decision, and enforcement points. | | **PKI** | Public key infrastructure. | | **RBAC** | Role-based access control. | | **SCIM** | System for Cross-domain Identity Management. | | **SoD** | Separation of duties (also segregation of duties). | | **SSF** | Shared Signals Framework. | | **vLEI** | Verifiable Legal Entity Identifier. | | **ZSP** | Zero standing privilege. | ## Evidence This report draws on standards and specifications from the recognized bodies, peer-reviewed role-engineering research and practitioner literature on access-review measurement, published regulatory and program direction, and enterprise and practitioner accounts of governance in operation. Vendor material was read only as evidence of what has been built, never as evidence of adoption or effectiveness. Empirical claims that could not be traced to independent primary sources were excluded. ### Standards and specifications referenced The report references the following standards and specifications: - SCIM: RFC 7643 and RFC 7644 (2015); SCIM Events: RFC 9967 (Proposed Standard, May 2026). - OpenID Shared Signals Framework, CAEP, and RISC: OpenID Final Specifications (2 September 2025). - OpenID AuthZEN Authorization API 1.0: Final (January 2026). - NIST SP 800-53 Rev. 5, control families AC and AU. - ISO/IEC 27001:2022, Annex A controls 5.15 to 5.18 and 5.3. - INCITS 359-2012 (R2022), Role Based Access Control. - OASIS XACML 3.0 (2013, Errata 01 2017); OASIS ACAL 1.0 (Committee Specification Draft 01, 18 February 2026), the XML-agnostic core, with the XACML 4.0 XML representation (Committee Specification Draft 01, February 2026). - GLEIF verifiable LEI Ecosystem Governance Framework. - NIST NCCoE concept paper on software and AI agent identity and authorization (2026); draft-klrc-aiagent-auth-02 (Informational, 2026). - EU AI Act (Regulation (EU) 2024/1689); Singapore IMDA Model AI Governance Framework for Agentic AI, Version 1.5 (20 May 2026). ## Related Reading - [IAM-RD-01](https://research.controlarch.org/identity-and-access-management/) for the Identity and Access Root Document - [IAM-F-RTM-01](https://research.controlarch.org/identity-and-access-runtime-controls/) for the Identity and Access Runtime Controls Foundation Report. - [IAM-F-OBS-01](https://research.controlarch.org/identity-and-access-observability-controls/) for the Identity and Access Observability Controls Foundation Report. - [IAM-F-SUB-01](https://research.controlarch.org/identity-and-access-substrate/) for the Identity and Access Substrate Foundation Report. ## Definitions The terms below are used precisely throughout this report. Several belong properly to the identity and access substrate; the definitions here are the working definitions this report relies on and are sufficient for it to read standalone. **Subject.** The person, organization, device, workload, or agent whose access is being governed. The subject is distinct from the digital identity that represents it and from the account through which it acts. **Identity.** The digital representation of a subject within a system of record. One subject may hold several identities even though the goal is to have only one; the governance question is whether each is authoritative and correlated to the subject through a globally unique identifier. **Account.** The means by which an identity acts within a specific target system. Accounts are where entitlements are actually held and where orphaned and shared access accumulates. **Entitlement.** A grant of a permitted action on a resource. In the workforce case an entitlement is declared and held; in the cloud infrastructure case the effective entitlement is computed across policy layers and inheritance and is not stored anywhere as a single object. This difference is central to the report. **Resource.** The system, service, application, dataset, or capability that a permitted action operates on. **Operating environment.** The technical and business context an access sits in: channel, infrastructure, data, or application surface, on-premises or cloud, and the operating unit, subsidiary, and jurisdiction the business runs in. **Authoritative source.** The system of record that is trusted to assert a fact about a subject or resource. For the workforce this is typically the human-resources system; for several other constituencies there is no equivalent, which is a governed problem rather than a detail. **Owner.** The accountable role for a control-and-coverage instance, an entitlement, a role, a resource, or a policy, with a named current incumbent and a defined backup. A durable role with a named incumbent is more resilient than accountability pinned to an individual who may leave; the failure modes are ownership that names no incumbent and title-only ownership that carries no decision rights. **Authority.** The person or organizational role from which a material access decision derives its legitimacy. A policy is not itself an authority but an expression of authority delegated or approved through an institutional process; a policy-derived decision still resolves to the role that owns and approved the policy. Automation may execute or recommend a decision; the authority for it is always nameable. **Policy.** A rule or set of conditions that governs access assignment. This report is concerned with admin-time policy, the rules that decide what should be bound, and treats runtime evaluation policy. **Lifecycle state.** The current position of an access binding in its lifecycle state. It is not a single value but a set of independent dimensions: approval, provisioning and reconciliation, effective access, credential, temporal validity, exception, and evidence. These can disagree. Access may be administratively revoked yet remain technically effective, or a policy may be active while a credential has expired. A binding has a lifecycle state whether or not any system is tracking it. **Governed access binding.** The report’s central analytical construct: an authoritative, lifecycle-managed relationship among a subject, an identity or account, a resource and permitted action, an entitlement or policy basis, conditions, an authority, an owner, and supporting evidence. It is the object that governance actually governs. ## Notes 1. The professional body is ISACA. The measures cited, the proportion of users adjusted and the proportion of entitlements removed per campaign, come from Vincent J. Schira, “Rethinking User Access Certifications,” ISACA Journal, Volume 2 (2018), which offered them without reporting a supporting study. 2. NIST SP 800-53 Rev. 5, control families AC (Access Control), notably AC-2 Account Management, AC-5 Separation of Duties, AC-6 Least Privilege and AC-6(7) Review of User Privileges, and AU (Audit and Accountability). ISO/IEC 27001:2022, Annex A controls 5.15 Access control, 5.16 Identity management, 5.17 Authentication information, 5.18 Access rights, and 5.3 Segregation of duties. 3. GLEIF, verifiable LEI (vLEI) Ecosystem Governance Framework, built on the Trust over IP Governance Metamodel. Cited as an existence proof of interoperable admin-time authority, not as a recommended implementation. 4. System for Cross-domain Identity Management (SCIM), RFC 7643 and RFC 7644 (2015); SCIM Events, RFC 9967 (Proposed Standard, May 2026), which conveys lifecycle state changes as Security Event Tokens and specifies that a receiver determines its own local follow-up action rather than treating an event as a command. 5. Representative anchors: Coyne, Role Engineering (ACM RBAC Workshop, 1995); Molloy et al., Mining Roles with Semantic Meanings (SACMAT 2008); Colantonio et al., A Formal Framework to Elicit Roles with Business Meaning in RBAC Systems (SACMAT 2009) and A New Role Mining Framework to Elicit Business Roles and to Mitigate Enterprise Risk (Decision Support Systems, 2011); Mitra et al., A Survey of Role Mining (ACM Computing Surveys, 2016). 6. INCITS 359-2012, Role Based Access Control, reaffirmed as INCITS 359-2012 (R2022); originally ANSI/INCITS 359-2004\. It defines the reference model and administrative functional specification, including role hierarchies and static and dynamic separation-of-duties constraints, and has not been substantively revised since 2012. 7. OASIS eXtensible Access Control Markup Language (XACML) Version 3.0 (2013; Plus Errata 01, 2017), which defines the Policy Administration, Decision, and Enforcement Points. OASIS Attribute-Centric Authorization Language (ACAL) Version 1.0, Committee Specification Draft 01 (18 February 2026), is an XML-agnostic evolution of the XACML core, with XACML 4.0 (Committee Specification Draft 01, February 2026) as the corresponding XML representation. 8. NIST SP 800-53 Rev. 5, AC-6(7) Review of User Privileges and AC-2 Account Management, which call for periodic review and adjustment of assigned privileges. CAI reads zero standing privilege, realized through just-in-time elevation, as one architectural direction for high-impact access rather than as a NIST-prescribed end state. 9. OpenID Shared Signals Framework, Continuous Access Evaluation Profile (CAEP), and Risk Incident Sharing and Coordination (RISC), approved as OpenID Final Specifications, 2 September 2025; OpenID AuthZEN Authorization API 1.0, Final, January 2026; SCIM Events, RFC 9967, May 2026. 10. NIST NCCoE concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization (draft, February 2026; public comment closed April 2026), which examines how existing identity and authorization mechanisms may be adapted for software and AI agents and solicits industry input on the gaps. Singapore IMDA Model AI Governance Framework for Agentic AI, Version 1.5 (20 May 2026). EU AI Act (Regulation (EU) 2024/1689), Articles 14 and 26\. Agent identity standardization remains at Internet-Draft status; draft-klrc-aiagent-auth-02 (Informational, June 2026) is an individual conceptual model, not a standard. ## 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.