Stickers, peeled, then auto-applied: a fourth chapter for the labels saga
Contents
Introduction
Three posts ago I called sensitivity labels stickers. Two posts ago I told you to make the stickers mean something. One post ago I warned you that the stickers peel. And now, courtesy of Microsoft’s RSA 2026 announcements, SharePoint will slap the stickers on for you. Even on the files that have been sitting in a library since 2019 (roadmap ID 559105).
This is good news. It is also the kind of good news that somewhat changes the assumptions in three of my previous posts. So let us walk through it properly.
What you may have missed
Quick links so nobody has to scroll:
- Purview Sensitivity Labels – 7 mistakes every org makes — why your labels are decorative.
- Labels are just stickers until you do this — how to make them actually do something.
- When the stickers start to peel — what happens when labels and reality disagree.
The thread running through all three: labels only work when they are applied consistently, and they almost never are, because we relied on users to do it.
That last part has just changed.
What is new
For a while now, when you set a default sensitivity label on a SharePoint document library, new files added to that library inherited the label automatically. Files updated in the library inherited it too. So far, so unsurprising.
What was missing: existing files. The 12,000 documents already sitting in the library when you turned on the default label kept whatever they had, which for most organisations meant nothing.
The new behaviour, announced at RSA 2026 and rolling out now, fixes exactly that. When you configure a default label on a SharePoint library, files at rest inside the library are now auto-labelled to match. No user click. No manual scan policy. No PowerShell. It just happens.
This is genuinely a big deal for Copilot readiness, because Copilot for Microsoft 365 respects sensitivity labels at grounding time. Unlabelled content with permissive sharing is exactly what surfaces in unwanted Copilot answers. Auto-labelling at rest closes the door on the largest source of that problem.
How to use it
Steps in my demo tenant:
- Configure the library default label. Library settings -> Sensitivity label -> choose the appropriate label for the content this library holds.
- Wait. Inheritance for existing files runs as a background job. In my testing it took anywhere from a few minutes to an hour for libraries with a few thousand files. It is not instant.
- Verify. Open a previously unlabelled file. The label should be applied. Check the activity explorer in Purview to confirm the auto-label events are firing.
- Test Copilot grounding. Ask Copilot a question that should hit content in the library. Confirm the response respects the label.
Expected behaviour (not bugs)
This is where some of the details from the previous posts come into play. None of this is broken, but it can look surprising if you’re not expecting it.
User-applied labels win. If a user manually labelled a file Confidential – Legal and the library default is Internal – General, the user’s label stays. This is correct behaviour but it means your inheritance coverage will look incomplete in reports. It is not broken. It is by design.
Encrypted labels behave differently. If the library default label includes encryption, applying it retroactively to existing content will change who can open those files. Test this with a small library first. I have seen organisations enthusiastically apply an encrypted default and then spend a week explaining to people why their old files no longer open on mobile.
Scope is per library, not per site. If your site has fifteen libraries and you want them all labelled, you need to set the default on each one. There is no site-level inheritance for this. (Yet. I assume.)
Existing label inheritance from parent folders or sites still applies first. The new behaviour is a fallback when nothing else applied a label. Useful to know when you are debugging why a file got the label you did not expect.
What this changes in my earlier posts
If you read the labels trilogy, here is what you can mentally update.
In 7 mistakes every org makes, mistake number three was “relying on users to label”. That mistake is now significantly less fatal, because for SharePoint-stored content you do not need to. You still need users to label correctly when content is more sensitive than the library default, but the floor is now covered for you.
In Labels are just stickers, the recommendation to set library defaults stands, but the urgency goes up. A library default now actually labels everything inside it, not just new uploads. Treat your library defaults as a real labelling decision, not a guess.
In When the stickers start to peel, the section on inconsistent application gets one fewer cause. Auto-inheritance at rest is one of the better tools we have for closing that gap.
The one catch
The catch, because there is always one: this is only for files in SharePoint libraries. Email, Teams chat attachments, files in OneDrive personal sites, files on endpoints, none of those benefit from this specific behaviour. You still need your auto-labelling policies and your client-side label suggestions for everything else.
But for the SharePoint content that Copilot grounds on every single day? You finally have a labelling story that works without herding users.
About the author
Åsne Holtklimpen
M365 Copilot MVP | Senior Architect – Microsoft AI & Compliance Lead | Top 50 Women in Technology 2022 | MCT
Holtklimpen, A (29/04/2026) Stickers, peeled, then auto-applied: a fourth chapter for the labels saga. Stickers, peeled, then auto-applied: a fourth chapter for the labels saga – Agder in the cloud
Tags
trending posts
