> ## Documentation Index
> Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Step-Up Authentication

> Why sensitive business account operations require an elevated access token, and the ways a user can obtain one.

<Note>
  Business Accounts are in **early access**. See [Business Accounts](/docs/business-accounts/accounts) for the model.
</Note>

Most business account modifications require an **elevated access token**: a short-lived JWT bound to a specific action. The regular session token proves who the user is, but not that they just re-verified their identity, so a call made without the elevated token is rejected with a `403`.

This page covers how step-up applies to business accounts. For the general model, including verification methods, token lifetimes, and single-use scopes, see [Step-Up Authentication](/docs/auth/step-up-auth).

## Which operations require step-up

| Operation | Required scope |
| - | - |
| Add a signer | `business_account:signer:add` |
| Remove a signer | `business_account:signer:remove` |
| Add a member | `business_account:member:add` |
| Remove a member | `business_account:member:remove` |
| Update a member's role | `business_account:member:role:update` |
| Transfer ownership | `business_account:transfer_ownership` |
| Link a wallet | `business_account:link_wallet` |
| Remove a wallet | `business_account:wallet:remove` |

Reads and account or wallet creation do not require step-up: `createBusinessAccount`, `getBusinessAccount`, `listBusinessAccounts`, and `createWalletForBusinessAccount` all work with the regular session token.

Step-up is independent of [governance](/docs/business-accounts/governance). Governance decides whether a change needs approvals from other members before it applies. Step-up decides whether the person initiating the change has recently re-verified their own identity. An operation can require either, both, or neither.

## How a user obtains an elevated token

A member obtains an elevated token by re-verifying their identity. There are three paths, and which one applies depends on how the user authenticates.

**Verify with requested scopes.** The member verifies with a passkey, TOTP, email or SMS OTP, social OAuth, or an external wallet signature, and the verification request names the scope the operation needs. The response carries an elevated token bound to that scope, and the SDK stores it and attaches it to the next call automatically. When the member has MFA methods registered, verification routes through MFA rather than re-authentication.

**External auth assertion.** If your backend issues its own JWTs, registered through the environment's JWKS URL, it can mint a short-lived JWT carrying the scope claim and hand it to the SDK in exchange for an elevated token. No user interaction is needed, which suits server-driven flows.

**Challenge flow.** Before a governed call, an SDK check reports whether step-up is required and which credentials the member can verify with. An app can use that response to drive its own verification UI, then complete verification with the requested scope.

An elevated token is short-lived and scoped to the action it was issued for. A token minted to add a signer does not authorize removing a member, and an expired token fails with the same `403` as a missing one, so the member verifies again.

## Next steps

<CardGroup cols={2}>
  <Card title="Step-up auth" icon="code" href="/docs/javascript/reference/business-accounts/step-up-auth">
    Check for a required step-up and obtain an elevated token with the JavaScript SDK.
  </Card>

  <Card title="Step-Up Authentication" icon="shield-check" href="/docs/auth/step-up-auth">
    The general step-up model: verification methods, scopes, and token lifecycle.
  </Card>
</CardGroup>