Appian Authentication

Purpose

The Appian Authentication page in the Admin Console allows you to control password strength requirements and password expiration policies.

Access

To access the Appian Authentication page, go to the Admin Console. Then, in the left navigation menu, under Authentication, click Appian Authentication.

Settings

The Appian Authentication page contains the following settings.

Password format

The Password Format section allows you to set the following:

Setting	Description	Default
Minimum Password Length	Specifies the minimum number of characters allowed in a password.	1
Minimum Number of Alphabetic Characters	Specifies the minimum number of characters from the English alphabet (A-Z and a-z) allowed in a password.	0
Minimum Number of Lowercase Characters	Specifies the minimum number of lowercase characters from the English alphabet (a-z) allowed in a password.	0
Minimum Number of Uppercase Characters	Specifies the minimum number of uppercase characters from the English alphabet (A-Z) allowed in a password.	0
Minimum Number of Numeric Characters	Specifies the minimum number of numerals (0-9) allowed in a password.	0
Minimum Number of Special Characters	Specifies the minimum number of special characters allowed in a password. Special characters include: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~	0
Minimum Password Age	Specifies the number of days a user must wait between password changes, where one day is defined as a 24-hour period and not a calendar day. This setting does not affect temporary passwords or the ability for an administrator to reset a user's password.	0
Prevent Reuse of Previous Passwords	Specifies how many previous passwords a user cannot reuse. Valid values are between 0 and 24, inclusive. The current password cannot be reused, but other previous passwords can be.	1
Passwords cannot contain usernames	Controls whether the user's password can contain their username.	Disabled

The settings in this section apply only to passwords managed by Appian. They do not apply to accounts that authenticate with LDAP, OpenID Connect, PIEE, or SAML.

Appian Cloud environments have different default settings than self-managed environments. The following default password policies are in place for Appian Cloud users:

• Passwords must be at least 7 characters long.
• Passwords must contain at least 1 numeric character.
• Passwords must contain at least 1 letter.
• Passwords must be different from the previous 4 passwords used.

Remember me

The Remember Me section allows you to set whether the Remember me checkbox displays on the Appian sign-in page.

If this setting is toggled on, you can use the Maximum Remember Me Time setting to configure the length of time that a user will remain signed in without having to enter their username and password. The maxiumum amount of time is 90 days.

If you disable this setting, users must provide their username and password once every two weeks for each browser on which they access Appian.

This setting does not apply to system administrators. System administrators are automatically signed out when their session expires based on the Session Timeout period.

Session timeout

Session timeout values can be configured differently for basic users and system administrators in your Appian environment. For both types of user, the minimum valid value is 10 minutes, and the maximum valid value is 480 minutes (8 hours).

The session timeout values apply to all applications in your Appian environment.

Setting	Description	Default
Basic User Idle Session Timeout (Minutes)	Specifies the number of minutes that a basic user can remain inactive before the system signs them out.	65
System Administrator User Idle Session Timeout (Minutes)	Specifies the number of minutes that an administrator can remain inactive before the system signs them out.	65

How session timeout works

Five minutes before the session expires, the system displays a default warning message to the user:

You cannot customize this warning message.

After five more minutes of inactivity, the system signs the user out. The user is automatically redirected to the sign-in page or single sign-on page, depending on your configuration.

Where users land after signing back in depends on your Return Link setting. For environments created before 26.7, the default is the user start page. For environments created in 26.7 or later, the default is the last visited page. You can change this setting at any time.

Sign out redirect

The Sign Out Redirect section allows you to configure how users are redirected after signing out of their application, whether it's from manually signing out or a session timeout.

Setting	Description	Default
Return Link	Sets the page users return to after signing back in. Applies to all authentication types. The options are: User start page: Takes users to the start page configured for their user or group. Last visited page: Takes users to the page they were on before being signed out, including any URL parameters set by rule inputs.	Existing environments: Return to the user start page. Environments created in 26.7 or later: Return to the last visited page.
Return Link Text	Sets the text displayed for the return link after signing out. Applies to single sign-on (SSO) authentication types only.	Return to Appian

Return to last visited page

Appian recommends setting the Return Link to Last visited page whenever possible so users can resume their workflow after signing back in. This option applies to all authentication types and to browsers only—it does not apply to Appian Mobile or Appian for Windows apps.

Users redirect to their last visited page only when signing out or timing out from one of the following locations:

• A page in a site.
• A record view or a process model start form accessed from a site.
• A Process HQ report or dashboard accessed from a site.

When you select Last visited page, keep the following in mind:

• URL tracking: The browser tracks the visible URL and updates it with every page change. The URL stores query parameters set by rule inputs, but does not store values set by local variables.
• Unsaved data: Unsaved form data is not restored. Any in-progress work within a form or interface is lost upon sign-out or timeout.
• User isolation: Stored URLs are tied to specific user sessions. A different user signing in from the same browser will not inherit the previous user's last visited page.

Return link text

The Return Link Text setting controls the text displayed on the return link page that users see after signing out. This setting applies to single sign-on (SSO) authentication types only. Users who authenticate with Appian Authentication or LDAP go straight to the sign-in screen on sign-out and do not see the return link page.

The Return Link Text options are:

• Default: Displays Return to Appian in the environment's primary locale.
• Custom: Displays the text you enter as-is. Custom text is not localized, so ensure the text is appropriate for the environment's primary locale.

Password expiration

The settings in the Password Expiration section apply only to passwords managed by Appian. They do not apply to accounts that authenticate with LDAP, OpenID Connect, PIEE, or SAML.

The Password Expiration section allows you to configure the following:

Setting	Description	Default
Expire Passwords	Controls whether passwords should no longer be valid after a certain amount of time. When a password expires, the user must change the password before they are allowed to proceed past the Appian sign-in page.	Disabled
Maximum Password Age	Specifies the number of days after which a password expires and must be reset.	--
Warn Users Before Password Expiration	Controls whether users see a warning if they sign in when their password is about to expire. The value must be lower than the number you set for Maximum Password Age.	Disabled
Password Expiration Warning Period	Specifies the number of days before a user's password expires where they will be warned about their impending password expiration.	--
Expire Temporary Passwords	Controls whether auto-generated passwords should expire. Auto-generated passwords include the temporary password generated when a new user account is created or when an administrator resets a user's password.	Enabled
Maximum Temporary Password Age	Specifies the number of minutes after which a temporary password expires. When a temporary password expires, the user cannot sign in and must request that an administrator reset the password.	10,080 (one week)

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

• Passwords expire every 90 days.
• Users are notified regarding password expiration 7 days before it happens.

Initial passwords for Appian Cloud are temporary passwords. The system prompts users to reset their password immediately after signing in to Appian Cloud.

Forgot password

The Forgot Password section allows you to set the following:

Setting	Description
Enable Forgot Password from Sign-In Page	Controls whether the Forgot your password? link appears on the sign-in page, allowing users to reset their passwords.
Password Reset Link Duration (Minutes)	Specifies the number of minutes a password reset link remains valid. If a user clicks an expired link, they must request a new one. Changes to this value apply retroactively to existing links.

When this feature is enabled, only users that meet the following requirements will be able to reset their passwords:

• The user does not authenticate through LDAP, OpenID Connect, PIEE, or SAML.
• The user is not deactivated.
• The user's password is older than the minimum password age.
• The user has a valid e-mail address.

If SAML or LDAP is enabled for all users, the Enable Forgot Password from Sign-In Page checkbox is disabled because Appian does not manage those users' credentials. If only some users authenticate through LDAP or SAML, you can enable the feature and the Forgot your password? link appears on the sign-in page for all users.

Use import customization files to change the value between environments with different authentication configurations.

Use of this feature can be audited through the Forgot Password Requests and Password Resets audit logs.

Email templates

The Email Templates section of the Forgot Password section allows you to customize the email messages that users receive when they request a password reset.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Appian sends two types of password reset emails:

• Password Reset Email: Sent to users who successfully request a password reset. The email contains the reset link.
• Password Reset Rejection Email: Sent to users when their password reset request cannot be fulfilled.

Each email template has a customizable Subject and Body. The body editor supports rich text formatting, including bold, italic, underline, strikethrough, text color, highlight color, subscript, superscript, links, alignment, lists, and tables.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Templates are organized by locale. If you have enabled additional locales on the Internationalization page, a tab appears for each enabled locale so you can provide localized versions of the email templates.

Available variables

Use variables in the subject and body fields to insert dynamic content into the email. Appian replaces the variable with the corresponding value when the email is sent.

The following variables are available for the Password Reset Email template:

Variable	Description
{FIRST_NAME}	The first name of the user requesting the password reset.
{LAST_NAME}	The last name of the user requesting the password reset.
{RESET_LINK}	The link the user must follow to reset their password.
{LINK_DURATION}	The number of minutes the reset link remains valid, as configured in the Password Reset Link Duration setting.
{SITE_NAME}	The name of the site as shown in the Environment Name field.

The following variables are available for the Password Reset Rejection Email template:

Variable	Description
{FIRST_NAME}	The first name of the user who requested the password reset.
{LAST_NAME}	The last name of the user who requested the password reset.
{REJECTION_REASON}	The reason the password reset request could not be fulfilled.
{SITE_NAME}	The name of the site as shown in the Environment Name field.

Customize email templates

To customize the email templates:

1. In the Email Templates section, click CUSTOMIZE TEMPLATES.
2. Select the tab for the template you want to edit: Password Reset Email or Password Reset Rejection Email.
3. Edit the Subject and Body fields as needed. Use the available variables to insert dynamic content.
4. Click DONE.

Reset email templates to defaults

To reset both email templates to their default content:

1. In the Email Templates section, click CUSTOMIZE TEMPLATES.
2. Click RESET TEMPLATES.
3. On the confirmation dialog, click YES to restore the default templates.

Account locking

User accounts that have difficulty supplying the proper credentials are temporarily locked (prevented from making a sign-in attempt) when the user (or someone attempting to sign in as the user) tries too many incorrect passwords. The system does this by keeping track of the number of failed sign-in attempts for each account. The failed sign-in count is reset automatically after some time has passed from the last failed attempt. This prevents the user from accumulating a large number of failed sign-in attempts over a long period of time.

The Account Locking section allows you to set the following:

Setting	Description	Default	Compatible Authentication Types
Lock Accounts After Failed Logins	Controls whether accounts are locked after repeated failed sign-in attempts.	Enabled	Appian authentication
Maximum Password Attempts	Specifies the number of failed sign-in attempts it takes for an account to be locked.	6	Appian authentication
Password Attempt Reset Duration	Specifies the number of minutes after a failed sign-in attempt before the failed attempt counter resets. Set this value high enough to capture repeated failed attempts from someone guessing passwords.	30	Appian authentication
Unlock Accounts Automatically	Controls whether an account locked due to failed sign-in attempts is automatically unlocked after a certain time period. If automatic unlocking is disabled, accounts remain locked until an administrator manually unlocks them.	Enabled	Appian authentication
Lock Duration	Specifies the number of minutes an account is locked after being locked due to failed sign-in attempts.	30	Appian authentication
Limit Number of Concurrent Sessions Per User Account	Controls whether users are only allowed a certain number of sessions active at the same time.	Disabled	Appian authentication, LDAP, SAML, OpenID Connect, and PIEE
Maximum Concurrent Sessions	Specifies the number of sessions a user can have open at the same time before they are no longer allowed to sign in again.	--	Appian authentication, LDAP, SAML, OpenID Connect, and PIEE
Deactivate Users Who Have Not Logged In Recently	Controls whether users who have not signed in recently are deactivated.	Disabled	Appian authentication, LDAP, SAML, OpenID Connect, and PIEE
Idle User Deactivation Duration	Specifies the number of days after a user's last successful sign-in before the user account is deactivated.	--	Appian authentication, LDAP, SAML, OpenID Connect, and PIEE

The failed sign-in count is reset if the account is unlocked by an administrator.

When you specify a deactivation interval, that same interval must elapse before user accounts begin to be deactivated. For example, if you specify an inactivity deactivation interval of 90 (90 days) on April 1st, a user account that does not successfully sign in between April 1st and June 30th is deactivated. In this scenario, a user account that has not signed in since January 1st also remains active until June 30th, as you did not activate the policy until 90 days after the user account became inactive.

User accounts that are deactivated due to inactivity are listed at the INFO level in db_PE_yyyy-mm-dd_hhmm.log in the <APPIAN_HOME>/logs/ directory.

The system user Administrator is never automatically deactivated.

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

• Users who have not signed in are considered inactive after a period of 90 days.

Activity from the Appian Mobile applications does not count towards the number of active sessions a user has and the number of requests from the mobile applications.

See also:

• User Deactivation Logging
• Reactivating Users
• Unlocking Users

Multi-factor authentication

Appian requires multi-factor authentication (MFA) for users that sign in with Appian authentication. This adds an extra layer of security to the sign-in process since users must provide their Appian username and password, and a custom verification code.

The Outbound Email Toggle is enabled by default so Appian can send verification codes to users. Also note that when MFA is enabled, users cannot reset their own password unless they have configured an authenticator app. Otherwise, they will need to request that a system administrator do it for them.

The Multi-Factor Authentication section displays different configuration options depending on whether default MFA enforcement is enabled for your environment.

When default MFA enforcement is enabled, you can configure the following settings:

Setting	Description
Email Verification	Users receive an email with a verification code that must be entered to complete the sign-in process. This setting cannot be disabled when MFA is enabled because email is required as the fallback method for users who have not yet configured an authenticator app.
Authenticator App	If enabled, users enter a verification code from an app to complete the sign-in process.
Allow users to skip authenticator app setup	This setting is only visible when Authenticator App is enabled. When enabled, users can defer authenticator app enrollment during their first sign-in and complete setup later through their user settings. See Skip authenticator app setup for details.
Enable Device Trust	Controls whether users can remember a web browser and skip the multi-factor authentication challenge on subsequent sign-ins from that browser. Users must still enter their Appian username and password. Device trust is disabled by default. See Device trust for details.
Trust Duration	Specifies how long a web browser can remain trusted. Enter a value from 1 to 90 days. The default value is 30 days.

When default MFA enforcement is not enabled, you can configure the following settings:

Setting	Description
Enable Multi-Factor Authentication	Select this checkbox to require a group of users to sign in using MFA. By default, this checkbox is deselected.
Authentication Group	Select the group that is required to sign in using MFA. These users must be configured to use Appian authentication. MFA does not apply to users configured to use SAML, OpenID Connect, PIEE, or LDAP.
Email Verification	Users receive an email with a verification code that must be entered to complete the sign-in process. This setting cannot be disabled when MFA is enabled because email is required as the fallback method for users who have not yet configured an authenticator app.
Authenticator App	If enabled, users enter a verification code from an app to complete the sign-in process.
Allow users to skip authenticator app setup	This setting is only visible when Authenticator App is enabled. When enabled, users can defer authenticator app enrollment during their first sign-in and complete setup later through their user settings. See Skip authenticator app setup for details.
Enable Device Trust	Controls whether users can remember a web browser and skip the multi-factor authentication challenge on subsequent sign-ins from that browser. Users must still enter their Appian username and password. Device trust is disabled by default. See Device trust for details.
Trust Duration	Specifies how long a web browser can remain trusted. Enter a value from 1 to 90 days. The default value is 30 days.

When both email verification and authenticator app verification are enabled, users can select their preferred verification method when they sign in.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to close

Email verification

If MFA is enabled, users are required to enter their Appian username and password. Then, the user will receive an email with a verification code that must be entered to complete the sign-in process. This code is valid for 5 minutes, after which a new code must be requested.

If the user requests a new verification code, the existing verification code will be invalidated.

Users only have three chances to enter a verification code before the code is invalidated. Each incorrect entry of the code counts towards Account Locking.

Users are also limited to three verification code requests per fifteen-minute window to maintain sign-in performance and security.

Authenticator apps

Users are required to configure an authenticator app during their first sign-in after this feature is enabled. After initial setup, users can modify their authenticator app configuration in their user settings, which generates a new secret key and invalidates the previous setup.

Users can configure any authenticator app that generates verification codes using the time-based one-time password (TOTP) protocol. This includes popular apps like Authy, Google Authenticator, and Microsoft Authenticator.

Use import customization files to change the value between environments with different authentication configurations.

Skip authenticator app setup

By default, basic users must complete authenticator app enrollment before they can access the application.

When multi-factor authentication (MFA) is enabled and Authenticator App is selected, you can enable the Allow users to skip authenticator app setup setting.

When the Allow users to skip authenticator app setup setting is enabled, basic users who have not yet configured an authenticator app are presented with the following options during their first sign-in:

• SET UP APP: Routes the user to the standard authenticator app enrollment workflow.
• SKIP: Bypasses the enrollment step and routes the user directly into the application. The user can complete authenticator app setup later through their user settings.

System administrator accounts cannot skip authenticator app setup and must complete enrollment immediately.

Reset authenticator app

If your site has the Authenticator App enabled and the user has MFA enabled, system administrators can reset a user's authenticator app configuration from the Users page. Use this option only when the user has previously enrolled an authenticator app and now needs to reset it, such as if the device is lost or replaced. This action will invalidate the current authenticator configuration and require the user to re-register at their next sign-in.

This control is only enabled when the selected user has MFA enabled and has an existing authenticator app configuration.

To reset a user's authenticator app:

1. On the Users page, select the checkbox of the user you want to reset.
2. Click RESET AUTHENTICATOR APP.
3. On the confirmation dialog, click YES.

The user's authenticator app configuration is removed. This action is recorded in the admin audit log.

Device trust

Device trust lets users who sign in with Appian authentication skip the multi-factor authentication (MFA) challenge a web browser they choose to remember. Users must still enter their Appian username and password on every sign-in.

If device trust is enabled, users can select Remember this device during MFA verification. Users who do not select Remember this device continue to complete an MFA challenge on subsequent sign-ins.

An administrator can configure a trust period from one to 90 days. The default trust period is 30 days.

When the trust period expires, the user must complete a full authentication flow, providing their password and one-time MFA code.

Device trust can be used by basic users in the following situations:

• Authentication type: Device trust applies only to users who sign in with Appian authentication. Device trust does not apply to SAML, OpenID Connect, PIEE, or LDAP authentication.
• Client: Device trust applies to web browsers. Appian Mobile apps do not support device trust in Appian 26.8.

System administrator accounts cannot use device trust and must complete MFA on every sign-in.

Users can revoke a device in their user settings, and the device trust will be lost if the user clears their Appian cookies. System administrators can also revoke a trusted device from a user .

Device trust is independent from Remember Me authentication. Device trust skips only the MFA challenge, while Remember Me authentication bypasses the Appian sign-in screen. See Device trust and Remember Me for a detailed comparison.

Revoke device trust for a user

System administrators can revoke device trust for a user when a remembered browser is lost or compromised.

To revoke device trust for a user:

1. On the Users page, select the checkbox of the user you want to reset.
2. Click REVOKE DEVICE.
3. On the confirmation dialog, click YES.

The user will be required to provide both their password and one-time MFA passcode in order to sign in to Appian.

Device trust is revoked if any of the following occur:

• The user clears Appian cookies from their browser.
• A user account is deactivated and then reactivated.
• The user changes their password.
• A user's account type is changed by an administrator.
• The user exceeds the number of trusted devices (defaults to 10). In that case, trust is revoked for the browser with the oldest sign-in and the new browser is added.

Terms of service

The Terms of Service Agreement section allows you to set a message on the sign-in page that users must click to accept before entering the system.

Setting	Description
Require Users to Accept Terms of Service Before Logging In	Controls whether users must accept terms of service before accessing the site.
Terms of Service	Specifies the message that appears on the sign-in page.

When you change the terms of service, all remember me authentication sessions will be invalidated and users will need to input their username and password the next time they sign-in to Appian.

Feedback