Shadow IT and the SaaS you cannot see

You do not need to buy a discovery platform to build the first inventory. Three data sources most organisations already hold will surface most of it, and each catches what the others miss.

Identity logs come first. If you run Microsoft 365, Entra ID has been recording the story all along. The enterprise applications list shows every application that has been consented into the tenant, including ones no administrator ever added, because a user clicked Sign in with Microsoft and accepted the prompt. Sort by date added and look at what arrived in the last year, then use the sign-in logs to see which of those applications are actually in use and by whom. Google Workspace keeps equivalent records for connected apps.

DNS is the second ledger. If you log resolver queries at the office network or on managed endpoints, a few weeks of logs grouped by domain give a crude but honest census of the SaaS your devices actually talk to. It catches tools that never touch your identity provider because staff signed up with an email address and a password, the population the identity logs cannot see.

Expenses are the third. Finance sees what technical telemetry misses: recurring card charges with per-seat pricing, annual renewals for tools nobody remembers buying, and reimbursed personal card spend, which is where the most invisible subscriptions live. Ask for twelve months of software-shaped line items and reconcile them against what IT believes exists. Tools paid for personally and never reimbursed will not appear anywhere, which is one reason the sanctioning process below matters more than any single discovery pass.

The sharpest version of the problem is the standing grant. When a user signs into a third-party tool with their work account and accepts the consent screen, the tool can receive tokens that let it act against your tenant without the user present. A grant of Mail.Read or Files.Read.All on Microsoft Graph means the vendor's servers can read that user's mail or files continuously until someone revokes the grant, and all the user saw was a brief consent prompt.

These grants accumulate quietly, and reviewing them is work you can do today. In Entra ID, walk the enterprise applications list and examine the permissions each application holds and whether an administrator or an individual user consented to them. An application with broad Graph permissions, no verified publisher and a single user's consent deserves immediate attention, and anything nobody recognises should be revoked. A compromised vendor holding a standing grant is functionally a compromise of your tenant, and attackers exploit the pattern directly through consent phishing: a convincing mail walks the victim into authorising a malicious application, and MFA never fires because every sign-in involved was legitimate.

Then close the door for the future. Entra ID lets you restrict user consent to low-impact permissions from verified publishers and route everything else through an admin consent workflow, so requests reach a human with context instead of being silently granted. That one change turns grant sprawl into a queue you can see.

The instinctive response to all this is a policy that bans unapproved software. Bans mostly relocate the problem. Sign-ups move from work email to personal email and spend moves to personal cards, so the discovery sources described above stop seeing any of it. The number of tools barely changes, but your visibility over them disappears.

What works better is a sanctioning path that is faster than the shadow path. Keep the intake small: what data will go into the tool, who hosts it and in which country, whether it supports single sign-on, and whether you can export and delete your data on exit. Tier the response. A low-risk utility holding no client or personal information gets a yes within days, with conditions such as SSO enrolment and a named owner. Anything that would hold client, financial or personal information gets an actual review. Publish the sanctioned list where staff can find it, because a lot of shadow IT starts with someone who could not tell whether a tool was allowed.

A one-off amnesty accelerates this. Invite every team to declare what they already use, with no consequences attached, and fold the declarations into the intake queue. You will learn more about your organisation's unmet software needs in a week than a year of network monitoring would tell you.

An offboarding checklist can only cover systems it knows about. Every shadow tool is an account that survives the leaver: a login that still works, sometimes holding client data, sometimes with the ex-employee as the only administrator. The worst version is common in small firms: a tool the business depends on was registered under a departed employee's personal email, so the company cannot reset the password, reach the billing settings, or prove to the vendor that it owns the account.

Single sign-on is the structural fix. Any tool enrolled behind your identity provider is cut off in the same motion that disables the mailbox. That is the strongest practical argument for making SSO support a default condition of sanctioning. For tools that cannot do SSO, the fallback is a register entry: a named owner, credentials held in the company password manager instead of one person's browser, and billing on a company instrument. When someone leaves, the register tells you which accounts to close and who takes over ownership.

Cloud access security brokers and their descendants automate what this note describes by hand. They build the application inventory from network and endpoint telemetry, score each application's risk, and can block uploads to unsanctioned destinations or apply policies inside sanctioned sessions. If your Microsoft 365 licensing already includes Defender for Cloud Apps, its discovery mode can build the inventory from Defender for Endpoint telemetry on managed devices, and turning it on is a configuration change rather than a procurement cycle.

Knowing where they are overkill matters just as much. A fifty-person organisation gets most of the available risk reduction from the cheap layer: a consent policy, a quarterly pass over the three ledgers, an intake path, and the SSO condition. An inline broker inspecting every session earns its keep when there are hundreds of staff, regulated data moving through many sanctioned applications, and someone whose job includes tuning the policies. An unmaintained CASB generates alerts nobody reads and blocks nobody expected, and the shadow response to a clumsy block is a personal hotspot. Sequence the cheap controls first and let the discovery findings make the case for further tooling.

None of this needs new software, and a partial inventory built this week is more useful than a complete one that never gets started. This discovery pass is also where Black Shard begins most security reviews, because controls scoped to the asset register only protect what the register lists. The depth beyond this note, scoring what discovery turns up, deciding which grants and tools carry real risk, and remediating without breaking the teams that depend on them, is engagement work.