Restore Permissions & Scopes
Every write-capable Microsoft Graph permission a restore action can invoke is granted once, at connection time, alongside the read-only permissions backup uses — not requested separately when a restore is actually started.
Granted once, at connect time — not staged per feature
BYOVault connects to a Microsoft 365 tenant in one of two ways:
- Quick Connect, which redirects the customer’s admin to Microsoft’s own tenant-wide admin-consent page against BYOVault’s shared Azure AD app.
- A customer’s own app registration, where the admin adds the same permissions and grants consent directly inside their own tenant.
In both flows, the full permission set is added and consented to as a single unit, before any backup or restore has run.
There is no separate consent step, prompt, or admin approval that occurs specifically when an operator starts a restore — the write-capable permissions a restore call depends on are already active on the application identity from the moment the tenant is connected.
The two write-capable permissions restore depends on
Six Microsoft Graph application permissions are requested in total; four back backup’s read-only calls and are covered in Required Graph Permissions.
The two below are the only ones capable of writing, and restore is the only feature that calls them.
| Permission | Restore call that uses it |
|---|---|
Files.ReadWrite.All | Uploads a restored file back into a SharePoint or OneDrive drive — the direct single-request upload for files at or under Graph’s 4 MB simple-upload ceiling, or a resumable upload session above it. Backs in-place restore. |
Mail.ReadWrite | Posts a restored message into a target mailbox folder, including a folder in a mailbox other than the one the message was originally backed up from. Backs in-place restore for Exchange. |
Both permissions are Microsoft Graph application permissions, not delegated permissions: they authorize BYOVault’s application identity itself, independent of any signed-in user.
That is why a restore triggered by an operator in the BYOVault dashboard does not require that operator to have any Microsoft 365 role or license of their own.
The grant is tenant-wide, whether or not restore is ever used
Microsoft Graph has no mechanism to scope an application permission to a single file, a single mailbox, or to a window of time such as “only while a restore is in progress.”
Once Files.ReadWrite.All and Mail.ReadWrite are consented, they authorize writing to any file in any SharePoint or OneDrive drive, and any mailbox, across the entire connected tenant, for as long as the consent stands — from the moment the tenant is connected, regardless of whether an operator ever actually starts a restore.
A tenant that only ever runs backups, and never restores a single file or message, carries the identical write grant as one that restores constantly. The permission exists at the application level the whole time; a write call is only ever made at the moment a restore request is submitted.
Files.ReadWrite.All or Mail.ReadWrite later, only when restore is first used. All six permissions, read and write alike, are requested together as one set at connection time, on both Quick Connect and a customer’s own app registration. A security team evaluating BYOVault’s access should treat the write grant as always present, not as something that switches on only during an active restore.What BYOVault actually does with the grant
Outside of an explicit restore request, BYOVault never calls a Microsoft Graph write endpoint. Backup only ever makes read calls:
- Lists sites and drives
- Runs delta queries
- Downloads file content
- Lists mailboxes and mail folders
- Reads messages
The two write calls above execute only when an operator submits a request to restore a file in place or restore a message into a mailbox for one specific item.
They also execute when a Self-Service Portal request reaches the point of approval; see Roles & Approvals for how that approval step works before a self-service restore reaches the same write call.
Per-tenant app registrations carry the same grant
A tenant connected through its own Azure AD app registration, rather than BYOVault’s shared app, requests the identical six permissions inside the customer’s own tenant.
Using a separate app registration changes which Microsoft Graph throttling budget the tenant draws from — its own, independent of every other BYOVault customer — but it does not change the shape of the permission grant itself: the same two write-capable permissions are still consented up front, on the same terms, for that tenant’s own app.
See Your Own Azure AD App for the registration steps.