Nobody sets out to cause a security incident with a PDF converter. Someone just needs to merge a few files, so they download a free tool. Someone else adds a browser extension to tidy up a spreadsheet, or signs up for an AI assistant with their work email. Each one takes a few minutes and solves a real problem. What nobody sees is what comes with it: code no one has reviewed, no patching, no licence record, and no one in IT who knows it is there.
The cost of that blind spot is climbing. According to IBM's 2026 Cost of a Data Breach Report, shadow AI incidents more than doubled in a single year, from 20% to 43% of breached organisations. Written policies have not slowed that down on their own.
What does work is a sequence: see what is installed, stop what should not run, and offer an approved route that is quicker than the workaround. The seven steps below follow that order.
Seven steps to keep unapproved software off managed endpoints
01. Find out what is already installed
Blocking comes later. The first job is learning what is running across the fleet, including per-user installs, portable executables that never touch an installer, and browser extensions. A one-time scan only gives you a snapshot, and new installs appear daily, so the inventory needs to refresh continuously.
Why the first inventory tends to surprise people
Flexera's 2026 State of ITAM Report found that only 36% of organisations report complete visibility into their IT estate. In most environments we look at, the first full inventory turns up applications nobody in IT can explain, and that moment usually makes the case for enforcement better than any slide deck. We suggest running discovery in audit mode first: log everything, block nothing, and review the results with department heads before any policy goes live.
02. Sort software into tiers before writing a blocklist
A single blocklist ages quickly and only tells employees what they cannot do. Three tiers work better because each one comes with an action.
| Tier | Examples | Action |
|---|---|---|
| Approved | Office suite, collaboration tools, security agents | Allow and auto-deploy |
| Conditional | Design tools, developer utilities, niche SaaS | Allow for named teams, review on a set date |
| Prohibited | Peer-to-peer clients, cracked software, unsanctioned remote access tools | Block and alert |
Where tiering usually goes wrong
The conditional tier is the one most organisations skip, and it matters most. Without it, every request becomes a yes-or-no decision, and employees who hear no often install the tool anyway. Try giving each conditional tool a named owner and a review date so the answer can change.
03. Enforce at the point of execution
A written policy tells employees what is forbidden. Enforcement stops the file from running. MITRE ATT&CK lists limiting software installation as a standing mitigation (M1033), alongside least privilege and allowlisting, because it takes the decision away from the user.
Blocklists are always one rename behind
Named blocklists miss anything renamed or newly released. We suggest an allowlist model for high-risk groups such as finance and administrator machines, with a blocklist and alerting for the wider fleet, rolled out in audit mode first and then enforced group by group. From what we observe, teams that scope enforcement this way tend to keep it switched on, while blanket rules often get switched off the first time a deadline is missed. A capable solution with prohibited software detection, auto-uninstall within a set time frame, and exclusion lists for machines that genuinely need an exception makes that rollout practical.
04. Take away standing admin rights
Most installers need local administrator rights. Remove those rights from standard users and a large share of casual installs stop at the permission prompt.
Admin removal narrows the path, application control closes it
Per-user installers, portable apps, and browser-based tools can run without elevation, so treat admin removal as one layer and pair it with step 03. Organisations should:
Remove standing local admin
Remove standing local admin from everyone outside IT.
Use time-limited elevation
Offer time-limited elevation through an approval request for the occasional legitimate install.
Log every elevation
Log every elevation so repeat requests show up as a signal.
05. Cover the tools that never install
Browser extensions and web-based AI assistants need no installer and no admin rights, so everything above can pass them by. They are also where much of the shadow AI exposure sits, because company data is pasted straight into a browser tab.
What a browser-level policy looks like
We suggest treating extensions the way you treat applications: keep an approved list, block the rest, and review permissions for anything that can read page content. For AI tools, publish a short list of sanctioned assistants with a clear rule on what data may be entered, because a ban without an alternative simply pushes the usage onto personal devices. Try pairing the policy with web filtering for the unsanctioned categories so the guardrail does not rely on memory.
06. Give employees an approved route that is faster than the workaround
People install their own tools when the official route takes longer than a download. Closing that gap does more for compliance than adding another block.
The delay behind most repeat violations
The most common cause of repeat violations we see is a request process that takes days for a tool that takes two minutes to download. Try publishing a catalogue of pre-approved applications that employees can install on demand, with a short request form for anything outside it and a fixed turnaround time. The Forrester Total Economic Impact study commissioned by ManageEngine, Endpoint Central points the same way: customers reported reduced help desk workload through self-service and reclaimed unused software licences through better asset visibility. That is a composite model rather than a guarantee, but it matches what we see when approved software is easy to reach. A self-service portal that lists IT-approved applications for each group is the simplest way to put it into practice.
07. Review blocks and requests as a signal
Enforcement produces data. Every blocked execution and every denied request shows where the approved stack falls short.
Read the pattern, not the incident
We suggest a monthly review of the most blocked applications and the most requested exceptions. An application blocked repeatedly by different teams is usually a missing tool, not a run of separate violations. Add it to the catalogue, or document why it stays prohibited. Pair the review with licence reconciliation so unlicensed installs surface before a vendor audit finds them.
What holds up in practice
Prevention works when three things line up: you can see what is installed, you can stop what should not run, and the approved route is quicker than the workaround. Miss the third and the first two turn into a running argument with your own employees. Get all three right and unauthorised software becomes a short exception list rather than an ongoing clean-up.
One console
to manage it all
