The Problem with Point-in-Time Access Decisions
Traditional authorization systems evaluate access at a single moment: the initial authentication event. Once a user obtains a session token, that token remains valid for its entire lifetime regardless of what changes occur afterward. The user’s device could become compromised, their account could be flagged by a threat intelligence feed, their role could be revoked in the HR system, or their session could be hijacked by an attacker. In all these scenarios, the original access grant persists until the token expires, creating a window of vulnerability that can extend for hours or even days depending on token lifetime configurations.
The Continuous Access Evaluation Protocol (CAEP), developed under the Shared Signals and Events (SSE) framework by the OpenID Foundation, directly addresses this gap. CAEP enables real-time communication of security events between cooperating systems, allowing resource providers to revoke or modify access immediately when risk conditions change. For Zero Trust architectures, CAEP transforms the “never trust, always verify” principle from a periodic check into a genuinely continuous evaluation.
CAEP Architecture and Event Model
CAEP operates within the broader Shared Signals and Events (SSE) framework, which defines how security event transmitters and receivers communicate using Security Event Tokens (SETs). SETs are JWTs with a standardized payload structure that describes the security event, the affected subject, and the event metadata.
Core Event Types
CAEP defines several critical event types that Zero Trust policy engines must process.
- Token Revocation events signal that a specific access or refresh token should no longer be honored. When an identity provider detects credential compromise, it transmits a token revocation event to all registered resource providers, which immediately invalidate sessions associated with the revoked token.
- Session Revoked events indicate that an entire user session should be terminated. This is broader than token revocation: it applies to all tokens and grants associated with the session, including tokens that may have been issued to downstream services through token exchange flows.
- Credential Change events notify resource providers that a user has changed their password, rotated their security keys, or updated their MFA enrollment. Resource providers can require re-authentication to verify the user possesses the new credentials.
- Device Compliance Change events communicate that a device’s security posture has changed. When an MDM system detects that a device has become non-compliant (missing patches, disabled encryption, removed EDR agent), it transmits a compliance change event that triggers access restriction for all sessions originating from that device.
- Assurance Level Change events indicate that the confidence in the user’s identity has changed. This can occur when a risk engine detects behavioral anomalies that reduce assurance, or when the user completes additional verification that increases assurance.
Transmission Mechanisms
CAEP events are transmitted through SSE streams using either push or poll delivery methods. Push delivery uses HTTP POST to transmit events to registered receiver endpoints in near-real-time. Poll delivery allows receivers to periodically retrieve accumulated events from a transmitter endpoint. For Zero Trust architectures where latency matters, push delivery is strongly preferred, as poll-based delivery introduces delay proportional to the polling interval.
The SSE framework also defines stream management APIs that allow receivers to discover available event types, configure delivery preferences, and verify stream health. Stream configuration includes specifying the subject formats (email, OIDC sub, SCIM ID) that the receiver can process, enabling the transmitter to filter events appropriately.
Integration with Zero Trust Policy Engines
CAEP events feed into the Zero Trust policy decision point (PDP) as additional input signals that can trigger immediate policy re-evaluation. The integration architecture typically involves a CAEP receiver service that processes incoming events and updates the policy engine’s context store.
When a CAEP event arrives, the receiver performs several actions. First, it validates the SET signature using the transmitter’s published JSON Web Key Set (JWKS), ensuring the event is authentic. Second, it maps the event subject to internal session and user identifiers. Third, it updates the relevant context attributes in the policy engine’s session store. Finally, it triggers policy re-evaluation for all active sessions associated with the affected subject.
The policy engine evaluates the updated context against the access policies for each affected session. Depending on the event type and the resource’s sensitivity classification, the policy engine may terminate the session immediately, downgrade the session’s access privileges, require step-up authentication before continuing, or flag the session for security team review while allowing limited access to continue.
Real-World Implementation Scenario
Consider a concrete enterprise deployment where an organization uses Azure AD as its identity provider, Intune for device management, and a custom Zero Trust gateway that protects internal applications. All three systems participate in a CAEP event mesh.
An engineer authenticates at 9 AM from a compliant corporate laptop and receives access to the source code repository, CI/CD pipeline, and production monitoring dashboard. At 10:30 AM, the Intune MDM agent detects that the engineer has disabled the host-based firewall on their laptop. Intune transmits a Device Compliance Change event over the CAEP stream to all registered receivers including the Zero Trust gateway.
The Zero Trust gateway’s CAEP receiver processes the event within 200 milliseconds. The policy engine re-evaluates the engineer’s active sessions and determines that the non-compliant device status requires elevated controls for production resources. The CI/CD pipeline session is downgraded to read-only (the engineer can view build logs but cannot trigger deployments). The production monitoring dashboard session continues unchanged because it is classified as low-sensitivity read-only access. The source code repository session continues but is flagged for audit logging at verbose detail levels.
The engineer receives a notification explaining the access restriction and providing instructions to re-enable the firewall. Once the firewall is restored and Intune confirms compliance, a new Device Compliance Change event restores the compliant status, and the Zero Trust gateway automatically re-grants full access privileges. The entire cycle, from compliance violation to access restriction to remediation to access restoration, occurs without any manual intervention from the security team.
Scaling CAEP in Large Environments
Enterprise environments with tens of thousands of users and hundreds of resource providers generate substantial CAEP event volumes. Scaling the event distribution infrastructure requires careful architectural decisions.
- Event fan-out from a single transmitter to many receivers benefits from message broker infrastructure such as Apache Kafka or cloud-native equivalents. The transmitter publishes events to a topic, and each receiver consumes from its own consumer group, decoupling transmitter throughput from receiver processing speed.
- Event filtering at the broker layer ensures that receivers only process events relevant to their active sessions. A resource provider with 1,000 active sessions does not need to process events for the 50,000 users who are not currently accessing its resources. Subject-based routing directs events only to receivers with matching active sessions.
- Event deduplication handles the case where multiple transmitters emit overlapping events for the same incident. For example, both the IdP and the SIEM might detect the same credential compromise and emit events. Receivers implement idempotent event processing using the SET’s unique jti (JWT ID) claim to ensure duplicate events do not trigger redundant policy actions.
- High availability requires that CAEP receiver services are deployed with redundancy across availability zones. Event processing must be exactly-once to prevent missed events (which could allow compromised sessions to persist) or duplicate processing (which could cause unnecessary user disruption).
Adoption Strategy and Ecosystem Maturity
CAEP adoption is accelerating as major identity and security vendors implement the specification. Microsoft, Google, Apple, Cisco, and Okta have contributed to the SSE framework development and are implementing CAEP support in their products. For organizations beginning CAEP adoption, the recommended strategy starts with the highest-impact integration: connecting the organization’s primary identity provider to its most critical resource providers.
The initial deployment should focus on session revocation events, which provide immediate security value by eliminating the stale-session vulnerability window. Once session revocation is operational, the deployment extends to device compliance events, which typically generate higher event volumes but deliver significant risk reduction by ensuring that non-compliant devices cannot maintain access to sensitive resources.
Organizations should instrument CAEP event processing with latency metrics to ensure that security events result in access changes within their target SLA. For most Zero Trust deployments, the target is sub-second from event transmission to policy enforcement. Monitoring should track end-to-end latency from the originating security event (such as a device compliance check) through CAEP transmission to policy enforcement, identifying bottlenecks that could allow compromised sessions to persist beyond the acceptable risk window.