The Winter '27 Enforcement Shuffle

The integration that posts grant_type=password to your org every fifteen minutes was supposed to stop getting a token this weekend. It did not. It kept running, and it will keep running until February 20, 2027.

Winter '27 started landing in production on Saturday. Preview sandboxes finished upgrading over Friday and Saturday, which means the testing window opens today. And the enforcement list that goes with it is shorter than the one the ecosystem, this site included, published two weeks ago.

Three release updates left the release. Two remain, and neither is the one most teams spent August rehearsing.

What Moved Out

The largest item is the OAuth one. Salesforce Help says it plainly on the release update page: the retirement of the OAuth 2.0 username-password flow for connected apps was originally scheduled to enforce with the Winter '27 major release, and the enforcement date was changed. The new date is February 20, 2027.

That flow, the resource owner password credentials grant, is the one where an integration sends a username, a password and a security token to the token endpoint and gets an access token back. It is still going away. It is going away on a fixed calendar date instead of a release weekend, which is arguably worse, because release weekends are already in your change calendar and February 20 is not.

Second, Update Instanced URLs in API Traffic moved to Spring '27. This update stops API calls that address old instance hostnames like na139.salesforce.com instead of your My Domain URL. It first appeared in Summer '25, was scheduled for Spring '26, then Winter '27, and has now been pushed again. Three scheduled enforcement windows, zero enforcements. Salesforce clearly still has customers pointing production traffic at instanced endpoints, and it clearly does not want to be the reason those customers have an outage.

Third, Adopt Authorized Email Domains was cancelled and replaced. The replacement is a new release update called Maintain Your Email Verification Exception, and it enforces on December 1, 2026. The practical change is the same either way: Salesforce Support can no longer switch off Email Change Verification for your org. If you have been running on a Support exception, that exception ends, and the fix is to configure DKIM signing or an authorized email domain before your next bulk user email update rather than during it.

Notice what those three have in common. Each one fails silently, at a layer with no user-facing error, which is exactly why teams put them at the top of their test plans. All three are now out of the release.

What Actually Enforces

Two items are left that change behaviour, and they are quieter than the three that departed.

Enable Profile Filtering. After this enforces, a user sees only their own profile name unless they hold one of eight bypass permissions, including View All Profiles, Customize Application and Manage Users. The failure mode is partial rather than loud. Automation that reads another user's profile name usually gets a blank value back, not an exception, so the record saves and the logic downstream quietly takes the wrong branch.

There is a trap in how you test it. Administrators hold the bypass permissions. Log in as yourself, run the flow, and everything passes. The only test that means anything is login-as against a standard user profile, and if your org has several cut-down profiles you need to run it against each one. A second effect catches people later: users cannot create or edit login flows without View All Profiles.

Assign Use Any API Auth Permission for SOAP login(). This makes the PermissionsUseAnyApiAuth permission mandatory for SOAP API login() calls. Any user without it gets an error instead of a session.

This is the one worth your Monday morning. The permission arrived in Summer '26 and has been enforced by default in newly created orgs since, so most teams have never had to think about it. Integration users are the exposed group, because they are usually provisioned from a stripped-down profile that grants the minimum, and nobody grants a permission deliberately when the platform has never asked for it. The check takes five minutes: query Login History filtered to SOAP API logins over the last ninety days, list the distinct users, and confirm each one holds the permission.

Worth pairing with a longer date. SOAP API login() itself retires on June 1, 2027, so granting the permission buys you nine months, not a solution. The migration target is the same one the OAuth change points at: external client apps with a proper OAuth flow.

The other three release updates in Winter '27 are Lightning Experience accessibility improvements for viewing at 200% zoom and above, aligned with WCAG 2.2. They need no action in most orgs. Order Management teams have one more, a change to tax rate calculations and adjustments, and any change that alters a calculated number deserves a test against your cancellation and refund paths.

The Checklists Disagree

This is the part that matters more than any single item on the list.

Right now, published Winter '27 checklists contradict each other. Salesforce Ben's release preparation page still lists Adopt Authorized Email Domains and Update Instanced URLs among the updates enforcing this release, with a reader comment underneath pointing out that the OAuth retirement is no longer in Winter '27. Software Insights has the current picture, with the three departures and their new dates. Our own August 19 piece counted eight release updates with five touching authentication or permissions, which was accurate against the release notes that morning and is not accurate today.

None of those sources was careless. Release updates get rescheduled after the notes publish, sometimes days after, and every static list starts decaying the moment it is written. This one included.

So treat the authoritative list as the one your own org shows you. Open Setup, go to Release Updates, filter to the ones due for enforcement in this release, and read what is actually there. That node reflects your org's edition, its enabled features and its current state, which is why it will sometimes show you fewer items than a blog and occasionally more. It costs two minutes and it is the only version that is true for you.

Wave One Already Shipped

The rollout calendar has the same problem as the enforcement list, which is that the widely quoted version is a simplification.

Most guides describe three production waves. Trust lists five Winter '27 major release dates: August 29, September 5, October 3, October 9 and October 10, 2026. The distribution is heavily uneven. Roughly 110 production instances went on Saturday and about 10 more go this coming Friday, then the volume arrives in October, with roughly 97 instances on October 9 and roughly 152 on October 10.

If your org was in Saturday's group, Winter '27 is not a plan, it is your production environment, and the two enforcing updates above are live behaviour right now.

For everyone else, the preview window opened today. Sandboxes on preview instances upgraded across Friday and Saturday, and the cutoff to land a sandbox on a preview instance was 6:00pm Pacific on August 27. That cutoff has teeth: refresh a preview sandbox after it and the sandbox drops back to Summer '26, taking your testing window with it. If you missed it, a pre-release org will let you explore the new features, but it holds none of your metadata and none of your data, so it cannot tell you what breaks.

One scheduling note for the calendar. Dreamforce runs September 15 to 17 at Moscone Center, which lands between the first two production waves and the October pair. If your instance upgrades on October 9 or 10, the people you would want testing in September are the people who will be in San Francisco or watching the keynote. Plan the regression sweep for the first two weeks of September instead.

The Deadline That Did Not Move

While three platform deadlines slid, the one aimed at people did not.

Tomorrow, August 31, is the last day it is possible to sit any of the 24 certifications Salesforce is retiring. Registration for those exams closed back on July 24, so this deadline only affects candidates who already booked a seat. Pass tomorrow and the credential is awarded normally and stays on your Trailblazer profile after the formal retirement date of February 1, 2027. Miss it and the exam is gone.

Put the whole sequence in one place and the shape is clear. August 31 for the certifications. December 1 for the email verification exception. February 1 for the certification retirements taking effect. February 20 for the OAuth flow. Spring '27 for instanced URLs. June 1, 2027 for SOAP login().

Five of those six are authentication or identity changes. The direction has not changed at all. Only the pacing did.

What To Do This Week

Five things, and the first one replaces every checklist you have bookmarked.

Read your own Release Updates node. In a preview sandbox, filter to updates enforcing this release. Whatever that list says is your list. Delete the others.

Run the SOAP API query today. Pull Login History filtered to SOAP API logins for the last ninety days, list the distinct users, and check each one for Use Any API Auth. This is the update most likely to break something in an org that did no Winter '27 preparation at all, precisely because nobody was told to prepare for it.

Test profile filtering with login-as. Not as yourself. Pick your most restricted standard profile, run your busiest record page and your two most complicated flows, and look for blank profile values rather than errors.

Do not unwind your OAuth work. February 20, 2027 is a postponement, not a reprieve, and SOAP login() dies on June 1 regardless. If you built the client credentials flow or moved to external client apps in August, ship it. The extra months are for the integrations you had not found yet, not for reverting the ones you fixed.

Diarise December 1. If Salesforce Support ever disabled Email Change Verification for your org, you have a DKIM key or an authorized email domain to configure before then, and you want that done outside a user migration rather than in the middle of one.

The pattern across this release is that Salesforce keeps pulling the loud, breaking changes back while letting the quiet permission changes go through on schedule. That is a defensible way to run a platform used by millions of people, and it does mean the update that actually catches you this cycle is the one nobody wrote a countdown post about.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.