Loading
Identify Your Users and Manage Access
Table of Contents
Filter by (0)Add
Select Filters

          No results
          No results
          Here are some search tips

          Check the spelling of your keywords.
          Use more general search terms.
          Select fewer filters to broaden your search.

            Search all of Salesforce Help
            Search all of Salesforce Help
            Device Activation for Salesforce Orgs

            You are here:

            1. Salesforce Help
            2. Docs
            3. Identify Your Users and Manage Access

            Device Activation for Salesforce Orgs

            Device activation is a security measure that helps prevent unauthorized access to your org. Device activation works by requiring extra identity verification for unfamiliar login attempts. For employees logging in to your org, device activation is automatically enabled and can't be turned off.

            Required Editions

            Available in: both Salesforce Classic and Lightning Experience
            Available in: Essentials, Group, Professional, Enterprise, Performance, Unlimited, Developer, and Contact Manager Editions

            Overview

            For UI logins in active production and sandbox orgs, device activation is required if Salesforce can't trust the login attempt by using one of these methods.

            Note
            Note Device activation isn't required for API login.
            Security Measure Description Device Activation Behavior
            Strong authentication method For username-password login, this means multi-factor authentication (MFA). For single sign-on (SSO), this means that the identity provider uses an authentication method that meets Salesforce security standards. For more information on accepted methods, see the Strong Authentication Methods for Single Sign-On section. Logins that use a strong authentication method always skip device activation, regardless of browser or device recognition and IP ranges.
            Browser or device recognition Salesforce considers a browser or device to be recognized if it can be matched to information in the sfdc_lv2 platform cookie.

            Salesforce uses this measure to determine device activation behavior only in certain scenarios:

            • IP ranges aren't configured and the login doesn't use a strong authentication method.
            • Org-wide trusted IP ranges or profile login IP ranges are too wide and the login doesn't use a strong authentication method.

            Narrow IP ranges

            • IPv4: not exceeding 16,777,216
            • IPv6: not exceeding 2^99

            These limits apply to org-wide ranges, and separately to login IP ranges for a specific profile.

            		 You can secure your org with two types of IP ranges: org-wide trusted IP ranges and profile login IP ranges.

            For narrow profile login IP ranges:

            • Device activation isn’t applicable. Users who are in range can log in without device activation. Users who are out of range are blocked entirely.

            For narrow org-wide IP ranges:

            • Users who are out of range must complete device activation, assuming that the login doesn't use a strong authentication method.
            Note
            Note To make it easier for Salesforce Customer Support representatives to troubleshoot issues, you can enable the Skip Device Activation at Login permission on a user’s account. Enabling this permission lets only a Customer Support representative skip device activation when logging in to the account. Users with the permission still have to verify their identity when they log in from an unrecognized browser, device, or IP address.

            Browser or Device Recognition

            To determine whether a user's browser or device is recognized, Salesforce uses the sfdc_lv2 platform cookie. Salesforce creates this cookie the first time that a user completes device activation, as long as the "Don't ask again" checkbox is selected. This checkbox is selected by default. Here's the checkbox on the page where users verify their identity via email. For other verification methods, this page looks different, but still includes this checkbox.

            Identity verification page with "Don't ask again" checkbox highlighted

            Profile Login IP Ranges

            Profile login IP ranges control whether a user can log in. If a user tries to log in from an IP address outside of their profile login range, Salesforce blocks the login, regardless of any other settings. However, if your IP ranges are too wide, users can still be challenged for device activation if they are within their profile range. The IP range limit applies to both profile login IP ranges and org-wide trusted IP ranges. For example, if the user’s profile login IP ranges are under the limit, but your org-wide trusted IP ranges exceed the limit, users can be required to complete device activation.

            The IP range limit depends on the type of IP address.

            IP Address Type Limit
            IPv4 16,777,216
            IPv6 2^99 (2 to the power of 99)

            Private IP addresses from 10.0.0.0 to 10.255.255.255, as defined in RFC 1918 from the Internet Engineering Task Force, don’t count toward the total.

            Here's an overview of the login behavior for active production and sandbox orgs.

            IP Range Configuration Login Behavior
            Doesn’t exceed the limit for either org-wide trusted IP ranges or the profile's login IP ranges
            • Within profile IP range: device activation isn’t required
            • Out of profile IP range: login is blocked entirely
            Exceeds the limit for either org-wide trusted IP ranges or the profile's login IP ranges
            • Within profile IP range: device activation is required for an unrecognized browser or device (no sfdc_lv2 cookie)
            • Out of profile IP range: login is blocked entirely

            Here’s how Salesforce evaluates the login when profile login IP ranges are configured.

            1. Is the user's IP address out of range for their profile login IP ranges?
              • Yes—the login is always blocked entirely, regardless of any other conditions.
              • No—go to step 2.
            2. Does the login use a strong authentication method—MFA for username-password login or an accepted authentication method for SSO?
              • Yes—device activation is skipped.
              • No—go to step 3.
            3. Are either the profile login IP ranges or your org-wide trusted IP ranges (if configured) too wide?
              • Yes—go to step 4.
              • No—users can log in from their profile login IP range without device activation. As mentioned in step 1, logins from outside of the range are blocked entirely.
            4. Does Salesforce recognize the browser or device, based on the sfdc_lv2 cookie?
              • Yes—the device is already activated. Users can log in without completing identity verification.
              • No—device activation is required. If users leave the “Don't ask again” checkbox selected, they won’t be challenged on subsequent logins, until the cookie expires.
            Example
            Example A user who doesn't use MFA logs in from an IP address within their profile range. The login IP ranges for their profile don't exceed the limit. However, the org also has org-wide trusted IP ranges, and these ranges do exceed the limit. Salesforce doesn't recognize the user's browser or device, so the user must complete device activation, even though their IP address is within their profile range. The user makes sure that the "Don't ask again" checkbox is selected when they verify their identity. Salesforce stores the user's browser and device information in the sfdc_lv2 cookie. Upon the user's next login attempt, Salesforce recognizes them based on this cookie, and they can log in without extra identity verification.

            Org-Wide Trusted IP Ranges

            Org-wide trusted IP ranges are less restrictive than profile login IP ranges. Users can still log in if they’re outside of the org-wide IP range. However, if IP ranges are too wide, users can still be challenged for device activation even if their IP address is trusted. The IP range limit depends on the type of IP address.

            IP Address Type Limit
            IPv4 16,777,216
            IPv6 2^99 (2 to the power of 99)

            Private IP addresses from 10.0.0.0 to 10.255.255.255, as defined in RFC 1918 from the Internet Engineering Task Force, don’t count toward the total.

            Here’s how org-wide IP ranges work, assuming that the user’s profile doesn’t have login IP ranges.

            Org-Wide IP Range Configuration Login Behavior
            Doesn’t exceed the limit
            • Within org IP range: device activation isn’t required
            • Out of org IP range: device activation is required, even if Salesforce recognizes the browser or device
            Exceeds the limit Device activation is required for an unrecognized browser or device (no sfdc_lv2 cookie), regardless of whether the user's IP address is within the org range or not.

            Here's the process that Salesforce uses to evaluate the login when org-wide ranges, but not profile login IP ranges, are configured.

            1. Does the login use a strong authentication method—MFA for username-password login or an accepted authentication method for SSO?
              • Yes—device activation is skipped.
              • No—go to step 2.
            2. Are your org-wide trusted IP ranges too wide?
              • Yes—go to step 3.
              • No—go to step 4
            3. (If IP ranges are too wide) Does Salesforce recognize the browser or device, based on the sfdc_lv2 cookie?
              • Yes—the device is already activated. Users can log in without completing identity verification.
              • No—device activation is required, even if the user’s IP address is within the org’s trusted range. If users leave the “Don't ask again” checkbox selected, they won’t be challenged on subsequent logins, until the cookie expires.
            4. (If IP ranges don’t exceed the limit) Is the user within the org's trusted IP ranges?
              • Yes—device activation is skipped.
              • No—device activation is required if the user is out of the org’s range, even if Salesforce recognizes the browser or device.
            Example
            Example Your org has trusted IP ranges that exceed the limit. A user who doesn't use MFA logs in from an IP address within your org range. Salesforce doesn't recognize the user's browser or device, so the user must complete device activation, even though their IP address is within the org range. The user makes sure that the "Don't ask again" checkbox is selected when they verify their identity. Salesforce stores the user's browser and device information in the sfdc_lv2 cookie. Upon the user's next login attempt, Salesforce recognizes them based on this cookie, and they can log in without extra identity verification.

            Strong Authentication Methods for Single Sign-On

            Device activation is bypassed for SSO if the login uses a strong authentication method. For strong authentication, you have two options.

            • Use the Salesforce MFA service.
            • Work with your identity provider to use an authentication method that meets Salesforce security standards. Salesforce accepts a range of Authentication Context Class Reference (ACR) and Authentication Method Reference (AMR) values from your identity provider.

            If you choose the second option, here's how Salesforce checks the authentication method during login depending on your SSO setup. In all cases, if your identity provider sends at least one strong authentication method, device activation is bypassed. For example, if your identity provider sends two authentication methods—a strong method and a weak method—users can skip device activation.

            SSO Configuration How Salesforce Checks the Authentication Method Implementation Steps
            OpenID Connect SSO with predefined authentication provider types In the ID token: ACR or AMR claims. AMR claims are case-sensitive, but ACR claims aren’t. For more information, see the OpenID Connect specification. Work with your identity provider to send an accepted ACR or AMR value.
            OpenID Connect SSO with a custom Apex authentication provider

            Work with your identity provider to send an accepted ACR or AMR value, and then update your Auth.AuthProviderPluginClass implementation to pass the ID token to Salesforce.
            Security Assertion Markup Language (SAML) SSO In the SAML response: ACR (AuthContextClassRef) or AMR values in the AuthnContext statement. For AMR values, the attribute can be named AMR or authmethodsreferences. ACR and AMR values for SAML aren't case-sensitive. Work with your identity provider to send an accepted ACR or AMR value.

            Here's a list of accepted ACR and AMR values. Salesforce accepts these values for both OpenID Connect and SAML.

            Authentication Method Type Accepted Values
            ACR

            Standard ACR values:

            • MobileTwoFactorContract—mobile device authentication using two factors
            • PublicKey—digital signature
            • PGP—digital signature using a public key
            • Smartcard—smart card
            • TimeSyncToken—time synchronization token
            • PKI—Public Key Infrastructure

            Custom values from specific identity providers:

            • Mfa
            • Fido
            • Multipleauthn
            AMR

            Standard AMR values from RFC 8176 from the Internet Engineering Task Force:

            • face—facial recognition
            • fpt—fingerprint scan
            • hwk—hardware-backed security key
            • iris—iris scan
            • retina—retina scan
            • sc—smart card
            • pop—proof of possession of a key
            • swk—software-backed security key

            Custom values from specific identity providers:

            • mfamultipleauthn
            • okta_verify

            Behavior Differences for Non-Revenue Orgs

            In non-revenue orgs, such as trial orgs, device activation is required for an unrecognized browser or device, even if the user's IP address is configured as trusted in the org-wide settings or in the user's profile. This requirement is enforced even for narrow IP ranges.

            Security Measure Device Activation Behavior In Non-Revenue Orgs
            Strong authentication method (MFA for username-password login or accepted authentication method for SSO) Logins that use a strong authentication method always skip device activation. The user is already using multiple factors to prove their identity.
            Browser or device recognition using the sfdc_lv2 cookie If there's no strong authentication method, Salesforce uses this measure to determine device activation behavior.
            Org-wide trusted IP ranges and profile login IP ranges

            For profile login IP ranges:

            • Users who in range must complete device activation for an unrecognized browser or device. Users who are out of range are blocked entirely.

            For org-wide IP ranges:

            • Whether they are in range or not, users must complete device activation for an unrecognized browser or device.
            Example
            Example A user logs in to a trial org from an unrecognized browser or device, without completing MFA. Their IP address is configured as trusted in both the org-wide ranges and their profile login IP ranges. However, they must still complete device activation.

            Verification Methods

            Salesforce uses the highest-priority identity verification method available. Here's the order that Salesforce follows for verification methods:

            1. Built-in authenticator registered with the user’s account, such as Touch ID or Windows Hello
            2. U2F security key registered with the user’s account
            3. Push notification or location-based automated verification with the Salesforce Authenticator mobile app connected to the user’s account
            4. Time-based one-time password (TOTP) generated by a mobile authenticator app connected to the user’s account, such as Google Authenticator™
            5. One-time password (OTP) sent via SMS to the user’s verified mobile device
            6. OTP sent via email to the user’s registered email address
             
            Loading
            Salesforce Help | Article