A password that has been reused, phished or leaked is a solved problem for an attacker. A second factor turns a stolen password into a failed login attempt. It is the cheapest meaningful security improvement available on any cloud account.
Not all factors are equal
| Factor | Assessment |
|---|---|
| Hardware security key | Strongest. Resistant to phishing by design. |
| Authenticator app (TOTP) | Good. Widely supported and easy to adopt. |
| Push notification | Good, provided people do not approve reflexively. |
| SMS codes | Weak. Vulnerable to number takeover; better than nothing. |
| Email codes | Weak, and circular if the email account is the recovery path. |
Hardware keys for administrators and an authenticator app for everyone else is a reasonable target for most teams.
Cover every entry point
- The root or owner identity, first.
- Every individual administrative login.
- The identity provider, if you federate – it becomes the master key.
- The email account used for account recovery.
- The domain registrar and DNS provider.
- Source control and CI/CD, which can deploy to production.
Securing the cloud console while leaving the recovery email unprotected simply moves the weak point rather than removing it.
Recovery codes need a plan
- Generate recovery codes when you enable the factor.
- Store them somewhere durable and access-controlled, not on the device.
- Make sure more than one trusted person can reach them.
- Record who has access and review it when people change roles.
- Regenerate them if that list changes.
Enforce it rather than encouraging it
Where the platform can require a second factor by policy, require it. Voluntary adoption reliably plateaus below full coverage, and the accounts that opt out are rarely the low-value ones.
Summary
Strongest factors for administrators, an app for everyone, coverage across every entry point including email and DNS, a tested recovery path, and policy enforcement rather than hope.
