Information Rights Management and Persistent File Protection Guide: Control Files After They Leave

Once a file leaves your storage, access controls on the folder it came from no longer protect it. Information Rights Management (IRM), also called persistent file protection or enterprise digital rights management, encrypts the file itself and binds it to a policy that names who may open it and what they may do, so the protection travels with every copy. It is one of the few controls that still works after a file is emailed to a partner, synced to a personal device or exfiltrated. It also breaks search, data loss prevention, previews and automation if it is deployed carelessly. This guide explains how IRM works, how usage rights, offline access and revocation behave in practice, how to share protected files with partners, and how to roll it out without locking your own services out. It uses Microsoft Purview Information Protection as the worked example because its behaviour is well documented; the concepts apply to other IRM products. It is for data security engineers, information protection owners and architects. For choosing how to share files in the first place, see the Secure File Sharing Guide.

Key takeaways

• Protection is in the file, policy is on the server. IRM encrypts content and requires the reader to obtain a licence from the rights service, which checks identity and permissions each time a licence is issued.
• Revocation is only as fast as offline access allows. A revoked file can still be opened until any cached licence expires; Microsoft's default use licence validity is 30 days, so set offline access deliberately for sensitive labels.
• Usage rights are not a guarantee against a determined reader. Rights such as no print or no copy are enforced by compliant applications; anyone allowed to view content can still photograph the screen.
• Encryption hides content from your own tools. Without the right integration, search, eDiscovery and DLP see only metadata of encrypted files, so plan service access (for example a super user role) before rollout.
• The recovery role is a crown jewel. Whoever can act as rights super user can decrypt everything your tenant protected; keep it disabled or tightly held, and audit it.

How IRM works

All IRM systems follow the same pattern, whatever the vendor calls the parts:

1. Protect: the application encrypts the file with a content key and attaches a protected policy (who, which rights, expiry, offline rules). In Microsoft Purview this happens when a user or an auto-labelling policy applies a sensitivity label configured for encryption, using the Azure Rights Management service.
2. Distribute: the file can be copied, renamed, emailed or uploaded anywhere. Microsoft notes that encrypted content stays protected when renamed and is encrypted at rest and in transit.
3. Consume: a reader's application authenticates the reader to the rights service, which evaluates the policy and, if allowed, issues a use licence that lets the application decrypt the content and enforce the rights.
4. Control: the owner or an administrator can change the policy centrally, track access attempts and revoke access; changes apply when the next licence is requested.

Two points follow from this design. First, IRM is identity-dependent: if a reader cannot authenticate to your rights service (because of cross-tenant settings, Conditional Access or a personal account type you do not accept), they cannot open the file, however legitimate they are. Microsoft lists Entra cross-tenant access and Conditional Access as settings that can block authorised access. Second, the issuer always keeps full control; in Purview, the user who applies the label becomes the Rights Management issuer.

Designing protection policies

Admin-defined vs user-defined permissions

Usage rights and permission levels

Purview offers predefined permission levels, Viewer, Restricted Editor, Editor and Owner, or custom usage rights, and a single label can grant different permissions to different users or groups. Recipients can be all members of the tenant (excluding guests), any authenticated users, specific groups, specific users, or whole external domains. Keep to a small number of labels; each extra label is a decision users get wrong.

Expiry, offline access and watermarks

• Content expiry: a fixed date or a number of days after labelling. Microsoft recommends Never unless there is a genuine time-bound requirement, such as a bid document that should die after the tender.
• Offline access: Never, Always, or a number of days. Microsoft's guidance is 7 days for sensitive business data, Never for very sensitive data and dynamic watermarks, and Always for less sensitive content. Use licences are valid for 30 days by default, and changes to settings and group membership are evaluated only when a user reauthenticates.
• Dynamic watermarks: insert the viewer's identity on each page and persist when printed, which deters screen photography. Some features, such as Outlook attachment preview, will not open such documents.

Customer-held keys

For the small share of data where the organisation must hold a key the provider cannot use, Microsoft offers Double Key Encryption (DKE): content requires both a Microsoft-held key and a customer-held key hosted on the customer's own service. Microsoft frames DKE for roughly the most sensitive 5% of data and lists what stops working, including search, eDiscovery and DLP for DKE files in SharePoint and OneDrive, co-authoring, Office for the web, and Copilot access. Key ownership options more broadly are covered in the BYOK, HYOK and External Key Management Guide.

Sharing protected files with partners

Partner sharing is where IRM projects usually succeed or fail.

• Name the partner domain, not "anyone": granting rights to a partner's domain or a partner group gives revocable, auditable access. "Any authenticated user" protects against casual leaks but lets anyone with a supported account open the file.
• Agree identity first: partners must be able to authenticate to your rights service. Test with each partner's real tenant, cross-tenant access settings and device policies before sending live files.
• Check application support: partners need applications that understand your protection. Viewers on mobile or non-Windows platforms may support fewer formats.
• Write it into the contract: state that files will arrive protected, what partners may do with them, and that access will be revoked at contract end.
• Plan for offboarding: at the end of an engagement, remove partner groups from labels or revoke individual documents, and remember cached licences keep working until offline access expires.

When a partner relationship is high volume and structured, a managed transfer platform with its own access control may be a better fit; see the Managed File Transfer (MFT) Security Guide.

Tracking and revocation in practice

Revocation is the feature most often oversold. In Microsoft Purview, document tracking and revocation:

• Covers Office files only: Word, Excel and PowerPoint, and documents must be registered for tracking, which happens when a labelled file is next opened in a supported app. Password-protected documents are not supported.
• Uses a ContentID: administrators find it with Get-AipServiceDocumentLog, view access attempts with Get-AipServiceTrackingLog, and revoke with Set-AipServiceDocumentRevoked (reversed with Clear-AipServiceDocumentRevoked). Users can revoke documents they protected from the Sensitivity menu.
• Is limited by offline access: if offline access is allowed, users can keep opening a revoked document until the offline period expires.
• Has copy gaps: a file downloaded from SharePoint or OneDrive gets a new ContentID, so revoking the original does not cover the downloaded copy; documents protected with admin-defined permissions lose their ContentID when uploaded there; and several attachments on one protected email share one ContentID, so revoking one revokes all.

The practical rule: for documents you may need to kill, set offline access to Never or a short period, and do not promise business owners instant revocation of every copy.

Keeping your own services working

Encryption that your security tools cannot read creates blind spots. Microsoft documents that, without SharePoint and OneDrive label integration, search, eDiscovery and Delve do not work on encrypted files, and DLP inspects only metadata of encrypted files. Exchange must be configured for Rights Management for search indexing and DLP on encrypted mail.

The usual answer is a service-level decryption capability. In Purview this is the super user feature: a super user always has Full Control over content the tenant protected, which supports leavers' files, re-protection, indexing and inspection by DLP and anti-malware services. It is off by default, enabled with Enable-AipServiceSuperUserFeature, and members are added with Add-AipServiceSuperUser or Set-AipServiceSuperUserGroup. Microsoft warns that global administrators can enable the feature and make themselves super users, and that usage logs show who decrypted a file but not that they were acting as a super user.

Where identity fits

IRM is an identity control as much as an encryption control: every open is an authentication and authorisation decision. Three identity points deserve explicit design:

• Service identities that decrypt: indexing services, DLP scanners, eDiscovery tools and migration scripts that hold super user or equivalent rights are non-human identities with access to everything protected. Give each its own identity, store its credentials in a vault, and monitor its use. See the Secrets Management Guide.
• Privileged administrators: treat the rights administrator and super user roles as privileged access, with just-in-time activation and review.
• External identities: partner accounts used to open files should be governed like guests: reviewed, expired and removed when the engagement ends.

Rolling out IRM

1. Classify first. Agree a label taxonomy and decide which labels encrypt. The Data Classification Guide covers taxonomy design.
2. Enable service integration. Activate the rights service, enable SharePoint and OneDrive label integration and Exchange support, and decide how DLP, eDiscovery and backup will read protected content.
3. Pilot with one team and one partner. Use non-encrypting labels first, then encrypting labels for a small group, including at least one external partner and mobile users.
4. Test break points. Previews, mobile apps, scanners, workflow automation, AI assistants, backup restore and legal hold export; document what stops working.
5. Set offline and expiry per label. Short or no offline access for the most sensitive labels, longer for routine confidential data.
6. Expand by department. Roll out label by label, with training and a support route for "cannot open" issues.
7. Keep a rollback path. Changing a label's encryption affects newly labelled items; existing files keep their protection unless relabelled. Plan bulk decryption with the super user role and Set-FileLabel if you need to unwind.

Decision guidance

Detection and measurement

Collect rights service usage logs, document tracking logs, label activity and administrative logs (Get-AipServiceAdminLog records super user changes) into your SIEM. Alert on super user feature enablement, new super users, bulk decryption, spikes in denied access attempts from unexpected locations, and label downgrades on sensitive files. Insider-driven exfiltration patterns are covered in the Insider Data Theft Guide.

Framework mapping

Common failure patterns

• Encrypt everything on day one: search, DLP, previews and automation fail, users switch to personal tools, and the programme is rolled back.
• "Any authenticated user" for confidential data: protection survives leaks to the public internet but not to anyone with a free account who receives the file.
• Promising instant revocation: offline access, downloaded copies and unregistered files mean revocation is partial.
• Super user left on with a broad group: one compromised administrator or service account can decrypt every protected file.
• Partners never tested: cross-tenant or device policies block legitimate partners, who then ask for unprotected copies.
• No plan for leavers: files protected with user-defined permissions by a departed employee cannot be opened without a recovery role.

Practitioner checklist

• Define a small label set and decide which labels encrypt, with owners for each.
• Enable SharePoint, OneDrive and Exchange integration before encrypting at scale.
• Set offline access and expiry per label, short or Never for the most sensitive.
• Test partner access with each partner's real identity configuration before go-live.
• Document what revocation covers and does not cover, and tell business owners.
• Keep the super user feature off or limited to named service identities, and alert on changes.
• Give every decrypting service its own monitored identity with vaulted credentials.
• Forward rights service, tracking and admin logs to the SIEM.
• Review label downgrades, super user events and partner access quarterly.

Standards and references

• Microsoft Learn: Restrict access to content by using sensitivity labels to apply encryption
• Microsoft Learn: Track and revoke document access
• Microsoft Learn: Configuring super users for Azure Rights Management
• Microsoft Learn: Double Key Encryption
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-21, AC-16, SC-28)
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Secure File Sharing Guide · Data Classification Guide · Data Loss Prevention (DLP) Guide · BYOK, HYOK and External Key Management Guide