Salesforce is introducing a stronger login security requirement for users with privileged access. From July 1, 2026, production environments will start moving to phishing-resistant multi-factor authentication for Salesforce admins 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 starts on June 22, 2026, staggered over approximately 7 days. Production enforcement starts on July 1, 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.
What is phishing-resistant MFA?
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 admin access;
- IT users who support Salesforce;
- some integration support accounts where humans log in through 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 admin may not be able 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 may lose confidence in the system at a critical moment.
The requirement itself is a security improvement, but it needs preparation.
Why this matters for mission-driven organisations
Nonprofits, 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 minimum, every organisation should have more than one administrator who can successfully log in with a compliant method. This avoids a single point of failure.
How TwoPurpose can support
TwoPurpose can help organisations prepare in a practical and controlled way. We can review your Salesforce users, identify who is likely to be affected, check current MFA settings, advise on the best verification method, and support 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.
Recommended next step
Do not wait until enforcement reaches your org. Review your privileged users now, decide which phishing-resistant method they will use, and complete testing before the production rollout begins on July 1, 2026.
If you are unsure whether your Salesforce org is ready, 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.
