Has this happened to you yet?

• A user can’t log into Salesforce because they set up an authenticator app, then changed phones.
• A user can’t log into Salesforce because verification was sent to their phone, but they don’t have it with them/don’t have that phone number anymore.

For some reason, this month has been verification/authentication hell for me. As a fairly advanced admin, I was shocked to discover how little I really knew about how to troubleshoot user login issues! Some things I learned…

Not all authenticator apps are created equal.

There is a Salesforce Authenticator app available in Google Play or the App Store – you can find supported devices and org requirements here. Salesforce Authenticator has some really powerful features, especially version 2 – but is only designed for Salesforce account authentication.

Google authenticator is another commonly used app for Salesforce authentication, but there are many others available. Salesforce allows other authentication app usage, but obviously they are not able to provide support for any issues you may have with those apps. Other authenticator apps can be used for pretty much anything – email accounts, Facebook, Twitter, etc. – and with the danger of account hacking growing every day, I highly recommend using two-factor authentication for everything that you possibly can.

To sever the connection between an authentication app and a user account, the two-factor authentication must be disabled on the User record.

There are two places to do this, depending on the type of authenticator the user has chosen. Look for a link that says Disconnect and click that.

Note: if the user is required to have two-factor authentication, they will be prompted to set it up again the next time that they attempt to log in. To disable this, find the profile or permission set that has “Two-Factor Authentication for User Interface Logins” checked (in System Permissions), and uncheck it.

That “Temporary Verification Code” isn’t a magic unicorn.

Ever try to use this code to solve an identity verification or authentication issue?

That code is a temporary substitute for an authentication code, but will only work if the user is logging in on a recognized device. It will not work on a new device or an unrecognized browser. Now we all know.

As of Spring ‘16, users will be prompted to verify their identity on unrecognized devices even if they log in from an IP address that was authenticated prior to the Spring ‘16 release.

To avoid this situation, follow the steps in this knowledge article.

But what if a user doesn’t have their phone handy? They are trying to log in or reset their password, but they can’t get the verification codes that are being texted to them! Don’t panic. This is easier than you’d think (so I won’t tell you how long it took me to figure it out). Here is the quick & dirty three-step process:

• Delete the number in the Mobile field on the User record.
• Make sure that the user has email verification enabled. This will be in their profile, or in a permission set, in System Permissions, and it is called “Email-Based Identity Verification Option.”
• Make sure that the user is not required to use two-factor authentication. This will also be in System Permissions, in a profile or permission set, and is called “Two-Factor Authentication for User Interface Logins.”

Choose authentication and verification requirements wisely.

As an admin, there are many ways to secure your org with identity verification and/or two-factor authentication, some that your company might not even know are possible. How long has it been since you reviewed your security settings? Is it time for an overhaul? The requirements will vary based on the sensitivity of your data, compliance regulations, etc., but if you have not given serious thought to this lately, it may be worth a discussion.

And if you aren’t sure where to start, there is always this tweetfrom Mark Burnett…