What's changing
Salesforce is enforcing phishing-resistant MFA (PR-MFA) for privileged users, including System Administrators. Standard MFA, SMS codes, authenticator apps like Google Authenticator, or push notifications will no longer be enough for these users.
Enforcement dates:
Sandboxes: 22 June 2026
Production: 1 July 2026
After these dates, any privileged user who hasn't enrolled in a phishing-resistant method will be blocked at the login screen until they do. You can read Salesforce's own guidance here: Prepare for Phishing-Resistant MFA Enforcement for Privileged Users.
Who's affected
A "privileged user" is any user with:
the System Administrator profile, or
any of these permissions (whether via profile, permission set, or permission set group): Modify All Data, View All Data, Customize Application, or Author Apex.
If you connect Gearset using a System Administrator account, that user counts as a privileged user.
Does this break Gearset?
No, your existing Gearset connections will keep working.
Gearset connects to Salesforce using OAuth. When you first connect, you're redirected to Salesforce's own login page to authenticate Gearset never handles your password. After that, your day-to-day work (deployments, CI/CD pipelines, backups) runs through the API using a secure token, and the API isn't affected by this change.
You can read more about how the OAuth connection works here: How does Gearset's OAuth connection to orgs work?
Where it does matter: re-authentication
PR-MFA is enforced at the login step. Gearset triggers a login when you:
set up a new org connection, or
re-authorise an existing connection (for example after an org refresh or a security settings change).
At those points the connecting user logs in through the browser, so PR-MFA applies. As long as that user is enrolled in a phishing-resistant method, the connection goes through and Gearset carries on as normal.
Which methods count
Salesforce accepts:
Built-in authenticators: Touch ID, Face ID, Windows Hello
Passkeys stored in a FIDO2-compliant password manager: e.g. 1Password, Bitwarden, iCloud Keychain
Hardware security keys: e.g. YubiKey (via USB, NFC, or Bluetooth)
What does not count: standard OTP authenticator apps (e.g. Google Authenticator) and push notifications (e.g. Salesforce Authenticator).
Shared service accounts
Many teams connect Gearset with a shared System Administrator account. Passkeys are tied to a device or a vault, so they can't be passed around informally.
The recommended approach is to store a passkey in a shared password manager vault (for example a 1Password shared vault). Anyone with access to the vault can then use it to re-authorise the Gearset connection.
Worth knowing: a passkey stored in 1Password registers in Salesforce as a Built-in Authenticator (the same category as Touch ID) not as a security key or OTP. We've confirmed this works.
A note on exemptions
Salesforce does have an MFA exemption process, but it's only a temporary measure Salesforce has confirmed it isn't a long-term solution.
What to do
Find every privileged Salesforce user you use to connect Gearset (System Admins, or users with the permissions listed above).
Enrol each one in a phishing-resistant method before the enforcement dates
22 June for sandboxes, 1 July for production.
For shared accounts, set up a passkey in a shared vault (e.g. 1Password).
Repeat for each sandbox org used with Gearset.
Once that's done, Gearset's normal operations will continue without any interruption.