Widevine Security Levels: L1, L2, L3 — What They Really Mean

Why This Matters

If you sell paid video, the Widevine security level your viewer's device reports is the single field that decides whether your 4K marketing claim is true or a lie. A product manager reading this article will leave knowing why Chrome on a MacBook plays Netflix at 540p while the same Netflix on an iPad plays at 1080p — different DRMs, different robustness, different studio rules. An engineer will leave with the exact code path that queries the level, the exact pssh and tenc plumbing that ties resolution caps to security levels (covered in our Common Encryption (CENC) in depth article), and the exact robustness strings to pass to requestMediaKeySystemAccess. A founder weighing piracy risk will leave with a defensible answer to "how much harder is L1 to break than L3?" — short version: in 2019 a security researcher broke L3's white-box cryptography in a weekend on a laptop (Buchanan's Differential Fault Analysis attack on the L3 white-box AES); nobody has publicly defeated a production L1 TEE since Widevine 5 shipped in 2014.

This is one half of a pair. The companion piece — DRM 101: why three systems, and why you ship all three — explains why Widevine alone is not enough; this article explains why one Widevine is, in practice, three Widevines.

What a Security Level Actually Is

Before any letter-and-number lands, let's pin down the job. A Widevine security level is a contract between Google and the device manufacturer about where in the device's hardware the dangerous operations happen — the decryption of the content key, the decryption of the video samples, and the decoded video frames on their way to the screen.

There are three dangerous operations and three places they can happen:

1. The license parse — when the device receives an encrypted license from a license server, it has to decrypt that license to extract the content key.
2. The sample decrypt — when the device receives an encrypted video sample (a slice of an I-frame, a P-frame, a B-frame), it has to decrypt the sample using the content key.
3. The decoded frame — once the sample is decrypted, the decoder turns it into pixels and pushes those pixels to the display.

A Trusted Execution Environment, abbreviated TEE — a separate, isolated processor mode that the regular Android or Linux operating system cannot read from — can host all three. Alternatively, normal application memory (the same memory your browser uses to render a webpage) can host all three. The Widevine level is the four-letter shorthand for which combination you have.

L1 — all three operations happen inside a TEE. The keys never appear in normal CPU memory, the encrypted samples never appear in normal CPU memory, and the decoded frames are pushed straight from the TEE to the display controller through a secure video path. The host operating system cannot read the keys, the host operating system cannot read the decoded pixels, and a screen-capture tool running on the host operating system sees a black rectangle where the video should be.

L2 — the license parse and the sample decrypt happen inside a TEE, but the decoded video frames are pushed back out to normal application memory for the software decoder to handle. The keys are safe; the pixels are not. L2 is rare in practice — almost no production device ships at L2 — because the cost of building a TEE is enormous and once you have it, building the secure video path that turns L2 into L1 is comparatively cheap. The 2026 production landscape has effectively two levels: L1 and L3.

L3 — no TEE is used. All three operations happen in normal application memory. The keys, the samples, and the decoded frames are all visible to the host operating system. The cryptography is still real — AES-128, RSA, the same primitives as L1 — but it is implemented in software, hidden by a technique called white-box cryptography that tries to make the key impossible to extract by static analysis. White-box cryptography has been broken twice in public: by David Buchanan in 2019 with a Differential Fault Analysis attack and by Tomer Hadad in 2020 with an RSA-side-channel attack. The L3 keys for the 4.10.x family of Widevine CDMs are publicly known. That is exactly why studios do not let L3 decrypt 1080p.

The single most useful sentence in this article is the next one. The security level lives in the device, not in the content. Your encrypted file is the same file regardless of who plays it back; what changes is which devices the license server agrees to release the key to, and which resolutions the license is allowed to unlock for each of them.

Figure 1. The trust boundary at L1, L2, and L3. The TEE is the dotted blue box; "normal memory" is everything outside it.

Where Each Level Actually Lives in 2026

This is the table every product team should print and pin above the desk.

Device class	Typical Widevine level	Max studio-cleared resolution
Modern Android phone (Pixel 6+, Samsung S22+, Xiaomi 12+)	L1	4K UHD
Older Android phone (2016–2019)	L1 or L3 (varies)	1080p or 480p
Android TV / Google TV (2020+)	L1	4K UHD
Fire TV stick 4K (Gen 2+)	L1	4K UHD
Chromecast with Google TV	L1	4K UHD
ChromeOS device (Chromebook 2020+)	L1	1080p
Desktop Chrome / Edge on Windows	L3	720p (Edge uses PlayReady SL3000 for 1080p+)
Desktop Chrome / Edge on macOS	L3	720p (Safari uses FairPlay for 4K)
Desktop Chrome on Linux	L3	720p
Desktop Firefox (any OS)	L3	720p
Smart TV Tizen / webOS (PlayReady-first)	n/a (PlayReady)	4K via PlayReady SL3000

Sources are vendor-published device matrices (Bitmovin's Widevine Security Levels in Depth, Bunny.net's Widevine documentation) cross-checked against the Widevine Device Compatibility list at integration.widevine.com (the new console that replaced partnerdash.google.com on 17 December 2025).

The headline pattern is consistent and worth memorising. Every device shipped to live in a living room is L1; every device built for general-purpose computing is L3. That gap is exactly the engineering chasm between "I built this device to play video" and "I built this device to do anything". A Chromecast or a Roku or a Samsung TV is a small, locked-down embedded computer with a verified boot chain, a measured firmware, and a chip-level TEE. A MacBook running Chrome is a general-purpose laptop with a million ways to attach a debugger, and Google cannot give it L1 without lying about the security guarantee.

The single most-asked question about this table — "why does desktop Chrome only give me 720p?" — has a one-paragraph answer. Desktop Chrome runs the Widevine CDM as a regular Chrome process in user-space memory. The keys it holds are protected by white-box cryptography, which is software-only obscuration. Studios know the L3 keys are extractable and rate the protection as low. They therefore license at most 720p (and many license at 540p or 480p). The same Chrome process on a Chromebook is the same code, but it loads the keys from a TPM (Trusted Platform Module) and the decoder is hardware-isolated, so studios licence at 1080p. The chassis, not the browser, is what changes.

Figure 2. Where each level reaches what resolution in 2026 production deployments.

The Robustness String and How EME Asks for a Level

When a web page wants to play protected video in a browser, it calls a single function: navigator.requestMediaKeySystemAccess, defined in the W3C Encrypted Media Extensions (EME) specification (Recommendation, 2017; the current draft is W3C EME 2). The call asks the browser whether the key system com.widevine.alpha is available and, crucially, what robustness level the browser can guarantee.

Widevine defines six robustness strings. Reading them aloud is the first lesson in DRM operations:

• SW_SECURE_CRYPTO — software keys, software decode. Widevine L3.
• SW_SECURE_DECODE — software keys, software decode. Widevine L3 (the difference between this and SW_SECURE_CRYPTO is historical; both map to L3 today).
• HW_SECURE_CRYPTO — hardware-backed keys, software decode. Widevine L2.
• HW_SECURE_DECODE — hardware-backed keys, hardware decode of compressed samples. Widevine L1.
• HW_SECURE_ALL — hardware-backed keys, hardware decode, and hardware-protected decoded frames through a secure video path. Widevine L1, strictest profile. Required by Netflix for 4K.
• "" (empty string) — the browser is asked to pick "whatever it can do". Most browsers downgrade to SW_SECURE_CRYPTO (L3) when the robustness is empty. This is the most common production bug, because a website that forgets to set robustness will silently get 720p when it could have asked for and received 1080p on the same device.

The robustness string is sent inside the EME license request to the Widevine license server (or to your packager's license proxy). The license server uses it as one input to the licensing decision: "is this device certified to deliver at this robustness, and is the content allowed to be unlocked at that robustness?" If both are yes, the server releases the content key with a max-resolution cap derived from the robustness. If either is no, the server returns a license that decrypts only the lower-resolution renditions.

Here is the minimum production JavaScript for a 1080p-and-up service:

const config = [{
  initDataTypes: ['cenc'],
  videoCapabilities: [{
    contentType: 'video/mp4; codecs="avc1.640028"',
    robustness: 'HW_SECURE_ALL',
  }],
  audioCapabilities: [{
    contentType: 'audio/mp4; codecs="mp4a.40.2"',
    robustness: 'SW_SECURE_CRYPTO',
  }],
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
  .then(keySystemAccess => {
    // device certified for L1 HW_SECURE_ALL — 4K is permitted
  })
  .catch(err => {
    // fall back to a less strict config (HW_SECURE_DECODE, then SW_SECURE_CRYPTO)
    // and adjust the available renditions in your manifest accordingly
  });

The pattern is try strict first, fall back if rejected. Never start with the loosest config; you will leak 1080p to L3 viewers and you will hand desktop Chrome a free upgrade your studio contract does not permit. The same logic applies to native Android, where the level query is exposed via MediaDrm.getPropertyString("securityLevel") and returns one of the strings "L1", "L2", "L3" directly — no robustness mapping required.

The Pipeline Inside L1: TEE, Secure Video Path, and HDCP

The phrase "all three operations happen inside a TEE" hides four pieces of infrastructure that have to exist on the chip before any of it is true. They are worth a short tour because every one of them is a place L1 can fail and silently fall back to L3.

1. Verified boot. When the device powers on, a small piece of code in the silicon (the "boot ROM", literally read-only memory burned into the chip at the foundry) checks a signature on the bootloader before running it. The bootloader checks the signature on the kernel; the kernel checks the signature on the system image; the system image checks the signature on the Widevine TEE binary. If any signature fails, the chain breaks and the device refuses to load the next stage. The signature keys are held by Google and the device manufacturer jointly. Without verified boot, there is no L1. This is the single biggest reason rooted Android phones lose L1 — root requires an unlocked bootloader, an unlocked bootloader breaks the verified boot chain, and Widevine sees the broken chain and demotes the device to L3 on the next boot. The Widevine documentation on integration.widevine.com and the Android Verified Boot specification describe the exact chain on each platform.

2. The TEE itself. On ARM-based devices (almost every Android phone and almost every Smart TV), the TEE is an ARM TrustZone-enforced secure world that runs in parallel with the regular operating system. The CPU itself has two modes — "normal world" and "secure world" — and the chip silicon enforces that normal-world software cannot read secure-world memory. Switching from one mode to the other goes through a single instruction called the Secure Monitor Call (SMC) (described in the ARM TrustZone Technical Reference). When the Widevine CDM in normal world needs the secure world to decrypt a license, it issues an SMC and the encrypted license, and the secure world returns the content key handle — never the key itself. The key never crosses the boundary. On x86-based devices (Chromebooks, some Windows ARM devices) the equivalent is Intel SGX or AMD SEV; the principle is the same.

3. The secure video path. Once a video sample is decrypted inside the TEE, the decoded YUV pixels go to the display through a hardware-isolated bus that the host operating system cannot tap. On Android this path uses the GPU's secure surface, on Apple TV it uses the FairPlay-restricted CoreMedia path. The OS never sees the pixels; a screen capture tool returns a black rectangle. The secure video path is what separates L1 from L2 — L2 has the TEE but lets the decoded pixels leak back to normal memory.

4. HDCP on the output. When the decoded frame finally leaves the chip on an HDMI cable, it is re-encrypted with High-bandwidth Digital Content Protection (HDCP) before being sent over the wire. HDCP 2.2 is required for 4K from most major studios; HDCP 1.4 is sufficient for 1080p. The receiving TV decrypts and displays the frame. If the HDMI cable's path includes an HDCP-non-compliant device (a cheap HDMI capture box, a non-compliant AV receiver), HDCP authentication fails and the source returns 480p or a black screen. This is why "I plugged in a 4K receiver and Netflix dropped to SD" is a common help-desk ticket — the receiver is HDCP 1.4 only.

The five-layer stack is the entire reason L1 is hard to attack: an adversary has to break verified boot, escape the normal-world OS into the secure world, defeat the TEE's memory isolation, tap the secure video path, and strip HDCP — all without the chip noticing and revoking its keys. Each layer is a separate research project. The combined attack surface is small enough that public, reproducible L1 attacks have not appeared since Widevine moved from version 4 to version 5 (the modular DRM architecture) in 2014.

Figure 3. The L1 pipeline. Each box on this diagram is a place an attacker would have to break.

Why L3 Is Cheap, Useful, and Doomed to 720p

L3 is the level you get when you take Widevine and remove the chip support. It runs anywhere a regular CPU does — every Chrome browser on every laptop on every operating system. The CDM is a single shared library (on Windows it ships as widevinecdm.dll; on macOS it is a .dylib inside Chrome's Frameworks directory) loaded into the browser's process address space.

The protection is white-box cryptography: the AES and RSA implementations inside the CDM are constructed so that the keys are mathematically interleaved with the algorithm's lookup tables, with the intent that a reverse engineer reading the binary cannot point at any bytes and say "those are the keys". The technique was introduced in academic literature by Chow et al. in 2002 and has been the subject of a steady stream of break papers ever since. The single most influential public break was David Buchanan's 2019 Differential Fault Analysis (DFA) attack, which extracted the L3 master keys from a desktop Chrome CDM and was released as the widevine-l3-decryptor tool. A year later, Tomer Hadad demonstrated an updated attack on a refreshed CDM build using an RSA-side-channel. Both researchers reported their findings to Google; Google rotated the CDM keys and re-issued the CDMs. The cycle is ongoing.

This is exactly why studios cap L3 at 720p (and often at 540p or 480p). The actual numbers vary by studio contract — Netflix is famously the strictest, allowing only 720p in L3 contexts even when the browser claims SW_SECURE_DECODE; Amazon Prime Video and Disney+ allow 720p but cap audio at stereo; smaller services allow 1080p in L3 on bring-your-own-license deals. The single useful generalisation: if a viewer is on desktop Chrome, do not advertise 1080p in your manifest unless your studio contract permits it and your license server is configured to release 1080p keys to L3.

A separate paragraph for the operational reality: even though L3 is "cracked", in 2026 the practical piracy cost of L3 content is very low. A pirate who wants HD-quality leaks of 1080p content goes for HDMI capture from a hardware Smart TV (an analog-hole equivalent for the digital age) rather than fighting white-box AES. The L3 protection is good enough to deter casual sharing — copying a stream off Chrome to a friend is hard for a non-technical user — and that is the threshold most studios are happy with for 720p.

Where the Level Actually Lives: the License Server Conversation

Three actors decide a viewer's effective security level: the device, the license server, and the content owner's policy. Their conversation is short.

Step 1. The device boots, the Widevine TEE binary loads, and Widevine queries the chip's secure-world identity (the Widevine Provisioning Server, called WVPS, issued a device certificate to this chip at manufacture). The CDM remembers the level the chip is certified at — L1, L2, or L3.

Step 2. The application calls requestMediaKeySystemAccess with a robustness string (or, on Android, with no string at all — the MediaDrm framework reports the device level directly). The browser maps the robustness string to a requested level and confirms the device meets it.

Step 3. Playback starts. The player parses the manifest (HLS or DASH), encounters an encrypted segment, and asks the CDM for a license. The CDM generates a license request that includes (a) the content's key identifier (KID, from the tenc box — see our CENC in depth article), (b) the device certificate, and (c) the requested robustness. The CDM signs the request with the device's private key and sends it to the license server.

Step 4. The license server validates the device certificate (revocation list check), validates the requested robustness against the device's certified level, and checks the content policy — a set of rules attached to the content key in the server's database. The content policy is where studio contracts live: "this key may be released to L1 devices for 4K, to L1 devices for 1080p down-rezzed if no HDCP, and to L3 devices for 720p capped, and to nothing else." The server picks the highest robustness the device can offer that the policy allows, builds a license, encrypts it with the device's public key, and returns it.

Step 5. The CDM decrypts the license inside the TEE (L1) or in normal memory (L3), extracts the content key, and feeds it to the decoder. Playback begins.

The mistake every team makes the first time is treating "the device is L1" as enough. The device being L1 is necessary but not sufficient. The license server also has to be configured to release L1 licenses, the content policy has to permit the resolution the player is asking for, and the manifest has to list the right KID (one key per resolution tier is the production pattern — see the Common mistakes callout below). Get any of those wrong and the same L1 device that played 4K yesterday plays 480p today.

Common Mistakes (And How to Catch Them Before Production)

Pitfall: one content key for all resolutions.
If you encrypt the 240p, 480p, 720p, 1080p, and 4K ladder with the same KID, the license server has only one decision to make: release the key or don't. That means an L3 device that successfully decrypts 720p has automatically decrypted the 1080p and 4K renditions too — because the same key unlocks all of them. The fix is one KID per resolution tier (240p–720p share KID_A; 1080p uses KID_B; 4K uses KID_C), so the license server can release KID_A to L3 devices while withholding KID_B and KID_C. This is the production default at every major OTT operator; the DASH-IF guidelines describe it as "multi-key per asset".

Pitfall: leaving robustness empty.
A web app that omits the robustness field in its EME config will get whatever the browser chooses to give it, which is almost always SW_SECURE_CRYPTO (L3). The L1 phone in the viewer's hand stays at L3 because the website never asked for L1. Always set robustness explicitly and fall back step by step.

Pitfall: assuming Android always reports L1.
Rooted phones, unlocked bootloaders, custom ROMs, and tampered firmware demote the device from L1 to L3 silently. The MediaDrm.getPropertyString("securityLevel") call is the only way to be sure; never trust the manifest's resolution to be deliverable just because the OS version is recent. The free DRM Info app on Google Play reports the level for an end-user; for QA, instrument it via Android's MediaDrm API.

Pitfall: requesting HW_SECURE_ALL on a Chromecast Audio.
The requestMediaKeySystemAccess promise rejects if the device cannot meet the requested robustness. A request for HW_SECURE_ALL on a low-end Android TV (it might be L1 for video, but not for the secure surface path) rejects entirely and your player falls back to "no DRM available" instead of "L1 down-rezzed". Always handle the rejection by retrying with the next-lower robustness, not by aborting playback.

Where Fora Soft Fits In

We have built and operated Widevine-protected OTT video, video conferencing, and telemedicine platforms across the seven verticals we ship into — streaming, OTT/Internet TV, WebRTC, video surveillance, e-learning, telemedicine, and AR/VR — since the modular Widevine architecture launched in 2014. The work that earns its money is rarely "integrate Widevine"; it is the device-by-device QA matrix that proves a 1080p Smart TV in the customer's bedroom and an L3 desktop Chrome on the customer's laptop both behave correctly, the license-server policy work that translates a 14-page studio contract into 40 lines of policy JSON, and the production-grade fallback ladder that does not strand a viewer at a black screen when their bootloader is unlocked. We build those things as a default, not an extra.

What to Read Next

• Common Encryption (CENC) in depth — the tenc, pssh, and KID plumbing that ties Widevine, FairPlay, and PlayReady to one encrypted file.
• DRM 101: why three systems, and why you ship all three — the multi-DRM pillar; why Widevine alone is not enough.
• FairPlay Streaming in depth — Apple's parallel system, the only DRM Safari and tvOS will speak.

CTA

Talk to a streaming engineer — scope a Widevine-protected OTT launch with our team. · See our case studies — production OTT and telemedicine work shipped under Fora Soft's portfolio. · Download the Widevine level-detection checklist — a one-page reference for QA matrices, robustness fallback ladders, and license-server policy rules.

References

1. W3C Encrypted Media Extensions, Recommendation 18 September 2017 — the EME specification that defines requestMediaKeySystemAccess and the robustness string contract. Status: W3C Recommendation. Read directly from the W3C TR snapshot. (Standards body — Tier 1.)
2. ISO/IEC 23001-7:2023, Common encryption in ISO base media file format files (3rd edition) — the controlling document for the pssh, tenc, and KID boxes that carry Widevine identifiers in CMAF/MP4. Read the catalogue page (the normative PDF is paywalled). (Standards body — Tier 1.)
3. Android Verified Boot 2.0 documentation, source.android.com — the verified-boot chain that underpins Widevine L1 on Android. (First-party, Google — Tier 1 for Android-specific behaviour.)
4. ARM Architecture Reference Manual — TrustZone Technical Reference Manual (ARMv8-A) — the SMC instruction and normal-world / secure-world model that ARM TEEs use. (Standards body — Tier 1.)
5. Widevine integration console, integration.widevine.com (effective 17 December 2025) — the Google-operated portal that lists certified device security levels. Replaces partnerdash.google.com. (First-party, Google — Tier 1.)
6. Bitmovin, "Widevine Security Levels in Depth", developer.bitmovin.com — the most accurate vendor-published mapping of robustness strings to security levels. (First-party engineering blog — Tier 3.)
7. Bunny.net, "Google Widevine DRM" documentation — vendor mapping of device classes to security levels in 2025. (First-party engineering blog — Tier 3.)
8. G. Patat, M. Sabt, P.-A. Fouque, "Exploring Widevine for Fun and Profit", arXiv:2204.09298 (Univ. Rennes, IRISA, CNRS, 2022) — peer-reviewed reverse-engineering of the Widevine CDM. The most thorough public account of the Widevine protocol. (Academic — Tier 5.)
9. D. Buchanan, "Widevine L3 Decryptor", widevine-l3-decryptor GitHub mirror, 2019 — the public DFA attack on L3's white-box AES. (Open-source security research — Tier 5.)
10. Digital Content Protection LLC, "HDCP 2.3 Specification" abstract — the HDCP standard that protects the HDMI hop after L1 decoding. (Standards body — Tier 1.)