Many discussions about DRM complexity focus on the player side: device fragmentation, codec support, CDM quirks across platforms. That's fair. The player is where things visibly break.
But every pain point on the player side has a counterpart on the license server side. Security level enforcement, multi-key encryption strategy, token lifecycle, session management - these aren't just player concerns. They're architectural decisions that span the entire chain from entitlement service to license server to CDM. And when the server side isn't designed with the same rigor as the player side, the edge cases multiply.
This article walks through the DRM challenges that teams consistently underestimate, from the perspective of what the license service needs to get right so the player can get it right.
Security Levels Are a License Server Concern, Not Just a Device Property
Widevine's security levels (L1, L2, L3) determine whether decryption happens in hardware or software. L1 uses a hardware-backed Trusted Execution Environment and is required by most studios for HD and UHD content. L3 is software-only and typically not authorized to be used for HD content.
The license server has its role to play. A properly configured DRM backend doesn't just hand out keys; it enforces which keys a device is entitled to receive based on its reported security level. In the Axinom DRM entitlement message, you can attach per-key usage policies that require hardware-backed Content Decryption Modules (CDM) for HD and UHD keys while allowing software-level CDMs to access only the SD key. The license server becomes the enforcement point: a device that reports L3 simply never receives the HD content key, regardless of what the player requests.
This is where multi-key encryption and license policy work hand in hand. Without both, you're relying on the player alone to make the right access control decisions - and in a security model, that's not a position you want to be in.
Additionally, Axinom DRM allows you to enforce Verified Media Path (VMP) verification levels and reject requests from tampered platforms, adding another layer of assurance that the CDM making the request is legitimate.
Multi-Key Encryption Is Ultimately a License Server Design Decision
The choice between single-key and multi-key encryption is often framed as a packaging decision. It is, but the consequences play out entirely at the license server.
With single-key encryption, every rendition in the ABR ladder shares the same content key. Anyone who obtains a license, at any security level, gets the key that also decrypts your 4K HDR stream. The license server has no way to differentiate.
With multi-key encryption, you assign separate keys to different quality tiers (SD, HD, UHD) and to audio tracks. Now the entitlement service can make granular decisions: a premium subscriber on a hardware-secured device gets all keys; a free-tier user on a browser gets only the SD key; and critically, a compromised software CDM that leaks a key only exposes your lowest-value content.
This is why best practice calls for unique encryption keys not just per asset, but per video profile and audio track within an asset. If audio and video share a key, an attacker who breaks the (typically less protected) audio decryption path gets the video key for free. Separate keys for separate tracks close that gap.
From the Entitlement Message, this translates to multiple keys each mapped to a named usage policy with DRM-technology-specific rules for Widevine, PlayReady, and FairPlay, covering HDCP requirements, output protections, minimum device security levels, and more. The license server evaluates these policies at request time and delivers only what the device and user are authorized to receive.
Most teams don't think about this architecture until a studio audit forces the conversation. By then, re-encrypting an entire content library with multi-key is a significant effort that could have been avoided with the right design upfront.
Token Lifetime and Mid-Session License Requests
JWT-based authorization is standard practice: the client obtains a token from the Entitlement Service and presents it with each license request. In simple VOD playback this works seamlessly - one token, one license request, done.
The assumption that licenses are requested only once at session start breaks in several common scenarios:
- Key rotation requires new licenses mid-session as keys change, very common in live streams.
- DRM-based concurrent stream limiting requires licenses to be renewed at short, regular intervals - the server uses these renewals to monitor active sessions.
- ABR switching, especially in case of FairPlay, can require a new license when changing quality tiers.
- Multi-period assets trigger license requests at period boundaries.
If the token has already expired at the moment one of these mid-session requests fires, playback stalls - often silently, with no clear error surfaced to the user. The player must track token lifetime, handle renewal proactively, and stay in sync with rotation boundaries for live streams. This is non-trivial complexity pushed down to every player integration.
A cleaner design is to implement the Entitlement Service as a proxy that stands in as the license server from the player's perspective. The flow changes fundamentally: the CDM creates a license request and the player sends it directly to the proxy - no token attached, because the player never deals with tokens at all. The proxy receives the request, performs its authorization checks, mints a fresh Entitlement Message token on the fly, and forwards both the license request and the token to the actual license server. The license response travels back through the proxy to the player. Token lifetime is entirely a server-side concern; the player just sees a license endpoint that always works. Silent stalls from expired tokens are eliminated by design.
Token design principles still matter on the server side: tokens should be short-lived, measured in seconds or a few minutes rather than hours, and configured for single use to prevent replay attacks. Axinom DRM's prevent_drm_message_reuse setting enforces exactly this - each token can only be redeemed once per entitled key. Because the proxy generates a fresh token per request, honoring these constraints requires no coordination with the player at all.
DRM-Enforced Concurrent Stream Limiting
Concurrent stream limiting is one of the most common content protection requirements, and one of the most commonly implemented incorrectly. The typical approach - tracking active sessions in a database and checking at playback start - is straightforward to bypass: intercept the API call, reuse a stale session token, or simply open a second tab. Application-layer enforcement is only as strong as the application layer.
DRM-based CSL is a fundamentally different model. The license server issues short-duration licenses that must be regularly renewed. Each renewal is a heartbeat: the player requests a license extension, and the Axinom DRM license server monitors how many active sessions the user currently has across all devices. When the configured limit is exceeded, the renewal is denied. Playback stops because the license expires - the CDM on the device enforces it. There is nothing for the client to intercept or spoof.
The heavy lifting falls entirely on the server side. Axinom DRM tracks session state, enforces limits across Widevine, PlayReady, and FairPlay, and handles all counting logic centrally. The player's only requirement is to support license renewal at the intervals the server expects, which any standards-compliant player already does. No custom client code, no fragile application-layer session tracking.
There are meaningful design choices to make. Do you count unique devices or unique sessions? If a user opens two browser tabs, is that one slot or two? Axinom DRM supports different concurrency modes to match different business models. There is also a cross-DRM consideration: PlayReady doesn't natively support session identifiers the same way Widevine does, so the entitlement service can supply custom session IDs to ensure consistent limit enforcement regardless of which DRM technology is in use.
What Holds It All Together: Clear Contracts, Not Tight Coupling
The recurring theme across all of these challenges is the same: the player, the entitlement service, and the license server form a triangle. Weaknesses on any side compromise the entire system.
One approach to this problem is tight vertical integration: use a single vendor's player and DRM service, and rely on their internal coupling to handle the complexity. There are scenarios where that makes sense. But it comes at a cost: you're locked into one player technology, one vendor's roadmap, and one set of trade-offs across every device and platform you need to reach.
At Axinom, we've taken a different path. Rather than coupling the license service to a specific player, we focus on well-defined contracts between the components. The DRM systems themselves - Widevine, PlayReady, FairPlay - already define how players and license servers communicate. When the license server exposes clear, standards-compliant behavior and the entitlement message carries explicit policies, any capable player can integrate correctly. The intelligence lives in the entitlement message and the license server's policy enforcement, not in proprietary glue between a specific player and a specific backend.
In practice, this means Axinom DRM works with the widest possible range of players - Bitmovin, Shaka, ExoPlayer, dash.js, AVPlayer, VisualOn, THEOplayer, and many others - without sacrificing the sophistication of multi-key policies, concurrent stream limiting, or security level enforcement. You choose the best player for each platform and device category, and the license service provides the same rigorous enforcement regardless.
When multi-key encryption is planned at packaging time, with usage policies defined in the entitlement message and enforcement on the license server, the player gets a clear contract: request keys, receive only the ones the server approves, and let the CDM enforce the policies. When concurrent stream limiting is active, the player must support license renewal at the intervals the server expects. When the entitlement service is implemented as a proxy, token lifecycle and authorization logic become entirely server-side concerns - the player sends license requests to an endpoint that always works, with no awareness of tokens at all. None of this requires the player and the license server to come from the same vendor; it requires them to speak the same well-defined language.
The teams that get this right are the ones that think about DRM as a system with clear interfaces from the start, not as a set of isolated integrations, but also not as a monolith where switching any one component means replacing everything.
For a detailed walkthrough of entitlement message configuration, usage policies, and security best practices, see our DRM Best Practices guide. For concurrent stream limiting specifics, see our CSL documentation.
Ready to put this into practice? Start a free trial of Axinom DRM or schedule a technical conversation with our team.
]]>
Screenshot: Bulk Edit in action - selecting multiple items and editing their properties
