Your staff are already using SaaS you never approved, and something has permission to read your mail.
It finds which subscription software is actually in use across your company, scores each one against more than ninety risk indicators, surfaces the misconfigurations sitting in the applications you did approve, and governs the applications holding standing permission to your data. Most companies find all four categories uncomfortable reading, and every SOC 2 auditor and insurance questionnaire now asks about at least two of them.

- 90+Risk indicators per discovered app
- SSPMMisconfigurations in approved apps
- OAuthApp-to-app permissions governed
- Secure ScoreFindings surfaced where you already look
What it does, and which of the four parts you genuinely need.
Shadow IT discovery, the pillar everybody expects
It works from network traffic assessed against a large catalog of applications, identifying what people across the company are actually reaching, and showing which applications are genuinely being used both on and off your network. Every cloud service gets detected and assigned a risk ranking, and every person and every outside application able to sign in gets identified. That final clause is the one everybody skims past.
More than 90 risk indicators per app
Everything discovered is evaluated against more than ninety risk indicators, and that is precisely what converts a list of application names into something anybody can act on. What you end up with is a sortable view of what is in use, ordered by how much of a problem each represents, which moves the conversation from an unmanageable inventory to a short list of applications genuinely requiring a decision.
SaaS security posture, which is usually the quickest win
The posture management side surfaces misconfigurations and recommends specific actions to strengthen each connected application, with those recommendations drawn from industry standards including the Center for Internet Security alongside whatever the application vendor themselves recommends. This concerns the applications you approved and configured yourselves, and it routinely finds settings nobody has revisited since the day somebody first set the thing up.
OAuth app governance, the pillar nobody expects
The problem is put bluntly: these applications frequently operate entirely unnoticed while holding extensive permission to reach data in other applications on somebody behalf, which makes them an attractive thing to compromise. The governance side lets you watch for applications nobody uses any more and monitor both live and expired credentials. In most tenants this is where the genuinely alarming finding turns up, because somebody consented to something in 2021 and it still holds standing access today.
Finding sensitive data where it actually sits
It connects into those applications and scans for files holding sensitive data, establishing what is stored where and who has been reaching it, with the Purview integration supplying classification types out of the box. For an American company carrying obligations under HIPAA, under CCPA and CPRA, and under the growing pile of state privacy laws, knowing where personal data genuinely lives is not optional, and it is very rarely where the policy claims it is.
Three controls once you know what is exposed
Three controls are named outright: applying a sensitivity label, blocking a download to an unmanaged device, and removing outside collaborators from a confidential file. That third one deserves real attention, because in most tenants there is a long tail of external sharing arranged for a project that finished years ago, where the access has comfortably outlived whatever reason produced it.
Behavioral analysis and adaptive access
There is adaptive access control built in, behavior analytics covering both people and other entities, and help containing malware. The behavioral half is what catches the case no policy ever anticipated: an account doing something that account has never done before, inside an application nobody was watching, with no rule having been written in advance by anybody.
One incident rather than four alerts
It feeds straight into Defender, correlating signals across every domain in the suite and producing detection and investigation at the level of an incident rather than an alert. The framing is around attacks that cross boundaries, moving sideways out of email, still the commonest way in, to compromise endpoints and identities before finally reaching data inside an application. Seeing all of that as a single timeline rather than four unrelated alerts is the practical case for staying inside one family.
A one-time SaaS inventory tells you what happened. This keeps telling you.
Whether you need a single inventory of unsanctioned software or the continuous product depends entirely on whether your problem is not knowing, or not being able to keep pace.
- A single discovery exercise gathers the evidence, builds the inventory, ranks what matters and hands you a list of decisions to make: approve it, replace it, or block it outright. It answers what is in use today, and it is the right choice where nobody has ever looked and the estate is reasonably stable.
- The product runs continuously and does three things a single exercise cannot. It keeps discovering as new applications appear, it assesses the posture of the applications you already approved, and it governs whatever holds standing permission to your data. Neither of those last two forms any part of a discovery exercise.
- For most American businesses the sequence that works is the inventory first, because it produces a decision list management can act on within a fortnight and it establishes whether the problem is large enough to justify buying anything. Where the estate genuinely moves, or where the standing permissions turn out to be the real issue, the product follows on behind.
- The exception is an organization that already knows it has SaaS sprawl, or one facing a SOC 2 audit or an enterprise security questionnaire that asks how third-party applications are governed. There, going straight to the product is the better use of the budget.
Four things deciding whether this ends up a control or merely another report.
We look at OAuth applications first
Everybody arrives asking about unsanctioned software, and nearly all of the genuinely urgent findings sit in application governance instead. Applications somebody consented to years ago, still holding extensive permissions, no longer used by a single person, and in several cases carrying credentials that expired without anybody ever withdrawing the consent. It is the fastest route to a finding that changes somebody mind about the budget.
We agree the sanctioning process before discovery runs
Discovery produces a list of applications, and a list with nobody empowered to decide anything produces precisely nothing. Before running it we establish who decides whether an application gets approved, replaced or blocked, and what route exists for somebody who genuinely needs a new tool next month. Without both, the identical list reappears next quarter, only longer.
We work the posture findings early
The posture data flows automatically into Secure Score for supported connected applications, which means those findings land somewhere your team already looks and are correspondingly easy to leave sitting untouched. They get worked through deliberately in the first few weeks, because they are concrete, they are fixable, and they reduce risk without depending on anybody being awake to answer an alert.
We are honest about when a one-time assessment is enough
If nobody has ever looked at unsanctioned software and the estate is fairly stable, a single discovery exercise may answer your question at considerably smaller scope, and you will hear us say so. The case for the product rests on continuous change, on managing the posture of approved applications, and on governing standing permissions. Where none of those three applies to you, the smaller engagement is genuinely the better purchase.
Six US situations where SaaS visibility earns its place.
Professional services with client data in a dozen tools
Consultancies, agencies and law firms accumulate subscriptions because each team adopts whatever suits the engagement in front of them. What results is client data spread across applications the firm never assessed, very often still shared with outside collaborators from a project that closed a year ago. Finding that data and reviewing the external sharing is nearly always the first thing worth doing.
A regulated firm asked to evidence third-party control
When a SOC 2 auditor, a bank examiner working through the FTC Safeguards Rule or NYDFS Part 500, or a large customer security questionnaire asks which cloud services process your data and how each was assessed, the honest answer at most firms is that nobody knows. Discovery combined with the risk indicators produces a defensible inventory, and the governance side answers the considerably harder follow-up about what holds standing access.
A company that has acquired other companies
Every acquisition arrives carrying a tenant, a pile of subscriptions and a consent history nobody has ever reviewed. The acquired estate is almost invariably less governed than the one acquiring it, and it becomes your exposure the moment the deal closes. Discovery across the combined estate is the fastest way to establish what you actually bought, and it is exactly the sort of finding now surfacing in technology due diligence.
Education, where adoption is genuinely decentralized
Teachers adopt tools because those tools work in a classroom, not because anybody in procurement approved them, and that is not a discipline problem policy can solve. Continuous discovery paired with a fast route to approval works considerably better than a ban everybody ignores, and the risk indicators let you separate the tool that is entirely fine from the one placing student records somewhere your FERPA obligations cannot follow.
Retail and hospitality with high staff turnover
Accounts, shared logins and outside integrations accumulate considerably faster than anybody removes them. Behavioral analytics running against accounts nobody watches, alongside a review of the standing permissions and the external sharing, reliably surfaces a long tail of access that should have gone the week somebody left.
Any organization that has never audited OAuth consent
Which describes almost every company. Somebody clicked accept on a permission prompt one afternoon, the application still holds exactly those permissions, and nobody has looked at the list since. These are described as behaving entirely unnoticed while holding extensive permission, and reviewing them is a short exercise with a consistently startling result.
What organizations can actually see across their SaaS estate.
| Feature | Full SaaS visibility | Microsoft apps only | No SaaS visibility |
|---|---|---|---|
Know which SaaS is in use | Yes | Partly | No |
Risk ranking of discovered apps | Yes | No | No |
Misconfigurations in approved apps surfaced | Yes | Partly | No |
OAuth apps with standing permissions known | Yes | No | No |
Unused OAuth apps identified | Yes | No | No |
Sensitive data located across SaaS | Yes | Partly | No |
External collaborators reviewable | Yes | Partly | No |
Downloads to unmanaged devices controllable | Yes | Partly | No |
SaaS signals correlated with email and endpoint | Yes | Partly | No |
Frequency in the US mid-market | Uncommon | Common | Common in smaller firms |
Four pillars, four different questions.
Pillar
Shadow IT discovery
- The question it answers
- Which subscription software are our people genuinely using, on the network and off it
Pillar
Risk scoring
- The question it answers
- Which of those applications ought to worry us first
Pillar
SaaS posture management
- The question it answers
- What is misconfigured in the applications we did approve
Pillar
App governance
- The question it answers
- What currently holds standing permission to our data, and does anybody still use it
Pillar
Information protection
- The question it answers
- Where does the sensitive data actually sit, and who can reach it
Pillar
Behavioral analytics
- The question it answers
- Is an account behaving unlike itself inside an application nobody is watching
Pillar
XDR correlation
- The question it answers
- Is this alert one part of a larger attack that began somewhere entirely different
Five steps, and the OAuth review comes early.
- 1
Confirm licensing and agree the decision route
What your existing subscription already entitles you to gets checked rather than assumed, and we establish who has authority to decide whether an application is approved, replaced or blocked. That second point needs an actual conversation, and it determines whether anything at all comes of the deployment.
- 2
Review OAuth applications first
Application governance comes before discovery, because it moves fast and it is where the uncomfortable finding nearly always lives. Applications nobody uses, applications holding extensive permission nobody remembers granting, and credentials in assorted states of expiry. The revocation decisions get taken here rather than deferred to a later phase that never arrives.
- 3
Run discovery and rank what it finds
Network traffic assessed against the application catalog, producing an inventory of what is genuinely in use both on the network and off it, with each entry evaluated against more than ninety risk indicators. We work through the ranked list alongside you rather than handing over a spreadsheet, because the point of the exercise is a short set of decisions rather than a long set of rows.
- 4
Connect key applications and work the posture findings
Connecting an application unlocks posture management and file scanning rather than leaving you with discovery alone. The posture recommendations flow into Secure Score by themselves, and they get worked through deliberately during this phase, because they are concrete, fixable, and require nobody to wait for anything to happen first.
- 5
Set policies and agree the review rhythm
Applying a sensitivity label, blocking a download to an unmanaged device, and removing outside collaborators from confidential files, each applied to the specific cases that warrant it rather than switched on everywhere simultaneously. Then a recurring review, because these estates change constantly and a single snapshot is wrong within months.
What US organizations ask about Defender for Cloud Apps.
Fifteen questions to answer first.
Do you have the problem
- Can you list the SaaS applications in use today?Almost nobody can, and the gap is the point.
- Could anybody list what holds standing permission into your tenant?This is usually the most uncomfortable answer.
- When were your approved apps last configuration reviewed?Most tenants are still on their original settings.
- Do you know where personal data actually sits?Relevant under HIPAA, CCPA/CPRA and state privacy laws.
- Is external sharing reviewed, ever?Project access routinely outlives the project.
Scope
- Which applications would you connect first?A connected application gets posture assessment and file scanning too, not merely discovery.
- Do you have network logs available for discovery?Discovery uses network traffic assessment.
- Do you use non-Microsoft SaaS heavily?That is precisely where the visibility gap lives.
- Are unmanaged devices in scope?Blocking a download to an unmanaged device is one of the controls named explicitly.
- Is Purview classification already in place?The integration is more useful if labels already exist.
Would anybody act
- Who decides whether an application is sanctioned?Discovery without a decision maker produces a list.
- Is there an approval route for new SaaS?Otherwise the same finding recurs every quarter.
- Who would revoke an OAuth consent, and can they?Frequently nobody owns this.
- Would the Secure Score recommendations be worked?They arrive automatically and are often ignored.
- Is anybody reviewing behavioral alerts?Decide before deployment, not after.
The pages around this one.
Microsoft security services
The wider Microsoft security practice this product sits inside.
Microsoft Purview
Classification, labeling and the data governance layer this integrates with for information protection.
DLP solutions
The data loss prevention program this product extends into non-Microsoft SaaS.
Start with the list of things that have permission to read your mail.
It is a short exercise, it does not need a deployment, and in most tenants the result changes the conversation. If shadow IT turns out to be your real problem instead, we will tell you which approach is the better purchase.
Related Services
Explore more solutions that work great with this service
Microsoft Security Services
The Microsoft security stack deployed and managed end to end
Learn moreMicrosoft Defender XDR Services
One incident queue across endpoint, email and identity
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreMicrosoft Purview
Data governance and compliance solutions
Learn moreDLP Solutions
Data Loss Prevention implementation for US businesses via Microsoft
Learn moreMicrosoft Purview Endpoint DLP
Endpoint data loss prevention for US organizations: device onboarding
Learn more