Microsoft 365 Sensitivity Label Co-Authoring: Rolling Out Encryption Without Breaking Collaboration

Sensitivity labels in Microsoft Purview give records and security teams a practical way to classify and protect documents, and the encryption that labels can apply is one of the strongest controls available within the Microsoft 365 platform. The difficulty many organisations encounter is that encryption historically interfered with real time co-authoring, forcing users to edit protected documents one at a time or to abandon protection altogether to keep shared editing workflows moving. For WA Government records teams, this tension sits at the heart of day to day operations, where protecting sensitive material must coexist with the collaborative drafting that underpins briefings, submissions, and policy documents.

Microsoft now supports co-authoring on documents encrypted by sensitivity labels, but the capability is not something to switch on without preparation. The enablement carries tenant wide consequences, interacts with licensing and client versions, and depends on a labelling approach that some organisations have not yet adopted. This article explains how the feature works, the prerequisites to confirm beforehand, and a sensible sequence for enabling it so that protection reinforces collaboration rather than stalling it.

Understanding co-authoring on encrypted documents

Co-authoring allows multiple people to edit the same document at the same time in the Office desktop, web, and mobile applications, with changes synchronised through SharePoint Online and OneDrive. When a sensitivity label applies encryption, the document carries protection information that the Office applications must be able to read and honour before they permit concurrent editing. The feature that unlocks this behaviour is a tenant level setting in the Microsoft Purview portal that enables co-authoring for files with sensitivity labels, and it alters the way label metadata is stored so that multiple editors can work on an encrypted file simultaneously.

Because the setting changes how labelling metadata is written, it affects more than the editing experience alone. Services and applications that read label metadata, including some data loss prevention, eDiscovery, and third party tools, need to support the updated format to continue functioning as expected. Treating this as a one way change in practical terms is prudent, because reverting after users have created and saved documents under the new metadata format can introduce inconsistencies. Understanding these downstream effects before enablement helps records teams avoid surprises in auditing, retention, and discovery processes.

Prerequisites to confirm before enabling

The first prerequisite is appropriate licensing, since sensitivity labels with encryption and co-authoring depend on the relevant Microsoft 365 and Azure Rights Management entitlements being active across the affected users. Teams should confirm that the Azure Rights Management service is turned on in the tenant and that the users who will collaborate on protected documents hold eligible licences. Verifying this early prevents a scenario where the capability is enabled but a subset of users cannot participate because of entitlement gaps.

The second prerequisite concerns the labelling client itself. The older Azure Information Protection add-in does not support co-authoring on encrypted documents, so organisations still relying on it must move to the built in labelling capability in the Office applications before the feature will work correctly. Alongside this, client applications across Windows, macOS, the web, and mobile need to meet the minimum versions that support the feature, which makes update management and a current servicing channel an operational dependency rather than an afterthought. Auditing the estate for the add-in, for unsupported versions, and for inconsistent configuration is essential groundwork.

Sequencing the rollout

A disciplined sequence begins with discovery and taxonomy work rather than with the setting itself. Records teams should review the existing label taxonomy, confirm which labels apply encryption and under what conditions, and document how those labels map to retention and classification obligations. This is also the moment to remove or consolidate redundant labels, because a cluttered taxonomy confuses users and undermines consistent protection once collaboration scales up across the organisation.

With the taxonomy settled, the next steps address technical readiness in order. Migrate any remaining users from the Azure Information Protection add-in to built in labelling, bring Office applications up to supported versions through a controlled update, and validate that data loss prevention and eDiscovery processes will continue to interpret the updated metadata. Only after these foundations are in place should the tenant setting be enabled, ideally following a pilot with a representative group of users who routinely co-author sensitive documents. A pilot surfaces practical issues such as unexpected prompts, version mismatches, or integration behaviour before the change reaches the wider workforce.

Communication and support form the final stage of the sequence, and they deserve the same care as the technical tasks. Users benefit from clear guidance on what will change, how labels behave during shared editing, and who to contact when a document does not open as expected. Pairing the rollout with short reference material and a defined support path reduces the risk that people respond to friction by downgrading protection or copying content into unmanaged locations.

Supporting records teams and sustaining collaboration

For WA Government records teams, the value of this capability lies in removing the false choice between protection and productivity. When co-authoring works on encrypted documents, teams can apply encryption to the material that genuinely warrants it without sacrificing the collaborative drafting that government work depends on. That alignment supports recordkeeping obligations because protection no longer pushes users towards workarounds that scatter sensitive content outside managed systems.

Sustaining the outcome requires ongoing attention rather than a single enablement event. Label taxonomies evolve, staff change, and client applications continue to update, so periodic reviews of labelling behaviour, licensing coverage, and supporting controls keep the environment healthy over time. Monitoring how labels are applied and how protected documents are shared also gives records teams the evidence they need to demonstrate that protection and collaboration are working together as intended.

References

• Enable co-authoring for files with sensitivity labels, Microsoft Learn
• Learn about sensitivity labels, Microsoft Learn