Understanding the Microsoft 365 Permissions Barracuda Email Protection Requests
When you connect Barracuda Email Protection to Microsoft 365, you're asked to approve a set of application permissions (scopes) during sign-in. This article explains what each permission is for, what data it lets us access, and why the list looks broader than what any single customer uses day to day.
Why the permission set covers more than "just scanning email"
Barracuda Email Protection is a suite – threat detection, Microsoft Quarantine management, account takeover remediation, and domain fraud protection all run through one Microsoft application registration. That registration requests the full set of permissions needed across the suite, not a custom set per customer.
This means:
Not every permission is exercised in every environment. Which ones are actively used depends on which capabilities you've licensed and enabled (for example, domain fraud protection uses different permissions than account remediation does).
The set is intentionally consistent across customers, so that turning on a capability you're already licensed for doesn't require a fresh consent prompt.
What each permission is for
Permission | What it does for you |
|---|---|
Read and write mail | Scans messages, attachments, and folders for threats; quarantines, tags, or remove malicious mail; applies mail flow rules. |
Send mail as user | Sends remediation and compromise-warning notices on your behalf when a threat is detected. |
Read mailbox settings | Reads forwarding rules and mailbox configuration to detect signs of a compromised account (e.g., a silent auto-forward rule an attacker added). |
Read users / read groups | Applies protection policies at the user and group level, and scopes Remediation actions correctly. |
Read and write all user's full profiles | Used to read profile data; write access is reserved for account-takeover remediation actions (forcing logout/password reset). Not used outside of an active incident. |
Read directory data | Reads tenant and domain configuration needed to validate setup (e.g., SPF/DKIM/DMARC records for domain fraud protection). |
Read and write directory role assignments | Assigns the Exchange Administrator role to Barracuda's service account required for Microsoft Quarantine management and mail flow configuration. |
Manage Exchange as app (Exchange.ManageAsApp) | Powers Microsoft Quarantine integration – this is the permission that lets Email Protection read, release, and manage items sitting in Microsoft's native quarantine. |
Delegated directory access | Supports admin-initiated flows such as password reset, performed under the signed-in administrator's own authorization. |
Read activity feed | Subscribes to Microsoft's security activity feed to detect and correlate account compromise signals. |
A smaller number of permissions in the requested set support capabilities that aren't active for every customer configuration – for example, device-registration auditing used only in certain remediation scenarios, or broader directory write access used by specific administrative workflows. We list the full technical scope, with Microsoft's own definitions, in the Microsoft Graph permissions reference linked at the bottom of this page.
Why we don't trim the permission list preemptively
We regularly audit which permissions our code paths actually call. That said, we don't remove a permission from the live application registration unless we can verify, with certainty, across our entire customer base, that no configuration depends on it.
The reason is simple: this is a security product running in production for thousands of tenants. Revoking a scope that turns out to still be load-bearing for some customer's configuration – even a rare one – risks silently breaking quarantine handling, remediation, or domain protection for that customer, with no warning before it happens. We treat that risk as unacceptable, so the bar for removing a permission is full validation across the install base, not just an absence of evidence in our own review.
Where our review found a permission genuinely tied to no functionality, we've noted that internally and continue to validate it – but we won't publish a removal date until that validation is complete.
Questions about a specific permission
If your security team needs a permission-by-permission justification for an internal review or audit, contact Barracuda Support and reference this article – we can provide additional detail on request.
Related Microsoft documentation
Microsoft Graph permissions reference Microsoft Graph permissions reference - Microsoft Graph