Step-Up Authentication in Salesforce Marketing Cloud: What Changed

On July 30, 2026, Salesforce switched on step-up authentication for Security Settings in Marketing Cloud Engagement. In plain terms, every save you make under Setup → Settings → Security Settings now triggers a fresh identity check, even when your session is already open. This isn't optional, and there's no compensating control to bypass it inside MCE. It looks like a minor interface tweak, but for CRM and marketing operations teams the operational impact is real. This article breaks down exactly what Salesforce turned on, how the rollout is staged by release group, and how to prepare your admins so a security save never turns into a lockout at the worst possible moment.

What Salesforce turned on July 30, 2026

Step-up authentication is an extra verification layer required before certain sensitive actions. The logic is straightforward: an open session is no longer proof that you are the person authorized to change critical settings. Before you can save a change on the Security Settings page, Salesforce asks you to confirm your identity again, typically through your multi-factor authentication (MFA) method.

The scope is deliberately tight. Any action taken under Setup → Settings → Security Settings can raise a re-verification challenge. That includes IP allowlists, password policies, session timeout values, and login settings — precisely the levers an attacker tries to manipulate once they've hijacked a session.

The rollout timeline

The rollout is staged by release group. Enforcement began on July 30, 2026 and continued through August 5; R1 orgs, for example, flipped over on August 3, 2026. One detail matters here: re-verification applies to direct logins first. Enforcement for federated SSO flows comes later, which means your environments won't all behave the same way during the transition window.

Why this change, and why now

The tightening is part of a broader Salesforce security overhaul in 2026, alongside expanded MFA and the push toward phishing-resistant methods. It's zero-trust thinking applied to high-impact actions: a session is no longer trusted on the strength of its age alone.

The threat model is well understood. A stolen session cookie, an unlocked workstation, or a compromised machine lets a third party act under a legitimate identity. By demanding fresh proof of identity at the exact moment of the change, Salesforce neutralizes stale or hijacked sessions before they can be used to open a breach — for instance, by quietly adding a malicious IP range to your allowlist.

Step-up authentication doesn't stop the initial intrusion. It stops an already-compromised session from turning stolen access into a durable configuration change. Think of it as a last line of defense on your most sensitive settings.

What actually triggers a re-verification

Any save on the Security Settings page can raise the challenge. In practice, your admins will hit it during operations like these:

Adding, editing, or removing an IP range in the allowlist.
Changing password complexity or expiration rules.
Adjusting session lifetime or idle-timeout values.
Tuning login settings and MFA requirements.

If the admin in question doesn't have an MFA method properly enrolled, the risk is concrete: the challenge can become a hard stop. That's why you want to confirm enrollment before the need to change a setting shows up as an emergency.

Preparing your teams and your access

The good news is that this change is easy to prepare for in a handful of concrete steps. Here's the playbook we recommend to our clients.

Audit roles and administrators

Start by mapping who actually holds rights over Security Settings. Least privilege applies: the fewer admins you have, the smaller your attack surface. You can pull the list of users and their roles through the Marketing Cloud REST API.

// 1. Get a token via your installed API package (Server-to-Server)
POST https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
Content-Type: application/json

{
  "grant_type": "client_credentials",
  "client_id": "YOUR_CLIENT_ID",
  "client_secret": "YOUR_CLIENT_SECRET",
  "account_id": "YOUR_MID"
}

// 2. List the users in the Business Unit
GET https://YOUR_SUBDOMAIN.rest.marketingcloudapis.com/platform/v1/users
Authorization: Bearer {access_token}

Cross-reference the results against assigned roles. Any inactive, generic, or shared admin account should be disabled or converted into a named account with MFA.

Verify MFA enrollment for every admin

Make sure every admin who might touch Security Settings has an active, up-to-date MFA method — an authenticator app, a security key, or a phishing-resistant method. Document a break-glass procedure so a lost device can't lock you out of your own tenant.

Federated SSO: what comes next

If your admins sign in through an identity provider (federated SSO), step-up isn't enforced on those flows yet — but it will be. Get ahead of it by confirming your IdP can trigger a re-authentication (for example, through a reauth policy) so the extension doesn't catch you off guard.

The blind spots to watch

Three points deserve extra attention. First, automations: step-up targets human actions in the UI, but it's no substitute for auditing your Server-to-Server integrations, which remain a prime target. Second, internal documentation: if your change-management runbooks don't mention re-verification, your teams will lose time staring at an unexpected challenge. Third, multi-BU coordination: in a multi-Business-Unit architecture, activation dates can vary by release group, so centralized tracking pays off.

Going further, a security review of your SFMC tenant is often the right moment to rationalize roles, clean up dormant integrations, and harden your IP lists. If you'd like a hand with any of this, our team is reachable through our contact form.

Key takeaways

1. It's already live. Since July 30, 2026, any change to Marketing Cloud Engagement Security Settings requires fresh identity verification, with no bypass available inside MCE.

2. A targeted scope. IP lists, password policies, session durations, and login settings are all in scope — the exact levers attackers go after.

3. MFA first. Confirm every admin has an active MFA method before you need it, and keep a documented break-glass account.

4. Federated SSO is coming. Step-up will extend to SSO flows: configure your identity provider now rather than later.

5. A chance to audit. Use the moment to enforce least privilege, cut the number of admins, and secure your Server-to-Server integrations.