Why MFA is not optional
A password is a single secret that can be phished, reused, leaked in an unrelated breach, or simply guessed if it is weak. Multi-factor authentication adds a second requirement that an attacker has to satisfy separately, and in practice that is what stops most account takeovers.
On a cloud account the stakes are higher than on a typical web service. Anyone with access can start resources that cost money, read whatever data is stored, and in most cases delete everything. That is why every provider pushes MFA on the owner identity specifically.
Choosing a factor type
Not all second factors are equally strong.
- Hardware security keys are the strongest option, because they cannot be phished by a fake login page.
- Authenticator apps generating time-based codes are the practical default. They work offline and are not tied to a phone number.
- SMS codes are better than nothing, but a phone number can be ported away by an attacker who convinces a mobile operator. Avoid SMS as the only factor on an account that matters.
Where to find the setting
| Provider | Where MFA lives |
|---|---|
| AWS | IAM, then Security credentials on the root user or the individual IAM user |
| Google Cloud | Google Account security settings, since the identity is a Google account |
| Microsoft Azure | Microsoft Entra ID, under security settings for the user |
| DigitalOcean | Account settings, then Security |
| Linode | My Profile, then Login and Authentication |
| Oracle Cloud | Identity settings for the user, under Multi-Factor Authentication |
| Hetzner | Security settings in the account console |
| IBM Cloud | Account settings, then Login policy |
The wording differs but the pattern is the same: it is a property of the identity, not of the project or subscription.
Save the recovery codes properly
Every provider issues backup or recovery codes when you enable MFA. These are the only way back in if the device holding your authenticator is lost.
Store them somewhere separate from the password itself. If both live in the same password manager entry and you lose access to that manager, you have lost the account. A printed copy in a safe place is not old-fashioned; it is a reasonable second location.
Enrol a second factor where you can
Several providers allow more than one MFA device on an identity. Where that is supported, register two: a phone-based authenticator and a hardware key, or two authenticator apps on separate devices. It removes the single point of failure entirely.
Then extend it to everyone else
Once the owner identity is protected, apply the same requirement to every other user on the account. Most providers can enforce this with a policy rather than relying on people to opt in, which is the only approach that works at more than a couple of users.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Hetzner vs Kamatera: Which Cloud Account Should You Buy?
- IaaS, PaaS and SaaS: Which Layer You Actually Need
- Amazon SES Accounts: What You Get and How to Choose a Configuration
- Cutting a Cloud Bill: Where the Money Actually Goes
Frequently asked questions
Yes. Authenticator apps hold many entries, each tied to a different account. Label them clearly so you can tell them apart.
You fall back to the provider's account recovery process, which typically requires proving identity and can take days. This is why the recovery codes should be stored separately.
No. Automation should authenticate with API keys or service accounts, not with the interactive login that MFA protects.
