1Security + Defender for Cloud Apps
Defender for Cloud Apps sees the session. 1Security shows the 200,000 files behind it.
Defender for Cloud Apps tells you which cloud apps your people use, controls what happens inside a live session and governs the OAuth apps they consent to. 1Security adds the part that lives outside any session: every file, site and mailbox each user, app and AI agent in your Microsoft 365 tenant can open right now - typically hundreds of thousands per ordinary account - and three years of what they actually did.
What Defender for Cloud Apps does
App discovery, session control and OAuth governance in one product.
Built into Microsoft Defender, so its signals land in the same incidents your SOC already works.
Cloud app discovery with risk scores
Traffic logs are matched against a catalog of more than 31,000 cloud apps, each scored on over 90 risk factors. You see what the organization actually uses, on and off the corporate network, and sanction, unsanction or block from one place.
Session control in real time
Conditional Access app control puts policy inside the live session: monitor sessions from low-trust contexts, block downloads of sensitive data to unmanaged devices, watch external collaboration as it happens.
OAuth apps under governance
The apps your users consent to, the permissions they hold, unused apps and expired credentials - monitored, with every signal correlated at incident level inside Microsoft Defender.
What you still need
A session ends. The permissions behind it stay.
Session control decides what happens while someone is connected, and it is exactly the right control for the moment of access. The question that comes next is standing access: what that same account, app or agent could open at any time, whether or not a session is running.
Inside Microsoft 365 that access is assembled from direct grants, sharing links, nested groups and site inheritance. In a typical tenant an ordinary account can open a couple of hundred thousand files, thousands of "anyone" links never expire, and 30-50 consented apps have no active user left. None of that shows up as a session, because nobody has to start one for it to exist.
That is the layer 1Security is built for: resolve who can reach what, keep three years of what they did, and stage the fix. Next to Defender for Cloud Apps you get both halves - the session as it happens, and the access underneath it.
What 1Security adds
The access under the session, resolved and kept.
Read-only connection, first findings the same day, on standard Microsoft 365 licenses.
- 01
Who can open what, resolved
Every file, site and mailbox an account, app or AI agent can reach - through direct grants, sharing links, groups and inheritance - answered in minutes. A blast-radius question that used to take a day of exports takes ten.
- 02
Apps and consents, with reach
Every consented app in the tenant with the permission scopes it holds and what those scopes actually open. The 30-50 apps nobody uses any more, and the handful with tenant-wide read into sensitive sites, are one filter each.
- 03
Three years of who did what
Every action attributed to the user, file, app, device and location, kept up to three years on standard licenses, with each account scored against its own baseline. When a session raises a question, the history is already there.
- 04
Fixes staged behind a review window
Revoke access, expire links, remove idle guests, disable an account - staged as per-resource proposals behind a 72-hour review window, with owner review available. Nothing irreversible happens without a person saying yes.
How the two fit
One product for the session, one for the access behind it.
Defender for Cloud Apps stays where it is: app discovery, session policy and OAuth governance, correlated inside Microsoft Defender. 1Security connects to the same tenant read-only, with no agents, and holds the layer underneath: who can reach what, who actually did, and which permissions should not exist any more. When a Defender for Cloud Apps alert names an account or an app, 1Security shows what it could open and what it touched - and Defender's own alerts appear inside 1Security already linked to the users, groups and apps they concern.
- Same dayfrom read-only consent to first findings
- 10 minto a blast-radius answer that used to take a day
- 3 yearsof attributed activity on standard licenses
Joint use case
NIS2 asks who can access what, and whether it worked.
NIS2 Article 21 requires essential and important entities to run access-control measures and to show that they work. The regulator's questions are concrete: who can access what, why, and what happened when that access was misused.
Together the two products answer both halves. Defender for Cloud Apps enforces the moment of access: sensitive downloads blocked on unmanaged devices, external collaboration watched live, risky OAuth grants governed. 1Security supplies the standing evidence: the resolved access of every identity as of today, three years of activity behind each one, and remediation staged with a recorded human decision.
When the auditor asks who could open the finance site on the day of the incident, it is a lookup, not a project.
Integration
Alerts in both directions, no agents.
Defender and Sentinel security alerts are read into 1Security and shown next to the users, groups and apps they concern. In the other direction, your SIEM can poll 1Security's read-only REST API for security alerts, 1Security's own monitoring alerts and the attributed activity feed, with an API key scoped to exactly those feeds.
Keep the session covered. Add the access behind it.
Defender for Cloud Apps already watches your apps in motion. Connect 1Security read-only and see, the same day, what every account and app in the tenant can actually open.
Or keep answering "who has access to what" by hand.