How to Locate Unauthorized AWS, Azure, and GCP Accounts Across Your Organization

Cloud subscriptions and tenants that exist outside the corporate organizational hierarchy are a near-universal finding in cloud discovery exercises. The standard explanation is benign — an engineer opened a personal account during a hackathon, a contractor used a trial credit, an early team adopted a region before central governance was in place. The accounts themselves are seldom malicious. The risk is that they hold real workloads and real data, while sitting entirely outside every governance tool the organization has deployed.

The procedure below describes how to find these accounts using signals that are accessible to most enterprise IT functions, organized by data source.

Signal 1: corporate billing and expense data

The most direct signal of an unauthorized cloud tenant is a corporate-card charge from one of the three major cloud providers that does not match a known invoice from the central account-vending workflow. Pull 24 months of card transactions filtered to the canonical billing entities for Amazon Web Services, Microsoft, Google, and Oracle Cloud. Any non-zero charge that cannot be reconciled to a central billing arrangement indicates an account worth investigating.

Signal 2: DNS and certificate transparency logs

Engineers commonly point subdomains of corporate domains at resources in unauthorized tenants. A DNS audit of every subdomain — including wildcard records — frequently reveals CNAME or A-record targets pointing to S3 buckets, Azure storage accounts, or GCP load balancers in accounts the central team does not recognize. Certificate transparency logs accessible via public search tools surface a similar set of signals, including TLS certificates issued for subdomains the central team never authorized.

Signal 3: identity provider federation history

Most cloud tenants accept federated logins from corporate IdPs at some point in their lifecycle. Inspect the application catalog in your identity provider for SAML or OIDC integrations with cloud-provider sign-in endpoints that do not correspond to the central tenants. Each unfamiliar entry indicates a tenant whose root account is owned by someone in the organization, even when the corporate IdP is not the primary authentication path.

Signal 4: mail traffic from cloud providers

Cloud providers send a substantial volume of operational mail to root account owners — billing receipts, security alerts, service announcements, root credential changes. Search corporate mail for messages from the canonical operational addresses used by each provider, restricted to messages received over the past 36 months. Each correspondence thread typically maps to a discrete tenant. The broader Shadow CSP analysis describes additional patterns that emerge from this data set.

Signal 5: surveys with structured prompts

Engineering surveys are often dismissed as unreliable. They become considerably more useful when the prompts are specific. Rather than asking whether engineers maintain personal cloud accounts, ask which AWS account IDs, Azure subscription IDs, or GCP project IDs they have ever billed work to outside the central organization. The shift from open-ended to structured questioning typically increases the disclosed account count significantly.

Consolidation and remediation

Merge the five signals into a single tenant register, deduplicating where multiple signals point to the same account. For each tenant, document the owner, the workloads present, the data classes involved, and the proposed disposition: absorption into the central organization, sanctioned exemption, or retirement. The disposition workflow benefits from alignment with established cloud governance baselines such as the CISA SCuBA project, the CIS Controls, and applicable provisions of the NIST Cybersecurity Framework 2.0.

Establishing ongoing detection

A one-time sweep produces a baseline. New shadow tenants will continue to be created as long as the friction of central provisioning exceeds the friction of opening a personal account. Sustained detection requires continuous correlation of the five signals above, ideally combined with a discovery system that includes identity-level attribution. Waldo Security's Cloud Governance is designed for this continuous detection model and integrates with the same signals — billing data, mail, IdP federation, and DNS — without requiring agent deployment.

If you would like to see the current shadow-tenant picture for your environment, a demonstration is available on request.