Set User Expectations for Device Registration and Authentication

Your RSA SecurID token users must learn how to access protected resources using the new authentication methods. You must educate these users to ensure that the onboarding process goes smoothly and that users know exactly what to expect when they register devices and authenticate for the first time. You can provide customized instructions to your users in the e-mail template as described in Customize the Cloud Authentication Service Invitation. Users can register devices only after receiving an invitation.

What Happens During Device Registration

Users complete device registration so that they can use an RSA authenticator app on their mobile device or personal computer to authenticate to protected applications.

Device registration binds the device to the user. For a description of how device registration works and what users experience, see Educating Your Users.

What Happens During Authentication

Users can access agent-protected resources with the following methods:

• Legacy-compatible authentication methods:

  PIN + Approve (Push Notifications)

  PIN + Device Biometrics (Push Notifications)

  Using PINs During the First (Legacy-Compatible) Approve or Device Biometrics Authentication

  Authenticate Tokencode

• Additional Authentication Methods for RSA Authentication Manager 8.5 or Later

• Cloud MFA Experience for RADIUS Client Authentication

• Passwordless Authentication for RSA MFA Agents

Users can authenticate with methods specified by the access policy. They are prompted to authenticate with a method that is based upon their access policy. For more information, see How Assurance Levels Are Used During Authentication.

PIN + Approve (Push Notifications)

To use the Approve method, the user attempts to access the application and is prompted to enter a passcode. The user enters the PIN, then taps a button on an Authenticate device. The user can also tap an interactive notification on the device or on an Apple Watch or Android Wear watch paired to the device. The user must respond within one minute. Otherwise, the method times out and is considered a failed authentication.

Note:  The PIN required for Approve authentication is different from the PIN that may be required to unlock the Authenticate Tokencode in the app.

PIN + Device Biometrics (Push Notifications)

Device Biometrics allows users to authenticate to applications using biometrics available on devices, such as Apple Touch ID or Face ID, Android fingerprint, or Windows Hello. To use Device Biometrics, users must first set up biometrics on their RSA Authenticator app devices. RSA does not force users to do this.

To use Device Biometrics on the RSA Authenticator app on Windows PCs, Windows Hello must be supported by the user's version of Windows and enabled. Users can also sign in using the Windows Hello PIN.

To use Device Biometrics, the user attempts to access the application and is prompted to authenticate. The user enters a PIN, and then will be prompted to use a biometric method to authenticate.

Note:  The PIN required for Device Biometrics authentication is different from the PIN that may be required to unlock the Authenticate Tokencode in the app.

Using PINs During the First (Legacy-Compatible) Approve or Device Biometrics Authentication

The following table describes what users must enter during their first legacy-compatible authentication using Approve or Device Biometrics, in order to establish a PIN to use with Approve or Device Biometrics.

Note:  After the initial Approve or Device Biometrics authentication, an RSA SecurID Token user can change the PIN used for Approve and Device Biometrics to be different from the RSA SecurID PIN(s). The same PIN must be used for both Approve and Device Biometrics authentication.

Note:   It is important to tell your users that, in all cases, the PIN they enter during the first Approve or Device Biometrics authentication will be required in future Approve or Device Biometrics authentications.

Note:  If the Enable Authenticate Tokencode PIN Prompts is checked, during the first authentication using Authenticate Tokencode, the user has to set a PIN. Subsequent authentications will not require a PIN, and the same PIN which was set can be used for Approve and Device Biometrics authentication methods.

Authenticate Tokencode

Similar to RSA SecurID Tokens, the Authenticate Tokencode uses a one-time, automatically generated number called a tokencode. The RSA SecurID Authenticate Tokencode app generates this tokencode on a registered device. The tokencode, verified by the Cloud Authentication Service (CAS), is time-based and must be used before it expires. Tokencodes are display for one minute remian valid for up to five minutes after they are generated and displayed on a user's device.

A PIN may be required to unlock Authenticate Tokencode in the app, but Authenticate Tokencode does not require a PIN during authentication. This method cannot be used for offline authentication.

Additional Authentication Methods for RSA Authentication Manager 8.5 or Later

RSA Authentication Manager (AM) 8.5 or later can act as a secure proxy server that sends authentication requests directly to CAS. This configuration supports authentication by REST protocol authentication agents to CAS over a single secure connection. To use AM as a secure proxy for CAS, it requires the agent to connect to AM but also be configured with a CAS access policy.

AM will send all authentication requests to CAS when the Agent is configured to use AM as a secure proxy for the Cloud. Refer to the Agent's documentation for a list of all CAS and AM authentication methods that the Agent supports.

Note:  Only PIN-free authentication is supported for push methods. The agent does not prompt the user for a PIN when performing Approve or Device Biometrics.

If AM cannot communicate with CAS, it ensures high availability by performing local authentication for CAS OTP methods using Authenticate tokencode (if High Availability Tokencodes is enabled in the Cloud Administration Console), SecurID 700, or DS100 tokencode, and all AM-assigned methods, including SecurID hardware tokens, software tokens, and on-demand authentications.

When the Agent is configured to use AM as a secure proxy for the Cloud, and if a connection from CAS to AM is configured in the Cloud Administration Console, AM will still be able to validate RSA SecurID hardware and software tokens and on-demand authentication assigned to the user in AM.

Cloud MFA Experience for RADIUS Client Authentication

The RSA Authentication Manager (AM) supports various authentication methods within the Cloud MFA Experience through CAS when enabled for RADIUS client configured with AM, allowing users to choose from the available authentication methods.

Key Features:

• Supported Authentication Methods: Supports multiple authentication methods using out-of-the-box (OOTB) configurations, including Approve (Push Notification), Authenticate Tokencode, Device Biometric, SMS Tokencode, Voice Tokencode, Emergency Access Code, and SecurID Tokencode (including New PIN and Next Tokencode modes) for RADIUS clients.

• PIN-Free Authentication:Eliminates the need for PIN when performing authentication for Approve or Device Biometrics.

• Dynamic Authentication Selection:Users can dynamically change their authentication method during the authentication process, enhancing flexibility.

• Tokencode via SMS and Voice: Supports tokencode through SMS and Voice as part of the MFA experience, in addition to standard authentication methods.

• Password + Step-up Authentication Method: (Optional) You can enable or disable password as the primary authentication method. If enabled, the system checks the password first before initiating the step-up authentication. If disabled, the system directly initiates step-up authentication.

• Support for External AD and Internal DB Users:Both external Active Directory (AD) users and Internal Database (DB) users, who are synchronized with CAS, can use this feature, ensuring smooth integration for MFA authentication.

• Unsupported Methods: FIDO, QR Code, and combinations like SecurID Tokencode + Approve are not supported in Cloud MFA Experience.

• SecurID Tokencode Support: Supports SecurID Tokencode, including both New PIN and Next Tokencode modes.

How the CAS RADIUS Access Policy Determines Authentication Methods

The CAS RADIUS access policy determines the authentication options available for users. Once the CAS policy is created, it is manually linked to the AM RADIUS client configuration for authentication.

Users can provide a passcode, any number (less than 4 digits), special characters, or leave the password field blank in the RADIUS client.

• If a valid passcode is entered, it is checked against all AM native authenticators. If no match is found, the CAS access policy configured on CAS is applied, and the server responds with either a success or failure status.

• If the entered input is not a valid passcode (for example, less than 4 digits, special characters, or a blank field), the server does not validate the passcode but instead provides the client with a list of available authentication methods based on the CAS RADIUS access policy.

User authentication options and the corresponding responses from AM depend on the configuration and the user's input in the Password field. The following scenarios describe the different configurations:

• Enable Cloud MFA Experience Only

• Enable Both Password Authentication and Cloud MFA Experience

• Support for AM Managed SecurID Tokencode Authentication

• High Availability (HA) Scenarios

• Code Matching for Approve and Device Biometrics

• Timeout Scenarios and Behavior

Enable Cloud MFA Experience Only

When only the Cloud MFA Experience is enabled for a RADIUS client, without enabling Password Authentication, the method of user authentication is determined based on the input in the Password field. AM uses the CAS access policies to select the correct authentication method for the user. The following table outlines the different authentication scenarios based on user input.

Enable Cloud MFA Experience with Push Notification

When both Cloud MFA Experience and Push Notification are enabled for a RADIUS client, user authentication options depend on input in the Password field. The following table outlines the different authentication scenarios based on user input.

Authentication with Password set to 1 and Push Notification Disabled

When the user enters 1 in the Password field to use the last successful method or default method, AM responds as follows:

Authentication with Password Set to 1 and Push Notification Enabled (Always Send Push Notification Not Selected)

If the user enters 1 in the Password field to use the last successfully used method in CAS or the default method from the assurance level, AM responds as follows:

Authentication with Password Set to 1 or Blank and Always Send Push Notification Enabled

When the user enters 1 or leaves the Password field blank, AM will always send a push notification if the assurance level includes Approve or Device Biometrics.

If none of these methods include Approve or Device Biometrics, AM will present a list of available authentication options to the user. Users are prompted only for authentication methods they are eligible to complete, as defined by the CAS Assurance Levels.

Enable Both Password Authentication and Cloud MFA Experience

Once AM validates the password, it evaluates the CAS access policy based on whether Push Notification is enabled or disabled.

1. Push Notification: Enabled

   • If Always Send Push Notification is not selected:

     • AM prompts the user with: Enter your SecurID OTP, 1 for the last used authenticator, or 2 for more options.

     • If the user enters a passcode, it is checked against all AM native authenticators. If no match is found, AM uses the CAS access policy defined in the RSA Cloud Authentication Service Configuration for authentication.

     • If the user enters options such as 1, 2, any digit (less than 4 digits), special characters, or a blank field, AM follows the CAS RADIUS access policy defined in the RADIUS Client page configuration.

   • If Always Send Push Notification is selected:

     • AM automatically sends a push notification, even if Approve or Device Biometrics are not the user’s default method, provided they are available in the CAS access policy.

     • If the CAS access policy does not include Approve or Device Biometrics, AM will present other available authentication options, based on the configured CAS access policy.

2. Push Notification: Disabled

   • AM prompts the user with: Enter your SecurID OTP, 1 for the last used authenticator, or 2 for more options.

   • If the user enters a passcode, it is checked against all AM native authenticators. If no match is found, AM uses the CAS access policy defined in the RSA Cloud Authentication Service Configuration for authentication.

   • If the user enters options such as 1, 2, any digit (less than 4 digits), special characters, or a blank, AM follows the CAS RADIUS access policy defined in the RADIUS Client configuration page.

Support for AM Managed SecurID Tokencode Authentication

If the Cloud MFA Experience is enabled for the RADIUS client and the user has RSA SecurID tokens managed by AM, they can use those tokens to authenticate to applications. This method supports all tokens managed by AM, including New PIN and Next Tokencode modes.

Pre-requisites:

• AM-managed SecurID Authentication: The Super Admin for CAS must connect the CAS deployment to the AM server. The AM server should be the same server connected to CAS. For more information, see Enable SecurID Token Users to Access Resources Protected by the Cloud Authentication Service.

• Skip Agent List Configuration: The Super Admin must add the authentication agent name to the skip agent list using the following command: /opt/rsa/am/utils/rsautil store -a add_config auth_manager.cas.authentication.runtime.skip.agentnames "agent1" GLOBAL STRING

  Where "agent1" is the authentication agent name created on AM and used by CAS. After adding the agent name, restart all services for the changes to take effect.

Note:  The Super Admin must ensure that CAS Assurance Levels and Access Policies are configured to support SecurID Tokencode.

Note:  When the Cloud MFA Experience is enabled and the user selects Authenticate Tokencode as their authentication method, a PIN is not required. The Create PIN and Change PIN functionalities do not apply in this case.

High Availability (HA) Scenarios

When CAS is unreachable, AM validates the tokencode locally using AM-owned tokens and Cloud-owned tokens, such as SID700, DS100, or Authenticate Tokencode, if they are synced and available.

When Cloud MFA Experience is enabled for the RADIUS client and CAS is unreachable, the system responds as follows:

• CAS Unreachable and Cloud MFA Availability:Modern cloud authenticators (for example, SMS Tokencode, Voice Tokencode, Approve, Device Biometrics, and Emergency Access Tokencodes) will not be available. AM prompts the user with: Enter your OTP. Note that additional MFA methods are currently unavailable.

• Password + Step-Up Mode Behavior: If both Password Authentication and Cloud MFA Experience are enabled for the RADIUS client and CAS is unreachable after password authentication, modern cloud authenticators will not be available. AM prompts the user with: Enter your OTP. Note that additional MFA methods are currently unavailable.

  In both Step-Up and Password + Step-Up modes, the user will be prompted to provide tokencode if CAS is unreachable. However, in Password + Step-Up mode, the user must first enter their password before being prompted for the Tokencode.

Code Matching for Approve and Device Biometrics

The Cloud MFA Experience now includes an option for AM to provide confirmation codes for push-eligible methods like Approve and Device Biometrics.

When Cloud MFA Experience is enabled for the RADIUS client, the user will see a confirmation code on the RADIUS client if Approve or Device Biometric is selected as the authentication method.

The user can select Approve or Device Biometrics in the authentication prompt or the CAS policy can automatically trigger it. Once the code is displayed, the user can verify it on their device using methods, such as Visual, Selection, or Input.

After successfully verifying the code on the device, the user can enter 1 in the RADIUS client to complete the authentication or 2 to choose any other eligible authenticators. For more information on how to enable the code-matching setting for Cloud tenants, refer to the Configure Session and Authentication Method Settings.

Timeout Scenarios and Behavior

Timeout Settings for Password + Step-Up Authentication:

• Timeout Configuration for Password + Step-Up Mode: Timeout behavior for Password + Step-Up authentication can be configured in the RADIUS client configuration page, allowing the user to define the timeout duration for step-up challenges after the primary password authentication.

Timeout After a System Triggered Push Notification:

• Timeout Behavior and Alternate Authentication Methods: When Push Notification is enabled, the RADIUS client sends a push notification for Approve and Device Biometrics without forcing users to select a method, when Approve or Device Biometrics is the user's default authentication method.

  If the push notification times out, AM will prompt the user with other available authentication options based on the CAS access policy configurations.

Passwordless Authentication for RSA MFA Agents

RSA is gradually introducing support for passwordless capabilities across its RSA MFA Agents, starting with the RSA MFA Agent for Windows in June 2025. When functioning as a secure proxy for CAS, AM supports passwordless features from agents that provide this capability. Passwordless authentication allows users to sign in to their devices without entering a password.

For information about passwordless authentication support and configuration, refer to the respective agent’s Installation and Administration Guide.

High Availability for Passwordless

If CAS is not reachable from AM, RSA MFA Agents that are configured for passwordless authentication use previously downloaded day files to complete authentication. This offline fallback applies only to agents performing passwordless authentication