Required Graph Permissions
Six Microsoft Graph application permissions back every backup and restore call BYOVault makes into a Microsoft 365 tenant. This page lists each one against the specific call it authorizes, whether that call runs during backup or restore, and nothing more — the same six permissions apply identically to Quick Connect and to a tenant's own app registration.
Why application permissions, not delegated
Every permission below is a Microsoft Graph application permission, granted once by a tenant admin at connection time and exercised by BYOVault’s own application identity — never a delegated permission tied to a signed-in user.
BYOVault’s backup and restore jobs run on a schedule with no user present to sign in, so a client-credentials (app-only) token is the only workable model: the admin consents once, for the whole tenant, and every subsequent Graph call authenticates as the application itself.
The six permissions
| Permission | Why BYOVault needs it |
|---|---|
Sites.Read.All | Lists every SharePoint site in the tenant and, for each site, its document libraries (drives), so backup knows what exists to back up in the first place. |
Files.Read.All | Runs the delta query that detects new, changed, and deleted items in a drive since the last backup, and streams file content in chunks during backup. |
Files.ReadWrite.All | Writes a restored file back into its original (or a recreated) folder path in a SharePoint or OneDrive drive — either a direct upload for files at or under Graph’s 4 MB simple-upload ceiling, or a resumable upload session above it. Called only during restore, never during backup. |
Mail.Read | Lists a mailbox’s folders and runs the delta query that detects new and changed messages in each folder since the last backup. |
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. Called only during restore, never during backup. |
User.Read.All | Enumerates licensed users in the tenant to build the mailbox list for Exchange backup, and resolves a specific user in order to read that user’s OneDrive for backup. |
User.Read delegated permission to every new app registration automatically, at creation time — it is not one of the six permissions above, and BYOVault never requests or uses it, since an application-permission-only app has no signed-in user for a delegated permission to act on behalf of. Its presence on the API permissions page is expected and harmless; it does not need admin consent and can be left as-is.Read scopes back backup; write scopes back restore
Four of the six permissions — Sites.Read.All, Files.Read.All, Mail.Read, and User.Read.All — are read-only, and are the only permissions BYOVault uses during a normal backup run.
The remaining two — Files.ReadWrite.All and Mail.ReadWrite — are the only permissions capable of writing. BYOVault writes only when an operator explicitly starts a restore for one specific file or message.
See Restore Permissions & Scopes for how that write grant behaves in practice, including why it is present tenant-wide from the moment of connection regardless of whether restore is ever used.
Where to grant these
A tenant admin adds these six permissions and grants admin consent either on BYOVault’s own shared Azure AD app (via Quick Connect’s tenant-wide admin-consent redirect, with no setup required on the admin’s side) or on an app the admin registers and controls directly inside their own tenant. See Your Own Azure AD App for the step-by-step walkthrough of the second path, including where in the Azure Portal each permission is added.