The MFA Scramble

Unless you've been willfully ignoring the panic-inducing messages from Salesforce, you've probably gotten an inkling that sometime this summer admins are going to be required to authenticate using "phishing-resistant" multifactor authentication (MFA). Most importantly, this means admins will not be able to use the Salesforce Authenticator app, you'll need something stronger..

Everyone else in your org will still be able to use Authenticator (or equivalents), but not admins. In fact, if you haven't already been requiring it (and you should be), they're going to be forced to use MFA from now on. There are some other changes as well, particularly that people will be forced to re-authenticate themselves before taking actions that could be used for mass exfiltration of data, like running or exporting a report.

It's the admin MFA change that's getting the most attention, though, and for understandable reasons. Enormous amounts of "ink" have already been spilled in discussions so I don't think it makes sense for me to rehash the whole issue. If you are interested, you won't have trouble finding threads on Ohana Slack, Trailblazer Community, or the Partner Community, I have no doubt. (I've been in at least four overlapping conversations in different channels.) And if you're not that interested, that's OK too. You just have to make sure you (or your org's admin) take the required steps to avoid any difficulties. I'll make those steps clear below.

Who's an Admin?

In case you were wondering, the "admins" that will need the elevated MFA are defined pretty much as we would expect. Without any intent to make a comprehensive list and acknowledging that Salesforce could change this, they're basically saying it's going to be either those on the standard System Administrator profile [Duh.], or those with the permissions Modify All Data, View All Data, or Customize Application. (It's my working assumption that those are OR, not AND conditions.) I don't know if they mean anyone who has a profile with those permissions or if getting those permissions via a permission set also ups you to needing phishing-resistant MFA.

If you're reading this blog, how about we just assume this is going to apply to you?

Pain for Partners

I want to give credit to Hayley Tuller for writing a great summary of the phishing-resistant MFA issue. As she notes, this change is going to be particularly difficult for consulting partners. It's been standard practice for years that those partners would share a login by storing credentials in a shared vault (like LastPass or 1Password), which could even handle sharing the MFA. It's much easier (and more cost-effective) than expecting the client organization to dedicate a full license for each employee of the consultancy that might need to log in to help with some admin tasks. That looks like it's going to be impossible going forward. Organizations will have to either figure out activating and deactivating licenses or Salesforce may need to work out a consultant licensing situation similar to the free integration users. The latter idea, if it were even considered, would take time for the company to implement. So change is coming, and quite soon.

Fortunately for me, as a solo consultant, this won't make a difference. I have individual named licenses in each of my client orgs. (And in the cases where I use subcontractors, so do they.) But I certainly understand the challenge this will present for consultancies.

I assume that any employee of Salesforce that gives it a moment's thought also recognizes this particular part of the challenge. But the company, in all of their communications to date has resolutely refused to acknowledge how this will affect partner operations, much less hint at any strategies to mitigate the disruption. That's not winning them any hearts and minds.

A Few Easy Steps

Let's turn now to what you need to do. It's really not that hard.

Prerequisites

You are going to be creating passkeys, a cryptographic key that is stored on your device (or in a secure vault) so it can't be stolen. This means that you need a way to generate a passkey and a place to store it. You almost certainly have this either built into your computer and operating system or through a password manager app. I am on a Mac and can easily create and store passkeys in the Passwords app, which stores them in Keychain. Your situation may be different, but mostly in name.

As far as I can tell, you do not need a biometric authentication device to be able to create a passkey. So don't worry if your computer doesn't have a fingerprint sensor or the ability to log in with your face, like your phone can. I verified that I could create a passkey on my Mac Mini that uses a keyboard that does not have a fingerprint sensor.

1. Enable Built-In Authenticators

This one is barely worth me writing it out because the relevant Help article is short and to-the-point. But I won't make you navigate away:

• Go to Setup> Identity> Identity Verification. (Just type "identity" into the Quick Find.)

• Check the box next to "Let users verify their identity with a built-in authenticator such as Touch ID or Windows Hello."

  • Note: If you want to let people use a physical security key (often called a "Yubikey," though that's just one brand), this is the place to enable that. It's the setting right below.

• Save the settings.

2. Register a Built-In Authenticator for Yourself

Again, there's a Help article about this, but it's longer and harder to skim. So:

• Go to your personal user settings. You can get to these settings in either of two places:

  • From the front end of Salesforce, click on your profile picture (or Codey's face, if you haven't uploaded a picture)> Settings> Advanced User Details and scroll down (or use the quick links at the top) to Built-in Authenticators.

  • From within Setup, go to your User record. Scroll down (or use the quick links at the top) to Built-in Authenticators.

• Now click Add.

• You'll get an MFA challenge from your current MFA method (presumably Salesforce Authenticator).

• Then follow the prompts to create a passkey, name it, and save it wherever you store these kinds of things. (I store mine in Apple Keychain.)

Note: I chose not to include screenshots of the process for registering and saving a passkey because I have to assume those screens look a bit different depending on browser, operating system, passkey vault, and maybe even other factors. For me, on a Mac with Touch ID, the process was pretty self-explanatory. I expect it's pretty clear with Windows Hello as well.

And one more note: I did this process with my Macbook closed the whole time and I have an older external keyboard that has no Touch ID sensor. So while I was "using a Mac with Touch ID," I never actually used a fingerprint sensor.

3. Moment of Truth

This is the panic moment:

• Log out.

• Ensure that you're able to log back in.

If you're not the only admin at your organization, you might give the other admin(s) a heads-up that you're doing this so that if you get locked out, they're available to help you. You shouldn't have any problems, but it can't hurt to have a backup plan.

I went through and did this for myself for all the orgs I work with several weeks ago. It took probably less than two minutes per org, including logging in, making the Identity Verification change in Setup, registering my new passkey, logging out, and then logging back in.

What's Different?

Your setup may vary, but I've actually found this to be much more convenient than Salesforce Authenticator. I no longer have to fish my phone out of my pocket to verify a login nor to wait for the location-based auto-approval (when it works). I can do it all on my computer. (And when my laptop is closed because I'm plugged into an external keyboard and monitor I don't even have to use Touch ID or take any action other than a click. That seems odd to me, but I'm not complaining!)

Unknowns

I don't know what will happen when it's time to get a new device, if my laptop dies, or I just decide to upgrade. My recollection is that Salesforce mentions device-specific passkeys. (See Haley's article for more on this.)

As of this writing, I can confirm, after trying this a few times, that I am able to log on from my "personal" Mac Mini to an org using a passkey that was generated on my work laptop and that is stored in my Apple Keychain. So at least for now (and maybe this will change with the restrictions that roll out in July, or maybe it will change at any moment) the passkey was able to be used on a different device, as long as that device was logged into my same iCloud account, thus giving it access to the passkeys in my Keychain. I'm not a security expert, but that actually feels pretty reasonable to me. I would very much appreciate it if Salesforce kept this state of affairs.

I definitely have a fear that even though it's stored in Keychain and in some way "available" across all my Apple devices, Salesforce passkeys will stop working from a different device than they were created on. We seem to have gotten some confirmation from Salesforce that they are going to allow stored/synced passkeys like this. But I would call the confirmation provisional or not-guaranteed, for the moment.

So if (or when) it becomes the case that passkeys can't sync across devices, I think that would mean that to migrate to a new computer I would need to un-register the passkey while logged in from my old computer, then log in on the new computer, then register a new passkey. Or maybe it will be possible to register a second one (on the new computer) and then subsequently delete the old one? Surely you'd need to be able to do something like this if you regularly worked from more than one computer...?

All this is to say that passkeys could make transitions to a new computer more challenging, especially if your transition is sudden, like if your laptop is run over, or stolen, or you pour lemonade on it during a Community Sprint...

In that case, you may need another admin to go to your user record and unlink the built-in authenticator so that you can start fresh. (Similar to what happens when users get a new phone.) If there's no other admin available, you'll probably need help from Salesforce Support.