Winter '27 is half deployed. The first production wave went out on 29 August, and the two remaining waves land on the weekends of 2 to 3 October and 9 to 10 October 2026, which is where most orgs sit. The release notes have been public since 19 August, and the coverage so far has mostly been feature lists.
The part that will generate incident tickets is not a feature. It is a set of four authentication and permission changes, two enforced on upgrade weekend and two with fixed calendar dates afterwards, that mostly affect integration users nobody has looked at in years. This piece is the timeline, what each one breaks, and how to find your exposure before it finds you.
What actually changes for integration users in Winter '27?
Two release updates are enforced when your org upgrades: Enable Profile Filtering, which stops most users from reading other users' profile names, and Assign Use Any API Auth Permission for SOAP login(), which ships with the release but is enforced on a fixed date, 1 December 2026, across every org regardless of upgrade wave.
Two more changes were moved out of Winter '27 and given dates of their own. The retirement of the OAuth 2.0 username-password flow for connected apps is now 20 February 2027. The retirement of the SOAP API login() call itself, in API versions 31.0 through 64.0, is Summer '27. A fifth, the instanced URL update, has been postponed again to Spring '27.
Read together, this is a nine-month schedule for removing password-based authentication from the platform. Each date takes away one way an integration can log in with a username and password.
| Change | Type | Effective | What stops working |
|---|---|---|---|
| Enable Profile Filtering | Release update, enforced | Your Winter '27 upgrade date (29 Aug, 2 to 3 Oct, 9 to 10 Oct 2026) | Apex, Flow and validation logic that reads another user's Profile.Name returns empty |
| Use Any API Auth for SOAP login() | Release update, enforced | 1 December 2026, all orgs | SOAP login() calls from any user without the permission |
| OAuth 2.0 username-password flow | Retirement | 20 February 2027 (was Winter '27) | Connected apps posting grant_type=password |
| SOAP login() in API 31.0 to 64.0 | Retirement | Summer '27 (already absent from 65.0 and later) | The login() call in those versions, permission or not |
| Update Instanced URLs in API Traffic | Release update | Spring '27 (third postponement) | API calls to na139.salesforce.com-style hostnames |
Dates for the two release updates come from the Winter '27 release notes and the Release Updates node in Setup. Your exact upgrade date is on Salesforce Trust, and it is worth checking rather than assuming, because the waves are by instance, not by region.
Which integrations stop authenticating on 1 December?
Any integration that authenticates with the SOAP API login() call, using a user that does not hold the Use Any API Auth permission. From 1 December 2026 the call returns INSUFFICIENT_ACCESS: SOAP API login() requires the Use Any API Auth user permission and nothing else happens. There is no notification to an admin, because server-to-server authentication has no user interface to put one in.
The permission is a standard user permission, API name PermissionsUseAnyApiAuth, available on both profiles and permission sets. System Administrator has it. The users most likely not to have it are the ones you built carefully: integration users on a cut-down profile, cloned years ago, with exactly the object access the job needed and nothing more. Least privilege was the right call and it is now the exposure.
One thing to get right, because a good share of the published coverage gets it wrong: Use Any API Auth is not Use Any API Client. Use Any API Client belongs to API Access Control and governs whether a user can self-authorise a connected app. Granting it does nothing for SOAP login(). If you assign the wrong one in October and test in November, you will find out on 1 December.
The Winter '27 release update includes a test option in Setup, so you can enforce it early in a sandbox and watch what fails. For the enforcement date itself, our reading of the release note is that 1 December applies to all orgs regardless of when they upgraded, which means an org upgraded on 10 October has seven weeks, not none.
What typically calls SOAP login()? Older Data Loader builds configured with username, password and security token. ETL and middleware connectors set up the same way before OAuth became the default. Custom code that was written against the Partner or Enterprise WSDL and never revisited. Some reporting and BI connectors. The pattern is age: login() is already absent from API version 65.0 and later, so anything pinned to a current API version cannot be calling it, and anything that can is at least two years old.
Why will profile filtering break logic without an error?
Because it returns empty rather than failing. After the upgrade, a user without one of the eight bypass permissions sees only their own profile name. The primary bypass is View All Profiles; the others (Manage Users, Customize Application, Manage Profiles and Permission Sets, and four Experience Cloud administration permissions) bypass it as a side effect.
Logic that reads the running user's own profile, such as $Profile.Name in a formula or Flow, is unaffected. Logic that reads someone else's profile is not. A Flow that looks up Owner.Profile.Name to decide a routing path gets a blank and takes the default branch. A validation rule that checks the approver's profile passes or fails on an empty string. An Apex query for Profile.Name on another user, particularly in user mode, comes back with no rows. List views and reports that show other users' profile names go blank in that column.
None of this throws. That is what makes it expensive: the failure mode is a decision going the wrong way, quietly, for weeks. Profile filtering has been available to switch on since Summer '26, so orgs that enabled it early have already seen what breaks. If yours did not, the sandbox preview is the only place to look before production.
The remediation Salesforce recommends is to assign View All Profiles where the role genuinely needs it. The better remediation, for most of these cases, is to stop branching on profile names. Profile-name logic is one of the oldest forms of security debt in a Salesforce org, and this release update is the first time the platform has actively punished it. We covered the general shape of that debt in the security debt hiding in your Salesforce org; this is a specific instance with a date.
What moved out of Winter '27, and why that is not a reprieve
The OAuth 2.0 username-password flow retirement was scheduled for Winter '27 and has been moved to 20 February 2027. When enforced, any connected app integration that posts grant_type=password to the token endpoint stops receiving tokens. The migration paths Salesforce names are the web-server flow (with PKCE) for anything with a browser, and the client-credentials flow or JWT bearer flow for server-to-server work.
Two details make this less of a reprieve than it looks. First, orgs created in Summer '26 or later already cannot use the username-password flow; the retirement is only a deferral for existing orgs. Second, the deferral moved the date by roughly four months, into a period when most teams are closing a financial year and the release after it, Spring '27, is already in sandbox preview. February is not far.
The SOAP login() retirement in Summer '27 is the end of the road for the first change above. Once it lands, the Use Any API Auth permission no longer preserves anything; the call is gone in versions 31.0 through 64.0. The permission is a bridge, and the bridge is nine months long. Salesforce's stated destination is External Client Apps with OAuth, which is a larger migration than adding a permission and is the reason to start with the inventory now rather than in May.
How do you find the exposure in an afternoon?
Three checks cover the four changes.
1. Find every SOAP login() user. Setup, then Login History, then export. SOAP login() calls appear with a Login Type of Other Apex API or Partner Product and a Login Subtype of SOAP API; filter on those and group by username. Setup shows around six months, so a quarterly job that last ran in April will not appear; ask each integration owner about anything that runs less often than monthly. If you prefer SOQL, LoginHistory supports grouping on UserId, Application and Status over LoginTime = LAST_N_DAYS:90, but several of the descriptive fields are groupable and not filterable, so filter the result set rather than the WHERE clause. A shortcut to the same list: the Summer '27 retirement has its own release update with a test run that disables login() in a sandbox, and whatever breaks is your inventory.
2. Find who already holds the permission. SELECT Id, Name FROM Profile WHERE PermissionsUseAnyApiAuth = true and SELECT AssigneeId, Assignee.Username FROM PermissionSetAssignment WHERE PermissionSet.PermissionsUseAnyApiAuth = true. Subtract this from the list in step 1. What is left breaks on 1 December.
3. Inventory profile-name branching. Search Flows, validation rules, Apex and formula fields for Profile.Name, Profile.Id and $Profile. Anything referencing the running user is fine. Anything referencing another user's profile, through Owner, CreatedBy, LastModifiedBy, an approver or a lookup, needs either View All Profiles on the users who trigger it or, better, a rewrite against a custom permission or permission set group.
Then, separately, list every connected app whose consumer posts grant_type=password. This one does not appear in Login History as SOAP; it appears as an OAuth login. Connected app owners usually know. Where they do not, the Connected Apps OAuth Usage page in Setup shows which apps have active tokens, and the app's own configuration will show the flow.
What to decide before your upgrade weekend
The four changes share one root cause. Integration users were set up once, with a password, on a narrow profile, and then left alone because they worked. Salesforce is now removing every one of the mechanisms that let that pattern keep working.
That is the same least-privilege problem we described for agents in the agent action surface piece: identities that act without a human present, with permissions nobody reviews because nothing forces a review. Winter '27 forces one for integration users. Treat it as the review, not as a permission to add.
Concretely, the decisions are these. Whether each SOAP login() integration gets the permission as a bridge or gets migrated to OAuth directly, given the bridge expires in Summer '27. Whether profile-name logic gets View All Profiles or gets rewritten, given that View All Profiles is a broad grant on a permission that exists to make profiles less visible. And who owns each integration user, because the honest answer in many orgs is that nobody currently does, and the retirement dates are going to ask.
If your org upgrades on 9 or 10 October, the Release Updates node in Setup will let you enforce both updates in a sandbox now. That is a week of testing you can have for free, and the only week in which a blank profile name is a finding rather than an incident.
What this does not change
It does not change REST API authentication, and it does not retire the SOAP API. Only the login() call is affected, and only in the named versions; SOAP calls authenticated with an OAuth token continue. It does not change how the running user's own profile is read, so $Profile.Name in formulas and Flows keeps working. It does not affect integrations already on the web-server, client-credentials or JWT bearer flows, which is most of anything built in the last three years. And it does not, on its own, remove the need for the migration to External Client Apps that Salesforce has signalled for Summer '27; it schedules it.
The Winter '27 auto-enable of Agentforce has had most of the attention in this release. The authentication changes will generate more support cases. Both are worth a look before your date.
*Release update details are drawn from the Winter '27 release notes (published 19 August 2026), the Salesforce Help release update pages for Use Any API Auth, Profile Filtering and the OAuth username-password flow retirement, and practitioner analysis by Software Insights and Apex Hours. Production upgrade dates vary by instance; confirm yours on Salesforce Trust. Third-party sources give 1 June 2027 for the SOAP login() retirement; Salesforce's release note says Summer '27, and we have used that. A separate release update on email change verification exceptions, dated 1 December 2026, is reported by one source and not independently confirmed here. Enterprise Dreamin' has no commercial relationship with Salesforce.*
