Shadow IT is any hardware, software or IT resource running inside your organization that the IT department never approved, never configured and, in most cases, does not know exists. It covers the file sharing account someone opened with a departmental card, the personal laptop plugged into the office network, and the AI assistant installed on a work machine last Tuesday. None of it is necessarily malicious, and all of it sits outside every control you have.
If you cannot name what is running, you cannot patch it, license it, budget for it or answer for it in an audit. This guide covers how to manage shadow IT in practice: detecting it from the IT Asset Management (ITAM) inventory you already run, writing a policy people follow, and deciding what to do with each unapproved tool once it surfaces.
Why shadow IT is a risk even when nothing breaks
Gartner reported in 2023 that 41% of employees had acquired, modified or created technology outside IT’s visibility during 2022, and predicted that share would reach 75% by 2027. With 2027 close, that prediction is about to be tested. The two sections below cover what shadow IT looks like in practice and why the unknown itself is the problem.
Common examples of shadow IT
Shadow IT rarely arrives as a deliberate breach of policy. It usually starts with someone solving a real problem faster than the official route would allow. The categories that recur across most organizations are:
- Unsanctioned Software as a Service (SaaS) accounts. A team signs up for a project tracker, a file sharing service or a design tool on a personal or departmental card.
- Personal devices on the corporate network. Laptops, phones and tablets that were never enrolled, never patched by IT and never recorded anywhere.
- Unapproved software on managed machines. Utilities, remote access tools and browser extensions installed locally by whoever holds administrator rights.
- AI assistants and chatbots. Generative AI tools adopted individually, often connected to corporate documents and mailboxes.
Each of these leaves a different trace, which is why no single detection method finds all of them. Installed software shows up on the endpoint, while a browser-only service may never appear anywhere except an expense report.
The benefits and risks of shadow IT
The UK National Cyber Security Centre frames the risk more precisely than most definitions do: "There might not be a risk, there might be a critical risk. The organisation simply doesn’t know. Shadow IT is therefore an unmanaged risk." A sanctioned tool with a known flaw can be sized and scheduled, while an unsanctioned one is a blank space on the map. The practical consequences are data leaving through services with no contract, licenses paid for twice, endpoints missing from patch cycles, and audit questions nobody can answer.
There is an argument on the other side, and the same guidance makes it: employees resorting to insecure workarounds to get the job done suggests existing policies need refining. Read that way, each unapproved tool is also feedback about a gap in what IT offers. It is worth separating this from Bring Your Own Device (BYOD) programs, which involve the same devices under a very different regime of enrollment, acceptable use agreements and some control over corporate data, none of which exists when nobody knows the asset is there.
How to detect shadow IT in your environment
Shadow IT detection works best as a set of overlapping passes rather than one scan. Each pass covers a different class of asset, and the value of running them together is that anything appearing in one source and missing from another becomes a candidate for review. The passes below move from the network outward to the accounts and the spending.
Scan the network for devices nobody registered
The first pass answers a narrow question: what is connected that the inventory does not hold? A network scan walks the address ranges you define and reports everything that answers. Because it works over protocols such as DNS, ICMP, SNMP, TCP and UPnP, it also reaches hardware that cannot run software of its own.
This is how unregistered laptops, consumer routers, printers and IP phones surface. Anything the scan finds and the inventory does not list goes into a review queue, which is the same workflow that rogue device detection follows more broadly.
Let the endpoint agent report what is actually installed
A network scan tells you a machine exists. An agent installed on that machine tells you what is running on it, reporting every installed application rather than only the ones IT provisioned.
This is the pass that finds unapproved software on managed hardware, and it usually produces the longest list. Running it on a schedule turns automated software discovery into a standing control instead of an annual exercise.
Contrast what is installed against what is authorized
A list of installed software is raw data until it is measured against something. It becomes a finding when you compare it to a classification of what is allowed, what is under review and what is prohibited.
Two comparisons matter. Installed against authorized surfaces policy violations, and installed against licensed surfaces compliance exposure along with software nobody paid for. That overlap is why a software audit and a shadow IT sweep usually turn up the same names.
Follow the spending and the user accounts
Software that never touches an endpoint leaves its trace somewhere else. Subscription records, expense claims and identity provider logs reveal tools a device scan will never see, which is where most unsanctioned SaaS lives.
Three sources are worth pulling on a schedule:
- Cloud tenant records. Subscription plans and assigned users pulled from the provider, which expose seats IT never requested.
- Usage measurement. Seats that are paid for and barely touched, which is duplicate spending rather than a security finding.
- Expense claims. Anything charged to a personal or departmental card, still the fastest route to shadow SaaS nobody has mentioned.
Read together, these answer who is using what and whether the organization is paying twice for the same capability. That is the ground SaaS governance covers once the discovery work is done.
What your inventory will not catch
Being clear about the limits keeps the exercise honest. An asset inventory sees installed software and connected devices, and it does not see a browser tab.
Three blind spots are worth tracking separately:
- Single sign-on grants and OAuth authorizations. These show which third-party services corporate identities have been connected to, whether or not anything was installed.
- Browser-only services used with a personal account. No install, no artifact on a managed device, no inventory record.
- Hardware that never touches the corporate network. A home machine syncing company files stays invisible to every scan you run.
Identity provider logs and outbound traffic monitoring cover most of that ground, and both sit outside the asset inventory. Naming the boundary up front is what keeps the inventory-based passes credible for everything they do cover.
Shadow AI is the fastest growing form of shadow IT
Unsanctioned AI tools are shadow IT with a shorter adoption cycle and a larger data surface. Gartner reported in November 2025 that 69% of organizations suspect or have evidence that employees are using prohibited public generative AI. The National Cyber Security Centre now names it directly in its shadow IT guidance, describing unmanaged AI services such as chatbots being used with corporate data.
For detection purposes the distinction that matters is where the tool runs. An AI application installed on a managed machine reports like any other executable and appears in the same pass that finds unapproved software, while an assistant used in a browser tab under a personal account produces no inventory record at all. The second case belongs to the identity and traffic signals above, which is why an explicit AI clause in the policy does more work here than any scan.
Building a shadow IT policy that people follow
There is no standard to copy for this. The National Cyber Security Centre is the only government body publishing dedicated shadow IT guidance, while the National Institute of Standards and Technology has no glossary entry for the term, ISO has no dedicated standard and ITIL does not cover it. What follows is drawn from that guidance and from the parts of a shadow IT policy that survive contact with users.
The clauses a shadow IT policy needs
A policy that only prohibits things gets ignored, because the behavior it targets comes from an unmet need. The useful version defines the approved route as clearly as it defines the boundary, which is the same principle that governs a broader IT Asset Management policy.
A workable shadow IT policy covers these clauses:
- Scope. Which devices, services, networks and data the policy governs, including personal hardware used for work.
- Approved catalog. Where the current list of sanctioned tools lives, and who maintains it.
- Request route and turnaround. How to ask for something new, who decides, and the maximum time a decision will take.
- Classification tiers. What counts as approved, under review and prohibited, and what each status means in practice.
- Data handling limits. Which categories of data may never leave sanctioned systems, stated in terms people recognize.
- Enforcement. What happens when prohibited software is found, from notification through to removal.
- No-blame disclosure. A stated route for declaring a tool already in use, and the assurance that comes with it.
Two of those carry most of the weight. The turnaround commitment is what makes the official route competitive with the unofficial one, and the no-blame clause is what gets existing shadow IT declared instead of hidden. A policy that gets neither right will be accurate and unused.
What makes people actually follow it
Compliance here is a design problem more than an enforcement one. The National Cyber Security Centre’s own recommendations are mostly organizational: avoid unnecessary lockdowns, put a simple request process in place as quickly as possible, provide controlled access to outside services, and take a no-blame approach to people who were pushed into workarounds.
The practical test is speed. If a sanctioned tool takes three weeks to approve and a corporate card takes ninety seconds, the policy is competing on the one dimension it cannot win, and building a culture of cybersecurity around it will not change that arithmetic. Publishing the turnaround alongside the prohibition is what changes it.
Bringing shadow IT under management
Discovery produces a list, and the list is not the outcome. Every item on it needs one of four decisions, and which one depends on what the tool does, what data it touches and how many people already rely on it. Working through them item by item is what converts a detection exercise into managed inventory.
Each finding resolves into one of these outcomes:
- Sanction it. The tool does something useful at acceptable risk, so it gets an owner, a contract, an inventory record and a review date.
- Consolidate it. The capability already exists under a license you hold, so users move onto the existing agreement and the duplicate subscription is canceled.
- Migrate it. The need is legitimate and the tool is not acceptable, so IT provides a sanctioned equivalent and sets a date for the switch.
- Block and remove it. The risk cannot be mitigated, so the software is uninstalled and the service blocked, with the reason communicated to the people who were using it.
The criteria that decide between them stay consistent: sensitivity of the data involved, whether an existing contract already covers the capability, the compliance exposure it creates, the number of active users, and whether a sanctioned alternative exists at all. Anything sanctioned has to land in the IT asset inventory with a named owner, or it becomes shadow IT again as soon as the person who introduced it changes role. Setting a review date on the record is what prevents that.
Managing shadow IT with InvGate Asset Management
InvGate Asset Management discovers and manages hardware, software and cloud assets in one interface, with no-code automation and lifecycle tracking from acquisition through to disposal. It runs in the cloud or on your own infrastructure, including air-gapped environments, with the same functionality either way.
For shadow IT specifically, every pass described above lands in the same inventory. Network scans and endpoint reporting populate it, software classification turns it into a queue of findings, and automations act on that queue without anyone having to watch it.
Five capabilities do most of the work, and the shadow IT detection tour shows how each one is configured:
- One inventory for every asset type. Hardware, software, cloud and SaaS assets in a single place, populated by the Agent, network discovery, integrations with Intune, Jamf, AWS, Azure, Google Workspace and Microsoft 365, and manual or spreadsheet import when you are starting from a CSV file.
- Smart Tags. Dynamic tags that group assets by condition, so unclaimed machines on the network or devices carrying a specific title stay grouped as the inventory changes underneath them.
- Authorization policies and Software Deployment. Classify any software title as allowed, under review or prohibited, by name or by name and version, then use software deployment packages and plans to install or remove titles across the fleet.
- Automations and alerts. Event-driven or scheduled rules that watch for the conditions you define and email the right team the moment something crosses the line.
- Smart Recommendations. The Intelligence Center surfaces around 20 recommendations across hardware, health and licensing, including assets with no owner or location assigned, each with a one-click path to set up the matching automation.
InvGate's Integrations database
Connect our solutions with the apps you use every day.
Explore InvGate's integrations
How to detect shadow IT hardware, step by step
The hardware side starts with a network scan and ends with a decision about each device that answers. The whole sequence takes five steps:
- Install a proxy on the network you want to scan. Go to Settings > Discovery > Proxies, click Add, save the details in the modal, then download and run the installer for the operating system (OS) of the host machine. One proxy per network segment is enough, ideally on an always-on server with full visibility of the local network.
- Configure the proxy and start scanning. Enter the platform URL, the proxy security token and a proxy name, then click Configure proxy followed by Start scanning. Each proxy covers one address range, so add more proxies for other subnets or office locations.
- Check the Discovery source. Creating a proxy usually generates an InvGate Discovery source on its own. If it did not, go to Settings > Discovery > Discovery sources, click Add, choose InvGate Discovery and set the name, the proxy from the previous step, the protocols to scan and the frequency.
- Review and convert what the scan found. Open Assets > Discovery for the list of detected devices, select anything that belongs in the inventory, click Convert to asset, complete the required fields and click Apply changes.
- Keep the unclaimed ones grouped. In the Assets module, filter on Assets > Owner Name > is > None and Assets > Location > is > None, then save that filter with Quick Smart Tag. Any device discovered later that arrives without an owner joins the tag by itself.
What is left in Assets > Discovery after step 4 is the hardware side of your shadow IT list. Each entry goes to one of the four decisions in the previous section, and the Smart Tag from step 5 is what stops the list rebuilding quietly.
How to detect and control shadow IT software, step by step
This side runs on the Agent, so deploy it first from Settings > Discovery > Agent Deployment, choosing the OS of the target assets and either manual or remote installation through a Group Policy Object. Once endpoints are reporting every installed title, four steps take you from a written policy to a clean fleet:
- Write a policy instead of keeping a watchlist. Go to Software > Authorization policies and create one. The Software tab matches on title and version, title contains or title starts with, and it also takes whole software categories, so a single rule can cover every gaming or remote access title the platform has normalized. The Categorization tab assigns allowed, banned or under review, either across all devices or scoped by tag, and the Exclusion tab keeps chosen tags out of scope, which is how a BYOD fleet stays exempt.
- Let it run, and get told what it finds. Policies execute in automatic cycles or immediately through the Run Policies button, and a new one sits at Not applied until one of those happens. To be pushed rather than having to look, go to Settings > CIs > Automations, add an automation with the Event set to Asset Software updated and a Software installations condition, then click Add action, choose Send email and include the CI_LINK variable in the body so the message links straight to the affected asset.
- Resolve the under review queue. Under review is a transitional status by design, so it needs a person. In the Software Explorer, filter on that status, select the installations and click Set authorization status, then choose Approve or Ban. This is where the four decisions from the previous section get made.
- Remove what stays prohibited. A policy classifies and flags, and removal is a separate action. For a one-off, run the Uninstall software action from the Asset Explorer against a group of assets, or schedule a plan under Software > Deployment > Plans. To make it standing, build an automation with the Scheduler event, a condition on Computer > Software Installations > Software Name, and Uninstall software as the action, scoped to the title and the versions you want gone.
Two mechanics matter once you run more than one policy: they are evaluated in list order, so an exception has to sit above the general rule it modifies, and an automated uninstall is configured one title at a time, which suits the applications that genuinely cannot stay rather than a whole prohibited category.
How to bring cloud and SaaS assets into the same inventory
Neither of the passes above sees a subscription that was bought with a card and never installed anything. Three steps close that side:
- Connect the cloud platforms. Go to Settings > Discovery > Discovery sources, open the catalog and add the source you need. Intune, AWS and Google Cloud Platform each take their own credentials and a synchronization schedule, and what they return appears under Assets > Cloud Assets.
- Connect Microsoft 365 as cloud software. Go to Software > Create CI, select Microsoft 365 as the software type, enter the Tenant ID, Client ID and Client Secret, then click Create. The subscription then carries Plans, Users and Activity tabs, which is where assigned seats and last activity live.
- Read the seats against the spend. The Users with Activity section filters by last activity at 7, 30, 90 or 180 days, which separates accounts nobody has touched from accounts in real use. Contracts > Software Compliance shows out of compliance installations and true-up cost, and Software metering, enabled at Settings > CIs > Software metering, reports last use for each installation.
This is the pass that turns duplicate spending into something you can cancel rather than something you suspect. It is also the one that most often produces the argument for sanctioning a tool instead of blocking it, because the user count is right there.
Setting this up takes less time than the first sweep usually does. You can start a free trial for 30 days, or talk to Sales about how the detection and policy workflow would fit your environment.
Conclusion
Shadow IT will keep appearing for as long as people have work to do and the official route is slower than a corporate card. The workable objective is a known list, where everything running is identified, owned, and either sanctioned or scheduled for removal.
Detection from the asset inventory produces that list, a policy with a published turnaround keeps it from growing back, and a per-item decision framework converts it into managed inventory. That sequence is how to manage shadow IT without slowing down the teams who created it in the first place.
Frequently Asked Questions
Shadow IT raises the same handful of questions in most organizations. The answers below follow the definitions and sources used throughout this article.
Is shadow IT bad?
Shadow IT is not bad by definition. The risk comes from the asset being unknown rather than from the tool itself, which is why the National Cyber Security Centre describes shadow IT as an unmanaged risk. The same application becomes acceptable as soon as it has an owner, a contract and an inventory record.
What are the most common shadow IT apps?
The recurring categories are file sharing and storage services, messaging and collaboration tools, project trackers, design tools and, increasingly, generative AI assistants. What they share is that one person can adopt any of them in a browser with no help from IT. Categories that need installation or procurement appear far less often.
What are the statistics for shadow IT?
Gartner reported in 2023 that 41% of employees had acquired, modified or created technology outside IT’s visibility during 2022, and predicted that share would reach 75% by 2027. On unsanctioned AI specifically, Gartner reported in November 2025 that 69% of organizations suspect or have evidence that employees are using prohibited public generative AI, from a survey of 302 cybersecurity leaders. Figures on this topic vary widely between publishers, so it is worth checking the sample behind any number before repeating it.
How does shadow IT relate to cloud computing?
Cloud services are what made shadow IT trivial to create. A subscription can be started with an email address and a card, with no installation, no procurement and no network artifact for a scan to find. That is why shadow IT detection has to cover subscription records and identity logs alongside device scans.
