--- title: Requirements description: Exactly what 1Security needs before you connect - which Microsoft 365 licenses count, which admin roles are used and when, every permission requested per module, and what stays optional. icon: ClipboardCheck --- # Requirements Everything 1Security needs from your tenant, in one place: the license check that runs at connect time, the admin roles involved, the exact permissions each module requests, and the handful of things that genuinely need a premium Microsoft SKU. The headline: **1Security runs on a standard Microsoft 365 license.** There is no agent to install, no appliance, no log forwarder, and no E5 requirement for the core product. ## Microsoft 365 licensing ### The one hard requirement Your tenant needs **at least one user with a license that includes SharePoint Online.** That is the whole check. 1Security verifies it at connect time and blocks with _"Your tenant does not have the required license"_ if no qualifying subscription is found. Any of these qualify (the list is matched on subscription SKU, so equivalents and regional variants count too): | Family | Plans that qualify | | :--- | :--- | | **Business** | Business Basic, Business Standard, Business Premium | | **Enterprise** | Office 365 E1 / E3 / E5, Microsoft 365 E3 / E5 | | **Frontline** | Microsoft 365 F1 / F3 (including the EEA "no Teams" variants) | | **Standalone SharePoint** | SharePoint Online Plan 1, Plan 2, Office for the web | | **Developer & Government** | E3 / E5 Developer, GCC High and DoD variants of E3 / E5 | The license is checked at the **tenant** level, not per seat. 1Security does not need a license for every user it maps - it needs the tenant to have SharePoint Online, because that is what makes the Microsoft Graph endpoints 1Security reads available at all. ### What needs nothing extra These all work on Business Basic - no E5, no add-ons, no premium sign-in logs: - The full [permission graph](/en/docs/permission-graph) - users, groups, sites, files, apps, agents, devices. - [Sensitivity scanning](/en/docs/sensitivity) with 1Security's own engine (300+ detectors, OCR included). - Up to three years of [activity history](/en/docs/screens/activity-logs), well past Microsoft's default retention. - [Location intelligence](/en/docs/location) - enrichment runs locally, no premium sign-in log add-on. - [Devices](/en/docs/screens/devices), including unregistered and shadow devices. - [Automations](/en/docs/screens/automations) and the whole remediation layer. ### What needs a premium Microsoft SKU Four features depend on something Microsoft itself puts behind a higher tier. Each one degrades on its own - the rest of the platform is unaffected. | Feature | What it needs | Without it | | :--- | :--- | :--- | | **Purview labels & SIT detections** | Microsoft Purview (Information Protection / Content Explorer) | 1Security's own sensitivity engine still classifies everything - you lose the Microsoft second opinion, not the finding. See [Sensitivity Labels](/en/docs/screens/sensitivity-labels). | | **Native security alerts** | Microsoft Defender | Defender's alerts don't flow in. 1Security's own anomaly detection is unaffected. | | **Copilot agent catalog** | **Microsoft Agent 365** on the one admin who connects the tenant (~$15/user standalone, or bundled in E7) | Entra-backend agents are still scanned in full; declarative Copilot agents look like ordinary enterprise apps. Details in [Agents](/en/docs/agents). | | **Historical audit backfill** | The `AuditLogsQuery.Read.All` permission granted on the read app | Forward audit-log polling keeps running - only the backfill of history from before you connected stays dormant. | ## Admin roles | When | Who has to do it | Why | | :--- | :--- | :--- | | Initial consent, and each extension module | **Global Administrator** | Microsoft requires a Global Admin to grant tenant-wide application permissions. | | Purview module | An admin who can edit Purview role groups | The 1Security service principal must be added to the **Content Explorer List Viewer** role group before Purview detections can be read. | | Day-to-day use | No Microsoft admin role at all | Analysts work inside 1Security. Access there is governed by [1Security's own roles](/en/docs/getting-started#managing-accounts-and-access). | Consent is a one-time action per module. If you are not a Global Admin, ask one to complete the consent flow - you can still own day-to-day operations afterwards. ### Directory roles 1Security assigns to itself Two modules need a Microsoft role on their own service principal, because the underlying API is Exchange-based rather than Graph-based. This is why those modules request `RoleManagement.ReadWrite.Directory` - it is used to make exactly one assignment, to 1Security's own application: - **Audit module** - assigns **Exchange Administrator** to the audit app's service principal, so it can read the unified audit log configuration through Exchange Online PowerShell. - **Purview module** - the same permission pattern, paired with the Content Explorer List Viewer role-group membership above. ## Tenant settings - **Unified audit log must be turned on.** It is on by default in most tenants. 1Security checks its status and, once the audit module is connected, can turn it on for you - or you can do it yourself first, see [Microsoft's guide](https://learn.microsoft.com/en-us/purview/audit-log-enable-disable). Without it, Microsoft records no activity for anyone to read, so the [Activity Logs](/en/docs/screens/activity-logs) screen stays empty. - **No other tenant configuration is required.** No mail flow rules, no conditional access exceptions, no service accounts, no mailbox impersonation. ## Permissions, module by module 1Security follows least privilege literally: the base install is **read-only**, and every capability that needs more permission is a separate consent you grant only if you want the feature. Write access exists in exactly two modules, both opt-in. ### Core visibility - read-only, granted at install Microsoft Graph: ```text User.Read.All Group.Read.All GroupMember.Read.All Directory.Read.All Files.Read.All Sites.Read.All Organization.Read.All Application.Read.All Team.ReadBasic.All Reports.Read.All Insights-UserMetric.Read.All UserAuthenticationMethod.Read.All AuditLog.Read.All SecurityAlert.Read.All SecurityIncident.Read.All Sites.FullControl.All AuditLogsQuery.Read.All (optional - historical audit backfill only) ``` SharePoint: ```text Sites.Read.All User.Read.All Sites.FullControl.All ``` **Why `Sites.FullControl.All` appears in a read-only module.** SharePoint's own API offers no read-only scope that exposes site-collection sharing settings and permission inheritance - the data the permission graph is built from. The visibility module only ever issues read calls with it. Nothing in 1Security writes to your tenant until you enable the Automations or Mailbox Management module below. ### Audit log ```text Office 365 Management API: ActivityFeed.Read, ActivityFeed.ReadDlp Microsoft Graph: RoleManagement.ReadWrite.Directory ``` The Graph permission is used only for the Exchange Administrator self-assignment described above. ### Purview ```text Microsoft Graph: RoleManagement.ReadWrite.Directory ``` Plus membership of the **Content Explorer List Viewer** role group in Purview. ### Email visibility ```text Mail.Read Domain.Read.All ``` Read-only access to mailbox contents. Message bodies and attachments are read during analysis, not stored. ### Mailbox management (optional, write) ```text Mail.ReadWrite ``` Granted **separately** from email visibility - you can read mailboxes without ever allowing changes. Lets an automation quarantine or flag a message rather than only alerting on it. No permanent deletion. ### Automations (optional, write) ```text Microsoft Graph: Files.ReadWrite.All, Group.ReadWrite.All, GroupMember.ReadWrite.All, User.ReadWrite.All SharePoint: Sites.FullControl.All ``` The only module that can change anything in your tenant. Actions are staged behind review queues and grace periods - see [Automations](/en/docs/screens/automations). ### Copilot agents (optional) ```text CopilotPackages.Read.All (delegated, on the read app) ``` Delegated rather than application permission, which is why Microsoft validates the **license of the single admin who connected the tenant** rather than every user. See [Agents](/en/docs/agents). ## Clients and network - **Browser** - Chrome, Edge, Firefox or Safari, last two major versions. Nothing to install: no extension, no desktop agent, no endpoint software. - **Cloud (SaaS)** - nothing to open on your side. 1Security calls Microsoft, not your network. - **BYOC and On-Premise** - the deployment needs outbound HTTPS (443) to the Microsoft endpoints 1Security calls: `login.microsoftonline.com`, `graph.microsoft.com`, `manage.office.com`, `.sharepoint.com` and `-my.sharepoint.com`, plus the Exchange Online and Security & Compliance PowerShell endpoints (`outlook.office365.com`, `*.compliance.protection.outlook.com`) used by the audit and Purview modules. Hardware and Azure resource sizing is in [Installation](/en/docs/installation). ## When a prerequisite is missing No subscription in the tenant includes SharePoint Online, or no user has been assigned one. Assign a qualifying license (see the table above) to at least one user and reconnect - a trial license is enough to verify. Two normal causes. Either Azure is still propagating the application permission assignment - this can take a few minutes after consent - or a module was added after the original consent and needs its own grant. Click **Assign permissions** in the banner to re-run the consent flow for what's missing. Check that the unified audit log is enabled in your tenant. Microsoft records nothing while it is off, and no tool can recover activity from that period afterwards - which is why turning it on is the first thing worth doing, even before connecting 1Security. The 1Security service principal is almost certainly not a member of the **Content Explorer List Viewer** role group. Purview exposes Sensitive Information Type detections only to members of that group, so the connection succeeds while every query comes back empty. The admin account that connected the tenant has no Microsoft Agent 365 license, so Microsoft won't return the agent catalog. One standalone Agent 365 license on that one admin unlocks the whole tenant's catalog - see [Agents](/en/docs/agents). Next: pick a deployment model in [Installation](/en/docs/installation), then see what the [first scan](/en/docs/scans) does with the access you granted.