MailboxFolder.ReadWrite.All & MailboxItem.ImportExport.All — Detailed technical justification required for backup operat

[sven.madai@switch.ch]

Hello Veeam Forum

I've already tried contacting Veeam Support, but unfortunately they couldn't provide me with any further information.
Maybe you can help. Thanks

We manage multiple enterprise customers using Veeam Backup for Microsoft 365 (v8.5.x) and are currently configuring the required Microsoft Graph permissions in the context of the EWS deprecation (October 1, 2026).

Our customers must formally justify every Graph permission to their CISO and data protection authority. Two permissions are being questioned for pure backup operations -> https://helpcenter.veeam.com/docs/vbo36 ... html?ver=8

1. MailboxFolder.ReadWrite.All — Why is write access needed for backup? Would MailboxFolder.Read.All not be sufficient?

2. MailboxItem.ImportExport.All — Why is the import capability needed for backup? Would MailboxItem.Export.All not be sufficient?

We kindly ask for a detailed technical explanation for both permissions, and suggest that Veeam adds these justifications directly to the official documentation.

Thxs
Sven

[Polina]

Hi Sven,

During backup write and import are not used, and technically only read and export abilities are used. ReadWrite and ImportExport permissions are requested to cover both backup and restore scenarios.

Thanks

[sven.madai@switch.ch]

Hi Polina

Thank you for your response. However, for our customers' compliance requirements, this explanation is unfortunately not sufficient.

Saying that "write and import are not used during backup" actually raises more questions than it answers:

1. If write and import are not used during backup — why are these permissions requested at all for the backup application registration? From a security and least-privilege perspective, an application should only request permissions it actually needs.

2. Can Veeam officially confirm that granting MailboxFolder.ReadWrite.All and MailboxItem.ImportExport.All to the backup app registration does NOT allow the application to write data into mailboxes during backup jobs — and that this is enforced technically, not just by convention?

3. Would it be possible to separate the permissions — using a restricted set for backup and elevated permissions only for the restore app registration?

Our customers need a formal, documented statement from Veeam that can be presented to their CISO and data protection authority. A forum reply is a good start, but ideally this should be reflected in the official documentation at:
https://helpcenter.veeam.com/docs/vbo36 ... html?ver=8

Thank you for your support.

Best regards
Sven

[sumeet]

For the exact same reason but for a different permission, I had opened a case few months back.

TeamSettings.ReadWrite.All - application type permissions, instead of just read.all.

Old case #08125679 - and this is the explanation I received.

And when I saw the new permissions for the graph API - same exact - ohh gosh feeling. Our clients are keen on the kind of permissions they allow.

===============
The TeamSettings.ReadWrite.All permission in the backup table is there for one specific purpose: accessing archived teams. Microsoft Graph only returns archived teams through this scope. The read-only TeamSettings.Read.All you found in the portal does not surface archived teams, which is exactly why the backup permission set lists the ReadWrite variant and not the read-only one. During a backup the product uses this permission to read archived team data only. It does not write to or change anything in your Teams configuration.
On the restore side, TeamSettings.ReadWrite.All is not actually one of the restore permissions. It sits only in the backup table. The restore lists (the delegated device-code-flow set and the certificate-based set) use a separate group of permissions, and those are independent of what backup needs.
For your security requirement, here is the part that matters: the restore-portal and certificate-based restore permissions you would rather not grant are not needed for backup at all. They only come into play if you later choose to use the Restore Portal, certificate-based Explorer restore, or restore through REST API and PowerShell. Backup runs fully without them, so you can leave those ungranted and grant only the backup set.
The one trade-off worth flagging: if your policy rules out granting TeamSettings.ReadWrite.All entirely, archived teams will not be included in the backup. Everything else in the backup set is read and query access. If archived-team coverage matters to your client, granting this permission (used purely for reading during backup) is what keeps those teams protected.
==============

[Polina]

Hi All,

@sven.madai@switch.ch For backup, MailboxFolder.Read.All and MailboxItem.ImportExport.All would be sufficient, and your customer can already assign those instead of the more privileged ones. Note though that for restores ReadWrite/ExportImport permissions are still required.
Our HelpCenter will be soon updated to reflect it. And with the next product release, we'll separate permissions for backup and restores assigned to the app in automated mode.

@sumeet TeamSettings.ReadWrite.All will remain required. It's used for protecting archived teams - during backup they have to be unarchived and then archived back to preserve the state.

Thanks!