Office 365 access management
An ordinary account can open 200,000 files. See why. Close it.
Access in Microsoft 365 is assembled from direct grants, sharing links, nested groups, site inheritance and app consents, and adding them up is the hard part. In a typical tenant an ordinary user can reach hundreds of thousands of files without anyone granting that on purpose. 1Security resolves it all into one live permission graph: click a user and see every file they can open, click a file and see everyone who can open it, and revoke access in one reviewed action.
- 200,000+files an ordinary account can typically open through groups, links and inheritance
- 98%of granted permissions go unused, per Microsoft's cloud permissions research
- 10 minfrom a permission change in Microsoft 365 to the graph reflecting it, at any tenant size
The gap
A grant is easy to see. What a person can actually open is the sum of hundreds of them.
Site membership, directory groups, mailbox delegation and Teams membership each hold one piece of the answer. The join is the work.
Real access in Microsoft 365 is assembled: a direct grant here, a sharing link there, membership in a group that sits inside another group that owns a site, plus everything a consented app can touch. Ask "what can this user open?" without a graph and the honest answer is a script per site, a spreadsheet, and a result that is stale before the export finishes.
That is why access reviews take weeks and still miss the biggest holes. A reviewer looking at group membership never sees the anyone link created in 2023. A directory-based guest review does not surface SharePoint-only guests - external identities invited straight into a site that never became directory objects - and most mid-size tenants have dozens of them.
The numbers we see on first connection are consistent: an ordinary employee account reaching 100,000-300,000 files, a handful of nested groups that quietly unlock a third of the tenant, and the large majority of granted permissions never used. 1Security computes effective permissions for every identity and every resource and keeps them current, so the question stops being "export three reports and cross-reference" and becomes "click the user".
What you get
The permission graph, from a user to a single file and back.
One model covers users, guests, groups, third-party apps and AI agents on one side, and sites, files and mailboxes on the other.
Effective permissions, resolved
Multi-level nested groups, SharePoint site inheritance, sharing links and app grants flattened into what an identity can actually open - not what one screen says was configured. Files reachable is a sortable column on Users.
Walk it in both directions
Open a user: every file they can open, sorted by sensitivity. Open a file: every person, group, link, app and agent that can open it. Every hop is a real server-side filter, one click each.
The why behind every grant
Each path carries its source: direct grant, sharing link, group chain (which group inside which group), site inheritance, app consent. You see the exact path that produced the access, which is what you need to remove it without breaking something else.
Access branches with sensitive counts
The user access graph splits reach by source - OneDrive, sharing links (view, edit, review, disabled links included), files received by email, group membership - with the count of sensitive files on every branch, so you review the risky path first.
SharePoint-only guests included
External identities invited straight into a site never become directory objects and are easy to miss in a directory-based review. 1Security lists them as identities like any other, with what they can reach.
Revocation with a blast radius
Remove access resolves every grant behind a person's reach - direct, link, group, site membership - shows what each removal disconnects, removes what it safely can and asks before anything it cannot. Automated runs wait behind a 72-hour review window.
One map
Audit by clicking through, not by exporting.
The graph is not a report you generate. Every screen in the product is a view of it.
Pick a user: their groups, then the sites those groups unlock, then the files on those sites that carry sensitive data, then everyone else who can read the same files. Each hop is one click and each hop is filtered - "files this user can reach" is a real filter on the Files screen, not a spreadsheet exercise. A blast-radius question that used to be half a day of scripting is a ten-minute walk.
The same walk works for a group, a guest, an app, an AI agent or a single sharing link. When an incident names an account at 3 AM, its reach - every file, site and mailbox it could open - is a lookup, and what it actually touched sits next to it in up to three years of Activity logs.
In practice
An offboarding audit, start to finish.
The identity everyone forgets to fully close out - and the workflow that closes it.
- 01
Measure the reach
Open the leaver in Users: groups, files reachable, sharing links they created, sensitive files in reach, apps they authorised. In a typical tenant that row says 150,000 files and 30 links - the size of what one credential still opens, before you touch anything.
- 02
Revoke by source
Remove access resolves their direct grants, group memberships and site roles, shows what each removal disconnects, and stages the change. Disabling the account alone leaves group and link access in place for anyone who still holds the credential or the link.
- 03
Expire what they left behind
Sharing links the account created keep working after the account is disabled - anyone links for years. The graph lists every one; expiring them is part of the same action, not a separate hunt.
- 04
Reclaim and record
The license goes back to the pool and every step lands in Actions with the approver and the timestamp - evidence that offboarding happened, not a checklist that says it should have.
The difference
The joins only a permission graph can make.
The data behind each of these lives in a different place. The graph joins it once and keeps it joined.
- Every file a specific user can open, as one filter - resolved through groups, links and inheritance
- SharePoint-only guests: external access counted even though it lives outside the directory
- Sharing links without a password and links past their expiry date, tenant-wide, with the file and the creator
- The exact chain that produced an access: which group, inside which group, granted by whom
- Sensitive-file counts per access branch, so the risky path is reviewed first
- Apps and AI agents as identities on the same graph as people, with the same reach numbers
- A permission change reflected in about 10 minutes, at any tenant size
- The whole graph maintained at 500M+ files in production tenants
Deployment
Read-only first. First reach numbers the same day.
One read-only consent connects the tenant; no agents, no appliances, no log forwarders. Write actions are a separate opt-in consent, and every automated change waits behind a review window - 72 hours by default. Works on standard Microsoft licensing from Business Basic up: no E5, no Entra P2. Each customer tenant lives in its own dedicated database.
- Same dayfrom read-only consent to the first "what can this account open" answer
- 0agents, appliances or log forwarders to deploy
- Business Basicthe license floor - no E5, no Entra P2
Use cases
The questions this answers.
Before a Copilot rollout: Copilot reads exactly what each user can already reach, so "what would AI inherit" is the same lookup - per user, per site, with sensitive counts.
During an incident: an account is compromised at 3 AM. Every file, site and mailbox in its reach, and what it actually touched, is minutes of clicking, not a day of log stitching.
For the auditor: access reviews built on effective permissions instead of group listings, exportable, with a remediation trail. Least privilege becomes a number you can show, not a sentence you assert.
Microsoft 365 Audit Tool
Up to three years of activity behind every access decision - what the account did with what it could reach.
See the audit tool →Microsoft 365 Inventory Tool
Every site, OneDrive, app, agent and device the graph is built on - counted live, hidden channel sites included.
See the inventory →SharePoint Governance Tool
The resource side of the same graph: every site ranked by external exposure and abandonment.
See SharePoint governance →
FAQ
Common questions.
How is this different from Entra ID access reviews?
Entra access reviews certify group and app membership, and do that well. 1Security adds the layer underneath - effective access: what an identity can actually open once nesting, SharePoint inheritance, sharing links and app grants are added up. It also lists SharePoint-only guests, so the review covers external access that lives outside the directory.
Do we need Microsoft E5 or Entra P2?
No. The permission graph works on standard Microsoft licensing from Business Basic up. Premium SKUs matter only for optional extras such as Purview label sync or Defender alert ingestion.
Can 1Security change permissions without approval?
Not by default. The base connection is read-only. Remediation is a separately consented module, and automated actions stage proposals behind a review window - 72 hours by default, configurable to instant, 24 hours, 7 days or manual-only.
How current is the access data?
Permission changes appear in about 10 minutes regardless of tenant size. The initial full scan of a very large tenant takes longer - a million-file tenant maps in hours, 500M+ files in weeks - and the graph updates continuously from then on.
Does it cover apps and AI agents too?
Yes. Third-party apps, OAuth consents, managed identities and AI agents are identities on the same graph, with the files they can reach and the sensitive data among them counted exactly as for a user.
Stop reconstructing access. Look it up.
Connect read-only and see, the same day, what your own users, guests, apps and agents can actually open - every identity, every grant, every path.
Or keep cross-referencing exports that are stale before the merge finishes.