Mismatched token validation and revocation policies across multiple CDN endpoints generate security gaps and subscriber lockouts.
Running validation logic inside globally distributed WebAssembly (Wasm) functions provides a single, high-performance source of truth closer to users.
Moving authorization rules to Akamai Functions integrates real-time bot management, AI-scoring, and state management in a single low-latency pass.
Most major streaming and media platforms run multi-CDN architectures. Multi-CDN offers both resilience and cost savings, and is the standard baseline architecture for global delivery.
But it also makes entitlement enforcement harder. Every time a viewer hits “Play,” the platform has to answer a simple question: Is this viewer allowed to access this stream, right now, through this CDN path? That decision is often enforced through access tokens, signed URLs, cookies, or other entitlement signals.
These are not AI tokens. They are authorization tokens that determine whether a viewer can watch, for how long, from where, and under what conditions.
For live content, those decisions need to be made accurately, consistently, and fast, often in less than 100 milliseconds. And in a multi-CDN environment, the decisions need to work the same way no matter which CDN serves the request. However, achieving this consistency presents significant operational challenges.
And the stakes are climbing. The global anti-piracy market is projected to grow from approximately US$210 million in 2024 to more than US$500 million by 2033, driven by AI-powered detection, increasing credential abuse, and the expansion of live and on-demand content. The losses are large: Piracy is on track to cost U.S. streaming services US$113 billion by 2027.
In the first blog post in this ongoing series, we argued that modern application logic belongs at the front door: the edge of the network that every request already crosses. Streaming entitlements are a textbook case. The cost of token logic that drifts between CDNs, revokes slowly, or enforces inconsistently across regions is a serious issue.
Let’s look at this consistency problem up close, then walk through three examples of how consistency is easier when token validation, revocation, and antipiracy enforcement move to the edge — all orchestrated by Akamai Functions.
In a multi-CDN setup, each CDN typically has its own key-value (KV) API, its own propagation latency, and its own constraints on what edge logic can run — and each CDN syncs with a central origin on its own schedule. Token revocations tend to propagate at different speeds, policy versions drift between regions, and anti-piracy enforcement that works on one CDN can quietly fail on another.
As a result, teams start experiencing problems with consistency. Piracy leaks through during the propagation window. Paying subscribers are locked out when policies fall out of sync. The same logged-in viewer can get different answers depending on whose POP server terminated the connection.
Overall, teams are challenged to ensure that every CDN is consistently in agreement.
Rather than trying to get every CDN's local engine to agree, a better design is to move these centralized decisions (and consistency challenge) to the front door — where token validation, revocation state, bot screening, and analytics can all run together, all be evaluated at the edge on every path, and orchestrated by Akamai Functions.
Akamai Functions is an edge native serverless platform that runs globally across Akamai Cloud. The platform executes Wasm-compiled code written in languages like Rust, Go, JavaScript, and Python, while integrating directly with Akamai's CDN, security, AI, and storage services.
Akamai Functions glues the needed services together. And because Akamai runs one of the world's most distributed edge networks, there's almost always a front door closer to where a request lands, creating low-latency and reliable communication between components.
Let's review three specific examples of how you can use Akamai Functions to effectively run entitlements across multiple CDNs:
A championship final goes live. Within minutes, credentials are circulating in chat apps and forums. Your security team flags a wave of leaked tokens, and the revocation list needs to propagate globally before unauthorized viewers can access the live stream.
This is a familiar problem for platforms delivering premium live or event content. Revocation is more than just updating a database; the update has to reach every CDN edge that might serve the stream, and do it fast enough to matter.
The centralized architecture
In a centralized setup, the token service lives at the origin. CDNs poll for revocation updates on intervals that are often measured in minutes. Multi-CDN drift is common: CDN A may have already revoked a token while CDN B is still serving the manifest to whoever holds it. This propagation gap is where piracy happens.
The Akamai Functions solution
With Akamai Functions, the revocation logic moves to the edge. Akamai Functions becomes the glue between several coordinating Akamai services. The function reads the revocation list from the Akamai Functions KV store and validates the token (Common Access Token [CAT], JSON Web Token [JWT], multi-step claims). Akamai Bot Manager screens for automated abuse at the CDN layer and routes suspect requests to the function before they reach the playback path. The decision is written to TrafficPeak for downstream analytics.
Revocation writes propagate to the KV store across Akamai Cloud regions in near real time. To the extent that there's centralized decision-making about which tokens need revocation, those updates can be pushed out on demand into the KV store, or even into a function's memory if the list is small enough (fewer than a million entries). This avoids polling and gives the flexibility to update that information as needed.
As a result, Akamai Functions describes new tokens being issued or revoked globally in seconds, rather than minutes. Akamai Functions replaces the central origin with a distributed source of truth that sits much closer to the user: Instead of every CDN path reaching back to one centralized service, each consults that same function-backed state, so the answer is identical no matter which CDN served the viewer (Figure 1).
Because our footprint sits adjacent to virtually every other CDN's front door, and the hop from that front door to the function stays inside our own network, the platform absorbs the revocation check without a trip to the origin and without the latency penalty you'd normally pay for running logic at every edge.
There's a small cost to doing the work at each front door, but it's no different from what multi-CDN already demands today. And it’s arguably better, as you can offload the cross-CDN harmonization you’d otherwise be doing yourself.
A global streaming platform standardizes on CAT as the credential format that spans catalog, playback, billing, and downstream entitlement services. The potential benefits are huge: one token format, validated everywhere.
However, success depends on every validation point agreeing on what the token means.
The centralized architecture
In a centralized solution, each CDN runs its own CAT validator, often implemented separately with separate caches of the policy graph. Several engineering teams are needed to maintain functionally identical validators. Drift between policy versions causes false denials on one CDN (paying subscribers are turned away) and false approvals on another (revoked tokens are still working).
The more difficult the validation gets — with multistep claims, signature verification, and downstream identity callouts — the worse the drift.
The Akamai Functions solution
With Akamai Functions, the validator runs once, as a single Wasm function on Akamai's network, not re-implemented separately on each CDN. It can be written in the language your team already uses — e.g., Go, JavaScript, Python, Rust, etc. — with Rust especially well suited to validation work that has to be both secure and fast on every request. Heavier validation logic (stateful checks, multistep claims, signature verification, and downstream calls to identity services) runs comfortably within the function.
And because the function executes in Akamai Cloud regions, just behind our global front door of almost 4,350+ points of presence across 130+ countries, it minimizes latency for viewers almost anywhere they watch. The validator becomes a single source of truth: one codebase, one policy version, deployed globally, with the KV store holding the state used by every CDN (Figure 2).
Piracy increasingly runs on stolen and shared credentials, and that abuse is climbing. Credential stuffing now makes up roughly one in five login attempts overall, rising to 25% at large enterprises. Streaming platforms constantly see signs of compromised credentials, such as geo-impossible logins, sudden surges of concurrent sessions per account, and device fingerprints that don't match historical behavior.
Anti-piracy teams need to act on those signals in near real time, regardless of which CDN handled the session.
The centralized architecture
In centralized setups, the anti-piracy analytics live in a central pipeline. Signals are processed centrally, decisions go back to origin, and then they propagate out to CDN edges.
The lag between detection and enforcement is when a leaked credential is most valuable to the abuser, and when watermarks, blackouts, or session terminations need to be applied.
The Akamai Functions solution
With Akamai Functions, anti-piracy logic runs as a Wasm function right alongside token validation.
The function acts as the glue, coordinating the KV store, security, AI scoring, and analytics in a single pass, all in just milliseconds (Figure 3).
Multi-CDN is a great solution for reliability but it creates problems around enforcement. Decisions on token validation, revocation, concurrency, geography, and anti-piracy need to be consistent on every CDN path, every time. And it all needs to happen fast.
Getting the architecture wrong causes issues on both sides: Underenforcement results in piracy, overenforcement results in paying subscribers being turned away. The solution is moving to a single decision layer at the front door, where token logic, security, AI, and analytics all run together with Akamai Functions as the glue.
Ready to see what your front door could be doing for entitlements? View the Functions Quick Start Guide in TechDocs.
© 2026 Akamai Technologies
