In September 2023, researchers at Wiz disclosed that a Microsoft AI research team had exposed 38TB of internal data — training data, secrets, and employee backups — through a single overly permissive SAS token attached to an Azure Storage account nobody was actively tracking. Nine months earlier, Toyota admitted that a misconfigured cloud storage bucket had leaked data on 2.15 million customers, quietly, for nearly a decade since 2013. Neither company lacked a security team. Neither lacked a CSPM tool. What they lacked was visibility into cloud infrastructure that existed outside the accounts their tools were told to watch. That's the shadow-cloud problem, and it's the reason a new category — Cloud Discovery and Exposure Management (CDEM) — is emerging alongside, and in some ways ahead of, CNAPP platforms like Prisma Cloud. This post breaks down what shadow cloud actually is, why existing tooling misses it, and what closing the gap requires.
What is shadow cloud, and how does it form inside a well-governed org?
Shadow cloud is any cloud account, subscription, resource, or service that exists and is reachable from the internet but isn't enrolled in your security tooling — and it forms through completely ordinary behavior, not negligence. A developer spins up a personal AWS account with a corporate email to prototype something over a weekend. A marketing team signs up for a SaaS tool that provisions its own S3 bucket. A company acquires a startup in 2022 and inherits 40 AWS accounts, half of which nobody can name an owner for by 2024. An engineer leaves in 2021 and the GCP project they created never gets transferred into the central billing org. Each event is small and explainable. The aggregate, across a company with dozens of business units and thousands of engineers, is an inventory of infrastructure that grows faster than anyone's ability to track it — and that inventory grows in the one place attackers look first: outside the perimeter anyone is actually watching.
How much of an enterprise's cloud footprint actually goes undiscovered?
More than a third, based on what shows up whenever a company runs its first true external discovery pass. Organizations that adopt CDEM tooling for the first time routinely find 20-40% more internet-facing cloud assets than existed in their CMDB or CSPM inventory — accounts opened outside procurement, forgotten proof-of-concept environments, and infrastructure left behind by mergers and acquisitions. In our own engagements, the most common single source of shadow cloud is M&A: a company acquired 18-24 months ago whose cloud accounts were never fully consolidated into the parent org's identity and billing structure. The second most common source is regional or business-unit autonomy — teams in a satellite office or a recently acquired product line standing up cloud resources under a different vendor relationship than the one security governs. None of this shows up in an asset inventory that only knows about accounts someone remembered to register.
Why doesn't a CSPM like Prisma Cloud already solve this?
Because CSPM and CNAPP platforms, Prisma Cloud included, are built to secure accounts you've already told them about, not to find the ones you haven't. Onboarding Prisma Cloud into an AWS organization, an Azure tenant, or a GCP project requires a connector: a role, an API credential, an integration that someone has to configure. That's the right design for policy enforcement and workload protection — it's how you get deep configuration checks, IAM analysis, and runtime protection across an account. But it means the tool's coverage is exactly as complete as your list of known accounts, and no more. A shadow AWS account opened with a personal card and a corporate email is invisible to Prisma Cloud on day one, day 100, and day 1,000 — not because the product is deficient at its job, but because discovery of the unknown was never the job. This is precisely the gap CDEM is built to close: it approaches cloud the way an external attacker does, from the outside in, discovering what's actually internet-reachable before asking whether it's configured correctly.
What does a shadow-cloud exposure actually look like in production?
It looks like an exposed asset sitting untouched for months because no monitoring tool has a reason to look at it. The Microsoft case in September 2023 is the clean example: the SAS token in question had been generated years earlier for internal sharing, was set to expire in October 2051, and granted full control over the storage account rather than read-only access to the specific files it was meant to share — a misconfiguration that Prisma-Cloud-style CSPM checks are excellent at catching, but only inside accounts already under management. Wiz found it by scanning GitHub for exposed credentials, not by auditing a known cloud estate. The Toyota case is the slower-burn version: a cloud environment misconfigured to allow public access sat that way from 2013 to 2023, exposing vehicle location data and customer information for a decade, discovered only when Toyota went looking after unrelated incidents earlier that year. In both cases, the exposure wasn't a novel vulnerability — it was a known class of misconfiguration sitting on infrastructure that fell outside the boundary of what was being actively assessed.
What does actually closing the shadow-cloud gap require?
It requires treating discovery as a continuous, outside-in process rather than a one-time onboarding step. Concretely, that means four capabilities working together: first, attack-surface-style discovery that enumerates cloud assets by DNS, IP ranges, certificate transparency logs, and cloud provider metadata rather than relying on a static list of connected accounts; second, ownership attribution that maps a discovered asset back to a business unit, team, or individual within hours rather than leaving it in a queue; third, continuous re-scanning, because a clean sweep run once a quarter misses the AWS account a contractor spins up in week two; and fourth, a direct handoff into exposure and vulnerability management workflows so a newly discovered asset doesn't just get logged — it gets triaged, prioritized against its actual internet exposure, and routed for remediation on the same timeline as anything already in inventory. Discovery without that last step just produces a longer spreadsheet. The goal of CDEM isn't a bigger inventory; it's fewer assets that exist for months without anyone deciding whether they're safe.
How Safeguard Helps
Safeguard's approach to CDEM starts from the assumption that your known cloud inventory is incomplete, and builds discovery as a continuous outside-in process rather than a connector you configure once and trust. We enumerate your organization's real internet-facing footprint — domains, subdomains, IP space, certificates, and cloud-provider signatures — on a recurring basis, and diff each run against the last so that a new AWS account or an unmanaged storage bucket surfaces within a single scan cycle, not at the next scheduled audit. Every asset we discover gets automatic ownership attribution based on registration data, DNS patterns, and organizational context, so security teams aren't left chasing down who owns a mystery subdomain for three weeks before they can even start remediation.
Where Safeguard differs from a traditional CNAPP is what happens after discovery: newly found assets flow directly into the same exposure and vulnerability management pipeline that governs your known infrastructure, ranked by actual internet reachability and exploitability rather than sitting in a separate "shadow IT" backlog that never gets prioritized. That means a forgotten cloud storage bucket with public read access gets flagged and routed with the same urgency as a critical CVE on a production server — because from an attacker's perspective, it often represents the same level of risk. For organizations already running Prisma Cloud or another CNAPP for policy enforcement on known accounts, Safeguard is designed to sit upstream of that investment: closing the discovery gap so the accounts your CSPM is protecting are actually the complete set of accounts that exist, not just the ones someone remembered to connect. If you want to see how much of your own cloud footprint is currently outside that boundary, that's the first question a CDEM assessment is built to answer.