Shadow IT Discovery with CASB
CASB shadow IT discovery reveals every SaaS app your employees use — expect to find 500-1,000+ apps vs the 50-100 IT knows about. Risk-score each app on data handling, compliance certifications, and breach history. Enforce in tiers: block high-risk apps, coach on medium-risk, and monitor everything. Run discovery for 30 days before making enforcement decisions.
Shadow IT is any technology — primarily SaaS applications — used by employees without the knowledge, approval, or governance of the IT and security organization. A Cloud Access Security Broker (CASB) discovers shadow IT by analyzing web traffic logs, DNS queries, and API integrations to identify every SaaS application accessed by employees, classify each application by risk and function, and provide enforcement controls to allow, coach, restrict, or block usage based on organizational policy. The average enterprise discovers 900 to 1,500 distinct SaaS applications in use when they first deploy CASB shadow IT discovery — roughly five to ten times more than the IT department knows about. This guide covers how to set up discovery, how to make sense of what you find, and how to move from awareness to enforcement without disrupting the business.
Why shadow IT matters for security
Shadow IT is not employees being malicious — it is employees being productive. They sign up for a project management tool because the approved one is slow. They use a personal Dropbox account because the corporate file share has a 10MB upload limit. They use a free PDF conversion site because the approved tool requires an IT ticket. The intent is almost always productivity, not data theft. But the security implications are severe: corporate data uploaded to unapproved SaaS applications is outside your DLP controls, your backup policies, your retention policies, and your incident response procedures. When a shadow SaaS vendor is breached, you do not even know your data was exposed because you did not know the application was in use.
The financial risk is equally significant. SaaS sprawl means redundant subscriptions across departments, each negotiated independently without volume leverage. One enterprise I worked with discovered 14 different project management tools in use across 8 departments, each with its own paid subscription. Consolidating to two approved tools saved $180,000 annually in licensing alone — before considering the security and compliance benefits of bringing those tools under governance.
From a compliance perspective, shadow IT is an audit finding waiting to happen. GDPR requires you to know where personal data is processed. HIPAA requires you to inventory all systems handling PHI. SOC 2 requires you to manage access to all systems in scope. If your employees are uploading data to SaaS applications you do not know about, you are not meeting these requirements — and you will not discover the gap until an audit or a breach forces the conversation.
Discovery methods
Method 1: SWG log analysis (inline discovery)
The most comprehensive discovery method uses the web traffic logs from your SASE SWG. Every HTTP/HTTPS request that flows through the SWG is logged with the destination URL, domain, SNI hostname, user identity, device information, bytes transferred, and application category. The CASB engine analyzes these logs against a database of 40,000 to 80,000 known SaaS applications (depending on vendor), matching URL patterns and hostnames to specific applications and calculating usage metrics: number of unique users, total sessions, data uploaded, data downloaded, and usage frequency.
Inline discovery through SWG traffic provides the richest data because you see not just which applications are accessed but what activities are performed: logins, file uploads, file downloads, sharing actions, and administrative operations. This activity-level visibility is essential for risk assessment — an employee who visits a SaaS application's marketing page is different from an employee who uploads 500MB of corporate data to it. The requirement for inline discovery is that all user web traffic flows through your SWG, either via endpoint agent, PAC file, or tunnel onramp. Traffic that bypasses the SWG (users on unmanaged devices without the agent, or traffic going through a split-tunnel VPN that does not route through the proxy) will not be discovered.
Method 2: DNS log analysis
DNS-based discovery analyzes DNS query logs from your recursive DNS resolvers or your SASE platform's DNS-layer security service. Every SaaS application access starts with a DNS query, so DNS logs capture application usage even for traffic that does not flow through the SWG proxy. DNS discovery is broader in coverage (captures all DNS-resolving devices on the network, including IoT and servers) but shallower in detail (you see domain lookups but not application activity, data volumes, or user identity without correlation).
DNS discovery is an excellent complement to SWG-based discovery, particularly for discovering SaaS usage from devices that do not have the SWG agent installed: IoT devices, servers making API calls to cloud services, build systems downloading dependencies, and network devices phoning home to vendor cloud portals. Use DNS discovery for broad coverage and SWG log analysis for deep visibility on managed endpoints.
Method 3: API-based discovery (out-of-band)
API-based CASB connects directly to your sanctioned SaaS platforms (Microsoft 365, Google Workspace, Salesforce, Box, Slack) using OAuth or service account credentials and inspects sharing settings, permission configurations, and third-party application integrations. This method discovers OAuth application grants — when an employee authorizes a third-party application to access their Microsoft 365 or Google Workspace data — which represents a particularly dangerous form of shadow IT because the third-party app maintains persistent API access even after the employee stops using it actively.
API-based discovery is not a replacement for inline discovery; it is a complement. Inline discovery finds all SaaS applications accessed by users. API-based discovery finds all third-party applications that have been granted API access to your sanctioned platforms. Together, they provide a complete picture of your SaaS exposure.
SaaS risk categorization framework
| Risk Category | Criteria | Example Applications | Default Policy |
|---|---|---|---|
| Sanctioned (Low Risk) | IT-approved, vendor-assessed, data handling agreement in place, SSO integrated | Microsoft 365, Salesforce, Workday, ServiceNow, Slack | Allow with full access. Apply DLP and activity monitoring. |
| Tolerated (Medium Risk) | Known to IT, serves a legitimate business purpose, not formally assessed but from reputable vendors | Canva, Notion, Miro, Loom, Calendly | Allow with coaching banner. Monitor data upload volumes. Review quarterly. |
| Under Review (Medium-High Risk) | Recently discovered, business purpose unclear, vendor security posture unknown | New SaaS tools discovered during discovery scans with >10 active users | Allow with coaching banner. Restrict file upload. Flag for security team review within 30 days. |
| Unsanctioned (High Risk) | No business justification, high data leakage risk, or vendor with poor security practices | Personal cloud storage (personal Google Drive, personal Dropbox), file conversion sites, free VPN/proxy services | Block with user notification explaining the policy and directing to the approved alternative. |
| Prohibited (Critical Risk) | Known malicious, phishing infrastructure, data harvesting, or legal/compliance violation | Identified phishing sites, known malware distribution domains, sanctioned country services | Block silently. Alert security team. Investigate user activity. |
From discovery to enforcement
Phase 1: Observe and catalog (Weeks 1-4)
Run CASB discovery in monitor-only mode for a full month before taking any enforcement action. The first month's data establishes your baseline: how many distinct SaaS applications are in use, which departments use the most shadow IT, what categories of applications are most common (file sharing, project management, communication, design, development tools), and which applications have the highest data exposure (most bytes uploaded). Do not block anything during this phase. Discovery that starts with blocking creates organizational resistance — users will find ways around the controls rather than complying, and you will lose the political capital needed for later enforcement.
During this phase, build your SaaS application inventory. Categorize every discovered application using the risk framework above. Identify the top 20 applications by user count and data volume — these are your governance priorities. For each of the top 20, determine: who is using it, what department, what data types are being uploaded, is there an approved alternative, and what would happen if it were blocked. This analysis takes time but is essential for making informed enforcement decisions rather than blanket blocking that frustrates users.
Phase 2: Coach and redirect (Weeks 5-8)
Enable coaching notifications for applications in the Tolerated and Under Review categories. When a user accesses a tolerated application, display a notification banner that says: 'This application has not been formally approved by IT. If you need this tool for your work, please submit a request through the IT portal. The approved alternative for this function is [X].' Coaching does not block access — it educates users about approved alternatives and creates a feedback loop where users request formal approval for tools they need. This feedback is valuable because it tells you which shadow IT applications serve genuine business needs that your approved tools are not meeting.
For unsanctioned high-risk applications (personal cloud storage, file conversion sites), enable upload blocking rather than full application blocking. Users can still access the application (reading files, checking information) but cannot upload corporate data. This is a nuanced control that reduces data exposure without the user backlash of full blocking. Pair upload blocking with a notification directing users to the approved alternative for file storage or conversion.
Phase 3: Enforce and govern (Ongoing)
After the coaching phase establishes user awareness, implement full blocking for prohibited applications and applications that remain unsanctioned after the 30-day review period. Implement tenant restrictions for sanctioned SaaS applications to prevent users from logging into personal instances — block personal Gmail when corporate Google Workspace is approved, block personal OneDrive when corporate SharePoint is available. Tenant restrictions are one of the most powerful CASB controls because they eliminate a major data leakage vector (employees uploading corporate data to personal cloud accounts) without blocking the SaaS platform itself.
Build a continuous governance process: review newly discovered applications monthly, assess top-usage applications quarterly, reassess risk categorizations semi-annually, and report SaaS risk metrics to leadership annually. Shadow IT discovery is not a one-time project — employees adopt new SaaS tools every week. Without continuous discovery and governance, your SaaS inventory becomes stale within 90 days and shadow IT returns to pre-CASB levels within a year.
Measuring success
Track these metrics monthly to measure the effectiveness of your shadow IT governance program. Total discovered SaaS applications (trending down after enforcement begins, but expect it to plateau around 200-400 as new tools constantly emerge). Percentage of traffic to sanctioned vs unsanctioned applications (target: 90%+ sanctioned within 12 months). Data volume uploaded to unsanctioned applications (should decrease 80%+ after upload blocking). Coach notification click-through rate (percentage of users who click through to the approved alternative). IT portal SaaS request volume (should increase during coaching phase, indicating users are engaging with the governance process rather than circumventing it).
Sources & further reading
- Gartner, "Market Guide for Cloud Access Security Brokers" — gartner.com/reviews/market/cloud-access-security-brokers
- Netskope, "Cloud and Threat Report: Shadow IT" — netskope.com/netskope-threat-labs/cloud-threat-report
- Cloudflare, "What is shadow IT?" — cloudflare.com/learning/access-management/what-is-shadow-it
- CSO Online, "Shadow IT: risks, costs, and how to manage it" — csoonline.com/article/shadow-it
- SANS Institute, "Managing Shadow IT in the Cloud" — sans.org/white-papers/shadow-it
Frequently asked questions
Related on sase.cloud
How to build managed SASE services: multi-tenant architecture, vendor MSP readiness, per-tenant isolation, licensing, an...
Phase-by-phase guide to migrating from MPLS to SD-WAN: circuit planning, overlay deployment, application-aware routing, ...
Structured framework for a SASE proof of concept: success criteria, test scenarios, evaluation scorecard, common PoC tra...
One email per publish. Unsubscribe anytime.