Multi-DRM: One Workflow for Every Device

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.

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.

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. Steps 1, 2, 4, and 5 are the same encoding and delivery pipeline you would build anyway. 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. Per-license pricing runs in the range of a fraction of a cent to a few cents per license issued (confirm current rates with each vendor — they change). 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.0005 / license = 3,000,000 × $0.0005     = $1,500 / month

Fifteen hundred dollars a month to protect a catalog earning a six-figure monthly subscription revenue is a fraction of a percent — and it buys protection on every device at once. (Caching and persistent licenses push the real number lower, because not every playback needs a fresh license.) 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.

Option	What you operate	Device coverage (Widevine + PlayReady + FairPlay)	Integration effort	Best for
Multi-DRM service (SaaS license + key provider)	Almost nothing — the vendor runs the key and license servers for all three systems; you call their endpoints	All three, maintained by the vendor as systems change	Low — wire endpoints, standardize on cbcs, test on real devices	Most platforms — startups to large services that want protection handled
Cloud packager + SPEKE key provider	A managed packager (e.g. AWS Elemental MediaPackage / MediaConvert) paired with a SPEKE-compliant DRM partner	All three, via the SPEKE/CPIX handoff	Medium — configure the packager and the key-exchange, still buy licenses	Teams already in a cloud media stack wanting tighter pipeline control
Self-hosted license servers	Your own Widevine, PlayReady, and FairPlay license servers and key management	All three, but you carry every vendor change, certificate, and security audit	High — and ongoing — including vendor certification and key custody	Very large platforms with strict control needs and a dedicated DRM team

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 in this space include Axinom, EZDRM, PallyCon, BuyDRM (KeyOS), Verimatrix, and castLabs, among others; name several, date your comparison, and 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.

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.

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 625+ shipped projects for 400+ clients, 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.

What to read next

• CENC, CTR, and CBCS: common encryption explained
• License servers and key delivery
• The DRM and content-protection reference architecture

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your multi-drm plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Multi-DRM Workflow & Build-vs-Buy Worksheet — A one-page worksheet to scope a multi-DRM build before you write packaging code or sign a DRM contract: confirm the encrypt-once / license-many model, lock packaging to the cbcs scheme of Common Encryption in CMAF, map the CPIX/SPEKE….

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. How Much Does Video DRM Cost? The Real Numbers for 2026 — Gumlet. Vendor cost analysis laying out the three multi-DRM pricing models (per-license/per-request, flat platform add-on, and self-hosted) with current figures — 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/ (accessed 2026-06-17)

Source note (per §4.3.2): 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). 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.