Identity and Access Runtime Controls

Observations

Identity and access runtime controls operate at the moment of access and for as long as the access lasts. They are not one mechanism. They are a capability family: identity verification at runtime, authentication and the strength of it, risk-based assessment and fraud prevention, session management, federation and identity propagation across security domains, and authorization with the enforcement that makes a decision take effect. Each of these is substantial engineering, built into the internals of identity systems, gateways, applications, meshes, and data platforms. Their outputs are visible as products — an authentication service, a session, an authorization interface — which is why the category is so often read as a set of purchases rather than as an architecture. The five observations below describe the landscape as CAI finds it.

• Runtime controls are engineered into systems; they are not acquired. What determines whether an enterprise has a runtime control is not which platform it bought. It is a series of engineering decisions taken inside its systems. How is a credential validated, and is it bound to its holder? What assurance did the authentication establish, and is that assurance carried forward? Where does a session’s state live, and what ends it? Is an assertion crossing a domain boundary evaluated, or merely accepted? At what granularity can an authorization decision be resolved? Where is that decision evaluated, and where is it applied? What context reaches that point, and what happens when it cannot be reached? Two enterprises running the same products differ enormously on all of it.
• Every capability family establishes authority well and sustains it poorly. This is the through-line of the category, and it repeats capability family by capability family. Authentication measures assurance rigorously at one instant, and the session then holds that assurance indefinitely without re-measuring it. A federated assertion is validated on receipt and never revisited, though the domain that issued it may revoke the subject minutes later. An authorization decision is resolved against context that was accurate when the request arrived, and is not resolved again as the context moves. A risk score is computed at authentication, when the signals that matter most arrive afterward. In every case the control is well built for the moment it was designed for, and the moment passes — leaving a subject exercising authority the enterprise can no longer show is warranted.
• The capability families are operated as separate products by separate teams, and the handoffs between them are where trust is lost. Access management owns authentication, session, and federation. An authorization platform or the application team owns policy evaluation. A fraud or risk function owns scoring, often for the customer estate only. Platform engineering owns workload identity. Each is competent within its boundary. No one owns the continuity between them, and the continuity is where the questions live: whether the assurance established by authentication is still the assurance the session holds; whether a risk signal reaches the authorization decision; whether an entitlement revoked at admin-time reaches the live session; and what becomes of any of it when the access crosses into a second security domain.
• Authorization is where the enterprise most often mistakes a decision for a control. Externalizing policy evaluation was the clearest architectural gain of the past decade, and enterprises have made considerable progress. Enforcement did not follow. It is distributed by nature, because it must happen where the access happens, and it is uneven across the coverage surface in a pattern worth naming. The operational data environment is the most capable, because filtering rows and masking fields are ordinary against a structured schema — but that capability does not survive the move to analytics, and it barely exists for unstructured content. The application environment is the weakest, because native permission models rarely expose the granularity that policy assumes. Infrastructure is improving fastest, because workload credentials are issued automatically from the deployment pipeline, with short lifetimes and key binding built into the issuance path rather than added afterward. The channel is the best covered and the least sufficient on its own. Across all four, most decisions resolve to permit or deny at a single granularity, when the resource being protected has several.
• Machine constituencies removed the slack that had been hiding these maintenance failures. A person re-authenticates by habit, and each re-authentication quietly repairs every capability family at once: assurance is re-measured, the session is replaced, the assertion is reissued, and the risk picture is refreshed. That rhythm is why a standing session has been survivable. Devices, workloads, and agents have no such habit and no one to ask. Authority for them is sustained structurally, or not at all — by binding credentials so they cannot usefully be stolen, by keeping lifetimes short, by making delegation explicit, and by re-evaluating continuously. Recent standards and community work on agent identity generally begins from these existing mechanisms rather than proposing new ones, while naming where they need extension: multi-hop delegation that preserves provenance and attenuation across a chain, revocation of delegated authority mid-task when an agent’s work outlives the request that started it, and attribution that resolves to both the delegating human and the acting agent rather than collapsing to one.

Position

CAI takes five positions on what identity and access runtime controls are and how an enterprise should build and operate them.

• Define runtime control by the authority it makes effective across the life of an access, not by any single capability family or product. Runtime control is the category that verifies, authenticates, assesses risk, sustains a session, conveys identity across security domains, and resolves and enforces authorization — at the moment of access and for as long as the access continues. No one of them is the category. Enforcement in particular is how an authorization decision takes effect, not the name of the whole.
• Treat the capability families as one loop, and effective trusted authority as the unit of control. Trust is the foundation the category rests on, but it is not the thing being controlled. What is controlled is the power a subject is permitted and sufficiently trusted to exercise at that moment: permitted by governed policy, trusted to the level the resource requires, and effective only where both hold at once. Verification, authentication, risk assessment, session, federation, and authorization are the means by which that authority is established and kept accurate, not six products to be procured separately.
• Design for the multi-domain case rather than treating it as an exception. A session that crosses a security domain boundary inherits trust the enterprise does not operate and cannot directly observe. Federation is therefore a control boundary rather than a convenience. Four questions belong at that boundary, and they belong in the architecture rather than in the integration: what the assertion carries, how the trust chain is anchored, how many issuers are trusted, and whether revocation crosses back.
• Match authorization granularity to the resource, and expect it to vary across the coverage surface. Coarse, medium, and fine-grained authorization answer different questions and sit in different places, and no single tier is right for a whole estate. The channel can rarely do better than coarse. The application environment needs medium to fine — the operation, and often the specific object or field it acts on (yet frequently delivers only coarse, because native permission models rarely expose the precision the policy assumes). Data resources need fine, and whether that is attainable differs sharply between an operational store, an analytical platform, and unstructured content. Agents sharpen the problem again: an agent calling a tool may need finer control than the human whose authority it is acting on.
• Keep programmable runtime controls as realization, never as authority. Policy authored as versioned, testable, pipeline-deployed code is the target posture, and this report endorses it. The runtime executes authored policy; it does not become the authority for it. A runtime that changes what a subject may do, with no governed record of who authorized the change, has not automated a decision, it has relocated one out of view.

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 Runtime 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 runtime control programme organized around its identity provider produces a coverage map shaped like its authentication traffic. The accesses that never involve an interactive authentication (service to service, agent to tool, query to dataset, and everything that arrives already authenticated from another security domain) are where the controls are thinnest.

What Runtime Controls Are, and What They Produce

Begin with a digital action. A subject attempts an action on a resource. Governance has already decided, before this moment, that a subject of this kind may perform an action of this kind on a resource of this kind, and has recorded that decision as an authoritative access state. Runtime controls resolve that governed intent against this specific attempt and the current context, and hold the result for as long as the access lasts. Observability records what happened and returns evidence that may change the next governance decision.

What runtime controls produce is effective trusted authority: the power a subject is permitted and sufficiently trusted to exercise at that moment. The term has three load-bearing parts.

• Permitted. Governed policy allows this subject this action on this resource. Governance decided it; runtime resolves it against the specific attempt.
• Sufficiently trusted. The assurance actually held (in the credential, the session, the device, the assertion that conveyed the subject from another domain) meets what the resource requires.
• Effective, at that moment. Authority exists only where both hold at once, and only for as long as they both continue to hold. It is what is true now, not what was declared earlier.

This is the runtime counterpart of a distinction governance already draws. Governance separates a declared entitlement from the effective permission actually computed across policy layers, and insists that every material decision resolve to a named authority. Runtime adds the third term: authority that is not merely permitted but currently warranted. Trust is the foundation the whole category rests on. Effective trusted authority is what the controls exist to keep accurate.

Governance produces the intended state. Runtime controls turn it into the actual state, and keep the two aligned while the access is live.

• the subject is established to a known level of assurance;
• the session it acts within has a state that is known and bounded;
• its identity is carried intact across whatever security domains the access spans;
• each consequential attempt is resolved against current policy and context, at a granularity the resource actually has.

And all of it is revisited as circumstances change. Governance produces the intended state. Runtime controls turn it into the actual state, and keep the two aligned while the access is live.

Six capability families, one job

The category divides into six capability families of control. They are separable, they are usually built and operated by different people, and each does work the others cannot.

Table 1. The six capability families, what each does at the moment of access, and what each must do for the rest of it

Figure 1. Each capability family helps establish effective trusted authority at the moment of access, and must help keep it accurate for the life of the access.

Two properties cut across all six and shape every one of them.

• Granularity. How precisely the control can discriminate. An authentication requirement may apply to a whole application or to one transaction; an authorization decision may resolve at the level of a broad scope, a business operation, or an individual field. A control is only as useful as the granularity at which it can act.
• Security domain scope. Whether the access stays within one boundary of trust and administrative control or crosses into others. Everything is harder across a boundary, because the assurance, the session state, and the revocation authority sit somewhere the enforcing party does not operate.

These two properties are why session management and federation are first-class families rather than supporting detail. An access is rarely one request in one domain. It is a session that persists, often spanning several domains, and the controls that carry trust across time and across boundaries are doing the work that makes the rest meaningful.

CAI View An enterprise can hold a capable product for every family and still have no runtime control worth the name, because the control lives in the engineering between them: what one family hands the next, and what happens to any of it an hour later.

The Runtime Control Point

Admin-time is a control point with its own inputs, outputs, and failure modes, and the companion report on governance makes that case. The runtime control point is the second, and it is the one an enterprise can least afford to describe loosely, because it is the only one standing between a governed intention and a real action on a real resource.

Its inputs are the governed access state that administration produced, together with what the moment of access supplies:

• the credential the subject presents, and the assurance it establishes;
• the assertion that conveyed it, if the subject arrived from another security domain;
• the attributes and context available at the moment of the attempt;
• the signals that arrive while the access remains open.

Its outputs are the resolved outcome and the events observability will consume. Its failure modes are specific, and unlike admin-time failures they are usually invisible until they are exploited:

• a credential that is valid but stolen, because nothing binds it to its holder
• a session that outlives the assurance that justified opening it
• an assertion accepted rather than evaluated, from a domain that has since revoked the subject
• a risk assessment made once, at the least informative moment
• a decision resolved at a coarser granularity than the resource requires
• an access path with no control point at all, trusted because it is internal
• a workload or agent acting on a person’s standing session, so the action cannot be attributed
• a fallback that permits when the decision point is unreachable

Each of these produces a successful, well-formed, fully logged access. Nothing fails visibly. The controls ran and returned a permit, and the permit was wrong, not because the policy was wrong, but because what the policy assumed about the subject, the credential, the domain, or the context had stopped being true.

The established control frameworks already treat the moment of access as a control surface. The federal control catalogue places identification and authentication, replay-resistant mechanisms, session control and termination, and the enforcement of approved authorizations in its access-control and identification families. The federal zero-trust architecture goes further, describing access as a per-session decision evaluated against current observable state rather than a position granted once.¹ The information security management standard, ISO/IEC 27001:2022, carries the same surface as secure authentication and the control of access to information and associated assets.

The requirement to verify, authenticate, decide, and enforce is already written down. What the standards do not settle is how these controls are placed across a distributed, multi-domain estate, and what becomes of any of them over the life of the access.

Boundaries and the Handoffs

Governance, runtime, and observability form a closed loop, and the value of keeping them distinct is that each remains separately auditable. Runtime sits in the middle of that loop, which means it owns two boundaries rather than one, and both are load-bearing.

The governance handoff: authored intent in

Governance hands runtime an intended, authoritative access state and the policy that expresses it. Runtime controls consume that state; they do not author it. The policy administration point sits on the governance side of this boundary, and everything downstream of it (evaluation, enforcement, obligation handling) sits on the runtime side. The consequence is precise: a runtime control may evaluate policy against any context it can reach and produce a decision no administrator anticipated, and it is still resolving governed intent, because the authority for that policy was committed when the policy was authored and approved.

The boundary is crossed when a runtime control begins to change what a subject may do rather than to resolve whether this attempt is permitted. A system that quietly grants a durable capability because a risk score improved, with no governed record of who authorized the grant, has made an admin-time decision at runtime and left nothing for anyone to review. This is the inverse of the failure the governance report names on its side of the same boundary, and the two together define the seam.

The observability handoff: what actually happened, out

The emission is therefore not a logging convenience but a deliverable of the category. It must carry:

• the assurance level in force;
• the session and its state;
• the domain and assertion provenance, where the subject arrived from elsewhere;
• the decision and the granularity at which it was resolved;
• the outcome, including any obligation;
• the identity of every party in the chain — a delegating human and an acting agent as distinct parties.

Where the emission is thin, the loop breaks quietly. Governance keeps deciding against evidence that never arrives, observability reports on authentication rather than on control, and the enterprise discovers only after an incident that it can prove who authenticated but not what its controls actually did.

Watch-Out A runtime control that resolves the governed decision is the control working as designed. A runtime control that changes what a subject may do, with no governed record of the authority for the change, has not automated governance. It has dissolved the boundary that made either category auditable.

Figure 2. Runtime consumes governed intent and emits what actually happened. Each handoff carries specific content, each boundary has a characteristic way of failing, and evidence returns to inform the next governance decision.

Terms used precisely throughout this report are collected in the Notes at the end of this report.

The Runtime Access Decision Across the Life of a Session

The unit of runtime control is effective trusted authority. The runtime access decision is how it gets established and kept accurate. That decision is not an event at the start of a session — it is a determination that has to hold, and be re-made, for as long as the subject keeps acting. Each time it is made, it resolves governed intent against a specific attempted action and the current context: a subject verified and authenticated to a known assurance level, acting within a session of known state, in one security domain or across several. It is resolved at the granularity the resource requires — coarse, medium, or fine — and carried out where the access actually happens.

What that produces is a statement of authority that is true only while its inputs stay true. When assurance falls, an assertion is revoked, or risk rises, the authority stops being effective whether or not any system notices. The gap between the authority a subject actually holds and the authority the enterprise believes they hold is where this category fails. The elements below are what each decision rests on, and any one of them can be the one that is missing or wrong:

• Verified and authenticated subject, with an assurance level. Who or what is acting, and how strongly that is established right now rather than at the start of the session.
• Credential binding. Whether the credential presented is bound to its holder, or merely presented by whoever holds it.
• Risk state. The assessed risk at this moment, which should set the requirement rather than be recorded beside it.
• Session and its state. The temporal context the access sits in, its status, and what would end it.
• Security domain scope. Whether the subject arrived from another domain, what assertion conveyed them, and where the authority to revoke them lives.
• Resource and attempted action. What is being accessed and what is being attempted on it.
• Granularity. The precision at which the decision can actually be resolved and carried out, against the precision the resource requires.
• Policy decision and its context. The evaluation of governed policy against the attributes available, and how current those attributes are.
• Outcome. What was actually carried out: permit, deny, or permit under an obligation, filter, or mask.
• Continuity. Whether the decision is re-made as the access continues, and how quickly a revoking signal takes effect.

The elements are not equally likely to fail. In CAI’s assessment the recurring defects are these:

• an assurance level established once and never revisited;
• a credential unbound to its holder;
• an assertion accepted rather than evaluated;
• a granularity mismatch between what the decision can resolve and what the resource requires;
• an outcome vocabulary limited to permit and deny;
• no continuity at all.

An enterprise that measures its runtime posture by authentication success rates is measuring the element least likely to be wrong.

Figure 3. Authority is effective only where the subject is both permitted and sufficiently trusted. The runtime access decision re-establishes it as circumstances change; neither half alone is a control.

Finding a defective runtime access decision does not require new tooling, only the discipline to look at the elements the authentication record does not carry. Five questions surface most of them, and each is answerable from data the enterprise already holds:

• access paths that reach a consequential resource without traversing a control point that could stop them
• credentials in use that are long-lived, static, and unbound to their holder
• live sessions whose current assurance is lower than the resources they can still reach require
• accesses arriving from another security domain where revocation in that domain has no path to a live session here
• revoking signals for which no enforced change in a live session can be demonstrated

Each returns a list an owner can act on this week.

Identity Verification and Authentication at Runtime

The substrate establishes who a subject is. Runtime controls re-establish it, at the moment of access, to a level of confidence proportionate to what is being attempted.

Verification at runtime

Identity verification binds a digital identity to a real subject by validating evidence. Most of that work happens once, at enrolment, and belongs to the substrate. What belongs here is the case where a runtime event calls the binding back into question: a high-value transaction, a recovery flow, a regulated action requiring the subject to be re-established rather than merely re-authenticated, or an account showing the signatures of takeover. Re-verification is a distinct control from re-authentication, and conflating them is a real weakness — re-authentication proves that whoever holds the credential is present, which is exactly what an attacker who has taken over the account can also prove.

Authentication and the strength of it

The assurance model the field has converged on is deliberately multi-dimensional. Three dimensions are selected separately against risk:

• the robustness of the proofing that established the identity;
• the robustness of the authentication process, and its binding to that identity;
• the robustness of the federation that conveyed the result.²

The third dimension exists precisely because an assurance level can be weakened in transit between domains, which is treated under federation below.

Strength is not one axis but three, and enterprises routinely conflate them:

• Factor count. Multi-factor authentication requires independent factors from different categories. It raises the cost of an attack and does not by itself resist phishing, because a factor that can be entered can be relayed.
• Phishing resistance. Origin-bound public-key authentication removes the credential class most often stolen, because there is no shared secret to relay. This is a different property from factor count, and it is the more consequential one.
• Credential binding. Whether the authenticated result, once issued as a token, remains tied to the subject. A bearer token is one whose holder is its owner by definition. A sender-constrained token (bound to a key at the application layer, to a client certificate at the transport layer, or to a workload’s private key) is generally unusable to a thief who does not also hold the key, subject to the residual risks each protocol documents.³

Binding deserves emphasis because it is where the strongest authentication is most often undone. An enterprise can deploy hardware authenticators, establish a high assurance level, and then issue a bearer token that any process which obtains it can replay from anywhere. The authentication was strong; what it produced was not. In CAI’s assessment this is among the highest-leverage runtime controls available to most enterprises today, and it is under-adopted because it is invisible when it works.

Step-up: raising assurance instead of refusing

Where a resource requires more assurance than the session currently holds, a control that can only permit or deny must refuse legitimate work. Step-up removes that choice: the resource signals that a higher assurance level is required for this specific resource or action, and the subject re-authenticates at that level. Standardizing the challenge is what turns step-up from a bespoke application behaviour into a runtime control that any resource can invoke.

Together these produce the frame the rest of the report uses. A resource carries a required assurance. A live access carries a maintained assurance. The task of runtime control is to keep the second at or above the first — by binding the credential so the level cannot be silently stolen, by watching for what lowers it, and by demanding step-up rather than either refusing or quietly proceeding.

Figure 4. Factor count, phishing resistance, and credential binding vary independently. A common deployment can be strong on the first and absent on the two that matter, producing a credential that is strong at the door and replayable after it.

CAI View Assurance is a level held over time, not a gate passed once. An enterprise that can state the assurance level of its authentications but not of its live sessions has measured the easy half.

Risk-Based and Adaptive Controls, and Fraud Prevention

The controls above apply a requirement. This family decides what the requirement should be, and revises it as circumstances change.

Risk-based, or adaptive, authentication computes a risk assessment from contextual signals (device recognition and posture, network and location reputation, behavioural pattern, time, transaction value, and prior activity) and adjusts the requirement accordingly. Its value is not that it adds friction but that it allocates friction: a routine access from a recognized device proceeds, and an unusual one meets a higher bar. An enterprise applying one static requirement to everything is simultaneously too strict for most accesses and too weak for the ones that matter.

Risk assessment is not confined to authentication. The same score properly informs authorization (the same subject may read a record at low risk and be denied the ability to export it at elevated risk) and session management, where an elevated score should shorten a session rather than merely be recorded against it. Where the risk assessment reaches only the authentication decision, the enterprise has bought a smarter front door and left the rest of the house on a fixed setting.

Fraud prevention as a runtime control

Fraud prevention addresses identity fraud in progress: account takeover, credential stuffing, automated and bot-driven abuse, synthetic identity, and behaviourally anomalous use of an account that is, by every credential test, legitimate. It matters to this category because its defining case is the one authentication cannot catch — the attacker who holds the real credential and passes every check. What stops that access is not a stronger credential test but a judgement about behaviour, and a control willing to act on it mid-session.

The boundary with observability is worth stating plainly, because these capabilities are usually bought together. Detection, scoring, correlation, and the analytics that produce them are observability work. What belongs to runtime control is what is done with the result while the access is live: raising the authentication requirement, demanding step-up or re-verification, constraining what the session may do, reducing its lifetime, or terminating it. A fraud capability that detects an account takeover and can only raise an alert has produced an observation. A runtime control that receives the same signal and changes what the live session can do has produced a control.

The customer estate has driven most of the maturity here, because the economics are direct and measurable. The workforce estate lags for a reason worth naming: an authenticated employee is assumed to be the employee, and account takeover inside the perimeter is treated as an incident to investigate rather than as a condition to be continuously assessed. The techniques transfer; the assumption is what has to change.

The signals themselves are unremarkable and mostly already collected — device recognition and posture, network and location reputation, behavioural pattern, transaction value, and prior activity. What separates an enterprise that has a control from one that has a dashboard is where the resulting assessment is allowed to go. A score that reaches only the authentication decision changes who gets in. A score that also reaches authorization changes what they may do once inside, and a score that reaches session management changes how long they may keep doing it. The same signal, wired to three families instead of one, is three controls instead of one.

The vendor implication follows directly. A risk or fraud capability that computes a score and emits an alert has built an input to somebody else’s control. The capability worth buying exposes that score to the authorization decision and the session manager as a first-class input, and accepts and emits the shared signals that let it act on, and contribute to, assessments made elsewhere — including in another security domain.

Watch-Out A risk assessment that reaches only the authentication decision leaves authorization and session management on a fixed setting. The signals that matter most arrive after the subject is already inside.

Session Management

A session is the temporal context established after authentication during which a subject exercises access without re-establishing anything. That is its purpose and its risk, and it is why the session rather than the request is the unit across which trust must be maintained.

A session has a state, and the states are the control surface:

• active while the subject is working;
• idle once activity stops for longer than a threshold;
• expired when a maximum duration or idle limit is reached;
• terminated when the subject signs out, or something ends it deliberately.

The levers over those states are maximum lifetime, idle timeout, renewal conditions, concurrency limits, and forced termination. They are usually configured once against a usability target, and never revisited against the assurance the resources behind the session require.

The question worth asking of any long-lived session is simple and rarely asked: if the credential that opened this session were stolen five minutes after it opened, what would stop it, and how long would that take? For most enterprises the honest answer is that the session would run to its natural expiry, and the natural expiry was set for convenience.

Renewal is where assurance quietly decays

Session renewal deserves particular scrutiny because it is where a well-designed authentication is most often undone. A session extended automatically on activity, or a refresh token exchanged indefinitely for new access tokens, carries forward an assurance level established at a moment that recedes further into the past with every renewal. The subject has not proved anything since. Renewal that is bounded (by an absolute lifetime beyond which re-authentication is required regardless of activity, and by conditions that force re-authentication when risk or resource sensitivity rises) is what keeps a session from becoming a permanent credential.

Privileged sessions

Privileged sessions are the same object held to a shorter tolerance. Where an administrator exercises elevated entitlements, the session is typically brokered through a controlled intermediary so that the administrator never connects directly with their own credential, monitored in real time, and recorded. The brokering matters architecturally: it makes the session itself an enforcement point, capable of terminating mid-activity on anomalous behaviour, which is precisely the capability ordinary sessions lack.

The generalization is worth drawing. What privileged access management has built for administrators (a session that is brokered, observed, and terminable) is the model of a session that is a control rather than a container. In CAI’s assessment most enterprise sessions are containers.

Sessions the subject cannot re-open

The session model above assumes someone is there to start a new one. For workloads and agents that assumption fails, and the session concept has to be carried by other means. A workload does not sign in again; it is reissued a credential, and the lifetime of that credential is its session. An agent working through a task holds authority derived from the session that delegated it, and if that derivation is not explicit the agent outlives the authority it was acting on. Three consequences follow:

• Credential lifetime becomes the session control, so it should be set against resource sensitivity rather than operational convenience.
• Delegated authority should be bound to the delegating session, so that ending the one ends the other.
• Termination must be something the platform can actually do at machine tempo, not a ticket raised against a running process.

For vendors the requirement this implies is specific. A session capability is a control only if it can demonstrate three things:

• an absolute lifetime bounds renewal rather than activity extending it indefinitely
• a forced termination or revoking signal ends a live session within a stated latency, and can evidence that it did
• a session’s derived authorities (exchanged tokens, delegated agent scopes) end with it.

A product that manages session creation well and cannot evidence any of the three has automated the easy half.

Federation and Identity Propagation

A security domain is a boundary of trust and administrative control within which a common set of security policies, authentication mechanisms, and identity practices apply. Federation is the mechanism that lets a subject authenticated in one security domain reach resources in another, without re-authenticating, on the strength of an assertion and a trust relationship. Almost every enterprise access of consequence now crosses at least one such boundary.

Single domain and multiple domains

Within a single security domain the enterprise controls the whole chain: it authenticates the subject, sets the assurance, holds the session, and can terminate it. Across domains it controls part. The relying domain receives an assertion describing an authentication event it did not perform, about a subject whose session it does not hold, from an identity provider that may revoke that subject a minute later without telling it. Every property this report has treated as maintainable becomes, at that boundary, something inherited.

Four questions decide whether the crossing is a control or a formality:

• What does the assertion carry, and is it evaluated? An assertion conveys the authentication event and optionally attributes. A relying party that treats its presence as sufficient, rather than evaluating the assurance level, the freshness, the audience, and the conditions it carries, has accepted rather than verified.
• How is the trust anchored? A trust relationship is a formal agreement between domains; a trust chain is the ordered sequence back to a trust anchor that lets a verifier establish that an issuer is authorized. Automatic trust establishment through published trust chains removes much of the bilateral configuration that made federation operationally heavy, and correspondingly raises the importance of the anchor being right.⁴
• How many issuers are trusted? A boundary with many token issuers has inconsistent validation and inconsistent trust. One trusted token authority per boundary is the durable design; the alternative accumulates until no one can enumerate what the enforcement points will accept.
• Does revocation cross back? This is the question most often unasked. If the issuing domain terminates the subject’s session or disables the account, the relying domain’s session frequently continues untouched until it expires on its own schedule. The trust was federated; the revocation was not.

Propagation: whether identity survives the hop

Inside a trust domain, one authenticated request typically becomes many internal calls, and what a downstream service knows about the original subject is determined entirely by what the caller passed on. The two common answers are both poor. Passing the original token onward gives every downstream service the subject’s full authority, so the least-trusted hop holds the most privilege. Dropping the subject and calling with a service credential preserves the boundary and destroys attribution, so the downstream control knows which service called but not on whose behalf.

Two mechanisms resolve this:

• The first is exchange: a token is exchanged at each hop for one scoped to the next, so authority narrows as it travels.
• The second is constrained propagation: an immutable transaction context travels with the chain, so every control point can see the original subject, the acting workload, and the authorization context that was true when the chain began.⁵ A trust domain has one authority for issuing that context, which is the same principle as one trusted token authority per boundary, applied inside it.

Figure 5. Within a domain the enterprise controls authentication, assurance, session, and revocation. Across a boundary it inherits them, and revocation is the property least likely to cross back.

CAI View A call chain that cannot name both the delegating subject and the acting workload at its final hop has not propagated identity. It has propagated permission, which is the part that should have been narrowed.

Authorization: Reference Model, Granularity, and Enforcement

Authorization determines whether an authenticated subject may perform a specific action on a specific resource. It is the family with the most mature architecture, the most active standards work, and the widest gap between what is designed and what is operated — which is why this report treats it at length while insisting it is one family among six.

The reference model

The runtime authorization model in general use separates four responsibilities, and the separation is the most durable idea in the category. Policy is authored at an administration point, evaluated at a decision point, carried out at an enforcement point, and supplied with the attributes it needs by an information point. The model predates most of the products that implement it and remains correct.⁶

Its first consequence is the boundary already drawn in this report: the administration point belongs to governance, the other three to runtime. Its second is the one the market under-reads. There can reasonably be one decision point, or a few, because consistency of judgement is the goal. There cannot reasonably be one enforcement point, because carrying out a decision must happen where the access happens, and access happens everywhere.

Two placements of the decision recur, and the choice between them is an engineering trade-off rather than a maturity ladder.

Table 2. The two authorization decision patterns and the engineering trade-off each carries

In CAI’s assessment large estates commonly run both, and should. The failure is not mixing them; it is mixing them without deciding which is authoritative for a given class of resource, and without answering what each does when the decision point cannot be reached. A fallback that permits preserves availability and silently suspends the control; a fallback that denies preserves the control and converts a decision-point outage into an enterprise outage. Both are legitimate. Neither should be a default nobody chose.

What the decision is made from

The access-control methodologies (roles, attributes, relationships, policy, purpose) are commonly presented as competing schools. At runtime they are not competing. They are different resolution mechanisms for the same question, and substantial systems compose them:

• a role compresses the standing grant;
• attributes qualify it against context;
• a relationship model answers the questions roles cannot express;
• policy binds the conditions;
• purpose constrains what the access may be used for.

The design question is not which model to adopt. It is which mechanism resolves each part of the question — and whether the control point can act on the answer at the precision the resource requires.

Granularity: coarse, medium, and fine

That precision is granularity, and it is the property this report treats as first-class because it determines what the control can actually protect. Three tiers are useful, and they sit at different places for different reasons.

Table 3. The three tiers of authorization granularity, what each resolves, where it sits, and what it cannot reach

The tiers are cumulative rather than alternative, and the recurring failure is treating the first as sufficient. An estate with a well-run gateway and no authorization inside its services has a strong front door and open interior rooms. Granularity also constrains what the other families must supply: a decision resolved at the object level needs context the edge does not hold, and a decision about a subject who arrived from another security domain can only be as fine as the attributes that survived the crossing.

The fine tier carries a caveat treated in full under coverage: its feasibility is a property of the resource rather than a free choice, and where a resource cannot deliver it the honest answer is to control the container and the retrieval path rather than claim a granularity that does not exist.

Granularity is also where the two properties introduced earlier meet.

• A decision that must be resolved at the object level needs context the edge does not have, which pushes the decision point closer to the resource or requires the information point to supply what the request does not carry.
• A decision that must be resolved for a subject who arrived from another security domain can only be as fine as the attributes that survived the crossing.

Enforcement and its outcomes

Enforcement is where the authorization family becomes a control. The enforcement point intercepts the access flow, assembles what the decision needs, obtains the decision, and carries out the result — including any obligation attached to it. Everything before it is preparation.

The reference model has always allowed a decision to carry obligations, and the data environment has long acted at row and field granularity. Yet in CAI’s assessment most enterprise enforcement still returns permit or deny, and the cost is not theoretical. Facing a query that returns some records the subject may see and some they may not, a binary enforcement point has two options and both are wrong: deny the query and block legitimate work, or permit it and disclose what should have been withheld. In practice it permits.

Table 4. The enforcement outcomes available to an authorization decision and the granularity each requires

An obligation is only a control if the enforcement point actually fulfils it. A decision returning “permit, with the obligation to mask the account number” against an enforcement point that can only permit or deny has produced a permit, and the mask exists only in the policy. This is the most common way a sophisticated authorization design fails in operation.

It is also the clearest instruction to the market. Enforcement capability at a stated granularity, not policy expressiveness, is the constraint worth measuring — so a control point should state which outcomes it can carry out and at what granularity, rather than which policy language it accepts. An enterprise evaluating one should ask for that statement first, and treat an engine that can express outcomes its enforcement points cannot fulfil as an unfinished product rather than a capable one.

Figure 6. Coarse, medium, and fine-grained authorization resolve different questions at different places. Filtering and masking require the fine-grained tier; step-up is available at every tier.

Standards Note The authorization API standardizes the interface between the enforcement point and the decision point, with the stated goal of making policy engines substitutable behind a common contract. That is a design goal reaching adoption, not a settled market fact; an enterprise should treat engine portability as something to test rather than assume.

Continuous Trust Maintenance

Each family establishes trust well. This section is about the part that makes them controls rather than gates: what each must do for the rest of the access, and the mechanism that drives all of them. State the problem plainly. A resource carries a required assurance — the confidence in the subject, the credential, and the context that its sensitivity demands. At the moment of access the runtime establishes a maintained assurance that meets or exceeds it, and the access proceeds. Then the maintained assurance decays. It decays because:

• the device falls out of compliance;
• a credential is stolen;
• behaviour turns anomalous;
• the issuing domain revoked the subject;
• the governed entitlement behind the access was removed at admin-time and nothing told the session.

None of these produces an event at the control point. They simply mean the gap between what the resource requires and what the access holds has opened, and no one is measuring it.

Figure 7. Required assurance is a property of the resource; maintained assurance decays as context changes. Continuous evaluation detects the gap and closes it through step-up, constraint, or revocation. Illustrative CAI model; values and relative positions are not derived from an industry dataset.

Maintenance is not one mechanism. Each family has its own, and a programme that implements only the last of them has not made the category continuous:

Table 5. What continuous maintenance looks like in each capability family

The mechanism that drives them is continuous evaluation over shared signals. A framework for transmitting security events between cooperating systems, with a profile for the access-relevant subset (session revoked, credential changed, device compliance lost, assurance level changed) has reached final specification, and the event format it carries is long settled.⁷

This matters for a reason worth stating precisely: the standard conveys a signal, and the receiving system decides what to do about it. The standard enforces nothing. An enterprise that has connected a signal feed and not decided, per resource class, what each signal should cause has bought a notification, not a control. Three decisions follow, and each belongs to the enterprise rather than to a product:

• Which signals cause a response, and for which resources. Not every signal warrants interrupting every access. A credential-change signal should terminate sessions on high-value resources and may reasonably do nothing to a low-risk read.
• What the response is. Termination is safe and expensive. Re-verification, step-up, and constraint restore or contain trust while preserving the work — which is why the graded outcomes of the previous section are what make continuous evaluation tolerable in practice.
• How quickly it must take effect. Permissible revocation latency is set by privilege, blast radius, threat state, and reversibility, not by whether the subject is a person or a process. This is the runtime measure most enterprises could compute today and do not.

The trajectory is clear and the present state is early. The standards are final and receivers are appearing in products, while public evidence of broad enterprise adoption remains limited. CAI’s reading is that continuous evaluation is what separates runtime controls that are gates from runtime controls that are controls, that the standards no longer block it, and that what blocks it is that most enterprises have not decided what their signals should mean.

CAI View Continuous evaluation is not a product feature to be acquired. It is a set of decisions about which signals matter, what they should cause, and how fast — and those decisions are the enterprise’s to make.

Runtime Coverage

Runtime control products are typically built for one shape of access: an interactive human session, opened by an authentication, carried by a browser or application, within a single security domain, reaching a resource that understands sessions. Every step away from that shape changes what each capability family can do, and coverage degrades in proportion to the distance.

The identity constituency

The constituency facet asks whose or what identity is acting. What changes with changes in the credential, where control points can sit, and, most consequentially, how trust can be re-established once it decays.

Table 6. The credential, control points, and maintenance mechanism for each identity constituency, with its coverage state

The pattern across the table is the fifth observation made concrete. For the three human constituencies a person is available, and every family can fall back on asking them: re-verify, step up, re-authenticate. For device, workload, and agent there is no one to ask. Trust must therefore be maintained structurally — by binding credentials so they cannot usefully be stolen, by keeping lifetimes short enough that theft has a small window, by making delegation explicit, and by re-evaluating continuously because no other mechanism exists. An enterprise running its machine constituencies on long-lived bearer credentials and periodic review has no maintained trust for them at all; it has an issuance event and hope.

The technical and business environments

The same questions (where can control points sit, at what granularity, and how is trust re-established) reshape the picture again as the technical environment changes.

• Channel. The best-covered environment. Authentication, session, and coarse-grained authorization all live here, and this is where most runtime investment has gone. It is also the least sufficient on its own, because nothing at the channel knows what an operation means.
• Application. Where most authorization work happens and where granularity is most often mismatched. Native permission models rarely expose the precision policy assumes, so the control point cannot act on the decision it receives.
• Data. The environment with the widest spread between best and worst. In an operational store with a structured schema, fine-grained control is ordinary: rows are filtered, fields are masked, and purpose is a governed dimension. That capability does not travel. In a warehouse or lake, where operational data is aggregated for analytics, classification is inherited rather than intrinsic, lineage breaks across transformations, and an aggregate can be more sensitive than any source it was built from. For unstructured content there is often no field to mask and no row to filter, so control collapses back to the container. Retrieval-augmented generation and agent access to data make it harder again, because the retrieval layer sits between the subject and the content and is frequently not an enforcement point at all — so the subject receives synthesized output assembled from records they were never authorized to read.
• Infrastructure. Service-to-service access at machine tempo, controlled in the mesh and the sidecar. The environment where short-lived, key-bound credentials are most achievable, because they are issued from the deployment pipeline rather than requested from a console.

The business environment adds the last reshaping, and it is the one that turns federation from an integration concern into an architectural one. A multi-tenant estate means several identity providers and several security domains that were never designed to trust each other; acquisitions arrive with their own; divestitures leave boundaries that must be severed rather than merely reconfigured. Jurisdiction becomes a property of the decision rather than a deployment detail: the same access, by the same subject, to the same data, may be lawful in one jurisdiction and not another, and the control point is where that distinction is either applied or lost.

A runtime coverage self-test. A short test reveals how far an estate’s runtime controls reach beyond the interactive single-domain session. For each consequential access path, ask four questions:

• Does this path traverse a control point that could stop it, and at what granularity?
• Is the credential it carries short-lived and bound to its holder?
• If the subject arrived from another security domain, can that domain’s revocation reach this session?
• Is the decision re-made while the access is open?

Where the answers are no (as they commonly are for service-to-service calls, agent tool invocations, federated partner access, and long-lived analytical sessions) the estate has a gap its authentication statistics report as healthy traffic.

Watch-Out An agent holding a person’s standing session is not an authenticated agent. It is impersonation with the audit trail of the person impersonated, and no control point downstream can tell the difference.

Programmable Runtime Controls

The direction of travel for the category is from console-configured controls toward controls authored as code, tested, and deployed through pipelines to the points that apply them. This report endorses that direction and adds one distinction the market blurs.

Programmability has two halves that are often conflated.

• The first is that a control’s definition lives as a versioned, reviewable, testable artifact rather than in a console.
• The second is that the control evaluates context at the moment it acts and produces a result shaped by inputs that did not exist when it was authored.

The halves reinforce each other, and both are needed. A control that adapts to context but whose rules live in a console is adaptive and unauditable. A control whose policy is beautifully versioned but which evaluates nothing but a static role has bought engineering discipline and no runtime adaptiveness.

This applies across the capability families, not only to authorization policy. Authentication requirements, session lifetime and renewal conditions, risk thresholds and what they trigger, federation trust anchors and the issuers accepted at a boundary — all of these are controls, and all of them more often live in consoles than in repositories. An enterprise that has moved its authorization policy into code and leaves its session and federation configuration in six consoles has modernized the family that was already best understood.

The governance boundary holds here, and this is where enterprises most often lose it. Authoring policy as code does not move the authority for that policy into the pipeline. The policy remains governed: it has an owner, a version, an approval, and a test, and those live on the governance side of the administration boundary. What the pipeline does is deploy it reliably to the points that apply it. The runtime executes; it does not authorize itself.

One practical consequence recurs at renewal. An enterprise may legitimately have a vendor operate its decision points and control infrastructure. Accountability does not transfer with operation. The enterprise remains the accountable integrator for what its control points do, and portability (whether the policy it has written can move to another engine) must be designed in at the start rather than discovered when the contract is renegotiated.

Runtime Operability Bands

The category needs a way to describe how well an enterprise operates its runtime controls, reusable across the three control-category Foundation Reports so that governance, runtime, and observability can be assessed on commensurable terms. The Runtime 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 7. The runtime operability bands, R0 through R5, and the entry condition that defines each

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. verification, authentication, and credential integrity
3. risk responsiveness and fraud resistance
4. session integrity and lifecycle control
5. federation and cross-domain trust
6. authorization granularity and enforcement completeness
7. programmability, testing, interoperability, and drift control
8. multi-constituency scalability, including workload and agent tempo

The last two dimensions are held in common with the Governance Operability Bands so that the two categories remain commensurable; the first six are specific to what runtime controls do.

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 8. The eight operability dimensions and the observable test that scores each

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 R3 on the programmability dimension, and a control estate whose definitions are not versioned, testable, and pipeline-controlled is not R4 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 and legacy applications cannot support uniform control depth, so an enterprise may deliberately run a constituency at 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 the same evidence discipline as their governance counterpart: 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.

Figure 8. A runtime 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 centrally brokered, session-based controls would, in CAI’s estimation, report at R2 or R3 today. That is an assessment of the state of the category rather than a defect in the measure.

Common Misconceptions

Five beliefs recur, and each is worth stating plainly and correcting.

• That runtime control is authorization, and enforcement is its name. Authorization is one family of six, and enforcement is how an authorization decision takes effect.
• That authentication establishes trust for the session. It establishes trust at that instant. What the session holds an hour later is a separate question most estates never ask.
• That strong authentication makes a session secure. Strength is three independent properties, and the one most often missing is binding: a hardware authenticator that issues a bearer token has produced a credential anyone who obtains it can replay.
• That federated access is authenticated access. It is access on an assertion about an authentication performed elsewhere, under a trust relationship, by a domain that may have revoked the subject since.
• That a workload or agent presenting a valid token is authenticated. If the token is a person’s and the credential is unbound, what has been established is that something holds a secret, and attribution is already lost.

A worked example

An insurance group runs claims analytics in a subsidiary that operates its own identity provider and its own security domain, acquired three years ago and never consolidated. An analyst employed by the parent asks an assistant agent to assemble a portfolio exposure report. The agent calls an orchestration service in the subsidiary domain, which calls a claims service, which queries a dataset holding policyholder records. Partway through, the parent’s security operations flags the analyst’s account. Follow the access.

• She authenticates in the parent domain with a phishing-resistant authenticator. The session is established at a known assurance level, and that level is recorded as a property of the session rather than discarded once authentication succeeds.
• The subsidiary domain receives a federated assertion and evaluates it rather than merely accepting it: the assurance level asserted, the freshness of the authentication, the audience, and the trust chain back to an anchor it recognizes. The assertion carries the level the dataset requires, so the access proceeds — and the subsidiary records which domain it is relying on, because it will need that later.
• The agent is issued its own short-lived, key-bound workload identity rather than inheriting her session token, so every downstream control point can see two parties: the person on whose authority the work proceeds, and the software making the call.
• Its token is exchanged at each hop for one scoped to the next, so the least-trusted hop carries the least privilege. A transaction context travels with the chain, carrying the original subject, the acting agent, and the authorization context that was true when the chain began.
• Authorization resolves at three tiers in sequence. The gateway confirms a valid token from a trusted issuer with the right audience and scope. The claims service confirms that this subject may run an exposure analysis on this portfolio. Neither can decide what the query should return.
• At the dataset, fine-grained authorization applies. The analyst may see the portfolio, so the query is permitted with obligations: rows outside her business unit are filtered, and policyholder identifiers are masked. A binary control here would have had to deny the report or disclose the identifiers.
• The parent’s security operations flags the account for impossible travel and anomalous behaviour, and the risk assessment rises. This is the moment that tests the architecture, because the signal originates in one security domain and the live access is in another. Because the subsidiary subscribes to the parent’s signal stream, the event crosses the boundary and its control points re-decide: maintained assurance has fallen below what the dataset requires.
• The response is proportionate rather than absolute. The session is not terminated; the enforcement point returns a step-up obligation and constrains the agent’s scope to non-sensitive fields until it is satisfied. She re-authenticates, assurance is restored, and the chain resumes. Had she failed or not been present, the agent’s authority would have lapsed with her session, because it was derived from it.
• Every assurance change, assertion evaluation, decision, granularity, outcome, and obligation is emitted from both domains, so observability can state what was attempted, in which domain, under what assurance, on whose authority, and by which acting party.

Nothing in that sequence required a product that does not exist. It required an assertion that was evaluated rather than accepted, a credential bound to its holder, an agent with an identity of its own, authorization resolved at three granularities, outcomes richer than permit and deny, a signal that crossed a domain boundary, and a response proportionate to the change.

Where an estate fails this scenario, it usually fails at the same four points. The subsidiary accepts the assertion without evaluating it. The agent rides the analyst’s token. The dataset can only permit or deny. And the risk signal stops at the boundary between the two domains.

• an assertion that was evaluated rather than accepted;
• a credential bound to its holder;
• an agent with an identity of its own;
• authorization resolved at three granularities, against what each control point could actually know;
• outcomes richer than permit and deny;
• a signal that crossed a domain boundary, and a response proportionate to the change.

The scenario as a diagnostic. Read as a table, the scenario becomes a diagnostic an architect can run against an estate. For each event it names the family in play, the control that maintains trust, the evidence produced, the role accountable, and the operability dimension it belongs to. Running the same five columns against your own critical access paths turns the model into a worklist.

Table 9. The worked example read as a diagnostic, mapping each event to the family, control, evidence, accountable role, and operability dimension that address it

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 10. What each audience takes away: a first move and the test that tells them it is done

Conclusion

Identity and access runtime controls are the controls that operate at the moment of access and for as long as the access lasts. They are six capability families — identity verification, authentication and its strength, risk assessment and fraud prevention, session management, federation and propagation across security domains, and authorization with the enforcement that carries a decision out. Each is substantial engineering built into the internals of systems. Together they consume the intended access state governance produces, resolve it against a specific attempt and the current context, apply the result where the access happens and at the granularity the resource requires, and emit what actually happened so that observability and governance can act on it.

Everything above comes down to one idea. Trust is the foundation runtime controls rest on, but the thing they control is narrower and more useful to name: effective trusted authority — the power a subject is permitted and sufficiently trusted to exercise at that moment. No single capability family produces it, and none of them can hold it alone.

Once this is clear, almost every failure in the category looks the same. The control was well built for the moment it was designed for, and the moment passed. The assurance was measured once. The session outlived it. The assertion was accepted and never revisited. The risk was scored at the least informative moment. The decision was resolved at a coarser granularity than the resource required. And nothing asked again — so a subject went on exercising authority the enterprise could no longer show was warranted.

The response is four things. Put a control point on every consequential access path, at the granularity its resource requires. Bind credentials to their holders, so that what strong authentication produced cannot be silently stolen. Treat every security domain boundary as a control boundary, with a revocation path that crosses back. And decide what your signals should cause, so that a compromised credential or a revoked entitlement changes what is happening now rather than what is reviewed later. Do those things, and runtime controls become what they are meant to be: not a gate that is passed, but a trust that is held.

Acronym Key and Glossary

Acronyms and terms used in this report.

Evidence

This report draws on standards and specifications from the recognized bodies, peer-reviewed research on authentication, authorization models, and continuous evaluation, published regulatory and program direction, and enterprise and practitioner accounts of runtime controls in operation. Vendor material was read only as evidence of what has been built, never as evidence of adoption or effectiveness. Third-party empirical claims that could not be traced to independent primary sources were excluded, and specifications that remain at draft status are identified as such wherever they are relied on. Where this report generalizes about the state of enterprise practice, the statement is CAI’s assessment drawn from its own engagements rather than an independently evidenced measurement, and is marked as such.

Standards and specifications referenced

• NIST SP 800-63 Revision 4, Digital Identity Guidelines, defining IAL, AAL, and FAL as independent assurance dimensions, and introducing syncable authenticators.
• NIST SP 800-207, Zero Trust Architecture; NIST SP 800-53 Rev. 5, control families AC and IA; NIST SP 800-162 on attribute-based access control.
• OAuth 2.0 (RFC 6749) and its modern extensions: Pushed Authorization Requests (RFC 9126), Rich Authorization Requests (RFC 9396), Demonstrating Proof of Possession (RFC 9449), mutual-TLS client authentication and certificate-bound tokens (RFC 8705), and Token Exchange (RFC 8693).
• RFC 9470, OAuth 2.0 Step-up Authentication Challenge Protocol.
• OpenID Connect Core 1.0; OpenID Federation 1.0, OpenID Final Specification (February 2026), refactored into OpenID Federation 1.1 in May 2026; SAML 2.0 (OASIS Standard, 2005) and WS-Federation 1.2 (OASIS Standard, 2009), which remain deployed in legacy and established federation environments.
• OpenID Shared Signals Framework, Continuous Access Evaluation Profile (CAEP), and Risk Incident Sharing and Coordination (RISC): OpenID Final Specifications (2 September 2025). Security Event Token, RFC 8417.
• OpenID AuthZEN Authorization API 1.0, Final (January 2026), standardizing the enforcement-to-decision interface.
• OASIS XACML 3.0 (2013, Errata 01 2017); OASIS ACAL 1.0 and XACML 4.0 (Committee Specification Draft 01, February 2026).
• INCITS 359-2012 (R2022), Role Based Access Control.
• W3C Web Authentication (WebAuthn Level 3, Candidate Recommendation Snapshot, 26 May 2026; Level 2 remains the completed Recommendation) and the FIDO Alliance Client to Authenticator Protocol 2.2 (Proposed Standard, 2025), with passkeys as the consumer profile.
• SPIFFE workload identity specifications and trust bundles, with SPIRE as their reference implementation; IETF WIMSE workload credentials (Internet-Draft).
• OAuth transaction tokens, draft-ietf-oauth-transaction-tokens-08 (March 2026), Internet-Draft.
• draft-klrc-aiagent-auth-02 (Informational, June 2026), an individual conceptual model for AI agent authentication and authorization, not a standard.

Related Reading

• IAM-RD-01 for the Identity and Access Root Document
• IAM-F-GOV-01 for the Identity and Access Governance Controls Foundation Report.
• IAM-F-OBS-01 for the Identity and Access Observability Controls Foundation Report.
• IAM-F-SUB-01 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 attempting an action. The subject is distinct from the digital identity that represents it and from the credential through which it proves that identity.

Identity verification. The binding of a digital identity to a subject by validating evidence of identity. Performed principally at enrolment; performed again at runtime where a high-value action, a recovery flow, or evidence of account takeover calls the binding into question.

Authentication. The verification of a claimed digital identity using one or more credentials. Its runtime output is an assurance level, not a binary result.

Strong authentication. Authentication that goes beyond a shared secret. Three independent properties matter: the number and independence of factors, resistance to phishing, and the binding of the resulting credential to its holder.

Assurance level. A measurable level of confidence in an identity process, expressed across three independent dimensions: the proofing that established the identity, the authentication process and its binding to that identity, and the federation that conveyed the result.

Required assurance. The assurance a resource demands of any access to it, set by its sensitivity and the consequence of misuse. A property of the resource, not of the subject.

Maintained assurance. The assurance an access actually holds at a given moment. Established at authentication and subject to decay as credential, device, context, domain, and risk state change. The task of runtime control is to keep it at or above required assurance for the life of the access.

Proof of possession. A property of a credential or token that binds it to a key its holder controls, so that presentation alone is insufficient. The distinction between a bearer credential, whose holder is its owner by definition, and a sender-constrained one.

Risk-based (adaptive) control. A control whose requirement is set by a contextual risk assessment — device, location, behaviour, transaction value, prior activity — rather than applied uniformly.

Session. The temporal context established after authentication during which a subject exercises access without re-establishing it. Its states are active, idle, expired, and terminated. The unit across which trust must be maintained.

Security domain. A boundary of trust and administrative control within which a common set of security policies, authentication mechanisms, and identity practices apply. Whether an access stays within one or crosses several is a first-order property of the runtime access decision.

Federation. The mechanism enabling authentication and identity assertion across security domain boundaries, so that a subject authenticated in one domain may reach resources in another on the strength of an assertion and a trust relationship.

Identity propagation. The carriage of subject and authorization context across the hops of a call chain, so that a downstream control point can decide against the original subject and the acting party rather than only the immediate caller.

Runtime authorization. The determination, in real time, of whether a specific attempted action by an authenticated subject on a specific resource is permitted, evaluated against current context rather than against standing grants alone.

Authorization granularity. The precision at which an authorization decision can be resolved and carried out. This report uses three tiers: coarse-grained at the edge (token, issuer, audience, broad scope); medium-grained at the service (this subject, this operation, this resource); and fine-grained in or beside the resource (this object, row, or field, under these conditions and for this purpose). The medium tier is CAI’s term for the service- and operation-level control that sits between the two commonly named tiers.

Policy decision point. The component that receives an authorization request, evaluates applicable policy against available attributes, and renders a decision. It decides; it does not carry out.

Policy enforcement point. The component that intercepts the access flow, requests a decision, and carries out the result including any obligation.

Policy information point. The component that supplies attribute values the decision requires but the request does not carry.

Enforcement outcome. What the enforcement point actually did: permit, deny, permit with obligations, filter, or mask. Distinct from the decision, which is what the decision point said should happen.

Obligation. A mandatory action the enforcement point or application must fulfil as part of enforcing a decision — step-up authentication, additional approval, a time bound, or mandatory logging. An obligation the enforcement point cannot fulfil is not a control.

Continuous access evaluation. The re-evaluation of an access while it remains open, driven by signals about changes in identity, credential, device, domain, or risk state. The mechanism that closes the gap between required and maintained assurance.

Control point. A location in the technology stack where a runtime control is applied. Placement varies by operating environment and determines what context is available and what granularity is achievable.

Effective trusted authority. The unit of runtime control, and a CAI term. The power a subject is permitted and sufficiently trusted to exercise at a given moment: permitted by governed policy, trusted to the assurance level the resource requires, and effective only where both hold at once and for as long as they continue to. Trust is the foundation the category rests on; effective trusted authority is what the controls keep accurate. It is the runtime counterpart of the distinction governance draws between a declared entitlement and an effective permission.

Capability family. One of the six groupings of runtime control used in this report — identity verification, authentication, risk-based control and fraud prevention, session management, federation and propagation, and authorization with enforcement. A structural term for organizing the category, not an ontology class.

Runtime access decision. The report’s central analytical construct: the resolution of governed intent against a specific attempted action and the current context — by a verified and authenticated subject at a known assurance level, within a session of known state, in one security domain or across several — resolved at the granularity the resource requires, carried out where the access happens, and revisited as circumstances change.

Notes

1. NIST SP 800-53 Rev. 5, control families AC (Access Control), notably AC-3 Access Enforcement and AC-12 Session Termination, and IA (Identification and Authentication), notably IA-2 and IA-2(8) replay-resistant authentication. NIST SP 800-207, Zero Trust Architecture, which frames access as granted per session on the basis of current observable state. ISO/IEC 27001:2022, Annex A controls 5.15 Access control, 5.17 Authentication information, and 5.18 Access rights, with implementation guidance in ISO/IEC 27002:2022.
2. NIST SP 800-63 Revision 4 (final, July 2025) carries Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL) as independent dimensions — a three-dimensional model introduced in Revision 3 (selected on the basis of risk). Revision 4 also introduces syncable authenticators, primarily synced passkeys, which provide phishing resistance and multi-device availability under different trust assumptions than device-bound authenticators.
3. Demonstrating Proof of Possession (DPoP), RFC 9449, binds a token to a client-held key at the application layer; mutual-TLS client authentication and certificate-bound access tokens, RFC 8705, bind at the transport layer. Workload identity credentials defined by the IETF WIMSE work bind a workload identity to its public-key material, with possession of the corresponding private key proven through separate protocol bindings.
4. OpenID Federation 1.0, approved as an OpenID Final Specification in February 2026, defines automatic trust establishment between entities using trust chains; in May 2026 the same functionality was refactored into OpenID Federation 1.1 and OpenID Federation for OpenID Connect 1.1. Within workload estates, trust bundles exchanged between trust domains serve the equivalent function for cross-domain workload authentication.
5. OAuth 2.0 Token Exchange, RFC 8693, provides the delegation and impersonation semantics for exchanging one token for another. Transaction tokens, at draft-ietf-oauth-transaction-tokens-08 (March 2026), carry immutable transaction context and mutable per-hop context through a call chain within a trust domain; the specification is an Internet-Draft and should be read as direction rather than as a settled standard.
6. OASIS eXtensible Access Control Markup Language (XACML) Version 3.0 defines the Policy Administration, Decision, Enforcement, and Information Points. The OASIS Attribute-Centric Authorization Language (ACAL) Version 1.0 and XACML 4.0, both at Committee Specification Draft 01 (February 2026), carry the same architectural elements toward a syntax-agnostic core.
7. The OpenID Shared Signals Framework, with the Continuous Access Evaluation Profile (CAEP) and Risk Incident Sharing and Coordination (RISC), was approved as OpenID Final Specifications on 2 September 2025. The underlying event format is the Security Event Token, RFC 8417. A receiver determines its own local follow-up action; the framework does not mandate a universal enforcement response to a given event.

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.