Salesforce MFA Enforcement Is Breaking Your Integrations: Here’s the Real Fix for Automation Users

If one of your Salesforce integrations, RPA bots, or scheduled jobs suddenly started failing login with an identity-verification prompt it never used to show then you’re not alone, and you’re not doing anything wrong. Salesforce has been tightening its multi-factor authentication (MFA) requirements, and the old trick admins relied on to keep automation users running smoothly has quietly stopped working.

This article explains exactly what changed, why your integration user is getting blocked, what people used to do that no longer works, and more importantly the actual solutions you can implement today, not just a temporary extension from Support.

What Changed: Salesforce’s MFA Enforcement

Salesforce has required MFA for UI logins for a while now, but over the last couple of release cycles it has closed most of the loopholes that let admins quietly exempt certain accounts. Two enforcement waves matter here:

1. MFA for all direct UI logins — every user logging into the Salesforce UI, including service/automation accounts that occasionally log in through a browser-based flow, is expected to complete a second factor.
2. Phishing-resistant MFA (PRMFA) for privileged users — starting in June 2026, any user with the System Administrator profile, or with Modify All Data, View All Data, Customize Application, or Author Apex permissions, is required to use a phishing-resistant verification method meaning passkeys (built-in authenticators like Touch ID/Windows Hello, or physical security keys like a YubiKey). Regular authenticator apps, push notifications, and even TOTP codes no longer satisfy MFA for these accounts once PRMFA is enforced.

Both of these enforcement waves target the same soft spot every org has: the automation user. That’s the service account your middleware, RPA bot, ETL job, or custom integration uses to log in and pull an API session and historically, admins gave it just enough privilege (and just enough exemption) to run unattended, 24/7, with no human around to tap “approve” on a push notification.

Why This Is Breaking Your Integrations

Here’s the practical failure mode most teams are hitting right now:

• A scheduled job or RPA script logs in using a username/password (or username/password + security token) UI-style login flow.
• Salesforce now challenges that login for MFA, exactly like it would a human.
• There’s no human on the other end to approve a push notification, tap a passkey, or read an SMS code.
• The login fails, the job fails, and your integration silently stops syncing data until someone notices.

If your automation user also happens to carry System Administrator or one of the high-privilege permissions listed above, it gets worse after June 2026, Even if you could automate MFA some other way, phishing-resistant methods like passkeys fundamentally can’t be scripted the way a TOTP code can,

The key thing to understand is why one path gets blocked and the other doesn’t , it comes down to whether the login is a UI-style interaction at all:

The Old Workaround (And Why It’s Deprecated)

For years, the standard fix was simple that assign the “Waive Multi-Factor Authentication for Exempt Users” permission to your integration user’s profile or a dedicated permission set, and that account would sail past MFA checks entirely.

That workaround is now effectively retired. Per Salesforce’s own documentation, once MFA enforcement is active in your org:

• Users with this permission are no longer exempted and they get prompted for MFA like everyone else.
• The underlying API field (PermissionsBypassMFAForUiLogins) is removed from the PermissionSet and Profile schema entirely, unless Salesforce Support has specifically granted your org an extension.

Reaching out to Salesforce Customer Support can buy you a temporary extension for a “valid exempt use case,” but it’s explicitly framed as a bridge, not a destination . Salesforce expects you to migrate away from blanket MFA exemptions, not lean on them indefinitely. Renewing a support case every few months is not a integration architecture; it’s a countdown timer.

So what should you actually do instead?

The Real Fix: 3 Ways to Keep Automation Running

1. Programmatic TOTP for automation-only, non-privileged users

Salesforce’s supported path for automation/RPA use cases is to complete MFA challenges programmatically using a time-based one-time password (TOTP) its the same mechanism apps like Google Authenticator use, just automated in your own script.

Here’s the setup, done once per user:

1. Log in to the automation user’s account.
2. Go to personal settings → Advanced User Details.
3. Find App Registration: One-Time Password Authenticator and click Connect.
4. On the QR code screen, click I Can’t Scan the QR Code where Salesforce shows you a plain-text secret key instead.

Copy that key and store it securely (a secrets manager, not a spreadsheet).

Finish connecting the authenticator app using that key.

From there, your integration script generates a fresh TOTP code on every login using that secret where no human interaction needed. Here’s a minimal Node.js example using the open-source “otplib” package:

// npm i otplib
const { authenticator } = require('otplib');

// Store the Base32 secret securely — env var, secrets manager, etc.
// This is the "Key" shown after clicking "I Can't Scan the QR Code"
const TOTP_SECRET = process.env.AUTOMATION_TOTP_SECRET;

function getTotpCode() {
  if (!TOTP_SECRET) {
    throw new Error('Missing AUTOMATION_TOTP_SECRET');
  }
  // 30-second step, 6 digits, SHA1 — otplib defaults match Salesforce's expectations
  return authenticator.generate(TOTP_SECRET);
}

async function completeMfaChallenge({ enterCode }) {
  const code = getTotpCode();
  await enterCode(code); // plug into your own login/UI-automation flow
}

module.exports = { getTotpCode, completeMfaChallenge };

// npm i otplib
const { authenticator } = require('otplib');

// Store the Base32 secret securely — env var, secrets manager, etc.
// This is the "Key" shown after clicking "I Can't Scan the QR Code"
const TOTP_SECRET = process.env.AUTOMATION_TOTP_SECRET;

function getTotpCode() {
  if (!TOTP_SECRET) {
    throw new Error('Missing AUTOMATION_TOTP_SECRET');
  }
  // 30-second step, 6 digits, SHA1 — otplib defaults match Salesforce's expectations
  return authenticator.generate(TOTP_SECRET);
}

async function completeMfaChallenge({ enterCode }) {
  const code = getTotpCode();
  await enterCode(code); // plug into your own login/UI-automation flow
}

module.exports = { getTotpCode, completeMfaChallenge };

2. Move to OAuth flows that never trigger MFA in the first place (recommended long-term fix)

This is the fix most teams should have made years ago, and MFA enforcement is a good forcing function to finally do it: stop authenticating integrations with a username/password UI-style login at all.

MFA enforcement targets UI logins. OAuth 2.0 flows designed for server-to-server, headless authentication like the JWT Bearer Flow or Client Credentials Flow authenticate using a digital certificate or a client secret instead of a username/password combo walking through the login page. Because there’s no interactive UI login step, there’s no MFA challenge to satisfy in the first place.

At a high level, migrating looks like this:

• Create a External Client App with OAuth enabled.
• For the JWT Bearer Flow: generate a certificate, upload it to the app, and have your integration sign a JWT with the corresponding private key on every request to get an access token.
• For the Client Credentials Flow: configure a run-as user for the app, and authenticate using a client ID and client secret.
• Update your integration/middleware to request tokens this way instead of a legacy SOAP/REST login() call with a username, password, and security token.

This is more setup work upfront than flipping on an MFA exemption, but it’s the difference between patching a hole and rebuilding on solid ground your integration stops depending on any MFA policy change ever again, and you get a proper audit trail of API access tied to a named connected app instead of a shared password.

3. Enforce MFA at your SSO identity provider instead

If your org already uses SSO (Okta, Azure , Ping, ADFS, etc.), you have a third lever , your MFA can be satisfied at the identity provider level rather than inside Salesforce. When a user authenticates through an SSO Auth Provider and MFA is properly enforced there, Salesforce doesn’t need to challenge them again on top of it.

For automation users specifically, this is less common (most integrations still authenticate directly via OAuth rather than routing through your corporate SSO), but if your automation identity already lives in your IdP, this can be a viable route then just be sure the profile is configured to require a High Assurance session security level at login, with MFA mapped into that High Assurance tier, so Salesforce actually trusts the IdP’s MFA rather than re-prompting.

Which Option Should You Actually Use?

If you only do one thing after reading this: stop giving automation users System Administrator.

FAQ

Is “Waive Multi-Factor Authentication for Exempt Users” completely gone?
Not gone, but neutered by default. Once your org enforces MFA, the permission stops automatically exempting anyone. Salesforce Support can restore it for specific, valid use cases, but it’s granted as an extension, not a permanent bypass, and the underlying permission field can be removed from your org’s schema entirely if you haven’t requested that extension.

Does JWT Bearer Flow or Client Credentials Flow require MFA at all?
No. These are non-interactive, server-to-server OAuth flows authenticated by a certificate or client secret rather than a UI-style login, so there’s no MFA challenge in the flow to begin with. This is why migrating integrations to these flows is the most durable fix.

What happens if I ignore this and do nothing?
Your automation/integration logins will start failing entirely as MFA enforcement rolls out, and if you’re relying on the old exempt-user permission, a future release can remove the underlying field from your org’s metadata which can break package installs and deployments, not just logins.

Is there a quick, no-code fix for this?
Not really , Support-granted temporary exemption is the closest thing, but it’s explicitly time-limited. There’s no permanent way to keep a UI-style login working indefinitely without either scoping the user down for TOTP or moving to a non-interactive OAuth flow.

Final Thoughts

Salesforce’s MFA enforcement isn’t trying to break your integrations but it’s closing a real security gap that attackers have actively exploited through phished credentials and stolen session tokens. But if your automation strategy was built on the old “Waive MFA for Exempt Users” permission, that gap is closing under you right now, and a Support ticket only buys you time, not a fix.

The durable answer is the same one good integration architecture always pointed to scope your automation users down, and move them off username/password logins onto proper OAuth-based, non-interactive authentication. Do that once, and this entire category of MFA enforcement stops being something you have to think about again.

If you’re auditing your org’s integration users and want a second pair of eyes on the migration plan, feel free to book a 1:1 session and I would be happy to help you map out which of your integrations need re-architecting versus a quick TOTP fix.