In this module

AD4.4 Label Protection: Encryption, Marking, and Restrictions

5-6 hours · Module 4 · Free

Operational Objective

A sensitivity label without protection is just a colored tag. The value of labels comes from the protection settings they enforce — encryption that prevents unauthorized access, content marking that provides visual classification, and usage restrictions that control what recipients can do with the content. But encryption is a double-edged sword: misconfigured encryption breaks collaboration, prevents legitimate access, and creates helpdesk tickets from users who can't open their own documents. This subsection explains exactly how Purview encryption works, what each permission level allows, how content marking appears across different apps, and the specific protection configurations for each of NE's four labels — with the practical testing procedures that prove the protection works before you deploy to all users.

Deliverable: A verified understanding of how encryption, content marking, and usage restrictions work for each label — tested in your own environment with documents you can open, share, and verify.

Estimated completion: 30 minutes

Figure AD4.4 — Protection settings escalate with sensitivity. Public and Internal use visual marking only. Confidential adds encryption to the tenant (all internal users). Highly Confidential adds user-specified encryption with Do Not Forward on email. Each level adds protection without removing the lower level's markings.

How Purview encryption works in practice

When a user applies the "Confidential" label to a Word document, Purview encrypts the file using Azure Rights Management (Azure RMS). The encryption wraps the document content with a key managed by your tenant. When someone opens the document, their Office app contacts Azure RMS to check whether the user is authorized. If the user is in your tenant (authenticated against your Entra ID), Azure RMS returns the decryption key and the document opens normally. If the user is external (not in your tenant), Azure RMS denies the request and the document won't open.

This happens transparently for internal users — they open the document normally without noticing the encryption. The only visible difference is the sensitivity label in the title bar and the content markings (header, footer, watermark). Encryption doesn't change the user experience for authorized users — it only blocks unauthorized access.

For the "Highly Confidential" label with user-specified permissions, the user applies the label and a permissions dialog appears. They type the email addresses of the people who should have access, select the permission level (Viewer: read-only, Reviewer: read + edit, Co-Author: full edit), and save. Only those named users can open the document — even other internal users who aren't on the list are denied access.

Understanding permission levels

Purview encryption offers several permission levels that control what recipients can do with the content:

Viewer: Read-only. The user can open and read the document but cannot edit, copy text, print, or save a new copy. For email, they can read but not forward, reply-all, or print. Use this for documents shared "for information only" where the content should not be modified or redistributed.

Reviewer: Read + edit. The user can open, read, and edit the document, but cannot copy content to other documents, print, or change permissions. Use this for collaborative documents where the recipient needs to make changes but shouldn't redistribute the content.

Co-Author: Full editing. The user can open, read, edit, save, copy, and print. They cannot change permissions or remove the label. This is the most permissive encrypted option — the content is protected from unauthorized access but the authorized user has full control.

Co-Owner: Full control including permission changes. The user can do everything including changing who else has access. Use sparingly — typically only for the document owner.

For the "Confidential" label (all internal users), set the permission level to Co-Author — internal users can work with the document normally, but external users can't open it at all. For "Highly Confidential" where the user specifies recipients, let them choose the permission level based on the use case.

Troubleshooting encryption issues

Problem: User can't open an encrypted document they should have access to. Check: Is the user signed into Office with their corporate account (not a personal account)? Encryption validates against the corporate Entra ID identity. If the user is signed in with a personal Microsoft account, authentication fails. Fix: sign out of Office → sign in with their @northgateeng.com account → try again.

Problem: Encrypted document won't open on a mobile device. Check: Is the user using the Office mobile app (Word, Excel, PowerPoint) or the Files app? Encrypted documents require the Office app — they won't open in generic file viewers or the native Files app. Fix: install the Office mobile app and sign in with the corporate account.

Problem: Encrypted email shows "This message is encrypted" but the recipient can't read it. Check: Is the recipient using an email client that supports Azure RMS? Most modern clients do (Outlook desktop, Outlook web, Outlook mobile, Gmail web). Some older or niche email clients don't. Fix: the recipient can open the email in Outlook on the web (outlook.office365.com) using the one-time passcode authentication, which works regardless of their email client.

Testing encryption before rollout

Before relying on encryption for production documents, test it with a non-sensitive test document:

Test 1 — Internal user access. Create a Word document, apply "Confidential," save to OneDrive. Open it from a different device while signed in with your corporate account. It should open normally — you're an internal user, so encryption is transparent.

Test 2 — External user block. Share the same document with a personal email address (Gmail, Outlook.com) via OneDrive sharing. The sharing succeeds (OneDrive creates the link), but when you try to open the document from your personal account, authentication fails — the document can't be decrypted because your personal account isn't in the tenant. This is encryption working correctly.

Test 3 — Highly Confidential named access. Create a document, apply "Highly Confidential," specify only your own email address in the permissions. Save to OneDrive. Ask a colleague to try to open it from their corporate account. They should be denied access — only you are on the permissions list. Then add their email and verify they can now open it.

Test 4 — Email Do Not Forward. In Outlook, compose a new email and apply the "Highly Confidential" label. The Do Not Forward restriction activates. Send the email to a colleague. The colleague can read the email but cannot forward it, print it, or copy the content. The "Forward" button is greyed out.

# Verify encryption settings on your labels
Connect-IPPSSession
Get-Label | Where-Object { $_.Name -eq "Confidential" } |
    Select-Object Name, EncryptionEnabled, EncryptionProtectionType,
        EncryptionContentExpiredOnDateInDaysOrNever |
    Format-List

Content marking across applications

Content markings (headers, footers, watermarks) appear differently across applications. In Word, Excel, and PowerPoint, headers and footers appear in the document header/footer area and watermarks appear as background text. In Outlook, headers appear at the top of the email body and footers at the bottom — watermarks are not supported in email.

In Outlook on the web, content markings may render differently than in desktop Outlook — test both. In mobile Office apps (Word, Excel on iOS/Android), headers and footers appear normally but watermarks may be less visible due to screen size.

The most important thing about content markings: they persist in the document. If a user exports a Word document to PDF, the header, footer, and watermark are included in the PDF. If someone prints the document, the markings appear on the printed page. This means that even if the encryption is removed (e.g., a user with sufficient permissions removes the label), the visual markings remain as a record of the original classification.

Compliance Myth: "Encryption prevents all data leakage — once a document is encrypted, it can't be shared outside the organization"

Encryption prevents unauthorized users from opening the document. It doesn't prevent an authorized user from copying the text and pasting it into an unencrypted document, taking a screenshot, reading the content aloud in a meeting, or photographing the screen. Encryption is a strong technical control against digital sharing and forwarding, but it's not a substitute for user awareness and organizational culture. A user who is determined to exfiltrate data can always use analogue methods that no technical control prevents. Encryption raises the bar significantly — but the data protection program includes labels (classification), encryption (access control), DLP (automated prevention), AND user education (awareness). All four together provide the strongest protection.

Decision point

After deploying labels, the procurement team reports that they can't share "Confidential" documents with vendors during contract negotiations. The documents are encrypted to internal users only, so vendors can't open them. The procurement team asks you to either remove encryption from the "Confidential" label or create a "Confidential — External" label that doesn't encrypt. What do you do?

Option A: Remove encryption from the "Confidential" label entirely — This removes the primary protection for all Confidential content, not just procurement documents.

Option B: Create a "Confidential — External Allowed" sub-label — This adds a fifth label to the taxonomy and creates the overlapping-label problem discussed in AD4.2.

Option C: Keep the "Confidential" label with encryption for internal documents. For documents that need external sharing, instruct procurement to label them as "Internal" (which allows external sharing) and use SharePoint or OneDrive sharing with specific authenticated external users. If the content genuinely needs encryption AND external access, the user can apply "Highly Confidential" and add the specific vendor email addresses to the permissions list — giving named external users access while keeping the document encrypted.

The correct answer is Option C. The Confidential label's purpose is to prevent external sharing — that's the protection it provides. If a document NEEDS to be shared externally, it's either not truly Confidential (use Internal) or it needs controlled external access to specific people (use Highly Confidential with named permissions). Don't weaken the label to accommodate a workflow — use the right label for the workflow.

Try it: Test all four protection levels

Create four test documents — one for each label:

1. Public: Create a Word doc, label as Public, save to OneDrive, share externally. Verify: external user can open it, footer shows "Public." 2. Internal: Create a Word doc, label as Internal. Verify: header and footer show "Internal," no encryption, anyone internal can open. 3. Confidential: Create a Word doc, label as Confidential, save to OneDrive, attempt to share externally. Verify: the document is encrypted, external users cannot open it, watermark and header/footer are visible. 4. Highly Confidential: Create a Word doc, label as Highly Confidential, specify only your own email. Ask a colleague to try opening it. Verify: denied. Add the colleague, verify: they can now open it.

Send a test email with each label in Outlook. For Highly Confidential, verify that the recipient cannot forward the email.

Document the results of each test. This is your verification record that label protection works as intended — evidence for your configuration register and for any audit.

A user applies the "Confidential" label to a Word document containing client pricing data. They save it to OneDrive and share it with a colleague via a sharing link. The colleague opens it normally. The user then tries to share the same link with the client's external email address. What happens when the client tries to open the document?

The client cannot open the document — encryption requires authentication against your Entra ID tenant, and the client's account is external. The client sees an "Access Denied" or "You don't have permission" error — Correct. The Confidential label encrypts the document to internal users only. The sharing link exists, but the client's authentication doesn't have decryption permission. The link alone doesn't grant access — the client needs to be an authenticated member of your tenant to decrypt the content.

The client can open the document because they have the sharing link — No. The sharing link provides the URL to the document, but encryption is a separate layer. The link grants access to the SharePoint resource; encryption controls who can decrypt the content. Both need to pass.

OneDrive blocks the share because the label prevents external sharing — Depends on your SharePoint sharing settings. OneDrive may allow the share at the platform level, but encryption prevents the external user from opening the content. The protection works at the document level, not the sharing level.

The client can open the document in read-only mode — No. Encryption doesn't offer a read-only fallback for unauthorized users. Either you're authorized and get full access per the permission level, or you're not authorized and get nothing.

One operational detail that catches administrators off guard: sensitivity label encryption uses Azure Rights Management keys managed by Microsoft by default. If your organization requires customer-managed keys (BYOK or HYOK), this requires additional Azure Key Vault configuration. For most organizations, Microsoft-managed keys are appropriate and require no additional setup. If you have a specific key management requirement (regulatory, contractual, or organizational policy), evaluate it before deploying encryption — changing key management after deployment is disruptive.

Operational Artifact — Label Protection Testing Checklist

Test each label's protection before relying on it for production documents. For each label, verify: visual markings appear correctly (header, footer, watermark) in Word, Excel, Outlook desktop, and Outlook web. For encrypted labels (Confidential, Highly Confidential), verify that internal users can open and external users are blocked. For Highly Confidential email, verify that Do Not Forward prevents forwarding, printing, and copying. Document the test results with screenshots. Run these tests after any label configuration change.

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →