Multi-DRM Explained (2026): One Workflow, Every Device

Updated October 2026: 2026 multi-DRM pricing (Mux at $0.003 per license, EZDRM flat plans), hardware PlayReady SL3000 in Chrome on Windows 11, a device-to-DRM matrix with Huawei WisePlay, and a multi-DRM FAQ.

What is multi-DRM? The short answer

Multi-DRM is the practice of encrypting a video catalog once and issuing a Google Widevine, Microsoft PlayReady, or Apple FairPlay license, whichever the playback device supports, so one set of protected files plays on every screen. The encryption is shared (the cbcs scheme of Common Encryption, ISO/IEC 23001-7, packaged as CMAF); only the license differs per device. A multi-DRM service runs the key and license servers for all of these systems behind one API. Published 2026 list prices start at about $0.003 per license (Mux, since November 2025) or about $200 to $300 a month for small flat plans (EZDRM's 2026 price list). For a one-line definition, see the multi-DRM glossary entry; this article walks through the full workflow, the cost, and the build-vs-buy call. We say "three DRMs" below because Widevine, PlayReady, and FairPlay cover almost every screen; Huawei's WisePlay is a fourth license type on the same encrypted files.

Why this matters

If you are a founder, product manager, or first-time streaming CTO, multi-DRM is the decision where reaching every device, satisfying every content deal, and controlling your protection bill all meet — and the place teams most often either overspend or ship a catalog that fails on a whole class of devices. The two classic failures are predictable: building a separate protection pipeline per DRM system (tripling encoding and storage for no reason), or encrypting in a way that quietly breaks every Apple device and only surfaces in production. This article gives you the workflow that avoids both — one encryption, one set of files, three licenses — and the build-versus-buy framework for the DRM layer, so you can size the work, talk to a multi-DRM vendor without being upsold, and pass a studio's security review. By the end you can describe your own protect-once pipeline on a whiteboard and say which parts you will buy and which, if any, you will build.

This article is the hub of our content-protection block. It assumes you already know the threat model from why DRM exists and what it actually protects and the device reality from the three DRM systems: Widevine, PlayReady, FairPlay. If you have not drawn the device-to-DRM map yet, read that one first; here we turn that map into a single working pipeline.

The problem multi-DRM solves, in one paragraph

Recall the fact that forces the whole design, established in the three DRM systems: content protection is not one technology but three competing ones, each owned by a platform company and built into its own devices. Google Widevine covers Android, Chrome, and most smart TVs and streaming sticks; Microsoft PlayReady covers Windows, Xbox, and a large share of TVs and set-top boxes; Apple FairPlay covers Safari, iPhone, iPad, Mac, and Apple TV and nothing else, because Apple licenses it to no one. No single system reaches every screen, and the gaps are hard walls. So a platform that wants to reach everyone has to satisfy all three. The question this article answers is not which systems you need — the device map already told you that — but how to serve all three without building, storing, and paying for three of everything. The answer is multi-DRM.

What multi-DRM actually means: encrypt once, license many

Start with a plain-language definition, because "multi-DRM" is often used loosely. The technology that keeps premium video from being copied, called digital rights management (DRM), normally ties a device to one vendor's system. Multi-DRM is the practice of protecting one catalog so that all three vendor systems — Widevine, PlayReady, and FairPlay — can play it, by encrypting the video a single time and issuing whichever license the arriving device understands. The phrase to carry through the rest of this article is encrypt once, license many.

The reason this works rests on a split that most "build a Netflix clone" articles miss, so make it the center of your mental model. A protected stream has two separate layers:

• The encryption layer — shared. This is the scrambling of the actual video and audio bytes. All three DRM systems can read from the same encrypted files, because they agree on a common scrambling standard (we get to it in the next section).
• The license layer — per system. This is the small message that hands a device the key to unscramble the video, wrapped so only that device's trusted hardware can open it. Each vendor has its own license format and its own handshake, and these are not interchangeable.

Picture one locked box holding your catalog, with three differently-cut keys — one for each brand of lock the world's devices use. You build the box once. What changes per visitor is only which key you hand them at the door. You do not build three boxes, and you do not put three copies of your catalog inside. That single picture — one box, three keys — is multi-DRM, and it is why the cost fear is misplaced: you pay for one box plus a small fee each time you cut a key, not for three catalogs.

Figure 1. Encrypt once, license many. One cbcs-encrypted, CMAF-packaged catalog sits inside the protection boundary; at playback the platform issues a Widevine, PlayReady, or FairPlay license depending on the device. The media is shared; only the license differs.

The shared encryption layer: one scheme, one container

If all three systems read from the same files, those files have to be encrypted in a way all three accept. That common ground is a standard called Common Encryption (CENC), defined in ISO/IEC 23001-7. Common Encryption is not itself a DRM; it is the agreement that lets one encrypted file be unlocked by any DRM that follows the standard. It defines two scrambling recipes, called schemes, and the difference between them is the single most important fact in multi-DRM:

• cenc scrambles the video with AES in counter mode (AES-CTR).
• cbcs scrambles it with AES in cipher-block-chaining mode with a repeating pattern (AES-CBC).

The two recipes produce different scrambled bytes, so a device must be handed files in the scheme its DRM understands. Here is the rule that decides your packaging: Apple FairPlay accepts only cbcs. Widevine and PlayReady historically used cenc, but modern versions of both also accept cbcs. Put those facts together and the modern convergence appears on its own — "cbcs everywhere": if you encrypt your catalog once with cbcs, all three systems can read it, because FairPlay requires cbcs and current Widevine and PlayReady accept it. One scheme, one encrypted asset, all three DRMs. That is what multi-DRM encryption means in practice: one AES-128 pass with the cbcs scheme, using content keys from your DRM provider, producing files that every DRM system's decryption module can read.

A common warning you will read deserves a precise correction, because getting it wrong drives needless cost. Many vendor guides state flatly that a multi-DRM setup "must maintain two encrypted copies — cenc for Widevine and PlayReady, cbcs for FairPlay." Per the standard and current vendor support, that is only true if your device list includes old clients that predate cbcs support. For a modern target audience, a single cbcs asset serves all three, and the second cenc copy is an optional fallback for a legacy long tail — not a requirement. Either way, the number that never changes is the most important one: you never produce three encrypted copies, one per DRM, and you never re-encode the video per system. The deep mechanics of the two schemes — why the pattern in cbcs exists and how the convergence happened — are the subject of CENC, CTR, and CBCS: common encryption explained; for the workflow, carry the one rule: standardize on cbcs.

The encrypted bytes also need a container — the file structure that holds the segments your player downloads. The modern choice is the Common Media Application Format (CMAF), defined in ISO/IEC 23000-19, a single segment format that both Apple's HLS and the MPEG-DASH delivery methods can read. Before CMAF, teams often packaged the same video twice — once for Apple devices, once for everything else. CMAF lets one set of segments feed both delivery methods, and the packaging-from-one-mezzanine workflow is covered in packaging: CMAF, HLS, and DASH from one mezzanine. The takeaway for multi-DRM: one mezzanine master, one cbcs encryption, one CMAF package, served as both HLS and DASH — the foundation every license is issued against.

The one packaging step: how keys reach the packager

Here is the part that turns "encrypt once" from a slogan into a real pipeline, and it is where this article goes deeper than the listicles. To encrypt the catalog, the component that packages your video — the packager (sometimes the encoder does this) — needs the content keys and the per-system signaling that each DRM uses to recognize its own licenses. Those keys come from a DRM key provider (your multi-DRM service or your own key server). The question is: how does the key provider hand the packager exactly the right keys and signaling, in a way that works for any packager and any DRM vendor? If every pairing needed a custom integration, multi-DRM would be a wiring nightmare.

The industry solved this with a standard document format for the handoff: CPIX — the Content Protection Information Exchange Format, a DASH-IF specification. A CPIX document is a small structured file that carries the content keys plus each DRM system's specific data — the key identifiers (KIDs) and the protection-system-specific header boxes (PSSH) that get written into the manifests and segments so a Widevine, PlayReady, or FairPlay client can later find and request its license. The CPIX document itself can be encrypted and signed, so the keys are protected in transit. In short, CPIX is the common language a DRM key provider and a packager speak so that one packaging step produces files all three systems can use.

CPIX is the format; you also need a way to request it at the moment of packaging. The widely used API for that is SPEKE — Secure Packager and Encoder Key Exchange, an open specification originally from AWS that defines the request/response between an encryptor or packager and a DRM key provider, using CPIX as the data structure. With SPEKE, any SPEKE-enabled packager (for example AWS Elemental MediaPackage or MediaConvert) can ask any SPEKE-enabled key provider for keys, and the newer SPEKE v2 (using CPIX 2.3) even supports different keys for different tracks, such as one key for audio and another for video. The practical effect: you can pair a managed cloud packager with a multi-DRM vendor and they interoperate out of the box, because both speak SPEKE/CPIX.

You do not need to memorize these acronyms to run a platform, but you should recognize them on a vendor call, because they are what makes "one workflow" literally true. When a DRM vendor says "we're SPEKE-compliant," they mean their key server will plug into your packager without custom glue. That is the difference between a one-week integration and a one-quarter one.

Figure 2. The multi-DRM workflow, end to end. The DRM key provider hands content keys and per-system signaling to the packager over CPIX/SPEKE; the packager encrypts the mezzanine once as cbcs CMAF and writes it to the CDN; at playback each device requests its own license (Widevine, PlayReady, or FairPlay) from the key provider.

What differs per device: the license at playback

With the catalog encrypted once and sitting on your content delivery network (CDN), the only thing that varies per viewer is the license — issued live, when someone presses play. On the web, the player asks the browser which protection system the device has, using a standard browser interface called Encrypted Media Extensions (EME), a W3C specification. EME defines named key systems the player can ask for:

• com.widevine.alpha — Google Widevine
• com.microsoft.playready.recommendation — Microsoft PlayReady
• com.apple.fps — Apple FairPlay Streaming

The player offers its list; the device resolves the one it actually has, through its built-in trusted decryption component (the Content Decryption Module, or CDM). The player then sends that system's license request to the matching endpoint on your DRM service, receives the wrapped key, and playback begins. One player, written once against EME, supplies three license endpoints and lets each device pick its own. The full negotiation and the browser-by-browser reality are covered in Encrypted Media Extensions and the browser DRM stack; the per-platform native side — AVPlayer with FairPlay on iOS, ExoPlayer with Widevine on Android — is in iOS and Android playback. The general flow of how a license server actually delivers a key, across all three systems, is in license servers and key delivery.

Notice what just happened to your architecture. The media layer is shared and static — encrypted once, cached on the CDN, identical for everyone. The license layer is dynamic and cheap — a few hundred bytes per playback, issued by a service. That separation is the whole reason multi-DRM scales: serving a million viewers does not mean a million encryptions, it means one catalog and a million small license calls.

Which DRM does each device use in 2026?

Apple devices use FairPlay only; Android, Chrome, and most streaming sticks use Widevine; Windows, Edge, and Xbox use PlayReady; smart TVs use PlayReady, Widevine, or both depending on model year; and Huawei HarmonyOS devices use WisePlay, a fourth system that several multi-DRM vendors now issue alongside the big three. Two facts matter for the workflow in 2026. Since Chrome 142 (Axinom, November 2025), Chrome on Windows 11 can play hardware-protected PlayReady Security Level 3000 content, which used to be an Edge-only path. And Huawei's WisePlay is offered by castLabs, EZDRM, and DoveRunner, so a catalog aimed at Huawei devices adds one more license type, not another encrypted copy.

The audio caveat changes how you package. Axinom's November 2025 note on Chrome for Windows points out that Security Level 3000 does not apply to audio tracks, so if audio and video share one content key the stream does not get the hardware path. Use multi-key packaging instead: separate keys for audio and video tracks, which is exactly what SPEKE v2.0 with CPIX 2.3 supports. The browser-by-browser details are in PlayReady in depth.

The full pipeline in one pass

Put the pieces in order and the workflow reads as a single line, left to right:

1. Mezzanine master — your high-quality source file enters the pipeline.
2. Encode — it is transcoded into the bitrate ladder (the set of quality levels), exactly as it would be without DRM.
3. Key request — the packager asks the DRM key provider for content keys and per-system signaling over SPEKE/CPIX.
4. Encrypt once + package — the packager scrambles the segments a single time with cbcs, wraps them as CMAF, and writes the HLS and DASH manifests with the Widevine, PlayReady, and FairPlay signaling embedded.
5. Distribute — the encrypted segments go to the CDN, where they are cached and served like any other file. The CDN never sees an unprotected byte.
6. Play — a device requests the stream, asks for its license from the matching endpoint, and its CDM unscrambles the video inside protected hardware.

Only steps 3 and 6 are DRM-specific, and both are handled by your DRM service. Step 4 adds one encryption pass to packaging you would run anyway, and steps 1, 2, and 5 are the same encoding and delivery pipeline you would build without DRM. That is the structural insight worth repeating: multi-DRM adds a key exchange and a license call to your existing pipeline; it does not add a second or third pipeline.

Why three DRMs is not three times the cost

Now the arithmetic, because the cost fear is the single biggest reason teams overbuild. Walk it out loud.

First, storage and encoding do not multiply by three. You encode one ladder and store one cbcs-encrypted, CMAF-packaged copy. Suppose a catalog encodes to 5 TB of protected segments. With multi-DRM the math is:

encrypted copies stored     = 1   (cbcs CMAF, all three DRMs read it)
storage                     = 5 TB        (not 15 TB)
extra encode passes per DRM = 0   (the encode is DRM-agnostic)

If you instead built a pipeline per system — the mistake — you would store 15 TB and run the encode three times, for protection no stronger than the one-copy version. The shared encryption layer is exactly what saves you.

Second, the license layer is a small, per-event fee, not a per-title cost. Multi-DRM services typically charge either a per-license (per-request) fee or a flat monthly platform fee. Published per-license list prices in 2026 sit around $0.003 to $0.005 per license request: Mux charges $100 a month plus $0.003 per license (DRM generally available since November 2025), and Gumlet's September 2026 pricing survey puts standalone DRM services at $0.003 to $0.005. Flat plans exist too: EZDRM lists Universal DRM at $199.99 a month for 10,000 licenses and Universal Complete at $299.99 for 20,000 licenses or 2,000 users. Volume contracts go lower, so confirm current rates with each vendor. Work a representative case: a service with 100,000 subscribers, each starting on average 30 playbacks a month, where roughly one license is issued per playback session:

license requests / month = 100,000 subs × 30 plays = 3,000,000
cost at $0.003 / license = 3,000,000 × $0.003      = $9,000 / month

About $9,000 a month at list price to protect a catalog that, at $9.99 a subscription, earns roughly $1 million a month is under 1% of revenue, and it buys protection on every device at once. A volume contract, license caching, and persistent licenses push the real number lower, because not every playback needs a fresh license. To run the numbers for your own audience, use the multi-DRM cost calculator. The point is the order of magnitude: the protection layer is a rounding error against content and CDN costs, if you use the shared-encryption pattern. The platform-wide cost picture — where DRM sits next to encoding, egress, and origin — is in the OTT cost model.

Figure 3. Three DRMs, not three times the cost. The shared encryption layer keeps encoding and storage at 1×; only the license layer scales, as a small per-event fee. Building a pipeline per system triples the costly layers for no added protection.

Build vs buy the DRM layer

The biggest decision in multi-DRM is not technical, it is make-or-buy, and for almost everyone the answer is buy. There are three realistic options, and they differ by how much of the protection plumbing you operate yourself.

The reason "buy" wins for most is the same reason you do not run your own certificate authority: DRM is a moving target. Vendor capabilities, device support, and certification requirements change — the shifting PlayReady support on Samsung Tizen TVs, covered in the PlayReady-on-Samsung 2026 migration, is exactly the kind of change a service absorbs for you and a self-hosted stack makes your problem. A multi-DRM vendor also holds the relationships and certifications with Google, Microsoft, and Apple that individual integration requires. Established multi-DRM providers include Axinom, EZDRM, DoveRunner (formerly PallyCon, renamed in 2025), BuyDRM (KeyOS), Verimatrix, and castLabs (DRMtoday), and video platforms such as Mux now sell DRM as an add-on. The table below dates what is public as of October 2026; check current device coverage and pricing before committing, because all of these move. The full make-or-buy logic for the whole platform, not just DRM, is in build, buy, or assemble: OTT platform build-vs-buy.

Multi-DRM providers compared (October 2026)

Read the table as a shape, not a quote: flat plans suit small catalogs with predictable viewing, per-license pricing suits growing services, and per-user pricing suits services whose viewers each watch a lot. At 3,000,000 licenses a month, per-license list prices land at roughly $9,000 to $15,000 a month before negotiation; flat plans of this size are volume deals you price directly with the vendor.

What a license can actually say — rental windows, offline playback, output protection (HDCP), and resolution caps tied to the device's security level — is policy you configure on top of whichever option you choose, and it is covered in license policy: rentals, offline, output control, and rights. Buying the service does not mean giving up that control; it means not operating the servers that enforce it.

Figure 4. Build vs buy the DRM layer. Most platforms buy a multi-DRM service; teams in a cloud media stack pair a managed packager with a SPEKE key provider; only very large platforms with strict control needs and a DRM team self-host the license servers.

A common mistake: building three pipelines, or cenc-only encryption

Two errors account for most wasted budget and most broken launches in this area, and naming them is the fastest way to avoid them.

The first is treating "three DRM systems" as "three pipelines." A team reads that it needs Widevine, PlayReady, and FairPlay and sets up three separate encode-and-package paths, tripling compute and storage. The cure is the model from this whole article: the three systems share one encryption layer and differ only in the license. Build one cbcs CMAF pipeline and issue three license types from it. If you find yourself encoding the same title more than once for DRM reasons, stop — that is the signal you have built the wrong shape.

The second is cenc-only encryption that silently breaks Apple. A team encrypts everything with the older counter-mode cenc scheme, confirms it plays on Android and Windows, and ships — then every iPhone, iPad, and Mac shows a black screen, because FairPlay cannot read cenc at all. The failure is invisible until someone tests on a real Apple device, which is why it survives to production. The cure is to standardize on cbcs from the first packaging job, so one set of files serves all three systems. If you must support an old cenc-only device tail, add a cenc variant as a deliberate fallback — never as the default that strands Apple.

The thread through both is the same discipline that runs through this block: derive your pipeline from the shared-encryption model, not from the count of DRM systems. Three systems, one workflow.

Multi-DRM FAQ

What does multi-DRM mean?

Multi-DRM means protecting one video catalog so that every major DRM system can play it: you encrypt once with Common Encryption and issue a Widevine, PlayReady, FairPlay, or WisePlay license depending on the device. One encrypted copy, several license types.

What is multi-DRM encryption?

Multi-DRM encryption is a single AES-128 encryption of the media with the cbcs scheme of Common Encryption (ISO/IEC 23001-7), packaged as CMAF. Current versions of every major DRM system can decrypt that one copy; only the license each device receives is different. Older smart TVs and devices that predate cbcs support may need a cenc fallback.

Do I need Widevine, PlayReady, and FairPlay?

You need every system your audience's devices use. Apple devices only play FairPlay, Android and Chrome use Widevine, and Windows, Edge, and Xbox use PlayReady, so a service that reaches all common screens needs all three, plus WisePlay if Huawei devices matter to you.

How much does multi-DRM cost in 2026?

Published list prices start at about $0.003 per license (Mux: $100 a month plus $0.003 per license) or $199.99 to $299.99 a month for EZDRM's flat plans with 10,000 to 20,000 licenses. Encoding and storage do not triple, because one encrypted copy serves every DRM.

What is a multi-DRM service?

A multi-DRM service is a vendor that runs the key server and the Widevine, PlayReady, and FairPlay license servers for you behind one API. Your packager fetches keys from it over SPEKE/CPIX, and your players request licenses from its endpoints.

What is multi-key DRM?

Multi-key DRM encrypts different tracks with different keys, for example one key for audio and another for video, or a separate key for 4K renditions. SPEKE v2.0 with CPIX 2.3 supports it, and it is required for hardware PlayReady SL3000, because audio tracks cannot take the SL3000 path and need their own key.

Can cloud video transcoding handle DRM?

Yes. Transcoding stays DRM-agnostic, and encryption happens at packaging: cloud packagers such as AWS Elemental MediaPackage and MediaConvert request keys from any SPEKE-compliant multi-DRM vendor and write one cbcs CMAF output for HLS and DASH.

What is a DRM scheme?

A DRM scheme, in Common Encryption, is the encryption recipe applied to the media: cenc uses AES-CTR and cbcs uses AES-CBC with a pattern. FairPlay accepts only cbcs, so cbcs is the scheme that lets one asset serve every DRM.

Where Fora Soft fits in

Multi-DRM is where a platform's device reach, its content deals, and its protection bill all have to agree in one pipeline, and a wrong shape at the start shows up as a tripled encoding bill or a catalog that fails a studio review. Fora Soft has built video streaming, OTT/Internet TV, e-learning, and telemedicine software since 2005, across 250+ shipped projects, and this protect-once problem runs through that work: standardizing a catalog on cbcs Common Encryption and CMAF so one package serves every screen, wiring a multi-DRM key provider to the packager over SPEKE/CPIX, supplying the three license endpoints to players on web, mobile, and TV, and matching license policy to the security level each content deal requires. When a media company needs protection that works on the first try across the whole device matrix — without paying to encode and store the catalog three times — that encrypt-once, license-many engineering is the capability we bring. Our OTT and IPTV development team ships cbcs Common Encryption packaging and the device QA matrix as part of the build, and our video streaming software developers integrate the license servers. When the packaging runs on Wowza Streaming Engine, our Wowza streaming development team wires the multi-DRM vendor's plugin and the CMAF and LL-HLS output in the same project.

The handbook

Fora Soft Video Engineering Handbook

We wrote a seven-volume handbook that works through the whole video stack across 9,000+ pages, and a protected catalog stands on every layer of it. Volume 3 carries the DRM layer past where this article stops - license servers, EME and the CDM, policy, and the delivery economics that decide what protection costs you - while Volume 2 covers the packaging half, CMAF with HLS and MPEG-DASH, and Volume 1 the encode ladder that feeds the one pipeline you just read about. Read the three in that order and you can specify, price, and build the workflow on this page yourself. Written by Nikolay Sapunov, CEO at Fora Soft.

Browse the handbook on Amazon →7 volumes · Kindle & paperback

See our case studies

References

1. ISO/IEC 23001-7 — Common Encryption in ISO base media file format files (CENC) — ISO/IEC. The standard that lets one encrypted file be decrypted by multiple DRM systems; defines the two non-interchangeable schemes, cenc (AES-CTR) and cbcs (AES-CBC with pattern). The foundation of "encrypt once, license many" and the source of the cbcs-everywhere convergence that lets a single asset serve Widevine, PlayReady, and FairPlay. Tier 1 (official standard). https://www.iso.org/standard/84637.html (accessed 2026-06-17)
2. ISO/IEC 23000-19 — Common Media Application Format (CMAF) for segmented media — ISO/IEC. Defines the single segmented container that both HLS and MPEG-DASH can read, so one encrypted package serves both delivery methods — the container half of the shared-media layer in multi-DRM. Tier 1 (official standard). https://www.iso.org/standard/85623.html (accessed 2026-06-17)
3. Encrypted Media Extensions (EME) — W3C Recommendation. Defines the browser DRM API and the key-system model that lets one player negotiate Widevine, PlayReady, or FairPlay without knowing each system's internals; defines the Content Decryption Module (CDM) as "the client component that provides the functionality, including decryption, for one or more Key Systems," and states content is "encrypted per container-specific common encryption specifications, enabling use across key systems" — the spec behind the per-device license layer. Tier 1 (official standard). https://www.w3.org/TR/encrypted-media/ (accessed 2026-06-17)
4. DASH-IF Implementation Guidelines: Content Protection Information Exchange Format (CPIX) — DASH Industry Forum. Defines the document format that carries content keys plus per-DRM signaling (key identifiers and PSSH boxes) from a DRM/key provider to a packager, and may be encrypted, signed, and authenticated — the standardized key handoff that makes one packaging step serve all three DRM systems. Tier 2 (issuing-body interoperability guideline). https://dashif.org/CPIX/ (accessed 2026-06-17)
5. What is Secure Packager and Encoder Key Exchange (SPEKE)? — Amazon Web Services. First-party specification for the request/response API between an encryptor/packager and a DRM key provider, built on the DASH-IF CPIX data structure; SPEKE v2 (CPIX 2.3) adds multi-key (separate audio/video keys) for live DASH and CMAF. The concrete API that implements the CPIX handoff between a cloud packager (MediaPackage/MediaConvert) and a multi-DRM service. Tier 4 (first-party vendor/API spec). https://docs.aws.amazon.com/speke/latest/documentation/what-is-speke.html (accessed 2026-06-17)
6. FairPlay Streaming Overview — Apple. First-party documentation that FairPlay protects Apple platforms only, uses HLS for delivery and the cbcs scheme of Common Encryption, and runs the key handshake via an Apple certificate, a Server Playback Context (SPC), and a Content Key Context (CKC) — the reason cbcs is mandatory in any multi-DRM catalog targeting Apple devices. Tier 3 (first-party). https://developer.apple.com/streaming/fps/FairPlayStreamingOverview.pdf (accessed 2026-06-17)
7. Widevine DRM — Overview and Supported Platforms — Google. First-party platform and encryption-scheme documentation, including the per-platform table showing cbcs support across current Android, Chromecast, smart TVs, and desktop/mobile Chrome, Firefox, and Opera — the support evidence behind "modern Widevine accepts cbcs." Tier 3 (first-party). https://developers.google.com/widevine/drm/overview (accessed 2026-06-17; page last updated 2024-10-09)
8. Multi-DRM protected HLS and DASH from a shared CMAF source — Unified Streaming. Vendor engineering documentation of the shared-CMAF multi-DRM workflow — one encrypted source feeding HLS and DASH with Widevine, PlayReady, and FairPlay licenses — confirming the encrypt-once packaging pattern in a production packager. Tier 4 (vendor engineering). https://docs.unified-streaming.com/documentation/package/multi-format-drm.html (accessed 2026-06-17)
9. CPIX and the role it plays in securing your content — castLabs. Vendor engineering explanation of how CPIX standardizes key exchange between a packager and a DRM solution in a multi-DRM workflow — context for why "SPEKE/CPIX-compliant" means out-of-the-box packager-to-key-provider interoperability. Tier 4 (vendor engineering). https://castlabs.com/news/cpix-and-its-role/ (accessed 2026-06-17)
10. Video DRM Cost in 2026: 3 Pricing Models Compared — Gumlet. Vendor cost analysis laying out the three multi-DRM pricing models (per-license/per-request, flat platform add-on, and self-hosted) with 2026 figures, including the $0.003 to $0.005 per-license range for standalone DRM services and the DoveRunner and castLabs DRMtoday entry plans — the basis for the cost-shape framing and the build-vs-buy options. Tier 4 (vendor pricing; dated). https://www.gumlet.com/learn/video-drm-cost/ (updated 2026-09-18; accessed 2026-10-21)
11. Protect your video content with DRM, now GA — Mux, 2025-11-10. First-party announcement that Mux DRM is generally available for Widevine, PlayReady, and FairPlay at $100 a month plus $0.003 per license, with volume discounts. Tier 4 (first-party vendor pricing). https://www.mux.com/blog/protect-your-video-content-with-drm-now-ga (accessed 2026-10-21)
12. Product & Service Pricing Summary — EZDRM. First-party price list: Universal DRM $199.99 a month for 10,000 licenses, Universal Complete $299.99 a month for 20,000 licenses or 2,000 users, single-DRM and WisePlay plans at $99.99, each with a one-time setup fee. Tier 4 (first-party vendor pricing). https://www.ezdrm.com/service-pricing (accessed 2026-10-21)
13. Hardware-backed DRM in Chrome on Windows — Axinom, 2025-11-18. Vendor engineering note that Chrome 142 and later on Windows 11 supports PlayReady Security Level 3000, previously Edge-only, and that SL3000 does not apply to audio tracks, so audio and video need separate keys. Tier 4 (vendor engineering). https://86.docs.axinom.com/blog/hardware-drm-chrome-windows (accessed 2026-10-21)
14. Multi-DRM Release Notes — DoveRunner (formerly PallyCon). First-party changelog: PlayReady Server SDK 4.7 (January 2026), PlayReady parameters in CPIX v2 and SPEKE v2.0 APIs (January 2026), SPEKE v1/v2 compatibility work (June 2026), and the PallyCon-to-DoveRunner rename across SDKs in 2025–2026, and WisePlay DASH packaging and license-token support (2025). Tier 4 (first-party vendor). https://docs.doverunner.com/content-security/release-notes/multidrm-release-notes/ (accessed 2026-10-21)
15. Huawei WisePlay — castLabs. Vendor page describing WisePlay as Huawei's DRM, compatible with Common Encryption (AES-CTR and AES-CBC) over DASH, HLS, and CMAF, on EMUI and HarmonyOS phones, tablets, and TVs, offered alongside Widevine, PlayReady, and FairPlay. Tier 4 (vendor). https://castlabs.com/partners/huawei-wiseplay/ (accessed 2026-10-21)

Source note: the shared-encryption foundation of multi-DRM traces to tier-1 standards — Common Encryption and its two schemes (ISO/IEC 23001-7, ref 1), the CMAF container (ISO/IEC 23000-19, ref 2), and the browser key-system/CDM model (W3C EME, ref 3) — plus the DASH-IF CPIX interoperability guideline for the key handoff (ref 4). The concrete key-exchange API (SPEKE, ref 5) and the cbcs/Apple requirement (Apple, ref 6) and Widevine cbcs support (Google, ref 7) are first-party vendor sources. The encrypt-once production pattern, the CPIX interoperability claim, and the cost models are vendor engineering/pricing sources, labelled in-text and dated (refs 8–10). The October 2026 refresh adds dated first-party pricing (Mux, EZDRM, refs 11–12) and device-support changes (Chrome PlayReady SL3000, DoveRunner, WisePlay, refs 13–15). Where popular guides claim a multi-DRM catalog "must" keep two encrypted copies (cenc + cbcs), this article follows the standard and current vendor support — a single cbcs asset serves all three for a modern device target, with cenc an optional legacy fallback — and flags the discrepancy.