How Azure Rights Management Works

Author Name
Yoshi Munchakoopas
  • Author Name
  • Author Name
  • Author Name


One important thing to understand about how Azure RMS works is that the Rights Management service (and Microsoft) do not see or store your data as part of the information protection process. Information that you protect is never sent to or stored in Azure unless you explicitly store it in Azure or use another cloud service that stores it in Azure. Azure RMS simply makes the data in a document unreadable to anyone other than authorized users and services:

At a high level, you can see how this process works in the following picture. A document containing the secret formula is protected, and then successfully opened by an authorized user or service. The document is protected by a content key (the green key in this picture). It is unique for each document and is placed in the file header where it is protected by your RMS tenant root key (the red key in this picture). Your tenant key can be generated and managed by Microsoft, or you can generate and manage your own tenant key.

Throughout the protection process when Azure RMS is encrypting and decrypting, authorizing, and enforcing restrictions, the secret formula is never sent to Azure.

For a detailed description of what’s happening, see the Walkthrough of how Azure RMS works: First use, content protection, content consumption section in this topic.

For technical details about the algorithms and key lengths that Azure RMS uses, see the next section.

Cryptographic Controls

Even if you don't need to know yourself how RMS works, you might be asked about the cryptographic controls that it uses, to make sure that the security protection is industry-standard.

Algorithm Key Length
Documentation Protection Method AES 128 bits and 256 bits
Key Protection Method RSA 2048 bits
Certification Signing SHA-256

256 bits is used by the Rights Management sharing application for generic protection and native protection when the file has a .ppdf file name extension or is a protected text or image file (such as .ptxt or .pjpg).


To understand in more detail how Azure RMS works, let's walk through a typical flow after the Azure RMS service is activated and when a user first uses RMS on their Windows computer (a process sometimes known as initializing the user environment or bootstrapping), protects content (a document or email), and then consumes (opens and uses) content that has been protected by somebody else.

After the user environment is initialized, that user can then protect documents or consume protected documents on that computer.


If this user moves to another Windows computer, or another user uses this same Windows computer, the initialization process is repeated.

Initializing the user environment

Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content:

The RMS client on the computer first connects to Azure RMS, and authenticates the user by using their Azure Active Directory account. When the user’s account is federated with Azure Active Directory, this authentication is automatic and the user is not prompted for credentials.

After the user is authenticated, the connection is automatically redirected to the organization’s RMS tenant, which issues certificates that let the user authenticate to Azure RMS in order to consume protected content and to protect content offline. A copy of the user’s certificate is stored in Azure RMS so that if the user moves to another device, the certificates are created by using the same keys.

Content protection

When a user protects a document, the RMS client takes the following actions on an unprotected document:

The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

The RMS client then creates a certificate that includes a policy for the document, either based on a template or by specifying specific rights for the document. This policy includes the rights for different users or groups and other restrictions, such as an expiration date.

The RMS client then creates a certificate that includes a policy for the document, either based on a template or by specifying specific rights for the document. This policy includes the rights for different users or groups and other restrictions, such as an expiration date.

Finally, the RMs client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document. This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

Content Consumption

The authenticated user sends the document policy and the user’s certificates to Azure RMS. The service decrypts and evaluates the policy, and builds a list of rights (if any) the user has for the document.

The service then extracts the AES content key from the decrypted policy. This key is then encrypted with the user’s public RSA key that was obtained with the request. The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. This lets the RMS client decrypt the document’s body as it is needed and render it on the screen. The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.


The preceding walkthroughs cover the standard scenarios but there are some variations:

Next Steps


For additional information and help, use the resources and links in Information and Support for Azure Rights Management.