We discussed about Scenario 1 and Scenario 2 in part 1 of this blog. Here we are going to discuss on Scenario 3 where User A (Tenant A) applies a User‑Defined Permissions (UDP) label to a document Grants Owner permission to User X (Tenant B), User X forwards the document to User Y (Tenant C) without applying any labels from the Tenant
User Y cannot open the document, Why User Y cannot access the document ?
The document remains encrypted using Azure Rights Management (RMS) with a fixed access control list created by User A. When a document is encrypted, access is restricted so that it can be decrypted only by users authorized by the label’s encryption settings (Refer – Apply encryption using sensitivity labels | Microsoft Learn). User Y is not listed in the RMS policy as a result authorization fails.
Forwarding alone does not modify the embedded RMS policy, does not evaluate email recipients. Even though user X is an owner which allows him/her access, allows re-sharing, but does not allow implicit delegation of rights.
In Scenario 2 why it worked is User X applied Encrypt‑Only to the email and as a result Attachments inherited email encryption, RMS dynamically authorized email recipients. When an Office attachment inherits encryption from an email message, recipients are authorized based on the email’s protection policy
In Scenario 3, No email encryption from User X, no new RMS policy, no inheritance and original protection remains intact.
Azure RMS enforcement depends on Identity authentication, Authorization in the RMS policy not on whether the recipient uses or applies labels themselves. In Scenario 3, User Y is authenticated, but not authorized and that’s why access denied.
Key Principles behind all scenarios,
- RMS evaluates access based on the encryption boundary, not the sharing method.
- UDP document uses static authorization
- Encrypt only email uses dynamic authorization
- Forwarding will not explicitly give permission delegation
- Scenario 3 behaves exactly like Scenario 1, not Scenario 2. The deciding factor is email encryption, not tenant, domain, or label usage. Without email‑level encryption, no new users are ever authorized unless given permission by original owner (User A)
Azure RMS / Microsoft Purview – Three Scenario Comparison
| Aspect | Scenario 1 Internal UDP Document | Scenario 2 External + Encrypt-Only Email | Scenario 3 External, No Email Label |
|---|---|---|---|
| Initial Protection Applied At | Document level (UDP) | Email level (Encrypt Only) | Document level (UDP) |
| Encryption Boundary | File | Message | File |
| RMS Policy Created When | At document protection time | At email send time | At document protection time |
| Policy Type | Static ACL (explicit users only) | Recipient-based dynamic policy | Static ACL (explicit users only) |
| Forwarding Impact | No re-encryption | Re-encryption occurs | No re-encryption |
| Attachment Inheritance | Not applicable | Inherits email encryption | Not applicable |
| RMS Policy Regenerated on Forward? | No | Yes | No |
| Transitive Permission Expansion | Not supported | Supported (via email policy) | Not supported |
| Cross-Tenant Support | If explicitly listed in ACL | Automatic (if allowed by org policy) | If explicitly listed in ACL |
| Authorization Model | Identity must exist in embedded ACL | Identity must exist in email recipient list | Identity must exist in embedded ACL |
| Expected Result | Access Blocked | Limited Access Granted | Access Blocked |
ACL – Access Control List
If encryption stays at the document, authorization stays static. If encryption moves to the email, authorization becomes dynamic.
Hope the above helps in understanding this distinction which is essential when designing Microsoft Purview sensitivity label strategies, cross-tenant collaboration models, and secure sharing workflows.
