Secure your first cloud account in an afternoon: the 10-point checklist

A new cloud account starts wide open in exactly the ways that matter: one all-powerful login, no logging, nothing blocking a public bucket. Closing those gaps takes an afternoon, and per the shared responsibility model, this side of the line is entirely yours. Work through the list before anything real ships.

The checklist

Copy this into your tracker; details for each item follow.

• 1. Lock down the root/owner identity (MFA, no access keys, stop using it)
• 2. Enable MFA for every human user
• 3. Individual identities via SSO, no shared logins
• 4. Least-privilege roles, start from zero, add as needed
• 5. Account-wide audit logging, shipped somewhere separate
• 6. Encryption at rest verified and enforced
• 7. Public storage blocked at the account level
• 8. Budget + billing alerts at 50/80/100%
• 9. Region chosen for residency; unused regions restricted
• 10. Private-by-default network, nothing exposed that doesn’t serve users

1. Lock down the root / owner identity

The root user (AWS), Global Administrator (Azure), or organization owner (Google Cloud) can do anything, including deleting the logs and backups you’ll set up below. Give it a long unique password in a sealed vault, enable MFA (a hardware key, ideally), delete any access keys attached to it, and stop using it. It exists for the handful of tasks that genuinely require it, a few account-level settings and emergencies, not for Tuesday.

2. Enable MFA everywhere

Then require multi-factor for every human user, via authenticator app or hardware key, not SMS if you can avoid it. Passwords get phished and reused regardless of strength; MFA is what stops a stolen password from becoming a takeover. Free, minutes to enable, and the single highest-impact line on this page.

3. Individual identities, never share logins

Each person gets their own identity, ideally through SSO from the identity provider you already run (Google Workspace, Entra ID, Okta) into AWS IAM Identity Center, Azure Entra, or Google Cloud Identity. Shared logins destroy accountability, the audit log reads “admin did it” forever, and can’t be cleanly revoked when someone leaves. One human, one identity, revocable in one place.

4. Apply least privilege

Grant permissions by starting from nothing and adding, never by starting from admin and meaning to trim later (nobody trims later). Use roles attached to groups, not per-user grants, and prefer short-lived credentials over long-lived access keys, a key in a laptop repo is the classic leak. This bounds the blast radius: when a credential leaks, the damage is limited to what that one identity could touch.

5. Turn on account-wide audit logging

Enable AWS CloudTrail, the Azure Activity Log (exported to a Log Analytics workspace or storage), or Google Cloud Audit Logs across the whole account, and ship the logs somewhere separate and tamper-resistant, in a multi-account setup, a dedicated log-archive account (see landing zone). This is your only record of who did what, and it only counts if it was running before the incident. At small scale it costs nearly nothing.

6. Verify and enforce encryption at rest

Modern clouds encrypt most storage by default, but “mostly by default” is not a policy. Verify it’s on for volumes, databases, and object storage, then set an account policy so it can’t be switched off. Provider-managed keys are fine to start; customer-managed keys are a compliance decision for later, not a day-one blocker.

7. Block public storage at the account level

One toggle each: S3 Block Public Access (account-wide) on AWS, disallowing anonymous blob access on Azure storage accounts, and the public access prevention org policy on Google Cloud. The leaked public bucket is still the most common cloud data breach in the world; this makes it impossible instead of merely discouraged. The rare genuinely-public bucket (a static website) can be an explicit, documented exception.

8. Set a budget and billing alerts

Create a budget (AWS Budgets, Azure Cost Management, GCP budgets) with alerts at 50/80/100% of expected spend. It’s a cost control, see avoiding bill shock, but it’s also a security control: a sudden spend spike in a quiet account is often the first visible sign of leaked credentials mining crypto. Many compromises are caught by the bill before any security tool notices.

9. Choose your region deliberately, and restrict the rest

Pick your region for data residency and compliance first, latency second, customer data may be legally required to stay in a specific country, and moving it later is a migration of its own. Then restrict unused regions by policy, so nothing lands in a jurisdiction nobody watches. Attackers favour exactly those regions for the same reason you ignore them.

10. Keep the network private by default

Give your VPC an IP range that won’t collide with your office or data-centre network later, and put databases and app servers in private subnets, only load balancers face the internet. No SSH or RDP open to 0.0.0.0/0; use the provider’s session-based access (SSM Session Manager, Azure Bastion, IAP) instead of an exposed port. Most intrusions walk through an open network path, not an exotic vulnerability.

Summary table

#	Control	Why it matters	Effort
1	Root/owner lockdown	The one credential that can do anything	15 min
2	MFA everywhere	Stops phished passwords becoming takeovers	15 min
3	Individual identities / SSO	Accountability + clean offboarding	1-2 h
4	Least privilege	Bounds the blast radius of a leak	Ongoing habit
5	Audit logging	The only record of who did what	30 min
6	Encryption at rest	Verified, enforced, not assumed	15 min
7	Block public storage	Kills the #1 cloud breach	5 min
8	Budget + alerts	Cost control and cheapest intrusion detector	15 min
9	Deliberate region	Residency and compliance by design	15 min
10	Private-by-default network	Closes the most-walked attack path	1-2 h

Roughly an afternoon, total. If you’re heading toward multiple teams or environments, don’t repeat this by hand per account, bake it into a landing zone so every account is born with all ten.

FAQ

What’s the first thing to do when securing a new cloud account?

Lock down the root (AWS), Global Administrator (Azure), or organization owner (Google Cloud) identity: long unique password, MFA, ideally a hardware key, delete any access keys attached to it, and stop using it for daily work. It’s the one credential that can do anything, including delete your logs and your backups, so it gets locked away and used only for the few tasks that genuinely require it.

Do I need MFA on a cloud account if I have a strong password?

Yes, without exception. Passwords get phished, reused, and leaked regardless of strength; MFA is what stops a stolen password from becoming an account takeover. It’s the single highest-impact control on this list, it’s free, and it takes minutes, enable it on the root/owner identity first, then require it for every human user.

What is least-privilege access and why does it matter?

Each identity gets only the permissions its job requires, granted by starting from nothing and adding, not starting from admin and trimming. It matters because it bounds the blast radius: when a credential leaks (when, not if), the damage is limited to what that identity could touch. One “admin everywhere” key turns a single phish into a full breach.

Should I enable audit logging even for a small account?

Yes, on day one. CloudTrail, the Azure Activity Log, and Google Cloud Audit Logs cost little to nothing at small scale and are the only record of who did what. Logs only help if they were running before the incident, turning them on afterwards gives you a very detailed record of the cleanup and nothing about the breach.

How long does securing a new cloud account take?

About an afternoon for all ten items on a fresh account, the root lockdown and MFA take thirty minutes, and blocking public storage is a single account-level toggle on each provider. It’s among the highest-return afternoons in the whole migration; retrofitting the same controls after workloads and teams pile in takes weeks.

---

The checklist covers the essentials; the details, which policies, which role boundaries, how to wire your SSO, depend on your provider and your team, and a small gap here has outsized consequences. If you’d like an experienced engineer to review or set up your account security before anything ships, talk to a Webisoft cloud engineer.