--- 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. 1Security reads the Entra device directory, not Intune - Intune is never required. (If you do run Intune, it fills in the compliance and managed-state columns; without it they stay empty.) - [Automations](/en/docs/screens/automations) and the whole remediation layer: file and link remediation, group and site membership, disabling users, apps and agent identities, revoking app consent grants, assigning and removing licenses - including removing a Copilot license. The only exceptions are the two Copilot search-exclusion actions listed below. - [Agents](/en/docs/agents) discovered through Entra Agent ID - agent identities and blueprints are readable on every Entra tenant, no license attached. ### What needs a premium Microsoft SKU A handful of features depend on something Microsoft itself puts behind a higher tier. Each one degrades on its own - the rest of the platform is unaffected, and 1Security detects the missing tier and skips cleanly rather than erroring. | Feature | What it needs | Without it | | :--- | :--- | :--- | | **Purview SIT detections** | Microsoft Purview Content Explorer - Microsoft 365 E5, E5 Compliance, or the Information Protection & Governance add-on | 1Security's own sensitivity engine still classifies everything - you lose the Microsoft second opinion, not the finding. See [Sensitivity](/en/docs/sensitivity). | | **Sensitivity labels** | Microsoft Purview Information Protection - Microsoft 365 E3 / E5 or Business Premium (labels have to exist in the tenant before there is anything to read) | The [Sensitivity Labels](/en/docs/screens/sensitivity-labels) screen stays empty. 1Security's own classification is unaffected. | | **Sign-in-level detail** | **Entra ID P1** - included in Microsoft 365 E3 / E5, Business Premium and EMS, not in Office 365 E1 / E3 / E5 | Activity keeps flowing in full from the unified audit log. What stays empty: per-user last sign-in time, per-sign-in Conditional Access attribution, and the Conditional Access policy inventory. 1Security detects the missing tier on the first call and skips that branch permanently. | | **Native security alerts** | Microsoft Defender (any workload that emits alerts) | Defender's alerts and incidents don't flow in. 1Security's own anomaly detection is unaffected. | | **Copilot search exclusion** | Both of the things Microsoft requires for Restricted Content Discovery: a **base subscription** - Office 365 E1 / E3 / E5 / A5 or Microsoft 365 E3 / E5 / A5 - **and** one **advanced management** route: a **Microsoft 365 Copilot** license assigned to at least one user (seats you own but have assigned to nobody do not count), **Microsoft 365 E7**, or the **SharePoint Advanced Management Plan 1** add-on | The two actions that exclude a site from Copilot and org-wide search (`Site_BlockCopilotOrgWideSearch` / `Site_AllowCopilotOrgWideSearch`) fail cleanly. Every other site-settings action works on any SharePoint plan. Once you connect, the **Action readiness** screen reads your subscriptions and says which of the two parts is missing, beside the action. | | **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. Depth follows Microsoft's audit retention: 180 days on every plan, 365 days with E5, up to 10 years with the 10-Year Audit Log Retention add-on | Forward audit-log polling keeps running - only the backfill of history from before you connected stays dormant. | | **Automatic audit-log enablement** | **Entra ID P2** - the audit module grants itself Exchange Administrator as a time-boxed (2 hour) PIM assignment, and PIM is a P2 feature | Audit ingestion itself is unaffected. Only the convenience of 1Security checking and turning on the unified audit log for you is lost - flip it on once yourself, see [Tenant settings](#tenant-settings). | The Copilot row follows Microsoft's SharePoint Advanced Management prerequisites page, which lists no Business plan. On Business Basic / Standard / Premium with Copilot, 1Security reports the two actions as not ready even though they will very likely run - buy nothing on the strength of that verdict alone. ### Check your tenant before you connect This section is for Microsoft 365 administrators: the check below reads your tenant's subscriptions, which takes a role that can see **Billing** in the Microsoft 365 admin center - Global Administrator, Billing Administrator or License Administrator. Without one of those you will hit a permissions wall at the first step. It is advisory. It compares the licenses your tenant holds against the same bundle table 1Security uses after you connect, and it assumes your base subscription is active - a lapsed or cancelled subscription still appears in the list for a while, and no prompt can see that. Microsoft decides what runs; this tells you what to expect. The check 1Security runs after you connect also matches subscriptions by their GUID, so it can only be more generous than this page, never less. ## 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. The assignment is deliberately time-boxed to **2 hours** through Privileged Identity Management, which means it needs **Entra ID P2** - on tenants without P2 the assignment doesn't complete, audit ingestion still runs in full, and the only loss is that 1Security cannot check or enable the unified audit log for you. - **Purview module** - the same permission pattern as a standing assignment (no PIM, no P2), 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) Policy.Read.All (optional - Conditional Access inventory 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 Optional (each unlocks only its own actions): Application.ReadWrite.All (app & agent enable / disable, assignment requirement) DelegatedPermissionGrant.ReadWrite.All (revoke app consent grants) AppRoleAssignment.ReadWrite.All (remove app role assignments) ``` 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. Users' browsers need outbound HTTPS (443) to `app.1security.ai` and `api.1security.ai` - the full hostname list, and what to do when a web filter classifies 1Security as an AI site and blocks it, is in [Network Requirements](/en/docs/network-requirements). - **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 tenant has no Entra ID P1 license (it comes with Microsoft 365 E3 / E5, Business Premium and EMS - Office 365 E1 / E3 / E5 don't include it). Microsoft serves the sign-in log API, per-user sign-in activity and the Conditional Access inventory only to P1 tenants. Everything sourced from the unified audit log - the activity feed, locations, devices, anomalies - is unaffected. 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. No license? The free admin-center registry export covers it manually: upload the CSV with **Import registry export** on the Agents screen - 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.