in one lineShadow cloud is infrastructure spun up outside the company tenant: dev accounts, trial projects, and databases nobody registered.
the numbers
- 35%of breaches involved shadow data, hidden ~26% longerIBM Cost of a Data Breach, 2024
- 82:1machine identities per human one, nearly half privilegedCyberArk Identity Security Landscape, 2025
- 241 daysdays to identify and contain the average breachIBM Cost of a Data Breach, 2025
1what it is
Shadow cloud is the infrastructure flavor of shadow IT: AWS, Azure, or GCP accounts created outside the company organization, the proof-of-concept project on trial credits, the database a contractor stood up to deliver faster, the staging environment that became production without ever becoming official.
It differs from shadow SaaS in what it holds. A shadow app holds a slice of data through a vendor's controls; a shadow cloud account holds raw infrastructure: storage buckets, databases, machine credentials, and API keys, configured by whoever created it, to whatever standard they had time for.
2why it accumulates
Engineers create environments because creating environments is the job. The company org has guardrails and a request path; the personal account has none, and the demo is due Thursday. Trial credits, hackathons, agency deliveries, and acquisitions each leave accounts behind, and the billing often hides on a personal card expensed monthly, where no inventory ever looks.
The end state is documented in breach data: IBM's 2024 Cost of a Data Breach report found 35% of breaches involved shadow data, data in unmanaged stores, and those breaches took about 26% longer to identify and 20% longer to contain. Unmanaged infrastructure is precisely where data sits unencrypted, unpatched, and unlogged.
3what it costs you
The classic incident is the open bucket: customer data in a store nobody hardened, found by a scanner before any audit found the account. Shadow cloud also mints credentials at machine speed, keys and service identities that never enter any rotation or review, and it hosts the workloads that keep running after their creator leaves, billed to a card nobody reconciles.
The compliance angle is inventory-shaped: NIS2 asset-management duties and GDPR processing records both assume you can list where company data lives. An account outside the org is outside the list by definition, and its existence usually surfaces at the worst moment, during an incident, an audit, or due diligence.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedMicrosoft AI data exposure, 2023howA share link meant for one folder opens the whole storage account.what leavesbackups, passwords and private messageswho ends up with itanyone who finds the link
- it happenedPower Apps misconfiguration, 2021howA default on a no-code app leaves its data readable without logging in.what leavespersonal records you collectedwho ends up with itanyone who looks
- it happenedToyota cloud exposure, 2023howA wrong setting is never rechecked and stays open for years.what leavescustomer data, over a long stretch nobody can account forwho ends up with itnobody knows, which is the problem
4what works
The money is the most reliable detector. Shadow cloud bills somewhere, and a personal-card AWS charge expensed monthly is its signature; expense reports and card statements surface accounts no directory-based tool can see. The second-best source is the people who created them. A short amnesty survey of engineering and data teams, framed as inventory rather than enforcement, turns up most accounts within a week, because a stated goal of migration rather than blame is the goal that gets answered honestly.
The technical seams add the rest. Company-domain signups appear in mail logs, and shadow accounts often touch the identity layer somewhere: a console federated to the IdP for convenience, an OAuth grant from a cloud platform, a service account or key bridging the sanctioned and unsanctioned environments. Accounts with no link to the directory stay invisible to identity-based discovery, which is why the expense trail and the survey bound the search rather than any single technical pass.
What follows discovery is account-by-account triage. Real workloads migrate into the organization, behind SSO and central billing, with keys rotated on the way in; experiments get exported and closed. The structural fix is speed, because guardrails slower than a credit card always lose. A sandbox account engineers can self-provision inside the org, in minutes, removes the reason the shadow account existed in the first place.
on the record
your turn
what you can do about it
this week
Ask engineering and data teams which cloud accounts exist outside the main one.
Check each for public storage and active keys.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →