1. The frontend treats MFA as a page instead of an auth state.
2. The backend treats MFA success as global permanent trust.
3. Product treats every action as same risk.

normal login -> baseline session
sensitive action -> assurance check
assurance too low/stale -> step-up challenge
challenge success -> short-lived elevated auth context
action retry -> server authorizes action using updated context
audit -> record method, freshness, resource, decision

Knowledge: something the user knows
  - password
  - PIN

Possession: something the user has
  - authenticator app
  - hardware security key
  - phone/device-bound credential

Inherence: something the user is
  - biometric unlock used locally by a platform authenticator

- phishing resistance;
- authenticator binding;
- authenticator lifecycle;
- device compromise risk;
- recovery process strength;
- authentication age;
- session risk;
- transaction context;
- tenant policy.

The user already has a session, but a specific action requires stronger or fresher authentication.

- export regulated data;
- approve enforcement action;
- change payment account;
- invite tenant administrator;
- create API token;
- view secret configuration;
- change MFA settings;
- impersonate another user;
- delete case evidence;
- submit final regulatory decision.

Who are you?

Are you still the authenticated user, and do you currently satisfy the assurance requirement for this action?

MFA success -> allow admin action

MFA success -> authentication context updated
server authorization still checks subject, action, resource, tenant, state, policy, and assurance

type AuthContext = {
  userId: string;
  tenantId: string;
  authenticatedAt: string;
  methods: Array<'password' | 'totp' | 'webauthn' | 'sso'>;
  assuranceLevel: 'aal1' | 'aal2' | 'aal3' | 'custom_high';
  lastStepUpAt?: string;
};

export type AuthorizationInput = {
  subject: { userId: string; tenantId: string };
  action: string;
  resource: { type: string; id: string; state?: string };
  context: {
    auth: AuthContext;
    ipRisk?: 'low' | 'medium' | 'high';
    deviceKnown?: boolean;
    requestTime: string;
  };
};

User needs permission cases.approve_final
AND case state must be ready_for_final_approval
AND tenant must match
AND assurance must be AAL2 or better
AND last step-up must be within 10 minutes

- original action intent;
- resource identity;
- idempotency key;
- return location;
- challenge id;
- user-visible reason;
- cancellation path.

Can user perform this action now?

{
  "allowed": false,
  "reason": "step_up_required",
  "requiredAssurance": "aal2",
  "challengeUrl": "/auth/step-up?intent=..."
}

403 step_up_required

pre-check for UX
mutation enforcement for correctness

export type ApiError =
  | {
      code: 'unauthenticated';
      message: string;
    }
  | {
      code: 'forbidden';
      message: string;
      reason?: string;
    }
  | {
      code: 'step_up_required';
      message: string;
      challenge: {
        id: string;
        methods: Array<'totp' | 'webauthn' | 'idp_mfa' | 'password_reauth'>;
        requiredAssurance: 'aal2' | 'aal3' | 'tenant_high';
        expiresAt: string;
        retryAfterSuccess: boolean;
      };
    };

async function approveCase(request: Request) {
  const session = await requireSession(request);
  const caseRecord = await loadCase(request.params.caseId);

  const decision = await authorize({
    subject: session.subject,
    action: 'case.approve_final',
    resource: caseRecord,
    context: {
      auth: session.authContext,
      requestTime: new Date().toISOString(),
    },
  });

  if (decision.kind === 'step_up_required') {
    return json(
      {
        code: 'step_up_required',
        message: 'Additional verification is required before approving this case.',
        challenge: decision.challenge,
      },
      { status: 403 }
    );
  }

  if (decision.kind === 'deny') {
    return json({ code: 'forbidden', message: decision.reason }, { status: 403 });
  }

  return commitFinalApproval(caseRecord, session.subject);
}

load session -> load resource -> authorize with auth context -> maybe step-up -> maybe deny -> maybe mutate

export type StepUpIntent<T> = {
  description: string;
  idempotencyKey: string;
  run: () => Promise<T>;
};

export async function runWithStepUp<T>(intent: StepUpIntent<T>): Promise<T> {
  try {
    return await intent.run();
  } catch (error) {
    if (!isStepUpRequired(error)) {
      throw error;
    }

    const completed = await openStepUpChallenge({
      challenge: error.challenge,
      intentDescription: intent.description,
    });

    if (!completed) {
      throw new Error('Step-up challenge was cancelled');
    }

    return intent.run();
  }
}

async function onApproveFinalDecision(caseId: string) {
  await runWithStepUp({
    description: 'Approve final case decision',
    idempotencyKey: crypto.randomUUID(),
    run: () =>
      approveFinalDecision({
        caseId,
        idempotencyKey,
      }),
  });
}

export async function runMutationWithStepUp<T>(input: {
  description: string;
  mutation: (ctx: { idempotencyKey: string }) => Promise<T>;
}): Promise<T> {
  const idempotencyKey = crypto.randomUUID();

  const run = () => input.mutation({ idempotencyKey });

  try {
    return await run();
  } catch (error) {
    if (!isStepUpRequired(error)) throw error;

    const ok = await openStepUpChallenge({
      challenge: error.challenge,
      intentDescription: input.description,
    });

    if (!ok) {
      throw new Error('Additional verification was cancelled');
    }

    return run();
  }
}

The retry is safe only if the mutation is idempotent or server handles duplicate attempts correctly.

export type StepUpState =
  | { kind: 'idle' }
  | { kind: 'required'; challengeId: string; reason: string }
  | { kind: 'starting'; challengeId: string }
  | { kind: 'challenging'; method: 'totp' | 'webauthn' | 'idp_mfa' | 'password_reauth' }
  | { kind: 'verifying'; challengeId: string }
  | { kind: 'succeeded'; completedAt: string }
  | { kind: 'failed'; reason: string; retryable: boolean }
  | { kind: 'cancelled' }
  | { kind: 'expired' };

Cancel step-up != logout
Cancel step-up != action success
Cancel step-up == action not performed, user remains in baseline session if still valid

View dashboard: baseline session enough
Edit profile: baseline session enough
Create API token: step-up within last 5 minutes
Change MFA factor: step-up within last 5 minutes
Export regulated data: step-up within last 10 minutes
Approve final enforcement decision: step-up within last 2 minutes
Impersonate user: step-up within last 2 minutes + admin permission

function isFreshEnough(input: {
  lastStepUpAt?: string;
  now: string;
  maxAgeSeconds: number;
}): boolean {
  if (!input.lastStepUpAt) return false;

  const last = Date.parse(input.lastStepUpAt);
  const now = Date.parse(input.now);

  if (!Number.isFinite(last) || !Number.isFinite(now)) return false;

  return now - last <= input.maxAgeSeconds * 1000;
}

acr: Authentication Context Class Reference.
amr: Authentication Methods References.
auth_time: time user authentication occurred.
max_age: request parameter requiring recent authentication.
prompt=login: force re-authentication prompt.

export type NormalizedAuthAssurance = {
  authenticatedAt: string;
  methods: string[];
  assuranceLevel: string;
  stepUpCompletedAt?: string;
  source: 'local' | 'oidc' | 'saml' | 'webauthn' | 'password';
};

Can the user do this action now?
If not, what challenge should be shown?

MFA enrollment: user adds or configures a factor.
MFA challenge: user proves control of a factor.

- backup codes;
- verified recovery email;
- admin reset;
- helpdesk flow;
- hardware key fallback;
- identity proofing;
- temporary bypass with expiry;
- tenant admin approval.

Can't access your code? Click here to disable MFA.

Can't access your authenticator?
Use a backup code, security key, or contact your organization admin.

1. Recovery must be logged.
2. Recovery must not silently downgrade future auth.
3. Temporary bypass must expire.
4. Admin reset should require admin step-up.
5. Users should be notified about factor changes.
6. Factor replacement should require recent strong authentication when possible.

navigator.credentials.create()
navigator.credentials.get()

- challenge generation;
- relying party ID;
- origin validation;
- credential public key storage;
- signature verification;
- counter/signature data checks where applicable;
- user handle mapping;
- policy decision.

async function startWebAuthnStepUp(challengeId: string) {
  const optionsResponse = await fetch(`/api/auth/webauthn/step-up/options`, {
    method: 'POST',
    credentials: 'include',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ challengeId }),
  });

  const options = await optionsResponse.json();

  const credential = await navigator.credentials.get({
    publicKey: options.publicKey,
  });

  await fetch(`/api/auth/webauthn/step-up/verify`, {
    method: 'POST',
    credentials: 'include',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ challengeId, credential }),
  });
}

- new device;
- unusual location;
- impossible travel;
- high-value action;
- suspicious IP/reputation;
- recent password reset;
- admin role;
- dormant account suddenly active;
- tenant policy requiring stronger auth;
- resource sensitivity.

{
  "decision": "step_up_required",
  "reason": "high_value_action_and_stale_authentication",
  "requiredAssurance": "tenant_high",
  "allowedMethods": ["webauthn", "idp_mfa"],
  "maxAgeSeconds": 300
}

Additional verification is required because this action changes tenant security settings.

/settings/security
/admin/impersonation
/cases/:id/evidence-export
/billing/payment-methods

export async function securitySettingsLoader() {
  const response = await fetch('/api/security-settings/bootstrap', {
    credentials: 'include',
  });

  if (response.status === 403) {
    const body = await response.json();

    if (body.code === 'step_up_required') {
      throw redirect(`/auth/step-up?challenge=${body.challenge.id}`);
    }
  }

  if (!response.ok) {
    throw response;
  }

  return response.json();
}

User opens final approval form.
User spends 45 minutes writing decision rationale.
User clicks submit.
Server requires step-up.
Challenge succeeds.
Original form state is lost.

- keep local draft state;
- use idempotency key;
- submit to server only after authorization;
- preserve form data across challenge;
- revalidate resource state after challenge;
- detect if resource changed while challenge was pending;
- show diff/refresh prompt if needed.

type SensitiveFormDraft = {
  resourceId: string;
  resourceVersion: number;
  formData: Record<string, unknown>;
  idempotencyKey: string;
};

Step-up freshness does not solve stale business state.

Step-up updates session auth context.
All tabs can benefit until freshness window expires.

Step-up completes only a specific challenge/action.
Other tabs do not inherit broad elevation.

const channel = new BroadcastChannel('auth-events');

function publishStepUpCompleted(challengeId: string) {
  channel.postMessage({
    type: 'step_up_completed',
    challengeId,
    at: new Date().toISOString(),
  });
}

export type SessionProjection = {
  user: { id: string; displayName: string };
  tenant: { id: string; slug: string };
  authContext: {
    authenticatedAt: string;
    assuranceLevel: string;
    methods: string[];
    lastStepUpAt?: string;
    elevatedUntil?: string;
  };
  permissions: Record<string, boolean>;
};

- sensitive buttons become enabled;
- security settings form becomes visible;
- export action becomes available;
- challenge banner disappears;
- countdown appears;
- cached permission decisions need invalidation.

localStorage.setItem('mfaPassed', 'true');

User completed MFA once this year -> all sensitive actions allowed forever.

403 step_up_required -> MFA success -> client performs local action

Attacker steals session -> removes victim's MFA factor -> owns account

Something went wrong.

export type StepUpAuditEvent = {
  type:
    | 'step_up_required'
    | 'step_up_started'
    | 'step_up_succeeded'
    | 'step_up_failed'
    | 'step_up_cancelled'
    | 'sensitive_action_authorized'
    | 'sensitive_action_denied';
  userId: string;
  tenantId: string;
  challengeId?: string;
  action?: string;
  resourceType?: string;
  resourceId?: string;
  method?: string;
  assuranceLevel?: string;
  authenticatedAt?: string;
  reason?: string;
  requestId: string;
  occurredAt: string;
};

- action attempted;
- resource identity;
- old/new resource state if relevant;
- authentication method used;
- freshness window;
- policy rule that required step-up;
- final authorization decision;
- correlation id.

Policy
- Which actions require step-up?
- What assurance level is required?
- How fresh must authentication be?
- Is elevation session-wide or intent-bound?

Backend
- Are sensitive actions enforced server-side?
- Does the server re-check authorization after step-up?
- Are challenges tenant-bound and action-bound?
- Are challenge IDs unguessable and short-lived?
- Are retries idempotent?

Frontend
- Can the user cancel step-up safely?
- Is form state preserved?
- Are typed errors handled?
- Are route-level and action-level challenges distinct?
- Are caches invalidated after step-up?

Security
- Can a stolen session add/remove MFA factors?
- Are recovery flows at least as protected as login?
- Are strong methods preferred for admin workflows?
- Are sensitive risk signals hidden?

Audit
- Is step-up recorded?
- Is final authorization recorded?
- Can support debug without seeing secrets?

user has baseline session
-> user attempts sensitive action
-> server evaluates permission + resource + auth context
-> server requires stronger/fresher auth if needed
-> React orchestrates challenge
-> auth service verifies challenge
-> session/auth context is updated or challenge token is issued
-> original action is retried with idempotency
-> server re-checks authorization
-> action succeeds or fails
-> audit records the chain

Step-up is not a bypass around authorization.
Step-up is an input into authorization.