From 16 October 2026, Salesforce can freeze an integration user in production in the middle of a sync, without anyone in your team changing a setting. That’s the first of five changes in the October 2026 Salesforce Platform Security Requirement Update, the email Salesforce sent on 14 October to everyone listed as an admin or security contact for an org.
The five changes have very different weight. Two need no work from most teams. One, the new rules for the SOAP API login() call, can quietly break a job that only runs a few times a year. Here’s each one in deadline order, what it means in practice and what I’d check.
If you look after integrations, also read our summary of the Salesforce OAuth security changes for 2026–2027. Salesforce sent those as a separate email, and they cover different login methods.
The five changes at a glance
| Change | Area | Key dates | What you need to do |
|---|---|---|---|
| Suspicious API data access can end sessions and freeze users | Threat Detection | Sandbox 9 Oct 2026; production 16 Oct 2026 | Know how to unfreeze a user; make integrations log in again cleanly |
| Single Sign-On Required permission replaces the legacy SSO setup | Identity | Available 23 Oct 2026 (sandbox), 6 Nov 2026 (production); auto-migration 1–9 Dec 2026 (sandbox), 4–22 Jan 2027 (production) | Usually nothing; review provisioning |
New SOAP API login() requirements, then retirement | Identity | 1 Dec 2026; 15 Dec 2026 (sandbox) and 31 Jan 2027 (production); Summer ‘27 | Find every caller and move it to OAuth |
| Guest users can no longer see most User fields | Experience Cloud | Available Winter ‘27; enforced Spring ‘27 | Test public pages that show user details |
| Guest user access to the GraphQL API | Experience Cloud | Winter ‘27 | Check the default suits your site |
1. Salesforce can freeze users over suspicious API activity
Salesforce now watches how data is read through its APIs. If something looks suspicious, it can end the session, freeze the user and email the org’s admins. After a session ends, the user just logs in again. A frozen user stays locked out until an admin unfreezes them.
This applies to every org except Government Cloud Plus and Government Cloud Plus Defense. It reached sandboxes on 9 October 2026, before the email went out, and production on 16 October 2026. If an integration user was frozen on or after those dates and nobody can explain why, this is a likely cause.
The email doesn’t explain what Salesforce treats as suspicious. My guess is that integration users reading large volumes of data are the most likely to trip it, but that’s a guess, and Salesforce hasn’t said so.
What I’d do:
- Check that the org’s admin email address goes to an inbox someone reads. A freeze notice sitting in a former colleague’s mailbox is how an overnight sync stays broken until Monday.
- Write down the unfreeze steps for whoever supports your integrations: Setup → Users → open the user → Unfreeze.
- Look at how each integration reacts when its session ends. A REST call on a dead session returns
INVALID_SESSION_IDwith the message “Session expired or invalid”. A good client logs in again and retries once. If the user is frozen, that login fails too, so the client should stop and alert someone instead of retrying in a loop.
2. A new Single Sign-On Required permission
Before this change, forcing a user to log in only through SSO took a mix of org-wide settings plus the Is Single Sign-On Enabled permission. Salesforce is replacing that mix with one user permission, Single Sign-On Required, and will move eligible orgs over automatically. Salesforce says no action is needed and it expects no disruption.
Your org is in scope only if it has this exact setup:
- Disable login with Salesforce credentials is turned on
- Delegated Gateway URL is empty
- At least one user has Is Single Sign-On Enabled
If that’s you, those users get the new permission during the migration window: 1–9 December 2026 in sandboxes and 4–22 January 2027 in production. Orgs that use delegated authentication, where a Delegated Gateway URL is set, aren’t part of it.
One thing worth a look afterwards: any provisioning script, permission set group or onboarding Flow that gives Is Single Sign-On Enabled to new starters. The email doesn’t say whether the migration updates that kind of automation, so check it yourself. The knowledge article linked from the email explains what changes after migration.
3. SOAP API login(): new rules before it’s retired
This is the change most likely to cause an outage. The SOAP login() call (API versions 31.0 to 64.0) is retired in Summer ‘27, and three new rules arrive before that.
| Date | Rule |
|---|---|
| 1 Dec 2026 | The user calling login() needs the Use Any API Auth permission |
| 15 Dec 2026 (sandbox), 31 Jan 2027 (production) | login() from a very broad IP range (larger than /8 for IPv4, or /29 for IPv6) needs a security token |
| 15 Dec 2026 (sandbox), 31 Jan 2027 (production) | login() is turned off in orgs with no SOAP login() activity in the last 6 months |
| Summer ‘27 | SOAP login() retired |
You can test the permission rule now through its Release Update in Setup.
The 6-month rule is the one that catches people out. Think of a year-end reconciliation or an annual data export. If nothing in the org has called login() for six months before the cut-off, Salesforce turns the call off, and that job fails the next time it runs. Often nobody notices until the person who needed the output asks where it is.
The IP range rule is less clear. The email doesn’t say which setting it checks. My reading is that it targets trusted IP ranges so wide that the security token stops meaning anything, because a trusted range is what normally lets a login skip the token. Check the knowledge article before you change Network Access or the login IP ranges on profiles.
Salesforce lists third-party and ISV apps, middleware, the Salesforce Connect Cross-Org Adapter and rarely run jobs as the usual callers. To find yours, check two places:
- Login History (Setup → Login History). Look for Login Subtype SOAP API. The Application column usually shows N/A for these.
- The API Total Usage event log. Look for rows with
API_FAMILY = SOAP,API_RESOURCE = loginand an emptyCONNECTED_APP_ID.
To list the event log files through the API:
SELECT Id, LogDate, LogFileLength
FROM EventLogFile
WHERE EventType = 'ApiTotalUsage'
ORDER BY LogDate DESCDownload each file’s LogFile content as a CSV and filter on those three columns. Event log files are only kept for a short time, so use Login History to look back over the full six months.
Giving users Use Any API Auth gets you past 1 December 2026, and that’s all it does. Salesforce’s advice is to move to External Client Apps with OAuth 2.0 now, so you do the work once instead of twice. We covered how to migrate, and which OAuth flow suits which kind of integration, in integration logins failing after the SOAP login() retirement. For packaged apps and middleware, ask the vendor which version stops using SOAP login() and when it’s available.
4. Guest users lose access to most User fields
In Winter ‘27, admins get a separate control for which User fields unauthenticated guests can see. It doesn’t change what logged-in portal users see. In Spring ‘27, Guest User External and Personal Information Management becomes mandatory, and nearly every User field is hidden from guests by default. You then unmask the fields you actually need.
There are two items to find in Setup → Release Updates:
- Independent Guest Field Masking switches on the separate guest control.
- Conceal Personal Information Fields from Guest Users has its own testing and activation steps.
This affects LWR, Aura and Visualforce sites that have the Guest User Profile enabled.
Before Spring ‘27, find the public pages that show anything from a User record. Common examples are a knowledge article’s author, a case owner’s name, or a “posted by” label. Once the change is enforced, those values come back hidden unless you unmask them. Turn on the release updates in a sandbox, browse the site as a guest and see what disappears. Then unmask only what each page needs. For a wider review of guest access, our Experience Cloud guest user hardening checklist walks through the rest of the guest profile.
5. Guest user access to GraphQL becomes a setting
From Winter ‘27, admins can decide in Setup whether unauthenticated guests can use the GraphQL API. The starting value depends on your org’s history:
- New orgs, and orgs where guests haven’t used GraphQL since March 2026: off.
- Orgs where guests have used GraphQL since March 2026: on, so nothing changes for them.
Like the field masking change, this affects LWR, Aura and Visualforce sites with the Guest User Profile enabled.
If your org starts with guest access turned on, find out why. A public LWC that uses the GraphQL wire adapter is a fair reason. A guest profile with API Enabled that nobody meant to leave on is a problem. GraphQL was one of the routes used to pull data out of badly configured guest profiles during the 2026 scanning campaign. If no public component needs it, turn it off.
A short checklist
- Make sure the org’s admin email goes to an inbox someone reads, and share the unfreeze steps with whoever supports integrations.
- Pull six months of Login History and list every SOAP
login()caller, including jobs that only run once a year. - Turn on the Use Any API Auth release update in a sandbox before 1 December 2026 and run each caller against it.
- Plan the move to OAuth for every caller before 31 January 2027.
- Add the two guest user release updates to your Winter ‘27 sandbox testing, and decide whether guests need GraphQL.
Salesforce keeps the full list on its Salesforce Platform Security Requirement Updates page, linked from the email, with a release note or knowledge article for each change. If anything here differs from those pages, go with Salesforce.