Multi-factor authentication on cloud accounts

A cloud account controls infrastructure that can be used to run expensive workloads, reach internal systems and read whatever data you have stored. Compromise is not an inconvenience.

Multi-factor authentication is the single highest-value control available, and it is worth understanding what the different methods actually defend against, because the gap between them is wider than the interface suggests.

What each method resists

SMS codes defend against a stolen password and nothing more. They are vulnerable to SIM swapping, where an attacker persuades a mobile operator to move your number, and to interception. They are far better than no second factor and the weakest of the real options. Use them only where nothing else is available.

Authenticator apps generating time-based codes defend against stolen passwords and against SIM swapping. They remain vulnerable to real-time phishing: a convincing fake login page collects your password and code and replays both immediately. This is the most common practical attack against them, and it is fully automated.

Push notifications are similar in strength, with one additional weakness. Repeated prompts sent to a tired person at three in the morning are sometimes approved simply to make them stop. Number matching, where you must enter a code shown on the login screen, largely closes this and should be enabled where offered.

Hardware security keys using WebAuthn or FIDO2 defend against all of the above, including real-time phishing, because the key verifies the domain it is talking to before responding. A fake site gets nothing, regardless of how convincing it looks. This is the only method that structurally prevents phishing rather than making it harder.

Passkeys are the same underlying cryptography with the credential stored in a device or password manager rather than on a separate token. Same phishing resistance, more convenient, slightly different recovery considerations.

For any account that controls infrastructure, hardware keys or passkeys are the right answer.

Protect the root account differently

Every cloud provider has an account-level identity that sits above normal user management and cannot be fully restricted: the root user, the global administrator, the owner.

That identity should be treated as a break-glass credential rather than a login.

• Give it a long unique password stored in a password manager.
• Register a hardware key, and ideally a second one stored separately.
• Do not use it for daily work. Create normal administrative identities for that.
• Alert on any use of it, because legitimate use is rare and unauthorised use is an emergency.
• Remove any access keys attached to it entirely.

Most serious cloud account compromises trace back to a root identity protected only by a password.

Plan recovery before you need it

The most common self-inflicted problem with strong authentication is lockout. A lost phone, a broken key, a reset device, and suddenly nobody can administer the infrastructure.

Three precautions prevent it.

Register at least two factors. Two hardware keys, one carried and one in a safe. Or a hardware key plus an authenticator app on a device you do not carry.

Store recovery codes properly. Printed and in a safe, or in a password manager not protected by the same factor you might lose. Not in a note on the phone that is your second factor.

Ensure more than one person can administer the account. A single administrator is an availability risk regardless of how well protected they are. If that person is unreachable, the organisation cannot act.

Test recovery once, deliberately, while everything is working. Discovering that a recovery path does not work during an incident is a bad time to find out.

Enforcing it across a team

Voluntary adoption produces partial adoption. The account that lacks a second factor is the one that gets compromised.

Enforce it with policy rather than encouragement: conditional access rules, or the provider’s equivalent, that require a second factor for console access and deny access without one. Where risk-based policies are available, requiring re-authentication for sensitive operations or from unfamiliar locations adds a useful layer.

Two exemptions are commonly needed and both should be narrow: service accounts, which should not use interactive login at all and therefore should not need a second factor, and genuine break-glass accounts, which should be alerted on rather than exempted quietly.

Where MFA does not help

It is worth being clear about the limits, because MFA is sometimes treated as a complete answer.

It does not protect API access authenticated by a long-lived key. That is a separate problem, solved by eliminating long-lived keys rather than by adding factors.

It does not protect against a compromised session token, which is why session lifetimes matter.

It does not help if an attacker gains access through an application vulnerability rather than through the login page.

And it does not protect an account whose password reset flow goes to a compromised mailbox, which is why the email account behind your cloud account deserves the same protection as the cloud account itself.

For a view of how the providers differ on the points above, the cloud account catalogue lays out their respective strengths and configurations.

For the vendor’s own reference on the services involved here, see the Azure documentation on Microsoft Learn.

Trying this on real infrastructure is the quickest way to absorb it. Our Azure accounts come in five configurations, each priced separately, and the cloud account catalogue covers the alternatives.

Questions people ask