This is a story of a smooth MFA transition. Smoother than what we all thought possible. And as with any story we shall start with…
Once upon a time, my colleague Mike (aka Agent Gill) and I were working on a project that involved a transition to Azure Active Directory for email client and SSO across applications. This time, we had the privilege of working on this project with yet another Salesforce MVP Hall of Fame member, Natalie Gunther.
Natalie championed the enablement of Salesforce MFA with Azure Active Directory set up as SSO for a Salesforce internal app, so we knew we were in good hands, especially as she emphasised the importance of testing this; as with anything related to authorisation… well, it can get messy!
Thank you Natalie for what I think is one of the smoothest Salesforce MFA enablements ever turned around! We thought that this pleasant (and honestly, unexpected) experience was worth sharing with others who may be facing similar transitions. So, we asked Natalie to share her insights, preparation, and steps with us.
In the this post, Natalie will walk you through the process, share her best practices, tips, and lessons learned from this. We hope you enjoy the ride!
Salesforce’s Latest MFA Release: Our Testing and Review
Salesforce’s latest multi-factor authentication (MFA) release has been highly anticipated by the user community, as it promises to provide an additional layer of security to safeguard against unauthorised access. In this post, I’ll be sharing our experience testing this new feature and our thoughts on its implementation.
Preparation is Key
We knew that Salesforce was planning to auto-release the MFA feature soon, so we wanted to be prepared. Before the release, we made a list (and checked it twice) of all the systems and logins that we wanted to test, including those for our integrations. It’s important to note that MFA is only supposed to be applied to non-API logins, but we wanted to be sure that our integrations would continue to work without any issues.
Testing in Sandbox
To test the MFA feature, we created a sandbox environment where we could safely run our tests. We kept a couple of users in the exception list, which we did by creating a “Waive MFA” permission set. This allowed us to test the MFA feature on specific users without affecting the rest of the organisation.
- We added a few admins to this permission set.
- We turned on the global setting (in our sandbox).
- We had some users test out logging into the sandbox to see what prompts they got.
- Then we ran through our list of scenarios to test all of our integrations.
- Then we removed this permission set from our Admin so that we could test an admin’s ability to login.
Everything worked perfectly and so we completed the same process in production, testing one by one and then added in the SSO test.
We also have the single sign-on (SSO) feature enabled, so we wanted to see how the MFA would work with it. Our goal was to ensure that the MFA feature would seamlessly integrate with our SSO system and not disrupt our users’ workflow.
- We followed the steps to make sure our Identity Provider was listed in the Session Settings.
- We referenced this article for help: https://help.salesforce.com/s/articleView?id=sf.mfa_sso_thirdparty_idp.htm&type=5. We had no issues with SSO.
- When users used SSO, they were NOT prompted to use or setup an authenticator.
In the end, we found that the MFA feature worked seamlessly. It only prompted users who did not use SSO, and it gave clear instructions on how to set up the MFA feature. We did not experience any integration interruptions, and our users were able to continue working without any significant changes to their daily workflow.
[PRO TIP]: I did have another client who did not want to download the Salesforce authenticator and that prevented them from logging in because they felt the instructions were not clear on how to use a different authenticator like Microsoft or Google authenticator. There is a small link on the bottom, but users may not notice it. Also, it is helpful to let them know, they CAN use other authenticators, but the Salesforce authenticator is nice because it pops up the request when you’re trying to login. This can save them the hassle of opening their authenticator and typing in the key, but the trade off is that they have to download another app on their mobile device.
We would suggest monitoring logins over the months following a go-live implementation to watch out for those users who are frustrated or perhaps didn’t read your preparation emails. You can help catch these by running a login history report and looking for any drop offs after turning on MFA. Login history is limited, so be sure to monitor these right away.
Overall, we are pleased with Salesforce’s latest MFA release. It provides an additional layer of security to our organisation and gives us peace of mind knowing that our systems are more secure. We appreciate that the implementation was smooth and didn’t cause any significant disruption to our organisation. We recommend that other organisations take the time to test the MFA feature and ensure that it works with their existing systems and integrations.
You can also reference Salesforce’s help page for more information: https://help.salesforce.com/s/articleView?id=000389361&type=1.
Have you already transitioned to MFA?
What’s your setup?
How did it go?
Once again, a super special thanks to Natalie for this entry and for her constant strive to better whatever she does. You are a pleasure to work with, from Mike & I.
You can check more of her adventures at: