Engineering Auth MFA

Credential & MFA Policy Prompt

Set credential rules that help instead of annoy — modern password handling, MFA factors and when to require them, and account-recovery that isn't the weakest link.

Overview

Credential policy is where security theatre lives — arbitrary rotation, complexity rules that breed Password1!, and a recovery flow that undoes the MFA you required. This prompt designs a policy on current guidance: how passwords are stored and checked (including breach-check), which MFA factors and when, lockout and rate-limiting, and a recovery path that isn't a backdoor.

How to use this resource

  1. Define the credential context

    Note how passwords are stored and checked today, which MFA factors you can support, and your account-recovery flow. The policy is designed around these and current guidance.

  2. Open this resource in Multi-Step Prompt Builder

    Load the prompt into Multi-Step Prompt Builder and fill in your context. Building it in stages keeps password handling, MFA, lockout, and recovery each fully worked out.

  3. Review the generated policy

    Read the password storage and breach-check rules, the MFA factors and when they apply, the lockout and rate-limiting, and the recovery path, confirming recovery is not a backdoor.

  4. Tighten the rules and re-run

    Adjust any rule that is theatre rather than protection, then regenerate so the policy helps users instead of annoying them.

Why This Works

  • Length and breach-checks beat the complexity rules that breed weak patterns
  • Step-up MFA protects sensitive actions without friction on every login
  • A recovery flow as strong as login closes the most common MFA bypass

Best for

  • Products handling accounts worth protecting
  • Teams using outdated complexity/rotation rules
  • Apps adding MFA and needing a recovery story

Not for

  • Reviewing session handling — use the Session Management Review Prompt
  • The broad auth mechanism choice — use the Authentication Strategy Prompt

Use cases

  • Setting a password and MFA policy for a product
  • Deciding when to require step-up MFA
  • Designing account recovery that doesn't bypass MFA

FAQ

Why does this policy prompt drop forced password rotation and complexity rules?

It follows current guidance instead of legacy habits. The PASSWORDS step favors length over arbitrary complexity, adds breach-list checking, and drops forced periodic rotation without cause — the rules that breed patterns like Password1!. The prompt produces a policy recommendation you run in your assistant and review; it isn't a security audit or a guarantee your accounts are safe.

How does this prompt keep account recovery from becoming an MFA bypass?

It treats recovery as a first-class threat. The RECOVERY step designs the flow to be no weaker than the login it protects, and the RULES state the recovery path must be as strong as the primary auth or it's the real attack surface. The output includes the recovery design with its threat note — a plan for your review, not a validated or compliant control.

When should MFA be required on every login versus stepped up?

The prompt separates the two so you don't add friction everywhere. The MFA step decides which factors — TOTP, passkeys/WebAuthn, SMS as last resort — and whether they're required or stepped up, while SENSITIVE ACTIONS names operations like changing email, payment, or deleting an account that require re-authentication. You supply the user base and sensitivity; the multi-step-prompt-builder builds the policy in stages and you own the final rules.

More resources from Multi-Step Prompt Builder

Resources that pair well

Related tools

Guides for this resource

Tip: Save time by exploring related resources and tools that integrate with this resource.