Directory Service, MFA, and the root user

Lesson 3 of 4 in Authentication Strategies.

Three topics that look unrelated and are not: they are all about the strength of an authentication claim. A directory decides where the claim is made. MFA decides how hard it is to forge. The root user is the claim that outranks every policy you will ever write.

AWS Directory Service offers three ways to have a directory in AWS, and the exam picks between them on two questions: where is identity mastered, and do you need a trust relationship?

MFA comes in three families, and the exam ranks them: virtual TOTP authenticators (an app on a phone), hardware TOTP tokens, and FIDO2 security keys and passkeys. FIDO2 is the strongest because the credential is cryptographically bound to the AWS sign-in origin — a proxy phishing page cannot replay it, whereas a six-digit code can be read out over the phone to a convincing attacker. Root users and IAM users can register multiple MFA devices, which is what makes hardware MFA survivable when someone leaves their key at home.

Requiring MFA at sign-in is an IdP or console setting. Enforcing it on API calls is a policy job, and this is where candidates lose marks. The condition key is [aws:MultiFactorAuthPresent](/certifications/glossary?term=mfa-condition-key), and its availability rules are the whole exam question:

• Present and true — temporary credentials created with MFA (GetSessionToken or AssumeRole with an MFA serial and code).
• Present and false — temporary credentials AWS minted for an IAM user without MFA. Console sign-in with a password does this, and so does a service re-using the user's credentials for a downstream call.
• Not present at all — requests signed with long-lived IAM user access keys, and requests from federated identities.

That last case is the trap. A condition is only satisfied when the key is in the request context, so "Bool": {"aws:MultiFactorAuthPresent": "false"} inside a Deny never matches an access-key request — the key is absent, the condition cannot be evaluated, and the statement simply does not apply. The fail-closed form uses the [IfExists](/certifications/glossary?term=ifexists-suffix) suffix:

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

BoolIfExists is true both when the key is present and false and when it is missing entirely — so access keys are caught too. The NotAction list is the deliberate carve-out that lets a user without MFA still enrol a device and call GetSessionToken; without it the policy locks the user out of fixing their own problem. (Note how NotAction is being used with Deny here, which is its safe direction — Reading a policy precisely covers why NotAction with Allow is not.)

The root user is the account's original identity, addressed by the email it was created with. It has unrestricted access to its own account, and — this is the part that matters for design — it is not constrained by identity policies or permissions boundaries, and for the organization management account it is not constrained by SCPs either. You cannot write a policy that limits root. You can only remove the credential, or remove the account from the path where it matters.

A short list of tasks genuinely requires root: closing the account; changing the account name, root email address, or root password; changing the AWS Support plan; enabling S3 MFA Delete on a bucket; restoring access after an IAM change locked every administrator out; and deleting a resource policy that denies all principals. Everything else belongs to a role.

Since 2024 you no longer have to keep a root credential in every account. Centralized root access, enabled in IAM for an organization, has two independent halves:

• Root credentials management — delete (and later restore) the root password, access keys, signing certificates, and MFA for member accounts. There is then no root credential in those accounts to phish, reuse, or forget to rotate.
• Privileged root actions — the management account or an IAM delegated administrator calls sts:AssumeRoot against a member account with a task policy ARN naming one scoped task, for example arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy, and gets a session just long enough to delete the bucket or queue policy that locked everyone out.

The constraints are exam-shaped: sessions are short (15 minutes), root credentials themselves cannot make the AssumeRoot call, the global STS endpoint is not supported for it, and every session lands in CloudTrail. The wider organization setup — enabling the feature, choosing the delegated administrator — belongs to Organizations and multi-account governance; what matters here is recognising it as the modern answer to "we have 300 accounts and 300 sets of root credentials".

Key terms: AWS Directory Service, aws:MultiFactorAuthPresent, FIDO2 security key / passkey, AWS account root user, Centralized root access, Break-glass access

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.