Multi-Factor Authentication for Cloud Accounts

One Login Sits Above Everything Else

Cloud accounts invert the usual security picture. A stolen laptop loses you one machine. A stolen account owner login loses you every machine, every database, every backup and the ability to lock the intruder out, all through a web page that works from anywhere.

Passwords alone cannot carry that weight. They are reused across services, they appear in breach corpora, and a convincing sign in page collects them at scale. Multi-factor authentication adds a second requirement that a remote attacker with only a password cannot satisfy.

This article is about turning it on properly: which factor types are genuinely stronger, how each major platform implements it, how to make it mandatory rather than optional, and how to handle recovery without leaving a weaker door open beside the strong one.

Not All Second Factors Are Equal

Hardware security keys and passkeys

The strongest widely available option. A FIDO2 key or a platform passkey performs a cryptographic challenge that is bound to the exact website origin. Present the credential to a lookalike domain and the browser simply will not release it, which means the whole category of convincing fake login pages stops working.

Authenticator applications

Time based one time codes are a solid, free improvement over a password alone. Their weakness is that a code can be read aloud or typed into the wrong page, so a patient attacker running a live proxy can still relay it. Good, not phishing resistant.

Push approvals

Convenient and better than nothing, though vulnerable to approval fatigue where a user taps accept to make repeated prompts stop. Implementations that display a number to be matched in the login window substantially reduce that risk.

Text messages

The weakest common option. Numbers can be ported away from their owner and messages intercepted in transit. The NIST digital identity guidelines discuss the limits of out of band authenticators of this kind in SP 800-63B. Use it only where the provider offers nothing else, and treat it as temporary.

Where the Setting Lives on Each Platform

On AWS, the account root user is the priority. Sign in as root once, enrol a factor, then stop using it for daily work entirely. Both root and individual IAM identities can register virtual authenticator applications, FIDO2 security keys or passkeys, as described in the IAM MFA documentation. AWS has also been tightening its own requirements for root users, so expect prompts if you have not enrolled.

Azure handles authentication through Microsoft Entra ID rather than the subscription. Small tenants can switch on security defaults, which requires registration for everyone. Larger ones use Conditional Access policies to require a factor under chosen circumstances, and can insist on a phishing resistant method for administrative roles.

Google Cloud inherits its identity from Cloud Identity or Workspace, where 2-Step Verification can be enforced for an organisational unit. Hardware key support is first class, and the Advanced Protection Program restricts high risk accounts to keys only.

Developer clouds keep it straightforward. DigitalOcean, Linode, Hetzner, Vultr and their peers all offer authenticator based two factor sign in with recovery codes, enabled per user in account settings, and team owners can generally see who has enrolled.

Optional Means Half Your Team

Voluntary enrolment plateaus. The accounts that skip it are rarely chosen at random either, since the busiest people are the ones who postpone.

Enforcement has two shapes. Identity level enforcement refuses to complete a sign in without a registered factor, which is what Entra ID policies and Google's enforcement setting do. Authorization level enforcement lets the login succeed but denies sensitive actions unless the session was authenticated with a factor.

AWS supports the second through a policy condition. A permission policy can require that aws:MultiFactorAuthPresent is true before allowing anything beyond the minimum needed to enrol a device and sign in, which is a clean way to make enrolment the only path forward for existing users.

Whichever route you take, announce a date, give people a self service enrolment page and check the report afterwards. Enforcement without warning generates support tickets that get resolved by weakening the policy.

The same principle belongs alongside the permission design in cloud IAM fundamentals: strong authentication and least privilege solve different halves of the same problem, and neither compensates for the absence of the other.

The Part That Confuses Everyone: Automation

A frequent misunderstanding is that enabling MFA will break scripts and pipelines. It does not, because those do not sign in the way a person does.

Automation should use workload identity: a role assumed by an instance, a service account attached to a function, or a federated token issued to a build job. None of those prompt for a code, because none of them are a human session that could be phished.

Where a human runs command line tools interactively, the pattern is to exchange long lived credentials for a temporary session that carries proof of the factor. On AWS that is a call such as aws sts get-session-token --serial-number arn:aws:iam::123456789012:mfa/alice --token-code 123456, returning credentials valid for a limited window.

The right conclusion is to reduce the number of static keys rather than to weaken sign in. That argument, and the mechanics of replacing keys with short lived credentials, is covered in managing API keys and secrets in cloud projects.

Planning for the Lost Phone

Every provider offers a recovery path, and that path is now part of your attack surface. A support process that restores access after a few personal questions is a second door beside the reinforced one.

Take the recovery codes at enrolment and store them somewhere genuinely durable and access controlled: a password manager the team already audits, or a sealed envelope in a safe for the highest value accounts. Not a screenshot in a chat thread, which is where they usually end up.

Keep the account contact details current. Recovery frequently depends on an email address, and a forgotten address at a former employee's domain has stranded more than one organisation. Keep billing contacts accurate for the same reason.

For organisations, designate a break glass identity: a separate high privilege account with its own hardware factor, stored offline, used only when normal administrative access is impossible. Alert on any use of it, and reconcile every use against a written record, which fits naturally into the practices in audit logging in the cloud.

Review enrolment when people join and leave. An account belonging to someone who left last year, still holding their factor, is a gap that no policy will close on its own.

Questions That Come Up

Most of this is a few minutes of setup per account. If you are working through it on a hyperscaler, the AWS account listings describe an account where root and IAM factor enrolment are both available, and the AWS versus Azure comparison covers how differently the two model identity.