Security Policy

The Security Policy settings define the rules that govern how users sign in to your contact center and how their credentials must be formed and maintained. Use this page to lock out accounts after repeated failed sign-in attempts, enforce password strength and history requirements, expire passwords and inactive accounts, and require multi-factor authentication (MFA).

Screen Properties

The following properties apply to all users of your contact center. Some options may be enforced by your service provider; when they are, they appear preset and cannot be changed.

Account Lockout

This section controls whether and how user accounts are temporarily locked after too many failed sign-in attempts, which helps protect against password-guessing attacks.

Enable lockouts

When enabled, a user account is locked after the configured number of failed sign-in attempts. When disabled, accounts are never locked out and the settings below have no effect. To comply with the PCI DSS security standard, this option must be enabled.

Maximum login attempts

The number of consecutive failed sign-in attempts allowed before the account is locked. To comply with the PCI DSS security standard, set this value to six or greater.

Reset attempt count after

The amount of time, measured from the last failed attempt, after which the failed-attempt counter returns to zero. If the user does not reach the maximum within this period, their count starts over.

Lockout duration

The length of time an account remains locked before the user can attempt to sign in again. Set this to 0 to disable automatic unlocking, in which case locked-out accounts can only be unlocked manually by an administrator. To comply with the PCI DSS security standard, set this to at least 30 minutes.

Password Complexity

This section defines the minimum strength requirements that a user's password must meet.


	Any change to the password complexity rules applies immediately to all new attempts to set or change a password by any method (self-service, administrator, import, API, or auto-generation). Existing users are not affected until they next change their password. When passwords are set or changed by import or API, an attempt to use a non-compliant password fails with an error that identifies the specific users whose passwords do not comply.

Minimum password length

The minimum number of characters a password must contain. The smallest value you can set is determined by your service provider (for example, 8 characters).

Require digits and letters

When enabled, passwords must contain both digits and letters. This requirement may be enforced by your service provider.

Require upper and lower case letters

When enabled, passwords must contain both uppercase and lowercase letters.

Require special characters

When enabled, passwords must contain at least one special character, such as a punctuation mark or symbol.

Check against login and tenant name

When enabled, a password may not contain the user's login ID or the tenant name. This requirement may be enforced by your service provider.

Check against weak passwords list

When enabled, passwords are checked against a list of commonly used, easily guessed passwords, and any match is rejected. Click See current list to review the weak passwords used for this check.

Password History

This section controls whether users can reuse recent passwords.

Check against previously used passwords

When enabled, users cannot set a new password that matches one of their recently used passwords. To comply with the PCI DSS security standard, enable this option.

Number of previously used passwords to keep

The number of a user's most recent passwords that are remembered and may not be reused. To comply with the PCI DSS security standard, set this to four or greater.

Expiration policy

This section controls how often passwords must be changed and when unused accounts are disabled.

Require users to change passwords every

The maximum age of a password, in days. When a password reaches this age, the user must set a new one at their next sign-in. Leave this field empty if passwords should never expire. To comply with the PCI DSS security standard, set this to no more than 90 days.

Disable inactive accounts after

The number of days of inactivity after which a user account is automatically disabled. Leave this field empty if accounts should never be disabled for inactivity. To comply with the PCI DSS security standard, set this to no more than 90 days.

Exceptions

A list of user accounts that are excluded from the Disable inactive accounts after rule. Accounts listed here are never disabled for inactivity. Select users to add them to the list. Note that API users are no longer disabled for inactivity, because API usage now counts as account activity.

Multifactor authentication configuration

Multi-factor authentication (MFA) requires users to confirm their identity with a second factor in addition to their password. This section controls who must use MFA and which second factors are available. For an explanation of when and how users are prompted, see How are Multi-Factor Authentication Challenges Issued?.

Choose who is required to use MFA:

Disabled: MFA is not required for any user.
Enabled for all: every user must complete MFA when signing in.
Enabled for specific roles: only users assigned one of the selected roles must complete MFA. Select the applicable roles in the field that appears.

The options below determine which second factors users can use.

Enable trusting a browser as a second factor in MFA

When enabled, a user who completes MFA in a browser can mark it as trusted, so they are not prompted for a second factor on that browser again until the trust expires.

Limit the duration of trusting a browser to: the number of days a browser remains trusted before the user must complete MFA again.

Allow using email as a second factor in MFA

When enabled, users can receive a one-time password (OTP) code by email to use as their second factor. This requires a system email to be configured for your contact center.

OTP email subject: the subject line of the email that delivers the OTP code.
OTP email template: the body of the OTP email. Placeholders such as $(TENANT_NAME) and $(OTP) are replaced with the tenant name and the generated code when the email is sent.

Allow using TOTP codes as a second factor in MFA

When enabled, users can generate time-based one-time passwords (TOTP) with an RFC 6238-compliant authenticator application and use them as their second factor.

Grace period for initial TOTP secret setup: how long a user has to set up their TOTP authenticator before it becomes mandatory. This grace period is ignored if email OTP is available to the user. If the user does not set up TOTP within this period, an administrator must reset their TOTP configuration.
Grace period for TOTP secret setup after administrative reset: how long a user has to reconfigure their TOTP authenticator after an administrator has reset their existing TOTP secret. If they do not set it up within this period, the administrator must reset it again.< Previous | Next >