Cloud Account Security Checklist: MFA, Least Privilege and Audit Logs

Most cloud breaches do not start with an exotic exploit. They start with a leaked access key, an admin user without multi-factor authentication, or a storage bucket someone made public for a quick test. This cloud account security checklist walks through the controls that close those gaps, in roughly the order you should apply them to an account you own and operate.

The steps apply to AWS, Microsoft Azure, Google Cloud and the smaller developer clouds alike. The names differ, but every serious provider offers the same building blocks: strong sign-in, scoped permissions, network controls, audit logs and billing alerts.

Phase 1: Lock down the owner identity #

Every cloud account has one identity with unlimited power. On AWS it is the root user, the email address used to create the account. On Azure it is typically the Global Administrator of your Microsoft Entra ID tenant plus the Owner of each subscription. On Google Cloud it is the Organization Administrator, or the Google account that created a project when no organization exists.

Protect it with MFA first

Turn on multi-factor authentication for the owner identity before you do anything else. Prefer phishing-resistant methods such as FIDO2 security keys or passkeys over SMS codes, which can be intercepted through SIM swapping. Register at least two factors (for example, two hardware keys stored in different places) so that losing one device does not lock you out.

Several major providers have started enforcing MFA for administrative sign-ins, but do not wait for a prompt. Check the security settings page today and confirm MFA is active.

Stop using it for daily work

The owner identity should be used only for the handful of tasks that require it, such as changing the account’s billing contact or closing the account. Everything else happens through separate, scoped users.

• Use a long, unique password stored in a password manager.
• Delete any access keys attached to the AWS root user. Programmatic access should never come from root.
• Point the account email at a monitored mailbox or a shared alias, not a single employee’s inbox, so recovery and security notices are never missed.
• Keep account contact details, including the security contact, current. Providers use these to warn you about abuse or compromise.

Phase 2: Build access around least privilege #

Least privilege means each person and each workload gets only the permissions it needs, for only as long as it needs them. It limits the damage when a credential leaks, and it makes audit reviews far easier.

Use named identities, not shared logins

Create an individual identity for every human. On AWS, IAM Identity Center is the recommended way to give people access, because it issues short-lived credentials instead of long-lived keys. On Azure, users live in Microsoft Entra ID and receive Azure role-based access control (RBAC) roles at a management group, subscription or resource group scope. On Google Cloud, users and groups receive IAM roles on the organization, a folder or a project.

Grant permissions to groups, not individuals. When someone changes teams you move them between groups instead of hunting down one-off grants.

Prefer narrow, predefined roles

Broad roles such as Owner, Editor or AdministratorAccess are convenient and dangerous. Start with the provider’s predefined job-function roles (read-only, billing viewer, network administrator) and tighten further with custom policies when you understand the access pattern. Google Cloud’s IAM recommender and AWS IAM Access Analyzer can both highlight permissions that have not been used, which is a practical way to trim grants over time.

Give workloads their own identities

Applications should authenticate as roles or service identities, not with keys copied from a developer’s laptop:

• AWS: attach an IAM role to the EC2 instance, Lambda function or ECS task.
• Azure: use a managed identity on the VM, App Service or Function.
• Google Cloud: attach a service account to the resource, and avoid downloading service account keys where workload identity federation can be used instead.

For CI/CD pipelines, most providers now support OpenID Connect federation with platforms such as GitHub Actions, which removes the need to store a long-lived cloud secret in the pipeline at all.

Phase 3: Secrets and credentials hygiene #

Leaked keys remain one of the most common ways accounts get compromised, often through a public Git repository. Treat every long-lived credential as a liability.

1. Inventory existing access keys and service account keys. Delete any that are unused.
2. Rotate the ones that remain on a schedule, and immediately if anyone who had them leaves.
3. Store application secrets in a managed secrets service (AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager) rather than environment files committed to source control.
4. Enable secret scanning on your code host so pushed credentials are flagged quickly.
5. If a key is exposed, deactivate it first, then investigate. Check audit logs for activity from that key.

Phase 4: Network exposure #

Identity controls who can call the cloud APIs. Network controls decide what the internet can reach on your servers. Both matter.

• Default to deny. Security groups, network security groups and VPC firewall rules should allow only the ports each service needs.
• Never leave SSH (port 22) or RDP (port 3389) open to 0.0.0.0/0. Restrict them to known IP ranges, or use a bastion or the provider’s session tooling, such as AWS Systems Manager Session Manager, Azure Bastion or Google Cloud Identity-Aware Proxy.
• Keep databases in private subnets with no public IP address.
• Turn on the account-level block for public object storage (S3 Block Public Access, or the equivalent public access prevention settings on Azure Storage and Cloud Storage) unless you deliberately host public content.

If subnets, route tables and firewalls are new territory, our guide to VPCs, subnets and cloud firewalls covers the fundamentals.

Phase 5: Audit logging and detection #

Audit logs record who did what, from where, and when. Without them you cannot investigate an incident or prove to an auditor that nothing happened.

Store logs in a location that the people being audited cannot delete, ideally a separate account, subscription or project dedicated to security. Then layer on detection: AWS GuardDuty, Microsoft Defender for Cloud and Google Security Command Center all analyze activity for suspicious patterns such as sign-ins from unusual locations or crypto-mining behavior.

Alerts worth setting on day one

• Any sign-in by the root or owner identity.
• Changes to IAM policies, role assignments or MFA settings.
• Audit logging being disabled or a log destination being modified.
• Creation of new access keys or service account keys.

Routing these alerts to a channel that someone actually watches is covered in our infrastructure monitoring basics guide.

Phase 6: Billing as a security signal #

A sudden spike in spend is often the first visible sign of a compromised account, because attackers commonly launch large compute fleets for mining. Set a budget with alert thresholds (for example at 50, 80 and 100 percent of expected spend) and send notifications to more than one person. On AWS, AWS Budgets and Cost Anomaly Detection handle this; Azure and Google Cloud offer budgets and alerts in their cost management tools.

Remember that budgets usually notify rather than stop spending. Our guide to cloud cost management with budgets and tagging explains how to go further with automated actions.

Phase 7: Resilience and ongoing review #

Security includes being able to recover. Configure automated backups for databases and critical volumes, keep at least one copy in a separate account or region, and test a restore. Consider immutable or locked backups so that a compromised administrator cannot delete them.

Finally, schedule reviews. A short quarterly pass catches the drift that accumulates in every account:

1. Remove users who have left and groups nobody uses.
2. Review who holds owner or administrator roles.
3. Check for unused keys and credentials.
4. Scan for public buckets, open management ports and unencrypted volumes. Provider posture tools such as AWS Security Hub, Defender for Cloud and Security Command Center can automate much of this.
5. Confirm alerts still reach the right people.

For provider-specific settings, the official documentation is the authority: see the AWS documentation, Microsoft Azure documentation and Google Cloud documentation. Our AWS platform overview and Microsoft Azure overview explain how each platform is organized.

Frequently asked questions #

What is the single most important cloud account security step?

Enable multi-factor authentication on the owner or root identity and on every administrator. It blocks the large class of attacks that rely on a stolen or guessed password.

Is SMS-based MFA good enough?

It is much better than no MFA, but SMS codes can be intercepted through SIM swapping or phishing. Hardware security keys, passkeys or an authenticator app are stronger choices for administrator accounts.

How long do cloud providers keep audit logs?

Default retention is limited and varies by provider and log type. For longer retention, export logs to storage or a log analytics service you control, and check the current defaults in the provider’s documentation.

Do small projects really need all of this?

The first phases, MFA, no root usage, least privilege, closed management ports and a billing alert, take under an hour on a small account and prevent the most common incidents. The later phases scale with your team and compliance needs.