Beyond CAEP: Building Continuous Access Evaluation That Scales
CAEP defines the protocol, but building continuous access evaluation that works at enterprise scale requires more. Event correlation, decision caching, and graceful degradation. Lessons from processing 10 billion access decisions.
In January, we published an introduction to CAEP and the Shared Signals Framework. The response was overwhelming. But the most common follow-up question was: “How do you actually build this at scale?”
CAEP (Continuous Access Evaluation Protocol) provides the protocol layer. How security events are transmitted between systems to trigger session re-evaluation. The Shared Signals Framework standardises the event format. Together, they are the foundation.
But the protocol alone does not solve the engineering challenges of evaluating millions of access decisions per second, correlating signals from dozens of sources, and maintaining sub-50 ms latency at 99.99% availability. This article covers what we have learned building TigerIdentity’s evaluation engine to handle 10 billion+ access decisions.
10B+
Access decisions processed
Across all deployments
<50 ms
p95 evaluation latency
Including policy evaluation
99.99%
Availability target
With graceful degradation
500K+
Events/second peak
Signal processing throughput
What CAEP doesn’t cover
CAEP is a protocol, not an architecture. It defines how to transmit events between systems but leaves the hard engineering problems to the implementer. Here are the four challenges we had to solve beyond the spec:
Event correlation across sources
A single identity threat involves signals from multiple sources. Your IdP reports a suspicious login, your EDR flags malware, your SIEM detects data exfiltration. Each signal alone might be low-confidence. Together, they're a confirmed incident.
Note: Correlating events across time windows, matching identities across systems with different naming conventions, and scoring multi-source signals without false positives.
Decision caching and consistency
What happens when the policy engine is unreachable for 500 ms? Fail-open (security risk) or fail-closed (availability risk)? Caching helps, but cached decisions go stale. Especially during active threats.
Note: Cache invalidation when policies or context change. Tiered caching strategies based on resource sensitivity. Consistency guarantees across distributed decision points.
Graceful degradation
Not all resources need the same rigor. A request to view a public wiki page can use a cached decision. A request to delete production data must be evaluated in real time, every time.
Note: Defining degradation tiers, implementing circuit breakers that activate per-resource-sensitivity, and ensuring degraded mode does not become a security bypass.
Multi-tenant isolation
One tenant’s event storm should not degrade another tenant’s evaluation latency. A security incident at Company A. Generating thousands of events per second. Must not affect Company B’s access decisions.
Note: Per-tenant rate limiting, resource isolation, and priority queuing without over-provisioning.
Architecture for scale
TigerIdentity’s evaluation architecture is designed around four key layers, each optimised for its specific role in the decision pipeline:
Event ingestion layer
NATS JetStream provides the messaging backbone with at-least-once delivery guarantees. Events from IdPs, EDR agents, SIEMs, and HR systems flow into topic-based streams with per-tenant partitioning.
Note: At-least-once over exactly-once. Duplicate events are idempotent; missing an event means missing a threat. We chose reliability over deduplication complexity.
Decision engine
Policies compile from YAML DSL to executable rules at deploy time. Not interpreted at evaluation time. The engine runs in memory with pre-indexed policy lookups. Cache hits resolve in under 5 ms.
Note: Compile policies to Go structs, not evaluate a rule engine at runtime. 10× faster and eliminates an entire class of parsing bugs.
Signal correlation
Sliding-window analysis correlates signals from multiple sources into composite risk scores. A suspicious login alone might score 30. Add a concurrent EDR alert and it scores 85. Multi-source fusion eliminates false positives.
Note: 5-minute sliding windows with exponential decay. Recent signals weighted higher than older ones. Window size configurable per tenant.
Session management
Distributed session store backed by Redis with instant revocation propagation. When a session is revoked, CAEP events publish to all connected relying parties within 2 seconds. No polling. Push-based revocation.
Note: Redis Pub/Sub for revocation fanout, with persistent storage for audit. Revocation is fire-and-forget from the decision engine’s perspective.
Patterns that work
Tiered evaluation
Pre-computed access grants
Circuit breakers
Eventual consistency for analytics
Event processing pipeline
# TigerIdentity evaluation engine configuration
evaluation:
engine:
compiled_policies: true
cache:
enabled: true
ttl_by_sensitivity:
public: 300s # 5 minutes
internal: 120s # 2 minutes
confidential: 0s # No caching. Always real-time
restricted: 0s # No caching. Always real-time
max_entries: 100000
signal_correlation:
window: 300s # 5-minute sliding window
decay: exponential
min_confidence: 0.7
sources:
- idp # Identity provider events
- edr # Endpoint detection
- siem # Security events
- hr_system # Employment status changes
- device_mgmt # Device posture signals
degradation:
circuit_breaker:
failure_threshold: 5
recovery_timeout: 30s
fallback_by_tier:
tier_1: use_cached_decision
tier_2: use_cached_with_alert
tier_3: fail_closed
messaging:
provider: nats_jetstream
delivery: at_least_once
partitioning: per_tenant
retention: 7d
session_revocation:
method: caep_push
propagation_target: 2s
storage: redis_cluster
audit_backend: clickhouseBuild on proven scale.
TigerIdentity's evaluation engine has processed 10 billion+ access decisions at sub-50 ms latency. Deploy continuous access evaluation that scales with your enterprise.