Streaming video providers serving US consumers are projected to lose a cumulative $113 billion to piracy by the end of 2027. Much of the conversation around that loss focuses on illegal restreams and takedowns, but a growing share of it starts somewhere most platforms aren’t watching: the moment a player asks your license server for keys. Attackers have gotten very good at DRM key extraction, and if you haven’t thought about where your defenses against it should live, you’re far from alone.
The platforms that have started looking into it tend to land in one of two camps. Some want everything handled server-side so they don’t have to touch their apps. Others have watched server-only defenses get worked around and want verification at the endpoint. Both approaches have real merit. This post walks through each one, what it does well, and where it falls short, so you can make the call with a clear picture of the tradeoffs.
Why DRM can’t catch a cloned CDM on its own
DRM does its core jobs well. It encrypts content, validates device credentials, and issues licenses. What it was never designed to do is judge whether the client asking for a license is a real player or an extraction tool pretending to be one.
That blind spot matters because modern attacks go after the client device. Devices that decrypt in software are especially exposed because keys are handled in unprotected memory rather than a hardware-backed trusted execution environment.
Most key extraction attacks follow the same basic pattern. An attacker targets the content decryption module (CDM), the component that handles decryption on the device, and finds a way to make it work for them instead of for your player. With that foothold, they can get a valid license from your server and recover the content keys inside it. Once those keys are out, your content can be decrypted anywhere, outside any player you control.
The hardest part for defenders is that newer cloned CDMs are built against the same interfaces a browser or device expects. To your app and your license server, they can look identical to the real thing. So the real question is where in your architecture you can catch them.
What server-side authorization gets right
Server-side authorization means your license server decides whether to issue keys based only on what it can see in the request, such as the device certificate, the user and session, request history, and known-bad signals. One common tactic is maintaining allowlists and blocklists (sometimes called revocation lists) of device certificates or CDMs known to be compromised.
The biggest advantage is that server-side authorization is transparent to your client. You enable it on the server, and your apps don’t change. That means:
- No app releases. You don’t need to ship a new build across every platform or wait for users to update.
- Lower risk to playback. Nothing new runs on the device, so there’s less that could affect performance or user experience.
- Centralized control. Policy changes happen in one place and take effect immediately.
Server-side controls can also enforce some genuinely important best practices. A well-configured license server uses license tokens to bind each request to the specific device, user, and session that initiated it, and treats requests as single-use so a captured request can’t be replayed for a second set of keys. In our platform assessments, replayable requests came up repeatedly, so if your server doesn’t block them today, it’s worth fixing no matter which direction you take.
If your team is stretched thin, or your app release cycle is slow, these are strong reasons to want a server-side approach. They’re valid concerns, especially if you support a wide range of devices, where every app update means another round of testing and releases.
Where server-side authorization falls short
Server-only protection has one structural limitation: the license server can only evaluate what the client sends it. If a cloned CDM presents a legitimate device certificate, the server has no independent way to confirm that the environment on the other end is genuine.
That limitation is why blocklisting tends to become a reactive cycle. Your team identifies a compromised device or CDM, adds it to the list, and the attacker moves on to one that hasn’t been flagged yet or creates their own. In our own testing against a blocklist-based approach, extraction tools were blocked effectively at first. Getting past it took extra work, but it was entirely feasible once we sourced a fresh CDM that hadn’t been blocklisted.
That work is also getting easier. Our testing was done without AI assistance, and attackers aren’t limited that way. AI tools can speed up the process of finding, adapting, and scripting around new device credentials, which shortens the window between “blocked” and “working again.” A defense that depends on spotting each new bad actor first will always be a step behind.
Session-based signals face a similar problem. Anything the server infers from request patterns can, with enough effort, be scripted to look normal.
What client-side hardening adds
Client-side hardening adds protected code to your app that checks the device for tampering and cryptographically signs each license request, so your license server can verify the request came from a legitimate client. The server checks that signature before issuing any keys.
Signing requests this way creates two-way trust. The server no longer takes the client’s word for it. Instead, it expects proof that only a legitimate, hardened client can produce. An extraction tool doesn’t have that protected code built in, so it can’t generate a valid signed request, and the server rejects it before keys are ever issued. It doesn’t matter whether the device certificate the tool presents has been blocklisted yet.
Two-way trust also raises the bar for attackers. Rather than hunting for an unflagged certificate, they have to defeat protections on the device itself. That added security does come with some upfront work, which is worth understanding before you decide.
What client-side hardening asks of you
Client-side hardening takes more upfront work than server-side authorization. You’re integrating an SDK into your apps, which means development time, testing, and app releases on each platform you protect. For teams with slow release cycles, that’s worth planning for. It’s also one reason some platforms weigh building their own protection versus buying it.
That upfront work tends to be more contained than teams expect. Hardening SDKs are typically built to integrate at the license request workflow, which keeps their footprint in your app small. Many also let you roll out gradually, starting with the platforms or content where you see the most risk.
The effort also pays off over time. Because client-side hardening doesn’t depend on maintaining an ever-growing list of known-bad devices, it needs less ongoing care as new exploits appear. You put the work in once, and the protection holds as attacks evolve.
Client-side vs. server-side DRM protection, side by side
| Server-side authorization | Client-side hardening + server verification | |
| Deployment effort | Low; enabled on the server | Higher; SDK integration and app releases |
| Impact on client apps | None | Small SDK integration focused on license requests |
| Detects cloned CDMs with valid certificates | Only after they’re identified and blocklisted | Yes, unsigned requests are rejected up front |
| Dependence on known-bad lists | High | Low |
| Main tradeoff | Easy to deploy, but reactive to new threats | Stronger client verification, more upfront work |
So where should your DRM controls live?
Server-side authorization on your license server gives you centralized policy, session binding, and replay protection. Client-side hardening gives that server something it can’t get on its own: verified evidence that each request came from a legitimate environment. Used together, each covers the other’s blind spot.
Which approach you prioritize depends on your situation. A few questions can help you decide:
- How much of your audience plays on software-decryption devices? The more playback happens outside hardware-backed environments, the more exposed you are to cloned CDMs.
- How valuable is your content to pirates? Live sports, premieres, and exclusive catalogs attract more determined attackers.
- How often do you ship app updates? If you release frequently, anything you add to the client has to fit into that rhythm without slowing it down or adding risk to each release.
If you’re evaluating client-side hardening, start with how much of your app it touches. Look for an SDK that’s small and self-contained, one that sits alongside your player instead of inside its core logic, so it doesn’t add regression risk or extra testing to every release. Make sure it supports the device platforms where you actually see extraction activity. Confirm it works with your existing multi-DRM provider, including in-house systems, and that you can roll it out gradually.
How exposed is your platform?
When we assessed platforms’ DRM license security over a recent three-month period, roughly two-thirds showed gaps such as replayable requests or no way to distinguish a cloned CDM from a real one. You can watch the full webinar for a deeper walkthrough of those findings and the attack chain, or request a complimentary vulnerability assessment. Our team will test your platform using the same techniques attackers use and give you clear evidence of what we find.
Frequently asked questions
Is server-side DRM protection enough to stop key extraction?
Server-side protection on its own can slow key extraction down, but it can’t reliably stop it. Because the license server only sees what the client sends, a cloned CDM using a legitimate device certificate can pass as a real player until it’s identified and blocklisted. Adding client-side hardening closes that gap by letting the server verify the client itself.
What is a compromised or cloned CDM?
A compromised or cloned CDM is a content decryption module that has been modified or rebuilt so it hands decryption keys to an attacker instead of keeping them protected. Newer cloned CDMs use the same interfaces a browser or device expects, so apps and license servers often can’t tell them apart from legitimate ones.
Does client-side hardening affect video playback?
It shouldn’t have a noticeable impact if it’s well designed. Look for an SDK that integrates at the license request workflow, where verification happens during license issuance and the added time should be measured in milliseconds.
Can I add client-side hardening without switching DRM providers?
Yes, as long as the solution is built to sit above your DRM rather than replace it. When you compare options, check whether they support your current multi-DRM provider, including in-house systems, and whether they can be self-hosted if you need that.