Untracked Cloud Accounts: 5 Signals Security Teams Can Check Today

Untracked cloud accounts are tenants, subscriptions or projects running real workloads and data outside your central governance, identity management and billing oversight. The core danger is simple: once an account sits outside your identity provider, you lose the signals that let you offboard staff, respond to incidents and track access. Finding them reliably means correlating several data sources at once, not trusting any single report.

---

TL;DR:

• Compare billing records from multiple months with DNS and certificate logs, identity provider apps, provider emails, and engineer account IDs; each reveals different accounts.
• Triage each account by finding its owner and data, classifying sensitive information, rotating exposed secrets, and securing administrator credentials before choosing its disposition.
• Coordinate migrations with legal or procurement when contractor accounts hold paid licenses, and verify data classification, contract terms, residency, and licensing before transferring sensitive data.
• Automate billing, DNS, and identity provider checks, then pair ongoing monitoring with periodic human reviews; faster sanctioned provisioning reduces the incentive to create hidden accounts.

---

Why untracked cloud accounts matter for security teams

An account nobody governs is an account nobody can secure. When a former contractor’s AWS project or a developer’s personal Google Cloud tenant sits outside your identity provider, offboarding processes never reach it. The credentials stay live long after the person has left, and nobody is watching for misuse.

This creates specific, compounding problems:

• Identity lifecycle breaks down, because deprovisioning tools only see accounts registered with the identity provider.
• Attacker dwell time increases, since forgotten service accounts and stale credentials sit unmonitored for months or years.
• Incident response slows, because responders cannot scope a breach across infrastructure they don’t know exists.
• Audits and budgets suffer surprise charges from unmanaged contracts nobody approved.

Security frameworks back up why this belongs on a governance agenda rather than a backlog item. NIST SP 800-53 sets out control baselines for asset inventory and access management that only work when every account that touches your data is in scope. A tenant outside that inventory is a gap in the control itself, not a minor exception to it.

Framework alignment matters because auditors and insurers increasingly expect organisations to demonstrate complete asset visibility, not just coverage of the systems they already know about.

How untracked accounts typically form in practice

Most untracked accounts start with good intentions. An engineer spins up a trial AWS account to test an idea over a weekend. A contractor uses a cloud credit tied to their own email rather than the company’s. A product team runs a proof of concept in a personal Google Cloud project because getting a provisioned account through IT would take two weeks.

Common sources include:

• Developer trial and sandbox accounts opened for a quick test and never closed.
• Contractor or agency credits issued outside the standard onboarding process.
• Early-adopter teams that built proof-of-concept tenants before a platform team existed.
• Unmanaged Google accounts created using a corporate email address, which Google treats as separate from any managed Workspace domain until converted.

That last case is worth flagging: Google accounts created with a corporate domain but never claimed by an administrator can sit entirely outside your control, even though they carry your company’s name. None of this is malicious. The risk comes from time, not intent: data accumulates, integrations get added, and the account becomes load-bearing infrastructure that nobody on the security team has ever seen.

Five-signal detection checklist security teams can run today

Relying on one data source to find shadow tenants will miss most of them. A practical discovery exercise merges five signals, a method Waldo Security sets out for locating unauthorised AWS, Azure and GCP accounts.

1. Billing and corporate-card reconciliation. Pull expense data spanning multiple months and match every cloud-related charge against your canonical list of billing entities.
2. DNS and certificate transparency checks. Audit subdomains and certificate transparency logs for records pointing at storage buckets or load balancers you don’t recognise.
3. IdP application catalogue review. Scan your identity provider’s connected-app list for SAML or OIDC integrations tied to cloud consoles nobody has registered.
4. Provider operational mail search. Search corporate mailboxes for billing receipts, usage alerts and renewal notices from AWS, Azure or Google Cloud.
5. Structured engineering surveys. Ask engineers for specific account IDs rather than open questions like “do you have any other accounts?”, which invites underreporting.

Each signal catches different accounts: DNS audits surface forgotten infrastructure that billing records miss, while provider mail catches tenants paid for on a personal card that never shows up in corporate expenses.

Once you’ve run all five, merge the results into a single tenant register. For every entry, record the owner, the workloads running on it, and a disposition: absorb into a managed account, sanction it with proper oversight, or retire it. Duplicate hits across signals are a good sign, since they confirm the account genuinely exists and is active rather than a false positive from a stale DNS record.

Pro Tip: Run the billing and IdP checks first. They’re the fastest to produce results and usually surface the accounts carrying the most risk.

Remediation and short-term recovery

Once you’ve confirmed an untracked account, triage it before anything else. Identify the actual owner, classify what data lives there, rotate any exposed secrets and secure root or admin credentials immediately. Don’t wait for a full migration plan before locking down access.

From there, you generally have three paths: absorb the account into your central tenant structure, invite the owner to convert it to a managed account, or retire it and migrate anything of value elsewhere.

Google’s own process illustrates this well. Administrators can use the transfer tool for unmanaged users to identify personal Google accounts created with a corporate email address and invite those users to convert to a properly managed account. Where a personal account already holds the exact username an administrator wants for a managed user, Google provides a conflict resolution path so the migration doesn’t stall on a naming clash.

Every migration needs billing and legal coordination, since moving data between tenants can trigger contract terms, data residency questions or licence transfers that engineering alone can’t resolve.

• Confirm data classification before migrating anything containing customer or financial data.
• Rotate credentials immediately, even before the account’s final disposition is decided.
• Loop in legal or procurement when a contractor-owned account held paid licences or support contracts.

Sustained detection: from one-time sweep to continuous monitoring

A single sweep tells you what exists today. It says nothing about the account someone spins up next month. Turning discovery into an ongoing control means building the five signals into automated pipelines rather than repeating a manual exercise annually.

Start with billing. Export cost and usage data into a warehouse such as BigQuery with consistent labelling, so new accounts and projects surface in the same report as everything else rather than needing a separate hunt.

• Automate DNS and certificate transparency log checks on a rolling schedule rather than a one-off audit.
• Pull IdP application exports daily so a new SAML integration gets flagged within hours, not months.
• Apply policy as code to provisioning, so teams get a sanctioned account fast enough that going around the process stops being the easier option.

Pro Tip: Slow provisioning is the single biggest driver of shadow tenants. Fix the approval bottleneck and the incentive to create untracked accounts mostly disappears.

The organisational model that works best pairs continuous automated correlation with a periodic human sweep, keeping an owner attribution policy that makes someone accountable for every account the moment it’s found.

Koritsu’s practical approach to hidden cloud costs and untracked tenants

We built our platform around the same correlation problem this article describes. Our AI platform continuously analyses cloud spending across accounts, and our agent, Kori, surfaces where money is being lost to inefficient infrastructure and build decisions. Clients start with a free assessment, and we only take a share of the savings we actually verify against the bill, before moving onto ongoing support if it suits them.

Treat discovery as an engineering problem, not a project

Shadow tenants aren’t a compliance checkbox you tick once. They’re a side effect of how fast your organisation provisions infrastructure, and that rate never stops. Treat discovery the way you’d treat any other observability gap: instrument it, test it, and keep iterating rather than filing a report and moving on.

The teams that stay ahead of this prioritise owner attribution over blame and make sanctioned provisioning faster than the workaround. Start with the five-signal checklist this week and build a tenant register you can actually maintain.

Where Koritsu fits alongside your detection work

Untracked accounts and untracked spend tend to travel together: an unmanaged tenant is also an unmonitored cost centre. Our Savings Opportunity Report applies continuous billing analysis to surface exactly this kind of hidden infrastructure, and our FinOps as a Service plans, Monitor, Advisor, Embedded and Premium, give teams ongoing coverage once the initial sweep is done.

What we offer	What it covers
Savings Opportunity Report	One-off assessment mapping hidden cost and inefficiency across your cloud accounts
FinOps as a Service	Ongoing monitoring and remediation support across Monitor, Advisor, Embedded and Premium plans
Success fee model	We only charge a share of savings verified against your actual bill

Start with a free assessment through our pricing page to see what an untracked account sweep could uncover in your own environment.

FAQ

What are cloud accounts?

A cloud account is a tenant or subscription with a provider such as AWS, Azure or Google Cloud that controls access to compute, storage and other services under a single billing and identity boundary. Organisations typically govern these centrally, but individuals can also create personal accounts using a corporate email address without any administrator involvement.

What is an untracked file?

In a cloud context, an untracked file is data stored in a bucket, drive or database that sits outside your organisation’s governed accounts and therefore outside your backup, access control and data loss prevention coverage. It typically surfaces during the same discovery work that finds untracked accounts, since the account and the data inside it share the same blind spot.

How do I tell if I have a cloud account?

Check your corporate billing records, search your email for provider receipts and alerts, and review your identity provider’s connected application catalogue for cloud console integrations. Running these checks alongside a DNS and certificate transparency audit, the five-signal approach security teams use, gives the most reliable picture.

Can anyone access your cloud storage?

Access depends entirely on how the storage is configured: a misconfigured bucket or an account with no administrator oversight can be reachable by anyone with the link or weak credentials. Untracked accounts carry extra risk here because nobody is monitoring their configuration for the kind of open access that a managed account would catch.

Sources

• Find and add unmanaged users | User management | Google Workspace Help
• How to Locate Unauthorized AWS, Azure, and GCP Accounts Across Your Organization
• NIST SP 800-53 Revision 5 (update)

Recommended

• Security - Read-only access, infrastructure and billing only