Multi-Factor Authentication (MFA)

The Email That Almost Got Mara

Three months after the Theo incident, Trailbase runs a tidy account. Every human has an IAM user, the developers inherit permissions through groups, and the EC2 fleet uploads hiker photos through an instance role. Then an email lands in Mara's inbox. It carries the AWS logo, a plausible sender address, and a warning that her console access will be suspended unless she verifies her credentials within 24 hours. The link opens a pixel-perfect copy of the AWS sign-in page on a lookalike domain, and Mara, deep in a data migration and running on cold coffee, types her password before the URL registers.

She catches it a second later and tells Dana, who rotates the password within the hour. Nothing is lost. But the near miss exposes an uncomfortable truth: every identity at Trailbase is guarded by a single string of characters, and a string can be phished, guessed, leaked, or shoulder-surfed. All the least-privilege work from the last lesson assumed the person typing the password really is Mara.

Multi-Factor Authentication (MFA) exists to break that single point of failure. Authentication factors come in three categories: something you know (a password), something you have (a physical or virtual device), and something you are (biometrics such as a fingerprint). MFA requires proof from two or more categories, so a stolen password alone opens nothing. The attacker who phished Mara's password would still need the phone in her pocket. This one control prevents over 99% of password-related attacks.

How a Second Factor Changes the Sign-In

Here is what Mara's sign-in looks like once Dana turns MFA on. The password still comes first, and then AWS demands proof of the second factor before any session exists.

The flow has four steps. First, the user presents a username and password, the something-you-know factor. Second, AWS issues an MFA challenge matched to whatever device the user registered. Third, the user proves possession of that device, and the proof differs by type:

Fourth, and only after both factors verify, AWS grants the session. Notice the two verification mechanisms in that table, because the entire security difference between MFA types lives there: cryptographic signatures resist phishing, and typed codes do not.

Who Carries What at Trailbase

Dana rolls out MFA the same way she rolled out least privilege: match the tool to the person and the risk. AWS supports three families of MFA devices, and each one has a natural owner at Trailbase.

FIDO2 Security Keys and Passkeys: Dana and the Root Account

For the root account and her own admin user, Dana buys two hardware security keys. A security key is a small physical device, a YubiKey for example, that connects over USB, NFC, or Bluetooth and authenticates using the FIDO2 standard, an open protocol built on public key cryptography: the key holds a private key that never leaves the device, and AWS holds the matching public key.

This design is what makes FIDO2 phishing-resistant. During sign-in, the browser asks the key to sign a challenge that is cryptographically bound to the real domain. The lookalike page that fooled Mara would receive no valid signature at all, because the key only signs for the origin it was registered with. There is no code on screen for an attacker to steal, and nothing the user can be tricked into typing.

Virtual MFA Apps: Mara and the Developers

For everyone else, Dana standardizes on virtual MFA apps, the free and fast option. A virtual MFA device is an authenticator app that generates a time-based one-time password (TOTP): a 6-digit code, derived from a secret seed shared with AWS at enrollment plus the current time, that changes every 30 seconds under the RFC 6238 algorithm. Google Authenticator, Microsoft Authenticator, Authy, and Duo Mobile all work, and a single app can hold tokens for many accounts.

The honest caveat: TOTP raises the bar without being phish-proof. A sufficiently patient attacker can build a fake page that asks for the code too and relays it to AWS within its 30-second window. Mara's phishing email could have been built exactly that way. That residual risk is why Dana keeps FIDO2 on the identities that can do the most damage.

Hardware TOTP Tokens: The Compliance Corner

When Priya's audit firm reviews Trailbase, her checklist includes environments where phones are banned from the room. That is the niche for hardware TOTP tokens: dedicated battery-powered devices, such as Thales tokens purchased with an AWS-approved pre-shared seed, that display the same rotating 6-digit codes as an app. They satisfy compliance regimes that mandate a physical token and work where no phone is allowed.

Registering Devices, and Why One Is Never Enough

Enrollment is quick: in the IAM console, open the user, go to the Security credentials tab, choose Assign MFA device, and follow the wizard for the device type. The limits matter more than the clicks. Every user, including root, can register up to 8 MFA devices in any mix of types, while each individual device belongs to exactly one user and can never be shared.

That 8-device ceiling is an invitation, and Dana accepts it. She registers a second security key for root and locks it in a fire safe, because a lost sole device turns MFA from a shield into a lockout. Mara registers both her authenticator app and a synced passkey. Losing one factor should mean reaching for the backup, never filing a support case.

When recovery is needed anyway, the path depends on who lost what. An IAM administrator can deactivate a user's MFA device and let them re-enroll, so Mara losing her phone costs minutes. Root recovery goes through the AWS Support identity verification process and can take days, which is exactly why the fire safe exists.

Enforcing MFA: Turning a Habit into a Rule

A week after rollout, Dana spots a gap. Everyone has enrolled a device, but enrollment by itself only protects console sign-in. A developer using long-term access keys from the CLI skips MFA entirely, and nothing stops a user from simply never enrolling. Policy from lesson 1 gives her the fix: IAM conditions can inspect whether a request was MFA-authenticated and deny it when it was not.

Two condition keys do the work. aws:MultiFactorAuthPresent is a Boolean that is true when the request rides on MFA-backed temporary credentials. aws:MultiFactorAuthAge is the number of seconds since MFA authentication happened, which lets you demand a fresh challenge for the scariest operations even inside a valid session.

Here is the policy Dana attaches to the Developers group. It denies everything except a short self-service list until MFA is present, so a user without a device can enroll one and can do nothing else:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedWithoutMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Two elements deserve a slow read. NotAction inverts the action list: the deny applies to every action except the MFA-enrollment calls named there, which keeps the bootstrap path open. BoolIfExists handles the sneaky case. A request signed with long-term access keys carries no aws:MultiFactorAuthPresent key at all, and a plain Bool check would let it slide through unmatched. BoolIfExists treats a missing key as a match, so key-based requests get denied too. Recall the evaluation ladder from lesson 1: this explicit Deny beats every Allow the developer holds.

For the actions that ended Theo's bucket, Dana goes further and requires that MFA happened within the last hour:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireRecentMFA",
      "Effect": "Deny",
      "Action": [
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
      ],
      "Resource": "*",
      "Condition": {
        "NumericGreaterThan": {
          "aws:MultiFactorAuthAge": "3600"
        }
      }
    }
  ]
}

MFA on the Command Line

The morning after the enforcement policy lands, Mara's migration script starts failing with AccessDenied, which means the policy is working. Her script authenticates with access keys, and access keys carry no MFA context. Her first instinct, plugging her security key into the laptop, goes nowhere, because FIDO2 works only with the AWS Management Console. The CLI and the APIs accept MFA exclusively through TOTP codes exchanged for temporary credentials.

The exchange goes through sts:GetSessionToken, an STS call that takes the ARN of her MFA device (its serial number) plus the current 6-digit code and returns temporary credentials that are flagged as MFA-authenticated. Mara exports those, and every subsequent CLI call passes the aws:MultiFactorAuthPresent check until they expire:

# Get temporary credentials with MFA
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/user-name \
  --token-code 123456

# Response contains temporary credentials:
# {
#   "Credentials": {
#     "AccessKeyId": "ASIA...",
#     "SecretAccessKey": "...",
#     "SessionToken": "...",
#     "Expiration": "2024-01-15T12:00:00Z"
#   }
# }

# Export credentials for subsequent commands
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

Notice that sts:GetSessionToken sits in the NotAction list of Dana's enforcement policy. That is deliberate: the call has to be reachable without MFA, since it is the very step that trades an MFA code for MFA-flagged credentials.

Trailbase, Two Factors Deep

The phishing email that started this lesson would land differently today. Mara's password alone buys an attacker a login form asking for a factor they do not have. Root and Dana answer challenges with security keys that no fake page can satisfy, and a spare key sits in the fire safe. Every developer enrolled within a day, because the Developers policy made an MFA-less session nearly useless. Even Mara's scripts prove a second factor before they touch production, and CloudTrail records every enrollment and challenge along the way.

Common Pitfalls

Quick Reference

aws:MultiFactorAuthPresent    - Boolean: true if MFA was used
aws:MultiFactorAuthAge        - Numeric: seconds since MFA authentication

# List MFA devices for current user
aws iam list-mfa-devices

# List all virtual MFA devices in account
aws iam list-virtual-mfa-devices

# Create virtual MFA device
aws iam create-virtual-mfa-device --virtual-mfa-device-name MyMFADevice

# Enable MFA device for user
aws iam enable-mfa-device \
  --user-name username \
  --serial-number arn:aws:iam::123456789012:mfa/MyMFADevice \
  --authentication-code1 123456 \
  --authentication-code2 789012

# Deactivate MFA device
aws iam deactivate-mfa-device \
  --user-name username \
  --serial-number arn:aws:iam::123456789012:mfa/MyMFADevice

# Get session token with MFA
aws sts get-session-token \
  --serial-number arn:aws:iam::123456789012:mfa/username \
  --token-code 123456

Virtual MFA:  arn:aws:iam::ACCOUNT-ID:mfa/DEVICE-NAME
Hardware:     arn:aws:iam::ACCOUNT-ID:mfa/SERIAL-NUMBER
Root MFA:     arn:aws:iam::ACCOUNT-ID:mfa/root-account-mfa-device

Related Services

Further Reading

• AWS MFA Documentation
• FIDO2 Passkey Support Announcement
• MFA Best Practices
• Supported FIDO2 Configurations