Identity and Access Observability Controls

Observations

Identity and access observability is the control category that establishes what actually happened. It is not a logging tier, not a detection product, and not the reporting surface of the other two categories. It operates at event time, on the record of accesses that have occurred and are occurring, and it returns two things: evidence to governance, and signal to runtime. Where governance decides what access should exist and runtime makes that decision effective at the moment of access, observability is what allows either of them to be assessed at all. An enterprise that cannot establish what happened cannot know whether its other controls worked.

• The field measures this category by inputs more than by outcome, so its metrics say little about whether it works. Telemetry volume counts logs collected. Coverage counts the configuration vulnerabilities and threats a tool could recognize under test conditions. Both describe the tooling, and where an action carries its own identity, that is enough. Where it does not, an enterprise can score well on both and still not know who did what. The metrics report on the estate they can see and say nothing about the estate they cannot.¹
• Attribution may fail quietly and everywhere, and no control fails with it. Shared administrative accounts, service accounts people log into, break-glass credentials, delegation that outlives its purpose, agents inheriting a person’s entitlements, each produces action recorded perfectly and attributable to no one. Adversaries know this; masking activity behind a shared account is documented tradecraft. It survives as ordinary practice because little breaks when it happens. The log is written, the alert fires, the certification completes, the audit passes. In CAI’s assessment this is among the category’s most consequential defects, and it goes unmeasured because the field has never named the property that is failing.
• Every capability in this category rests on an identity data foundation that is fragmented by construction. A single access crosses the identity provider, the vault, cloud control planes, the application, and the governance platform, each recording it on its own schema with its own idea of the subject. Reconstructing that access means joining on identifiers that disagree and clocks that are not aligned, so one person appears as several unrelated actors and correlation fails before analysis starts. A detection is only as good as the join beneath it. In CAI’s assessment this is a data-engineering problem the identity function does not staff for and the data function does not claim.
• The market has split the category in three, and enterprises have split the practice with it. Visibility platforms, posture management, and threat detection and response are separately named, separately sold, and separately budgeted. Vendors are now converging the products; enterprises have not converged the work. Posture findings reach an identity team as a remediation backlog, detections reach a security operations center as alerts, and neither queue sees the other’s evidence. The same misconfiguration is a low-priority finding in one place and the precondition of an incident in the other, with no one holding both facts at once.
• Machine and agent constituencies break the assumption that an action has one actor. An agent working under delegated human authority produces an event with two parties and a chain between them, and most identity telemetry carries a single subject field. So does the Shared Signals Framework, whose model admits exactly one subject principal per member.² The specifications are otherwise finished.³ What has not arrived is the ability to act on them: across the leading implementations, emitting events is standard while receiving and acting is licensed separately or simply absent. The ecosystem rewards emitting and charges for acting.

Positions

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

• Define observability by what it can establish, not by what it collects. Observability is the event-time category that establishes what happened, when, to what, and to whom it is attributable, and returns that to governance as evidence and to runtime as signal. Judge it by the questions it can answer after the fact and the actions it can trigger during, not just by ingest volume, source count, retention window, or technique coverage. A pipeline that collects everything and establishes little is not an effective control, however complete its coverage map. The first question to ask of an observability program is not what it watches but what it can prove.
• Treat attribution as the unit of control, and score it rather than assume it. Attribution is not a binary property that an investigation either achieves or does not. It is a graduated property of an event, degraded at identifiable and engineerable points: shared credentials, delegation without context propagation, identifier collision across sources, clock skew, and the ability of the implicated party to alter the record. This report defines a five-level scale for it. An enterprise that cannot state the attribution confidence of its privileged actions cannot bound the scope of its own incidents, cannot defend its audit trail when it is contested, and cannot tell the difference between an access review that examined a person’s behavior and one that examined an account’s.
• Make the loop the deliverable: observability that does not emit is a record, not a control. The category’s output is evidence into governance and signal into runtime. Shared signals are the mechanism that makes the second half real, and the mechanism is now specified well enough to build against. Judge a transmitter by what it emits on a state change and a receiver by what it does on receipt. An enterprise that receives a session-revoked event and writes it to a log has implemented a protocol and not a control, and should not record the capability as present.
• Operate posture and detection as one evidence base with two response paths. A posture finding says an exposure exists. A detection says one is being exploited. Usually it is the same exposure, and the finding came first. Keep the two queues separate if your operating model needs that, but do not keep the evidence separate. The identity team and the security operations center should be looking at the same picture of the same identity. The test: can you trace a detection back to the posture finding that made it possible, without someone joining two consoles manually?
• Engineer observability controls as versioned, testable artifacts on a named and owned identity data foundation. Detection logic, correlation joins, attribution rules, retention schedules, and evidence schemas are all code. Treat them that way: version them, test them, deploy them through a pipeline, and check them for drift. But the harder obligation sits underneath. Give the identity data foundation a named owner, because no capability here can be better than the joins beneath it, and an unowned foundation decays quietly while every tool above it keeps reporting success.

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 Observability 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 Observability is the only control category that both consumes the substrate and continuously reports on its condition. When the substrate is weak, observability is where you notice it. The usual mistake is to treat that as an observability problem and buy another tool, when the fix should be applied to the upstream identity and access data.

What Observability Is, and What It Produces

Identity and access observability is not one mechanism. Six capability families share a single job, worked from two kinds of raw material.

• The estate as it currently stands: identities, entitlements, credentials, and configuration. From this the families establish what exposure exists and who owns it.
• The record of what has occurred within it: the events. From this they establish what happened and who did it.

Both go to governance as evidence and to runtime as signal. The six families are operated by different teams, bought from different vendors, and measured by different metrics. This report’s argument is that they share one dependency and one output, and that both are usually unowned.

The shared dependency is the identity data foundation. The shared output is an account of the estate that resolves to accountable identities: what exists and who owns it, what happened and who did it. Every family degrades the same way when the foundation is weak, and every family produces something worthless when that resolution fails.

• A detection that identifies no one.
• A posture finding on an identity nobody owns.
• An audit trail that names an account rather than a person.
• An analytic model trained on a subject field that merges five actors into one.

Six capability families, one job

The families are presented in dependency order rather than maturity order. Event capture and the data foundation come first because everything else consumes them. Attribution comes second because it is the property the rest of the category exists to establish and the one that determines whether any downstream output can be acted on. Posture and detection follow, treated together for reasons the report argues rather than assumes. Shared signals and continuous evaluation carry the output back out. Analytics, intelligence, and evidence turn the record into something a decision can be made from.

Table 1. The six capability families, what each establishes, and what each depends on

Read across the third column and the report’s structure follows. Five of the six families depend on something owned outside the observability function.

• The identifier space and clock discipline belong to the directory and platform teams.
• The delegation context that would carry authority belongs to the application teams.
• Credential practices that stop pooling actors belong to privileged access and governance.
• A complete inventory belongs to the application and platform owners.
• A receiver that acts on a signal rather than logging it depends on what the vendor shipped and what runtime policy will accept.

The exception is detection and response, whose principal dependency is attribution, and attribution is the one thing in this table the observability function does own. That is why attribution rather than collection is treated here as the unit of control: it is the only item on the list the function can fix without direct dependency.

Three things distinguish this category from the other two and are worth stating before the families are treated individually.

• Its subject matter is the past, and its raw material is fixed before it arrives. Governance decides about a future access and runtime acts on a present one; observability reasons about an access that has already occurred. Everything the category can ever establish about an event was determined at the moment of emission and cannot be improved retrospectively.
• It has no enforcement point of its own, and that is a feature. Governance enforces through the provisioning path and runtime through the decision point. Observability enforces nothing directly and instead obliges the other two to act, which makes it the easiest category to under-fund: its failures appear as failures of the others. An incident that could not be scoped looks like a detection failure, an access review that certified an unused entitlement looks like a governance failure, and in both cases the actual defect was that nobody could establish what had happened.
• It degrades gracefully in appearance and catastrophically in substance. A governance control that stops working produces a visible queue; a runtime control that stops working produces a visible outage or breach. An observability control that stops establishing anything continues to produce dashboards, alerts, and reports of exactly the same shape as before. There is no operational signal that the category has failed, which is why it must be measured deliberately rather than monitored.

The Event-Time Control Point

The three control categories are distinguished by when they act, and the times are not a sequence.

• Admin-time is when access is decided: a request is approved, a role is assigned, an exception is recorded.
• Runtime is the moment of access and the life of the session that follows.
• Event-time is when an occurrence is recorded and can be reasoned about, and it overlaps runtime rather than following it.

That overlap is the most frequently misunderstood point in the category. Observability is commonly described as after the fact, which is true of forensics and audit and false of everything else the category now does. A risk signal computed from behavior observed seconds ago and delivered to a policy decision point before the next authorization is an event-time output consumed at runtime. A device falling out of compliance is observed at event time and acted on at runtime. Continuous access evaluation is the clearest case: the evaluation is a runtime act, and the thing being evaluated is an event-time product.

The boundary that matters is therefore not temporal but functional. Observability produces and distributes the signal. Runtime decides and enforces it. An enterprise that blurs this builds one of two failures. If observability is allowed to enforce, the enterprise acquires a second, undocumented authorization system whose policy nobody authored and whose decisions nobody governs. If runtime is expected to observe, the enterprise gets telemetry shaped like its authentication traffic and blind to everything that never passes through an interactive login.

Standards Note NIST’s guidance on log management remains SP 800-92, published in 2006. Its replacement has been an initial public draft since October 2023, with the comment period closed since November of that year. An enterprise citing it for logging architecture is citing a document written before cloud control planes, federated session management, and machine identity at scale. The revision will not close that gap when it lands: it is scoped to log management planning, and explicitly excludes implementing log management technology and making use of log data. The auditable-event requirements that are current sit in the AU control family of SP 800-53, not in the log management guidance behind it.

The control point itself is the place where an occurrence becomes a record with enough context attached to be attributable later. It is almost never the log sink, which receives whatever the emitter chose to send. It is the emitter: the identity provider, the vault, the gateway, the application, the data platform. What is not attached at the point of emission cannot be reconstructed downstream, and the two things most commonly omitted there are the authority under which the action proceeded and the chain by which it arrived. Both omissions are cheap to fix at the emitter and impossible to fix anywhere else, which is the single most useful design consequence in this report.

Figure 1. Admin time, runtime, and event time as three lanes rather than a sequence, showing what each produces, where event time overlaps runtime, and what the emitter does and does not attach at the point of emission

Boundaries and the Handoffs

Observability sits between the two other control categories and returns something different to each. The category’s value is realized entirely in those two handoffs; an observability program whose output terminates in a dashboard has built a reporting function.

The governance handoff: evidence out

Governance authors intent and needs to know whether that intent held. What observability returns is evidence: that an entitlement was never used, that a certification decision was approved and never executed, that an exception outlived its expiry, that a privileged action occurred under a credential nobody owns. This is not reporting. It is the input that turns certification from an attestation exercise into a decision informed by behavior, and it is the only mechanism by which a governance control can be shown to have operated rather than merely to have completed.

The runtime handoff: signal out, telemetry in

Runtime makes authority effective and needs to know when the conditions underlying an existing access have changed. What observability returns is signal: session revoked, credential changed, device out of compliance, risk level raised. What it receives back is the runtime’s own account of what it decided and enforced, which subject, which resource, which action, which obligations applied, which policy version was in force. That last item is the one most commonly missing, and without it an enterprise can show that a decision was made but not what it was made from.

The loop closes only if both handoffs carry attribution with them. Evidence that names an account tells governance nothing about a person. A signal that names a session tells runtime nothing about the agent chain behind it. The handoffs are where attribution is most often silently dropped, because each side assumes the other established it.

Figure 2. The observability loop, showing what each return path carries to governance and to runtime, the telemetry returned from runtime, and what breaks when either return path is absent

Identity Events and the Data Foundation

Four things are routinely called the same thing, and the conflation is the root of most correlation failure. The occurrence is what happened. The record is what a system wrote down about it. The format is the envelope in which the record travels between systems. The finding is what an analysis concluded from one or more records. These are different objects with different lifetimes, different owners, and different integrity requirements, and an architecture that does not separate them cannot say whether a gap is a gap in reality, in capture, in transport, or in inference.

Table 2. The identity event distinguished from the record, the format, and the finding

The data foundation is what makes joining possible across the four. It has three components, and each fails characteristically.

• The identifier space determines whether the same subject in two systems can be recognized as the same subject. It fails through collision, through reuse of identifiers after deprovisioning, and through the absence of any stable identifier for machine constituencies.
• The time base determines whether two records can be ordered. It fails through clock skew, through mixed time zones, and through systems that record ingestion time rather than occurrence time, which silently destroys causality.
• The relationship model determines whether the estate can express that an agent acted for a person, that a service account belongs to an application, that an entitlement grants a permission on a resource. It fails by having no place to put those facts at all.

Watch-Out Ingestion time is not event time. A pipeline that stamps records on arrival will order a slow source after a fast one regardless of what actually happened first, and every causal chain reconstructed from it will be wrong in a way that looks entirely plausible. Check which timestamp the correlation joins on before trusting any incident timeline.

Where the foundation is weak, the correct response is not another analytical layer on top of it. Adding an intelligence platform to an unreconciled identifier space produces confident conclusions about the wrong actors, which is worse than no conclusion, and it is the most expensive failure mode in the category because it is invisible until an incident tests it.

Ownership is the part of the foundation that has no technical remedy. The identifier space, the time base, and the relationship model are each maintained by decisions taken in systems owned by different teams: the directory team chooses whether identifiers are reused after deprovisioning, the platform team chooses whether hosts synchronize to a common time source, the application teams choose what subject they write into their own logs. No single one of those decisions looks like an observability decision to the person making it, and the aggregate determines what the enterprise can ever establish.

The practical form of ownership is a small set of published contracts rather than a platform. Four are sufficient, and an enterprise that has written them down can answer questions about its estate quickly:

• Which identifier is canonical, and what resolves to it.
• What timestamp every emitting system must carry, and to what tolerance.
• What minimum context accompanies a privileged action (at least the acting party, the authorizing party, and the policy version in force).
• How long each class of record is retained, and under whose integrity guarantee.

Enterprises that have not written these down will find that each incident re-litigates the same four questions under time pressure, and answers them differently each time.

Attribution

Attribution is the property that makes a record evidentially useful rather than merely descriptive. An action that cannot be attributed to an accountable identity has been observed but not established. It can be counted, charted, and alerted on. It cannot be acted on against anyone, defended in a dispute, or used to bound an incident. Every other capability in this category produces output whose value is capped by the attribution beneath it.

The field treats attribution as binary and as an investigative outcome (something an examiner achieves with enough effort and enough artifacts). That framing is why it is never measured. If attribution is an outcome of investigation, it can only be assessed after an incident, when it is too late to engineer. CAI’s position is that attribution is a property of the event, present in degrees, determined by decisions taken long before the event occurs, and therefore both measurable and engineerable in advance.

Attribution confidence

Five levels describe how much an event establishes. They are properties of a class of event rather than of an enterprise, so a single estate will hold different levels for different actions, and the useful exercise is to score the actions that matter (privileged operations, data access, configuration change) rather than the estate as a whole.

Table 3. The attribution confidence scale, A0 through A4, and the condition that defines each

A4 exists because of a specific and well-documented threat. Administrators with superuser capability can disable, modify, or delete the records that would implicate them, and the forensic literature treats this as a primary anti-forensic method rather than an edge case. An audit trail that an administrator can edit attributes nothing about that administrator, which means the estate’s most privileged actions are frequently its least attributable, the exact inversion of what the control is for.

CAI View Attribution confidence is the unit of control for the observability category, in the way that effective trusted authority is the unit for runtime and the governed access binding is the unit for governance. An enterprise that scores its privileged actions A0 or A1 has an observability program that cannot support the decisions it is being asked to support, regardless of how much telemetry it holds or how many techniques it covers.

Where attribution degrades

The degradations are few, well understood, and individually fixable, which is what makes the aggregate failure remarkable. Each has a known remedy:

• Credential pooling collapses many actors into one subject. Remedy: per-actor credentials, with individual authentication to a shared target where the target itself cannot be un-pooled.
• Delegation without context propagation preserves the actor and loses the authority. Remedy: a transaction context that travels the whole chain and survives every hop.
• Identifier collision across sources merges distinct actors, or splits one. Remedy: a reconciled identifier space with a canonical join key and a resolution rule for everything that is not it.
• Clock skew destroys the ordering that would establish causation. Remedy: a disciplined time base recording occurrence rather than ingestion, with skew monitored at the emitter.
• Record mutability lets the implicated party remove the evidence. Remedy: an append-only evidence store outside the administrative control of the estate it records.

None of these is novel and none is expensive relative to what is spent on the analytical layers above them. They persist because no control fails when they are absent, and because no metric in common use would show their absence. Naming the property and scoring it is therefore not an academic exercise. It is the mechanism by which a silent failure is made to produce a finding.

Scoring is deliberately narrow. The exercise is not to assign a level to every event in the estate, which would be both impossible and useless, but to enumerate the action classes whose attribution actually matters (privileged database and infrastructure operations, changes to the identity infrastructure itself, access to regulated data, financial transaction authorization, and any action an agent performs under delegated authority) and to establish the ceiling for each. Fifteen to twenty classes covers most enterprises, and the result is a short list of specific, fixable gaps rather than a maturity score.

The value of the scale is that it converts an architectural argument into a finding someone owns. “We should not use shared administrative accounts” is a position that has been losing to operational convenience for thirty years. “Privileged database operations in the settlement estate are attributable at A1, meaning no individual can be held accountable for any of them” is a statement with a named owner, a remediation, and a place in a risk register. The scale does not make the remedy easier; it makes the absence of the remedy visible.

Figure 3. One call chain read hop by hop, showing what each record actually carries, the attribution level it leaves behind, the remedy that would raise it, and why the chain ceiling is the lowest hop

Posture and Detection: One Evidence Base, Two Response Paths

Identity security posture management (ISPM) and identity threat detection and response (ITDR) are sold as adjacent categories and operated as separate practices. They are the same estate observed at two moments. A posture finding says an exposure exists; a detection says an exposure is being exploited. In the majority of identity incidents the second is the direct consequence of the first, and the enterprise held the evidence for the first before the second occurred.

Posture: what exposure exists

Posture management computes exposure from the current state of identities, credentials, entitlements, and configuration. Its outputs are findings rather than events: an account without multi-factor enrolment, a service account with interactive login rights, a standing privileged assignment where a just-in-time grant would serve, a toxic combination of entitlements that no single grant would have flagged, an orphaned identity whose owner left the organization, an attack path that reaches a tier-zero asset in three hops.

The analytical technique is mature and is not where posture programs fail. They fail on inventory. A posture assessment is a statement about the identities it knows about, and the categories it knows least about (workload identities, embedded credentials, tokens issued outside the identity provider, agents registered by application teams) are the categories with the fastest growth and the weakest ownership. A posture score computed over a partial inventory is not a conservative estimate of exposure; it is an unbounded one, because nothing in the calculation reveals what is missing.

Table 4. Posture findings, the exposure each names, and the attribution consequence when it persists

Detection: what is being exploited

Detection identifies exploitation in progress or after the fact. The capability is real and the metric attached to it is not. Technique coverage measures what a rule set can recognize under laboratory conditions; it does not measure what the enterprise can establish in production, and the published evidence shows the gap is large and systematic. The more useful question for each detection class is what it establishes when it fires, whether it produces an actor, a scope, and an authority, or only an event.

Table 5. Detection classes and what each establishes when it fires

Watch-Out A detection that fires on an action performed under a pooled credential has detected something and identified no one. Containment can still proceed (the account can be disabled) but scoping, notification, and any consequence for the responsible party cannot. Score the detections that matter most against the A-scale before buying more of them.

One evidence base

The argument for unification is not organizational tidiness. It is that each side holds the context the other needs. A detection is triaged against the posture of the identity it concerns: an anomalous authentication on an account with standing domain privilege and no owner is a different event from the same anomaly on a fully governed account, and a triage queue that cannot see the difference will prioritize by alert severity rather than by exposure. Conversely, posture findings are prioritized by which exposures adversaries are actually reaching for, which only detection data can tell you.

The practical test is whether a detection can be traced to the posture finding that made it possible without a person joining two consoles manually, and whether a posture finding carries the detection history of the identities it names. Enterprises that pass this test generally did not buy a converged product; they built a shared identity data foundation and pointed both practices at it. Enterprises that bought a converged product and kept two teams, two queues, and two definitions of an identity did not pass it.

Sequencing follows from the same observation. Where an enterprise is investing in one of the two, posture generally repays first, because posture findings are pre-incident and individually remediable while detections are post-incident and individually only informative. The exception is an estate whose inventory is too incomplete for posture assessment to mean anything, in which case detection data is the cheapest way to discover what identities actually exist (a diagnostic use of detection that most programs never consider).

Both practices share a failure mode worth naming separately: they are evaluated on volume of findings and volume of alerts, which are measures of production rather than of establishment. A posture program that closed four thousand findings and left every shared administrative credential in place has reduced a count and not an exposure. A detection program that triaged nine thousand alerts and could not attribute any of the three that mattered has produced work rather than establishment. The dimensions in this report are written to measure the latter.

Shared Signals and Continuous Evaluation

Shared signals are the mechanism by which observability stops being a record and becomes a control. A transmitter emits a security event token when a state relevant to access changes; a receiver consumes it and acts. The pattern closes the gap that otherwise defines federated access: an identity provider revokes a session and the relying party continues to honour its token until the next refresh, which may be minutes, hours, or never.

The specification layer is essentially complete. The framework and its two profiles (continuous access evaluation and risk incident sharing) were approved as final specifications in September 2025, which fixes them against further revision. The SCIM events profile reached RFC status in May 2026, extending the same token format to provisioning lifecycle changes. An interoperability profile specifying the minimum a compliant implementation must offer entered its final review in July 2026, with the membership vote scheduled to close in October.⁴ An enterprise can build against this stack today without betting on a draft.

The emit and act asymmetry

What has not arrived is symmetric capability. Emitting is cheap, standard, and widely shipped; receiving and acting is scarce and, where it exists, frequently licensed separately. Three implementations show the same shape:

• The most complete commercial implementation gates the receiver, not the transmitter. Its documentation describes the transmitter as a standard platform capability and the receiver as a feature of a licensed threat-protection add-on.
• The largest enterprise identity provider publishes no supported external path in either direction. Its continuous evaluation operates as an internal closed loop, and it was absent from the interoperability event that demonstrated the finalized specification.
• The leading open-source identity provider shipped a transmitter first, with no receiver. Experimental support arrived in mid-2026 as a transmitter only. This is from the one implementer with no commercial incentive to gate anything, which is what makes it the most telling of the three.

This is not a temporary implementation gap. It is what the incentives produce. A transmitter improves the security of the parties who consume its events and costs the emitter little; a receiver that acts must own the consequences of acting on another party’s assertion, integrate with a policy engine, and expose itself to a new failure mode. The consequence for architecture is direct: an enterprise designing a shared-signals topology should assume it will be able to emit widely and act narrowly, and should place its receiving-and-acting capability where it will do the most good rather than assuming it will be available everywhere.

Standards Note The Shared Signals Framework, the Continuous Access Evaluation Profile, and the RISC Profile were published as OpenID Final Specifications on 29 August 2025 and are not subject to further revision. RFC 9967 published the SCIM profile for security event tokens in May 2026. The CAEP Interoperability Profile is in its final public review, which closes 25 September 2026, with the membership vote running to 10 October 2026.

One consequence of this asymmetry should be stated plainly, because it bears on how an enterprise is assessed. Closing the loop is an O4 entry condition, and for some estates the capability to close it is sold separately from the platform that would close it. Where an enterprise can emit but cannot act because the receiving function sits behind a license it has not bought, the finding belongs in the assessment as a commercial constraint rather than as an operational failure, and it belongs in the vendor conversation, where it is one of the few places an enterprise has leverage.

One structural limitation should also shape design decisions now.

Continuous evaluation is the consuming half of the pattern and belongs to runtime, not here. The distinction is worth holding precisely: observability produces and distributes the signal; runtime decides what to do about it. An architecture that puts the decision in the observability platform has created a second authorization system that no one governs. What the platform should own instead is everything up to the decision, the signal, its provenance, and the confidence attached to it, which is the subject of the family that follows.

Figure 4. Three shared-signals implementations compared across transmit, receive, and act on receipt, with whether the loop closes in each case and why the acting half is the scarce one

Identity Analytics, Intelligence, and Evidence

The final family turns the record into something a decision can be made from. Three distinct outputs are usually collapsed into one and should not be.

Three distinct outputs are usually collapsed into one, and should not be:

• Analytics computes properties of the record. Baselines of normal behavior for a subject or peer group, deviations from them, entitlement usage against entitlement grant, concentration of privilege, and the blast radius reachable from a given identity.
• Intelligence says which of those properties matter now. It combines the computed properties with external context (threat activity, credential exposure, known adversary tradecraft) none of which the enterprise produced itself.
• Evidence is the defensible account that a control operated. Not that a review completed, but that the access it reviewed was or was not used, by whom, and under what authority.

Evidence is the output this report treats as most undervalued, because it is the one produced as a by-product elsewhere and consumed as an obligation. Continuous controls monitoring has made evidence collection largely automatic, and the automation has been read as a compliance efficiency rather than as a control capability. It is a control capability. Evidence that an entitlement was granted and never exercised is the strongest available input to a removal decision. Evidence that a certification approval was recorded and never executed is a governance control failure that no governance system will surface on its own. Evidence that a privileged action occurred at A1 is a statement about the enterprise’s ability to hold anyone accountable for it.

CAI View Treat evidence as a control output with a specification, not as a reporting by-product. An evidence schema should state, for each control, what artifact demonstrates operation, at what attribution confidence, retained for how long, and under whose integrity guarantee. Enterprises that write this down discover quickly which of their controls cannot currently be evidenced at all.

The analytical layer inherits everything beneath it. A behavioral model is a model of the subject field it was trained on; where that field pools five actors, the baseline it learns is the aggregate of five behaviors and will not deviate when one of them changes. This is the mechanism by which sophisticated analytics on a weak foundation produce confident and wrong conclusions, and it is why the sequence in this report runs foundation first.

Intelligence has an additional and less discussed dependency: it is the only part of the category that consumes assertions the enterprise did not produce. Credential exposure feeds, threat activity reporting, and shared signals from other domains all arrive as claims whose provenance and confidence the enterprise cannot independently verify. Treating them as facts about the estate rather than as claims about it is a category error that propagates quickly, because an external claim about an identity will be joined to internal records using the same identifier space that is already the weakest part of the foundation.

The discipline is to carry provenance and confidence with every external assertion and to keep them attached through the join, so that a decision made partly on an external claim can be reconstructed later with that dependency visible. This matters most in exactly the circumstances where it is least likely to be observed: an incident under time pressure, where an external feed provided the initial lead and nobody recorded that the identity resolution behind it was probabilistic.

Observability Coverage

Coverage in this category is not source coverage. It is the question of which constituencies and environments the enterprise can actually establish action for, and the answer varies far more than most programs assume. The pattern is consistent: attribution is strongest where an interactive human authentication occurs and weakest everywhere else, which is precisely inverted from where the volume of access now sits.

The identity constituency

Table 6. Observability coverage by identity constituency, and the attribution ceiling each typically reaches

Two conclusions follow:

• A program organized around the identity provider inherits its blind spots. The coverage map comes out shaped like interactive authentication traffic, and the accesses that never involve an interactive login (service to service, agent to tool, query to dataset, anything arriving already authenticated from another domain) are where establishment is thinnest.
• The ceiling is set by credential and delegation practice, not by telemetry. Which means the remedy for most of the table above is a governance or runtime change, and not an observability purchase.

Watch-Out An agent registered against a person’s account and inheriting that person’s entitlements is the fastest way an enterprise loses attribution at scale, because it is invisible to every control that examines entitlements rather than actors. The governance record shows one identity with appropriate access. The runtime record shows that identity authenticating normally. Only the observability record could show two parties, and only if someone specified that it should.

The technical and business environments

Across environments the constraint shifts from what is emitted to whether it can be joined. On-premises directories emit richly and in a schema of their own. Cloud control planes emit consistently within a provider and incompatibly across providers. Software-as-a-service applications emit at whatever granularity the vendor chose, frequently without a stable subject identifier and frequently only to a tenant administrator. Data platforms are where the consequential access happens and where identity context is thinnest, because the query arrives under a connection identity rather than a person.

Business environment adds the constraints that determine whether evidence is admissible rather than merely available: jurisdictional limits on what may be collected about a person, retention obligations that differ by entity, and works-council or equivalent constraints on behavioral monitoring of employees. An enterprise that designs a monitoring capability without these in the requirement set will build something it cannot deploy in half its estate.

The data platform case deserves particular attention because it is where the most consequential access now occurs and where the coverage gap is widest. A query reaching a regulated dataset typically arrives over a pooled connection established by an application, under a connection identity that represents the application rather than the person or agent whose request produced it. The platform’s audit log is complete and its subject is the connection. Unless the application propagates the originating subject into the query context (which most do not, because nothing obliges them to) every access to that dataset is permanently A1, regardless of how well governed the entitlement behind it was.

This is the clearest illustration of the report’s central point. The remedy is not an observability purchase; it is an application change, obliged by an architectural standard, enforced at design review. Observability’s role is to make the gap visible and to specify what would have to be carried. Where the category is treated as a monitoring function rather than a control, that specification is never written and the gap is rediscovered at every incident.

Coverage should therefore be scored as a matrix rather than a percentage: for each constituency and each material environment, the attribution ceiling actually achievable today and the specific mechanism that sets it. The output is a small number of engineering obligations, most of which belong to teams outside the identity function. In CAI’s assessment an observability program that cannot name those obligations has not finished its analysis, whatever its telemetry coverage.

Programmable Observability Controls

The target posture for this category is the same as for the other two: the control is an artifact, not a configuration. Detection logic, correlation joins, attribution rules, baseline definitions, retention schedules, and evidence schemas are authored as versioned code, tested against known cases before deployment, deployed through a pipeline, and monitored for drift between the authored state and the running state. Detection-as-code is the most mature part of this and the rest lags it considerably; attribution rules and evidence schemas are almost universally undocumented, existing only as the implicit behavior of whatever joined the data last.

Two cautions apply specifically here:

• A programmable observability control must not become an authorization control. A pipeline that computes a risk score and acts on it directly has authored policy that no governance process approved. The score is the observability output; what to do about it belongs to runtime, expressed in policy someone owns.
• Programmability without an owned data foundation accelerates the wrong thing. Versioned detection logic on an unreconciled identifier space produces rapid, testable, well-governed deployment of rules that join on the wrong key. In CAI’s assessment the sequencing is not negotiable: name an owner for the identity data foundation, reconcile the identifier space and the time base, and then invest in the programmable layer above it.

Observability Operability Bands

The category needs a way to describe how well an enterprise operates its observability controls, reusable across the three control-category Foundation Reports so that governance, runtime, and observability can be assessed on commensurable terms. The Observability 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 observability operability bands, O0 through O5, 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. A single enterprise figure conceals the pattern that matters, which is almost always a workforce estate several bands ahead of the machine estate beside it.

The bands describe operation, not ambition. An enterprise sits at the band whose entry condition it currently meets in production for the constituency being scored, not the band its tooling would permit if configured differently. This distinction does most of the work in practice: estates commonly hold O4-capable platforms and operate at O1, because the identifier space was never reconciled and the receiving side of shared signals was never bound to a policy.

Three transitions carry most of the difficulty:

• O1 to O2 is a data-engineering program, and is where most enterprises stall. Reconciling identifiers and time across sources produces no visible new capability and consumes a year, which makes it the hardest transition to fund and the one everything else depends on.
• O2 to O3 is a measurement change rather than a build. Scoring attribution and specifying evidence require analysis and agreement more than technology, and can move quickly once someone owns them.
• O3 to O4 is where the category stops being a reporting function. It is gated by whether governance and runtime will accept observability output as an input to their own decisions, an organizational question, not a technical one.

Scoring separately by constituency is not a refinement but a requirement. A single enterprise figure averages a well-instrumented workforce estate with a machine estate that frequently sits two or three bands lower, and produces a number that describes neither. The gap between the two scores is usually the most decision-relevant output of the whole exercise, because it locates the risk and it names the constituency the next investment should serve.

CAI View The bands measure an enterprise control system in operation and must never be read against a vendor capability score. A platform can be O5-capable in every datasheet dimension and deployed into an estate operating at O1, and the gap between the two is not a product deficiency. It is the reconciliation, ownership, and policy binding that no vendor can supply.

Table 8. The eight operability dimensions and one observable test for each

Figure 5. An observability operability profile: each cell is one identity constituency scored on one observability dimension, with the agent constituency shown at O1 throughout

Common Misconceptions

Six beliefs about this category are common, load-bearing, and wrong. Each is disproved somewhere above.

• Observability is the reporting layer of identity and access management. It is a control category with its own control point, its own failure modes, and its own outputs that the other two categories consume. Reporting is one of its products and the least consequential one.
• More telemetry produces better observability. Beyond the point where the principal sources are captured, additional volume produces additional cost and no additional establishment. What produces establishment is reconciliation, propagated context, and integrity, none of which is a volume property.
• Detection coverage measures observability maturity. It measures what a rule set can recognize, under conditions unlike production, and the published evidence shows the figure roughly halves when low-severity rules are excluded. It says nothing about what a firing detection establishes.
• Supporting a signal format means implementing the control. Parsing a security event token and writing it to a log is format support. The control is the action taken on receipt, and the distinction is the difference between a capability recorded as present and a capability that exists.
• Attribution is a forensics concern. Forensics is where the absence of attribution is discovered, not where it is created or fixed. By the time an examiner is reconstructing an event, every determinant of what can be established (credential practice, propagated context, identifier reconciliation, clock discipline, record integrity) was fixed months earlier. Attribution is an architecture concern that surfaces as a forensics problem.
• Observability is what you do after the other two categories are mature. The sequence runs the other way. Without observability an enterprise cannot establish whether its governance decisions were carried out or whether its runtime controls held, which means the maturity of the other two categories is asserted rather than demonstrated. An estate with strong governance, strong runtime, and no attribution is an estate whose controls are believed to work.

A worked example

A payments processor runs card-settlement infrastructure across a primary estate and a subsidiary acquired two years earlier and never consolidated. At 02:14 on a Sunday, a privileged operation is executed against a production settlement database: a table containing merchant payout instructions is altered. It is discovered eleven days later during a routine reconciliation. The enterprise has complete logs, retained for two years, from every system involved. Follow the reconstruction.

The database audit log records the operation, the affected rows, and the connecting principal: an application service account used by the settlement platform. The account is one the platform uses for all privileged maintenance. It resolves to no person. The record is complete and the action is A1.

The connection originated from a jump host in the subsidiary’s estate. The jump host records an interactive session, but the operating system audit log rolled at seven days and the retention policy for that host was never brought into line with the primary estate’s. What survives is a network flow record showing a source address.

The source address belongs to a virtual desktop pool. Assignment of desktops to users is recorded by the desktop platform, which stamps its records on ingestion into the central pipeline rather than on occurrence, and the pipeline was backlogged that night. Three users appear to have held that desktop within the relevant window, in an order the timestamps cannot be trusted to establish.

One of the three is an automation engineer whose account holds an entitlement granted for a migration project that closed fourteen months earlier. A certification the previous quarter flagged the entitlement; the reviewer approved its removal; the removal was never executed. Governance holds a decision. The estate holds the access.

The same engineer had registered an assistant agent six weeks earlier to perform reconciliation queries. The agent authenticates with its own credential and then assumes the settlement service account to reach the database, because that is the only principal the database recognizes. Its own credential appears in no record the database retains.

Eight days before the incident, a shared-signal event arrived from the subsidiary’s identity provider indicating a credential change for the engineer’s account. The primary estate’s platform received the event, validated it, and wrote it to the security information and event management system. No policy consumed it. The receiver was configured; the action was not licensed.

The reconstruction ends at A1. The enterprise can say that the settlement service account altered the table, that one of three people plausibly initiated it, possibly through an agent, and that an entitlement which should not have existed made it possible. It cannot say who, and it cannot say so eleven days later or eleven months later, because nothing that would have established it was ever captured. Every log required was present. Every control reported success. Nothing in the estate failed in a way that produced an alert, and the certification that should have closed the exposure recorded a correct decision that was never carried out.

Table 9. The worked example read as a diagnostic, mapping each failure to the control, the evidence it would produce, the accountable role, and the operability dimension it belongs to

Read as a table, the scenario becomes a diagnostic an architect can run against an estate. Every failure in it is a defect in attribution or in the loop, and not one of them is a detection gap. Running the same four columns against your own high-impact action classes turns the model into a worklist.

What each audience takes away

Table 10. What each audience takes away: a first move and the thing to design toward

Conclusion

The three control categories complete here. Governance decides what access should exist and on whose authority. Runtime makes that authority effective at the moment of access and maintains it for the life of the access. Observability establishes what actually happened and returns it to both, as evidence that changes governance decisions and as signal that changes live access. The loop is the architecture; each category is incomplete without the other two, and the third leg is the one that makes the first two assessable.

The loop closes only if the third leg can attribute. That is this report’s central claim and the reason it treats attribution rather than collection as the unit of control. An enterprise can hold every log, cover every technique, and buy every platform in the category, and still be unable to say who did a thing (and every downstream capability inherits that ceiling). Attribution is not an investigative outcome to be hoped for after an incident. It is a property of the event, set by decisions about credentials, delegation, identifiers, time, and record integrity taken long before anything goes wrong, and therefore measurable and engineerable in advance.

For now, four moves. None requires a purchase, and each converts a silent failure into a finding:

• Score the highest-impact action classes on the A-scale, and find what sits at A0 and A1.
• Check which timestamp the correlation joins on.
• Name an accountable owner for the identity data foundation.
• Take one received shared signal and bind it to an action.

For the horizon: the machine and agent constituencies make partial attribution the normal case rather than the exception, and the specification layer will not resolve it. The framework’s single-subject model cannot express the delegation relation, and the receiving side of the ecosystem is where the commercial incentives are weakest. Enterprises that intend to hold agents accountable will carry the delegation chain themselves, in transaction context they propagate and telemetry they specify. In CAI’s assessment the enterprises that build that capability in the next two years will be the only ones able to make a defensible statement about what their agents did.

Acronym Key and Glossary

Evidence

This report draws on standards and specifications from the recognized bodies, peer-reviewed research on detection efficacy, attribution, and log integrity, published regulatory and program direction, and enterprise and practitioner accounts of observability controls in operation. Vendor material was read only as evidence of what has been built and licensed, never as evidence of adoption or effectiveness. Third-party empirical claims that could not be traced to independent primary sources were excluded, including two widely repeated figures on detection coverage and one survey statistic on the prevalence of identity-related breaches. Market sizing was excluded entirely, since the available estimates for this category differ from one another by a factor sufficient to make any of them unusable and none bears on what an enterprise can establish. 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

• OpenID Shared Signals Framework 1.0, Continuous Access Evaluation Profile 1.0, and RISC Profile 1.0, published as OpenID Final Specifications on 29 August 2025 and not subject to further revision.
• OpenID CAEP Interoperability Profile 1.0, specifying the minimum feature set for a compliant implementation; final public review to 25 September 2026, membership vote to 10 October 2026.
• RFC 8417, Security Event Token; RFC 9493, Subject Identifiers for Security Event Tokens.
• RFC 9967, SCIM Profile for Security Event Tokens (May 2026), extending the token format to provisioning lifecycle change.
• NIST SP 800-53 Revision 5, the AU control family, carrying the current auditable-event requirements.
• NIST SP 800-92, Guide to Computer Security Log Management (2006). SP 800-92 Revision 1 has remained an initial public draft since October 2023.
• MITRE ATT&CK Enterprise matrix, identity provider and cloud platform techniques.
• Virkud et al., “How does Endpoint Detection use the MITRE ATT&CK Framework?”, USENIX Security Symposium 2024, on technique coverage as a security metric.
• Forensic literature on superuser anti-forensics and log-of-logs integrity, motivating the A4 level of the attribution confidence scale.
• Vendor product documentation for shared-signals transmitter and receiver capability, read as primary evidence of what is built and what is licensed.
• Practitioner implementation reporting distinguishing interoperability-event participation from shipping production capability.

Related Reading

• IAM-RD-01 for the Identity and Access Root Document
• IAM-F-GOV-01 for the Identity and Access Governance Controls Foundation Report.
• IAM-F-RTM-01 for the Identity and Access Runtime Controls Foundation Report.
• IAM-F-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.

Occurrence. The access, change, or decision that actually took place. It exists whether or not anything recorded it, and nothing downstream can recover what was not captured at the moment it happened.

Identity event. The occurrence treated as an object that can be reasoned about: what happened, when, to what, and to whom it is attributable. Distinct from the record that stores it, the format that conveys it, and the finding derived from it.

Record. What an emitting system wrote about an occurrence, carrying the context that system chose to attach. A record is evidence of an occurrence, not the occurrence itself, and its absence is not evidence that nothing happened.

Format. The envelope in which a record travels between systems: a security event token, a cloud audit schema, a vendor log line. Support for a format is not support for the capability that would act on it.

Finding. What an analysis concluded from one or more records: an anomaly, a posture exposure, an attribution. A finding carries a confidence; a record does not.

Point of emission. The place where an occurrence becomes a record with context attached. It is the emitting system rather than the log sink, and it is the only place where missing context can still be added.

Event time. The control time at which an occurrence is recorded and can be reasoned about. It overlaps runtime rather than following it: a signal computed at event time may be consumed by a runtime decision moments later.

Telemetry. The stream of records an enterprise collects. A quantity rather than a capability. Telemetry is what observability consumes, not what it produces.

Signal. An assertion emitted to another party that a state relevant to access has changed. Its value lies in what the receiving party does on receipt, not in whether the assertion was parsed.

Evidence. A defensible artifact demonstrating that a control operated, produced to a specification. Distinct from a report, which describes activity, and from a record, which stores it.

Identity data foundation. The identifier space, time base, and relationship model on which every capability in this category depends. Not a platform, and not owned by whoever bought the platform.

Identifier space. The set of identifiers by which subjects are named across systems, and the rules by which those identifiers resolve to one another. It fails through collision, through reuse after deprovisioning, and through the absence of any stable identifier for machine constituencies.

Time base. The discipline by which records can be ordered. Occurrence time is when the thing happened; ingestion time is when a pipeline received the record. Correlating on the second silently destroys causality.

Relationship model. The means by which the estate expresses that an agent acted for a person, that a service account belongs to an application, or that an entitlement grants a permission on a resource. Where there is no place to put these facts, they are not lost in transit; they are never recorded.

Attribution. The property of an action being traceable to an accountable identity, and the capability that establishes it. Attribution is what makes a record evidentially useful rather than merely descriptive.

Attribution confidence. The degree to which an event establishes the acting party, the authorizing party, and the link between them. A CAI term, and the unit of control for this category. Graded A0 to A4 in this report, and a property of a class of event rather than of an enterprise.

Acting party. The identity that performed the action.

Authorizing party. The identity on whose authority the action proceeded. In a human-operated access the two parties coincide; in an agent-mediated one they do not, and an event that carries only the acting party is attributable at A2 at best.

Transaction context. The set of facts about the originating subject, the acting party, and the authorization state that travels with a call chain. What is not propagated at a hop cannot be reconstructed at the destination.

Posture finding. A statement that an exposure exists, computed from the current state of identities, entitlements, credentials, and configuration. Pre-incident and individually remediable, and only as good as the inventory it was computed over.

Detection. A statement that an exposure is being or has been exploited. Post-incident, and useful to the degree that it establishes an actor, a scope, and an authority rather than an event alone.

Shared signals. The mechanism by which one party emits an assertion about a state change and another consumes it. A transmitter emits, a receiver consumes, and only a receiver bound to a policy acts.

Continuous evaluation. The re-evaluation of an open access as signals arrive. The signal is an event-time product; the decision it triggers belongs to runtime.

Capability family. One of the six groupings of observability control used in this report: event capture and the data foundation, attribution, posture management, detection and response, shared signals and continuous evaluation, and analytics with intelligence and evidence. A structural term for organizing the category, not an ontology class.

Observability operability band. One of six levels, O0 to O5, describing how well an enterprise operates its observability controls in production. Commensurable with the governance and runtime bands, scored by identity constituency, and never read against a vendor capability score.

The observability loop. The report’s central analytical construct: the establishment, from the record of what occurred, of what happened and to whom it is attributable, returned to governance as evidence that changes decisions and to runtime as signal that changes live access. The loop closes only where attribution holds.

Notes

1. Virkud et al., “How does Endpoint Detection use the MITRE ATT&CK Framework?”, USENIX Security Symposium, 2024. Analyzing the rule sets of three major products, the study found technique coverage of 48 to 55 percent, falling to 25 to 26 percent when low- and medium-risk rules are excluded, and concluded that many techniques are not realizable as detection rules at all. On the breach statistics: the 2026 Data Breach Investigations Report places credential abuse at 13 percent of initial access, behind vulnerability exploitation at 31 percent, while credential abuse appears in 39 percent of breaches counted across the full progression. The 2026 edition also added pretexting as a separately tracked initial access vector, reclassifying incidents previously counted as credential abuse; Verizon notes that without that change credential abuse would have been 16 percent rather than 13 percent.
2. OpenID Shared Signals Framework Specification 1.0, subject principal and subject member definitions. Each subject member must refer to exactly one subject principal. Event types may define additional subject members, and a Complex Subject may carry user, device, session and application members, but all members of a Complex Subject must represent attributes of the same Subject Principal and the Complex Subject as a whole must refer to exactly one. The core model therefore has no construct for the relation between an acting agent and a delegating human.
3. The Shared Signals Framework, the Continuous Access Evaluation Profile, and the RISC Profile were published as OpenID Final Specifications on 29 August 2025. RFC 9967 published the SCIM profile for security event tokens in May 2026. On implementation: the most complete commercial implementation offers the transmitter as a standard capability and the receiver as part of a licensed add-on; the largest enterprise identity provider publishes no supported external path in either direction; the leading open-source identity provider shipped an experimental transmitter in mid-2026 with no receiver.
4. The CAEP Interoperability Profile specifies the minimum feature set for a compliant implementation, covering the session-revoked, credential-change, and device-compliance-change event types. Public review runs 27 July to 25 September 2026, with the membership vote from 26 September to 10 October 2026.

Disclaimer

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