Streaming DRM Explained: Widevine, PlayReady, and FairPlay
How the three major DRM systems work, why every service has to support all three, and what Widevine security levels actually mean for playback quality.
Digital rights management is the part of a streaming pipeline that most developers encounter only when something breaks, a stream that plays fine in Chrome refuses to go above 480p, or works on one Android phone and returns an opaque error on another. Understanding the architecture makes those failures legible rather than mysterious.
The Basic Architecture
Every modern DRM system separates two things: the encrypted content, and the keys that decrypt it. This separation is what makes DRM compatible with ordinary CDN delivery.
The content is encrypted once, at packaging time, with a content key. Encrypted segments are then served from any CDN like any other file. The CDN never holds a key and never needs to. When a player wants to start playback, it performs a separate transaction with a license server, proving it is entitled to the content and receiving the decryption key wrapped in a form only that specific device can unwrap.
The flow looks like this:
1. The player fetches the manifest and sees that content is encrypted, along with identifiers for which DRM systems are supported.
2. The player's Content Decryption Module generates a license request containing a key identifier and a device certificate.
3. That request goes to your license server, usually accompanied by an application-level authentication token you issued.
4. Your service decides whether this user is entitled to this content.
5. If so, the license server returns a license containing the content key, encrypted to the device's certificate.
6. The CDM decrypts the key inside a protected environment and begins decoding.
The critical property is that step 4 is yours. DRM vendors supply the cryptographic plumbing; entitlement (subscription status, rental windows, concurrent stream limits, geographic rights) is business logic you own. This is where most of the interesting engineering lives.
Why There Are Three
The three major systems exist because three platform vendors each built one, and each controls the platforms where theirs is mandatory.
Widevine (Google) covers Chrome, Firefox, Edge, Android, Android TV, Chromecast, and the majority of smart TVs.
PlayReady (Microsoft) covers Windows, Xbox, and a substantial share of smart TVs and set-top boxes, particularly in operator-deployed hardware.
FairPlay Streaming (Apple) covers Safari, iOS, iPadOS, tvOS, and macOS. There is no alternative on Apple platforms.
No single system covers everything, so any service with broad reach implements all three. The saving grace is that under Common Encryption they can share content: one encrypted copy, with per-system license acquisition. The manifest advertises each supported system alongside system-specific initialization data, and the player selects whichever its platform provides.
This is why the encryption scheme question matters so much. Once all three systems supported cbcs, a single encrypted asset became genuinely universal.
Widevine Security Levels
This is the source of most real-world confusion, so it is worth being precise.
Widevine defines three levels describing where cryptographic operations and video decoding happen:
L1 means both key handling and video processing occur inside a hardware-backed trusted execution environment, so decrypted frames never enter memory the main operating system can read. L3 means the CDM runs in software, and a determined attacker with control of the device could in principle extract frames.
Content owners set minimum levels contractually. Most premium studio licensing requires L1 for HD and above, which is why:
• Desktop Chrome, which is L3, is commonly capped at 720p or lower on major services.
• Some Android phones play HD and others do not, despite similar specs, L1 depends on the specific SoC and vendor implementation.
• Rooted or bootloader-unlocked Android devices often drop from L1 to L3, because unlocking invalidates the attestation the TEE depends on.
None of this is a bug. It is the policy working exactly as the content licence specifies. When a user reports "I can only get SD on my laptop," the answer is almost always L3, and it is not something your application can override.
PlayReady has an analogous concept in its security levels (SL150, SL2000, SL3000), and FairPlay relies on Apple's hardware security across its platforms, which is part of why Apple devices generally have fewer quality-capping surprises.
Multi-DRM in Practice
Implementing all three separately is possible and rarely worth it. The usual approach is a multi-DRM service that presents a single license endpoint and handles per-system protocol details behind it. Several commercial vendors occupy this space, and there are open-source implementations for the parts that are not vendor-restricted.
Whichever route you take, the pieces you must build are the same:
A key management strategy. How many content keys per asset? A single key per title is simplest. Separate keys per resolution tier allow enforcing L1-only for HD while still serving SD to L3 devices, a common requirement, and one that is painful to retrofit.
Token-based entitlement. The license request should carry a short-lived token your application issued after checking subscription status, not raw credentials. The license server validates the token and returns the key or refuses.
License policy. Licenses carry rules: expiry, whether they persist for offline playback, output restrictions such as HDCP requirements. Persistent licenses for downloads need particular care around renewal and revocation.
Robust error handling. DRM errors are notoriously unhelpful, and the same underlying cause surfaces differently across platforms. Log the CDM error code, the system in use, the security level, and the device model together, without all four, diagnosing a report is guesswork.
What DRM Does Not Do
Worth stating plainly, because expectations here are often miscalibrated.
DRM does not make content impossible to copy. It raises the cost and complexity of doing so, and (more importantly commercially) it satisfies contractual requirements that content owners impose before they will license anything. A service without DRM generally cannot obtain premium content at all, which is the actual business reason it exists.
It also does not protect against the analogue hole, screen capture on compromised devices, or credential sharing. Those are addressed, if at all, by watermarking, concurrency limits, and device registration, separate systems that sit alongside DRM rather than inside it.
Finally, DRM adds real failure modes for legitimate users. Every additional requirement (a minimum security level, an HDCP-compliant display chain, a working license endpoint) is another thing that can go wrong between a paying subscriber and a picture. Budget engineering effort for that reality rather than treating DRM as a component you integrate once and forget.