Assurance levels define the authentication methods required to access applications or authentication clients (relying party or RADIUS client) during authentication. RSA SecurID Access provides three assurance levels: High, Medium, and Low. Each level indicates the relative strength and security of the authentication methods within that level.
You can configure authentication options for each assurance level. An option can be a standalone authentication method such as Device Biometrics, or it can combine two methods connected by AND operators, such as RSA SecurID Token and Approve (push notifications). RSA SecurID Access provides default options for each assurance level, but you can add or remove options using the Cloud Administration Console.
The access policy for an application or authentication client specifies an assurance level if the application requires additional authentication. To access the application or authentication client, users must successfully authenticate using one option from that assurance level or a higher assurance level. For example, if Concur is protected by a policy named Inside Network and the policy specifies the Medium assurance level, then users accessing Concur must authenticate using an authentication method defined for the Medium or High level.
The first option listed for an assurance level on the Assurance Levels page is presented as the default for each new user when he or she authenticates to an application or client assigned to that assurance level for the first time. A user can select another option at any time, as long as the assigned assurance level or a higher assurance level contains additional options that the user can complete. When a user successfully authenticates with an option, that option becomes the user's default for future authentications for that assurance level.
If users cannot use the default option in an assurance level and are authenticating to an assurance level for the first time, RSA SecurID Access presents the next possible option in the list for the users to complete. For example, if the default option is Authenticate Tokencode and the users have not registered devices with the Authenticate app, then RSA SecurID Access skips the default option and displays the next non-Authenticate option in the list, such as RSA SecurID Token.
If users cannot complete any options, then the users see "Contact your administrator," "Authentication failed," or a message to install and register the Authenticate app. To avoid this situation, ensure that users can authenticate with at least one option from each assurance level that they will use. For example, if only a subset of users have Authenticate devices, include non-Authenticate authentication options (for example, RSA SecurID Token) in higher assurance levels.
After the authentication method is locked, the authentication method times out, or users have three unsuccessful authentication attempts in a RADIUS deployment, users are automatically prompted to select a different method, retry, or cancel. For more information about lockout, see Authentication Method Lockout.
Similar to other RSA SecurID Access authentication methods, Emergency Tokencode must be defined in your assurance levels and access policies before it can be used online or offline. For configuration and usage details, see Supported Authentication Methods - Emergency Tokencode.
Note:RSA recommends that you avoid adding Emergency Tokencode to the High assurance level. Doing so will make Emergency Tokencode available to your most sensitive applications.
In SSO Agent deployments, after users authenticate to a specific assurance level, users can access any application that allows access through access rules and uses the same assurance level or lower without providing additional forms of authentication, as long as the session is active. For example, if users successfully authenticate using an option defined for the Medium level, then the users in the same sessions can access other applications that require options for the Medium or Low levels.
If users successfully authenticate with an option from a higher assurance level than is required by the access policy, the users can still only access applications that use the same required assurance level or lower without completing additional authentication. For example, if an application requires the Low level and users successfully authenticate using an option defined for the Medium level, then the users in the same sessions can seamlessly access other applications that require options for the Low level but not the Medium level.
In relying party and RADIUS deployments, users must authenticate when accessing each relying party or RADIUS client.
Understand these guidelines and best practices for configuring assurance levels.
The first time users authenticate, they are prompted for the first option configured in the list for that assurance level. Make sure you configure options in the correct order for each level. For details on how options are presented to users for each deployment type, see Assurance Levels.
If your company includes multiple deployment types, make sure your assurance levels contain enough options to support each type. For example, a deployment might support SSO Agent, RADIUS, and relying parties. An assurance level can require FIDO authenticators for users gaining access through the SSO Agent or relying parties, but it must provide additional options for users gaining access through RADIUS. For a complete list of supported authentication methods for each deployment type, see Authentication Methods for Cloud Authentication Service Users.
You can configure an option only once. For example, if you select Device Biometrics at the Medium assurance level, you cannot configure this option for another level. If you select the combination option such as SecurID Token and Approve for the High level, you cannot configure this option for another level.
If you have enabled the setting to require users to complete additional authentication to view the RSA SecurID Authenticate Tokencode, consider not adding Device Biometrics as an authentication method in the same assurance level as the tokencode. Otherwise, Device Biometrics could be used by two authentication methods in the same assurance level.
You can delete all options from an assurance level, but an access policy cannot specify a level that has no options.
If your company does not use an option, you can remove that option from all assurance levels.
Ensure that users can authenticate with at least one option from each assurance level that they will use.