Is MFA enforced on cloud provider (AWS / Azure / GCP) management consoles?

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.

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.

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