---
schema_version: "1"
id: 0231c547acc571ffd3db290d2b10322c01354db4c2826f4e30cddd2db93aa9ea
title: Device Activation for Salesforce Orgs
collection: admin
version: current
locale: en-us
portal_url: https://docs.salesforce.com/admin/current/en-us/xcloud/264-0-0/device_activation_orgs.md
canonical_url: https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5
source_site: help.salesforce.com
content_type: documentation
content_hash: cf37bb4455f8e972b187813e3fa70f36d10cfc1060d7e47cc50c679295da2e56
description: 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.
products:
  - Security
release: "264"
---
# 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

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small edition"><colgroup><col></colgroup><tbody><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: both Salesforce Classic and Lightning Experience</td></tr><tr class=""><td class="slds-cell-wrap" style="vertical-align:top;">Available in: <strong>Essentials</strong>, <strong>Group</strong>, <strong>Professional</strong>, <strong>Enterprise</strong>, <strong>Performance</strong>, <strong>Unlimited</strong>, <strong>Developer</strong>, and <strong>Contact Manager</strong> Editions</td></tr></tbody></table>

- [Overview](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Browser or Device Recognition](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Profile Login IP Ranges](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Org-Wide Trusted IP Ranges](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Strong Authentication Methods for Single Sign-On](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Behavior Differences for Non-Revenue Orgs](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)
- [Verification Methods](https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&release=264.0.0&type=5)

## 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)

Note Device activation isn't required for API login.

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col style="width:33.33333333333333%">
          <col style="width:33.33333333333333%">
          <col style="width:33.33333333333333%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e133">Security Measure</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e136">Description</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e139">Device Activation Behavior</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e133 ">Strong authentication method</td>

            <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e136 ">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 <a href="https://help.salesforce.com/s/articleView?id=xcloud.device_activation_orgs.htm&amp;release=264.0.0&amp;type=5">Strong Authentication Methods for Single Sign-On</a>
              section.</td>

            <td data-label="Device Activation Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e139 ">Logins that use a strong authentication method always skip device activation,
              regardless of browser or device recognition and IP ranges.</td>

          </tr>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e133 ">Browser or device recognition</td>

            <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e136 ">Salesforce considers a browser or device to be recognized if it can be matched
              to information in the <a href="https://help.salesforce.com/s/articleView?id=xcloud.platform_cookies.htm&amp;release=264.0.0&amp;type=5" title="The Salesforce Platform uses cookies to improve functionality and accelerate processing times. By saving a user’s settings, cookies can enhance the user’s experience and the Salesforce Platform’s performance.">Salesforce Platform Cookies</a> platform
              cookie.</td>

            <td data-label="Device Activation Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e139 ">
              <p>Salesforce uses this measure to determine device activation behavior only in
                certain scenarios:</p>
              <ul>
                <li>IP ranges aren't configured and the login doesn't use a strong authentication
                  method.</li>

                <li>Org-wide trusted IP ranges or profile login IP ranges are too wide and the
                  login doesn't use a strong authentication method.</li>

              </ul>
            </td>

          </tr>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e133 ">
              <p>Narrow IP ranges</p>
              <ul>
                <li>IPv4: not exceeding 16,777,216</li>

                <li>IPv6: not exceeding 2^99</li>

              </ul>
              <p style="margin-bottom:0;">These limits apply to org-wide ranges, and separately to login IP ranges for a
                specific profile.</p>
            </td>

            <td data-label="Description" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e136 ">You can secure your org with two types of IP ranges: <a href="https://help.salesforce.com/s/articleView?id=xcloud.security_networkaccess.htm&amp;release=264.0.0&amp;type=5" title="To help protect your Salesforce data from unauthorized access, specify a list of IP addresses from which users can log in without receiving an identity verification challenge.">Set Trusted IP Ranges for Your Org</a> and <a href="https://help.salesforce.com/s/articleView?id=xcloud.login_ip_ranges.htm&amp;release=264.0.0&amp;type=5" title="To control login access at the user level, specify the ranges of allowed IP addresses on a user’s profile. When you define IP address restrictions for a profile, a login from any other IP address is denied.">Restrict Login IP Addresses in Profiles</a>. </td>

            <td data-label="Device Activation Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e139 ">
              <p>For narrow profile login IP ranges:</p>
              <ul>
                <li>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.</li>

              </ul>
              <p>For narrow org-wide IP ranges:</p>
              <ul>
                <li>Users who are out of range must complete device activation, assuming that the
                  login doesn't use a strong authentication method.</li>

              </ul>
            </td>

          </tr>
        </tbody>
      </table>

![Note](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_note.png)

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 [Salesforce Platform Cookies](https://help.salesforce.com/s/articleView?id=xcloud.platform_cookies.htm&release=264.0.0&type=5 "The Salesforce Platform uses cookies to improve functionality and accelerate processing times. By saving a user’s settings, cookies can enhance the user’s experience and the Salesforce Platform’s performance."). 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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/security/images/dont_ask_again.png)

## 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](https://datatracker.ietf.org/doc/html/rfc1918#section-3), don’t count toward the total.

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

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col style="width:50%">
          <col style="width:50%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e341">IP Range Configuration</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e344">Login Behavior</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="IP Range Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e341 ">Doesn’t exceed the limit for either org-wide trusted IP ranges or the profile's
              login IP ranges</td>

            <td data-label="Login Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e344 ">
              <ul>
                <li>Within profile IP range: device activation isn’t required</li>

                <li>Out of profile IP range: login is blocked entirely</li>

              </ul>
            </td>

          </tr>
          <tr class="">
            <td data-label="IP Range Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e341 ">Exceeds the limit for either org-wide trusted IP ranges or the profile's login
              IP ranges </td>

            <td data-label="Login Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e344 ">
              <ul>
                <li>Within profile IP range: device activation is required for an unrecognized
                  browser or device (no <code>sfdc_lv2 </code>cookie)</li>

                <li>Out of profile IP range: login is blocked entirely</li>

              </ul>
            </td>

          </tr>
        </tbody>
      </table>

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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_example.png)

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](https://datatracker.ietf.org/doc/html/rfc1918#section-3), 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.

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col style="width:50%">
          <col style="width:50%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e531">Org-Wide IP Range Configuration</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e534">Login Behavior</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="Org-Wide IP Range Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e531 ">Doesn’t exceed the limit</td>

            <td data-label="Login Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e534 ">
              <ul>
                <li>Within org IP range: device activation isn’t required</li>

                <li>Out of org IP range: device activation is required, even if Salesforce
                  recognizes the browser or device</li>

              </ul>
            </td>

          </tr>
          <tr class="">
            <td data-label="Org-Wide IP Range Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e531 ">Exceeds the limit</td>

            <td data-label="Login Behavior" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e534 ">Device activation is required for an unrecognized browser or device (no
              <code>sfdc_lv2</code> cookie), regardless of whether the user's IP address is
              within the org range or not.
            </td>

          </tr>
        </tbody>
      </table>

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](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_example.png)

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 [Use Salesforce MFA for SSO (Salesforce Orgs)](https://help.salesforce.com/s/articleView?id=xcloud.mfa_sso_logins.htm&release=264.0.0&type=5 "To help prevent unauthorized access to your account, Salesforce requires multi-factor authentication (MFA) when users log in via single sign-on (SSO). You can use the MFA service included in the Salesforce platform to satisfy this requirement. With this approach, when users log in to Salesforce, they're prompted to provide an MFA verification method to confirm their identity.").
- 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.

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col style="width:33.33333333333333%">
          <col style="width:33.33333333333333%">
          <col style="width:33.33333333333333%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e671">SSO Configuration</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e674">How Salesforce Checks the Authentication Method</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e677">Implementation Steps</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="SSO Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e671 ">OpenID Connect SSO with <a href="https://help.salesforce.com/s/articleView?id=xcloud.sso_predefined_authentication_provider_parent.htm&amp;release=264.0.0&amp;type=5" title="To use an authentication provider for single sign-on (SSO), define an authentication provider in Setup by using configuration information from a third-party identity provider. Control security settings, customize the SSO experience with error and logout URLs, and configure registration handler settings. Most authentication providers support single sign-on (SSO) and third-party data access, with the exceptions of GitHub, Microsoft Access Control Service, and X (formerly Twitter).">Define an Authentication Provider</a></td>

            <td data-label="How Salesforce Checks the Authentication Method" class="slds-cell-wrap" rowspan="2" style="vertical-align:top;" headers="d105396e674 ">In the ID token: ACR or AMR claims. AMR claims are case-sensitive,
              but ACR claims aren’t. For more information, see the <a href="https://openid.net/specs/openid-connect-core-1_0.html" target="_blank">OpenID Connect specification</a>.</td>

            <td data-label="Implementation Steps" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e677 ">Work with your identity provider to send an accepted ACR or AMR value.</td>

          </tr>
          <tr class="">
            <td data-label="SSO Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e671 ">OpenID Connect SSO with a <a href="https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_plugin_custom.htm&amp;release=264.0.0&amp;type=5" title="To configure single sign-on (SSO) from a third party that supports OAuth but not OpenID Connect, create a custom authentication provider. With a custom authentication provider, users can log in to your Salesforce org with third-party credentials.">Create a Custom External Authentication Provider</a></td>

            <td data-label="Implementation Steps" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e677 ">
              <p>Work with your identity provider to send an accepted ACR or AMR value, and then
                update your <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_AuthProviderPluginClass.htm" target="_blank"><code>Auth.AuthProviderPluginClass</code></a> implementation to pass the
                ID token to Salesforce.</p>
              <ul>
                <li>Use the <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_AuthProviderPluginClass.htm#apex_Auth_AuthProviderPluginClass_handleCallback" target="_blank"><code>handleCallback(authProviderConfiguration,
                      callbackState)</code></a> method to return an instance of the <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_AuthProviderTokenResponse.htm#apex_Auth_AuthProviderTokenResponse_ctor_2" target="_blank"><code>Auth.AuthProviderTokenResponse
                        (provider, oauthToken, oauthSecretOrRefreshToken, state,
                      idToken)</code></a> class.</li>

                <li>Alternatively, use the <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_AuthProviderPluginClass.htm#apex_Auth_AuthProviderPluginClass_getUserInfo" target="_blank"><code>getUserInfo</code></a> method to
                  return an instance of the <a href="https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_Auth_UserData.htm#unique_189672599" target="_blank"><code>Auth.UserData(identifier, firstName,
                        lastName, fullName, email, link, username, locale, provider, siteLoginUrl,
                        attributeMap, idToken, userInfoJSONString)</code></a> class.</li>

              </ul>
            </td>

          </tr>
          <tr class="">
            <td data-label="SSO Configuration" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e671 ">Security Assertion Markup Language (SAML) SSO</td>

            <td data-label="How Salesforce Checks the Authentication Method" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e674 ">In the SAML response: ACR (<code>AuthContextClassRef</code>) or AMR values
              in the <code>AuthnContext</code> statement. For AMR values, the attribute can be
              named <code>AMR</code> or <code>authmethodsreferences</code>. ACR and AMR
              values for SAML aren't case-sensitive.</td>

            <td data-label="Implementation Steps" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e677 ">Work with your identity provider to send an accepted ACR or AMR value.</td>

          </tr>
        </tbody>
      </table>

For a list of accepted AMR and ACR values, see [the accepted MFA values documented in this article](https://help.salesforce.com/s/articleView?language=en_US&id=005321561&type=1).

## 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.

<table class="slds-table slds-table_bordered slds-max-medium-table_stacked slds-m-bottom_small ">
        <colgroup>
          <col style="width:50%">
          <col style="width:50%">
        </colgroup>
        <thead class="slds-text-title_caps ">
          <tr class="">
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e803">Security Measure</th>
            <th scope="col" class="slds-cell-wrap" style="vertical-align:top;" id="d105396e806">Device Activation Behavior In Non-Revenue Orgs</th>
          </tr>
        </thead>
        <tbody>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e803 ">Strong authentication method (MFA for username-password login or accepted
              authentication method for SSO)</td>

            <td data-label="Device Activation Behavior In Non-Revenue Orgs" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e806 ">Logins that use a strong authentication method always skip device activation.
              The user is already using multiple factors to prove their identity.</td>

          </tr>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e803 ">Browser or device recognition using the <code>sfdc_lv2</code>
              cookie</td>

            <td data-label="Device Activation Behavior In Non-Revenue Orgs" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e806 ">If there's no strong authentication method, Salesforce uses this measure to
              determine device activation behavior.</td>

          </tr>
          <tr class="">
            <td data-label="Security Measure" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e803 ">Org-wide trusted IP ranges and profile login IP ranges</td>

            <td data-label="Device Activation Behavior In Non-Revenue Orgs" class="slds-cell-wrap" style="vertical-align:top;" headers="d105396e806 ">
              <p>For profile login IP ranges:</p>
              <ul>
                <li>Users who in range must complete device activation for an unrecognized browser
                  or device. Users who are out of range are blocked entirely.</li>

              </ul>
              <p>For org-wide IP ranges:</p>
              <ul>
                <li>Whether they are in range or not, users must complete device activation for an
                  unrecognized browser or device.</li>

              </ul>
            </td>

          </tr>
        </tbody>
      </table>

![Example](https://sf-zdocs-cdn-prod.zoominsoftware.com/tdta-xcloud-security-264-0-0-production-enus/8cecd769-ab2d-4e07-addf-c4f2927925e1/images/icon_example.png)

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