SharePoint Permissions vs File Encryption

The Two Completely Different Mechanisms

Every file sitting in SharePoint, OneDrive for Business or Teams is governed by two distinct protection layers, and they are easy to confuse because Microsoft's UI presents them in the same dialog.

Layer one: permissions (ACLs). SharePoint stores every file in a library, and every library has a permission list mapping Azure AD identities to roles (Read, Contribute, Design, Full Control). When you double-click a file, your browser asks the server "please send me this file", the server checks your identity against the ACL, and either streams the file bytes or refuses with a 403. The file itself on SharePoint storage is not encrypted with a user-specific key — the server holds ordinary encryption at rest (BitLocker on the datacentre disks) but not per-file, per-user encryption. This is access control, full stop.

Layer two: Sensitivity Labels / MIP / Azure Rights Management. On top of ACLs, Microsoft 365 offers an optional label system that wraps individual files in genuine AES-256 encryption using a tenant-controlled key. When you open a labelled file, Office contacts Microsoft's rights management service, validates your identity token against the label's policy, and receives a decryption token. The file remains encrypted at rest and encrypted in transit; the key is released only at the moment of use and only to an authorised identity.

If a file has only Layer 1 protection (SharePoint permissions), an admin with tenant access can give you a copy by adjusting the ACL. If a file has Layer 2 (Sensitivity Label) protection, the encryption travels with the file — you can email it, copy it to a USB stick, paste it on a personal drive, and it still will not open without an authorised Azure AD identity. These are different worlds with different recovery paths.

Layer 1: How SharePoint / OneDrive Permissions Actually Work

SharePoint's permission model descends from the classic Windows NT access control list. Every object (site, library, folder, file) has an ACL that lists principals (users and groups) and the role they are granted. Roles stack — a user can be a member of "Contoso Finance" which has Contribute on the library, and also be individually granted Full Control on one specific file, and the final decision is the union.

When someone "shares" a file with you through the green Share button, SharePoint adds a new entry to that file's ACL. The entry can grant "Can view" (read-only) or "Can edit" (read-write), and can be scoped to a specific person, a group, or anyone with the link. The file bytes on disk do not change when the ACL changes. If you lose access it is because an entry was removed, not because any cryptographic key expired.

The consequence: if you own a OneDrive and a colleague had read access to a workbook you kept there, and you revoked their access, there is nothing to "recover" — the file was never in their possession to begin with. They were viewing it through the SharePoint web viewer, which renders the file live from the server. No plaintext copy ever existed on their disk unless they explicitly downloaded one.

When the front-end says "View only" it is a mild setting. The user can read the file in browser view, but cannot use File → Download, cannot Copy the content, and cannot open in desktop Office. These restrictions are enforced by the SharePoint viewer, not by encryption. A determined user could screenshot or retype the content; the only enforcement is UI-level.

Layer 2: Sensitivity Labels (MIP / AIP / IRM)

Microsoft Information Protection is the umbrella term for the current generation of document encryption and classification. It evolved from the earlier Information Rights Management (IRM) built into Windows RMS and SharePoint, and from Azure Information Protection (AIP) which Microsoft bought in 2015. As of 2026 the shipping product is Sensitivity Labels, configured in the Microsoft Purview compliance portal.

A Sensitivity Label is a policy that an admin defines centrally and that users or automation can apply to documents. Typical labels include "Public", "Internal", "Confidential", "Highly Confidential", and custom variants. Each label can specify:

• Encryption. Apply AES-256 with a tenant-held key. Choose who the file decrypts to (specific people, a group, the entire tenant, or "do not forward").
• Content marking. Visual headers, footers and watermarks stamped on the document body.
• Data-loss-prevention (DLP). Rules for Exchange, SharePoint, Teams about what the file can and cannot do — attach to outgoing mail, upload to consumer storage, share with external recipients.
• Conditional access. Require managed device, MFA, location, or session restrictions at the moment of opening.

When Layer 2 encryption is active, the file has real AES-256 applied with a random content key, and the content key is wrapped with the tenant's RMS public key. The wrapped content key, plus the label policy, is embedded in the file itself. Opening the file requires your Office client to contact the tenant's RMS endpoint, present your Azure AD token, pass the policy check, and receive the unwrapped content key.

Because the content key is wrapped with the tenant's key rather than a user password, there is nothing for a recovery service to brute force. The security is not in guessing a user-chosen string; it is in possessing a valid token against a centrally-held key. That model is the opposite of the Excel-password world where a user typed a string and the whole security of the file depends on how long and random that string was.

"Do Not Forward" and "Encrypt Only"

Two quick labels that users interact with daily:

Do Not Forward (DNF). Applied commonly to email by clicking Options → Encrypt → Do Not Forward. The recipient can read the message and attachments but cannot forward, print, or copy content. Attachments are themselves wrapped with AES; removing them from the email and saving locally preserves the encryption. The enforcement continues on the recipient's disk.

Encrypt Only. Encrypts the message and attachments for the recipient but allows normal forwarding, printing and copying. The encryption persists on the recipient's side, so an accidentally-forwarded message stays encrypted for the next hop, but the policy does not actively block the forward.

Both labels require Azure AD authentication every time the recipient opens the file. An external recipient without an Azure AD account can still open DNF/Encrypt-Only content by going through a Microsoft one-time passcode flow against their email — Microsoft sends a code, they type it in, Office authenticates them temporarily. This is how cross-tenant and personal-email recipients access labelled files.

How Admins Recover Access: Super-User Mode

Azure Rights Management includes a "super-user" role that can decrypt any labelled document in the tenant. It is disabled by default — deliberately, because granting it is a serious compliance decision — and enabling it requires a Global Admin to run PowerShell against the RMS service:

# Connect to AIP / Purview
Install-Module AIPService
Connect-AipService

# Enable super-user feature
Enable-AipServiceSuperUserFeature

# Grant super-user rights to a specific admin account
Add-AipServiceSuperUser -EmailAddress legal-admin@contoso.com

# When done
Remove-AipServiceSuperUser -EmailAddress legal-admin@contoso.com
Disable-AipServiceSuperUserFeature

Once super-user is active, the designated admin can open any labelled file in the tenant regardless of the original access list. Typical use cases:

• Departing-employee recovery. An employee leaves and their account is disabled. Files they labelled under their own permission list become inaccessible. Super-user mode lets IT reassign them.
• Legal discovery / eDiscovery. A subpoena requires producing documents. Super-user + eDiscovery tools pull everything.
• Compliance investigations. Reviewing suspicious activity by an account holder.
• Disaster recovery. A misconfigured label policy locks everyone out. Super-user unlocks and the admin fixes the policy.

All super-user actions are audited to the Microsoft 365 audit log and the tenant RMS log. This is by design: super-user is a break-glass capability, not a daily-use tool, and a Global Admin who enables it leaves an immutable trail.

The Decision Tree for "I Cannot Open This File"

1. Does the browser / desktop client say "You need permission to access this item"? Layer 1 issue. Contact the owner. No encryption involved.
2. Does the file say "This item has a sensitivity label"? Layer 2. If you can still open it, no action needed. If you cannot, see the next step.
3. Does Office say "You do not have permission to open this file"? Layer 2 denial. You are not on the label's recipient list. Contact the sender or a tenant admin with super-user rights.
4. Does Office say "Your organisation does not allow opening this file"? Layer 2 + Conditional Access. Either you are on an unmanaged device, off the corporate network, or your token has expired. Sign in again, connect via VPN, or use a managed device.
5. Does Office show the yellow Protected View banner? Neither layer. See our Protected View explainer.
6. Does Office show a password dialog? Document-level AES encryption, separate from Layer 1 and Layer 2. This is the only case where a recovery service can help. See our Excel password recovery guide.

What a Recovery Service Can (and Cannot) Do

Our service handles the one case on the list above where the security model is a user-typed password — document-level AES encryption, applied by File → Info → Protect Document → Encrypt with Password. We cannot help with:

• SharePoint permission denials. Not an encryption problem. Contact the owner.
• Sensitivity Labels / AIP / IRM. Encrypted with a tenant key; we have no way to brute-force a 4096-bit RSA-wrapped key.
• Conditional Access denials. Identity / device trust problem. IT handles it.
• OneDrive Personal Vault. 2FA gate on a folder. Use Microsoft's account recovery flow.
• BitLocker disk encryption. Different product entirely; Microsoft's recovery key escrow applies.

If you are not sure which bucket your problem falls into, the decision tree above is the fastest way to find out. If you land on a password dialog and you remember creating the password yourself years ago, upload to our free-check endpoint. If you land on any other message, contact your IT admin or the file owner.

Good Practice for Teams Sharing Sensitive Files

A few lessons learned from supporting clients through shared-file recoveries:

• Use Sensitivity Labels over document passwords. A tenant-managed label lets your IT restore access when someone leaves the company. A document password buried in a departing employee's head is unrecoverable.
• Do not email password-protected Office attachments. If a colleague forgets the password, you have lost the file with no admin recovery path. Share via SharePoint with a label instead.
• Keep super-user disabled in the default state. Only enable during active investigations or migrations. Disable again immediately to preserve the audit guarantee.
• Educate users on the difference between "shared" and "encrypted". Most users do not realise that a shared OneDrive file is still readable to Microsoft employees with datacentre-level access. Sensitivity Labels change that; permissions alone do not.

Frequently Asked Questions