Cloud Account Ownership Transfer: What Complete Actually Means

A cloud account transfer is complete when you hold every path into the environment and no one else does.

Logging in successfully proves you have one path. It says nothing about the others, and there are usually more than people expect.

The paths that must change hands

Only the first line is addressed by "change the password". Everything below it persists, and most of it is invisible unless you go looking.

Recovery options are the quiet one

If the recovery email or phone number still belongs to someone else, they can initiate a password reset at any time. Every other control is downstream of that.

Replace recovery options before you do anything else. It is the step that makes the password change durable.

Machine identities are the technical one

API keys and service credentials are designed to work without a human present, which is exactly why they survive every human-facing security change.

On each platform, the specific things to enumerate:

• AWS — IAM users and their access keys, roles and their trust policies, instance profiles.
• Google Cloud — service accounts and every key attached to each.
• Azure — service principals, app registrations, client secrets and certificates with their expiry dates.
• VPS providers — API tokens, personal access tokens, and SSH keys in the account key store.

Role trust policies deserve particular attention, because a role can be written to allow a principal in a completely different account to assume it. That is a standing access path that no credential change touches, and it is the most commonly missed item in any transfer.

A verification sequence

Work through this in order, and treat it as the definition of "transferred":

1. Primary credential changed by you.
2. Recovery email and phone replaced with yours.
3. Existing MFA removed, your own enrolled.
4. Active sessions terminated.
5. Every human identity listed; anything unexplained removed.
6. Every machine identity listed; unexplained ones deactivated, then deleted.
7. Role trust relationships read and any external principals removed.
8. Billing administrator confirmed as you, on a payment method you control.
9. Organisation or management-group membership established, and its implications understood.
10. Audit logging enabled in all regions and writing somewhere you control.
11. All regions checked for running resources.
12. Budget alert set before you deploy anything.

Steps six and seven are the ones that turn a login into ownership. The hardening checklist expands each of these into concrete actions.

What does not transfer

Being clear about this avoids later surprises:

• Support entitlements may be tied to a contract rather than to the account.
• Compliance posture is a property of how you operate, not of the account you received.
• Responsibility for acceptable use attaches to whoever operates the environment — that is now you.
• Data protection obligations follow the data, and arrive with it.
• Promotional credits generally cannot be moved to a different billing account, though they may remain on the one you now hold.

Doing it in a sensible order

The sequence matters because each step depends on the previous one holding:

Before — agree exactly what will transfer, confirm the account state, confirm the billing position, and confirm nothing is outstanding.

During — change the primary credential first, then recovery options, then MFA. Only then start the audit, because the audit is only meaningful once authentication is yours.

After — revoke machine identities, review network exposure, enable logging, set budgets, and document what you found.

Doing the audit before securing authentication means auditing an environment someone else can still change.

Frequently asked questions

How long should a transfer take? The credential steps take minutes. A thorough audit takes hours. Both are worth the time.

What if I cannot change the recovery email? Then the transfer is not complete, and that should be resolved before anything else. Raise it rather than proceeding.

Do I need to rebuild the servers? If you cannot account for what is installed and running, rebuilding from a clean image is the most reliable answer.

What is the single best test of whether a transfer is complete? Ask yourself who else could still get in. If you cannot answer confidently, the audit is not finished.

The how it works page sets out the full sequence from evaluating a listing to a running, hardened environment.