Multi-factor authentication (MFA) has gone from a nice-to-have to a baseline requirement across cloud providers like AWS, Azure, and Google Cloud. This article covers what MFA is, why not every second factor offers the same level of protection, and how to roll it out in an organized way, starting with your most critical accounts.
What MFA Is, and Why a Password Alone Isn't Enough
MFA requires a user to prove their identity with at least two different factors before accessing a system. That reduces the risk of a breach even when a password leaks, gets reused, or is guessed.
Based on research on Entra ID/Azure AD accounts, Microsoft estimates that MFA cuts the risk of account compromise by roughly 99.22% overall, and by 98.56% even when the password has already been exposed. In other words: passwords still matter, but they are no longer enough as the only line of defense.
In Brazil, the LGPD (Law 13.709/2018), in Article 46, requires data controllers and processors to adopt technical and administrative measures that protect personal data from unauthorized access. Brazil's data protection authority, the ANPD, reinforces this in its Information Security Guide for Small Data Processing Agents (v1.0, Oct. 2021), which recommends MFA as a minimum technical safeguard for accessing systems, databases, and cloud environments, including at small organizations.
Not Every "Second Factor" Is Created Equal
Authentication factors generally fall into three categories:
- Something you know: a password, PIN, or answer to a security question.
- Something you have: an authenticator app, a physical token, a FIDO2 security key, or a code sent by SMS.
- Something you are: biometrics, such as a fingerprint or facial scan.
Combining two factors already qualifies as MFA, but the strength of each combination varies widely. An SMS code and a FIDO2 security key are technically both "a second factor," yet they hold up very differently against real-world attacks.
Phishing-Resistant MFA: FIDO2, WebAuthn, and Passkeys
Methods like SMS, one-time codes sent by email, and simple push notifications are vulnerable to real-time phishing techniques known as adversary-in-the-middle (AiTM) attacks, where the attacker intercepts the session between the user and the legitimate site. They're also exposed to "MFA fatigue," or prompt bombing, where an attacker fires off repeated approval requests until a tired or distracted user finally taps accept.
According to coverage of the Verizon 2025 Data Breach Investigations Report, prompt bombing shows up in roughly 14% of incidents involving MFA, while AiTM attacks and SIM swapping account for about 4%. These figures show that MFA lowers risk, but it doesn't close every attack path when the chosen method is weak.
NIST SP 800-63B (the Digital Identity Guidelines) sorts authentication strength into three assurance levels: AAL1, AAL2, and AAL3. Only cryptographic authenticators with channel and verifier binding, such as those built on the FIDO2/WebAuthn standard, including passkeys and physical security keys, are considered phishing-resistant and meet the highest level, AAL3. That's because the credential is bound to the legitimate site's origin (domain): a fake site simply cannot complete authentication, even if the user is tricked into visiting it.
Passwords, one-time codes, and out-of-band verification (like SMS) are not considered phishing-resistant by NIST. That doesn't mean they should be abandoned, especially at smaller organizations, but they should be treated as a minimum baseline, not the ideal standard for sensitive accounts.
What AWS, Azure, and Google Cloud Already Require
All three major cloud providers have made MFA mandatory over the past two years, each on its own timeline:
- AWS: MFA is mandatory for the root user across all account types; it has applied to standalone and management accounts since May/June 2024, and to member accounts since June 2025. AWS supports FIDO2 passkeys and FIDO-certified security keys, with up to eight MFA devices per user.
- Microsoft Azure/Entra: the requirement rolled out in two phases. Phase 1, starting October 2024, covers the Azure portal, the Entra admin center, the Intune admin center, and, since February 2025, the M365 admin center. Phase 2, starting October 1, 2025 (with a possible extension to July 1, 2026), extends the requirement to Azure CLI, PowerShell, the mobile app, infrastructure-as-code tools, and REST API calls for create, update, and delete operations. One important side effect: the legacy ROPC flow (direct username and password) stops working once MFA is enabled.
- Google Cloud: 2-Step Verification rolled out in three phases, wrapping up by the end of 2025. Phase 2, mandatory since May 12, 2025, already covered the console, the gcloud CLI, and the Firebase console.
Since these deadlines involve extension windows and can shift at the provider's discretion, always check the official documentation for each platform at the time you're planning your rollout.
How Standards and Frameworks Treat MFA
Beyond the LGPD and the ANPD guide, a few other references help define the right bar for your organization:
- NIST SP 800-63B, as mentioned above, defines the AAL1 through AAL3 levels and sets the bar for what counts as phishing-resistant authentication.
- CIS Controls v8.1, under Control 6 (Access Control Management), requires MFA for all administrative access to enterprise assets and specifically recommends phishing-resistant MFA, such as FIDO2, for high-risk users.
- ISO/IEC 27001:2022, in Annex A, includes control 8.5 on secure authentication, which serves as a general reference within a certifiable information security management system.
One caveat worth noting: the ANPD guide, published in 2021, lists SMS and tokens as acceptable MFA examples for small organizations. That's still valid as a minimum baseline, but more recent technical references, like NIST and CIS, along with real-world attack data from the Verizon 2025 DBIR, make it clear that SMS is the weakest method available. It shouldn't be treated as equivalent to a FIDO2 security key when protecting administrative accounts or access to sensitive data.
Rolling Out MFA Without Friction: Steps and Common Pitfalls
Rolling out MFA across an entire organization all at once usually triggers pushback. A phased approach tends to work better:
- Start with your highest-risk accounts: root users, global admin accounts, and privileged roles (like Global Admin, Security Admin, or Privileged Role Admin in Azure/Entra) should get phishing-resistant MFA first, enforced through Conditional Access policies combined with authentication strength requirements.
- Use transition tools to register strong methods: in the Microsoft ecosystem, a Temporary Access Pass lets a user register a FIDO2 key or passkey without relying on a second factor they don't have yet.
- Protect break-glass accounts, don't exempt them: emergency access accounts are usually excluded from specific Conditional Access policies to avoid accidental lockouts, but they still need strong MFA, ideally FIDO2 or certificate-based, within the overall mandatory requirement.
- Migrate service accounts and automation: instead of forcing user-style MFA onto automated accounts, migrate them to managed identities or workload identities, which were designed specifically to eliminate static credentials in these scenarios.
- Retire incompatible legacy flows: check whether any process still relies on ROPC (direct username and password) or other flows that break once MFA is enabled, and fix them before enforcing the requirement.
A few mistakes show up often during this process: excluding automation accounts from the MFA policy without migrating them to a managed identity, keeping legacy flows like ROPC active "just in case," and rolling out SMS as the only available method for every user, including administrators.
Conclusion
MFA doesn't eliminate risk entirely, but it significantly cuts the odds of an account being compromised, especially when the chosen method is phishing-resistant, like FIDO2, WebAuthn, or passkeys. Prioritizing admin and root accounts, following the deadlines already set by AWS, Azure, and Google Cloud, and aligning your rollout with standards like the LGPD, NIST SP 800-63B, and CIS Controls all help build a more secure cloud environment without grinding day-to-day operations to a halt.
If your company is still working through this transition, or wants to review how MFA is configured today, the Cloud Minds Trusted team can help plan a structured rollout, starting with what matters most.