Back

Blog details

Widevine vs FairPlay vs PlayReady: DRM Explained for Video

AIOZ Network
14 min readSeptember 16, 2026
aioz-streamguide
Widevine vs FairPlay vs PlayReady DRM explained

Widevine, FairPlay and PlayReady are the three DRM systems you need for full device coverage. Widevine (Google) covers Chrome and Android, FairPlay (Apple) covers iPhone, Apple TV and Safari, and PlayReady (Microsoft) covers Windows and Xbox. All three share one license flow but differ in security tiers and encryption support.

If you are still deciding whether you need DRM at all, the first section below answers that. The rest covers what changes once you build it: the license request, the security tier that caps resolution, and the encryption mismatch that once broke protected playback on Apple devices.

TL;DR:

  • Widevine (Google) covers Chrome, Firefox, Edge, Android and most non-Apple TVs. PlayReady (Microsoft) covers Windows, Xbox and many smart TVs. FairPlay (Apple) is required for protected video on iOS and tvOS and in Safari on a Mac.
  • Every system grades the device by where decryption happens, and the license server releases the HD or 4K key only to hardware-backed grades: Widevine L1, PlayReady SL3000, FairPlay on Secure Enclave hardware.
  • FairPlay reads only the cbcs encryption scheme. Widevine and PlayReady started on cenc, which is why protected video could play on Android and Windows and fail on Apple devices.
  • Widevine on Android reads cbcs from version 7.1 and PlayReady from client version 4.0, so the common default is now one cbcs encryption, packaged as CMAF, serving all three systems. Older PlayReady clients are the exception.
  • AIOZ Stream's documentation mentions none of the three systems, rechecked on Oct 29, 2026.

Updated Oct 29, 2026: expanded the FairPlay section with supported devices and players, Android, and the implementation steps (deployment credentials, Key Server Module, the playlist key tag and the SPC to CKC exchange), plus a labelled diagram of the FairPlay key flow.

Updated Oct 22, 2026: merged our separate post What Is DRM and Do You Need It for Video Streaming? into this guide.

Updated Oct 19, 2026: added "What is FairPlay DRM?" and "Widevine vs PlayReady" sections, a shorter answer-first opening, and a closing section on how AIOZ Stream handles access today.

What is DRM, and do you need it?

DRM (digital rights management) encrypts the video itself, so a player needs a license from a license server before it can decrypt and play it. That is different from gating access to a URL. A signed URL or a login wall controls who can start a request, but once a valid URL is in hand, the segments arrive in the clear. HTTPS does not change that, because it encrypts the connection, not the content.

Whether you need DRM usually comes down to a contract. Studios often require it before they license premium films and series, which is why subscription services use it. Mux draws the line by content type:

  • Premium on-demand video (films, TV, paid courses): DRM is the right call, and often a contract term.
  • Live pay-per-view events: DRM plus token-based session checks, with time-bound licenses.
  • Free or ad-supported content: signed tokens are likely enough.
  • Internal company video: signed tokens with referrer checks usually meet compliance needs.

Plan around one limit, too. DRM protects the path to decryption, not what the screen shows, so anyone who can watch a video can find a way to capture it. What it does is make casual redistribution impractical and satisfy studio licensing terms.

If your library is user uploads, creator content you own or internal training, there is usually no contractual trigger. On AIOZ Stream, the docs describe an is_public flag on each video, true unless you set it, alongside the API key roles covered at the end of this guide. That is access control, not encryption.

Which DRM works on which platform?

Each system belongs to the platform vendor that built it, so your reach follows platform share. Widevine runs in Chrome, Firefox, Edge and Samsung Internet, on Android devices, and on most non-Apple smart TVs and streaming sticks. PlayReady covers Windows, Xbox and many smart TVs. FairPlay stays inside Apple's ecosystem: per Mux, it is required for any DRM-protected video on iOS and tvOS, and Kinescope lists it as the DRM for Safari.

On a Mac, the browser picks the system. Fora Soft notes that FairPlay-licensed content can stream 4K HDR on a Mac, while Widevine in Chrome on the same Mac caps at 720p. If you want full audience coverage, you still run all three, since each one is the only option on at least one platform you want to reach.

What is FairPlay DRM?

FairPlay Streaming (FPS) is Apple's DRM for video delivered over HLS. Apple describes it as the technology content providers, encoding vendors and delivery networks use to encrypt content, exchange keys securely and protect playback on Apple platforms. If you want protected video on an iPhone, iPad or Apple TV, or in Safari on a Mac, FairPlay is the system you need.

Three things set it apart from the other two. It reads only the cbcs encryption scheme, which the cenc vs cbcs section below explains. Its license exchange uses Apple's own message format, an SPC from the device and a CKC back from your server. And you run part of it yourself. Apple's FairPlay Streaming Server SDK gives you a guide, reference information and development keys for the Key Server Module that answers those requests.

Which devices and players support FairPlay?

FairPlay works only inside Apple's platforms and only with HLS. Bitmovin lists iOS, iPadOS, watchOS 7, tvOS and macOS. On the web that means Safari, where the browser's own EME and CDM handle the license, so your web player asks for the com.apple.fps.1_0 key system. In a native app, Apple's AVFoundation player does the work, and Fora Soft notes that you wire the keys through AVContentKeySession. Apple's Server SDK also ships a sample iOS app that shows how to handle key requests on a device.

Does FairPlay DRM work on Android?

No. Android phones do not ship FairPlay, so on Android you protect the same stream with Widevine, and Chrome on a Mac uses Widevine too. That does not mean a second copy of your library. If you package once with cbcs encryption in fMP4 (CMAF) segments, Fora Soft explains that the same files play under FairPlay on iOS and under Widevine on Android. Only the license your key server issues differs per platform.

How do you implement FairPlay DRM?

You need four pieces in place before an iPhone plays a protected title:

  1. Deployment credentials. Per Apple's FairPlay Streaming page, the Account Holder of your Apple Developer Program membership requests approval. Apple approves only teams that run a streaming service for consumers, and it refuses third-party accounts acting for content owners.
  2. A Key Server Module. You build it from the FairPlay Streaming Server SDK, which includes a guide, reference information and development keys, or you rent one from a DRM vendor. SDK 27 added advisory keys and certificate parsing and deprecated Rental Duration for streaming.
  3. A FairPlay-signalled playlist. Segments are encrypted with SAMPLE-AES (cbcs), and the playlist carries a key tag with an skd:// URI and Apple's key format string. For fMP4 segments, the playlist also needs HLS version 6 or higher.
  4. A player that runs the exchange. It fetches your FPS certificate, builds the SPC, posts it to your license URL and hands the CKC back to the operating system for decryption.

The key tag is the part teams most often get wrong. It looks like this (the skd:// value is an example key ID):

#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://example-key-id",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"

Bitmovin describes how the player uses it: the app spots METHOD=SAMPLE-AES with that KEYFORMAT and starts the key request. Fora Soft adds that any other key format value means FairPlay never engages.

Labelled diagram of the FairPlay key flow: the Apple device fetches the HLS playlist with an skd key tag, fetches the FPS certificate, sends an SPC to the Key Server Module and receives a CKC to decrypt cbcs segments
The FairPlay key flow, step by step. Sources: Apple, Bitmovin, Fora Soft.

What happens when a viewer presses play

The vocabulary differs, but the sequence is shared. At packaging time the video is encrypted with a content key, and the stream carries PSSH boxes (Protection System Specific Header) naming the DRM systems that can decrypt it. In a browser, the player finds that data through the Encrypted Media Extensions (EME) API and sends a license request to the system it picked. The license server authenticates the request and returns an encrypted license holding the content key, and the Content Decryption Module (CDM) opens it and decrypts segments as they arrive. In EME code the three systems appear as key system strings: com.widevine.alpha, com.apple.fps.1_0 and com.microsoft.playready (all per Mux).

FairPlay changes the envelope. The device sends a Server Playback Context (SPC) blob to your license server. Your Key Server Module decrypts it with your team's private key, checks its integrity and replay window, finds the requested key ID and returns a Content Key Context (CKC). On modern Apple hardware the key never leaves the Secure Enclave. A PlayReady request carries a copy of the device's client certificate, which is what the next section depends on.

Security levels gate the resolution, not just the vendor

All three systems grade a device by where decryption happens, and studios tie the resolution they permit to that grade. The license server reads the grade and decides what to release.

SystemTierWhere decryption runsWhat it unlocks
WidevineL1Hardware Trusted Execution Environment (TEE)HD and 4K
WidevineL2Hybrid, rare on real devicesHD
WidevineL3Software onlySD, limited by license policy
PlayReadySL150Any implementationTesting only, not commercial content
PlayReadySL2000Software or hardware means, commonly called software-DRMLower than SL3000, set by the license server
PlayReadySL3000Processor TEE, PlayReady 3.0 or higherThe highest quality of commercial content
FairPlayNo published tiersKeys held in the Secure EnclaveA device either supports FairPlay Streaming or it does not

Widevine rows are from Kinescope, PlayReady rows from Microsoft's security level page, and the FairPlay row from Fora Soft.

PlayReady enforces the grade twice. The server can read the tier from the client certificate in the request and send different licenses to different clients. Every license also carries a MinimumSecurityLevel of 150, 2000 or 3000, and a client refuses to bind a license whose minimum is above its own level. Multi-key encryption applies the same idea to the files. Renditions are encrypted with different keys, such as an SD key and a separate HD or 4K key, and the license server releases the high-resolution key only to hardware-backed devices. A weaker device plays SD and never holds the 4K key.

Widevine vs PlayReady: what is the difference?

Widevine and PlayReady do the same job for different owners. Widevine is Google's system, built into Chrome, Firefox, Edge and Android. PlayReady is Microsoft's, built into Windows, Xbox and many smart TVs. Both plug into the same EME license flow in a browser, and both read Common Encryption files. The differences show up in four places when you build it:

  • Widevine grades devices L1, L2 and L3, and PlayReady uses SL150, SL2000 and SL3000. L1 and SL3000 are the hardware tiers that unlock HD and 4K.
  • A PlayReady request carries the device's client certificate, and every PlayReady license states a minimum security level the client must meet.
  • Widevine on Android reads cbcs from Android 7.1. PlayReady reads it from client version 4.0, with extra limits on Windows SL2000 clients before version 4.4.
  • In EME code, your player asks for com.widevine.alpha or com.microsoft.playready.

In practice you rarely choose between them. A service that wants Android and Windows viewers runs both, plus FairPlay for Apple, from one encrypted asset.

The historical gotcha: cenc vs cbcs

Common Encryption, standardized as ISO/IEC 23001-7, sits under all three systems. It defines four modes, and Microsoft notes that two of them, cens and cbc1, are allowed but not supported in PlayReady. The two that matter are cenc, AES in counter mode, and cbcs, AES in cipher-block-chaining mode with a 1:9 encryption pattern. FairPlay reads only cbcs. Widevine and PlayReady began with cenc: the Android ExoPlayer documentation lists Widevine cenc from Android 4.4 (API 19) and cbcs only from Android 7.1 (API 25), and Microsoft says PlayReady clients before version 4.0 supported only cenc.

That gap produced the classic multi-DRM failure. Content encrypted once with cenc played on Android and Windows and then failed on Apple devices, because FairPlay cannot read it. Teams that hit it kept two encrypted copies of every title, one per scheme, which doubled storage and packaging work.

The convergence: cbcs everywhere via CMAF

Most of that gap has closed. PlayReady clients from version 4.0 can take cbcs, and so can Xbox One units on version 1709 or later. Fora Soft calls cbcs packaging the production default for single-encode multi-DRM: one CMAF asset feeds FairPlay, Widevine and PlayReady, with HLS and DASH manifests built from the same segments. On the HLS side, fMP4 segments need protocol version 6 or higher. The result is one set of encrypted segments, two manifests and three license types. The segment structure is the one covered in video container formats.

Three limits in Microsoft's content encryption modes page keep that from being universal:

  • Support is optional for PlayReady clients and signaled to the license server inside the license request. Asking for a CBC key from a client that did not signal support throws an exception.
  • Before PlayReady 4.4, a license server could not issue a CBC key to a Windows client at SL2000, because Windows clients supported CBC only on SL3000 units.
  • A title must not be encrypted in both CTR and CBC mode with the same key ID and key. A client acquiring both would not function, and an attacker holding both versions could decrypt more easily. If you keep both versions during a migration, give each its own key.

Offline playback and license expiry

Offline playback depends on how long licenses last. FairPlay added persistent licenses in iOS 10 (2016), with two clocks: a storage duration, the time a license stays valid before playback starts, and a playback duration, the time it stays valid after playback starts. Fora Soft's example of 30 days to start and 48 hours to finish is a rental. On Android, the ExoPlayer documentation loads an offline key set by ID and states a known limit: only one offline key set can be specified per playback, so offline playback of multi-key content works only with one particular license-server configuration. Mux adds that offline licenses need explicit setup, or a product that promises downloads breaks.

Build, buy or bolt on

Kinescope lists three routes to multi-DRM. You can build it in-house (license servers, FairPlay certificates, CDM updates), hire a vendor that charges per stream (it names DoveRunner, BuyDRM and castLabs), or use a platform with DRM built in. The in-house route has a lead time on the Apple side. Fora Soft reports that Apple approves FairPlay deployment credentials by hand, with reviews running two weeks or more in 2026. A team holds at most two FairPlay certificates at a time.

Whichever route you take, four questions are worth asking any provider:

  • Does it encrypt once with cbcs and CMAF and serve all three systems from that, or does it keep separate encodes? The difference shows up in your storage bill and in how many places a bug can hide.
  • Does it expose which security tier a client negotiated, so you enforce a resolution cap on purpose instead of finding it during a studio audit?
  • Where does the license server sit relative to your viewers? License requests run before playback, so Mux flags that a server adding 500 ms or more is felt as startup delay. It recommends geographic distribution and player-side license pre-fetching.
  • Was it tested on Safari for macOS and on real iOS devices? Mux notes that teams testing only in Chrome ship broken FairPlay, and that simulators behave differently from devices.

How AIOZ Stream handles it

AIOZ Stream does not offer Widevine, FairPlay or PlayReady today. We checked all 47 pages in the docs sitemap, the full API reference included, on Oct 29, 2026, and none of them mentions DRM. If you need DRM on an AIOZ-hosted workflow, you layer a license service from one of the routes above on top. Playback runs through the AIOZ Stream player, and our guide to the player's features and customization covers what it does offer.

What the docs do give you is access control at the API key level. A key is either full_access, which can do every action, or only_upload, which can only upload video, and each key has a time to live in seconds. This is the request body from the API keys reference:

{
  "api_key_name" : "api key name" , // your api key name.
  "ttl" : "1100000" , // Time in seconds that the token will be active. Max 2147483647
  "type" : "full_access" // full_access or only_upload
}

An upload-only key limits what a leaked credential can do. It does not encrypt your video or stop a viewer from saving it, which is the job DRM does. Next step: read the AIOZ Stream API keys docs.

Frequently Asked Questions

Do I need to support all three DRM systems, or can I pick one?
Full audience coverage requires all three, since each is the only option on at least one platform: FairPlay on iOS and tvOS, Widevine on Android and Chrome, PlayReady on Windows and Xbox. Picking one excludes whichever platforms it does not cover.

What's the difference between Widevine L1, L2 and L3?
L1 decrypts inside a hardware Trusted Execution Environment and allows HD and 4K. L2 is a hybrid that is rare on real devices and tops out at HD. L3 is software only, and its ceiling is SD, set by license policy.

What's PlayReady's equivalent to Widevine L1?
SL3000, available from PlayReady 3.0, which runs in the processor's trusted execution environment and receives the highest-quality licenses. SL2000 is the software-DRM tier, comparable to L3.

Why did my DRM-protected video fail only on iPhone?
The likely cause is a cenc and cbcs mismatch. FairPlay reads only cbcs, and a title encrypted only with cenc plays on Android and Windows but cannot play on Apple devices.

Do I still need to encrypt my content three separate times?
Not with modern clients. Encrypting once with cbcs and packaging as CMAF serves all three systems. The exceptions are PlayReady clients older than version 4.0, and Windows clients at SL2000 before PlayReady 4.4.

Can I encrypt the same title with cenc and cbcs using the same key?
No. Microsoft says a service must not encrypt one piece of content in CTR and CBC mode with the same key ID and key, for both functional and security reasons.

Does Chrome on a Mac use FairPlay or Widevine?
Widevine. Safari uses FairPlay. Fora Soft reports that FairPlay content can reach 4K HDR on a Mac while Widevine in Chrome on the same Mac caps at 720p.

Does FairPlay work on Android?
No. Android devices use Widevine. Package once with cbcs in CMAF segments and the same files serve FairPlay on Apple devices and Widevine on Android.

What do I need to deploy FairPlay?
Apple-approved deployment credentials, a Key Server Module built from Apple's SDK or rented from a vendor, a playlist with the skd key tag, and a player that sends the SPC and applies the CKC.

Does AIOZ Stream support Widevine, FairPlay or PlayReady?
No. None of the three appears in AIOZ Stream's documentation, rechecked on Oct 29, 2026. You can limit API keys to upload-only, but that is access control, not DRM.

Do I need DRM for my video platform?
Usually only if a licensing contract requires it, which is common for premium films, series and paid courses. For free, ad-supported, user-uploaded or internal video, signed tokens are often enough.

Does DRM stop screen recording?
No. DRM controls decryption before playback, not what the screen shows afterward. It raises the effort needed to copy a video, but anyone who can watch it can find a way to capture it.

References

We only send updates when meaningful changes ship, and you can unsubscribe anytime

Related Content

blog thumbnail

Video Streaming Protocols: HLS, DASH, WebRTC, RTMP and SRT

Video streaming protocols move video from encoder to viewer. See how RTMP, SRT, HLS, DASH and WebRTC differ in latency, transport and where each one fits.

aioz-streamguide
7 min readNovember 04, 2026
blog thumbnail

What Is Decentralized Live Streaming and How Does It Work?

Decentralized live streaming sends a real-time broadcast through independently run nodes instead of one company's servers. Here's how each stage of it works.

aioz-streamguide
6 min readNovember 03, 2026
blog thumbnail

Video Streaming Glossary: Codecs, Protocols and Delivery A-Z

A video streaming glossary of 114 terms, from AAC and ABR to WebRTC and Widevine, each defined in plain English with sources and links to the deep posts.

aioz-stream
23 min readOctober 31, 2026
blog thumbnail

Monitor Livestream Health With Bitrate, FPS and Viewer Count

Read the AIOZ Stream Statistics panel: bitrate in and out, FPS in and out and current viewers, plus the documented rules for each and what the docs leave out.

aioz-streamguide
6 min readOctober 30, 2026
blog thumbnail

How to Embed a Livestream on Your Website (Link or iFrame)

Embed an AIOZ Stream livestream with the Share button's iframe or send the Public Playback URL as a link. Covers API fields, public access limits and doc gaps.

aioz-streamguide
6 min readOctober 27, 2026
blog thumbnail

Stream Key vs Streaming Session: Preconfiguring a Livestream

Learn how a stream key differs from a streaming session on AIOZ Stream, what each one stores, and what to preconfigure before you go live. Docs-based guide.

aioz-streamguide
7 min readOctober 23, 2026