Your Labels Already Decided Who Can Annotate PDFs. You Never Looked.

Microsoft didn't grant new annotation permissions—it started honoring the edit rights your sensitivity labels defined years ago. If you haven't audited those rights, this rollout just made them visible.

Mo WasayOctober 16, 20267 min read

Everyone is reading roadmap item 576276 as a convenience win, and it is one. That’s precisely why most admins will skip the single thing it actually asks of them.

Here’s the surprising part, stated plainly: this feature doesn’t grant anyone new permissions. It just starts honouring permissions your sensitivity labels have been carrying all along. Annotation in the OneDrive and SharePoint web viewer is governed entirely by the usage rights already baked into each label. If you’ve never audited those rights — and in most tenants I’ve seen, nobody has since the labels were first stood up — then this rollout is not a feature announcement. It’s a notification that a configuration you forgot about is now visible to end users.

What Microsoft got right, because they did

Give credit where it’s due. The old behaviour was genuinely bad for security. A user with edit rights on an encrypted PDF who wanted to scribble a comment had two options: download the file and mark it up in a desktop app, or ask someone to strip the label so a web tool could touch it. Both options take the document out of the governed surface. The download path lands a decrypted-at-rest copy on an endpoint you may or may not control. The strip-the-label path is worse — it deliberately removes the encryption and the usage restrictions to solve a UI limitation.

So the common take — “this closes a collaboration gap and reduces the temptation to remove protection” — is correct on its own terms. Annotating in place preserves the sensitivity label, the encryption, and the usage rights. The file never leaves the protected envelope. That is a real improvement over the download-strip-reupload dance, and if your users were doing that dance, you should be pleased.

The problem isn’t the feature. It’s the sentence doing all the heavy lifting in the announcement: users with the appropriate usage rights.

“Appropriate usage rights” is carrying the entire security story

When a sensitivity label applies encryption, it doesn’t just scramble the bytes. It attaches an authorization policy — a set of rights-management permissions that say which identities can do which things: VIEW, EDIT, PRINT, EXTRACT (copy), EXPORT, REPLY, FORWARD, and so on. Annotation is not a new right. From everything in the rollout, it rides on the existing content-edit right. If a label grants a user the ability to edit the document, the web viewer now lets that edit include annotations. There is no separate “annotate but don’t edit” permission to hand out, and no “edit but don’t annotate” either. They are the same right wearing a new hat.

That matters because of how these rights usually got set. Almost nobody configures RMS rights by hand. They pick a preset in the Purview label wizard — “Co-Author,” “Reviewer,” “Co-Owner” — and move on. Those presets are bundles:

Co-Author grants VIEW, EDIT, COPY, PRINT, and more.
Reviewer grants VIEW and EDIT (no copy, no print).
Viewer grants VIEW and reply rights only — no edit, so no annotation.

And the assignment target is the quiet killer. A huge number of labels assign a preset to all authenticated users in the organization, or to a broad “All Employees” group, because that was the fastest way to make internal collaboration stop breaking during rollout. If that’s your configuration, then as of this rollout, anyone in the building with web access to the file can now modify a classified PDF in the browser. They always had the right. They just couldn’t exercise it this easily until now.

Microsoft’s framing says “no new risk, no behaviour change.” I’d phrase it differently: no new permissions, but a very real behaviour change for every user who previously couldn’t act on a right they were holding. Those are not the same statement.

Where this bites in six months

Picture the incident review. A sensitive contract PDF, labelled and encrypted, gets a handful of annotations added over a week. One of them pastes a customer identifier into a sticky note. The annotation layer is now part of the encrypted file — it travels with the document, it’s preserved by the label, and it’s exactly as protected as the body text. Good, in the sense that it didn’t leak. Awkward, in the sense that your reviewers were adding governed content through a surface nobody signed off on, under rights nobody re-examined.

The more mundane version: a label grants org-wide EDIT, and now “comments” start appearing on documents from people the owner never intended to have write access. Nothing was breached. The authorization model simply did what it was configured to do, in front of an audience that can finally see it.

There’s also the control question, and here I’ll be honest about what I can’t confirm. I’ve found no evidence of a dedicated tenant-level toggle to switch web-viewer annotation on or off independently of the usage rights. That tracks with the design — the right is the control. Your enable/disable switch is the label’s encryption configuration, full stop. If you want to prevent annotation on a given classification, you remove the edit right from the identities who shouldn’t have it. There is no blunt instrument, which means the only way to manage this is the granular way you’ve been avoiding.

Audit the rights, not the feature

Before you touch anything, inventory what your labels actually grant. This is a read-only pass against the Security & Compliance endpoint — no changes, no bulk edits, just a map of which labels carry edit rights and to whom. (Label encryption rights still live in the compliance PowerShell surface; this is the current supported module, not the retired AzureAD/MSOnline ones.)

audit.ps1PowerShell

#Requires -Modules ExchangeOnlineManagement

try {
    Connect-IPPSSession -ErrorAction Stop
}
catch {
    Write-Error "Could not connect to the Security & Compliance endpoint: $($_.Exception.Message)"
    return
}

# Rights that imply the ability to edit (and therefore annotate) protected content
$editRights = @('EDIT', 'DOCEDIT', 'OWNER')

try {
    $labels = Get-Label -ErrorAction Stop
}
catch {
    Write-Error "Failed to enumerate labels: $($_.Exception.Message)"
    return
}

$report = foreach ($label in $labels) {
    # Only labels that actually apply encryption carry usage rights
    if (-not $label.EncryptionRightsDefinitions) { continue }

    foreach ($grant in $label.EncryptionRightsDefinitions) {
        # Format is typically "identity:RIGHT,RIGHT,RIGHT"
        $identity, $rights = $grant -split ':', 2
        $rightList = ($rights -split ',').Trim()

        $canAnnotate = [bool]($rightList | Where-Object { $_ -in $editRights })

        [pscustomobject]@{
            Label        = $label.DisplayName
            Identity     = $identity
            CanAnnotate  = $canAnnotate
            BroadGrant   = $identity -match 'AuthenticatedUsers|AllStaff|Everyone'
            Rights       = ($rightList -join ', ')
        }
    }
}

# Surface the combinations that deserve a second look first
$report |
    Where-Object { $_.CanAnnotate -and $_.BroadGrant } |
    Sort-Object Label |
    Format-Table -AutoSize

# Export the full picture for review before you change anything
$report | Export-Csv -Path .\label-usage-rights-audit.csv -NoTypeInformation -Encoding UTF8

Anything flagged CanAnnotate = True with a broad grant is a label where the people who can mark up protected PDFs is effectively “the whole org.” Decide whether that’s intentional. If it isn’t, change the label’s rights deliberately — review the exported CSV, scope the edit, and run any Set-Label change with -WhatIf first. Never pipe a live query straight into a modify.

Where to verify it in the portal

In the Microsoft Purview portal, go to Information Protection → Labels, open a label, and check Encryption. The Assign permissions now configuration is where the presets and custom rights live — that’s the surface that governs annotation. Cross-reference against Label policies to confirm which users and groups the label is actually published to. The combination of “who it’s published to” and “what rights it grants” is the real blast radius, and the portal makes you look in two places to see it.

The rollout status, per the roadmap, is in-flight across OneDrive and SharePoint web. Microsoft hasn’t published a browser compatibility matrix I’d quote; treat it as modern Chromium-based Edge and Chrome until they say otherwise, and don’t promise users it works everywhere. Desktop Office apps are explicitly out of scope — this is a web-viewer capability, so don’t let anyone assume the same behaviour shows up in Acrobat or the Office desktop stack.

The feature is fine. Ship it, enjoy the fewer stripped labels. Just don’t let “no new permissions” lull you into thinking nothing changed — the permissions were always there, and now your users can finally feel them.