How are sensitivity labels stored in PDF files? How is encryption handled when documents are exported from Office to PDF? And what about the archival format PDF/A? Let’s take a deep dive into the PDF format.
A short introduction to PDF
Unlike Office documents, which are essentially ZIP containers with a folder structure of XML files, a PDF is built as a single binary file. This binary file consists of a series of objects that reference each other through object numbers, and PDF readers interpret these objects sequentially to render the document visually.
In the PDF standard, content is organized into different object types, including:
• /Catalog – the top-level object describing the document structure
• /Pages – a list of all pages
• /Page – a single page
• /Contents – drawing instructions for the page (text, graphics, layout)
• Streams – binary data blocks used for text, images, and attachments
PDF files also include a dedicated metadata layer based on XMP (Extensible Metadata Platform). XMP metadata is stored as XML inside the PDF file and is used to describe document properties such as title, author, timestamps, and technical metadata. Microsoft stores its sensitivity label information in this XMP layer, using a dedicated namespace called pdfx. This allows information about which sensitivity label was applied to be read directly from the file, even when the document content itself is encrypted.
How encryption is implemented in PDF
When a PDF file is encrypted using a sensitivity label from Microsoft Purview Information Protection (MIP), Azure Rights Management (RMS) performs the actual encryption. The PDF file is given an additional layer consisting of a wrapper page and an encrypted payload. The wrapper page contains, among other things, the message shown in PDF readers that do not support MIP, while the original document is stored in an encrypted stream. This stream can only be decrypted by PDF readers with MIP support, which are able to retrieve the decryption key from the tenant where the encryption was applied.
Example – opening an RMS-encrypted PDF file
Let’s start by creating a new document in Word and applying the sensitivity label “Confidential”. The label is configured with access control, where all tenant users have editor permissions. This configuration means that when a user applies this label to a document, the document is encrypted and only users in the same tenant can decrypt and read the content.
Once the document is labeled as confidential, we export it to PDF. This should be done on a Windows device, as macOS (at the time of writing) cannot export encrypted documents to PDF. We now have a PDF file that we can examine.
If we attempt to open the PDF file in Brave or Chrome, we see the following text (in norwegian though):
This is the informational text stored in the unencrypted part of the PDF file. The text is hardcoded into the file and is displayed when the PDF reader does not support MIP. The actual document content (the text written in Word) is encrypted in a separate stream. As shown, the browser is not able to retrieve the decryption key from the tenant where the document was created. Of course, Microsoft Edge supports MIP natively.
What happens if we use a PDF reader that supports MIP? One such reader is Adobe Acrobat Reader DC. After installing the application and opening the PDF file again, we are prompted to sign in:
After entering the email address of a user in the same tenant, we can approve the authentication request. Once this is completed, the encrypted content of the PDF file is displayed. As shown, the document content remains protected even after being exported to PDF. This is exactly what we want—the protection should follow the content, not the file format.
The dialog itself is displayed by Adobe Reader, but authentication is performed through Microsoft’s authentication library (MSAL) against Entra ID. After sign-in, Adobe Reader retrieves an RMS license from the user’s tenant and uses that key to decrypt the PDF file locally. This is why the document can only be opened by users who have permissions in the relevant tenant.
…but what about PDF/A?
PDF/A is widely used as a long-term archival format by public-sector organizations and archival authorities in many countries. The format is defined in ISO 19005 and is designed to ensure long-term preservation, software independence, and self-contained documents. A key requirement of PDF/A is that it does not allow encryption or any form of access control. As a result, documents that are encrypted using Azure Rights Management (RMS) cannot be exported directly to PDF/A unless the encryption is removed first.
Word for Windows can export documents to PDF/A, but if the document is RMS-encrypted, it must first be decrypted. The result is therefore always an unencrypted PDF/A file, and the MIP protection does not carry over. If the user does not have rights to decrypt the document (for example, is not an owner), the document cannot be exported to PDF/A at all.
This is important, because RMS-encrypted files are not suitable for long-term archival in records management systems. To avoid encryption-related issues, many public sector organizations choose not to apply encryption to sensitivity labels. Instead, they rely on compensating controls such as DLP policies.
PDF deep dive
Let’s explore metadata and PDF objects in more detail. We start by extracting XMP metadata from a couple of PDF files using exiftool. Below we can see metadata from both an unencrypted PDF file and an RMS-encrypted PDF file:
We can clearly see that the file encrypted-pdf.pdf is RMS-encrypted. Such a PDF file has a ContentBits value of 9, while an unencrypted PDF file has a value of 0. In addition, an RMS-encrypted PDF file automatically receives the title “MicrosoftIRMServices Protected PDF.pdf”. This is not a title we have defined ourselves; it is added by MIP to indicate that the document contains protected content and can only be opened by PDF readers that support MIP.
But wait—what is IRMServices? We have so far discussed MIP and RMS. IRM is not a separate technology, but an older name that is still used in certain components when PDF files are encrypted with RMS. Adobe Reader and Microsoft’s own PDF components still refer to RMS encryption as “IRM Services”, as this was the original terminology before MIP was introduced as the overarching framework for labeling and protection. Even though the modern terminology is MIP for labeling and RMS for encryption, PDF metadata still uses “MicrosoftIRMServices Protected PDF.pdf” for encrypted documents. This is still RMS encryption—just using a historical name in the metadata. You can read more about metadata on Microsoft Learn under Microsoft Information Protection SDK – Metadata.
Now let’s continue by analyzing the PDF files at the object level. For this, we can use pdf-parser. This tool displays all objects, stream contents, and metadata. When analyzing an RMS-encrypted PDF file, we can clearly see the difference between the unencrypted wrapper page, which contains the message stating that the document is protected, and the encrypted payload, which is stored as a binary stream that cannot be accessed without decryption.
Let’s first examine an unencrypted PDF file. Here we see the same metadata as extracted earlier with exiftool (stored in object 3):
We can then inspect the document content itself (stored in object 5):
When examining the contents of an unencrypted PDF file, we do not see readable text in the same way it appears in Word. The PDF format does not store text as plain characters, but as a sequence of graphical instructions. Operators such as BT and ET mark the beginning and end of a text object, Tf sets the font, Tm defines the position on the page, and TJ renders the character sequence. This is completely normal and simply reflects the fact that PDF is a graphical page description format, not a document format with text strings like Word.
Now let’s examine an RMS-encrypted PDF file. Here we can see how the wrapper page is stored in the PDF (object 7):
The wrapper page (object 7) contains the text “This document uses encryption powered by Microsoft Information Protection…” in norwegian. While not immediately readable at first glance, the text “Dette dokument…” is represented by the following instructions:
[(De)22(t)-10(t)-10(e)23( )-25(d)-12(o)-15(ku)13(m)9(e)23(n)16(t)…] TJET
