Frequently Asked Questions

We have collated some key questions - and the associated answers - that deal with how Digital Rights Management (DRM) is used in the video services marketplace today. We hope you find it useful, but if you have addition questions for us please request us to add a topic at the bottom of this page.

  • What is DRM as a Service (DRMaaS)?
  • How is DRMaaS Managed?
  • Why is DRM useful to distribute video content?
  • What does video encryption protect?
  • What is watermarking?
  • What is MPEG-DASH and DASH-IF?
  • What is Common Encryption (CENC)?
  • What is CMAF?
  • Where does video encryption happen?
  • Should I use In-browser players or player applications?
  • Which browsers support DRM for video services?
  • What are Encrypted Media Extensions (EME)?
  • What is a Content Decryption Module (CDM)?
  • What is DRM hardware security?
  • What is a DRM license request?

When you are setting up a video service, there are many components to put into place. In past years, the deployment model was to invest in a specialist data center and racks of equipment to do video acquisition, video encoding, subscriber management, security and so on. The predominant model in today's market is to use an integrated suite of cloud-based components to provide the same functions - but without the fan noise!
Since DRM is a specialized area and needs specific attention to licensing and security, amongst other things, the model of access to a cloud-based service, that supports the DRM function you need, is a very convenient simplification of the overall deployment setup.
The benefits of using a service for DRM implementation include:

  • No capital costs - payment primarily on a transactional, periodic basis that scales with the use of the service.
  • Fast time to market - the infrastructure is already set up and only requires integration logic to tie to the rest of the service workflow.
  • Easy integration - well documented and fully tested templates.
  • Easy scaling - the management of the service includes the addition of resources as your viewership grows.
  • Access to specialist expertise when required - you always have someone available to keep things running at peak performance.

Fully managed means that you, as a service provider, do not need to be concerned about:

  • System setup - all initial service configuration and reporting management is undertaken as you set up your account.
  • Security - all system data is maintained in a fully hardened environment, so there is no concern over unauthorized access to key data or business critical transactions. Personally identifiable data is limited by design in order to comply with privacy regulations.
  • Monitoring - the management of service operation is covered by expert engineers on a 24/7/365 basis. Any issues that arise with operation or performance are flagged and resolved before becoming business critical.
  • Resilience - using state of the art cloud resource management techniques, resiliency and redundancy is automatically addressed. Issues that arise with communications or compute resources are resolved in real time.
  • Upgrades - an important part of this business is keeping up to date with the evolving technology. As the DRM versions from the various vendors evolve and new features are released the integrated service can be ready on day one.

Anyone in the business of commercial video distribution - in the enterprise or entertainment or education space - should be fully aware of the imperative to protect such video from unauthorized copying or re-distribution. If you don't have any protection in place, its hard to create a business around the video service.
The movie and TV industry is especially protective of their video assets and, if you try and license such assets for your service, they impose strict rules on distribution to ensure that appropriate security is in place. DRM solutions are the core of such protection mechanisms - and the DRM mechanisms are used to encrypt video before distribution AND control the distribution of the vital decryption keys to limit viewership to the intended devices and consumers. For more information on this, see our DRM Comparison page.
DRM requirements can vary with the quality (or value) of the assets being licensed. And these requirements can limit what content can be delivered across devices such as PCs, smart phones and tablets for example. In general, SD (480p) playback can utilize software-based DRM while HD (720p+) playback typically requires a hardware enhanced DRM implementation (see FAQ section on Hardware Security). Providing 4K/UHD quality content also requires hardware-secured DRM along with additional security requirements beyond DRM, including watermarking (see FAQ section on Watermarking).

Compressed video playback is universally supported on today's hardware devices. But the process of compression makes the video material exceptionally sensitive to alterations in its binary content. You can see that sometimes, when a video you are watching glitches somehow and dissolves into a mass of randomly colored pixels. Changes that cause this disruption - corruption if you like - can happen accidentally - when communication breaks down, for example. Or the video can be corrupted deliberately at it's source, by encrypting some or all of the content with a scrambling key. This is a very precise process using controlled scrambling key data and a well-defined algorithm. The whole concept of this process is that it is, of course, reversible.
The scrambled video content cannot be played back without reversing the process - which of course, requires access to the scrambling key or keys used for protection. To maximize security, a different scrambling key is often used for each time period and certainly for every individual video asset.
Scrambled/encrypted video content is essentially valueless without knowledge of how to reverse the encryption process. It can’t be played or redistributed. This is the essence of video security and why it is the core to the video service business.

When video content is watermarked - typically during encoding, but also potentially at time of individual delivery or even during specific device playback - it means that some form of copy identifier information (often termed a payload) is added to the video, which will be included in any copies that are made. The identifier payload is - by design - intended to be subliminal or imperceptible so that it does not interfere with the viewing experience. But because any potential illegal copies also carry the payload, watermarking provides an additional form of security mechanism that extends beyond the envelope of encrypted delivery. For more general information on video watermarking please refer to the Digital Watermarking Alliance

Adaptive Bitrate (ABR) streaming has been a core enabler of the streaming video revolution by offering a way to deliver a good user video experience across a wide variety of networks and device types. In April 2012, ISO, the international standards body which had already given us the core media foundations of MPEG-2, MP3 and MP4, finally ratified the version of an adaptive streaming standard: MPEG-DASH (DASH stands for Dynamic Adaptive Streaming using HTTP). The participating companies in the MPEG-DASH standardization (including Microsoft, Apple, Netflix, Qualcomm, Ericsson, Samsung, and many others) saw a vision of interoperability and convergence required for large-scale market growth in streaming video that trumped the prior emphasis on proprietary and competing streaming formats based around HTTP. They replaced multiple corporation-controlled solutions with a single industry-defined open standard.
Of course, a standard document typically only marks the beginning of the work of detailed interoperable usage - and so the baton for a lot of practical effort was passed to an industry forum to promote and catalyze the adoption of MPEG-DASH. The DASH Industry Forum (DASH-IF) is filled with member companies who are realists about the DASH deployment challenges. EZDRM is a member ofthe DASH-IF. Member companies are willing to take on the work of creating recommendations, filing bugs, and attending plug-fests and interop events, with the belief that their business and the Internet streaming market in large will benefit a great deal with convergence around the DASH format. For further information see

To try and help reduce fragmentation of the video delivery equipment and software market, a standardized algorithm for streaming video file encryption has been created. It is called Common Encryption (also referred to as CENC). CENC is an ISO 23001-7 standard ( that defines how encryption will be applied to different sections of a video file format and what scrambling algorithm will be used with the encryption key(s). Ultimately, the CENC format enables the same secure content to be distributed to numerous playback devices/platforms, all of which can use the defined algorithm to restore the content to playable form. What isn't standardized in CENC is how the scrambling keys themselves will be delivered to the playback device - this is left to the technology of distinct DRM clients in each device. Individual DRM clients retain responsibility for the security of aspects such as license distribution, rights mapping, and compliance which means these processes can be implemented in a proprietary fashion in individual DRM systems. See the FAQ section on License Delivery.

The Common Media Application Format (CMAF; officially MPEG-A Part 19 or ISO/IEC Standard 23000-19 - is a newer initiative that builds on MPEG-DASH standardization, but also attempts to reconcile the de-facto adaptive streaming standard (HLS as defined, implemented and evolved by Apple) with some of the DASH related advances and move the ball forward to a truly secure common file format that can be used as the origin of all streaming delivery.

In most streaming video workflows, the option to encrypt video is a processing step between the output of the video encoder and the input of the distribution platform. The operations that are often combined are the segmentation of video streaming into delivery packets, running the encryption algorithm over those packets and the building of a manifest file that references both the packets and the identifiers necessary for video players to request the decryption keys. The overall operation is sometimes termed packaging. When DRM is used, the keys are requested from the DRM service (which assures appropriate randomization etc.) and paired at that point with the identifiers to be used later at playback.
While it makes the most sense, from a security perspective, to have video stored in a protected format at the origin of a CDN for example, there are also examples of Just In Time (JIT) packaging systems where the various packaging steps are triggered by end device requests and where the process can adapt to specific device requirements.

How a given service chooses to present its video on any given device - and the accompanying elements of the service's user interface is a very important question, but one that sometimes has political as well as technical overtones. In general, downloadable apps are used for commercial video services on mobile devices, tablets and TVs, while desktop/laptop computers often use a browser environment. Offline playback also dictates the use of an app. There's a lot of debate over the merits of the two approaches in terms of user experience - considering startup time, service latency and device efficiency for example. The standardized video formats of MPEG-DASH were originally typically defined around the need for in browser consumption although the usage profile is very much a moving target at the present time.

Modern browser environments from different vendors on each consumer platforms have adopted the HTML5 principle of including support for video more or less directly as a part of their native code and then extending that support to provide mechanics for playback of DRM protected video (see FAQ section on EME). You should also refer to the table on our DRM comparison page.

Encrypted Media Extensions are a set of JavaScript API specifications that provide a method for the code of web pages to interact with DRM license servers and the built-in security mechanisms of browsers (see FAQ section on CDMs) to play back DRM protected video within a web page. A long-standing political battle has delayed formal standardization of these APIs by the W3C, but de-facto support exists in all commercial browsers. For more information, see the EME specification at

A Content Decryption Module is an implementation of proprietary DRM client code inside a browser that lies behind the standardized EME implementation. As originally conceived, any browser could support multiple CDM implementations, but politics and commercial rivalry has limited each of today's commercial offerings to support of a single CDM and therefore a single DRM format. Given the way that MPEG-DASH streams and the use of CENC interact, this is not as limiting as it may sound - but it is important to operate an MPEG-DASH video service alongside a Universal DRM service to provide a seamless consumer playback experience.

DRM functionality in devices can be supported wholly via software by building it into a device’s operating system or a library module. Some devices have DRM clients that have been integrated in a way that uses security features of the underlying chipset. This provides a ‘hardware protection’ layer to the logic of the DRM client and protects any decryption keys or unencrypted video from being intercepted by malicious code running in parallel with the DRM client software. The hardware support is offered by ARM TrustZone or another secure processor element at the device level. The details of how security is implemented at this level are beyond the scope of this FAQ, but fundamentally tie to a hardware implemented, individualized shared secret related to the identifier of the chipset. Hardware root of trust is another way you may hear someone refer to hardware DRM.

Without going to far into the details of video player logic, the video content itself is scrambled using one or more encryption keys (see FAQ section on video encryption) which are not stored within the video. The video content does contain an identifier of both the DRM system or systems, where the key can be obtained, and an identifier, a KeyID, that can be used to select the right key from that DRM system.
Simply put, the video player process recognizes the need for a key and requests the local DRM client code to obtain that key. The security of the keys would be easily compromised if the communication between DRM client and the DRM key service was not heavily protected, so the keys are frequently delivered in the form of an encrypted object known as a license. Its convenient to include in this license object some rules about the restrictions on use of the keys (such as a rental period etc), but for the most part the license simply is a way to deliver the requested key information - which is then processed by the DRM client and offered to the video player process to enable viewing. Check out our Demos to see this process in action.

If you have questions we did not answer? Please let us know and we will be happy to answer it for you.