Enable MFA for root and IAM users

MFA across AWS is almost free to enable. Registering a device on the root user costs nothing in AWS charges; enrolling IAM users costs at most a few pounds per hardware key. The only meaningful spend sits in Cognito, where the Advanced Security Feature that adds risk-based MFA is a usage-based charge per monthly active user. Against that, the downside of leaving any of these open is open-ended: a compromised root user can run up an uncapped bill, and a leaked key can drive a five- or six-figure crypto-mining event before anyone notices.

Treat each failing control as a line on the risk register rather than a compliance checkbox. Root MFA (IAM.9, IAM.6) is the highest-priority because it is the one credential nobody can lock out from inside the account. Programmatic-user MFA (IAM.19) catches the silent automation identities whose keys leak most often. Cognito MFA (Cognito.5) is where a credential-stuffing breach against your customers becomes a notification-and-fines event. Prioritise by what each identity can reach, not by the order the report lists it.

The insurance maths is one-sided. The remediation is a handful of device registrations plus a bounded Cognito migration. The downside of leaving it is the documented cost of a credential breach: regulatory fines, breach notification, forensics, and the runaway compute bill an attacker can generate on credentials you never locked behind a second factor.

Priya brings the scatter of MFA findings to her finance partner before the SOC 2 prep meeting because she wants the spend and the risk ordering agreed before she touches anything. The partner's first reaction is that the cost barely registers: registering a device on root costs nothing in AWS charges, enrolling IAM users is at most a few pounds per hardware key, and the only ongoing line is the Cognito Advanced Security Feature for risk-based MFA, a usage-based charge per monthly active user. As remediation budgets go this is near zero. What the partner cares about instead is which failing identity carries the most exposure, because that is what decides the order of work.

So the framing the partner sets is a risk register, not a checklist. Root MFA (IAM.9 and the hardware-only IAM.6) goes first because a compromised root user can run an uncapped bill and lock out every administrator, and it is the one credential nobody can disable from inside the account. The programmatic-only users IAM.19 catches go next, since their keys are the ones that leak into committed code and sit unwatched for days. The Cognito pool on optional MFA is treated as a notification-and-fines exposure against the customer base. The partner's closing note is that for a fix this cheap against a tail risk this large, leaving any of it open is an uninsured liability, not a saving.

The cost model here is asymmetric in a way that is rare for security work. Enabling MFA on root and IAM users costs essentially nothing, and leaving it open creates an unbounded tail risk. The one real ongoing cost is the Cognito Advanced Security Feature for risk-based MFA, a usage-based charge per monthly active user, which is trivial next to the documented cost of a credential-based breach.

The documented cost of a credential compromise includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, customer churn, and, for compromised root or broad keys, a runaway compute bill from crypto-mining that AWS is not obliged to waive. Against that, the remediation is a handful of device registrations plus a bounded Cognito migration. The finance role is to attach expected loss to each failing identity, so the root user and the broadest keys are fixed first.

MFA is the single highest-leverage control in cloud identity. It is the difference between an account that survives a leaked credential and one that does not. The report shows it as a scatter of separate findings across the root user, IAM users and Cognito, but the leadership question behind all of them is one sentence: if a password or key leaks tomorrow, can it act on its own?

The defensible end state is that every identity that can sign in requires a second factor by policy, not by each user remembering to enrol. Root carries a hardware key locked away for break-glass use, IAM users either carry MFA or have been retired in favour of short-lived role credentials, and customer-facing Cognito pools require MFA rather than offering it.

Almost none of this is a cost decision. Enabling MFA is free or near-free in AWS terms. It is a governance decision about whether credential compromise is prevented by design or only by everyone behaving perfectly all the time.

The MFA findings reached the executive review during SOC 2 preparation, after the security lead pointed out that the account still had a password-only root user and a customer pool where MFA was merely offered. The lesson leadership drew was not about any single identity. It was that credential compromise is the most common way into a cloud account, and that the business was relying on every user behaving perfectly rather than on a control that makes a stolen password useless on its own.

So the executive framing settled on two things. First, this is the rare class of control where the risk of inaction is severe and unbounded while the cost of action is essentially free for root and IAM and a small premium for Cognito, which is exactly the trade to approve fastest. Second, the end state is structural, not behavioural: root carries a hardware key locked away for break-glass use, standing IAM users either carry MFA or have been retired for short-lived role credentials, and customer pools require a second factor by policy. The question leadership keeps asking is whether a leaked password or key could act on its own tomorrow, and the only acceptable answer is no.

Credential compromise is the most common entry route into a cloud account, and MFA is the control that makes a stolen password or key useless on its own. The root user is the extreme case: its compromise is unrecoverable, which is why AWS rates root MFA Critical. The programmatic and customer-facing identities are the quiet cases, where the gap sits unwatched until a leak turns it into an incident.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially free for root and IAM and a small, bounded premium for Cognito. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve, and exactly the standard that should be enforced by default rather than left to memory.