TL;DR
- Common Encryption (CENC), standardized as ISO/IEC 23001-7, lets one encrypted media file be decrypted by Widevine, PlayReady, and FairPlay instead of requiring a separately encrypted copy for each DRM.
- CENC is not a DRM system. It standardizes how media gets encrypted and signaled. Each DRM still runs its own license request, license server, and key delivery process.
- Two schemes matter in practice: CENC (AES-CTR, full sample) and cbcs (AES-CBC, pattern encryption). Apple FairPlay reads cbcs only, and its own streaming specification explicitly rules out CTR-based encryption for HLS delivery.
- A file packaged with classic CENC plays cleanly on Widevine and PlayReady and fails on every Apple device, because the cipher mode itself does not match what FairPlay's key exchange expects.
- pssh boxes carry each DRM's initialization data inside the same encrypted asset, which is the mechanism that lets one file point three separate license systems to the same content key.
- Checking a packaged file's schm, tenc, senc, and pssh boxes tells you exactly which scheme it uses, before a QA pass on an iPhone tells you the hard way.
A developer on Apple's own developer forums spent hours debugging a FairPlay stream that returned "sharp noise with no video" on every playback attempt.
The license exchange worked, the key and IV were confirmed correct in the CKC response, and the content was AES-128 CBC, encrypted and packaged the way their existing Widevine and PlayReady pipeline already handled it. It still would not play, because FairPlay does not decode arbitrary AES-CBC content.
This article is the deep dive on that one failure mode. For the full multi-DRM build, including the license broker layer and the build-versus-managed cost comparison, see Gumlet's guide on building a multi-DRM setup.
It requires content encrypted and signaled specifically as SAMPLE-AES, and no amount of correct key delivery fixes a cipher mismatch at the container level.
That thread, still sitting on Apple's developer forums years later, is the single most common failure mode in multi-DRM video delivery, and almost nobody names it correctly.
Teams call it a licensing bug. They call it a player configuration issue. They restart the Widevine integration, because that one works. The actual problem sits one layer down, in the encryption scheme chosen at packaging time, and Common Encryption is the standard that determines whether that choice was ever going to work across all three DRM systems in the first place.
This article breaks down what CENC actually standardizes, why the specific scheme you pick determines whether FairPlay plays your content at all, and how to check your own packaged files before that check happens in a support ticket.
If you already have a multi-DRM pipeline live, or if you're about to spec one, this is the layer that decides whether "one encrypted file" is a real architecture or a claim your Apple audience disproves for you.
What is Common Encryption (CENC), and What Problem Does it Solve?
Common Encryption is the ISO/IEC 23001-7 standard that defines how to encrypt media samples inside an ISO base media file, in a way that more than one DRM system can decrypt using the same underlying content key.
It solves one specific problem: without it, a platform serving Widevine, PlayReady, and FairPlay would need three separately encrypted copies of every asset, tripling storage and multiplying the packaging pipeline by three.
Regional DRM systems such as Huawei's WisePlay also implement CENC and follow the same CENC-versus-cbcs logic described here; this article scopes to Widevine, PlayReady, and FairPlay because they cover the large majority of SaaS and EdTech audiences, not because CENC is limited to three systems.
Common Encryption was formalized as ISO/IEC 23001-7 and has gone through multiple editions since its original release, with the third edition published in 2023 extending the original scheme set.
The standard itself does not touch licensing, authentication, or playback policy. It only defines the encryption format and the metadata that tells a compatible client which key and which scheme were used.
That distinction matters more than most explanations give it credit for. CENC is the encryption layer. DRM is the licensing and enforcement layer, and the two are not interchangeable even though they're almost always deployed together.
The fastest way to spot a team that's about to misconfigure their multi-DRM build is listening for the phrase "we're implementing CENC for security." CENC is not a security feature on its own. It's a packaging format. The security comes from the DRM systems that sit on top of it, and skipping that distinction is how teams end up assuming one CENC pass automatically means every DRM they've contracted with is protected.
How One Encrypted File Plays on Widevine, PlayReady, and FairPlay
A single CENC-packaged file reaches all three DRM systems through five steps: encode the source, package it as CMAF, encrypt the samples once with a shared key and a chosen scheme, embed each DRM's initialization data in the manifest, and let each client request its own license independently.
- Encode the source video into adaptive bitrate renditions, typically H.264 or H.265, targeting fragmented MP4 output.
- Package the renditions as CMAF (Common Media Application Format), the container format that lets HLS and DASH reference the same underlying media segments instead of maintaining separate rendition trees. DASH is the only one of the two delivery protocols that natively supports multiple DRM systems in a single manifest; HLS is required for every Apple platform, and FairPlay is the only DRM Apple platforms accept, which is why a complete multi-DRM pipeline needs both protocols even after CMAF unifies the underlying media segments.
- Encrypt the samples once, using a single AES-128 content key and one of the CENC schemes, most commonly cbcs in a 2026 production pipeline targeting all three DRMs.
- Embed PSSH boxes for each DRM system into the manifest or the initialization segment, so a player can identify which license systems are available for that asset.
- Let the client request its own license. Widevine, PlayReady, and FairPlay each run a separate license request against a separate license server endpoint, but all three decrypt the same encrypted bytes using the key that request returns.
That fifth step is where the confusion usually starts. Encrypting once does not mean licensing once. Gumlet's own documentation on building multi-DRM pipelines makes the same point from the engineering side: the encryption problem gets solved at the standards layer, and the operational complexity that remains lives entirely in license server management, not in the packaging step.
If you're scoping a full build rather than diagnosing one scheme decision, that breakdown of the multi-DRM architecture covers the license broker layer, the four-layer stack, and the build-versus-managed cost comparison in more depth.
Does CENC Mean Widevine, PlayReady, and FairPlay Use the Same License?
No. CENC lets the three DRM systems decrypt the same encrypted media, but each one runs an entirely separate license request, license server, and key delivery protocol. The encrypted bytes are shared. The path to unlocking them is not.
That separation shows up cleanly in the device mapping each DRM owns:
| DRM System | Primary Platforms |
|---|---|
| Google Widevine | Chrome, Android, Chromecast, Android TV |
| Microsoft PlayReady | Windows, Edge, Xbox, most Samsung and LG smart TVs |
| Apple FairPlay | Safari, iOS, iPadOS, macOS, tvOS |
None of these three systems talk to each other. Widevine's license server has no visibility into a FairPlay request, and a PlayReady CDM cannot negotiate a license from a Widevine endpoint.
What CENC gives you is the ability to point all three at the same underlying content key through three completely separate license conversations.
A single AES-128 content key can be issued through three unrelated license protocols, which is the entire mechanical trick behind multi-DRM, but it is a trick that happens after decryption has already succeeded, not instead of it. Miss that ordering and the whole architecture looks broken when it's actually working exactly as designed, just pointed at the wrong scheme.
CENC vs. CBCS: The Scheme Choice That Actually Determines Compatibility
The scheme you pick at packaging time, not the fact that you used CENC at all, is what determines whether your file actually works across Widevine, PlayReady, and FairPlay. Two of the four ISO-defined schemes see real production use in 2026: CENC and cbcs.
| Scheme | AES Mode | Pattern Encryption | Widevine | PlayReady | FairPlay | Typical Use |
|---|---|---|---|---|---|---|
| CENC | CTR (counter) | No, full sample | Yes | Yes | No | Legacy DASH, Widevine and PlayReady only |
| cbcs | CBC (chaining) | Yes, 1:9 pattern on video | Yes, on supported clients | Yes, from PlayReady 4.0 | Yes, required | 2026 default for CMAF multi-DRM |
| cbc1 | CBC | No, full sample | Rare | Rare | No | Legacy, minimal production use |
| cens | CTR | Yes | Rare | Rare | No | Legacy, minimal production use |
A fifth scheme, sve1, entered the ISO/IEC 23001-7 third edition in 2023 but has not reached production deployment as of 2026; it does not appear in the table above because no current pipeline needs to account for it.
Verdict: If your pipeline needs to reach FairPlay, and almost any consumer or SaaS audience does, cbcs is the only scheme in this table that gets you there. Teams still shipping classic CENC in 2026 are running Widevine and PlayReady coverage with a hard ceiling on Apple devices, whether that decision was intentional or not.
The gap between the two schemes is not cosmetic. CENC encrypts every byte of a sample using AES in counter mode. cbcs encrypts in cipher block chaining mode, and it does it in a pattern, typically encrypting one block and leaving nine clear across video samples.
Apple introduced this pattern encryption approach in 2014 for the original FairPlay Streaming implementation, specifically to reduce the AES-CBC decryption load on the hardware of that era, and the same 1:9 pattern has carried forward into the modern cbcs scheme.
That pattern behavior is what makes cbcs compatible with codec structures FairPlay expects, and it's why the two schemes are not interchangeable at the client level even though both technically qualify as "CENC."
Both Widevine and PlayReady added cbcs support industry-wide starting around 2018, which is why cbcs has become the practical default for any pipeline built after that point. The compatibility ceiling now sits almost entirely on the FairPlay side, where cbcs was never optional to begin with.
Why Standard CENC (AES-CTR) Breaks Apple Playback
FairPlay cannot decrypt classic CENC content because Apple's streaming specification requires AES-CBC encryption for HLS delivery, and CTR-mode content simply does not match what a FairPlay-compatible client expects to decrypt.
This is not a configuration flag you can toggle after the fact. It's a hard constraint baked into the codec and container handling on every iPhone, iPad, Mac, and Apple TV.
Here's the sequence that plays out when a team misses this: A pipeline gets built around Widevine first, because Widevine's Shaka Packager tooling and DASH-CENC documentation are the most widely referenced starting point. Classic CENC, AES-CTR, full-sample encryption, works cleanly. PlayReady gets added next, and because PlayReady has supported CTR mode since its earliest CENC implementations, it also plays without incident. FairPlay gets added last, using the exact same encrypted package that just worked twice.
It fails. Not with a clear error naming the scheme mismatch, but with generic playback failures: black screens, "sharp noise with no video" as one developer described it on Apple's own forums, or opaque CoreMediaErrorDomain codes that say nothing about cipher modes.
Teams spend days checking certificate chains, KSM configuration, and license server responses, because those are the layers that usually break FairPlay integrations. The actual cause never gets checked, because the packaging step "already worked" for the other two DRMs.
A developer troubleshooting this exact mismatch on Apple's developer forums described getting clean playback with test SAMPLE-AES content, then a garbled, videoless result the moment real AES-128 CBC-encrypted content replaced it, despite an already-working FairPlay KSM and client setup.
That exchange, from a developer troubleshooting exactly this mismatch on Apple's developer forums, captures the failure precisely: correct keys, correct CKC response, wrong cipher path entirely.
If your Widevine and PlayReady streams play cleanly and FairPlay fails with no clear DRM error, check your packaging scheme before you touch your license server configuration. A CENC-only pipeline will pass every Widevine and PlayReady test you run and still be structurally incapable of reaching Safari or iOS, no matter how correctly the FairPlay license exchange itself is wired.
Why Does FairPlay Require CBCS Instead of Accepting CENC Like The Other Two DRMs?
The HLS specification itself defines a SAMPLE-AES-CTR method, but FairPlay's key exchange does not support it. Apple's FairPlay implementation is built around the cbcs scheme specifically, and a FairPlay-protected asset must use cbcs regardless of what the broader HLS spec technically allows.
Widevine and PlayReady were both built to accept CTR mode from the start, since that was the original DASH-CENC default, but FairPlay's key exchange and decryption path were designed around CBC mode from day one.
The result is that cbcs is not a nice-to-have for cross-DRM compatibility. It is the only scheme that reaches all three systems, which is why any 2026 pipeline aiming for full device coverage should treat cbcs as the default, not an optional upgrade.
What are PSSH Boxes, KIDs, and Content Keys?
A pssh (Protection System Specific Header) box is a piece of DRM-specific initialization metadata embedded inside a CENC-packaged file, and it's what tells a player which license systems are available for that asset and where to find the key.
A KID (Key ID) is the identifier that ties a specific content key to the encrypted samples that key unlocks.
Picture a single fictional feature film, encrypted once with one AES-128 content key and one KID. That KID gets referenced in three separate PSSH boxes inside the same packaged file: one carrying Widevine's system ID, one carrying PlayReady's, and one signaling FairPlay's key URI in the HLS manifest, since FairPlay's signaling path differs from the standard PSSH pattern the other two use.
When a Chrome viewer loads the asset, the player reads the Widevine pssh box, sends a license request naming that KID, and receives back the same content key that unlocks the identical encrypted bytes a Safari viewer just decrypted through an entirely separate FairPlay request.
Content key here refers to the single symmetric AES-128 key generated at packaging time and shared across every DRM's license response for that asset, and it's the mechanism that makes "one encrypted file" a literal description rather than marketing language. Without it, each DRM's license server would need to negotiate a different key, which would break the entire premise of shared encryption.
Named entity anchor: Microsoft's own PlayReady documentation confirms this structure directly. CENC packaging can include headers for multiple DRM systems as separate pssh payloads, each identified by its own SystemID, inside a single encrypted asset. That's the same mechanism this walkthrough describes, documented from the vendor side rather than inferred from behavior.
How to Check Whether Your File is Actually CENC or CBCS Encrypted
You can confirm a packaged file's scheme without waiting for a device-specific playback failure to tell you. Four boxes inside the file carry the information: schm, tenc, senc, and pssh.
- schm states the scheme type directly. This box literally contains the four-character code, CENC, cbcs, cbc1, or cens, that names which scheme the file uses.
- tenc carries the default encryption parameters for the track, including the default KID and the IV size, which differs between CTR and CBC implementations.
- senc holds the per-sample encryption data, including initialization vectors and, for cbcs, the pattern encryption metadata that marks which byte ranges are encrypted versus left clear.
- pssh contains the DRM-specific initialization data discussed above, one instance per DRM system the file signals support for.
A quick inspection with a tool like Bento4's mp4dump or Shaka Packager's built-in inspection output will surface all four boxes directly, and the schm box alone answers the scheme question in one line.
Before shipping a multi-DRM asset to production, inspect the schm box on your packaged output and confirm it reads cbcs, not CENC, if FairPlay coverage is part of the requirement.
A file that passes Widevine and PlayReady QA tells you nothing about whether it will decrypt on a single Apple device. That's the decision rule worth pinning above your packaging pipeline's QA checklist, because it's the one check that catches this failure mode before a support ticket does.
Is CBCS Supported on Every Widevine and PlayReady Device?
No, and this is the disqualifier that keeps a blanket "just use cbcs everywhere" recommendation from being safe advice on its own. Support depends on client version, and older devices in both ecosystems predate cbcs entirely.
On the Widevine side, the split runs on the Android version. Android releases from 4.4 through 6.x support CENC but not cbcs. Android 7.x and later support both.
If your audience skews toward budget Android devices or older set-top boxes running an outdated CDM, a cbcs-only pipeline can silently drop coverage for a real slice of that audience, even though it fixes FairPlay compatibility for everyone else.
PlayReady draws a similar line at version 4.0. PlayReady 1.x through 3.x support CENC but not cbcs. PlayReady 4.0 and later support both.
Confirm both thresholds against Google's current Widevine documentation and Microsoft's current PlayReady documentation before treating them as fixed; DRM client support windows shift as vendors deprecate old CDM versions.
Teams serving older PlayReady clients, most commonly through legacy smart TV firmware that never receives CDM updates, need to account for that gap before assuming a single cbcs-encrypted package covers every Windows and TV endpoint they've contracted to support.
Do not switch a live pipeline to cbcs-only without first pulling your own device and CDM version distribution from playback analytics. If your audience data shows meaningful traffic from Android devices on 6.x or earlier, or from PlayReady clients below version 4.0, a cbcs-only migration will fix FairPlay and quietly break a segment of your existing Widevine or PlayReady coverage on the same day.
What CENC Does Not Do
CENC standardizes encryption and signaling. It does not stop screen recording, does not eliminate the need for separate license servers, and does not mean a single manifest serves every device.
Output protection, the layer that actually resists screen capture or HDMI ripping, comes entirely from the DRM and device stack sitting above CENC, not from the encryption scheme itself.
A properly cbcs-encrypted file with no DRM enforcement behind it offers zero resistance to a screen recorder, because CENC never claimed to address that threat model in the first place.
That distinction gets lost constantly in vendor copy that implies encryption alone equals piracy protection, and it's worth naming directly rather than letting the reader infer it.
The "one file, one manifest" assumption breaks the same way. CMAF lets HLS and DASH reference the same encrypted media segments, which is a genuine efficiency gain, but HLS and DASH manifests still carry protocol-specific structure and DRM signaling that differ from each other. Sharing the media bytes is not the same as sharing the manifest.
2026 reality check: In 2020, a team building multi-DRM delivery from scratch usually maintained separate HLS and DASH rendition trees as a matter of course, because CMAF adoption was still inconsistent across encoder and packager tooling. In 2026, that separation has no operational justification for a new build. CMAF has become the default output format across every major packager, which means the "one file" claim in this article's own headline is now accurate at the media-segment level in a way it simply wasn't five years ago. The scheme decision is what's left to get right.
Gumlet runs the packaging and license infrastructure behind video protection for SaaS, EdTech, and media customers at scale, so the CENC-versus-cbcs decision described above is one the platform resolves automatically rather than leaving to a customer's packaging pipeline.
That's a stake worth disclosing directly. The mechanics in this article hold regardless of who's running the pipeline, whether that's a self-managed Shaka Packager setup or a platform handling it behind a dashboard toggle.
Where This Fits in a Full Multi-DRM Build
Scheme selection is one layer inside a larger multi-DRM stack, and it's rarely the layer that costs teams the most engineering time once it's set correctly.
If you're scoping the full build rather than fixing a scheme mismatch, the harder problems sit in license server operations: per-DRM token construction, concurrent stream enforcement, and FairPlay's distinct SPC and CKC exchange.
That's the right next stop if this article answered your "why is FairPlay broken" question and you're now scoping the rest of the pipeline.
For the encryption fundamentals specifically, Gumlet's open reference guide at howdrm.works walks through the broader DRM encryption landscape in more depth, and the platform's CMAF explainer covers the container format this article assumes as a starting point.
Teams evaluating FairPlay against Widevine specifically, rather than the full three-way comparison, may also find the head-to-head breakdown in FairPlay vs. Widevine useful for matching DRM choice to audience device mix before packaging decisions get locked in.
As an all-in-one video hosting platform, Gumlet handles CENC packaging and pssh injection automatically during transcoding for both DASH and HLS output, which means the CENC-versus-cbcs decision this article just walked through never becomes a customer-facing choice on the platform.
DRM is available as an add-on on any paid plan, with the first five videos covered free on any tier, and unlimited multi-DRM protection available for $99 a month. Widevine and FairPlay certification, pssh injection, and CDM detection across Android, iOS, Chrome, and Safari are handled at the platform level rather than left to a customer's packaging pipeline.
Why Does an Integrated Platform Handle This Better Than a Self-Built Pipeline?
A self-built CENC pipeline puts scheme selection, pssh injection, and per-DRM certification entirely on the team building it, and the FairPlay failure mode described earlier in this article is exactly the kind of mistake that surfaces only after a self-built pipeline reaches production.
Gumlet's platform data across its customer base shows the same pattern repeatedly: teams that build packaging in-house discover the CENC-versus-cbcs gap during a QA pass on Apple devices, not during initial architecture review, because Widevine and PlayReady playback masks the problem until FairPlay gets tested.
An integrated platform that defaults to cbcs and handles pssh injection automatically removes that failure mode by never presenting the wrong scheme as a viable option in the first place.
If you're evaluating a video platform's DRM claims, ask them directly which CENC scheme they default to and whether that default has ever caused a FairPlay compatibility gap for an existing customer. A platform that can't answer that question with specifics hasn't actually operated a multi-DRM pipeline at scale.
Gumlet's DRM implementation has blocked more than 150 million unauthorized downloader install attempts across its customer base. GrowthSchool, an EdTech platform using Gumlet's Multi-DRM setup, is one documented example; see the case study for the specific engagement and completion figures reported there.
Gumlet's DRM implementation has blocked more than 150 million unauthorized downloader install attempts across its customer base, and platforms using its Multi-DRM setup, including GrowthSchool, have reported measurable gains in course completion tied directly to viewers trusting that paid content stayed protected.
Frequently Asked Questions
1. What is Common Encryption (CENC)?
Common Encryption, standardized as ISO/IEC 23001-7, is the format that lets a single encrypted media file be decrypted by multiple DRM systems, Widevine, PlayReady, and FairPlay, without maintaining a separately encrypted copy for each one.
It defines the encryption scheme and the metadata signaling, not the licensing or authentication layer that sits above it. CENC by itself never grants playback access. It only makes the encrypted bytes shareable across DRM systems that each still run their own license exchange.
2. Does CENC mean I need only one DRM license?
No. CENC shares the encrypted media across all three DRM systems, but Widevine, PlayReady, and FairPlay each require a completely separate license request, license server endpoint, and key delivery protocol.
The content key returned by each of those three separate requests happens to be identical, since it's the same key generated once at packaging time.
Treat license server management as its own engineering problem, separate from the encryption decision, because solving CENC correctly does zero work toward solving license delivery.
3. Why won't my FairPlay stream play if Widevine and PlayReady work fine?
The most likely cause is a scheme mismatch: your pipeline is packaging with classic CENC (AES-CTR), which Widevine and PlayReady both accept, while FairPlay requires cbcs (AES-CBC) and cannot decode CTR-mode content at all.
This produces generic playback failures rather than a clear DRM error, since the license exchange itself may be working correctly while the underlying cipher mode simply doesn't match.
Check the schm box on your packaged output and confirm it reads cbcs before troubleshooting anything further down the FairPlay stack.
4. Can CENC work without DRM?
Yes, technically, since CENC only defines encryption and key signaling and does not require a DRM system to function. In practice, commercial premium video deployments pair CENC with DRM almost universally, because raw key delivery without a DRM's license server, entitlement checks, and playback policy enforcement offers no meaningful content protection.
Skip pairing CENC with a real DRM only for genuinely low-stakes content where a leaked key carries no real cost, and never for anything gated behind a paywall or subscription.
5. Does using CENC mean I only need one manifest for HLS and DASH?
No. CMAF packaging lets HLS and DASH reference the same underlying encrypted media segments, which cuts out the older practice of maintaining fully separate rendition trees for each protocol.
The manifests themselves, the .m3u8 for HLS and the .mpd for DASH, remain protocol-specific files with their own structure and their own DRM signaling format.
Sharing the encrypted media bytes is a real efficiency gain. Sharing the manifest is a separate claim that CENC never made.
6. Is CBCS safe to use for every device in my audience?
Not automatically. cbcs covers current Widevine clients on Android 7.x and later, PlayReady 4.0 and later, and every FairPlay client, but it drops coverage for Android 4.4 through 6.x and PlayReady versions before 4.0.
Pull your actual device and CDM version distribution from playback analytics before committing to a cbcs-only pipeline, and keep a fallback CENC rendition available if your audience data shows meaningful traffic on pre-cbcs clients.
7. How do I check whether a video file is cenc or cbcs?
Inspect the packaged output's schm box with a tool like Bento4's mp4dump: cenc means AES-CTR full-sample encryption (Widevine/PlayReady), cbcs means AES-CBC pattern encryption (required by FairPlay, accepted by modern Widevine and PlayReady). If FairPlay fails while the others play, the schm box almost always reads cenc.
Closing Thoughts
CENC solves the encryption half of multi-DRM cleanly, and it has for years. What breaks pipelines in 2026 is treating "we implemented CENC" as equivalent to "our file works everywhere," when the actual answer depends entirely on which of four schemes got chosen at packaging time, and whether that choice accounted for FairPlay's hard requirement for cbcs.
If you're troubleshooting a live pipeline right now, the fastest path to an answer is checking the schm box on your packaged output before touching anything else in the FairPlay stack.
If you're scoping a build from zero, default to cbcs, verify it against your actual device distribution rather than assuming universal support, and treat license server operations, not encryption, as the layer that will actually consume your engineering time.
The teams that get burned by this aren't the ones who skip CENC. They're the ones who implement it once, watch two out of three DRMs work, and never go back to check why the third one didn't.
