The Post-Transfer Hardening Checklist for a Cloud Account

Whenever a cloud environment changes hands, the correct assumption is that you do not yet know what is in it. Not because anything is necessarily wrong, but because an environment you did not build is a system of unknown provenance until you have looked.

This is the order to work through. The order matters: each step closes a door that the next step depends on being closed.

Phase 1 — Take control of authentication

1. Change the primary credential. Password reset on the account holder identity. On AWS this is the root user, on Google Cloud the identity that owns the billing account, on Azure the subscription's account administrator, on a VPS provider the single account login.

2. Replace recovery options. Recovery email and phone number must become addresses and numbers you control. A recovery path you do not own is a standing back door that survives every password change.

3. Re-enrol multi-factor authentication. Remove existing MFA devices and enrol your own. Do not assume an existing enrolment belongs to you.

4. Terminate active sessions wherever the provider offers it. A password change does not always invalidate existing sessions.

5. Change the billing contact and any separate billing portal credential. On several platforms billing access is a distinct login.

Phase 2 — Revoke machine identities

This is the phase people skip, and the one that matters most. API keys, service accounts and service principals do not care about passwords or MFA. They keep working.

6. Enumerate every machine identity.

7. Read role trust relationships, not just permissions. A role can be assumable by a principal in a completely different account. No credential change affects that. This is the single most overlooked item on the list.

8. Deactivate before deleting. Deactivate unknown keys, wait, see what breaks. Deleting first turns an audit into an outage investigation.

9. Remove SSH keys from every instance's authorized_keys and from the provider's key store. Replace with your own.

10. Rotate any credential you keep. If it existed before you arrived, it is not yours until it has been rotated.

Phase 3 — Audit access and inherited policy

11. List every human identity. Remove anyone you cannot account for.

12. Check for organisation membership. An AWS account inside an Organization, or an Azure subscription under a management group, inherits policy from above — and its charges may roll up to someone else's invoice.

13. Review inherited guardrails. Service Control Policies, organisation policies and Azure Policy can deny actions regardless of your own permissions. Knowing what they are prevents a confusing afternoon later.

Phase 4 — Find out what is actually running

14. Check every region. Not just the one you intend to use. Resources run and bill in regions nobody has looked at. The billing console's breakdown by region is the fastest way to find them.

15. Inventory running resources — instances, volumes, databases, load balancers, reserved addresses, snapshots.

16. Audit each instance. Installed packages, running services, listening ports, cron jobs, systemd timers, and any startup scripts. Remove what is not explained.

17. Look for unattached and orphaned resources. Unattached volumes, unused reserved IPs and old snapshots bill indefinitely and tell you about the environment's history.

Phase 5 — Network

18. Review every firewall rule and security group. Close anything not explicitly required.

19. Remove 0.0.0.0/0 from SSH and RDP. Use a bastion, a VPN or the provider's session equivalent.

20. Move datastores off public addresses. A database reachable from the internet is the most common serious misconfiguration there is. The networking guide covers the pattern.

21. Check DNS records pointing at the environment, including any you did not create.

Phase 6 — Visibility and cost

22. Enable audit logging in all regions — CloudTrail, Cloud Audit Logs, Azure Activity Log — and confirm it writes somewhere you control.

23. Set a budget with alert thresholds before deploying anything. The budget guide covers this concretely.

24. Enable monitoring and alerting on utilisation and on anomalous activity.

25. Configure backups aligned to a written recovery point objective, and test a restore.

Phase 7 — Operate responsibly

26. Read the provider's acceptable-use policy. It applies to you as the operator, and it governs what may run and how email may be sent.

27. Confirm your data protection position. Any personal data you process brings obligations regardless of where the infrastructure came from.

28. Document the environment — what runs, why, who owns it, and what you changed. The next person, possibly you in six months, will need it.

The short version

If you do only five things: rotate credentials, re-enrol MFA, revoke every machine identity, check all regions for running resources, and set a budget alert. Those five remove most of the risk.

Frequently asked questions

How long should this take? A few hours for a simple environment, a day or more for a complex one. Doing it properly is faster than not doing it.

What if something breaks when I revoke a key? That is the point of deactivating rather than deleting first. Whatever breaks reveals a dependency you did not know about.

Do I need to reinstall the operating system? If you cannot account for what is installed, rebuilding from a clean image and redeploying your application is the most reliable answer.

Is this necessary for a small environment? The list is shorter but the principle is identical. Credentials and network exposure matter at every size.

The ownership transfer guide covers what should happen before this checklist begins.

Every environment in the RunCloudMarket catalogue is listed with its configuration and provider so you know what you are hardening before you start.