Prevent users from removing or downgrading the labels

Question

Prevent users from removing or downgrading the labels

Archit Jain 40

Hello guys, I am here to get some understanding on preventing users from removing or downgrading sensitivity labels. Ik we have option of adding justification for that, But I just wanna prevent that action. Is it possible? So I was thinking using the sensitivity labels internal permissions options, if I publish the labels with only restricted editor or view permissions for the whole org wide users and only authorized group with co-author permission, would this work in preventing the user to remove the labels. I am guessing NO, but Just want to have your opinion. Please feel free to provide your suggestion.

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer accepted by question author

AI answer

Yes—this can be prevented, but not by relying only on justification prompts.

For Microsoft Purview sensitivity labels, justification is the default behavior when a user removes a label or replaces it with a lower-priority label. That setting does not block the action; it only requires a reason.

To prevent users from changing or removing protection, the supported approach is to use protected sensitivity labels with encryption and assign permissions so only authorized users have rights that allow label changes.

The relevant rule is:

A user can change or remove a protected label only if that user either:
- applied the label, or
- has one of these usage rights:
  - OWNER
  - EXPORT
  - EDIT and EDITRIGHTSDATA

For automatically applied labels in Fabric/Power BI scenarios, the requirement can be relaxed to OWNER, EXPORT, or EDIT.

About the permission presets:

Viewer cannot change or remove protection.
Restricted Editor can edit, but cannot change or remove protection.
Editor can view, edit, print, and copy, but cannot change or remove protection.
Owner has full control, including changing or removing protection.

So the design being considered is broadly correct:

Give most users Viewer, Restricted Editor, or Editor rights.
Give only the authorized group Owner-level rights, or otherwise ensure they have the required usage rights.

That will prevent standard users from removing or changing the protected label. However, there is one important limitation:

The user who originally applied the protected label can also change or remove it.

Also note:

Mandatory labeling can require users to apply a label before saving, but it does not by itself stop label changes.
Downgrade justification requires a reason for lowering/removing a label, but it does not block the action.

If the goal is “no downgrade or removal by regular users,” the practical approach is:

Use a sensitivity label with encryption/protection.
Publish it with permissions such as Viewer, Restricted Editor, or Editor for broad users.
Reserve Owner or equivalent change-capable rights for a small authorized group.
Avoid workflows where regular users are the original label appliers if the requirement is that they must never be able to remove the label.

AI-generated content may be incorrect. Read our transparency notes for more information.

1 additional answer

Your answer

Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

Archit Jain 40

so what if the org has mandatory label apply label policy before saving it, and the suer who applies the label has only editor or restricted editor permission on the label. So as soon as the label is applied the user must inherit the permissions from the label right, then he must not have the ability to remove or change the label although he added the label originalluy? Need clarification

Maksood Ahmed 15 Reputation points Microsoft External Staff Moderator

2026-09-28T11:45:19.59+00:00

You're correct that the label's encryption permissions apply to the content after labeling. However, in Fabric/Power BI, label-change enforcement separately treats the user** who applied the sensitivity **label as authorized to change or remove that label. Therefore, restricting that user to Editor/Restricted Editor permissions doesn't by itself prevent the original label applier from changing/removing the label. Mandatory labeling ensures a label is applied, but it doesn't remove this original-applier authorization.
Archit Jain 40 Reputation points

2026-09-29T08:37:33.2933333+00:00

Thanks for your input Maksood.

So lastly, I would like to know that currently I am trying to use the labels on to my sharepoint and onedrive where I would usually have excels or ppts.
So my basic concern is that those permissions which I have been assigned to those groups or users. Will it really be working for sensitivity labels actions as well. as above mentioned in the AI generated answer particular roles will have different level of actions and permissions at the file level but also different access for making changes on the labels as well.

Just want be sure, Thanks
Maksood Ahmed 15 Reputation points Microsoft External Staff Moderator

2026-09-29T09:54:03.3933333+00:00
Yes, for SharePoint and OneDrive-hosted Word, Excel, and PowerPoint files, the permissions assigned through the sensitivity label can control what users can do with the protected content, including whether they can change the applied sensitivity label.

The important distinction is that SharePoint permissions and sensitivity-label usage rights are related but not identical. When an encrypted sensitivity label is configured to extend SharePoint permissions, Microsoft maps the SharePoint permission level to Rights Management usage rights. For example:

Owner → Full control, including changing the sensitivity label.

Edit → Users can edit the document, but can't change the sensitivity label applied.

Read → Users can view/copy the document, but can't change the content or sensitivity label.

So, if your requirement is:

“Users should be able to edit the Excel/PPT files, but should not be able to remove or downgrade the sensitivity label,”

an encrypted sensitivity-label configuration that gives those users Edit-level usage rights rather than Owner-level rights is the appropriate model.

Also, mandatory labeling is a separate control. It ensures a label is required, but the encryption/usage-rights configuration is what determines whether the user has rights to modify the protection.

One important point: don't assume that the “Editor” or “Restricted Editor” names in the Purview label configuration are simply equivalent to SharePoint's Editor permission. What matters is the actual usage rights granted by the encrypted label. Microsoft provides the SharePoint-to-usage-rights mapping described above.

Recommended approach for your scenario:

Enable sensitivity labels for Office files in SharePoint and OneDrive.

Configure the sensitivity label with encryption.

Give normal users the required Edit capability, but not Owner/full-control usage rights.

Give Owner/full-control rights only to the administrators or authorized group.

Test with a normal user using an Excel/PPT file: apply the label, edit the file, then attempt to downgrade/change/remove the label.

Microsoft also notes that SharePoint and OneDrive enforce the encryption settings assigned to the label when users access the files, so the protection travels with the file.

Therefore, yes—the permissions can affect sensitivity-label actions, but you should look at the actual Rights Management usage rights granted by the encrypted label, rather than relying only on the SharePoint/OneDrive permission name. For your specific requirement, Edit for regular users and Owner/full control only for the authorized group is the configuration I would validate in a test library before production rollout.Yes, for SharePoint and OneDrive-hosted Word, Excel, and PowerPoint files, the permissions assigned through the sensitivity label can control what users can do with the protected content, including whether they can change the applied sensitivity label.

The important distinction is that SharePoint permissions and sensitivity-label usage rights are related but not identical. When an encrypted sensitivity label is configured to extend SharePoint permissions, Microsoft maps the SharePoint permission level to Rights Management usage rights. For example:

Owner → Full control, including changing the sensitivity label.

Edit → Users can edit the document, but can't change the sensitivity label applied.

Read → Users can view/copy the document, but can't change the content or sensitivity label.

So, if your requirement is:

“Users should be able to edit the Excel/PPT files, but should not be able to remove or downgrade the sensitivity label,”

an encrypted sensitivity-label configuration that gives those users Edit-level usage rights rather than Owner-level rights is the appropriate model.

Also, mandatory labeling is a separate control. It ensures a label is required, but the encryption/usage-rights configuration is what determines whether the user has rights to modify the protection.

One important point: don't assume that the “Editor” or “Restricted Editor” names in the Purview label configuration are simply equivalent to SharePoint's Editor permission. What matters is the actual usage rights granted by the encrypted label. Microsoft provides the SharePoint-to-usage-rights mapping described above.

Recommended approach for your scenario:

Enable sensitivity labels for Office files in SharePoint and OneDrive.

Configure the sensitivity label with encryption.

Give normal users the required Edit capability, but not Owner/full-control usage rights.

Give Owner/full-control rights only to the administrators or authorized group.

Test with a normal user using an Excel/PPT file: apply the label, edit the file, then attempt to downgrade/change/remove the label.

Microsoft also notes that SharePoint and OneDrive enforce the encryption settings assigned to the label when users access the files, so the protection travels with the file.

Therefore, yes—the permissions can affect sensitivity-label actions, but you should look at the actual Rights Management usage rights granted by the encrypted label, rather than relying only on the SharePoint/OneDrive permission name. For your specific requirement, Edit for regular users and Owner/full control only for the authorized group is the configuration I would validate in a test library before production rollout.
Archit Jain 40 Reputation points

2026-09-29T10:00:46.1833333+00:00

Perfect, Thanks. Will test it out.