A default sensitivity label on a SharePoint document library has always had a blind spot: it labels new files and files someone edits, and leaves everything already sitting in the library alone. Microsoft Purview now closes that gap with an auto-labeling policy that applies each library's default label to its existing files. The roadmap lists it as launched, general availability October CY2026 (ID 559105), and Message Center post MC1477181 put the worldwide rollout between early and mid-October 2026. It's opt-in. Nothing happens until an administrator builds the policy.
The catch is the size of the door. One policy of this type per tenant, and no more than 10 SharePoint sites in it at a time. So the first decision isn't technical. It's which ten sites go first, and the records owner and the security owner should make it together.
A Confidential site does not mean Confidential files
This is the part that surprises people preparing for Copilot. Microsoft's Copilot considerations page is plain about it: sensitivity labels applied to containers, such as SharePoint sites and Teams, aren't inherited by the items inside them. A site labeled Confidential holds files that carry no label at all unless something labels them. Copilot sees the file's label, not the site's.
Files that predate the library default were exactly that gap. Users were never going to open ten years of contracts just to trigger a label. The new policy does it as a background service process, with no content inspection and no sensitive information types to tune. The label comes straight from the library setting.
What gets relabeled and what doesn't
The library default follows the same override rules it always has, per Learn's page on default library labels:
Label already on the fileReplaced by the library default?Manually applied, any priorityNoApplied automatically, lower priorityYesApplied automatically, higher priorityNoPolicy default label, lower priorityYesPolicy default label, higher priorityNo
A person's deliberate choice wins. MC1477181 adds that whether a lower-priority label is upgraded depends on the policy setting, so check that setting before you run it.
Auto-labeling doesn't touch the modified, modified by or date values, in simulation or when labels land. That protects a file's history. One detail cuts the other way: when the label applies encryption, Learn says the Rights Management issuer and owner become the account that last modified the file. On old libraries, that account may belong to someone who left years ago. Decide whether the library's default label should encrypt before you push it onto a decade of content in one pass.
Before the policy will work
Learn's prerequisites, in the order we'd check them:
Sensitivity labels must be enabled for Office files in SharePoint and OneDrive; (Get-SPOTenant).EnableAIPIntegration should return True. PDFs need EnableSensitivityLabelforPDF set as well, or the policy skips them entirely. Libraries with the older SharePoint IRM setting can't have a default sensitivity label. Labels that use user-defined permissions, an access expiry other than Never, or Double Key Encryption can't serve as a library default.
The person building the policy needs to read library metadata, which in practice means Compliance Administrator or SharePoint Administrator. The policy targets named sites, not All, and doesn't support administrative units. Files that are open, checked out, locked or unsupported when the policy reaches them get skipped. The tenant ceiling for auto-labeling still applies: 500,000 automatically labeled files a day.
Simulation comes first and isn't optional; no auto-labeling policy labels anything until it has run at least one. Use it to confirm the expected sites, libraries, default labels and files are in scope. A site with no library default can't be added, and Learn notes that a "couldn't be verified" message is about access, not proof the label is missing.
Ten sites at a time is a sequence
Learn's guidance for more than ten sites is to finish a batch, review the results, then edit the policy and swap in the next ten. That makes this a program with an order, and the order should come from risk:
Sites the security owner already treats as sensitive, where the library default is set and agreed.
Sites Copilot users will reach first.
Everything else with a library default, in batches, reviewed each time.
Libraries without a default label never enter the policy. If a site's libraries have no default, the site owner and records owner settle one first, because the label on a library is a statement about what that library holds. Our Purview labels post made the case for a short label set; this is where that set gets used.
Who signs what
The records owner and the security owner choose the label for each library and the order of the batches. Site owners confirm their libraries hold what the label says. The compliance administrator builds the policy, runs the simulation, shares the results with both owners, and only then turns it on. Each batch closes with a check of what got labeled and what was skipped.
The labels were already on the libraries. Now they can finally reach what's inside them.
