Missing or weak MFA
Multi-factor authentication is the single highest-return control in cloud identity, because it breaks the direct line between a stolen password and account access. But MFA is rarely all-or-nothing: coverage erodes at the edges, where it matters most. The accounts that most need it — root and global administrators, break-glass identities, and privileged human users — are precisely the ones most often left on a password, a weak second factor, or an authentication path that skips MFA entirely. This sub-topic examines not just whether MFA exists, but whether it is enforced on the right identities, resistant to modern phishing, and impossible to route around through legacy protocols or unconditioned sign-in paths.
Overview
What this check looks like in practice
Multi-factor authentication is the single highest-return control against credential theft. Gaps concentrate on the accounts that matter most — root/owner, break-glass, and privileged human users.
Why it matters
Credential theft through phishing, infostealer malware, and password reuse is the most common initial-access technique against cloud tenants, and MFA is what turns a working password into a dead end. The catch is that attackers do not attack MFA where it is strong — they hunt for the identity or sign-in path where it is absent or weak: a root account with only a password, an admin exempted "temporarily," a service that still accepts legacy authentication, or a user who can be worn down by MFA-fatigue push spam. SMS and voice one-time codes, once considered sufficient, are now routinely defeated by real-time phishing proxies and SIM-swap attacks, so their presence can create false confidence. To an auditor, uneven MFA is a control-design failure regardless of intent — SOC 2, PCI-DSS, HIPAA, and the CIS Benchmarks all expect MFA on privileged and remote access — and to an attacker, one unprotected privileged identity is enough to compromise the entire estate.
What we assess
What we look for
- Root, management-account, and global-administrator identities lacking MFA, or protected only by a phishable factor rather than a hardware/FIDO2 security key
- Privileged human users who can complete sign-in with a password alone, or with MFA enforced inconsistently across accounts, subscriptions, or projects
- Reliance on SMS or voice OTP where phishing-resistant methods (FIDO2/WebAuthn passkeys, platform authenticators) are warranted for the risk level
- Authentication paths that bypass MFA entirely — legacy protocols (IMAP/POP/SMTP AUTH), basic authentication, or app passwords that accept a password with no second factor
- MFA enforced per-user or via opt-in settings rather than through centralized, tenant-wide policy that fails closed for new and unmanaged identities
- Break-glass / emergency-access accounts excluded from MFA policy without compensating controls — dedicated monitoring, alerting on use, and stored hardware factors
- Conditional Access or equivalent policies with broad exclusions (named users, trusted-location IP ranges, or device states) that quietly exempt sensitive access from MFA
- Programmatic and CLI access — long-lived API keys and access tokens — that operates outside the interactive MFA boundary, leaving human MFA cosmetic for the highest-value paths
Across your clouds
AWS, Azure & Google Cloud
AWS
The IAM credential report and account summary reveal whether the root user and each IAM user has MFA active; we check root for a hardware or FIDO2 security key, and look for policies that require the aws:MultiFactorAuthPresent condition on sensitive actions. In IAM Identity Center (successor to AWS SSO) we review the MFA enforcement mode — context-aware versus always-on — and whether phishing-resistant WebAuthn security keys and built-in authenticators are required rather than allowing optional TOTP authenticator apps.
Azure
In Entra ID we review whether MFA is enforced through Conditional Access (or at minimum Security Defaults) rather than the deprecated legacy per-user MFA, and whether Authentication Strength policies mandate phishing-resistant methods for administrator roles. We check Conditional Access for standing exclusions, whether legacy authentication is blocked, the state of the Authentication Methods policy (migrating off SMS/voice toward FIDO2 and number-matched Microsoft Authenticator), and that emergency-access accounts are excluded deliberately with monitoring.
Google Cloud
In Cloud Identity / Google Workspace we check whether 2-Step Verification is enforced at the organization or OU level — not merely available — with particular attention to super-admin accounts, and whether enforcement mandates security keys or passkeys rather than any-method 2SV. We also review reauthentication and session-length policies, Context-Aware Access rules, and any users allowed to bypass enrollment during grace periods.
Example finding
Global administrators enforced with SMS MFA and three standing Conditional Access exclusions
Risk: The tenant enforces MFA, but privileged administrators satisfy it with SMS one-time codes — defeatable by a real-time phishing proxy or SIM swap — and three named admin accounts are excluded from the Conditional Access policy for a legacy integration, meaning those identities can authenticate to the control plane with a password alone. A single phished or SIM-swapped credential yields full tenant control, and the exclusions mean the strongest identities have the weakest protection.
Fix: Apply an Authentication Strength requiring phishing-resistant methods (FIDO2 security keys or passkeys) to all administrator roles, migrate administrators off SMS/voice, and remove the standing Conditional Access exclusions — replacing the legacy integration's need with a service principal and certificate-based auth rather than an exempted human admin.
Remediation
How to close it
- 1 Inventory every identity that can reach the control plane — root/management account, global and privileged admins, break-glass accounts, and federated admins — and confirm MFA status for each across all accounts, subscriptions, and projects.
- 2 Protect the highest-value identities first: register hardware or FIDO2/passkey factors on root, super-admin, and management-account identities, and store break-glass hardware factors securely offline.
- 3 Enforce MFA through centralized, tenant-wide policy that fails closed (Conditional Access / IAM Identity Center / org-level 2SV enforcement) instead of per-user opt-in, so new and unmanaged identities are covered by default.
- 4 Require phishing-resistant methods (FIDO2/WebAuthn, passkeys) for all privileged access and migrate off SMS and voice OTP as an accepted factor for those roles.
- 5 Close the bypasses: block legacy and basic authentication protocols, disable app passwords, and audit Conditional Access exclusions and trusted-location assumptions so no sensitive sign-in path skips MFA.
- 6 Treat break-glass accounts as monitored exceptions — exclude them from interactive MFA only with dedicated alerting on every use, and review MFA coverage on a recurring cadence to catch drift as new identities and integrations are added.
Compliance evidence
Questions
Isn't having MFA enabled enough to pass an audit?
Not reliably. Auditors increasingly look at how MFA is enforced, not just whether it exists — coverage on privileged and remote access, resistance to phishing, and whether bypass paths (legacy protocols, broad exclusions) exist. Frameworks like PCI-DSS v4 now explicitly expect MFA that cannot be trivially circumvented, so an enabled-but-uneven deployment can still produce a finding.
Why do you flag SMS-based MFA if it's still better than nothing?
SMS and voice codes are meaningfully better than a password alone and are worth keeping for low-risk users, but they are defeated by real-time phishing proxies and SIM-swap attacks that now target administrators specifically. We flag SMS where the identity's privilege level warrants a phishing-resistant method — root, admins, and break-glass — so you can prioritize hardening the accounts whose compromise is unrecoverable.
How do you assess MFA without changing our sign-in configuration?
The assessment is read-only. We review MFA state through credential reports, identity-provider policy configuration, Conditional Access and enforcement settings, and authentication-method inventories — none of which alters your sign-in flows or touches production. You receive the gaps and a prioritized plan; enforcing the changes stays entirely in your team's hands.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
