Overe is a Microsoft 365 security operations platform built around four pillars: Assess, Harden, Monitor, and Respond.
When you connect a tenant, Overe asks you to consent to a single set of Microsoft permissions. Every permission below maps to a specific pillar and a specific job. Nothing is requested that is not used.
Configured does not mean enforced. Overe uses these permissions to validate that your Microsoft 365 controls are actually working, not just that they exist.
Who needs to grant consent
The Overe consent link can be sent to any administrator in the tenant, but the person who clicks it needs a role with authority to consent to Microsoft Graph application permissions.
Recommended: Privileged Role Administrator
This is the least-privileged role that can complete an Overe installation. It can consent to the permissions Overe requests and assign the required directory roles to the Overe service principal. If your organisation would rather not use a Global Administrator account for an application consent step, this is the role to use.
Also works: Global Administrator
A Global Administrator can complete the same steps. Many smaller tenants only have Global Administrators available, and that is fine. Privileged Role Administrator is simply the tighter option where you have the choice.
Not sufficient: Application Administrator and Cloud Application Administrator
These roles cannot consent to Microsoft Graph application permissions, which is most of what Overe requests. They also cannot assign directory roles to an enterprise application. If you send the consent link to someone holding one of these roles, they will not be able to complete the installation.
Overe does not create an account in your tenant
This is worth being clear about, because some Microsoft 365 security tools work differently.
Overe does not create a user account. There is no dedicated service account, no break-glass administrator, no licensed identity, no password, and nothing to enrol in MFA. There is no standing credential in your tenant that can be signed into, phished, or compromised.
What Overe installs is a service principal: an enterprise application holding the specific permissions listed below and nothing beyond them. You can see it at any time under Entra ID, Enterprise applications.
Overe never holds Global Administrator or Privileged Role Administrator. That role is needed once, by the person granting consent, at the moment of installation. After that, Overe operates entirely through the consented permissions on the service principal.
Permissions Overe requests
Permission | Pillar | What it is for |
Assess, Harden | Read user and directory objects to identify risky accounts, and support the admin consent request approval control. | |
Assess, Harden | Read licensing information for posture and licence assessment, and support Exchange Online policy controls. | |
Assess | Access secure scores for posture assessment. | |
Assess | Read sharing link expiration settings. | |
Harden | Verify that policies are being applied as expected. | |
Harden | Read and manage Conditional Access policies. This is the permission behind Conditional Access Assurance, which validates that your Conditional Access policies actually enforce MFA and other controls across every authentication path, not just that the policies exist. | |
Harden | Manage the policy controls related to MFA. | |
Harden | Manage the application consent settings control. | |
Harden | Manage the user application consent settings control. | |
Harden | Manage the password expiration and validity control. | |
Harden | Manage policy controls related to Exchange Online. | |
Harden | Manage policy controls related to SharePoint Online. | |
Harden | Manage policy controls related to SharePoint Online site collections. | |
Harden, Platform | Manage policy controls dealing with app permissions. Also used to remove the Overe application from your tenant during offboarding. | |
Monitor, Assess | Review audit logs for a detailed history of user actions, making it easier to trace malicious activity. Also reads user registration details for posture assessment. | |
Monitor | Read tenant activity for anomaly detection. | |
Monitor | Read data loss prevention events for anomaly detection. | |
Monitor | Read service health information alongside activity signals. | |
Respond | Used in response actions to disable accounts and revoke sessions. | |
Platform | Read details of delegated admin relationships with customers to streamline site creation. | |
Platform | Used during the delegated onboarding flow. |
Requested for future use
The following permissions are included in the consent set but are not currently in active use. They are listed here so that the consent screen holds no surprises.
MailboxSettings.ReadWrite, Reports.Read.All, SecurityIncident.Read.All, SecurityAlert.Read.All, SecurityIdentitiesHealth.Read.All, IdentityRiskEvent.Read.All, ThreatIntelligence.Read.All, UserAuthenticationMethod.ReadWrite.All, DeviceManagementApps.ReadWrite.All, DeviceManagementManagedDevices.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All, DeviceManagementServiceConfig.ReadWrite.All, AiEnterpriseInteraction.Read.All
What these permissions enable
Conditional Access Assurance: enforcement validation across every authentication path, not just policy existence
Automated hardening of Microsoft 365 and identity controls
Continuous monitoring for configuration drift and behavioural signals
Guided Security Operations: a structured workflow for each finding, addressing root cause rather than symptom
Auto Response Engine: account containment, MFA enforcement, and session revocation without waiting for manual action
Posture visibility across MFA coverage, security policy state, external app integrations, inactive accounts, and which controls your current Microsoft licence tier allows
Directory roles assigned to the Overe application
Alongside the permissions above, two Microsoft directory roles are assigned to the Overe service principal.
Exchange Administrator. Enables and verifies the audit log so that Overe can monitor activity and detect anomalies, and configures email policy controls including those covering attachments and secure protocols.
Teams Administrator. Reads and configures Microsoft Teams policy controls.
Both roles are assigned to the Overe application, not to a user account. Assigning a directory role to an enterprise application requires Privileged Role Administrator or Global Administrator, which is why those are the roles listed above.
These are workload-scoped roles. Overe holds no tenant-wide administrative role, and there is no account behind them that can be signed into or have its password reset.
You can find additional detail on assigning these roles in the video guide below.
How to re-consent to Microsoft permissions
Some scenarios require you to re-consent the permissions granted to the Overe app. See Giving consent to missing Microsoft permissions.
Offboarding
To remove Overe from a tenant, use the offboarding process in the Overe console. Offboarding removes the Overe application registration from your tenant automatically. Because Overe never created a user account, nothing else is left behind.
Overe uses Application.ReadWrite.All for this. The narrower Application.ReadWrite.OwnedBy permission is not sufficient, because Overe is not registered as the owner of its own application inside your tenant.
Do not remove Overe by deleting the enterprise application directly in Entra ID. That cuts off access, but it leaves the tenant in a partial state in Overe and does not end an existing agreement or stop billing. Always offboard from the console.
Before you consent
Overe requests these permissions once, at tenant connection. The 14-day full product trial uses the same permission set as a paid site, so what you see during the trial is what you get afterwards.