Salesforce Winter '27 Security Readiness: The Release Updates and the Sandbox Window to Test Them

TL;DR

• The sandbox cutoff is 6:00 PM PT on 27 August 2026 (01:00 UTC on 28 August, 1:00 PM NZST on 28 August). A sandbox has to be created or refreshed before that moment to sit on a preview instance. Refresh a preview sandbox after it and Salesforce routes it to a non-preview instance and reverts it to Summer '26, so a routine refresh on the wrong day costs you the whole testing window.
• Preview instances upgrade across 28 and 29 August 2026 Pacific time. 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 now lists five items enforced with Winter '27, and only two are security relevant: Enable Profile Filtering, and Assign Use Any API Auth Permission for SOAP login(). The other three are accessibility enhancements for high-magnification viewing.
• Three changes widely reported as Winter '27 are no longer in it. The OAuth username-password flow retirement was postponed to 20 February 2027. Update Instanced URLs in API Traffic was postponed to Spring '27, its third slip. Adopt Authorized Email Domains was cancelled and replaced by Maintain Your Email Verification Exception, enforced 1 December 2026.
• That is good news for your upgrade weekend and bad news for planning, because the two silent integration breakers now land in 2027 and are easy to forget. This post keeps them, with their new dates.
• 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

Your sandbox has to be created or refreshed before 6:00 PM PT on 27 August 2026 to sit on a preview instance, and refreshing a preview sandbox after that cutoff reverts it to Summer '26. Preview instances upgrade across 28 and 29 August 2026 Pacific time, 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 five items enforced with Winter '27, of which two are security relevant: Enable Profile Filtering, and the new requirement that anyone authenticating through SOAP API login() holds the Use Any API Auth permission. Three changes commonly attributed to Winter '27 have moved out of it and are covered below with their new dates. 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

Those are the window start times as Salesforce Trust publishes them, which is UTC. Read them in your own timezone before planning around them, because for anyone west of UTC the local date can be a day earlier.

Four 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.

The sandbox row says 29 August in UTC and 28 August in California. Salesforce Help states that preview instances are upgraded "on August 28 and August 29", while every Trust window above starts on 29 August. Both are right. Trust publishes UTC, and those windows begin between 02:30 and 18:30 UTC, so the earliest of them land at 19:30 to 21:00 Pacific on 28 August. If you have seen 28 August and 29 August quoted against each other, that is the whole of the disagreement. What actually binds you is neither date but the cutoff before them, and in New Zealand that cutoff falls at 1:00 PM on 28 August, after the preview window has already opened in California.

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 changes, and where three of them went

When this post was first published, all five below were scheduled for Winter '27. Three have since moved. They are kept here rather than deleted, because the work does not go away and a date that slips is the easiest kind of deadline to lose track of.

Still enforced with Winter '27: Enable Profile Filtering, and Assign Use Any API Auth Permission for SOAP login().

Moved: the OAuth username-password retirement to 20 February 2027, Update Instanced URLs in API Traffic to Spring '27, and Adopt Authorized Email Domains cancelled and replaced.

1. OAuth 2.0 username-password flow retirement

Status: moved out of Winter '27. Salesforce states it "was scheduled to be enforced in Winter '27, but we postponed the enforcement date to February 20, 2027". The change itself is unaltered, so everything below still applies, on the later date.

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

Status: moved out of Winter '27, for the third time. Salesforce now states it was "scheduled to be enforced in Spring '26, but we postponed the enforcement to Spring '27". First available in Summer '25. If you enabled the My Domain block setting already, none of this matters to you, which was always the argument for doing so.

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

Status: enforced with Winter '27. Unchanged, and one of only two security items actually landing in this release.

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

Status: cancelled. Salesforce's Release Updates page now reads "This update has been canceled and replaced by the Maintain Your Email Verification Exception update", enforced 1 December 2026. The replacement is narrower: if you previously had email verification disabled through Support, you configure an authorized email domain to keep that exception, and when it enforces Salesforce removes the existing allowlists. The preparation below is still the right preparation, against the new name and date.

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

Status: not a Release Update. This change does not appear on the Release Updates page in any section, so it is not tracked or dated there and will not show in Setup under Release Updates. It ships as a permission change in the release itself. Treat the detail below as accurate but unscheduled, and verify against your own org rather than a countdown.

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.

6. Assign Use Any API Auth Permission for SOAP login()

Status: enforced with Winter '27. This one was not on the original list and is the second of the two security items that actually land in this release.

What breaks: Any user authenticating through the SOAP API login() call without the Use Any API Auth user permission. Salesforce's wording is blunt: such users "can no longer authenticate with SOAP API login() and will encounter an error."

How it fails: Completely, at authentication, server to server. Same shape as the OAuth retirement, and the same absence of any UI signal. The difference is that this one is not deferred to 2027.

Why it catches people: Integration users are frequently provisioned from a cut-down profile precisely to limit their reach, and this is not a permission most orgs have had cause to grant deliberately.

Find your exposure before granting anything. Pull Login History filtered to SOAP API logins and list the distinct users, because that set is exactly who needs checking:

SELECT UserId, Application, Status, COUNT(Id) logins
FROM LoginHistory
WHERE LoginTime = LAST_N_DAYS:90
GROUP BY UserId, Application, Status
ORDER BY COUNT(Id) DESC

Run it with sf data query --query "..." --target-org yourorg, then pick out the SOAP rows from the result.

The filtering has to happen after the query, not in it. On LoginHistory, Application, Status and ApiType are groupable but not filterable, so adding AND Application = 'SOAP Api' to the WHERE clause returns a parse error rather than a filtered list. LoginTime, UserId, LoginType, SourceIp and LoginUrl are the fields you can filter on. Ninety days matters more than it looks, because a quarterly integration that has not run since May will not appear in a thirty day window and will still break.

The permission, confirmed against an org rather than an article. It is PermissionsUseAnyApiAuth, labelled Use Any API Auth. Third party write-ups routinely confuse it with "Use Any API Client", which governs API Access Control and connected app self-authorization and is a different thing entirely. To see who already holds it:

SELECT Id, Label FROM PermissionSet WHERE PermissionsUseAnyApiAuth = true
SELECT Id, Name FROM Profile WHERE PermissionsUseAnyApiAuth = true
SELECT AssigneeId, Assignee.Username FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsUseAnyApiAuth = true

Grant it through a permission set assigned to the specific integration users the first query set surfaces, rather than by editing a profile, so the grant is visible, revocable and attached to a named reason.

Note the related but separate Spring '27 item, SOAP API login() Call in SOAP API Versions 31.0 Through 64.0 Is Being Retired. Winter '27 changes who may call login(). Spring '27 begins removing the older API versions it can be called against.

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. Most were written before the release notes went live, and the list has since changed underneath them.

Salesforce's Release Updates page, under "Enforced with This Release", now lists five items:

Item	Security relevant
Assign Use Any API Auth Permission for SOAP login()	Yes
Enable Accessibility Enhancements for Cards, Docked Containers, Menu Lists, and Panels	No
Enable Accessibility Enhancements for Date Pickers, Popovers, Bottom Utility Bars, Record Headers	No
Enable Accessibility Enhancements for Page Headers and Modal Windows When Zoom Is Greater Than 200%	No
Enable Profile Filtering	Yes

And the items that left, with where they went:

Item	Now
Retirement of OAuth 2.0 Username-Password Flow for Connected Apps	Postponed to 20 February 2027
Update Instanced URLs in API Traffic	Postponed to Spring '27
Adopt Authorized Email Domains	Cancelled, replaced by Maintain Your Email Verification Exception, enforced 1 December 2026
Modify Transaction Security Policy Permission	Not listed as a Release Update at all

Three 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 it is now the majority of the release rather than a footnote. There is no Order Management tax update scheduled for Winter '27 at all, so any list including one is describing a different release. And the two changes that break integrations silently have both moved into 2027, which makes them easier to drop from a plan than to solve.

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.

Do that before 6:00 PM PT on 27 August 2026. That is the cutoff for a sandbox to land on a preview instance, and it is the one date in this post that cannot be worked around later. Two things about it catch people out. A refresh has to be complete by the cutoff rather than merely requested, so a large sandbox needs to start well before it. And if you already hold a preview sandbox, refreshing it after the cutoff moves it to a non-preview instance and drops it back to Summer '26, which turns a routine refresh into the loss of your only testing window. Check the Release Type column under Setup, then Sandbox, to see which instance each sandbox is on.

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 did. Salesforce has moved it to Spring '27, a third postponement. That does not change the advice, and if anything it strengthens it: the fix is small, the failure is complete, and the My Domain block setting lets you cut over on your own schedule and stop tracking the enforcement date at all. Orgs that did that in Summer '25 have now sat out three slips without having to think about any of them.

Q: We have no preview sandbox. What are our options?

A: Create or refresh one before 6:00 PM PT on 27 August 2026, since preview eligibility is determined ahead of the preview window rather than on demand, and the refresh has to finish before the cutoff rather than just be requested by it. 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

• The sandbox cutoff is 6:00 PM PT on 27 August 2026, which is 1:00 PM on 28 August in New Zealand. Refreshing a preview sandbox after it reverts that sandbox to Summer '26.
• Winter '27 enforces five items and only two are security relevant: Enable Profile Filtering, and Use Any API Auth for SOAP login(). The other three are accessibility enhancements.
• Three changes widely reported as Winter '27 have moved: the OAuth username-password retirement to 20 February 2027, instanced URLs to Spring '27, and Adopt Authorized Email Domains cancelled in favour of a 1 December 2026 replacement.
• The two silent integration breakers are the ones that moved, so the risk did not disappear, it just stopped having an upgrade weekend attached to it. Both let you force the failure early on a date you choose.
• 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:

1. 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.
2. Confirm you have a preview-eligible sandbox, and sort it out now if you do not.
3. 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