Salesforce is introducing a stronger login security requirement for users with privileged access. From 1 July 2026, production environments will begin transitioning to phishing-resistant multi-factor authentication for Salesforce administrators and other users with elevated permissions.
For many organisations, this will not affect every user. However, it can directly affect the people your organisation depends on to keep Salesforce running: administrators, advanced users, consultants, developers, and in some cases integration or IT support users.
For nonprofits, charities, membership organisations and healthcare-related teams, this is an important moment to review access. Salesforce often contains sensitive operational information: donor details, member records, case information, care-related data, volunteer information, finance processes, grant management, reports, and integrations with other systems. The users with the highest level of access are therefore also the users who need the strongest protection.
What Salesforce has announced
Salesforce has announced that phishing-resistant MFA will be enforced for users with privileged Salesforce access. This includes users with the System Administrator profile and users with powerful permissions such as Modify All Data, View All Data, Customize Application, or Author Apex.
Sandbox enforcement begins on 22 June 2026, staggered over approximately 7 days. Production enforcement begins on 1 July 2026, staggered over approximately 30 days.
This means your exact production enforcement date may fall somewhere during the July rollout window. Organisations should not wait for the precise moment of enforcement. The safest approach is to identify affected users and complete setup before the production rollout begins.
Phishing-resistant MFA is a type of multi-factor authentication (MFA) that is designed to be highly secure against phishing attacks. This means that even if a user is tricked into revealing their username and password to a malicious actor, the attacker will still be unable to gain access to their account because an additional, phishing-resistant authentication factor is required. There are several types of phishing-resistant MFA, including: * **Hardware security keys:** These are small USB devices that generate unique, one-time codes or use public-key cryptography to authenticate users. They are considered highly secure because they cannot be easily duplicated or intercepted by phishing attempts. Examples include YubiKey and Google Titan Security Key. * **Biometrics:** This includes methods like fingerprint scans, facial recognition, or iris scans. While convenient, the security of biometrics can vary, and some forms are more susceptible to sophisticated attacks than others. * **FIDO2/WebAuthn:** This is a set of open standards that allow for strong authentication using hardware security keys, biometrics, and other device-based authenticators. It is designed to be phishing-resistant by design. Key characteristics of phishing-resistant MFA include: * **Verifiable user presence:** The user must be physically present to complete the authentication. * **Binding to the origin:** The authentication credential is cryptographically bound to the specific website or application, preventing it from being used on a fraudulent site. * **No shared secrets:** It doesn't rely on secrets that can be easily phished or stolen, like SMS codes or one-time passwords (OTPs) sent via email or text. OTPs are generally *not* considered phishing-resistant because they can be intercepted. By implementing phishing-resistant MFA, organisations can significantly reduce the risk of account compromise due to phishing attacks, which remain a prevalent threat.
Multi-factor authentication adds an extra check when someone logs in. Standard MFA methods include mobile authenticator apps or push notifications. These are useful, but some can still be vulnerable to advanced phishing attacks.
Phishing-resistant MFA uses methods that are more strongly tied to the real login session and device. In Salesforce, this means methods such as:
- built-in authenticators, including Touch ID, Face ID, or Windows Hello;
- physical security keys based on WebAuthn or FIDO2 standards.
Salesforce also refers to these methods as passkeys.
Who is likely to be affected?
The requirement mainly applies to users with the most powerful access in Salesforce. These are users who can view or change large amounts of data, update configuration, manage automation, or work with code.
Examples include:
- Salesforce administrators;
- internal CRM managers;
- advanced users with broad data permissions;
- developers;
- Consultants with administrative access;
- IT users who support Salesforce;
- Some integration support accounts allow humans to log in via the user interface.
Most regular day-to-day users are not expected to be affected by this specific phishing-resistant requirement unless they also have elevated permissions.
What could happen if you do nothing?
If an affected user does not have a compliant method registered when enforcement reaches your org, that user may be blocked from logging in until they complete registration.
For an organisation that relies heavily on Salesforce, this can create operational risk. For example:
- An administrator may be unable to support users.;
- urgent changes to campaigns, reports, or automations may be delayed;
- data management tasks may be interrupted;
- integrations or support processes may take longer to resolve;
- Internal teams might lose faith in the system at a crucial moment.
The requirement itself is a security improvement, but it needs preparation.
Why this matters for mission-driven organisations
Non-profit organisations, charities, membership organisations and healthcare-related teams often work with sensitive and trusted data. This can include information about donors, beneficiaries, members, volunteers, patients, care professionals, campaigns, grants, services, or financial processes.
A compromised administrator account can have a much larger impact than a compromised standard user account. It can expose sensitive data, change system configuration, interrupt reporting, or affect connected processes.
Phishing-resistant MFA helps reduce this risk by making it harder for attackers to gain access through stolen passwords, fake login pages, or intercepted verification codes.
What organisations should do now
The first step is to identify who is in scope. This means reviewing users with the System Administrator profile and the permissions Modify All Data, View All Data, Customize Application, and Author Apex.
The second step is to confirm how those users log in. If they log in directly to Salesforce, they should register a phishing-resistant method in Salesforce. If they log in via Single Sign-On, the Identity Provider setup should be checked to make sure Salesforce receives the correct signal that phishing-resistant MFA was used.
The third step is to test. At a minimum, every organisation should have more than one administrator who can successfully log in using a compliant method. This avoids a single point of failure.
How TwoPurpose can help
TwoPurpose can help organisations prepare in a practical and controlled manner. We can review your Salesforce users, identify who is likely to be affected, check current MFA settings, advise on the best verification method, and provide support with registration and testing.
For organisations using Single Sign-On, we can work with your IT team or Identity Provider administrator to clarify whether additional configuration is needed.
Suggested next step
Don't wait until enforcement reaches your organisation. Review your privileged users now, decide which phishing-resistant method they will use, and complete testing before the production rollout begins on 1 July 2026.
If you are unsure whether your Salesforce organisation is ready, please contact TwoPurpose. We can help you assess the impact and prepare your users before access becomes urgent.
Need help checking your Salesforce MFA readiness? Contact TwoPurpose for a quick access and security review.
