Widevine vs FairPlay vs PlayReady: DRM Explained

Most Widevine-vs-FairPlay-vs-PlayReady comparisons stop at platform lists: this one runs on Android, that one runs on Apple, the third runs on Windows. True, but it skips the two details that actually decide how a real multi-DRM deployment gets built: security levels gate the resolution a studio will let through, and a historical encryption-format mismatch used to mean protected video silently failed on Apple devices until the industry converged on a single fix. The previous article covered whether you need DRM at all. This one assumes the answer is yes and explains what actually differs once you're building it.

TL;DR:

• Widevine (Google) covers Android, Chrome, and most smart TVs; PlayReady (Microsoft) covers Windows, Xbox, and much of the TV/set-top-box world; FairPlay (Apple) runs only on Safari, iPhone, iPad, Mac, and Apple TV, and Apple doesn't license it anywhere else.
• Each system has a security tier that gates resolution: Widevine L1, PlayReady SL3000, and FairPlay's Secure Enclave hardware path all unlock HD/4K/HDR, while software-only tiers (Widevine L3, PlayReady SL2000) typically cap out around standard definition.
• FairPlay only ever reads the cbcs encryption scheme. Widevine and PlayReady historically used cenc instead, a real incompatibility that caused protected video to play on Android and Windows while failing silently on Apple devices.
• Since 2018, modern Widevine and PlayReady both support cbcs too, so the industry default is now encrypting once with cbcs, packaging as CMAF, and serving all three DRM systems from the same encrypted files instead of maintaining separate copies.
• AIOZ Stream doesn't support any of the three today, confirmed in the previous article, so evaluating a third-party DRM layer means checking for exactly this CMAF/cbcs convergence rather than assuming any modern provider handles it by default.

Platform ownership and reach

Each system belongs to the platform vendor that built it, and reach follows platform share directly. Widevine, Google's system, runs on Android, Chrome, Firefox, Edge, Samsung Internet, and most smart TVs and streaming sticks. PlayReady, Microsoft's system, covers Windows, Microsoft Edge, Xbox, and a large share of TVs, set-top boxes, and pay-TV devices, territory that browser-share statistics don't capture since most of it isn't a browser at all. FairPlay, Apple's system, is the most constrained of the three by design: it runs only on Safari, iPhone, iPad, Mac, and Apple TV, and Apple does not license it to run anywhere else. That last point cuts the other way too, protected video on any Apple device has to go through FairPlay specifically, since Apple doesn't allow Widevine or PlayReady into the protected video path on its own hardware. Practically, that means real multi-DRM coverage, protected playback across a full audience rather than just the majority of it, requires running all three, not picking a favorite.

Security levels gate the resolution, not just the vendor

All three systems split into tiers based on where decryption actually happens, and that tier is what a studio's licensing terms use to decide what resolution a given device is allowed to receive, not a marketing distinction. Widevine's L1 handles key handling and decryption inside a Trusted Execution Environment, a tamper-resistant hardware region isolated from the main OS, with decrypted video routed through a secure path straight to the display; that's what unlocks HD and 4K, and it's standard on modern Android flagships and current smart TVs. Widevine L3 runs entirely in hardened software instead, no hardware isolation, and because software is easier to attack than a hardware-backed enclave, studios typically cap L3 playback around standard definition, sometimes stretching to 720p. PlayReady mirrors this split with SL2000 (software or mixed hardening, capped near SD, the PlayReady equivalent of L3) and SL3000 (introduced with PlayReady 3.0, runs inside the processor's own trusted execution environment, unlocks HD, UHD, and HDR). FairPlay doesn't publish an equivalent numbered tier system, but on Apple hardware with Secure Enclave, it provides hardware-enforced key protection that functions the same way Widevine L1 does. In every case, a license server checks which tier a requesting device reports and hands out a license scoped to what that tier is allowed to decode, an SL3000 client gets access to a resolution an SL2000 client never will, from the exact same catalog.

The historical gotcha: cenc vs cbcs

Common Encryption, standardized as ISO/IEC 23001-7, defines the actual encryption layer all three DRM systems sit on top of, and it specifies two non-interchangeable schemes: cenc (AES in counter mode) and cbcs (AES in cipher-block-chaining mode with a pattern). FairPlay only ever reads cbcs. Widevine and PlayReady, historically, defaulted to cenc. That mismatch is the single most common multi-DRM failure mode reported across the industry: content encrypted once with cenc played correctly on Android and Windows and simply failed, often silently with no clear error, on every Apple device, because FairPlay had no way to read it. Anyone who built a multi-DRM pipeline before this converged had to maintain two separately encrypted copies of the same content, one in cenc for Widevine/PlayReady and one in cbcs for FairPlay, doubling storage and packaging work for no reason other than a format mismatch between vendors.

The convergence: cbcs everywhere via CMAF

That's no longer necessary. Modern Widevine and modern PlayReady both added support for cbcs, and since roughly 2018 the industry default has shifted to encrypting a title exactly once with cbcs, packaging it as CMAF (Common Media Application Format), and serving Widevine, PlayReady, and FairPlay licenses off that identical set of encrypted segments, with HLS and DASH manifests generated from the same source rather than separate encodes per format. The practical shape of a modern pipeline is one set of encrypted segments, two manifests (HLS and DASH), and three license types issued from license servers keyed to whichever DRM system a given player actually requests, not three separately encrypted catalogs maintained in parallel. That's a real, meaningful workflow simplification, not just fewer files sitting in storage: it removes an entire class of "works everywhere except one platform" bugs that used to be routine in DRM integrations before this converged.

What this means evaluating a DRM provider

Since AIOZ Stream doesn't document DRM support today, covered directly in the previous article, adding real DRM to an AIOZ-hosted workflow means layering a dedicated multi-DRM provider or license service on top rather than flipping on a native setting. The two questions worth asking any provider, given everything above: does it encrypt once with cbcs/CMAF and serve all three systems from that, or does it still maintain separate encodes, a real cost and complexity difference that shows up directly in a storage bill and in how many places a bug can hide. And does it expose which security tier a given client negotiated, so a resolution cap can be enforced deliberately rather than discovered when a studio contract's terms get audited after launch.

Frequently Asked Questions

Do I need to support all three DRM systems, or can I pick one?
Full audience coverage requires all three, since FairPlay only runs on Apple devices and Apple doesn't allow Widevine or PlayReady into the protected video path there. Picking one means excluding whichever platform it doesn't cover.

What's the difference between Widevine L1 and L3?
L1 decrypts inside a hardware Trusted Execution Environment and unlocks HD/4K. L3 runs in software only, with no hardware isolation, and studios typically cap it around standard definition.

Why did my DRM-protected video fail only on iPhone?
Almost certainly a cenc/cbcs mismatch. FairPlay only reads cbcs; older Widevine/PlayReady pipelines defaulted to cenc, which plays fine on Android and Windows but fails on Apple devices.

Do I still need to encrypt my content three separate times for three DRM systems?
No, not since modern Widevine and PlayReady added cbcs support. Encrypting once with cbcs and packaging as CMAF now serves all three systems from the same files.

Does AIOZ Stream support Widevine, FairPlay, or PlayReady?
No. Confirmed directly against AIOZ Stream's documentation in the previous article, none of the three are documented as supported today.

What's PlayReady's equivalent to Widevine's L1?
SL3000, introduced with PlayReady 3.0, which runs inside the device's trusted execution environment and unlocks HD, UHD, and HDR the same way Widevine L1 does.

Related Reading

• What Is DRM and Do You Need It for Video Streaming: whether a project actually needs DRM at all, and what AIOZ Stream offers instead today
• HLS vs WebRTC: the delivery protocol FairPlay's cbcs requirement is tied to
• Video Transcoding Basics: H.264 vs H.265 vs VP9: the encoding layer DRM's encryption wraps around
• How Video Segmentation and M3U8 Manifests Work: the segment structure CMAF packaging builds on
• AIOZ Stream vs Livepeer vs Theta: how AIOZ Stream's infrastructure compares more broadly, content protection aside

References

• Fora Soft: Widevine vs PlayReady vs FairPlay, The 3 DRM Systems: the security-tier definitions and platform details quoted above
• Unified Streaming: Multi-DRM protected HLS and DASH from a shared CMAF source: the cbcs/CMAF convergence workflow quoted above
• Android Developers: ExoPlayer DRM support: confirms Widevine's cenc/cbcs scheme support and PlayReady SL2000 on Android TV directly from Google's own documentation