The Privileged User Audit Most Orgs Aren’t Going to Like

By Justin Seaman, IT Manager, and Jory Cohen, Development Director

Salesforce starts enforcing phish-resistant MFA in sandboxes on June 22 and in production on July 1. Every privileged user — System Administrator profile, or anyone with Modify All Data, View All Data, Customize Application, or Author Apex — has to register a security key, Touch ID, Windows Hello, or Face ID before that date. Authenticator apps and SMS don’t satisfy the requirement. There is no on-platform bypass. If admins don’t take the appropriate steps, locked-out users will have to open a Salesforce Support case and wait.

That’s the visible problem, but not the most impactful one.

The real impact comes from the audit that uncovers which users have access to what permissions. Last week we ran a Health Check for a client. It came back green. Then we reviewed their permission set assignments end-to-end. We found three Modify All Data grants nobody on the admin team could explain. An integration user no one had touched in a year. A consultant who’d been gone eight months, still active and with a permission set granting Modify All Data privilege.

The pattern is consistent across every org we’ve scanned: admins are under-counting their privileged users by three to five times. Most of the gaps are invisible when you only look at the profiles people are assigned. They hide in permission sets and permission set groups, in integration accounts that were stood up during implementation and never cleaned up, in dev and QA logins that get sandbox-only privileges in theory and production privileges in practice.

A common pushback: “We use SSO, so this doesn’t apply to us.” Here’s the catch. Salesforce reads the authentication signals coming from your SSO — Microsoft Entra ID, Okta, Ping, and so on. If your Entra or Okta Conditional Access policy doesn’t enforce a phish-resistant authentication strength for your Salesforce-bound app, those privileged users get challenged again at the Salesforce layer — and blocked if they can’t satisfy it. SSO doesn’t exempt you from the requirement. It just changes where you have to configure it.

The fix itself isn’t complicated. Two checkboxes in Salesforce Settings can prevent privileged users from getting locked out, and for SSO orgs, a Conditional Access policy that asserts phish-resistance will make the login process seamless. What takes time is the audit before that. Building the queries to identify who needs to enroll. Identifying integration users who need a bypass, which requires submitting justification in a Salesforce case. The decision on whether the remaining consultants actually need phish-resistant MFA or should just have their permissions trimmed.

Don’t wait to have these conversations and decisions until it’s too late and you are locked out of the org along with the rest of your admins. Use the deadline as an opportunity to audit and strengthen your security before it forces the issue.

The enforcement is the forcing function, and ForeFront’s MFA Readiness Scan is the value. The teams that come out of this in good shape will be the ones that used the deadline as a reason to read their permission set assignments end-to-end — probably for the first time since their original implementation. Don’t get bogged down in manual SOQL queries or building one-off reports before the deadline. ForeFront’s MFA Readiness Scan skips straight to the actionable insights your admins need to keep your company secure.