Skip to content
Help Center
Submit a request Sign in


Require two-factor authentication for agents

Account Authentication lets administrators require two-factor authentication for agent sign-in. Use it with your account’s sign-in policies so staff understand the additional verification expected of them.

Applies to: Supportbench Core. Location: Settings → Account → Authentication. Access and available controls depend on your role and account capabilities.

Before you begin

  • You need permission to edit this configuration. Ask an administrator if the page is available but its editing controls are not.
  • Review the current configuration and where it is used before making a change. Available choices depend on your account, enabled modules, division access and role.
  • Use a test record or a controlled test account for behavior checks. Do not change production routing or send customer messages just to try an example.

Configure and verify

  1. Open Settings → Account → Authentication.
  2. Review the current Require 2FA value and prepare agents for the change.
  3. Set the requirement and use the page’s authentication save action.
  4. Test a fresh sign-in with a representative test agent and confirm the expected verification experience.

Settings reference

Authentication policy

SettingWhat it controlsHow to choose
Require 2FARequires two-factor authentication under the account authentication policy.Confirm agents can complete their supported verification process before enabling the requirement.

Behavior to know

  • The Core page currently exposes Require 2FA. It is not an identity-provider or SSO connection editor.
  • Account Policies contains the separate Allow only SSO logins setting. Do not enable SSO-only until the actual SSO connection and administrator access have been tested.

Recommended use

  • Use terminology that agents and customers already understand. Explain the intended meaning in the description.
  • Keep the initial configuration small enough for people to choose consistently. Add options when they represent a real operational difference.
  • Review existing references before renaming, changing scope, or deleting. Where supported, deactivate an obsolete option before considering permanent deletion.

Worked example

  1. Arrange a controlled sign-in check with a test agent.
  2. Verify access to the supported verification channel.
  3. Enable the account requirement during an agreed change window and confirm a fresh sign-in succeeds.

Troubleshooting

ProblemWhat to check
The item is missing from a picker.Check Active, division access, parent hierarchy, enabled modules, and the user’s role. Reopen the consuming form after saving.
The form rejects a save.Read the displayed validation message. Check required values, text limits and permitted scope; do not change unrelated settings to bypass validation.
An existing record still shows an old value.A configuration change and a record change are different operations. Inspect the record and relevant references before assuming the save failed.
  • Account → Configure account policies
  • Organization → Configure agent roles and division access

For additional setup and usage context, see these related guides:

Was this article helpful?