Salesforce Security Monitoring: The 5 Changes That Put Your Org at Risk

Salesforce security monitoring: the 5 configuration changes that put your org at risk, what they look like in the Setup Audit Trail, and how to catch them.

Not every Salesforce configuration change carries the same risk. A renamed list view is not the same as a disabled MFA requirement. A new custom field is not the same as a modified session timeout policy.

Salesforce security monitoring starts with knowing which changes matter most. The problem is that in the raw Setup Audit Trail, every change looks identical: a timestamp, a user, an action, a section. Without context, a Critical security change and a routine cleanup task appear side by side with no visual distinction.

This post covers the five specific security changes that carry the highest real-world risk in Salesforce orgs, what they look like in the Setup Audit Trail, and what you should do when you see them.

Why Security Configuration Changes Are Different

Most Salesforce changes are additive: a new field, a new flow, a new permission. If something goes wrong, users are affected, but the org itself is not compromised.

Security configuration changes are different. They affect who can access the org, how they authenticate, what they can do once inside, and how much data they can see. The wrong security change does not just break a business process. It can expose customer data, enable unauthorized access, or create a persistent vulnerability that goes undetected for months.

Salesforce is enforcing five mandatory security changes in 2026: email domain verification by April, MFA requirements by June, phishing-resistant authentication for admins, IP restriction policies, and auto-enabled data export policies. The fact that Salesforce has to enforce these mandatorily tells you something: many orgs were not applying them voluntarily.

Monitoring for security configuration changes is not optional in a mature Salesforce environment. Here are the five changes that should trigger an immediate response.

1. Multi-Factor Authentication Requirement Disabled or Modified

What it is: MFA requires users to provide a second authentication factor (Salesforce Authenticator, a time-based one-time password, or a hardware security key) in addition to their username and password. Disabling or weakening MFA requirements removes this layer of protection.

Why it's dangerous: Username and password combinations are routinely compromised in phishing attacks, credential stuffing campaigns, and data breaches at other services where users reused passwords. MFA blocks the vast majority of these attacks even when credentials are exposed.

The attack path without MFA: attacker obtains credentials from a phishing email or a credential database breach, logs in to Salesforce directly, and has full access with whatever permissions that user holds. With MFA in place, the attacker still needs the physical device.

What to look for in the Audit Trail:

In the Setup Audit Trail, MFA requirement changes appear under the Security Controls section. Relevant action descriptions include changes to "Multi-Factor Authentication" settings, "Session Settings," or "Identity Verification." The Display field will contain a plain-English description of what changed.

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'Security Controls'
AND (Display LIKE '%Multi-Factor%' OR Display LIKE '%MFA%' OR Display LIKE '%Session%')
ORDER BY CreatedDate DESC

What to do: Any change to MFA settings requires immediate review. If MFA was disabled or weakened, determine whether it was intentional (rare and requires documented justification) or unauthorized. Check whether the change coincides with any unusual login activity.

As of 2026, Salesforce requires MFA for all users. Any configuration that relaxes this requirement should be treated as a Critical finding.

2. Login IP Range Removed or Expanded to 0.0.0.0/0

What it is: Salesforce allows you to restrict which IP addresses can log in to the org. When Login IP Ranges are configured, users can only authenticate from approved networks. Removing these restrictions opens the org to authentication attempts from any IP address in the world.

Why it's dangerous: IP restrictions are one of the most effective controls for preventing unauthorized access, particularly from locations outside your company's offices or VPN. Without them, a user with compromised credentials can log in from anywhere.

The specific risk that many admins underestimate: even if SSO and MFA are configured, Salesforce may allow local username/password logins as a fallback. If a user's Salesforce-native password is set and IP restrictions are removed, that local credential becomes a viable attack path that bypasses your identity provider entirely. Security researchers have documented this "IdP bypass" pattern specifically in Salesforce orgs.

What to look for in the Audit Trail:

IP range changes appear under the Security Controls section with action descriptions referencing "Network Access" or "Login IP Ranges."

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'Security Controls'
AND (Display LIKE '%IP%' OR Display LIKE '%Network Access%' OR Display LIKE '%Login IP%')
ORDER BY CreatedDate DESC

What to do: If IP ranges are removed entirely or expanded to include 0.0.0.0/0 (all IPs), treat it as a Critical change. Confirm it was intentional and documented. If remote workers need access, the correct approach is requiring VPN, not removing IP restrictions entirely.

3. Single Sign-On Configuration Modified

What it is: SSO integrates Salesforce authentication with your corporate identity provider (Okta, Microsoft Entra, Google Workspace, etc.). An SSO configuration change can modify which provider is trusted, what the certificate validation settings are, or whether users can bypass SSO and use local Salesforce credentials.

Why it's dangerous: SSO configuration changes can introduce authentication gaps that allow users to bypass your identity provider and its associated controls (MFA, conditional access policies, device compliance checks). They can also allow the addition of a rogue identity provider that accepts attacker-controlled assertions.

A specific risk: if "Just-in-Time (JIT) provisioning" settings are modified, attackers may be able to create new Salesforce users on the fly through a compromised identity provider without admin intervention.

What to look for in the Audit Trail:

SSO changes appear under the Identity or Single Sign-On Settings sections.

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section IN ('Identity', 'Single Sign-On Settings')
ORDER BY CreatedDate DESC

What to do: SSO changes should always be planned, tested in a sandbox, and deployed through your change management process. An unplanned SSO change in production is a high-priority incident. Verify the change matches your identity provider's current configuration and that all users can still authenticate correctly.

4. Connected App OAuth Settings Changed

What it is: Connected Apps define how external systems and third-party tools authenticate to Salesforce via OAuth 2.0. Their settings control which users can authorize the app, what OAuth scopes (permissions) the app is granted, and where it is allowed to redirect after authentication.

Why it's dangerous: A connected app with overly broad OAuth scopes can expose your entire org to a third-party tool without the data access being obvious to admins or users. Changes to connected app settings can also expand an existing integration's access far beyond what was originally intended.

More specifically: if "All Users May Self-Authorize" is enabled on a connected app, any user in your org can connect that application to their Salesforce account. If that application is malicious or compromised, it gains an OAuth token with the permissions of every user who has authorized it.

What to look for in the Audit Trail:

Connected App changes appear under the OAuth section.

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'OAuth'
ORDER BY CreatedDate DESC
LIMIT 50

Also watch for new Connected App installations, which may appear as new records without a preceding review or approval.

What to do: Review the change against your register of approved integrations. If a connected app you do not recognize was added or modified, investigate immediately. Verify the OAuth scopes are appropriate for the integration's stated purpose (principle of least privilege).

5. Session Security Settings Weakened

What it is: Salesforce session settings control how user sessions are managed: how long sessions last before requiring re-authentication, whether sessions are locked to the IP address they were created from, whether HTTPS is required, and whether concurrent sessions are allowed.

Why it's dangerous: Session settings that are too permissive make it easier for an attacker who has obtained a session token to maintain persistent access to the org. For example:

  • A very long session timeout (24 hours or more) gives an attacker whose phishing page captured a session token an extended window of access
  • Disabling "Lock sessions to the IP address from which they originated" allows session tokens captured on one network to be replayed from another network
  • Disabling HTTPS for session security allows session tokens to be captured in transit on unsecured networks

What to look for in the Audit Trail:

Session setting changes appear under Security Controls.

SELECT Action, Section, CreatedDate, CreatedBy.Name, Display
FROM SetupAuditTrail
WHERE Section = 'Security Controls'
AND Display LIKE '%Session%'
ORDER BY CreatedDate DESC

What to do: Compare the changed settings against your security policy. Salesforce's Health Check tool provides a baseline recommendation for session settings. Any deviation below the recommended baseline should be documented with a business justification.

Building Automatic Detection for All Five

Manually querying the Setup Audit Trail for each of these change types is a starting point, but it requires daily discipline and can still miss changes that happen on weekends or holidays.

The more reliable approach is continuous monitoring: a system that queries your SetupAuditTrail on a regular schedule, evaluates every change against a severity framework, and notifies you automatically when a Critical or High change appears. See How to Monitor Salesforce Org Changes for a step-by-step guide to building that routine.

AuditForce does this automatically. Every setup change is evaluated against a configurable rules engine that maps Section values and Action patterns to severity levels. All five change types covered in this post are classified as Critical by default. When any of them appear, you receive an immediate alert rather than finding out in the next morning's digest.

The rules engine is configurable: if your org has specific integrations or administrative patterns that produce false positives for a particular rule, you can adjust the classification without losing coverage for everything else.

The Posture to Build

Security monitoring is not a one-time exercise. It is a continuous practice.

Set a reminder to review Security Controls changes in your Setup Audit Trail every morning. For any change that touches MFA, IP restrictions, SSO, connected apps, or session settings, ask one question: was this planned?

If the answer is yes, verify it matches what was planned. If the answer is no, treat it as an incident until you can prove otherwise. The five changes covered in this post are too consequential to assume benign.