MFA as a Baseline Identity Governance Control

Overview

This article converts an approved forum intelligence record into a client knowledgebase reference on enterprise multi-factor authentication governance. The source facts are attributed to Amazon Web Services and its article, “Supporting ASD’s multi-factor authentication campaign: Why MFA matters more than ever.” This Kenzie article is an original synthesis and is not a substitute for the official AWS source.

The supplied AWS summary states that AWS supports the Australian Signals Directorate’s multi-factor authentication campaign. It identifies phishing, credential stuffing and social engineering as credential threats that make password-only access inadequate. It also presents MFA as part of ASD’s Essential Eight and other cybersecurity frameworks.

What the intelligence means for enterprise identity risk

The practical governance question is no longer only whether passwords are convenient. For important identities, the question is whether password-only access remains acceptable given the credential attack methods described in the source record.

The approved forum record supports a baseline principle: MFA should be treated as a default identity control for privileged and commonly used accounts. Stronger authentication methods may be justified where exposure and business impact are higher, but the source does not provide a customer-specific implementation design or legal compliance conclusion.

Password-only access and credential attacks

The source record identifies phishing, credential stuffing and social engineering as examples of credential attacks. These attack types are relevant because they target or exploit credentials rather than relying only on technical vulnerabilities inside a platform.

Within the limits of the supplied evidence, the conclusion is that relying on passwords alone is inadequate for important accounts. The record also states that MFA prevents over 99 percent of password-related attacks. This article preserves that as an AWS-referenced statement and does not independently validate the metric.

Provider-enforced controls versus customer-managed coverage

The supplied AWS summary says AWS completed MFA enforcement for root users across all account types after a phased program from May 2024 to June 2025. This is important because it illustrates a distinction between platform defaults and identities that customers must still govern themselves.

Enterprises should separate what a provider enforces automatically from what internal teams must configure for workforce users, service-adjacent access and everyday administrative workflows. The evidence does not establish that any specific customer environment has complete MFA coverage.

Reviewing dependency chains beyond the cloud console

The forum record notes that AWS advises considering MFA beyond AWS for services such as email, collaboration tools and source control. This matters because a non-cloud account may influence password recovery, deployment workflows, secrets exposure or administrative access paths.

A practical review should therefore ask whether compromise of one account can create a path into another sensitive system. If it can, MFA coverage should be assessed across the dependency chain, not only in the cloud console.

Authentication methods mentioned in the source

The supplied AWS summary states that AWS supports FIDO2 passkeys and FIDO-certified security keys at no additional cost to AWS customers. The source record also frames phishing-resistant options as a relevant review point for architecture and procurement discussions.

This article does not prescribe a specific method for any client environment. Selection of authentication method should be handled through the client’s security, identity, operational and procurement processes, with staff support where implementation affects production access or privileged accounts.

What clients may safely do

Clients may use this article to brief stakeholders, frame identity governance questions and review whether their MFA policy covers privileged accounts, commonly used accounts and connected services such as email, collaboration tools and source control.

Clients should not treat this article as a step-by-step implementation procedure. It does not provide commands, console instructions, configuration values, exception workflows or a legal interpretation of any framework.

When to escalate

Escalate to qualified internal security, identity or managed hosting staff before making production identity changes, changing privileged access settings, creating exceptions, modifying account recovery paths, responding to a suspected credential compromise, or interpreting regulatory obligations.

Escalation is also appropriate when teams are unsure which identities are protected by provider defaults and which require customer-managed configuration.