This change impacts RSA customers who use Salesforce Single Sign-On (SSO) with an external Identity Provider, including customers who have configured RSA Cloud Access Service (RSA ID Plus) as the SSO provider for Salesforce.
- SSO initiated via SAML
- OIDC
Summary
On January 20, 2026, Salesforce began enforcing a security change requiring Device Activation for Single Sign-On (SSO) logins from external identity providers. This change affects how users authenticate to Salesforce when RSA is configured as the SSO provider. This will apply on the 3rd of February 2026.
Salesforce Device Activation is a security control that ensures a user’s device or browser is recognized and trusted before granting access. It can require additional verification (for example, an email code or authenticator prompt) when a new or unrecognized device or IP address is used.
What's Changing
Salesforce is enforcing Device Activation for security and compliance. Key points include:
- Devices will need activation during SSO login when not previously recognized.
- The enforcement is part of Salesforce's MFA and security posture updates.
What Is Device Activation?
Salesforce Device Activation is a security feature that requires users to verify their identity when logging in from an unrecognized browser, device, or from a location outside of a trusted IP range.
Email verification is the primary identity verification method for most users. During login, Salesforce sends a verification code to the user's registered email address.
Impact on RSA-Based SSO Integrations
Customers who use RSA Cloud Authentication Service (including RSA SecurID or RSA Ready integrations) as the Identity Provider to sign into Salesforce will observe the following:
- Mandatory Device Activation: Users may be prompted to activate their browser/device when logging in via RSA SSO if the device/IP is new or doesn't meet Salesforce trust criteria (e.g., trusted IP range, previously activated device).
- No Change to RSA Authentication Logic: RSA continues to perform the authentication as usual (e.g., RSA SecurID passcodes, push, or adaptive authentication). The change is on the Salesforce service-provider side requiring device trust signals.
FAQs
Q: Are users required to re-authenticate every time?
A: No — once a device has been activated and trusted by Salesforce (e.g., via cookie/IP), users typically won't see repeated device challenges until conditions change (clear cache, new IP, expiration).
Typically you won't be seeing multiple prompts once a device has been trusted.
Q: What if users get unexpected device activation prompts?
A: This typically means Salesforce did not recognize the device/IP. Ensure trusted IP ranges and assertion attributes are configured appropriately and advise users on how to complete activation prompts.
Q: Will this impact RSA Community Logins?
A: No. RSA Customers and partners will not be impacted by this change on RSA Community, myRSA, or RSA Partner Portal.
NOTE: You can follow this article for future updates relating to this topic.
Related Articles
Salesforce - SCIM Configuration - RSA Ready Implementation Guide 51Number of Views UPDATE: RSA Via LG Integrations with Salesforce Using TLS 1.0 Encryption Protocol 38Number of Views Salesforce Experience Cloud - SAML My Page SSO Configuration - RSA Ready Implementation Guide 21Number of Views Root CA certificate is required for activation error when importing a custom certificate signed by a known CA into Operati… 507Number of Views User changes his mobile device in RSA Cloud Authentication Service 126Number of Views
Trending Articles
RSA MFA Agent 2.3.6 for Microsoft Windows Installation and Administration Guide RSA Authentication Manager 8.9 Release Notes (January 2026) How to install the jTDS JDBC driver on WildFly for use with Data Collections in RSA Identity Governance & Lifecycle RSA Authentication Manager 8.8 Setup and Configuration Guide Artifacts to gather in RSA Identity Governance & Lifecycle