The new domain owner may be able to re-create former employee mailboxes, then use those identities to access third-party SaaS systems that still trust the old organisation. Google itself does not hand over its own data, but connected applications may still expose sensitive HR, payroll, or records data if their access checks depend on stale identity assumptions.
Why this works as an account takeover path
The key issue is not that Google hands over its own mail or SSO data. The exposure happens when a third-party SaaS product still trusts the old organisation’s identity assertions, or keeps stale user records, group membership, or delegated access in place after the domain has changed hands. If the new owner can recreate a formerly valid identity, the SaaS may treat that account as legitimate.
That is an identity lifecycle failure, not a Google breach. The trust decision lives in the connected application, which may continue to accept an email address, SSO subject, or directory-linked identity that no longer belongs to the original business. In practice, the domain sale becomes a way to re-enter systems that were never fully detached from the old tenant’s assumptions.
For the attack pattern, the closest analogue is token or identity reuse after ownership changes, where old trust relationships outlast the original organisation. NHIMG’s Salesloft OAuth token breach shows the same downstream problem: once a third-party access path is still trusted, the application can expose data even when the original control plane is gone.
Where the data exposure usually appears
The highest-risk systems are the ones that use email ownership, domain assertions, or SSO membership as a proxy for authority. HR platforms, payroll tools, support portals, document stores, and internal admin consoles are all vulnerable if they were configured to trust the old domain without a clean offboarding and revalidation cycle.
What makes this dangerous is that access often persists in layers. The recreated account may unlock one application directly, but it can also restore password reset rights, group-based access, shared links, approval flows, or downstream integrations. A single identity assumption can therefore fan out into multiple sensitive records if the SaaS platform does not re-check the identity against current organisational control.
That is why stale external trust deserves the same attention as exposed credentials. NHIMG’s Ultimate Guide to Non-Human Identities is useful here because it frames the broader lifecycle problem: identities and the secrets or assertions that represent them only remain safe when ownership, expiry, rotation, and offboarding are enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Identity Lifecycle and Offboarding | Domain transfer can revive stale identity trust and access paths. |
| NHI-02 — Secrets and Credential Management | Connected SaaS often relies on tokens or assertions that outlive the original tenant. | |
| NHI-03 — Privileged Access and Least Privilege | Recreated identities can inherit excessive access in SaaS and admin tools. | |
| Recommendation — Revoke stale identities and bindings when ownership changes to prevent account re-creation abuse. Rotate or revoke credentials and tokens tied to decommissioned tenants before trust is reused. Limit access by business need and remove inherited privileges from identities tied to old domains. | ||
| NIST CSF 2.0 | PR.AA-1 — Identity Management, Authentication, and Access Control | The issue hinges on whether applications still trust obsolete identity assertions. |
| PR.AA-5 — Access Permissions and Authorisations | Access persists when SaaS authorisation does not revalidate tenant ownership. | |
| Recommendation — Enforce current identity assertions before allowing access to connected applications. Revalidate authorisation rules after organisational changes that affect identity ownership. | ||
| CIS Controls v8 | 6.3 — Access Control Management | The attack path depends on stale permissions surviving tenant change. |
| 6.7 — Manage Default Accounts and Remove Unnecessary Access | Recreated accounts become dangerous when old access is not removed promptly. | |
| Recommendation — Remove or disable access paths that depend on old organisational ownership. Eliminate unnecessary accounts and permissions after business or domain transitions. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | The abuse pattern uses legitimate-looking accounts to gain access to SaaS. |
| Recommendation — Hunt for access using valid accounts that were recreated or repurposed after ownership changes. | ||
Practitioner Guidance
What to verify: Test whether each SaaS application binds access to a durable tenant-controlled identifier, or whether it trusts a reusable email address, domain, or SSO assertion that can be recreated after domain transfer. The former is safer; the latter needs immediate review.
What to prioritise: Start with systems that hold HR, payroll, legal, finance, or customer records, then move to admin consoles and delegated integrations. These are the places where stale identity trust creates the most damaging blast radius if a domain is reclaimed.
Decision rule: If re-creating an old mailbox or SSO identity can trigger access without a fresh proof of ownership from the former organisation, treat the application as exposed until the trust model is corrected.
Practitioner takeaway: The real control question is not who owns the domain now, but whether any connected service still uses that domain as proof of authority without a separate, durable, and revocable tenant binding.
Related resources from NHI Mgmt Group
- What happens when service accounts and AI tool access are governed separately from the rest of identity?
- What happens when teams manage non-human identities as if they were ordinary service accounts?
- What happens when enterprise customers want SSO but the product cannot support it cleanly?
- What happens when a domain controller or forest-level Active Directory failure is not recovered quickly?
