Assurance LevelsAssurance Levels
Assurance levels define the authentication methods required to access applications or authentication clients (relying party or RADIUS client) during authentication. RSA 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 SecurID OTP and Approve (push notifications). RSA provides default options for each assurance level, but you can add or remove options using the Cloud Administration Console.
For more information, see:
How Assurance Levels Are Used During AuthenticationHow Assurance Levels Are Used During Authentication
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 presents the next possible option in the list for the users to complete. For example, if the default option is Authenticate OTP and the users have not registered devices with the RSA Authenticator app, then RSA skips the default option and displays the next non-Authenticate option in the list, such as SecurID OTP.
If users cannot complete any options, then the users see "Contact your administrator," "Authentication failed," or a message to install and register the RSA Authenticator 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 registered devices, include non-app authentication options (for example, SecurID OTP) 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.
For a detailed description of how the assurance level evaluation process works, see Evaluating Assurance Levels and Primary Authentication Status to Return Authentication Methods .
Assurance Levels and Emergency Access CodeAssurance Levels and Emergency Access Code
Similar to other RSA authentication methods, Emergency Access Code 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 Access Code.
Note: RSA recommends that you avoid adding Emergency Access Code to the High assurance level. Doing so will make Emergency Access Code available to your most sensitive applications.
Assurance Levels and SSOAssurance Levels and SSO
In IDR 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 t+
he 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.
Preconfigured Options for Assurance LevelsPreconfigured Options for Assurance Levels
RSA provides the following preconfigured options for assurance levels. You can select each option once in your assurance level configuration.
Authentication Methods | When to Use |
---|---|
SecurID OTP |
For users who are assigned a SecurID hardware or software authenticator in Authentication Manager, or who register a hardware authenticator in the Cloud Authentication Service. |
Device Biometrics |
For users who have completed registration with the RSA Authenticator app on a device with biometrics and have set up biometrics. |
Approve |
For users who have completed registration with the RSA Authenticator app. |
SecurID Authenticate OTP |
For users who have completed registration with the RSA Authenticator app. |
SMS OTP |
For users who have a phone that can receive SMS messages. Does not require authenticator registration. |
Voice OTP |
For users who want to receive an OTP through a voice phone call. A mobile phone is not required. |
FIDO |
For users who have a registered FIDO authenticator. Only supported in IDR SSO Agent and relying party deployments. |
QR Code | For users who have completed registration with the SecurID app. |
Emergency Access Code | A method for users who do not have access to the authenticator they normally use. |
SecurID OTP and Approve |
For users who are assigned a SecurID hardware or software authenticator and have completed registration with the Authenticator app. Only supported in IDR SSO Agent and relying party deployments. |
SecurID OTP and Device Biometrics |
For users who are assigned a SecurID hardware or software authenticator and have completed registration with the SecurID app on a device with biometrics and have set up biometrics. Only supported in IDR SSO Agent and relying party deployments. |
FIDO and Approve |
For users who have a registered FIDO authenticator and have completed registration with the RSA Authenticator app. Only supported in IDR SSO Agent and relying party deployments. |
FIDO and Device Biometrics |
For users who have a registered FIDO authenticator and have completed registration with the RSA Authenticator app on a device with biometrics and have set up biometrics. Only supported in IDR SSO Agent and relying party deployments. |
Guidelines and Best PracticesGuidelines and Best Practices
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.
-
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 IDR SSO Agent, RADIUS, and relying parties. An assurance level can require FIDO authenticators for users gaining access through the IDR 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 OTP 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 SecurID Authenticate OTP, consider not adding Device Biometrics as an authentication method in the same assurance level as the OTP. 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.