Continuous access evaluation for device posture changes

The session gap after sign-in

Many SSO deployments evaluate device trust when a user signs in and then rely on an application session or access token until it expires or is refreshed. During that interval, disk encryption can be suspended, an endpoint agent can stop reporting, device management can become stale, or platform attestation can fail without automatically changing the application's decision.

These conditions are device-posture changes. Some depend on hardware-backed evidence from a TPM or Secure Enclave, while others come from MDM, endpoint security, operating-system, or configuration signals. Treating all of them as hardware-state changes obscures where the evidence originates and how quickly it can be detected.

Continuous access evaluation narrows the gap by propagating a security-relevant state change to systems that can reassess access before the existing token would otherwise expire. It is near-real-time control, not a guarantee of instantaneous detection, delivery, or enforcement.

Why shorter token lifetimes are only a backstop

Reducing an access-token lifetime limits how long a resource may accept an unchanged bearer token, but it does not make evaluation continuous. The resource can continue accepting that token until expiry unless it also checks revocation, introspection, current policy state, or another live signal.

Short lifetimes can also increase token issuance and refresh activity and may reduce reliability when identity services are degraded. Keep a bounded token lifetime as defense in depth, but use event-driven evaluation or an equivalent live control when a posture change must affect an active session.

SSF and CAEP: the standards layer

The OpenID Shared Signals Framework 1.0 defines how cooperating systems establish event streams and exchange Security Event Tokens. A Security Event Token, defined by RFC 8417, is a signed JWT that carries a security event rather than an authentication assertion or API authorization grant.

The Continuous Access Evaluation Profile 1.0 defines event types for changes that may affect ongoing access. SSF and CAEP became OpenID Final Specifications in 2025, although vendor coverage and interoperability still vary.

CAEP is descriptive. A Transmitter reports a change to a Receiver; the standard does not require the Receiver to terminate a session. Local policy decides whether to deny the next request, revoke sessions, require reauthentication, reduce authorization, quarantine a device, notify an operator, or retain the event without disrupting access.

CAEP events relevant to active access

• Device compliance change. Conveys a change in a device's compliance status. The receiver must correlate the subject to the correct device, user, sessions, and resources before applying policy.
• Session revoked. Reports that the identified session has been revoked. Each enforcement point still needs a way to stop accepting the session.
• Credential change. Reports a material credential change that may require session review, reauthentication, or another response.
• Token claims change. Reports that claim values associated with previously issued tokens have changed.
• Assurance level change. Reports a change in authentication assurance that can cause step-up authentication or reduced access.

A defensible enforcement flow

• 1. Detect. MDM, endpoint security, platform attestation, or another posture source observes a material state change. Record signal freshness and distinguish noncompliant, unknown, stale, and error states.
• 2. Normalize and identify. Map the source evidence to a defined compliance transition and a stable subject identifier. Preserve the source, observation time, policy version, and reason.
• 3. Transmit. Send a signed SET through an authorized SSF stream using push or poll delivery. The event should carry enough subject context for the receiver to correlate it without exposing unnecessary personal data.
• 4. Validate and correlate. The receiver verifies the event and resolves the device, user, active sessions, and applicable resources. An unmatched or ambiguous event should not silently modify unrelated sessions.
• 5. Decide. Evaluate local policy using the event, resource sensitivity, current posture, session context, exceptions, and signal freshness. Document fail-open, fail-closed, grace-period, and recovery behavior.
• 6. Enforce. Propagate the decision to the API gateway, application, resource server, session service, or other enforcement point. Verify that all relevant sessions and channels respond as intended.
• 7. Explain and audit. Give the user an actionable reason and recovery path where appropriate. Retain the detection, event, decision, enforcement, exception, and restoration evidence.

Validate more than the JWT signature

• Trust only configured issuers and approved stream relationships; validate the signing algorithm and key against current trusted metadata.
• Validate the intended audience, supported event type, required claims, subject format, and any applicable time constraints.
• Use the SET identifier, such as jti, for replay protection and idempotent processing. Do not apply the same event twice.
• Handle signing-key rotation and metadata refresh without accepting an unknown key indefinitely or dropping every event during a planned rotation.
• Protect subject correlation from cross-tenant, cross-device, and cross-session confusion. Treat missing or ambiguous bindings as an explicit error state.

Design for delayed, duplicated, and out-of-order signals

Push and poll delivery can fail, retry, or arrive out of order. The receiver needs bounded retries, acknowledgements, deduplication, backlog monitoring, dead-letter handling, and an ordering policy based on trustworthy event and observation data.

A device can also become compliant again before an earlier noncompliance event arrives. Do not let a stale recovery event restore access over a newer blocking state, or let an old blocking event override a verified recovery without review. Define which source is authoritative, how long its evidence remains fresh, and what happens when transmitters disagree or go offline.

Choose an enforcement pattern that fits the session architecture

• Central session state. A shared session service or low-latency store can mark sessions blocked or constrained. This is useful when applications already consult centralized state.
• Revocation or policy cache. Gateways and resource servers can consume compact invalidation state, such as a subject security-state version, revoked-after timestamp, or targeted deny entry.
• Token introspection. A resource can ask an authorization server or policy service whether a token remains active, trading stateless validation for a live dependency that must be resilient.
• Direct invalidation. An event processor can push a session or policy update to known enforcement points, with acknowledgement and reconciliation for missed consumers.
• Layered backstop. Use bounded token and session lifetimes so a failed signal path does not leave access valid indefinitely. Test the actual maximum exposure window under degraded conditions.

What current product support proves—and does not prove

• Microsoft Entra. Microsoft documents production Continuous Access Evaluation for supported services, clients, critical user events, and location-policy changes. It is based on CAEP but does not provide universal CAEP event coverage. Microsoft describes enforcement as near real time, notes propagation can take up to 15 minutes in some cases, and documents additional coauthoring and policy-update limitations.
• Jamf Security Cloud. Jamf documents an SSF Transmitter that emits CAEP device-compliance-change events when Apple device management status changes. This demonstrates standards-based posture signaling; the receiving product still owns correlation, policy, and enforcement.
• Keycloak. As of July 2026, Keycloak documents experimental, off-by-default SSF Transmitter support and warns against production use. Its documented scope is transmitting SETs to downstream receivers, not acting as a general receiver for device-posture events.

Questions to test with vendors

• Which device-posture changes can generate a signal, how are they detected, and what is the measured end-to-end latency under normal and degraded conditions?
• Is the integration SSF and CAEP compatible, proprietary, or both? Which final specification versions, delivery methods, subject formats, and events are supported?
• What action does each event trigger for each resource class: deny, session revocation, reauthentication, reduced access, quarantine, notification, or observation only?
• How are events authenticated, deduplicated, ordered, retried, monitored, audited, and reconciled after an outage?
• How are device, user, tenant, and session identifiers correlated without terminating the wrong session or leaking cross-tenant data?
• What happens when posture is stale, missing, conflicting, or restored, and which actor may approve an exception or recovery?
• Which applications, APIs, background channels, mobile clients, and collaborative sessions actually honor the decision before token expiry?

How this maps to a Gideon evaluation

Evaluate Gideon Identity and Endpoint Management as one signal-to-enforcement path: confirm which endpoint conditions are observed, how freshness and subject correlation are represented, which access decisions consume them, and how enforcement and recovery are verified. Require measured evidence for detection, delivery, decision, and enforcement latency rather than relying on an unsupported universal real-time claim.

Related reading

• Separate credential, managed-device, and session controls with Device-bound authentication vs conventional MFA.
• Review posture freshness and lifecycle enforcement in Zero-touch endpoint management for security teams.
• Explore Gideon Identity for product capabilities and evaluation paths.

Primary references

• The OpenID Foundation defines streams, transmitters, receivers, and delivery in the OpenID Shared Signals Framework 1.0 Final Specification.
• The OpenID Foundation defines continuous-access event types in the OpenID Continuous Access Evaluation Profile 1.0 Final Specification.
• The IETF defines the Security Event Token format in RFC 8417.
• Microsoft documents supported events, clients, timing, and limitations in Continuous access evaluation in Microsoft Entra.
• Jamf documents its transmitter and device-compliance event flow in Shared Signals Framework and Continuous Access Evaluation Protocol.
• Keycloak documents the scope and production warning for its experimental SSF support.

How to use this resource

Map one high-impact device-posture change from detection through restoration. Measure each handoff, test duplicate and out-of-order delivery, verify both blocking and recovery across representative applications, and retain the evidence as an acceptance test for continuous access evaluation.