Step-up authentication
Sign-in proves "you're at the keyboard right now". For most actions that's enough. For a handful of high-impact actions — transmit payroll, cosign equity, finalize account erasure, send the year-end tax filing — AxisSynapse asks for a fresh MFA proof at the moment of the action. This is step-up authentication: a single-use token that says "yes, I am still here, and I am authorizing this specific thing." The pattern protects you from session hijacking, accidental clicks, and insider mistakes alike.
TL;DR — Sixteen platform actions trigger a step-up prompt automatically; the modal asks for your current MFA factor and issues a single-use, IP-bound, time-limited token. The admin's only knob is Settings → Security → Step-up policy — whether phishing-resistant factors are required for each purpose.
What counts as a "high-impact action"
The platform enumerates the purposes that require step-up. The list isn't customer-configurable on the action side (every workspace gets the same set so the audit trail is consistent), but the factor requirement for each purpose is configurable.
| Field | What it does | Accepted values / default |
|---|---|---|
| Payroll ACH transmit | Sending a NACHA file to the bank for direct-deposit payroll. | Requires phishing-resistant by default. |
| Equity grant cosign | The second-signer on an equity grant. | Requires phishing-resistant by default. |
| Year-end tax transmit | Finalizing W-2 / 1099 / T4 / 1095-C output for transmission. | Requires phishing-resistant by default. |
| Account erasure finalize | Final 'complete the erasure' button after cooling-off + 4-eyes. | Requires phishing-resistant by default. |
| Webhook secret rotation | Changing the HMAC secret on a webhook subscription. | Any acceptable MFA factor. |
| SCIM token revocation | Revoking the active SCIM bearer token. | Any acceptable MFA factor. |
| SAML provider deletion | Removing an enabled SAML provider. | Requires phishing-resistant by default. |
| Custom domain change | Re-pointing the workspace's custom domain. | Any acceptable MFA factor. |
| MFA policy disable | Turning Require MFA off. | Requires phishing-resistant by default. |
| Network policy disable | Disabling an active network allowlist. | Requires phishing-resistant by default. |
| Data-export download | Downloading a prepared data-export bundle. | Any acceptable MFA factor. |
| Audit-log export | Generating a CSV / NDJSON of the audit log. | Any acceptable MFA factor. |
| Personal-access-token elevation | Increasing a PAT's scope past read-only. | Any acceptable MFA factor. |
| Holds override | Override of a regulatory retention hold during account erasure. | Requires phishing-resistant + 10-year audit retention. |
| Attestation policy tighten | Switching the attestation mode to a stricter level. | Any acceptable MFA factor. |
| Branding domain CNAME | Issuing a TLS cert for a custom subdomain. | Any acceptable MFA factor. |
How the prompt feels
You click the high-impact button
Example: Transmit payroll in
/hcm/payroll. The button doesn't immediately commit; instead a step-up modal slides in.The modal names the purpose
The modal title says exactly what you're authorizing — Authorize payroll ACH transmit — and the body explains the consequence (in this case: real money moves).
You complete the MFA challenge
Tap your passkey, insert your hardware key, or type your TOTP code (whichever the per-purpose policy allows). If the purpose requires phishing-resistant, only passkey and hardware-key options appear.
The action proceeds
The platform redeems the single-use token, executes the action, and records both the step-up proof and the action itself in the audit log.
Why single-use + IP-bound
The token is bound to the IP that requested it and is consumed the moment it's used. That makes a stolen token useless: an attacker on a different network can't redeem it, and even on the same network they only get one shot per stolen session.
Admin: configuring the step-up policy
The default policy is "phishing-resistant for everything that moves money or data; any factor otherwise". You can tighten the policy per purpose but not loosen below the platform default — money-moving actions are always phishing-resistant.
Open Settings → Security → Step-up policy
The page lists every purpose with its current factor requirement and the platform minimum.
Pick the factor requirement per purpose
For each purpose, choose Any acceptable factor or Phishing-resistant only. Purposes whose minimum is phishing-resistant cannot be loosened (the dropdown disables the weaker option).
Click "Save"
The new policy takes effect immediately on the next step-up prompt. In-flight prompts complete on the old policy.
Every field, explained
| Field | What it does | Accepted values / default |
|---|---|---|
| Purpose | One of the 16 platform-defined high-impact actions. | Read-only — the set is platform-managed for audit consistency. |
| Factor requirement | Whether any acceptable factor or only phishing-resistant satisfies the prompt. | Tighten freely; loosen only down to the platform minimum. |
| Token TTL | How long the issued token is valid before expiring. | Per-purpose default; not customer-configurable. Reflects the action's risk profile. |
| IP binding | The token is bound to the source IP at issuance. | Always on. A token presented from a different IP is rejected. |
| Replay protection | Detects and blocks attempts to redeem the same token twice. | Always on. A replay attempt fires ACCOUNT_STEPUP_REUSED — critical severity. |
What appears in the audit log
ACCOUNT_STEPUP_CHALLENGE_REQUESTED— a prompt was issued.ACCOUNT_STEPUP_VERIFIED— the user passed.ACCOUNT_STEPUP_FAILED— the user failed. A cluster of failures on the same action is a credential-confusion or social-engineering signal.ACCOUNT_STEPUP_REUSED— critical. A single-use token was presented twice. The Security Console raises a real-time alert.ACCOUNT_STEPUP_BLOCKED— the prompt was refused before it reached the user (e.g. policy mismatch).
Common gotchas
- "I just signed in — why am I being asked again?" Step-up is intentional. Sign-in proves you were here when the session started; step-up proves you're still here at the moment of a high-impact action.
- "The prompt opened but my passkey didn't appear." The purpose requires phishing-resistant and your only enrolled factor is TOTP. Either enroll a passkey or hardware key, or ask an admin if the purpose can be loosened (it can't be loosened past the platform minimum).
- "A step-up failed and now my session is locked." Failed step-ups don't lock the session — only the action is aborted. Re-attempt the action and retry the prompt. If repeated failures persist, the workspace's sign-in lockout may eventually kick in.
- "My second-signer didn't get a step-up prompt." Each signer is evaluated independently. The cosigner gets their own step-up at the moment they click cosign — not when you do.
Troubleshooting
| Error code | What it means | Fix |
|---|---|---|
| STEPUP_REQUIRED | The action needs a step-up proof; none provided. | Click the action button; the modal will appear. |
| STEPUP_FACTOR_INSUFFICIENT | A weaker factor was used than the purpose requires. | Enroll and use a phishing-resistant factor. |
| STEPUP_TOKEN_EXPIRED | The token elapsed before redemption. | Re-issue by clicking the action again. |
| STEPUP_TOKEN_REUSED | A single-use token was presented twice. | Investigate immediately — possible session replay. |
| STEPUP_IP_MISMATCH | The redeeming IP doesn't match the issuance IP. | Re-issue from the same network. |
Related