--- title: "Is MFA enforced on cloud provider (AWS / Azure / GCP) management consoles?" url: https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-cloud-provider-management-consoles category: "Multi-factor authentication" canonical_key: q_idn_004 evidence_state: partial updated: 2026-08-24 --- # Is MFA enforced on cloud provider (AWS / Azure / GCP) management consoles? URL: https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-cloud-provider-management-consoles Section: Multi-factor authentication Evidence state: Partly verifiable from your tenant Answering for the portal is easy and usually beside the point. The console is not the only way into the control plane, and the other ways are the ones an attacker will use. ## What the carrier is actually asking The carrier is asking whether the administrative plane of your infrastructure, the place where machines are created and destroyed and where backups can be deleted, requires more than a password. It names the consoles because that is the recognisable surface, but the exposure is the whole management API: portal, command line, SDK, REST, and any long-lived access key that skips interactive authentication altogether. ## Why it is underwritten Control-plane compromise is the fastest route to a total loss. An attacker with cloud administrative access does not need to encrypt anything: it can delete storage, revoke access, and destroy the backups in the same account. Carriers that have paid these claims now ask about the control plane separately from general MFA, and some make it a condition rather than a rating factor for infrastructure-heavy insureds. ## Where the answer lives in Microsoft 365, Entra ID, and Azure Azure is directly measurable, and so is AWS. Google Cloud is not covered by Insurance Posture today, so a tenant that also runs Google Cloud can prove part of this answer and must attest the rest. That distinction is worth stating on the application rather than smoothing over. | Platform | Where the setting lives | What has to be true | | --- | --- | --- | | Azure | Conditional Access scoped to the Windows Azure Service Management API | Multi-factor is required for portal, Azure CLI, Azure PowerShell, and REST, not only for the portal application | | Azure | Subscription and management group role assignments | Owner and User Access Administrator holders are enumerated and covered by that policy, including guests and cross-tenant assignments | | Entra ID | Device code flow and authentication transfer policies | Device code flow is blocked, since it is the standard way a phishing kit obtains a token for a command-line session | | AWS | IAM users, the root account, and the account credential report | Root has MFA and no access keys; every IAM user with console access has MFA; long-lived access keys are inventoried and rotated | | AWS | Identity Center or federated access through Entra ID | Where AWS access is federated, the Entra Conditional Access policy is the enforcing control and must cover the AWS application | **Access keys are the answer most people forget** An AWS access key pair authenticates without a second factor by design. If a developer holds a long-lived key with administrative permissions, the console requiring MFA does not describe your exposure. Carriers increasingly ask about key age and rotation as a follow-up for exactly this reason. ## What a defensible yes requires - The multi-factor requirement is enforced against the management API, not only the web console. - The root or break-glass account of each cloud account is covered, or is protected in a way you can describe precisely. - Long-lived programmatic credentials with administrative permissions are inventoried, rotated, and ideally replaced with federated short-lived access. - Every cloud provider you actually use is covered by the answer, including the small account someone opened for a proof of concept. - Where a provider is outside your measurement, you say so rather than letting one provider stand for all. ## How this answer goes wrong The dominant failure is scope drift in the estate rather than in the control. Organisations answer for the production cloud they manage carefully and forget the second account, the legacy subscription from an acquisition, or the personal-turned-corporate account holding a marketing site. Underwriters do not ask which account, and claims adjusters find all of them. The second failure is treating the portal as the control plane. A Conditional Access policy on the Azure portal application, with the Service Management API left out, is a common and entirely invisible gap: everything looks correct in the policy list and nothing is enforced for the command line. ## If this answer turns out to be wrong Multi-factor answers are the ones a carrier can most easily show were material, because most US forms gate quoting on them rather than merely rating them. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [how materiality is decided](https://insuranceposture.com/glossary/materiality). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary). ## Frequently asked ### We only use Azure. Does that make this simpler? Yes, and it makes it fully verifiable. A single-provider estate can settle this answer from Conditional Access and role assignments alone, which is why it is worth saying explicitly on the application that Azure is the only cloud in scope. ### Is federated access to AWS through Entra ID enough? It is a strong position, because the enforcing control becomes your Conditional Access policy and short-lived credentials replace stored keys. It only holds if the federated application is actually in scope of the policy and no IAM users with console access remain alongside it. ### Does the root account need MFA if nobody uses it? Especially if nobody uses it. Unused root accounts have stale passwords, forgotten recovery addresses, and no monitoring. Every AWS security baseline treats root MFA as mandatory, and carriers have started to ask for it by name. ### What about Google Cloud or other providers? Insurance Posture does not read Google Cloud today, so that portion of the answer is attested rather than verified. Splitting the answer honestly is better than a blanket yes, and it is the kind of precision that helps at renewal rather than hurting. ## Related questions - [Is MFA enforced on all privileged / administrative user accounts?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-privileged-administrative-user-accounts) - [Is MFA enforced on all remote access (VPN, RDP, remote network admin)?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-remote-access) - [Are administrative/management login portals restricted from the public internet (closed or limited to specific IP addresses)?](https://insuranceposture.com/questions/network-and-logging/administrative-management-login-portals-restricted-from-public-internet) - [Does the Applicant utilize a Privileged Access Management (PAM) tool?](https://insuranceposture.com/questions/access-control/applicant-utilize-privileged-access-management-tool) --- Insurance Posture by SecValley. https://insuranceposture.com The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished. SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact. Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.