All Tools View Categories About Contact Privacy

MFA-Required Policy Condition Generator

Build a statement requiring MFA (aws:MultiFactorAuthPresent), with an optional recent-MFA freshness check.

Runs entirely in your browser — nothing you enter is uploaded.
-
effect
0
conditions
-
structurally valid

  

About MFA-Required Policy Condition Generator

Requiring multi-factor authentication for sensitive AWS actions is one of the highest-value, lowest-cost security controls an account can adopt, and it is expressed in IAM entirely through a single condition key: aws:MultiFactorAuthPresent. MFA-Required Policy Condition Generator builds the statement that enforces it, including the optional, less commonly known second layer — requiring that the MFA authentication itself was recent, not just present at some point in the session.

The core of every statement this tool produces is the same: a Bool condition checking aws:MultiFactorAuthPresent equals "true". AWS sets this key only when the calling principal's session was actually authenticated with MFA; if MFA was never used, the key is absent from the request context entirely, and the condition evaluates to false. You choose the Effect the statement should carry — Allow, if you are narrowly granting a specific sensitive action only when MFA is present, or Deny, for the far more common pattern of attaching a broad statement that blocks an action whenever MFA is not present, letting some other Allow statement's permission only take effect once MFA has been used. The condition logic itself does not change between the two; only what the Effect means in context does, and the tool lets you pick either.

The optional second layer addresses a real gap in "MFA present" alone: a session can authenticate with MFA once, at login, and then remain valid — and MFA-present — for hours or days afterward, depending on session duration settings. For genuinely sensitive actions, some organizations want more than "MFA happened at some point"; they want "MFA happened recently." AWS exposes exactly this via aws:MultiFactorAuthAge, the number of seconds elapsed since the MFA authentication occurred, paired with the NumericLessThanEquals operator and a threshold you choose. Enabling the checkbox adds this as a second, independent entry in the same Condition block (both entries must hold for the statement to apply), with a sensible one-hour default of 3600 seconds that you can adjust to whatever your security posture requires. Because this genuinely changes behavior — a long-lived session that used MFA once will eventually stop satisfying a recent-MFA check — it is left as an explicit, visible opt-in rather than silently bundled in.

Beyond the condition itself, the tool is a standard statement builder: pick an Effect, list the actions the condition should govern (one per line — a blanket * for "every action," or a specific set like iam:DeleteUser), list the resources it applies to, and give the statement an optional Sid. The assembled statement runs through the same structural validator used across this tool category before being shown, confirming Version, Effect, Action, and Resource are all present and well-formed.

What this tool does not do is configure MFA itself — assigning an MFA device to a user, or requiring one be set up before any other action is permitted, are separate IAM/account configuration steps outside a policy condition. It also does not call AWS to verify anything; the entire assembly and validation happens locally in your browser.

Features

  • Bool condition on aws:MultiFactorAuthPresent, the core MFA-required check.
  • Choice of Allow or Deny effect, supporting both the narrow-grant and the common "deny unless MFA" patterns.
  • Optional recent-MFA check via aws:MultiFactorAuthAge + NumericLessThanEquals, with an adjustable seconds threshold (default 3600).
  • Multi-line actions and resources, collapsing to a string or array automatically.
  • Structural validation of the assembled statement and document.
  • Pretty-printed JSON output with Copy and Download .json.
  • Sample "deny unless MFA" scenario pre-filled, including the recent-MFA window.
  • One-click clear.
  • 100% client-side — nothing is uploaded.

How to Use

  1. Choose the Effect — Allow (narrow grant) or Deny (the common "deny unless MFA" pattern).
  2. List the actions the condition should govern, one per line.
  3. List the resources it applies to, one per line.
  4. Optionally enable "Require recent MFA" and set the maximum age in seconds.
  5. Optionally set a Sid.
  6. Click Build MFA statement and check the structural validation result.
  7. Copy or download the JSON and attach it to your policy.

Examples

Example 1 — deny everything without MFA. Effect Deny, actions *, resources *, no recent-MFA check — a broad statement that blocks all API calls whenever the session lacks MFA, letting Allow statements elsewhere take effect only with MFA present.

Example 2 — require recent MFA for account deletion. Effect Deny, action iam:DeleteUser, resources *, recent-MFA enabled at 900 seconds (15 minutes) — blocks the action unless MFA was both present and used within the last 15 minutes.

Example 3 — narrow Allow grant. Effect Allow, action iam:ChangePassword, resource arn:aws:iam::123456789012:user/${aws:username}, MFA required — grants self-service password change specifically when MFA is present.

Example 4 — one-hour MFA freshness for billing changes. Effect Deny, actions covering aws-portal:*, recent-MFA enabled at the default 3600 seconds.

Example 5 — MFA present, no freshness requirement. Recent-MFA checkbox left off — the statement only checks that MFA was used at some point in the session, with no age limit.

Benefits

  • Enforces MFA correctly with the exact condition key and operator AWS expects.
  • Adds the less-commonly-known recent-MFA freshness check as a clear, optional layer.
  • Supports both the Allow-grant and Deny-unless-MFA patterns from one form.
  • Structural validation before you attach the statement.
  • Copy or download straight into the IAM console, CLI, or IaC.
  • Private — nothing entered ever leaves your browser.

Frequently Asked Questions

Should this be an Allow or a Deny statement?
It depends on the pattern you want. An <strong>Allow</strong> with the MFA condition grants access only when MFA is present — useful for a narrowly scoped statement like allowing a sensitive action only with MFA. The far more common real-world pattern is a <strong>Deny</strong>: "deny this action <em>unless</em> MFA is present," attached broadly, so that an existing Allow elsewhere only takes effect when MFA was used. This tool lets you pick either effect; the condition logic (the Bool check on <code>aws:MultiFactorAuthPresent</code>) is identical either way — only the Effect field changes, and what it means depends on that choice.
What does aws:MultiFactorAuthPresent actually check?
It is a boolean condition key AWS sets to <code>true</code> only when the calling principal authenticated using multi-factor authentication for the current session (or, for a role, when the session was assumed with MFA). If the key is absent (no MFA was used at all), a <code>Bool</code> condition checking it as <code>true</code> evaluates to false, which is why pairing it with a <code>Deny</code> effect produces "deny unless MFA."
What does the optional MFA age condition add?
A second, independent condition using <code>aws:MultiFactorAuthAge</code>, which is the number of seconds since the principal authenticated with MFA. Combined with the <code>NumericLessThanEquals</code> operator and a seconds value you choose (3600 = one hour, by default), it means "MFA must have been used recently" — not just present at session start, but within the given window. This catches the case of a long-lived session where MFA happened hours or days ago and arguably should no longer count as "currently" authenticated.
Why is the recent-MFA age condition optional rather than always on?
Because it changes user experience meaningfully: requiring recent MFA means a session that started with MFA still gets blocked once the age window elapses, forcing re-authentication for sensitive actions. Some organizations want that; others are fine with "MFA at all, for this whole session." Making it an explicit opt-in with a visible, adjustable seconds value avoids silently imposing session-timeout behavior nobody asked for.
What is a sensible default for the MFA age window?
This tool defaults to 3600 seconds (one hour) when the checkbox is enabled, a common balance between security and not forcing re-authentication too aggressively — but the field is a plain number input, so you can set it to whatever window your security policy calls for.
Does this require the principal to actually have MFA configured?
No — this tool only builds the IAM policy condition. Whether a user has an MFA device registered, and whether they are required to use it at sign-in, are separate account/IAM configuration steps (an MFA device must be assigned, and typically a separate policy is used to force users to set one up before doing anything else).
Can I list multiple actions and resources?
Yes — enter one action per line and one resource per line; a single value collapses to a plain string, and multiple values become a JSON array.
Does this validate against AWS's live IAM service?
No — it builds and structurally validates the JSON statement locally. It does not call any AWS API.
Is anything I enter sent anywhere?
No — the whole assembly runs in your browser.