Two-Factor Authentication on Cloud Accounts

A password is one secret, and secrets leak. They are reused across sites,
captured by malware, guessed from breach databases and handed over to convincing
phishing pages. A second factor means that knowing the password is not enough,
which converts most credential compromises from an incident into a non-event.

For a cloud account, where the credential controls your entire
infrastructure and your billing, this is not optional.

The options, worst to best

SMS codes

Better than nothing, and worse than everything else. The weakness is that
your phone number is not really yours: it is held by a carrier that can be
persuaded to move it. SIM swap attacks are a well-established technique
precisely because so many accounts can be recovered through a phone number.
Messages can also simply fail to arrive on a different network.

Use SMS only where a provider offers nothing else, and treat it as a
temporary arrangement.

Authenticator applications

A time-based code generated on your device, with no network involved. This is
the right default for most people: free, supported essentially everywhere, and
immune to carrier-level attacks.

Its limitation is that a convincing phishing page can ask for the code and
use it immediately, because the code is just another thing you can be persuaded
to type. It defeats credential theft and does not fully defeat real-time
phishing.

Hardware security keys

A physical device using the WebAuthn standard. The important property is that
the key verifies the website’s identity before responding, so a phishing site at
a lookalike domain receives nothing. This is the only option that genuinely
defeats phishing rather than merely raising the cost.

For the root credentials of an account that controls production
infrastructure, this is worth the modest price. Buy two: one in use and one
stored somewhere safe.

The part people skip

Recovery planning is where multi-factor authentication goes wrong, and the
failure is not a breach but a lockout.

When you enable it, you are shown recovery codes. Save them somewhere that
does not depend on the device you are protecting. A password manager is fine. A
note on the phone that holds the authenticator is not, because the scenario you
are planning for is losing that phone.

Register a second factor as well as a first wherever the platform allows it:
two hardware keys, or a hardware key plus an authenticator app. A single factor
with no backup is a single point of failure that you created deliberately.

Then think about the organisational version of the same problem. If the one
person holding the root credentials and the authenticator is unreachable, can
the business regain access to its own infrastructure? For anything commercial,
the answer needs to be yes, which means the credentials and recovery codes
belong in a shared vault with documented access rather than on an individual’s
phone.

Where to apply it

Not only the root login. The same reasoning applies to:

• Every user on the account, not just administrators. A compromised read-only
  user is still a disclosure.
• The email address used for account recovery, which is the route back in for
  everything and is therefore as sensitive as the account itself.
• The domain registrar and DNS provider, which are frequently overlooked and
  would let an attacker redirect your traffic without touching your servers at
  all.
• Your version control account, which usually holds the deployment
  credentials.

Securing the cloud account while leaving the recovery mailbox protected by a
password alone is a common and self-defeating arrangement.

Enforcing it across a team

Larger platforms let you require multi-factor authentication through policy,
so that users without it cannot perform sensitive actions. Where that exists,
use it: voluntary adoption produces partial adoption, and the account that
matters is the one that opted out.

Where policy enforcement is not available, the practical substitute is a
periodic review of who has access and whether each of them has a second factor
enabled. Combine it with removing accounts belonging to people who have left,
which is the other thing that never happens on its own.

What it does not solve

Multi-factor authentication protects the login. It does nothing about API
keys, which authenticate without any interactive step at all. An account with a
hardware key on the console and a leaked access key in a public repository is
compromised through the key, and the second factor never comes into it.

Both need handling, and key hygiene is covered in
securing a new cloud account.