OTTPublished Oct 22, 202613 min read

Content protection, end to end: how premium video stays safe from source to screen

DRM is one link in a longer chain. How premium video is protected from the contribution feed to the screen, what rights holders expect, and what comes next.

By TV2Z Editorial

Content protection, end to end: how premium video stays safe from source to screen. A stream passes five locked stages on its way to a TV screen.

Ask a platform provider how they protect content, and the answer usually starts and ends with DRM. DRM matters, but it covers one stretch of a longer journey. A film or a live match passes through contribution links, storage, packaging, a CDN and a device before anyone watches it, and it can leak at every one of those points. Rights holders know this, and their security schedules now ask about all of them.

Live sport shows why. In its November 2025 assessment of piracy of live events, the European Commission described one broadcaster that, in some instances, found more than 3,000 illegal streams of a single event. It sent more than one million notices to hosting providers, and only 1.4% of the streams it reported came down while the event was still live. For almost all of them, the match was over first. What works is protection that makes a leak hard in the first place, and that can trace any leak back to the account it came from.

This article follows content along that path, from the rights holder to the screen and beyond. It ends with what every service needs, what premium content demands, and what is coming next.

Five places content leaks

Every protection measure belongs to one of five stages: the source, storage and packaging, the network, the device, and what happens after the screen.

At the source: contribution feeds and master files

Content is at its most valuable before it has been encrypted for viewers. A contribution feed is a clean, high-bitrate signal, and a mezzanine master is the film itself. A pirate who gets either has better quality than any subscriber.

Live feeds now travel over IP using protocols that encrypt in transit: SRT, RIST and Zixi all support AES with keys of up to 256 bits. Encryption on its own only keeps outsiders out. A rights holder sending one feed to many distributors also needs to know which receiver leaked it, and to switch that receiver off. The EBU's royalty-free BISS-CA standard does exactly that: entitlements travel inside the stream, so a receiver can be granted or revoked in real time. BT Sport started using it in August 2019 and went on to protect its Premier League satellite feeds with it.

Finished programmes usually arrive as IMF packages (SMPTE ST 2067), the master format that Netflix, Disney and the BBC prefer for UHD delivery. They move over accelerated transfer tools that encrypt every packet and verify the files on arrival, so both sides can prove what was delivered and that nothing changed on the way.

The weakest link at this stage is rarely the cryptography. It is people and suppliers. In 2017 an episode of Game of Thrones leaked through a processing vendor in India. In 2024 Netflix confirmed that "one of our post-production partners has been compromised" after unreleased episodes appeared online. This is why studios assess their vendors through the MPA's Trusted Partner Network. TPN changed its shield tiers in September 2025: what used to earn Gold now earns Silver, and Gold now requires every best-practice remediation item to be completed and reviewed by TPN.

In storage and packaging: the keys matter more than the files

Once content is inside a platform, two things need protecting: the master files, and the keys that will encrypt the streams.

Encryption at rest is now the floor rather than a feature. Amazon S3, for example, has encrypted every new object by default since January 2023. The controls that matter sit above that floor. Keys managed by the platform owner can be rotated, restricted and disabled. Access should follow least privilege, with short-lived credentials. And because reads of individual files are not logged by default, someone has to switch that logging on to know who opened a master.

Packaging is where content changes form. The encoding and packaging pipeline cuts each title into short segments and encrypts them with Common Encryption (ISO/IEC 23001-7), so that one set of files can be unlocked by Widevine, PlayReady and FairPlay alike. The industry is converging on the "cbcs" variant of that standard, which FairPlay requires and current Widevine and PlayReady clients support. Some older smart TVs and Android versions still need the earlier "cenc" variant, which means packaging twice, with separate keys.

The keys never travel with the content. A separate key service generates them and hands them to the packager over a standard exchange, DASH-IF CPIX or AWS SPEKE, which is built on it. That separation is the point: anyone who breaks into the CDN origin finds only ciphertext. Two further practices raise the bar:

Separate keys per quality tier. SD, HD and UHD renditions, and the audio, each get their own key. A key extracted from a weak software client then unlocks the SD picture and nothing more.
Key rotation on live channels. Keys change at a set interval during a live stream, which limits what any single compromised key exposes.

On the network: tokenisation at the edge

Encryption protects the content. Tokenisation protects access to it. A CDN serves files to anyone who asks, unless each request carries proof that it is allowed. That proof is a token: a signed, expiring credential attached to the URL or carried in a cookie.

Basic token schemes, such as signed URLs and signed cookies, set an expiry time and can bind a request to a range of IP addresses. They stop casual link sharing. They do less against a determined restreamer, who can keep refreshing a valid token from one paying account.

The newer Common Access Token (CTA-5007-B, published in April 2025) standardises richer rules that any CDN can enforce: renewal, limits on replay, binding to an IP address or a country, and proof that the token belongs to the device presenting it. Support is arriving, but unevenly. Amazon CloudFront added it in November 2025. As of October 2026, Akamai supports part of the specification, without replay limits or proof of possession.

Around the token sit the other network controls:

Geo-blocking and VPN detection, so content stays inside the territories it is licensed for.
Licence windows. Licences are often limited in time as well, so access rules need to be set per country and per period in the content management system that runs the service.
TLS on every connection, for manifests, segments, licence requests and the APIs behind the app.
No reliance on "clear key" encryption. Plain AES-128 HLS encryption hands the raw key to the player. It keeps out casual downloads, but it offers no device binding, no output protection and no licence rules, so it is not DRM.

On the device: DRM, security levels and the screen

The device is where encrypted content has to become a picture, so it is where DRM does its work. Three systems cover the market: Widevine for Android, Chrome and many smart TVs; PlayReady for Windows, Xbox and many other TVs; and FairPlay for Apple devices. A service that reaches every screen needs all three, built into the app on each platform: Widevine L1 on certified Android devices, FairPlay on Apple devices, and the browser's Encrypted Media Extensions on the web.

The security level a device reaches matters as much as which DRM it runs:

Widevine L1 decrypts and processes video inside a trusted execution environment, isolated from the operating system. L3 runs in software and is typically limited to SD.
PlayReady SL3000 keeps its secrets in secure hardware. SL2000 covers hardened clients that may protect them in software. Microsoft's security level documentation explains how a licence server can reserve higher resolutions for SL3000 devices.
FairPlay handles keys and decryption inside the operating system's kernel, out of reach of the app.

The licence carries the business rules. It can cap the resolution by security level, require HDCP 2.2 or later before UHD plays, set an expiry on offline downloads, and require periodic renewal so that a session can be ended. Account rules sit alongside: limits on registered devices and simultaneous streams deter casual sharing and make restreaming from one account easier to spot.

Then there is the path to the screen, and the app around the player:

HDCP protects the HDMI link between a box or stick and the television. On set-top boxes such as TV2Z Play One, secure boot makes sure only signed software runs.
Screen-capture blocking stops casual recording, with limits worth knowing. Google says Android's mechanism works reliably on only about 70% of devices running Android 11 or older, and iOS blacks out FairPlay video in a screen recording but not the audio.
Root and jailbreak detection, and attestation through Google Play Integrity and Apple App Attest, let a service refuse to play on a compromised device or in a tampered app.

Keeping all of this current on every platform is specialist work, and one of the reasons most enterprise OTT projects should not build their own platform.

After the screen: watermarking, monitoring and takedown

No protection is perfect. A camera pointed at a television, or a single compromised device, will eventually produce a pirate copy. From that point the goal is speed: find the copy, identify where it came from, and stop it.

Forensic watermarking makes the middle step possible. Each viewer's stream carries an invisible, unique mark, usually a session or subscriber ID. When a pirate stream turns up, reading the mark shows which account it came from, and that session can be cut off while the event is still live.

The most scalable method is A/B watermarking, standardised by DASH-IF and published by ETSI as TS 104 002. Every segment is prepared in two versions, A and B, that look identical. The CDN serves each viewer a unique sequence of As and Bs, so any recording spells out the session it came from.

Every segment exists in two versions, A and B, that look the same to a viewer. The CDN serves each session its own sequence, so a recording spells out where it came from. In theory, six segments can tell 64 sessions apart, and 32 more than four billion. This is a simplified model: real systems spread each ID over many more segments, with error correction, so that a trace survives re-encoding and mixed sessions. Vendors report traces in minutes.

Watermarking is becoming a standard capability rather than a specialist one. AWS added A/B forensic watermarking to its live encoder in September 2026, and vendors now insert marks at the CDN edge from a single encode. Vendors report tracing a leak on live sport in as little as three to five minutes.

Monitoring and legal action complete the loop. Rights holders search for illegal streams during each event and send notices to the services hosting them, and the 1.4% figure above shows why notices to hosting providers do not work on their own for live content. Governments are responding unevenly. The European Commission found the effect of its 2023 recommendation "limited" and is examining further measures. Italy's Piracy Shield requires blocking within 30 minutes, and its regulator fined Cloudflare €14.25 million for not blocking through its public DNS resolver, a fine Cloudflare has said it will contest. Spain's court-ordered IP blocking during LaLiga matches has affected hundreds of thousands of domains, most of them unrelated to football, according to a 2026 OONI study. In the United States, site-blocking bills are pending, but as of October 2026 none has passed.

Account sharing is a quieter version of the same problem. Since Netflix moved to one-household accounts in 2023, enforcement based on devices, IP addresses and activity has become normal practice for subscription services.

The hardest case: offline and on board

Ships and aircraft remove the safety net. There is no licence server reachable over the internet, the servers travel with the vessel or aircraft, outside a secured data centre, and the content is often early-window.

Airlines answered this with the APEX 0415 content security specification for in-flight entertainment. Version 2, approved in 2019, uses CMAF with Common Encryption, sets security requirements for content up to UHD and early-window releases, and adds forensic watermarking.

An on-premises deployment for maritime and transport follows the same model. The platform runs locally on board, and content syncs from a hub ashore over encrypted, certificate-based transfers that send only what has changed, which matters over satellite links. All three DRM systems run side by side. Keys sit in an encrypted store anchored in hardware, typically a TPM, with secure enclaves for the most sensitive processing, and the on-board systems sit behind a VPN rather than on the public internet.

Hardware enclaves raise the bar, but they are not enough on their own. Research published in 2025 showed that an attacker with physical access to a server and inexpensive hardware can defeat the memory encryption that Intel SGX and comparable technologies rely on, and the chip makers treat such attacks as out of scope. That is why a sound design does not rest on the enclave alone: keys are also encrypted and wrapped, a TPM anchors trust, each server's certificate is renewed regularly and can be revoked, and the physical security of the server room is part of the design, not an afterthought.

Three levels of protection

Not every title needs every control. The right level depends on the value of the content and on what the rights holder's contract requires.

Baseline, for every service. Encrypted contribution feeds and file transfer. Encrypted storage with controlled access, and keys from a separate key service. TLS everywhere. Multi-DRM, with software security levels accepted for SD. Signed, expiring URLs. Geo-blocking. Device and concurrent-stream limits. Root and jailbreak detection where the platform allows it. Monitoring and takedown notices.

Premium, for UHD, early-window releases and live sport. This level builds on the Enhanced Content Protection specification from MovieLabs, the studios' joint technology organisation (version 1.4, August 2024). ECP calls for hardware-backed DRM, HDCP 2.2 or later, separate keys for ECP content, signed or tokenised URLs, geo-filtering with VPN and proxy detection, device revocation and enforced security updates, forensic watermarking that survives recording, and content placed on the CDN as late as possible, for example no earlier than two days before release. Premium services add key rotation on live channels, separate keys per quality tier, tokens bound to the session, receiver revocation on contribution feeds and an assessed supply chain.

Next, what is changing. Some of it is arriving now:

Watermarking as a standard feature of cloud encoders and CDN edges, rather than a separate integration.
The Common Access Token on more CDNs, giving multi-CDN services one token format.
Hardware DRM by default. Widevine now revokes older desktop clients regularly, Chrome dropped offline licences on desktop in 2025, and PlayReady SL3000 now works in Chrome on Windows 11.
Post-quantum key exchange for connections. NIST finalised its first post-quantum standards in August 2024, and Chrome and iOS 26 already use one of them, ML-KEM, by default in a hybrid key exchange, so licence requests over HTTPS are increasingly protected in transit when the server supports it.

Some of it is emerging:

Tokens that prove possession, binding access to a device key or a TLS session so that a stolen token is useless anywhere else. The standard supports it; as of October 2026, most CDNs do not.
AI on both sides. Rights holders use it to spot illegal streams in real time, and pirates use it to build and move sites faster.
Faster legal remedies, as the EU considers further measures against live piracy, possibly binding ones.

And some of it is worth watching without overstating:

Post-quantum cryptography inside DRM. As of October 2026, we have seen no published roadmap from a DRM vendor for the key exchange inside DRM itself.
Confidential computing for licence and key servers. Enclaves such as Intel SGX are already used in on-premises systems, but we found no public deployments for licence and key servers in the cloud, and the 2025 physical attacks apply here too.
Content Credentials (C2PA). They show where content came from and whether it has changed since it was signed, which matters for news and against deepfakes. They do not control who can watch.
Passkeys. They make account takeover much harder. Their effect on sharing is less clear.

Questions to ask any platform provider

Whether you are choosing a platform or answering a rights holder's security schedule, these questions quickly show how complete a provider's protection is:

Which DRM systems do you support on each device, and at what security level?
How are content keys generated, stored and rotated, and do quality tiers and audio get separate keys?
How are CDN requests tokenised, and can a valid URL be shared or replayed?
How do you enforce territories, licence windows and VPN detection?
What limits apply to devices and concurrent streams, and can a session be ended remotely?
Can you watermark each session, and how quickly can a leak be traced to an account?
How is content transferred to you and stored at rest, and who can open a master file?
Which security assessments has your supply chain passed?
Can protection keep working offline, on a ship or an aircraft?

Where to start

Content protection is easiest to get right when it is designed into the platform from the start, rather than added one rights holder at a time. Which controls a service needs depends on its content, its contracts and its audience, and the questions above are a good way to find the gaps.

If you run or are planning a managed TVaaS service or an enterprise OTT platform and a rights holder's security schedule is on your desk, we are glad to think it through with you.