Cloud Provider Mandatory MFA: AWS, Google Cloud, Azure

All three major cloud providers now require multifactor authentication for some or all human sign-ins to their management consoles, and the scope, dates and exemptions differ enough that a multi-cloud team can be compliant in one and locked out in another. AWS requires MFA for the root user of every account type, Google Cloud requires 2-Step Verification (2SV) for console access on a schedule that depends on account type, and Microsoft requires MFA for Azure and admin portals and, in a second phase, for Azure command-line and API write operations. This guide compares what each provider enforces, from which date, for which identities, and what it means for break-glass accounts and automation. It is written for cloud platform, identity and security teams who run more than one provider. Platforms are listed alphabetically; order is never a ranking.

Key takeaways

Every provider targets humans, not workloads. AWS's requirement covers root user credentials only, Google's applies to user accounts using the Google Cloud and Firebase consoles, and Microsoft states that managed identities and service principals are unaffected.
Scope differs sharply. AWS: root users of all account types. Google Cloud: all in-scope user accounts at the console, phased by account type. Azure: every user signing in to the listed portals, then Azure CLI, PowerShell, infrastructure as code tools, REST and SDK write operations.
Federated identities are treated differently. Google lists federated SSO users as "to be announced" and lets them use their identity provider's 2SV; Microsoft accepts MFA claims from a federated identity provider; AWS's root requirement does not depend on federation because root is a local credential.
Break-glass accounts are in scope everywhere. Each provider recommends a phishing-resistant method: passkeys or security keys for AWS root, a security key for Google Cloud super admins, and passkey (FIDO2) or certificate-based authentication for Azure break-glass accounts.
Automation under a person's name is the casualty. Scripts that use a user account with only a password fail or will fail. Move them to the provider's workload identity: IAM roles, service accounts with federation, or managed identities and service principals.

What is changing and why

For years MFA on cloud consoles was a recommendation that providers left to customers. Each of the three has now made it a default the provider enforces itself, independent of customer policy. AWS's security blog of 15 November 2024 said that enabling MFA prevents more than 99% of password-related attacks and that more than 750,000 root users enabled MFA between April and October 2024. Google describes its change as a phased requirement that Google Cloud customers enable 2SV. Microsoft enforces MFA for its management applications regardless of the tenant's own Conditional Access policies; its Azure announcement of 15 August 2024 cited Microsoft research that MFA can block more than 99.2% of account compromise attacks and set out the phased rollout to portals first, then command-line and infrastructure as code tools.

The attack the providers are closing is simple: a password for a privileged console identity, obtained by phishing, reuse or password spraying (MITRE ATT&CK T1110.003), then used as a valid cloud account (T1078.004). Console identities sit at the top of the privilege chain, and the AWS Root Account Compromise Playbook shows how quickly a root takeover turns into account-wide loss. For the general case for MFA, see the MFA Guide.

Official timeline and current status

Dates below are as published on each provider's own page, listed in Standards and references and checked on 8 November 2026. Providers roll out gradually and notify affected customers; treat these as "as announced" and recheck before planning around a date.

Provider	Who is in scope	Dates as announced	Status on 8 November 2026
AWS	Root user of AWS Organizations management accounts	Requirement began May 2024, starting with larger environments	In force
AWS	Root user of standalone accounts	Expanded alongside the June 2024 passkey launch	In force
AWS	Root user of member accounts without centralised root access	Beginning spring 2025, gradual rollout with advance notice	AWS IAM documentation now states all account types require root MFA, with registration within 14 days of the first console sign-in attempt
Google Cloud	Reseller domain user accounts (not resellers' end users)	On or after 28 April 2025	Start date passed
Google Cloud	Personal Google Accounts, including Gmail accounts used as principals	On or after 12 May 2025	Start date passed
Google Cloud	Cloud Identity enterprise accounts not using SSO, organisations created before 3 August 2026	On or after 20 October 2026, with a one-time 90-day extension available	Start date passed; extended organisations later
Google Cloud	Same, organisations created on or after 3 August 2026	30 days after organisation creation	Rolling
Google Cloud	Federated users (Workspace SSO, Cloud Identity SSO, Workforce Identity Federation)	To be announced	Not yet scheduled
Microsoft Azure	Phase 1: Azure portal, Microsoft Entra admin center, Intune admin center	From October 2024, gradual; postponement available until 30 September 2025	In force
Microsoft Azure	Phase 1: Microsoft 365 admin center	From February 2025	In force
Microsoft Azure	Phase 2: Azure CLI, Azure PowerShell, Azure mobile app, IaC tools, REST API and SDK control plane create, update and delete	From 1 October 2025, gradual; postponement available until 1 July 2026	Postponement window closed; after Phase 2 starts a Global Administrator can only request a temporary lift through support

Who and what is affected

Identity type	AWS	Google Cloud	Microsoft Azure
Top-level account owner or admin	Root user: in scope in all account types	Super admin and other user accounts: in scope at the console when their account type's date arrives	All users of the listed apps, including Global Administrators and eligible role holders
Everyday human users	IAM users and IAM Identity Center users are not covered by the root requirement; MFA for them stays a customer control	In scope for the Google Cloud and Firebase consoles	In scope when using the listed apps
Command-line tools	Root requirement applies to console sign-in	gcloud CLI has no separate requirement; 2SV becomes part of the user's sign-in, including for gcloud authentication	Phase 2: CLI and PowerShell write operations; Microsoft recommends Azure CLI 2.76 and Azure PowerShell 14.3 or later
Workloads	Requirement affects root credentials only	Applications and workloads (the data plane) are not affected; the page addresses user accounts only	Managed identities and service principals are unaffected
Federated users	Not applicable to root; federated access uses roles	Federated SSO users use their identity provider's 2SV; enforcement date to be announced	Federated identity provider must send an MFA claim (multipleauthn)
Sovereign or special partitions	Confirm with the vendor	Confirm with the vendor	Enforced only in public Azure, not currently in Azure Government or other sovereign clouds

Availability notes. AWS: centralised root access management requires AWS Organizations. Google Cloud: the conformance logs and 90-day extension described here apply to Cloud Identity enterprise organisations not using SSO. Microsoft Azure: Conditional Access requires Microsoft Entra ID P1 or P2; tenants without it can use security defaults.

Finding affected systems and identities

AWS

Root MFA state: the IAM credential report includes a root account row with an MFA active column, and the IAM account summary reports whether the account has MFA enabled. In an organisation, collect this per member account, or remove member root credentials entirely with centralised root access management.
Root usage: search AWS CloudTrail for console sign-in events where the user identity type is Root. Any routine root use should be moved to IAM Identity Center administrators. See the AWS CloudTrail Guide.
Root access keys: the credential report also shows whether root access keys exist. Delete them; AWS strongly recommends not using root for everyday tasks.

Google Cloud

Conformance logs: for Cloud Identity enterprise organisations not using SSO, Google records per-user state in Cloud Logging from 1 August 2026. Principals with Logs Viewer (roles/logging.viewer) at organisation level can filter on the log entry type google.identity.mfaforall.LogEntry and read enforcementState, userEmail and mfaEligibility.
States to act on: ENFORCEMENT_STATE_UPCOMING_ENFORCEMENT (in the reminder window) and ENFORCEMENT_STATE_ENFORCED (prompted now). An mfaEligibility of INELIGIBLE means a Workspace policy blocks the user from enrolling: fix the policy before the date.
Admin console: in the Google Admin console, Security, Authentication, 2-step verification, review enforcement, the new user enrolment period (1 day to 6 months) and any exception groups.

Microsoft Azure

Enforcement banners: as a Global Administrator, check aka.ms/managemfaforazure (Phase 1) and aka.ms/postponePhase2MFA (Phase 2) for the dates applied to your tenant.
Sign-in logs: Entra sign-in logs show which application enforced the MFA requirement; filter for the Azure management applications and single-factor results to find user accounts used as service accounts.
Azure Policy rehearsal: Microsoft provides built-in MFA enforcement definitions with Audit and Deny effects so you can see which create, update and delete calls would fail. Detail is in Azure Mandatory MFA.

Migration options

Problem	AWS	Google Cloud	Microsoft Azure
Strong method for the top account	Passkey or FIDO security key for root (AWS recommends these as more resistant to phishing); one security key can serve multiple root and IAM users	Security key or other physical device for super admin 2SV, kept safe at your premises	Passkey (FIDO2) or certificate-based authentication for break-glass accounts
Reduce the number of top accounts	Centralised root access management removes root passwords, access keys, signing certificates and MFA from member accounts	Separate admin accounts per super admin; day-to-day work through Organization Administrators in a group the super admin is not in	Two or more cloud-only emergency access accounts with permanent Global Administrator; everyday admins through PIM
Scripts running as a person	IAM roles and temporary credentials; never root access keys	Service accounts, preferably with Workload Identity Federation instead of keys	Managed identities or service principals; ROPC flows such as MSAL AcquireTokenByUsernamePassword are incompatible with MFA
Need more time	Register within 14 days of first sign-in attempt; confirm any deferral with the vendor	One-time 90-day extension for qualifying organisations; opt-out possible but not recommended	Phase 2 postponement window closed on 1 July 2026; temporary lift via support only

The decision for small and large organisations differs mainly on the top account. A single-account AWS customer must protect one root user carefully; a large AWS Organizations estate should remove member root credentials and keep only the management account root, protected by two security keys. A small Google Cloud organisation may have one super admin; Google's guidance implies at least one separate admin identity for daily work. Azure tenants of any size need two emergency accounts. For workload identity patterns across all three, see the Workload Identity Federation Guide.

Where identity fits

Mandatory MFA is a forcing function for non-human identity hygiene. Any pipeline, runbook or integration that authenticates as a named person with a password is an unmanaged non-human identity, and each provider's change exposes it in a different way: Azure on write calls, Google at the console, AWS only if the automation used root. Inventory them now and move them to roles, service accounts or managed identities with least privilege.

Testing and rollback

Prepare break-glass first. Register two phishing-resistant authenticators per top account (AWS root, Google super admin, Azure emergency accounts), store them in separate locations and test sign-in. Microsoft recommends testing emergency accounts at least every 90 days. See the Break-Glass Account Guide.
Verify recovery paths. AWS root recovery uses the account email and phone number, so confirm those are current. Google keeps super admin self-recovery disabled by default for new customers and recommends keeping it that way, so Organization Administrators must know the recovery process.
Rehearse in audit mode. Use Azure Policy Audit, Google's conformance logs and the AWS credential report to list affected identities before enforcement reaches them.
Migrate automation in a pilot. Move one pipeline per provider to a workload identity and confirm it survives an enforced user account.
Enforce your own policy before the provider does. Turn on Conditional Access or security defaults in Entra, 2SV enforcement in the Google Admin console, and move AWS human users from IAM users to the AWS IAM Identity Center Guide pattern.

Rollback is limited by design. Azure allows only a temporary lift through support once Phase 2 has started; Google allows a one-time 90-day extension or an opt-out (opting back in triggers at least a 30-day grace period); AWS describes no deferral. The realistic rollback is therefore your own controls, such as a Google exception group used briefly, not the provider's requirement.

Metrics

Top accounts (root, super admin, break-glass) with two registered phishing-resistant authenticators, per provider: target 100%.
Member AWS accounts with root credentials removed: target all except the management account.
Google users in ENFORCEMENT_STATE_UPCOMING_ENFORCEMENT or INELIGIBLE: target zero.
User accounts performing Azure management write operations without MFA in sign-in logs: target zero.
Automation jobs authenticating as named users: count trending to zero.

Risks of doing nothing

Lockout at the worst moment: a break-glass account without a registered method fails when it is needed, because provider enforcement ignores your own exclusions.
Silent automation failure: Azure Phase 2 blocks writes but not reads, so a script can appear healthy until it tries to change something.
Phishable methods on top accounts: SMS satisfies Google's requirement for Google Accounts, but phishing-capable methods leave the account exposed to adversary-in-the-middle phishing (T1557). Prefer security keys. See the Phishing-Resistant MFA Guide.
Federation blind spot: Google's requirement does not yet apply to SSO users, so 2SV for them depends entirely on your identity provider's policy. Check it.

Common failure patterns

One root security key held by one person, with no second key and an out-of-date account email.
Opting a Google Cloud organisation out of enforcement to avoid friction and never opting back in.
Keeping user-based service accounts in Azure by excluding them from Conditional Access, which does not exempt them from Microsoft's own enforcement.
Treating AWS root MFA as job done while IAM users with console passwords have no MFA requirement at all.
Super admins using their everyday accounts for administration, contrary to Google's separate-account guidance.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev 5	IA-2(1), IA-2(2)	MFA for privileged and non-privileged accounts
NIST SP 800-53 Rev 5	AC-2	Emergency, root and service account management
NIST CSF 2.0	PR.AA-03	Users, services and hardware are authenticated
CIS Controls v8.1	6.5	Require MFA for administrative access
MITRE ATT&CK v20	T1078.004, T1110.003, T1557	Techniques mitigated

Practitioner checklist

Record, per provider, which enforcement dates apply to each of your accounts, organisations and tenants.
Register two phishing-resistant authenticators for every AWS root user you keep, every Google super admin and every Azure emergency account.
Enable AWS centralised root access management and remove member root credentials where you use AWS Organizations.
Review Google conformance logs for UPCOMING, ENFORCED and INELIGIBLE users and decide on the 90-day extension deliberately.
Run Azure Policy MFA definitions in Audit mode and fix every user account that performs management writes.
Move all automation off named user accounts to IAM roles, service accounts with federation, or managed identities.
Confirm your federated identity provider enforces MFA for cloud console access, since provider enforcement may not reach SSO users.
Test break-glass sign-in for all three providers on a fixed schedule and alert on every use.

Cloud Provider Mandatory MFA: AWS, Google Cloud and Azure enforcement dates and scope compared