Microsoft Limits App Access to Sensitive Message Properties

Apps Won’t Be Able to Update Sensitive Message Properties

In an interesting and understandable move, Microsoft announced on March 24 that apps using the update message Graph API will be restricted from updating sensitive properties for non-draft messages from December 31, 2026.

A sensitive property can be defined as one that is expected to remain immutable after the originator sends the message like its subject or content. The documentation for the update message API highlights these properties as “updatable only if isDraft = true” (Figure 1).

App Access to Message Properties

It’s easy to understand why an app shouldn’t add TO, CC, or BCC recipients to a sent message or amend the body (text) of a message while it’s acceptable to update the categories, follow up flag, or importance. Apps often update these properties for their own purposes. For instance, an app tracking customer requests flowing into a shared mailbox might update categories as agents (human or computer) process requests.

Obviously, it appears that some apps have been updating the sensitive properties and that’s a bad thing if done without good reason. For example, adding a recipient to a sent message won’t deliver a message to that recipient’s mailbox (because the message has already been through the transport pipeline), but anyone looking at the message would assume that the added recipient had seen it. This creates an obvious compliance issue for eDiscovery, communications compliance, and other areas.

Change to Required Graph Permissions

Up to now, the Mail.ReadWrite Graph permission has been sufficient to allow an app to update messages. Use of this permission should be restricted by RBAC for Applications as otherwise the app has full access to update items in any mailbox.

After December 31, 2026, apps can continue to update non-sensitive message properties via the Mail.ReadWrite permission, but if those apps want to update sensitive properties for non-draft messages, apps must be assigned and receive administrator consent for an appropriate advanced mail access permission:

• Mail-Advanced.ReadWrite (delegated).
• Mail-Advanced.ReadWrite.All (application access to normal mailboxes).
• Mail-Advanced.ReadWrite.All.Shared (application access to shared mailboxes).

At the date of writing, only the Mail-Advanced.ReadWrite.All permission is visible in the Entra Admin center (Figure 2).

Sample Code to Update Message Properties

To illustrate the point, let’s update some message properties. Everything below can be done by an app with the Mail.ReadWrite permission. First, retrieve some messages from a mail folder. In this case, the code fetches the latest message from the Sent Items folder.

$Message = Get-MgUserMailFolderMessage -UserId $Userid -Top 1 -MailFolderId SentItems -Property Id, categories, subject, body, ccRecipients, toRecipients

Now create a hash table containing the new values for the properties that you want to update (including some sensitive properties) and use the Update-MgUserMessage cmdlet to update the message. Notice how even the message body can be updated.

$Body = @{}
$Body.Add("contentType", "HTML")
$Body.Add("content", "<b>Kilroy Was Here and Messed this message up!</b>")

$Properties = @{}
$Properties.Add("subject", "An odd message changed from the Graph")
$Properties.Add("categories", "Happiness")
$Properties.Add("Body", $Body)

Update-MgUserMessage -MessageId $Message.Id -UserId $UserId -BodyParameter $Properties

Updating recipients (always sensitive) is harder unless you decide to overwrite the existing recipient information. This code extracts the current CC recipients and adds a new recipient before updating the message. Recipient information is always passed in an array of hash tables, which each hash table holding the details of a recipient.

[array]$CCRecipients = $null

ForEach ($Recipient in $Message.ccRecipients) {
   $RecipientInfo = @{}   
   $EmailAddress = @{}
   $EmailAddress.Add("address", $Recipient.emailAddress.address)
   $EmailAddress.Add("name", $Recipient.emailAddress.name)
   $RecipientInfo.Add("emailaddress", $EmailAddress) 

   $CCRecipients += $RecipientInfo
}

$NewCCRecipient = @{}
$EmailAddress = @{}
$EmailAddress.Add("address", 'Ken.Bowers@office365itpros.com')

$NewCCRecipient.Add("emailaddress", $EmailAddress) 

$CCRecipients += $NewCCRecipients

Update-MgUserMessage -MessageId $Message.Id -UserId $UserId -CcRecipients $CCRecipients

Figure 3 shows a message with properties updated by the code example.

The only property that the app can update using this code after 31 December 2026 will be categories. Everything else requires the app to have an advanced mail permission.

What Action to Take Now

The only way to discover if a tenant has any apps (registered or enterprise) with the Mail.ReadWrite permission is to check permission assignments. Retrieving and checking permission assignments is boring manual work. Fortunately, PowerShell can automate the process.

Use the analysis script explained in this article to check for service principals with high-priority permission assignments, which include Mail.ReadWrite. Then ask what justification exists for apps to have the assignment. If justification exists, make plans for the apps to be assigned the appropriate advanced mail permission before December 31. Otherwise, the apps will stop working when their permissions become invalid.

---

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.