Skip to main content
Grupos* MFA - Getting Started *
Grupo em destaque

* 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
Faça uma pergunta...
Bhavin Patel (Community Experience Manager na Salesforce) publicou em Communications & Readiness Connect
24 de jul., 15:02

*** Important updates: MFA Enforcement Update: R1 Window Rescheduled to July 27-28 ****** Important updates: MFA Enforcement Update: R1 Window Rescheduled to July 27-28 ***We wanted to give you a heads-up that the R1 MFA enforcement window has been updated.We wanted to give you a heads-up that the R1 MFA enforcement window has been updated. Here's what you need to know:

 

What Changed

The R1 enforcement window has moved from July 21–22 to July 27–28.

 

Why the Change

We made this adjustment to address a few things:

  • Additional time was needed to fully process previously approved extensions
  • Some SSO users on orgs with approved extensions were being unexpectedly prompted for MFA

If You Have an Approved Extension

Keep in mind that approved extensions can take up to 48 hours to take effect, so you may still see MFA prompts during that window.

 

If your org has an approved extension but you're still being prompted for a passkey, please refer to this Knowledge Article for detailed guidance on specific use cases.

 

What's Not Changing

  • The MFA for All schedule remains the same
  • R2a, R2b, Japan & Korea, and all subsequent release groups are on their original schedules

Where to Find the Latest Info

The PRMFA Knowledge Article has been updated to reflect the new R1 window — that's your best source for the current schedule and details.

 

Have questions? Drop them in the comments below and we'll do our best to help! 

 

#MFA #Security

2 comentários
Escrever um comentário...
0/9000
Gabriel Zanotelli (Salesforce Developer na Carbel Auto Group)
20 de jul., 13:55
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. 

 

7 respostas
Escrever uma resposta...
0/9000
Alex Crowder
29 de nov. de 2023, 00:05
New phone, can't find qr code for authenticator app

I have a new phone, and I downloaded my authenticator app and logged in.  However, I don't know where to find the qr code to finish setting up for accessing Salesforce.

7 respostas
  1. Jasmine Weathers (Mass General Imaging)
    27 de jul., 15:06

    Experiencing the same issue. I have been exporting reports for years and all of a sudden this morning I have to authorize exports using the authenticator app???? There's no way to bypass it, and I really need this report and the others I am trying to export. The authenticator app doesn't even work when trying to set it up; no screen pops up in Salesforce that prompts you to enter the phrase the app wants you to type in. 

Escrever uma resposta...
0/9000
Tina Chang (Deputy Director, Operations na Food and Drug Law Institute)
22 de jul., 19:34
Verification code for report exporting

 It just started today, 7/22, that when staff export reports, they are asked for verification code. 

When they enter the code from the authentication app, it doesn't work and just keep looping. 

I tried to generate temporary verification code via staff's user account. An email was sent to them but no code and no link, nothing. I don't have the code either. so dead-end. 

 

We use MS SSO for staff to get in Salesforce. Our IT people just enabled passkey method on the network. One staff set up passkey successfully and she could now export reports fine. However, two other staff can't set up passkey, the same, got stuck on verification code screen. 

 

I don't know what else to do. Please advise. 

3 respostas
  1. Nancy Jacobs
    24 de jul., 19:26

    Hi @Rodrigo Andrade

     

     

    Please review these areas in the sandbox within Setup: 

     

    Session Settings

    Look for the session-level policy named approximately:

    - Also review the Reports and Dashboards access policy under the sensitive-operation or session-security settings. Depending on the release and org configuration, it may show options such as:

    •  None 
    •  Block access 
    •  High Assurance required 
    •  Raise the session level with step-up authentication 

    Salesforce is making parts of the report-export step-up framework mandatory, so the option may be enabled automatically, locked, or scheduled for enforcement.  

     

    Regarding whether or not you can you eliminate the second screen: 

     

    For report exports governed by Salesforce’s new step-up framework, probably not. Enforcing phishing-resistant authentication through Entra does not currently cause Salesforce to accept the Entra challenge as the verification for this Salesforce-controlled export action.

    The practical approach is to:

    •  Continue using Entra passkeys for the initial SSO login. 
    •  Register the same device’s platform passkey directly in Salesforce, where supported. 
    •  Educate users that report exports may require a separate Salesforce verification. 
    •  Restrict report-export permissions to users who genuinely need them. 
    •  Check Setup → Identity Verification History to confirm that the second challenge is being recorded as a Salesforce step-up event. 

    I would also open a Salesforce Support case and explicitly ask:

     

    That said, based on Salesforce’s current published guidance, the answer appears to be that

    external IdP MFA cannot satisfy this particular step-up requirement. 

Escrever uma resposta...
0/9000
Ayu P
21 de mai., 05:05
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 *

7 respostas
  1. Kathleen Dell (Northwestern University)
    22 de jul., 20:36

    As of July 16 Salesforce is no longer accepting the 'multipleauthn' as a valid MFA claim.  We have an EntraID/DUO SSO setup as well and our users are now being prompted for additional MFA in the Salesforce UI.  Has anyone figured out a way to get an approved claim passed back to Salesforce?

Escrever uma resposta...
0/9000
Bhavin Patel (Community Experience Manager na Salesforce) publicou em Communications & Readiness Connect
7 de mai., 15:20

*** 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 comentários
Escrever um comentário...
0/9000
Anthony Lullo (Solution Architect na Topco)
24 de jun., 16:11
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 respostas
  1. Eric (Moonpie) (.)
    30 de jun., 15:45

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

Escrever uma resposta...
0/9000
Bhavin Patel (Community Experience Manager na Salesforce) publicou em Communications & Readiness Connect
19 de jun., 12:22

*** 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 comentários
  1. Joanna Lloyd (Bridge Communities)
    29 de jun., 17:11

    @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)

Escrever um comentário...
0/9000
Voonna Meghana (Student na Raghu Engineering College)
20 de abr., 11:02
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 respostas
  1. Jenni Killmer (Voya Investment Management)
    25 de jun., 14:18

    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. 
Escrever uma resposta...
0/9000
Gail Flowers
14 de mai., 21:02
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 respostas
  1. shefali tanwar (Trail Guild)
    18 de jun., 08:15

    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.

Escrever uma resposta...
0/9000