You discover shadow IT by connecting Defender for Cloud Apps to your network and reviewing discovered cloud app traffic and usage patterns. Focus on unsanctioned apps, unusual upload volumes, risky permissions, and services with weak security controls. Then classify, sanction, or block apps, and use policies to monitor recurring use and data movement.
How Defender for Cloud Apps finds shadow IT
Defender for Cloud Apps discovers shadow IT by ingesting network traffic and cloud usage signals, then correlating them into a cloud app inventory. That lets you see which apps employees are actually using, how much data flows to them, and whether the apps look unsanctioned or risky. The key is not just discovery, but deciding what to allow, monitor, or block based on the observed behaviour.
A useful way to read the results is to separate “newly visible” apps from “business-approved” apps. Many discovery findings are not malicious by themselves, but they can still expose data, bypass procurement controls, or create compliance gaps if they are unmanaged. That is why discovery usually leads to classification, sanctioning, or blocking rather than a simple list of unknown domains.
Discovery also depends on coverage quality. If traffic sources, log collection, or user activity feeds are incomplete, the app inventory will understate the true shadow IT footprint. In practice, the value comes from comparing app popularity, data upload volume, permissions requested, and the security posture of the service itself, then using those indicators to prioritise review.
What you should look for in the discovered app list
The highest-value findings are usually the apps that combine high usage with weak governance. A service may be popular across the business yet still be unsanctioned, use weak controls, or move sensitive data outside approved boundaries. That is the point where discovery becomes a governance and exposure problem, not just an inventory task.
Pay close attention to apps that show unusually large upload activity, repeated access from the same user groups, or a pattern of data movement that does not fit the normal workflow. Those signals can point to file-sharing, collaboration, or workflow tools that users adopted because they were convenient, even if they were never reviewed for security or compliance.
It also helps to distinguish low-risk experimentation from persistent dependency. A one-off app trial is different from a service that has become part of a team’s daily process, especially if the app is handling customer data, internal documents, or regulated content. At that point, the discovery output should feed a real approval decision, not just awareness.
For a broader view of the problem space, NHIMG’s Attack Surface Management Guide is useful because shadow IT is part of unknown-asset discovery, not just SaaS hygiene.
When the discovered app is clearly SaaS, NHIMG’s SaaS Security Guide helps frame the follow-up questions around shared responsibility, auditability, and app governance.
How to turn discovery into action
Discovery only becomes useful when it feeds a repeatable review process. The practical workflow is to identify the app, assign an owner, decide whether it should be sanctioned, and then apply monitoring or blocking rules where needed. If the app is business-critical but risky, the right answer is often conditional approval with tighter policy controls rather than immediate removal.
You should also use policy to watch for recurrence. Shadow IT often returns after a one-time cleanup because users keep choosing the easiest tool available, especially for file transfer, collaboration, and external sharing. A recurring-alert policy gives you evidence of whether the organisation is actually changing behaviour or simply rediscovering the same apps every month.
For Microsoft-centric environments, NHIMG’s Microsoft 365 Security Guide is a strong companion because many shadow IT decisions are really about app consent, sharing, and audit visibility inside the Microsoft estate.
Where app approval depends on identity and consent posture, NHIMG’s Entra ID Applications and Consent Guide is useful for judging whether the app is merely discovered or actually able to obtain persistent access.
Risk and Threat Considerations
Shadow IT becomes risky when unsanctioned apps receive sensitive data, broad permissions, or repeated use without review. The main exposure is not the app label itself, but the fact that the organisation may have no assurance over where data goes, who can access it, or whether the service has adequate security controls.
Failure mechanism: Users adopt an external cloud app outside approved channels, then upload or share business data through it before security or governance teams can assess the service, its permissions, or its retention model.
Impact: Data can leave approved control boundaries, audit evidence becomes fragmented, and an unsafe app can become a durable business dependency before anyone has a chance to sanction or block it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-15 — Service Provider Management | Shadow IT apps are third-party services that need security review and ongoing oversight. |
| Recommendation — Review and approve external apps before business data is sent to them. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Shadow IT discovery depends on knowing what cloud services and data paths are actually in use. |
| PR.AA-03 — Identities are proofed and bound to credentials and asserted attributes | App discovery often leads to governance over who can use external services and what access they can obtain. | |
| Recommendation — Inventory discovered cloud apps and keep the list current. Bind app access to approved identities and review those permissions regularly. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Shadow IT is often a hidden or unmanaged external service that escapes inventory and review. |
| Recommendation — Track all approved and discovered apps in a single authoritative inventory. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Discovery requires maintaining an inventory of external services and connected components. |
| Recommendation — Maintain a current inventory of discovered cloud services and owners. | ||
Practitioner Guidance
What to verify: Confirm that discovery coverage is coming from more than one signal source where possible, and that the app list is being reviewed against business ownership, data sensitivity, and security posture rather than popularity alone.
Decision rule: If an app is both actively used and handling sensitive data, treat it as a governance decision immediately, even if no incident has occurred. If the app is low use and low sensitivity, monitor first and avoid noisy overblocking.
What good looks like: The organisation has a short, repeatable path from discovery to disposition, with clear criteria for sanction, monitor, or block, plus a way to detect when the same shadow app reappears.
Practitioner takeaway: Shadow IT discovery is most valuable when it changes decisions, not when it just creates a larger inventory. The real goal is to identify unmanaged app use early enough to contain data exposure and convert informal tool adoption into governed use.
Related resources from NHI Mgmt Group
- How do you discover shadow AI usage with Microsoft Entra Global Secure Access?
- How do you use Just-in-Time VM access in Microsoft Defender for Cloud?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?