Cloud Account Security Essentials: MFA, Roles, and Least Privilege
The three controls that stop most cloud account compromises: MFA on the root identity, roles instead of long lived keys, and least privilege on AWS, Google Cloud, and Azure, plus a takeover checklist.
Most cloud account compromises do not start with a clever exploit. They start with a root password reused from another site, an access key committed to a public repository, or an administrator role handed to someone who only needed to read a bucket. The three controls in this article, multi-factor authentication, role based access, and least privilege, close those doors on AWS, Google Cloud, and Azure. They cost nothing beyond an hour of setup, and they matter twice as much on an account that you did not create yourself.
Lock down the root identity first
Every provider has one identity that sits above IAM. On AWS it is the root user, the email address the account was opened with. On Google Cloud it is the Organization Administrator or, for a standalone project, the project Owner. On Azure it is the Global Administrator in Entra ID together with the subscription Owner. These identities can change billing, close the account, and undo every other control, so they are the first thing to protect and the last thing to use.
Turn on MFA for that identity before anything else. AWS supports FIDO2 security keys, passkeys, and virtual authenticator apps for the root user, and allows more than one registered device. Google accounts accept security keys, passkeys, and the Google prompt, and an organization can enforce 2-Step Verification for every user from the Admin console. Entra ID supports Microsoft Authenticator, FIDO2 keys, and Conditional Access policies that require MFA for anyone holding a privileged role. Prefer a hardware key or authenticator app over SMS.
Then stop signing in as root. Create a separate administrative identity with MFA for daily work and keep the root credentials in a password manager with the recovery codes. AWS documents a short list of tasks that require the root user, such as closing the account; everything else belongs to IAM.
Give people roles, not keys
The second control is to make sure every human and every workload signs in through an identity the provider can see and you can revoke. On AWS that means IAM users with MFA for small teams, or IAM Identity Center for anything larger, which lets people federate from an existing directory and assume roles with temporary credentials. On Google Cloud, people use their Google or Cloud Identity account and receive IAM roles on a project, folder, or organization. On Azure, users live in Entra ID and are assigned Azure RBAC roles at a management group, subscription, resource group, or single resource scope.
Workloads follow the same pattern. An EC2 instance gets an instance profile, a Lambda function gets an execution role, and a GitHub Actions job assumes a role through OpenID Connect, so no long lived access key ends up in a config file. Google Cloud offers Workload Identity Federation for the same purpose and attaches service accounts to Compute Engine and GKE workloads. Azure uses managed identities, which give a VM, function, or container an Entra ID identity with no secret to store. The guide to API keys and secrets management covers what to do with the keys that remain.
Least privilege in practice
Least privilege means each identity holds only the permissions its job needs, at the smallest scope that works. The consoles make the opposite easy: AWS offers the AdministratorAccess managed policy, Google Cloud the basic Owner and Editor roles, and Azure Contributor at subscription scope. All three suit one or two administrators and nobody else.
Start from the provider’s narrower building blocks. AWS managed policies such as ReadOnlyAccess and service specific policies cover most needs, and IAM Access Analyzer can generate a custom policy from the actions an identity actually used in CloudTrail. Google Cloud’s predefined roles, for example Storage Object Viewer or Cloud SQL Client, are far tighter than Editor, and the IAM Recommender flags roles that have gone unused. Azure’s built in roles such as Reader, Virtual Machine Contributor, and Storage Blob Data Reader can be assigned at resource group scope, and Privileged Identity Management lets an administrator activate Owner only for a set window rather than holding it permanently.
| Control | AWS | Google Cloud | Azure |
|---|---|---|---|
| Top level identity | Root user | Organization Administrator or project Owner | Global Administrator and subscription Owner |
| MFA enforcement | IAM policy condition or Identity Center setting | Admin console 2-Step Verification policy | Conditional Access policy |
| Human sign in | IAM Identity Center or IAM user with MFA | Google or Cloud Identity account with IAM roles | Entra ID user with Azure RBAC |
| Workload identity | IAM role, instance profile, OIDC federation | Service account, Workload Identity Federation | Managed identity |
| Permission review | IAM Access Analyzer, last accessed data | IAM Recommender, Policy Analyzer | Access reviews, PIM |
| Activity record | CloudTrail | Cloud Audit Logs | Activity Log in Azure Monitor |
Know when something changes
Prevention fails eventually, so the account needs a record of events and a way to raise an alarm. AWS CloudTrail records management events in every region by default and can send them to an S3 bucket and CloudWatch Logs; a metric filter on root sign in, IAM policy changes, or MFA being disabled gives you an alert within minutes. Google Cloud writes Admin Activity audit logs for every project automatically, and a log based alert in Cloud Monitoring can watch for IAM policy changes. Azure keeps the Activity Log for each subscription and Entra ID sign in logs, both of which Azure Monitor alert rules can query.
Add a billing alarm too. A sudden jump in compute spend in a region you never use is a reliable sign of stolen credentials being used for crypto mining, and AWS Budgets, Google Cloud budgets, and Azure Cost Management budgets can all email you when a threshold is crossed. Read Cloud Audit Logs: What They Record and Why They Matter for the detail on what each log contains.
Securing an account you did not create
If you take over an account from a former colleague, a contractor, or a marketplace purchase, assume the previous holder still has a way in until you prove otherwise. Work through this list on day one.
- Change the root or owner password, register your own MFA device, and remove any MFA devices you did not add.
- Update the account email, phone, and recovery options to addresses you control, then confirm the change from the provider’s verification message.
- List every IAM user, service account, and Entra ID user. Delete the ones you cannot explain and reset credentials on the rest.
- Rotate every access key, service account key, and client secret, and delete any that nobody claims.
- Review role assignments at the organization, subscription, and project level for identities outside your domain.
- Check for standing access you cannot see in IAM: AWS cross account roles with trust policies, Google Cloud service accounts with external principals, Azure guest users and app registrations.
- Read the last thirty days of audit logs for regions and services you do not use.
The cloud account handover checklist extends this list to billing, support plans, and quotas.
Where to go next
These controls apply whether the account is new or already carries usage history. The marketplace lists AWS accounts in several vCPU and credit tiers, Google Cloud accounts with prepaid and credit variants, and Azure accounts with pay-as-you-go and credit options. Whatever you pick, run the takeover list above before deploying anything.
For the underlying concepts, continue with IAM basics across cloud providers, which compares users, roles, and policies in more depth. The rest of the security series and the provider guides are in the Cloud Library.