TL;DR
- Sandbox preview begins 29 August 2026. Salesforce Trust lists Winter '27 production upgrade dates of 29 August, 5 September, 3 October, 9 October and 10 October 2026, and your org is assigned to one of them by instance.
- Salesforce's Release Updates page lists eight items scheduled for Winter '27. Five are security relevant: the OAuth 2.0 username-password flow retirement, Update Instanced URLs in API Traffic, Enable Profile Filtering, Adopt Authorized Email Domains, and the new Modify Transaction Security Policy permission.
- Two of the five break integrations, and both fail silently server to server with nothing in the UI to warn an admin.
- The remaining three Winter '27 items are accessibility enhancements for high-magnification viewing, split across three separate release updates. Worth testing, not a security matter.
- The list that applies to your org is the one in your own Setup under Release Updates, because updates only appear when they are relevant to the features you use.
What You'll Learn
- The Winter '27 dates that matter, and how to find your org's specific one
- What each of the five security changes breaks, in one place
- Which ones fail silently, and why that changes how you test them
- A week-by-week plan for the sandbox preview window
- What to tell users, and when to tell them
The Problem
Release readiness has a predictable failure pattern. Somebody skims the release notes in September, notes that nothing looks urgent, and the org upgrades on a Saturday in October. On the Monday, a nightly integration has not run since Friday, and nobody knows which change caused it because four things enforced at once.
Winter '27 is a good candidate for that pattern, because its security changes are unusually quiet. Two of the four break at the authentication or network layer, which means they fail server to server with no error surfaced anywhere a person would look. One changes what users can see rather than what they can do, so it manifests as a blank field rather than an error. Only the email domain change announces itself clearly.
The other complication is that this wave has already slipped. The instanced URL update was first available in Summer '25 and was scheduled for Spring '26 before being postponed, so teams that deprioritised it twice have learned that the deadline moves. That is a reasonable inference from history and a poor basis for planning, because the work is small and the failure is total.
Common questions this article answers:
- What is actually enforcing in Winter '27, and when does my org get it?
- Which of these changes can break something without anybody noticing?
- What should I be doing during the sandbox preview window?
Quick Answer
Sandbox preview begins 29 August 2026, and Salesforce Trust lists Winter '27 production upgrade dates of 29 August, 5 September, 3 October, 9 October and 10 October 2026, assigned by instance. Find your org's date by looking up your instance on Salesforce Trust Status, and confirm which updates apply to you in Setup under Release Updates. Salesforce lists eight items for Winter '27, of which five are security relevant. The OAuth 2.0 username-password flow retirement stops any integration authenticating with grant_type=password. Update Instanced URLs in API Traffic stops API calls to a hostname that no longer matches your org's instance. Both of those fail silently, server to server. Enable Profile Filtering restricts users to seeing only their own profile name, which can change how automation behaves when it reads another user's profile. Adopt Authorized Email Domains means Salesforce Support can no longer disable Email Change Verification, so bulk email updates need DKIM or an authorized domain configured in advance. The new Modify Transaction Security Policy permission becomes required to create, update or delete a TSP, and Customize Application drops to view-only. Test the two integration changes first, because they are the ones that break completely, and note that both of them let you force the failure early on a date you choose rather than waiting for the upgrade.
The dates
These are the Winter '27 major release windows published on Salesforce Trust, counted by distinct instance:
| Date | Sandbox instances | Production instances |
|---|---|---|
| 29 August 2026 | 24 | 110 |
| 5 September 2026 | 0 | 10 |
| 3 October 2026 | 0 | 18 |
| 9 October 2026 | 0 | 97 |
| 10 October 2026 | 12 | 152 |
Three things about that table are worth reading carefully.
There are five upgrade dates, not three. Most published summaries list 29 August, 3 October and 10 October and stop there. Trust also shows a 5 September window and a 9 October one, and together those cover more than a quarter of production instances. If your instance is in one of them, a plan built from the three-date version has you testing after you have already upgraded.
Your sandbox and your production org are not on the same schedule. Preview-eligible sandboxes get Winter '27 on 29 August, while roughly seven in ten production instances land in the October windows. That gap is the testing window and it is the entire reason preview sandboxes exist. Non-preview sandboxes upgrade on 10 October instead, so if your only sandbox is non-preview you have no window at all, which is worth finding out now rather than in September.
A large share of production upgrades on the same day preview starts. Around 110 production instances take Winter '27 on 29 August, the same day preview sandboxes do. "Production is in October" is true for most orgs and emphatically not all, so check your instance rather than assuming.
To find your date: open Setup, then Company Information, and note your instance. Then look that instance up on Salesforce Trust Status and open its maintenance schedule. Setup, then Release Updates, shows the enforcement status of each update as it applies to your org specifically.
The five security changes
1. OAuth 2.0 username-password flow retirement
What breaks: Any integration that authenticates by posting grant_type=password with a username, password and security token stops receiving an access token.
How it fails: Completely and silently. The break is at authentication, so the integration does not degrade, it stops. Because the exchange is server to server, nothing appears in the Salesforce UI.
Who is exposed: Older orgs with long-running integrations. New orgs already block this flow by default.
Where to look: Setup then Release Updates for Salesforce's own assessment, Login History for the OAuth Username-Password login subtype, and Connected Apps OAuth Usage.
Full detail, including the migration paths to client credentials and JWT bearer, is in Salesforce Retires the OAuth Username-Password Flow in Winter '27.
2. Update Instanced URLs in API Traffic
What breaks: API calls to an instanced hostname such as na139.salesforce.com that no longer matches the instance your org actually sits on.
How it fails: Silently, at the network layer, before authentication is even attempted.
Who is exposed: Any org that has been moved between instances, which is most orgs that have been running for several years. The hostname went stale when Salesforce moved you, and compatibility routing has been quietly covering for it since.
The useful part: A My Domain setting blocks this traffic on demand, so you can force the failure in a sandbox now and schedule the production cutover for a weekday morning of your choosing.
Full detail in Salesforce Winter '27 Stops Supporting Incorrect Instanced URLs in API Traffic.
3. Enable Profile Filtering
What changes: Users can see only their own profile name unless they hold one of eight bypass permissions, including View All Profiles, Customize Application and Manage Users.
How it fails: Quietly and partially. Logic reading the running user's own profile is unaffected. Logic reading someone else's profile, such as a Flow reading a record owner's profile name, can behave differently, usually by returning a blank rather than an error.
The trap: Admins hold the bypass permissions, so testing as yourself shows a false pass. Test with login-as as a standard user.
Bonus gotcha: With Profile Filtering on, users cannot create or edit login flows without View All Profiles.
Full detail in Salesforce Winter '27 Turns On Profile Filtering.
4. Adopt Authorized Email Domains
What changes: Salesforce Support can no longer disable Email Change Verification for you. To update user email addresses at scale, you configure a DKIM key or an Authorized Email Domain in advance.
How it fails: Visibly, but at the worst time. The symptom is that a bulk email update you planned for a migration or a rebrand cannot proceed, and the escape hatch you used last time no longer exists.
Who is exposed: Anyone with a domain change, acquisition, or mass user update on the roadmap.
Full detail in Salesforce Retires Support-Disabled Email Change Verification.
5. Modify Transaction Security Policy permission
What changes: Creating, updating or deleting a Transaction Security Policy now requires a new Modify Transaction Security Policy user permission. In Salesforce's own words, users with Customize Application "are now restricted to view-only access".
How it fails: As a permission error at exactly the wrong moment. Somebody who has always maintained your TSPs finds they can still see them and can no longer change them, which tends to surface during an incident rather than during a quiet Tuesday.
Who is exposed: Shield and Event Monitoring orgs, and anyone whose TSP maintenance is done by a person holding Customize Application rather than full admin rights.
What to do: Work out who genuinely maintains TSPs and assign them the new permission before your upgrade date. This is the rare case in this wave where the fix is to grant something rather than to change configuration. It is also a real least-privilege improvement, because Customize Application is a broad permission that has been quietly carrying TSP write access for years.
If your policies cover report exports, the behaviour of that control has already changed once this year. We cover the known issues in Transaction Security Policy report export: the known issues.
And one that is not on the list
Legacy Named Credentials are deprecated but have no announced retirement date, so nothing about them breaks in Winter '27. They are worth handling in the same pass because you are already opening every integration's configuration for changes 1 and 2, and the legacy format has a real weakness: endpoint, authentication and secret in one record with no permission set control over who may use it. See Migrating legacy Named Credentials.
The full list, and why other lists differ
Most articles about Winter '27 describe "the five release updates" and then disagree about which five. Some include an Order Management tax calculation fix, some include the instanced URL change, some fold the accessibility work into one line.
Salesforce's own Release Updates page, under the heading "Scheduled to Be Enforced in Winter '27", lists eight items:
| Item | Security relevant |
|---|---|
| Adopt Authorized Email Domains | Yes |
| Enable Accessibility Enhancements for Page Headers and Modal Windows When Zoom Is Greater Than 200% | No |
| Enable Accessibility Enhancements for Date Pickers, Popovers, Bottom Utility Bars, Record Headers | No |
| Enable Accessibility Enhancements for Cards, Docked Containers, Menu Lists, and Panels | No |
| Enable Profile Filtering | Yes |
| Modify Transaction Security Policy Permission | Yes |
| Retirement of OAuth 2.0 Username-Password Flow for Connected Apps | Yes |
| Update Instanced URLs in API Traffic | Yes |
Two things fall out of that. The accessibility work is three separate release updates rather than one, which is where several of the "five" counts come from. And there is no Order Management tax update scheduled for Winter '27 at all, so any list including one is describing a different release.
That said, do not build your plan from anybody's list, including this one. Release Updates appear on your own page only when they are relevant to the features your org uses, so the set that applies to you is a subset of the eight above. Open Setup, then Release Updates, in your own production org. That page shows what applies to you, with the enforcement date for your instance. Use articles like this one to understand what each update means, then work from your own page.
Using the preview window
If your production instance upgrades in October, preview gives you five to six weeks. If it upgrades on 29 August or 5 September, you have days rather than weeks, so check your date before you plan around this schedule. Here is how to spend the window without doing everything at once.
Before preview begins (now):
Do the inventory work, because none of it needs Winter '27 to exist. Grep your repositories and middleware exports for hardcoded instanced hostnames. Pull Login History for OAuth password-flow logins. Retrieve Flow, ValidationRule, ApexClass and ApprovalProcess metadata and search it for cross-user profile references. Confirm which of your sandboxes are preview-eligible, and if none are, sort that out immediately because it takes time.
Week 1 of preview: the silent breakers.
Test the two integration changes first, because they fail completely and their fixes take the longest. Both let you force the failure early: enable the My Domain block setting for instanced URLs, and switch a test integration to confirm the OAuth flow. Run a full integration cycle, not just the daily jobs.
Week 2: the visible changes.
Enable Profile Filtering in the sandbox and walk your automation list as a standard user via login-as. Configure your Authorized Email Domain or DKIM key and confirm a test email change works end to end.
Week 3: the long-interval jobs.
The things that run monthly or quarterly will not have appeared in weeks 1 and 2. Go to your scheduler, list anything with an interval longer than a week, and trigger it manually or verify its configuration by inspection. This is where the payroll job that runs on the 15th lives.
Week 4: fix and re-test.
Deploy the fixes to the sandbox and run the whole cycle again. Test the negative cases, particularly that credentials fail for users who should not have them.
Week 5: production preparation.
Schedule the production cutovers you control for weekday mornings, with owners available and a rollback plan. For anything owned by a partner or vendor, this is well past the point where you should have emailed them, so check the replies.
The sequencing principle is that you test the total failures before the partial ones. A blank profile name in a Flow is a bad afternoon. A payroll integration that has not authenticated since Friday is a different kind of problem, and it deserves the first week of your window.
If you want the inventory step automated rather than done by hand, our open-source sf-audit plugin (sf plugins install @cclabsnz/sf-audit) inventories connected apps, OAuth scopes, integration users and privileged access in one command. See Catch Salesforce security gaps in one command.
What your users will see
Most of this wave is invisible to end users, and the comms should reflect that rather than manufacturing alarm. Two messages are worth sending, to different audiences.
To everybody, close to your upgrade date:
Salesforce updates its platform three times a year, and our next update lands in October. Most of what is changing happens behind the scenes and you should notice nothing at all. One small change: Salesforce is tightening who can see profile information, so if a screen used to show other people's access level and now shows a blank, that is expected rather than a fault. If a screen you rely on stops showing something you need for your job, tell us rather than working around it.
To the people who own reports and dashboards fed by other systems:
Ahead of the October Salesforce update we are changing how our connected systems authenticate. If a report or dashboard of yours is fed from another system, please keep an eye on whether the data still looks current over the next few weeks. There will be no error message if something goes wrong here. The symptom is data that quietly stops refreshing, so a quick "this looks out of date" is the fastest way for us to catch it.
The second message is the one that earns its keep. You cannot personally watch every integration, and the people who would notice a stale number are already looking at it every day. Telling them explicitly that silence is the failure mode turns them into your monitoring.
Frequently Asked Questions
Q: When exactly does my org upgrade?
A: Look up your instance on Salesforce Trust Status and check its maintenance schedule. Trust lists five Winter '27 major release dates: 29 August, 5 September, 3 October, 9 October and 10 October 2026. Most published summaries mention only the first, third and last of those, so check Trust rather than an article. Setup, then Release Updates, shows the enforcement date for each update as it applies to your org.
Q: Which of these changes can break something without anyone noticing?
A: The OAuth username-password retirement and the instanced URL enforcement. Both fail server to server, at authentication or before it, with nothing surfaced in the UI. Profile Filtering is quieter than an error but more visible than those two, because users see blanks. The email domain change is the only one that announces itself clearly.
Q: The instanced URL update was postponed twice. Will it slip again?
A: It might. Betting on it is poor value, because the fix is small and the failure is complete, and because the My Domain block setting means you can cut over on your own schedule and stop caring about the enforcement date entirely.
Q: We have no preview sandbox. What are our options?
A: Create or convert one now, since preview eligibility is determined ahead of the preview window rather than on demand. If that is not possible for this cycle, focus on the changes you can verify without the release being present: the instanced URL block setting, the Profile Filtering toggle and the Authorized Email Domain configuration all exist in your current org today. That covers three of the four without needing preview at all.
Q: Does any of this affect our MFA position or the 2026 enforcement wave?
A: No, these are separate changes. The 2026 wave covering MFA, device activation and report export controls enforced across January to July 2026 and is described in Salesforce Security Enforcement in 2026. Winter '27 is the next wave rather than a continuation of that one, and nothing in it revisits MFA.
Q: What about the accessibility and tax updates in this release?
A: Winter '27 carries three separate accessibility release updates, covering page headers and modal windows, date pickers and popovers and bottom utility bars and record headers, and cards and docked containers and menu lists and panels. All three adapt Lightning Experience behaviour above 200% magnification as part of Salesforce's work toward WCAG 2.2 Resize and Reflow. They are worth testing if you have users working at high zoom, and none of them is a security matter, so they do not belong on this checklist. There is no Order Management tax update scheduled for Winter '27, despite some published lists including one.
Key Takeaways
- Sandbox preview is 29 August 2026, and Trust lists five production dates: 29 August, 5 September, 3 October, 9 October and 10 October. Two of those are missing from most published summaries.
- Salesforce lists eight Winter '27 items and five are security relevant, covering integration authentication, API hostnames, profile visibility, email domain control and Transaction Security Policy permissions.
- Two of the four fail silently, server to server, which means they need testing first and cannot be caught by watching the UI.
- Two of the four let you force the failure early, so you can cut over on a weekday morning of your choosing instead of on upgrade weekend.
- Build your plan from Setup, then Release Updates, in your own org, because the set of updates that applies varies by org and no published list is correct for everyone.
What's Next?
Recommended Reading:
- Salesforce Winter '27 Turns On Profile Filtering
- Salesforce Winter '27 Stops Supporting Incorrect Instanced URLs in API Traffic
- Salesforce Retires the OAuth Username-Password Flow in Winter '27
- Salesforce Security Enforcement in 2026: Every Change, Date, and What Admins Must Do
Action Items:
- Look up your instance on Trust Status to get your upgrade date, and open Setup then Release Updates to get the list that actually applies to your org.
- Confirm you have a preview-eligible sandbox, and sort it out now if you do not.
- Do the inventory work before preview begins: hardcoded hostnames, OAuth password-flow logins, and cross-user profile references in metadata.
Resources & References
- Release Updates, including the "Scheduled to Be Enforced in Winter '27" list (Salesforce Help)
- Limit Profile Details to Required Users (Salesforce Help)
- Salesforce Trust Status (find your instance's release date) is the source for the five upgrade dates in this article
- Transaction Security Policy report export: the known issues
- Catch Salesforce security gaps in one command