A cloud account is never more exposed than in the window between receiving it and configuring it. Whatever credentials exist at that moment are the only thing standing between your future infrastructure and anyone else who has ever seen them. The work in this article takes under an hour and it is the highest-value hour you will spend on the account.
The order below is deliberate. Each step closes a door that the following step assumes is already shut.
Change the primary password first
Do this before anything else, including exploring the console. The account was prepared by someone else, which means the delivered password has existed outside your control. Changing it is what makes the account yours rather than shared.
Use a generated password from a password manager rather than something you compose. The primary or root identity on a cloud account is not a credential you should ever need to type from memory, because after the next step you will rarely use it at all.
Enable multi-factor authentication on the primary identity
This is the single control that matters most. A password alone can be replayed; a password plus a time-based code cannot be replayed from a leaked string.
Every platform in the catalogue supports this, though they name it differently. AWS calls it MFA on the root user. Azure applies it through Entra ID and conditional access. Google Cloud calls it 2-Step Verification on the Google account that owns the project. DigitalOcean, Linode, Hetzner, UpCloud, Kamatera, Civo, OVHcloud, IBM Cloud and Oracle Cloud all expose it in account or security settings.
Two practical notes. Register a hardware security key as well as an authenticator app if the platform allows it, because an app lives on a device you can lose. And store the recovery codes somewhere that is not the same device as the authenticator, because recovering a locked-out root identity on a cloud platform is slow and sometimes impossible.
Review and rotate existing access keys
Programmatic credentials are the quiet risk. A password change does not invalidate an API key, an access key pair or a service account token. If any exist on the account when it arrives, they still work after you have changed the password and enabled MFA.
So enumerate them. Look for access keys, API tokens, service accounts, application credentials and personal access tokens, depending on the platform’s terminology. Delete anything you did not create. If you are unsure whether something is in use, deactivate rather than delete first, because deactivation is reversible and tells you quickly whether anything breaks.
The same applies to SSH keys registered at the account level. A key you do not hold the private half of is a standing login.
Create least-privilege users and stop using the primary identity
The primary identity on a cloud account can do everything, including dismantle the account and change its billing. That is exactly why day-to-day work should not happen through it.
Create a separate administrative user for yourself, grant it the permissions you actually need, and use that from then on. Then create narrower identities for anything automated: one per deployment pipeline, one per application, each scoped to the services it touches. If a pipeline credential leaks, the blast radius is that pipeline’s permissions rather than the whole account.
This feels like overhead on day one and pays for itself the first time something is compromised or someone leaves the team. On platforms with full identity systems, such as AWS, Azure, Google Cloud, Oracle Cloud and IBM Cloud, this is a native concept. On the simpler developer clouds the model is coarser, often a team-member role rather than a policy document, so use the roles that exist and compensate with separate accounts where isolation genuinely matters.
Set billing alerts before you provision anything
Cloud spend accrues continuously and silently. A misconfigured autoscaling group, a forgotten GPU instance or an accidentally public storage bucket serving traffic can produce a bill far larger than anything you intended, and the first signal is often the invoice.
Configure a budget and at least two alert thresholds before you create a single resource. Set one at a level you expect to reach in normal operation and one at a level that should never happen. The second one is the one that saves you.
Where a configuration includes promotional credit, understand that credit is not a spending cap. Once it is consumed or expired, charges continue against the payment method. Treat credit as a runway, not a limit, and set the alerts as though the credit were not there.
Inventory what already exists
Finally, walk the account and look at what is in it. You are checking for two things: resources you did not create, and access paths you did not establish.
Check compute instances, storage buckets and volumes, databases, networks and firewall rules, load balancers, DNS zones, scheduled functions and any marketplace subscriptions. Check every region, not just the one your console defaults to, because an unused region is a convenient place for something to sit unnoticed.
Then check the account-level settings that grant access without a login: registered SSH keys, authorised OAuth applications, third-party integrations, cross-account roles and trust relationships, and any support or delegated access grants.
A short checklist
- Primary password changed to a generated value.
- Multi-factor authentication enabled on the primary identity, recovery codes stored separately.
- All pre-existing access keys, API tokens and SSH keys reviewed, and anything unrecognised removed.
- A least-privilege administrative user created, and the primary identity set aside.
- A budget and at least two billing alert thresholds configured.
- Every region swept for unexpected resources.
- Account-level integrations and delegated access reviewed.
Why this sits with you rather than with the marketplace
CloudAccSale.com supplies a prepared starting point. From delivery onward the account is yours, and so is responsibility for its security configuration, its spend and its compliance with the provider’s terms of service. That division is not a disclaimer to skim past; it is the actual operating model, and it is identical to the model that applies to an account you create directly with a provider.
The practical consequence is that this hour is not optional. An account that is hardened in the first hour behaves like infrastructure. One that is not behaves like a liability.