What is video DRM and how does it work?

By the WpStream Editorial Team

Last updated: June 26, 2026

Most video content protection stops casual copying, not a determined pirate. That’s the honest starting point. Video DRM (Digital Rights Management) is the strongest layer you can add, but it isn’t a single switch; it sits at the top of a stack that also includes AES-128 HLS encryption, signed expiring URLs, and CORS domain restriction. The three DRM systems that matter are Widevine (Chrome and Android), FairPlay (Apple and Safari), and PlayReady (Windows and Xbox). On certified devices, DRM keeps decrypted video out of reach of the operating system, so screen-capture tools can’t grab it. What it can’t stop is someone pointing a phone camera at the screen. For most independent sites, AES-128 with secure key delivery covers the bulk of the risk, and full multi-DRM earns its place only when content value or licensing demands it. If you run a private streaming platform, the right layer depends on what you’re protecting and from whom.

Disclosure: This article is published by WpStream. Where WpStream features appear, we’ve noted them, and recommendations are based on independently verified technical criteria.

Video content protection is a layered system, not a switch

Think of video content protection as a spectrum. At one end is access control: who can reach the stream. In the middle is cryptographic protection: whether the stream data is encrypted. At the far end is hardware enforcement: whether decryption happens in a trusted environment the OS can’t read. Each layer stops a different attacker, and (this is the part competitors skip) each leaves a specific gap open. A table names both.

The real question isn’t “should I use DRM?” It’s “which layers match my content value and my audience?”

Access control and password protection

Access control is the outermost layer, and it sits before any encryption. It decides who can request the stream at all. Passwords, WooCommerce payment gating, membership status, and subscription logic are all access control, and none of them touch the content itself. They stop people who haven’t paid or registered, which makes this the first non-negotiable layer for live and pay-per-view.

What they do not stop is the viewer you already let in. A paying subscriber can hand their login to a friend; a legitimate viewer can screen-record while they watch. Both happen on the far side of the gate, where access control has no say. Our guide to password protected streaming covers the gating mechanics in full.

How do signed URLs and expiring tokens work?

A signed URL carries a cryptographic signature and an expiry timestamp. Your CDN or video server checks both, so a link valid ten minutes ago is dead now. That stops link sharing: someone copies the stream URL into a group chat, and by the time anyone clicks, the token has expired. It also blocks a third party from embedding your stream with a static link. What it does not stop is screen capture during a valid session, or a viewer who shares their login.

Common practice as of mid-2026 is short windows for video segment URLs, roughly 60 to 300 seconds, with longer windows (15 to 60 minutes) for direct download links. Treat those as hedged guidance from CDN documentation, not a hard spec. And signed URLs are often the single highest-return upgrade you can make: they kill link sharing with no encryption overhead.

CORS and domain restriction: what they actually enforce

CORS (Cross-Origin Resource Sharing) is enforced by the browser, and that one fact explains both its value and its limits. When a page on an unauthorized domain tries to fetch your stream, the browser checks whether your CDN’s CORS headers permit that origin, and blocks it if they don’t. MDN’s Cross-Origin Resource Sharing reference is the clean technical background on the header exchange.

What it does not stop is anything that isn’t a browser. A command-line tool, a server-side script, or a native app sails right past CORS, because there’s no browser to enforce it. CORS is not encryption; it does nothing to protect the content itself. Referrer restrictions (which check the Referer header) overlap with it, but the Referer header is forgeable and CORS is not, so using both closes more of the hotlinking surface.

AES-128 HLS encryption: strong cipher, vulnerable key

This is the most misunderstood layer. AES-128 in HLS encrypts each video segment using CBC mode with PKCS7 padding. RFC 8216, the IETF’s HTTP Live Streaming specification from August 2017, defines it in Section 4.3.2.4:

“An encryption method of AES-128 signals that Media Segments are completely encrypted using the Advanced Encryption Standard (AES) with a 128-bit key, Cipher Block Chaining (CBC), and Public-Key Cryptography Standards #7 (PKCS7) padding. CBC is restarted on each segment boundary.”

An alternative called SAMPLE-AES encrypts individual media samples instead of whole segments; FairPlay uses it with the cbcs scheme. Either way, the cipher is not the problem. A 128-bit AES key is cryptographically robust, and nobody is brute-forcing it.

Why the key delivery endpoint is the real vulnerability

RFC 8216 puts the decryption key’s location in the manifest and makes securing that endpoint the publisher’s job; it specifies how to obtain the key via the EXT-X-KEY tag’s URI attribute, and stops there. So an unauthenticated key endpoint hands the key to anyone who asks. Someone with basic browser developer tools can read the key URL out of the manifest, fetch the key, and decrypt the segments. That’s a rainy afternoon, not a research project.

The fix is three things together: require a session-bound token to fetch the key URL, use short-lived expiring key URLs, and rotate keys per segment for high-value content. Done well, AES-128 stops casual segment downloading and bandwidth theft. Done carelessly, with the key behind an open endpoint, it’s barely better than no encryption. And it still won’t stop a screen recorder.

How does video DRM work: Widevine, FairPlay, and PlayReady

Three DRM systems exist for a boring reason: the platform vendors each built their own (nobody agreed on a single standard, the kind of thing you’d hope they would coordinate on). Chrome and most Android devices ship Widevine, from Google. Safari, iOS, macOS, and Apple TV use FairPlay, from Apple. Edge and Xbox use PlayReady, from Microsoft. No single DRM covers everything, which is why “multi-DRM” means running all three (yes, all three, if you want full coverage).

The glue is the W3C’s Encrypted Media Extensions (EME) specification, updated by the W3C Media Working Group on July 18, 2024. EME defines the JavaScript API that lets a web page talk to whichever Content Decryption Module (CDM) is present. It passes the key request to the CDM, which gets a license from the DRM license server (usually via a publisher proxy) and decrypts inside its protected module. The CDM handles decryption. The browser just watches. Underneath all three sits Common Encryption: ISO/IEC 23001-7 lets one encrypted file carry initialization data for multiple DRM systems at once. As of 2026 the cbcs scheme (AES-128 CBC pattern encryption) is becoming the production default, because FairPlay requires cbcs while newer Widevine and PlayReady support it too, so one file can serve all three instead of two.

Device coverage at a glance

For a browser-only audience, Widevine plus FairPlay covers most viewing sessions without touching PlayReady. Widevine itself covers Chrome, Firefox, Edge, Android, iOS native apps via Google’s SDK (per a footnote in Google’s Widevine documentation; iOS browsers, including Safari, use FairPlay, not Widevine), Chromecast, Roku, Amazon Fire, and many smart TVs, but not Safari on desktop or Xbox. FairPlay covers Safari, iOS, macOS, and Apple TV; Apple’s FairPlay Streaming page describes its CBCS-encrypted content, and in practice FairPlay encrypts HLS segments using SAMPLE-AES with AES-128 in CBC mode, with credentials requiring Apple Developer Program approval. PlayReady covers Windows and Xbox over MPEG-DASH, per Microsoft’s DASH content protection specification (version 1.3); its hardware-based top tier, SL3000, is defined in Microsoft’s PlayReady security-level documentation.

Software versus hardware DRM: the screen recording question

This is where most “DRM stops screen recording” claims fall apart. Google’s Widevine documentation describes three security levels: L1 handles all decryption inside a hardware Trusted Execution Environment and enables HD and UHD playback, L2 performs the cryptography inside the TEE so the keys and decrypted media stay off the host CPU, though decoding may still happen in software, and L3 is software-only with no TEE. L3 is the default on desktop Chrome and Firefox, and at L3 the decrypted signal passes through the host OS, where screen recording software can capture it. So the accurate statement is narrow: hardware DRM (L1) blocks OS-level screen recording on certified devices, and software DRM (L3) on desktop does not. The July 2024 EME update also added the ability to query HDCP policy status, the output protection that works alongside L1 to stop capture at the cable.

Live streaming versus VOD: different threat windows

For a live event, the piracy window is measured in hours, and the content loses most of its money value once the event ends, so AES-128 with short-lived signed tokens is often enough. For a VOD library the window is open-ended and the content keeps value for years, which is where full multi-DRM starts to make sense.

Forensic watermarking: traceability after capture

Once you accept the analog hole, forensic watermarking answers the obvious next question: if you can’t prevent capture, can you trace it? Watermarking isn’t prevention; it’s traceability. Every playback session gets a unique, invisible identifier before it streams, and it travels with any recording the viewer makes. It doesn’t stop capture, but it does give you something to act on: if a leaked copy surfaces, specialized tools can extract the session watermark and point to the account it came from.

This is the combination major studios lean on. Netflix, Disney+, and Amazon Prime Video are widely understood to deploy hardware-backed DRM, and even then determined pirates still find ways to capture content. One caveat: watermarking has no open standard the way DRM does, so implementations are proprietary and server-side, which is real cost. For most independent operators, start with AES-128 and signed URLs, and add watermarking only for high-value content you can actually pursue leaks on.

Is video DRM the right choice for your streaming site?

Three variables decide whether full DRM is worth the overhead, and none of them is “how worried am I right now.” Value per session comes first: a $200 pay-per-view event or a $500 online course justifies stronger protection than a free webinar, because high per-session value gives piracy a high payoff. Audience trust radius is second: a small, authenticated subscriber base carries far less risk than anonymous public access. Content shelf life is third, and it’s the one operators forget. A live event that’s worthless the morning after has low piracy ROI; an evergreen library does not. None of these three maps cleanly to a number you can calculate in advance.

For most independent sites, the baseline that covers the majority of exposure is AES-128 with token-authenticated key delivery, signed URLs, and CORS domain policies, all at lower cost than full DRM. Multi-DRM makes sense when content is studio-licensed and the licensor requires it, when per-session value justifies the overhead, or when you distribute to smart TV apps that expect certified L1 playback. And before you commit: Google’s Widevine documentation notes that even with Widevine, you run a license proxy that validates your business rules before forwarding requests to Google’s service. Full DRM is never zero-configuration; it’s an integration you maintain.

How WpStream handles content protection

WpStream is the publisher of this article. The following section describes WpStream’s own features.

WpStream’s technical capabilities include encryption, DRM, and CORS access control, and content protection is included on all paid plans. The specifics, from WpStream’s content protection page, are concrete: all live and VOD content is encrypted with AES-128, and decryption keys are distributed through your website’s built-in user authentication and restricted access logic. A third-party site can’t hot-link to your videos or live events, because secure key distribution and cross-domain policies rule it out.

So the documented stack is the one this article built toward: AES-128 segment encryption, plus authenticated key distribution (keys only reach viewers with valid session credentials, the exact fix for the open-endpoint problem), plus CORS cross-domain policies. For a live and pay-per-view site, that stops the most common attack surfaces, segment downloading, hotlinking, and unauthorized embeds, without a full multi-DRM integration. In practice, the misconfiguration we run into most often isn’t weak encryption; it’s a hotlink or cross-domain policy left too open, which is exactly the gap these CORS rules close. Protection ships on every paid tier, from Lite at $24 per month to Plus at $59 per month. WpStream is a WordPress live streaming and PPV plugin, a strong fit for charging for live events or rentals, including building a white label streaming presence on your own domain. For simple pre-recorded VOD-only playback, credit Presto Player instead.

Key Takeaways

• AES-128 encryption protects HLS video segments, but its security depends entirely on how the decryption key endpoint is authenticated, per RFC 8216.
• Widevine L3, the default for desktop Chrome and Firefox, does not block screen recording; only L1 hardware DRM on certified devices stops OS-level capture.
• The analog hole means any content on a display can be filmed with an external camera, making forensic watermarking the only layer that survives post-capture piracy.
• WpStream protects live and VOD content with AES-128 encryption, authenticated key distribution, and CORS policies on all paid plans (Lite $24/month, Plus $59/month).
• For most independent sites, AES-128 with token-authenticated key delivery plus signed URLs covers the majority of piracy exposure without full multi-DRM overhead.

Frequently Asked Questions

Does AES-128 encryption prevent someone from downloading my videos?

AES-128 encrypts each video segment, so a raw download of the segment files yields undecipherable data. The practical risk is the decryption key endpoint: if the key URL in your HLS manifest isn’t protected by session authentication, anyone who can read the manifest can fetch the key and decrypt the segments. WpStream distributes keys only through authenticated session logic, which closes that gap.

What is the difference between Widevine L1 and L3 for screen recording?

Widevine L3 is the default on desktop Chrome and Firefox. It’s software-only and does not prevent OS-level screen recording. L1 requires a hardware Trusted Execution Environment, available on most Android devices and certified smart TVs, and at L1 the screen capture API cannot read the decrypted signal. For a site running WpStream’s protection stack, the relevant layer is AES-128 with authenticated key delivery rather than hardware DRM.

Is DRM necessary for pay-per-view live streaming?

For most PPV live events, AES-128 encryption with short-lived signed tokens is enough, because the content loses piracy value once the event ends and the payoff for an attacker drops fast. Full multi-DRM becomes worthwhile when per-session value is high, studio licensing requires it, or you distribute to smart TV apps. WpStream’s built-in protection covers the live PPV use case without a custom DRM integration.

Can DRM prevent someone from recording my video with a second camera?

No digital protection layer, including hardware DRM, prevents someone from pointing an external camera at a screen. This is the analog hole: once content is visible on any display, it’s physically capturable. What WpStream and DRM systems protect against is digital extraction and automated piracy at scale. For tracing a leak back to its source after capture, forensic watermarking is the complementary tool.

The protection stack for video isn’t static. The W3C updated EME in July 2024, cbcs packaging is settling in as the new production default, and hardware DRM certification keeps reaching more device classes. For an operator, the most durable decision is matching protection strength to your content’s value today, and revisiting it as you grow. The next step, if you’re building from the ground up, is deciding how the rest of your private streaming platform fits around that protection layer.