Skip to main content
Groups* MFA - Getting Started *
Featured group

* MFA - Getting Started *

Welcome! This group is dedicated to helping you protect Salesforce account access with Multi-Factor Authentication (also known as MFA, and formerly called Two-Factor Authentication or 2FA). Join the conversation here to ask questions, get answers, learn best practices, and share your experiences. --------------------------------------- This group is maintained and moderated by Salesforce employees. The content received in this group falls under the official Forward-Looking Statement: http://investor.salesforce.com/about-us/investor/forward-looking-statements/default.aspx
Ask a question...
Bhavin Patel (Community Experience Manager at Salesforce) posted in Communications & Readiness Connect
May 7, 3:20 PM

*** Important change for: All Core Org Admins & Security Contacts ****** Important change for: All Core Org Admins & Security Contacts ***This update is limited to Salesforce Platform.This update is limited to Salesforce Platform. 

 

In Progress Enhancements: Immediate Action Required

Salesforce is enforcing these controls now. To avoid service disruption, verify your configuration. 

 

 

Upcoming Enhancements: Take Action Now

Detailed enforcement dates for each control are available in the linked resources.

 

  • Phishing-Resistant Multi-Factor Authentication (MFA) for Privileged Users, including Admins: Phishing-resistant MFA will be enforced for System Administrators and users who have certain privileged permissions when they log in to any org, including sandboxes. This requirement applies to direct UI and Single Sign-On (SSO) logins. Learn more about how to set up this feature and the enforcement timeline.
  • MFA for All: MFA will be enforced for all employee license users who log in via the Salesforce UI or Single Sign-On (SSO) to all orgs, including sandboxes. Learn more about how to set up this feature and the enforcement timeline.
  • Step-Up Authentication: Salesforce will enforce identity verification challenges for all users (including those using SSO) when they perform high-sensitivity actions, starting with UI report exports and viewing, and for anomalous behavior while accessing reports. This change applies across all orgs, including sandboxes. To prepare for this change, ensure that your users each have one of the following registered: Salesforce MFA, a current email address, or a mobile phone number. To learn more about how to prepare for this change, see Prepare for the upcoming Step-up Authentication requirements on Report Actions and Prepare for Step-up Authentication in Anomalous Report Export.
  • Upcoming Transaction Security Policy (TSP) Enhancements (Shield & Event Monitoring customers): Salesforce will automatically deploy a default TSP for ReportEvent. When enabled, this policy triggers a step-up authentication challenge for UI report exports that exceed 10,000 records. Additionally, a new "Manage Transaction Security Policy" permission will be required, in addition to the "Customize Application" permission, to manage any TSP. Review and assign this new permission to authorized users before enforcement. Learn more about how to set up this feature and the enforcement timeline.

 

Strongly Recommended but Not Required at This Time

This control is recommended but not mandatory as previously announced.

 

  • IP Address Restriction: Salesforce isn’t enforcing the IP address restrictions in profiles or the “Enforce login IP ranges on every request” session setting at this time. However, we continue to strongly recommend that you adopt IP address restrictions and enable the setting, and we may require that configuration in the future. To learn more about how to configure your IP Allowlist permissions, see Restrict Login IP Addresses in Profiles and Set Trusted IP Ranges for Your Org.
  • Phishing-Resistant MFA for Non-Admin Users: To ensure the highest level of protection against identity-based threats, Salesforce strongly recommends that you implement phishing-resistant MFA for all users. See Prepare for MFA Enforcement for All Employee Users.

 

More Information

Join one of these webinars where Salesforce experts will discuss these changes.

 

32 comments
Write a comment...
0/9000
Gabriel Zanotelli (Salesforce Developer at Carbel Auto Group)
Today, 1:55 PM
Having problems authenticating whit MFA

Last week, I created a passkey for my Sandbox org and was able to log in without any problems for several days.

Today, after not logging in over the weekend, I was unable to authenticate beyond the screen below. Every time I clicked the "Verify Your Identity" button, the page simply reloaded.

  

 

Having problems authenticating whit MFA

 

I asked another System Administrator for help, and they deleted the

Security Key (U2F/WebAuthn)

associated with my account. Now I'm stuck on the screen below and I'm unable to register a new passkey. The same issue is occurring: whenever I click the button, the page simply reloads.  

 

image.png

 

Is anyone having the same problem? I tried this at two different browsers and the same error occured. 

 

1 answer
Write an answer...
0/9000
Anthony Lullo (Solution Architect at Topco)
Jun 24, 4:11 PM
Outside partners who need System Admin access

With the waive MFA permission being phased out, what are customers expected to do when they bring on a third-party consulting partner to create projects and those users need System Admin privileges?  

#MFA

8 answers
  1. Eric (Moonpie) (.)
    Jun 30, 3:45 PM

    @Charles Troster

     

    Thank you for that information. Our company does approve/allow one of the password managers. However, I do not use it and am unsure the corporate thought on a shared service user. I will ask my manager about that possibility. 

     

    "Are you saying that in a "Login As" session, the service user's managed package license does not work?" 

     

    I would say that it does not *fully* work. We are able to access the package content and do some things, but not the things that we ultimately need this Service User to do:

    • We give our Service User a license to use this managed package.
    • I have a license to use this managed package.
    • When logged in directly as myself, I can schedule jobs "inside" this managed package.
    • When logged in directly as the Service User, I can schedule this managed package's jobs.
    •  When I login as myself, then use the Salesforce "Login As" functionality to login as the Service User, I am unable to schedule this managed package's jobs.

     

    I am unsure whether this is across all managed packages or just this one. But I can say that this is either a feature of this managed package or a known bug that they have embraced as a "feature." 

     

    Currently I am testing whether a Service User can schedule and run these jobs without "privileged" access. If so, we could split our current Service User into two and have one non-privileged with "standard" MFA for the managed package.

Write an answer...
0/9000
Bhavin Patel (Community Experience Manager at Salesforce) posted in Communications & Readiness Connect
Jun 19, 12:22 PM

*** Important Update: Step-Up Authentication for Report Actions ****** Important Update: Step-Up Authentication for Report Actions ***Hey Trailblazers! We have some important updates to share about the upcoming Step-Up Authentication requirement for Report Actions —Hey Trailblazers! We have some important updates to share about the upcoming Step-Up Authentication requirement for Report Actions —  Here's what you need to know: 

  

Change 1: Step-Up Challenges Now Scoped to Export Actions Only

Step-Up Authentication challenges will now trigger only when exporting or printing reports — not when simply viewing reports, dashboards, or accessing the Reports/Dashboards tabs in the UI. 

 

The Session Level Policy setting has been added to reflect this:

 "Require periodic step-up authentication when exporting or printing"

This updated policy replaces the prior setting upon enforcement. Find this by going to Setup -> Identity Verification and selecting the new policy for Reports and Dashboards. 

 

Change 2: Profile Login IP Restrictions as an Alternate Control

Step-Up Authentication for report exports will not be required when both of the following conditions are met:  

  • A user's Profile has Login IP restrictions configured, AND
  • Either the user's IP address hasn't changed between login and report export, or "Enforce login IP ranges on every request" is enabled in Session Settings

This gives admins a meaningful alternate control if your org uses IP-based access restrictions and when configured, users will not see step-up challenges during report export. 

 

Enforcement Timeline — No Changes  

Enforcement dates remain unchanged from what was previously published:

  • All Sandboxes: June 17 – June 24
  • Production: July 1 – July 25

 Additional Resources

Have questions? Drop them in the comments below — we're here to help! 

15 comments
  1. Joanna Lloyd (Bridge Communities)
    Jun 29, 5:11 PM

    @Kristi Maness

    thanks for this information:  "...in our testing, we have OKTA authentication for login but I currently have Salesforce authenticator as well so it kicks me there to verify the export."    

    I was

    wondering whether Admins could respond to the report export challenges via the regular authenticator.   To me, that seems easier than going back to the initial login method for Admins, which in our case might be Entra with a biometric option.  Is this what others are seeing?    (thanks, this has been very confusing for our small-ish org)

Write a comment...
0/9000
Voonna Meghana (Student at Raghu Engineering College)
Apr 20, 11:02 AM
Do We Need Salesforce MFA if MFA Is Already Enforced via Entra ID (SSO)?

With MFA becoming mandatory starting June 2026 for both sandbox and production environments, I have a question regarding our current setup. 

 

At present, users log in to Salesforce via SSO using Microsoft accounts (Azure/Entra ID), and MFA is already enforced at the identity provider level. Similarly, access to Azure DevOps (ADO) is also managed through Entra ID, where MFA is enforced. 

 

Given this setup, is it still necessary to enable Salesforce-native MFA for users, or is enforcing MFA through the identity provider (Entra ID) sufficient to meet the requirement? 

 

Appreciate any guidance or clarification on this.

3 answers
  1. Jenni Killmer (Voya Investment Management)
    Jun 25, 2:18 PM

    MFA with your SSO will work for your non-privileged users. Note that MFA is currently required in all production orgs, but not in sandboxes. Between June 22 and 29, MFA will be required in all sandboxes, too. 

     

     

    However, sysadmins and users with one or more of these permissions (view all data, modify all data, customize application, author apex) will need to add phishing-resistant MFA to their login pattern.  

     

    Because Salesforce hasn't created a way for us to test this specific division between phishing-resistant and non-phishing resistant requirement, I don't know exactly what the login experience will be in prod with SSO. My educated guess is that it will be one of these two sequences after launching Salesforce from our MyDomain link:

    1. Use the SSO MFA as before, and then use the phishing-resistant MFA; or
    2. Use only the phishing-resistant MFA. 
Write an answer...
0/9000
Gail Flowers
May 14, 9:02 PM
MFA updates for both Admin and Non-Admin users . Are OAuth integrations (Login Type Remote Access 2.0) exempt?

The mandatory MFA updates for both Admin and Non-Admin users states " This requirement applies to direct UI and Single Sign-On (SSO) logins." Does this mean user accounts used in OAuth integrations (Login Type Remote Access 2.0) are exempt from this security update. If not, how does this effect these logins/integrations?

4 answers
  1. shefali tanwar (Trail Guild)
    Jun 18, 8:15 AM

    Yes, user accounts used strictly for programmatic OAuth integrations (Remote Access 2.0) via the API are exempt from the mandatory MFA update. Because this requirement exclusively targets interactive direct UI and Single Sign-On (SSO) human logins, these back-end integrations will remain unaffected and continue to function seamlessly without interruption.

Write an answer...
0/9000
Ayu P
May 21, 5:05 AM
We use SSO, is there any changes to be done at Salesforce side to meet ACR/AMR requirement ? The SAML shows it as weak.

Received an security notification from Salesforce regarding Phishing-Resistant MFA for Privileged users. We use Entra SSO SAML, the SAML tracer shows weak, is there any configuration changes that needs to be done on Single sign on page in salesforce? I do Know there are some changes to be done on the IDP side but I'm not sure what changes to be made at Salesoforce end to meet ACR/AMR requirement. @* MFA - Getting Started *@* Salesforce Administrators *@* Customer Success *@* Salesforce Developers *

6 answers
  1. Jim Williams (Berkeley College)
    Jun 9, 6:19 PM

    HI all, for single sign-on where we use the DUO authenticator app, our network administrator updated our MS Active Directory IdP to pass this attribute in the SAML response.  After this, we no longer received the verification code email after authenticating with DUO: 

     

    Under the SAML Tag Heirarchy: samlp:Response , Assertion:               

            <AttributeStatement> 

                <Attribute Name="AMR"> 

                    <AttributeValue>multipleauthn</AttributeValue> 

                </Attribute> 

            </AttributeStatement> 

     

    What I am not following, under the same tag hierarchy, we have the subtag hierarchy  AuthnStatement;AuthnContext, and under there we have  

     <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</AuthnContextClassRef>  

      

    I thought the value PasswordProtectedTransport would also be picked up as not stringent enough, but apparently just having the AMR attribute value of  multipleauthn  was enough of a strong "signal" to bypass the verification code. 

     

    I hope this helps anyone.   And yes the comments are correct - we needed to make the changes on the IdP side.   I donlt know by what mechanism this is done; I'm a developer not a network admin.   But I assume we will need to have our IdP pass different values for the high-level users that need the "anti-phishing" MFA signal passed to Salesforce.  I'm trying to whittle down the number of those users down significantly.   I'll let you know how that does when we are able to test in a sandbox. 

     

    Thanks again everyone, JIm

Write an answer...
0/9000
Samantha Li (IT Admin at ChinchillaLand Inc)
May 7, 3:56 AM
Question regarding upcoming Phishing-Resistant MFA Enforcement for Privileged Users

Hi community, 

 

The article said user with Modify All Data and View All Data would need to use Phishing-Resistant MFA, I'm just wondering if View All Data on specific object only counts in the requirement or not? Any one knows? 

 

Article:

https://help.salesforce.com/s/articleView?id=005321563&type=1

 

 

Many thanks!

2 answers
  1. Rosie Lewis (SHARE)
    May 13, 8:14 PM

    A follow up to this question. Do you know if it is every View/Modify in the system preferences?

Write an answer...
0/9000
Abhijeet Budke
Apr 2, 5:06 AM
Verify MFA in Salesforce for upcoming Security Control ( June 2026 )

We have OKTA enabled SSO ( ID Initiated) for our Salesforce Production org only. We are planning to implement for our non prod org. For user experience, we are getting push notification through OKTA and then user able to login in to Salesforce. As SSO was implemented long back, we want to know with upcoming security checks ( June 2026) our current configuration is compliant. What is best way to verify ?

1 answer
  1. Deepak Sachdeva (Nubys Tech)
    Apr 2, 5:27 AM

    Hi @Abhijeet Budke

     

     

    Since we are using OKTA SSO with push-based MFA, Salesforce MFA compliance depends on whether the MFA challenge is enforced at the IdP and correctly passed in the SAML assertion. The best way to verify is by checking Login History for the “Authentication Method Reference” field showing “mfa”. Additionally, validate OKTA sign-on policies to ensure MFA is enforced for all users and not bypassed. We should also test in non-production orgs and use Salesforce’s MFA Assistant to confirm compliance ahead of the June 2026 security checks  

    If it works for you, feel free to mark it as the best answer. 

Write an answer...
0/9000
Pranav Burhade
Jan 29, 11:46 AM
MFA bypass on salesforce site if already validated MFA on IDP side

So, we received information that Salesforce is going to enforce MFA on each SSO login, as mentioned in the following documentation: 

 

https://help.salesforce.com/s/articleView?id=005237070&type=1&utm_source=techcomms&utm_medium=email&utm_campaign=FY26_Core_4097908

As described in this document, we enabled MFA using the “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org” option under Setup → Identity Verification.

We are sending the following AuthnStatement in the SAML response:

  <saml:AuthnStatement AuthnInstant="2026-01-29T10:11:46.404Z"
                             SessionIndex="e19ce28a63754b40a9361c98504d8d1d"
                             >
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:MobileTwoFactorContract</saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>

However, Salesforce is still prompting users for MFA after SSO login.

Is there anything else that needs to be configured on the Salesforce side to bypass MFA, considering that MFA is already being verified at our IdP?

Thanks in advance.

8 answers
  1. Chun Wei Lee (Seagate)
    Mar 15, 3:30 PM

    If you are using custom SAML SSO, then you can add additinoal attribute "AMR " to your SAML response with suggested value in the document "Changes to Device Activation for Single Sign-On (SSO) Logins" (refer to 1st table , row "SSO Identity Provider (IdP) Secure Authentication") 

Write an answer...
0/9000