Part 1 explained the problem: sessions stay valid for hours even when security context changes. CAEP solves this by creating real-time communication between systems that detect changes and applications that need to respond.

But how does that actually work? Let’s walk through it step-by-step using the contractor termination scenario from Part 1.

How Events Actually Flow

CAEP operates through a simple but powerful sequence. Let’s walk through it with the contractor termination scenario.

Step 1: Detection

Friday 5 PM: HR marks the contractor as terminated. The employment status changes in your systems.

Step 2: Event Creation

Your identity provider receives the termination notice. It creates a standardized message called a Security Event Token (SET). This message contains:

  • Who it affects: The terminated contractor
  • What happened: Session revocation required
  • When it happened: 5:00 PM Friday
  • Why it matters: This person should no longer have any access
  • Proof: Signed cryptographically so applications know it’s legitimate

Step 3: Event Publishing

Your identity provider publishes this event to a stream. Think of streams like broadcast channels. Applications that care about termination events subscribe to this stream.

Step 4: Delivery

The event travels to every subscribed application. This happens in seconds, not hours. Salesforce gets it. GitHub gets it. Your financial dashboard gets it. Your data warehouse gets it. Every application with an active session for the contractor receives the event simultaneously.

Step 5: Application Processing

Each application receives the event and asks itself: “Do I have an active session for this user? If yes, what should I do?” Different applications might decide different things based on their policies. But they all decide fast. Within seconds.

Step 6: Action and Logging

Applications take action. Salesforce terminates the session. GitHub revokes the token. Financial dashboard ends access. Data warehouse removes session. Each action is logged with a timestamp, creating an audit trail that proves you responded immediately.

The entire sequence from termination (5:00 PM) to enforcement (5:03 PM) takes minutes, not hours.

This is mechanically different from everything that came before. Your applications are no longer passive consumers of stale identity decisions. They’re active participants in continuous access control.

Five Event Types That Matter

CAEP defines specific event types. Each represents a different security condition that should trigger access decisions. Understanding these events is understanding CAEP.

Session Revoked

What it means: Immediately terminate all sessions for this user. No exceptions. No re-authentication required.

When it happens:

  • User terminated from employment
  • Account takeover detected
  • Critical security policy violated
  • Administrative action required immediate access removal

What apps do: Revoke sessions instantly. Log the action. Optionally notify the user.

In practice: HR marks someone as terminated. Identity provider publishes session-revoked. By the time the terminated employee reaches their desk, they’re locked out everywhere.

Credential Change

What it means: Authentication credentials were modified. The change could be routine or serious depending on the reason.

When it happens:

  • Password reset (user-initiated, routine)
  • Password reset (forced due to compromise, urgent)
  • MFA enrollment change
  • Authenticator revoked or rotated
  • Certificate expiration or renewal

What apps do: Evaluate the reason. If routine, allow sessions to continue. If compromise-related, terminate sessions and force re-authentication.

In practice: Friday 5 PM termination triggers session-revoked event. Apps receive it with reason: “employment terminated.” Apps terminate all contractor sessions immediately. Contractor has no access when they return to their desk.

Token Claims Change

What it means: User attributes or permissions changed. The user is the same, but who they are (role, group, department, location) is different.

When it happens:

  • Role change (promotion, demotion, lateral move)
  • Group membership changes
  • Department or organizational unit changes
  • License or entitlement changes
  • Location or network context changes

What apps do: Re-evaluate permissions for this user’s current session. Adjust access if claims affect authorization. May require step-up authentication for sensitive operations if claims downgrade.

In practice: User gets promoted from engineer to manager. Token claims change includes new role. Applications receive the event. Financial system recognizes manager role has access to budget approvals. GitHub recognizes manager role has admin capabilities. Access adjusts automatically without re-authentication.

Device Compliance Change

What it means: The device security posture changed. Device went from compliant to non-compliant, or vice versa.

When it happens:

  • Missing security patch detected
  • Malware or threat detected
  • Disk encryption disabled
  • Device management agent offline
  • Endpoint protection failed
  • Device remediated and now compliant again

What apps do: Check device policy. If device required, revoke or restrict access. If device not required, log and continue monitoring.

In practice: User’s laptop gets flagged for missing patches. Device compliance event fires. Finance app with strict device policy: revokes session. GitHub with moderate policy: downgrades to read-only. Internal wiki with no device policy: logs but allows access. Same event, different responses based on application risk tolerance.

Assurance Level Change

What it means: Authentication strength or session confidence changed. Session assurance increased (user completed MFA) or decreased (behavioral anomaly detected).

When it happens:

  • Step-up authentication completed (assurance increases)
  • Session age exceeds threshold (assurance degrades)
  • Risk score changes based on behavior (increase or decrease)
  • Authentication method changed mid-session
  • Anomaly detection flags unusual access pattern

What apps do: Compare current assurance with required level for requested operation. Allow, restrict, or require step-up based on policy.

In practice: User logs in with password (low assurance). Later tries to access sensitive financial data. Application requires higher assurance. Application triggers MFA challenge. User completes MFA. Assurance level increases. Application receives assurance-level-change event. User gains access to financial data. All without full re-authentication.

Real Scenario: Contractor Termination End-to-End

Let’s walk through the contractor termination scenario in detail. Watch how these actually play out.

5:00 PM Friday: HR marks contractor as terminated. Status changes in your identity system.

5:01 PM: Identity provider detects the termination. IdP creates a session-revoked event with reason: “employment terminated.”

5:02 PM: IdP publishes the event to all subscribed applications. Salesforce, GitHub, financial dashboard, data warehouse, internal tools all receive the event simultaneously.

5:02 PM (Salesforce receives event): Salesforce checks its policy. Termination requires immediate session revocation. Salesforce finds the contractor’s active session (logged in since 1 PM). Salesforce revokes the session. If the contractor tries to access Salesforce, they get an error: “You no longer have access.”

5:02 PM (GitHub receives event): GitHub checks its policy. Termination requires immediate revocation of all access. GitHub finds the contractor’s active sessions (they have code in flight, pending commits). All sessions are revoked. Any pending API calls fail with “invalid credentials.”

5:02 PM (Financial dashboard receives event): Financial dashboard checks its policy. Termination requires immediate access removal. Dashboard revokes session. Future login attempts are denied.

5:02 PM (Data warehouse receives event): Data warehouse checks its policy. Termination with audit logging required. Data warehouse revokes session and logs the event with user, timestamp, and revocation reason for compliance audit.

5:03 PM: Your security team receives alerts. All applications have reported session revocation due to termination. Audit logs show coordinated enforcement across entire environment.

Timeline with CAEP:

  • Termination: 5:00 PM Friday
  • Event published: 5:01 PM
  • All applications revoked: 5:02 PM
  • Complete: 5:03 PM

Manual process (without CAEP):

  • Termination: 5:00 PM Friday
  • Security team manually revokes in Active Directory: 5:15 PM
  • Security team revokes in Salesforce: 5:30 PM
  • Security team remembers to revoke in GitHub: 5:45 PM
  • Finance app manually revoked: 6:00 PM
  • Data warehouse: contractor still has access (6 hours until natural session expiration)
  • Complete: 11:00 PM (or longer)

The difference is hours. During those hours, the terminated contractor could have accessed anything. Downloaded code, customer data, financial records. Not because they’re malicious, but because the gap existed.

Why Different Applications Respond Differently

One event. Five different applications. Five potentially different responses. This isn’t a bug. It’s the core feature.

In the contractor termination scenario:

Salesforce with financial data enforces strictly: termination means immediate session revocation, no exceptions.

GitHub with code access enforces tightly: revoke all sessions immediately. Pending commits are abandoned. Access is gone.

Internal wiki with public documentation enforces loosely: log the event, continue allowing read-only access briefly (giving the contractor time to wrap up), then full revocation.

This risk-based, application-aware response is impossible without CAEP. With old-style federation, you have two options:

  1. Uniform response: Revoke everyone everywhere. Simple but sometimes overkill.
  2. Per-application response: Manually revoke in each system. Complex, error-prone, slow.

CAEP enables a third option: policy-based application response. Each application defines its risk tolerance. The same termination event triggers appropriate responses across different applications automatically.

Your security posture becomes granular, proportional, and automated.

The Audit Trail Your Compliance Team Loves

Here’s something often overlooked: CAEP creates perfect audit trails.

When you terminate someone, you have to prove you responded. Not eventually. Immediately.

Old-style audits show: “Termination processed at 5:00 PM Friday. Active Directory revoked at 5:15 PM. Salesforce revoked manually at 5:30 PM. GitHub revoked at 5:45 PM. Data warehouse contractor still has access (natural expiration at 11 PM).”

CAEP audits show: “Termination event published at 5:01 PM Friday. Active Directory revoked at 5:01:15 PM. Salesforce revoked session at 5:02:12 PM. GitHub revoked at 5:02:18 PM. Financial dashboard revoked at 5:02:22 PM. Data warehouse revoked at 5:02:31 PM.”

Seconds, not hours. Coordinated. Provable. Compliant.

Regulators increasingly want to see this. Auditors specifically ask: “How quickly do you revoke access after termination?” CAEP lets you answer: “Within seconds, automatically, across all systems, with full audit trail.”

What This Enables Going Forward

Understanding these event flows and responses opens up possibilities.

You’re not just managing sessions anymore. You’re managing continuous access. The same mechanics apply to:

  • Transaction-level decisions: Before approving a large financial transaction, check current assurance level.
  • Data-centric access: Before serving sensitive data, evaluate current device compliance and user location.
  • Policy-driven responses: Different applications, different data sensitivity levels, different policies, all responding to the same events intelligently.

This is the foundation for true Zero Trust. Not authentication at login and trust forever. But authentication at login, verification continuously, and enforcement at the speed of threat detection.

What’s Next

You now understand how CAEP events flow through systems. You understand five event types and what they mean. You understand why different applications respond differently to the same event.

Part 3 covers implementation. How do you actually wire this up? What patterns work at scale? What policies should you define? How do you avoid disrupting your environment?

Part 4 ties everything together: why CAEP is foundational for Zero Trust, and why AI agents make continuous access evaluation critical for the future.

Series Navigation

CAEP Explained Series: