Most coverage of the Winter '27 release is about the new features: report previews, joined-report filters, Setup with Agentforce. The changes more likely to cause a support ticket are further down in the release notes, in the release updates. These are changes Salesforce enforces on a set date, whether or not you have tested them.
This time several of them are about security and access. Together, they narrow who can see what, close old ways of logging in to the API, and add a narrower permission for the audit trail. That is good for your org. It can also break a help-desk process, a reporting habit or a ten-year-old integration.
Below is each change, what it breaks, and how to check your org before the enforcement date. Every detail is taken from Salesforce's own Winter '27 release notes, which are linked in each section.
1. Profile Filtering is on by default (enforced in Winter '27)
What changes: With Profile Filtering enabled, users can see only the name of their own profile unless they have the View All Profiles permission. The update was first available in Summer '26, and Salesforce enforces it in Winter '27.
What can break: Anything that shows or depends on other users' profile names for someone who is not an admin. Common examples:
- help-desk or team-lead users who check a user's profile when triaging an access problem
- delegated administrators who manage users but are not full admins
- reports and list views on Users that group or filter by profile, run by non-admins
- custom components or code that show a user's profile to a colleague
How to check: List who actually needs to see profile names, and grant View All Profiles through a permission set rather than editing profiles. Then activate the release update in a sandbox (Setup → Release Updates) and test those users' journeys before Salesforce enforces it in production. To find your instance's upgrade date, search for your instance on Trust Status and open the maintenance tab.
A narrow permission set is the right way to grant it. Profile names reveal how your org is organised, so this change fits least privilege well. Do not undo it by giving View All Profiles to everyone.
2. SOAP login() now needs Use Any API Auth (enforced 1 December 2026)
What changes: To authenticate with the SOAP API login() call, a user must have the Use Any API Auth permission. Without it, login fails with an error. Salesforce enforces this across all orgs and environments, sandboxes included, from 1 December 2026.
What can break: Any integration that signs in with a username, password and security token. These are often the oldest integrations in an org: legacy middleware, desktop tools set up to use password login, spreadsheet connectors and scripts written years ago. Nobody has changed them in a long time, so nobody thinks of them.
How to check: Login History records how each user signs in. Start with the non-browser logins from the last 30 days:
SELECT UserId, LoginType, Application, ApiType, ApiVersion, LoginTime
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:30
AND LoginType != 'Application'
ORDER BY LoginTime DESC
LIMIT 2000
Rows whose API type is SOAP point to integrations using login(). Give the permission only to those integration users, through a permission set, and use the test run in Release Updates to confirm nothing else fails.
3. SOAP login() in API versions 31.0–64.0 is retired in Summer '27
The December change is a stopgap. Separately, Salesforce is retiring login() in SOAP API versions 31.0 through 64.0 in Summer '27. After that, those calls fail with an error saying the endpoint has been deactivated. Salesforce's advice is to move these applications to external client apps (OAuth) before then.
So the integrations you find in step 2 need two things: the permission now, and a migration plan for next year. It makes sense to plan both at the same time.
4. API versions 31.0–40.0: deprecated in Summer '27, retired in Summer '28
Salesforce Platform API versions 31.0 through 40.0 are deprecated from Summer '27, when they stop receiving security updates and bug fixes. They are retired in Summer '28, when calls to them fail. This applies to SOAP, REST, Bulk API and everything under /services/data/vXX.X/, including the Metadata and Tooling APIs.
The ApiVersion column in the Login History query above shows which integrations still call old versions. Anything below 41.0 should go on the same migration list.
5. Instanced URLs in API traffic: enforcement postponed to Spring '27
This update requires API traffic to use your org's My Domain login URL instead of a hard-coded instance such as na123.salesforce.com. It was meant to be enforced in Spring '26 and has been postponed to Spring '27, in phases.
Postponements tend to be forgotten until they arrive. The integrations you are already reviewing for steps 2–4 are the ones most likely to have an old instance URL hard-coded, so check their endpoint configuration during the same review.
6. A dedicated View Setup Audit Trail permission (enforced in Spring '27)
Setup Audit Trail access is moving to its own View Setup Audit Trail permission, so you no longer need to grant the much broader View Setup permission to let someone see what changed. Note the date: this update appears in the Winter '27 release notes, but Salesforce enforces it in Spring '27, not Winter '27. Some coverage has reported it as a Winter '27 change.
Salesforce automatically adds the new permission to every profile and permission set that already has View Setup, so current access stays the same. Two points to act on:
- New profiles, permission sets and users will need the permission added explicitly.
- This is a good chance to reduce access. If auditors, compliance staff or managers were given View Setup only so they could read the audit trail, you can now give them View Setup Audit Trail and remove View Setup.
7. Worth turning on: field history tracking for Users (GA)
This one is not a release update, but it belongs on a security checklist. Field history tracking on the User object is now generally available in Enterprise, Performance, Unlimited and Developer editions. You can track up to 20 User fields, with old value, new value, timestamp and who made the change. Changes made through the UI, bulk operations, Apex and the API are all recorded.
Turn it on from Object Manager → User → Fields & Relationships. Good first choices are profile, role, active status, email, manager and federation ID. These are the fields that matter when you are asked "who gave this person access, and when?"
Doing the permission work in bulk
Most of the checklist above comes down to the same task: give one permission to a few specific people, and take broader permissions away from people who no longer need them. In Setup, that means editing profiles and permission sets one by one.
The orgadmin.ai Permissions Workbench puts profiles and permission sets side by side in one matrix. It reads the list of system permissions from your org, so View All Profiles, Use Any API Auth and View Setup Audit Trail appear once your org has them. You can stage changes across many permission sets at once, review the full diff in plain language, and apply it as a background job with results for each row. It can also create a new permission set, such as "Help desk – View All Profiles", cloned from an existing one.
For the review side:
- Security Review runs fourteen audit modules against your org. These include a breakdown of how users log in from Login History, security-relevant changes from the last 90 days of Setup Audit Trail, and privileged-access checks. Every finding comes with its evidence.
- User Management lists who holds Modify All Data, View All Data or Manage Users, and through which profile or permission set. It also flags dormant accounts that still have those permissions. Old integration users often turn up here.
A two-week plan
If you have not started yet:
- Days 1–2: Run the Login History query. List every integration using SOAP
login()or an API version below 41.0, and name an owner for each. - Days 3–4: Create two permission sets, one for View All Profiles and one for Use Any API Auth, and assign them to the people and integration users who need them.
- Days 5–8: In a sandbox, activate the Profile Filtering and SOAP
login()release updates. Test help-desk journeys, delegated admin tasks and each integration you listed. - Days 9–10: Replace View Setup with View Setup Audit Trail for anyone who only needed the audit trail.
- Ongoing: Turn on User field history tracking, and put the Summer '27 OAuth migration on the roadmap now, before it is urgent.
Release updates reward teams that prepare early. The same checks, repeated each release, are also the core of a regular security audit. We covered how often to run one in how often you should audit Salesforce security.