Salesforce Winter ’27: Four Security Enforcements You Need to Prepare For

In our recent Salesforce Security Office Hours, Tom Bassett shared what admins need to know about the Salesforce Winter ’27 security updates. Four security enforcements are scheduled to take effect when your org upgrades to Winter ’27. Each one can break existing integrations, automations, or configuration, and each takes effect on your upgrade date whether or not you have prepared for it.

The four changes share a common thread worth naming up front, because it affects how you should prioritize. Each one targets access that was granted once and never reviewed again. That is also the pattern behind the recent breaches. When Microsoft Threat Intelligence published its account of a year of Salesforce intrusions on July 13, 2026, every path it described ran on access the org itself had authorized, with no platform vulnerability and no malware involved. Winter ’27 is, in large part, a prompt to find those connections and clean them up.

Salesforce has not published the Winter ’27 release notes yet, so the current source of truth is the release update list carried over from Summer ’26. Enforcement begins from September 2026 and varies by instance. To find your exact date, go to Salesforce Trust Status, search for your My Domain name or instance, and open the maintenance tab. Note that sandboxes upgrade to a new release ahead of production, so these enforcements can land in a sandbox first. That is useful rather than alarming, because it gives you a live preview of what will happen in production, but only if you know to expect it.

Change 1: The OAuth username and password flow retires

Salesforce is retiring the OAuth 2.0 username and password flow, also called resource owner password credentials, for connected apps in Winter ’27. The reason is straightforward. That flow passes a real username and password directly in the body of the HTTP request on every call, which is exactly the pattern modern authentication is built to eliminate. Any connected app integration still using it will stop authenticating on your upgrade date. If you do not see the Retirement of OAuth 2.0 Username-Password Flow for Connected Apps release update in Setup, the flow is already blocked in your org and this change does not affect you.

The trap here is that these integrations are usually old, invisible, and load-bearing. Someone wired a nightly job or a middleware connection years ago, it has run quietly ever since, and nobody has touched it. These are the integrations most likely to fail without anyone noticing until they do.

Finding them is a login history exercise. In Setup, open Login History and filter on the login subtype of OauthUsernamePassword, then download the results or build a custom list view. Compare the Application column against your connected apps OAuth usage to tie each hit back to a specific app. If you prefer to work in code, you can run a query against the OauthToken object in the Developer Console under Query Editor, ordering by last used date, to see which tokens are still being issued through this flow. Whichever route you take, remember that login history retains only six months. A quarterly batch job or a disaster recovery integration that runs less often than that will not appear at all, so reconcile against your own inventory rather than trusting the export to be complete.

Once you know what is affected, pick the right replacement rather than the nearest one. For a server to server integration with no human in the loop, move to the OAuth 2.0 client credentials flow bound to a dedicated integration user carrying a scoped permission set. For anything user facing where the audit trail needs to name a person, use the web server flow with PKCE, which returns a token scoped to that user’s permissions. If the integration belongs to a managed package you cannot refactor, contact the vendor now for their Winter ’27 statement, because their timeline is not the same as yours. Salesforce stopped allowing the creation of connected apps back in Spring ’26, so your migration target is an External Client App in every case. Rebuild each integration, test it end to end in a sandbox, then disable the flow yourself in Setup under OAuth and OpenID Connect Settings once nothing depends on it. Do not wait for Salesforce to switch it off for you. One caution on rollback: you can re-enable that setting yourself only until Salesforce enforces the block on your upgrade date, and after that there is no toggle back, which is exactly why proving the replacement in a sandbox first is not optional.

Change 2: Profile filtering hides profile names

Today, a user in your org can read the profile names of other users without holding the View All Profiles permission. Winter ’27 closes that gap through a setting called profile filtering, which becomes the enforced default. Once it is on, users see only their own profile name unless they hold View All Profiles or one of a handful of administrative permissions.

The reason this matters as a security change, and not just a cosmetic one, is that a readable list of profiles is reconnaissance. Attackers rarely start at the admin account. They compromise a low privilege user, then look for a path upward, and a list of every user and their profile tells them which accounts are worth the effort and which are not. Removing that visibility takes a step out of the information gathering phase.

The reason it matters as an operational change is that its reach is wider than most admins expect. Anything in your org that resolves a profile name off a record the running user does not own is a dependency nobody has had to think about before, and any of it can break. The clean way to tell the difference is the reference itself. A formula or query that walks a lookup to somebody else’s profile, such as Owner.Profile.Name on a Case, is at risk. Anything that resolves the running user’s own profile through the $Profile global variable is safe, because that variable always resolves to the person executing. Scan your validation rules, flows, approval processes, sharing rules, Experience Cloud audiences, Apex, Lightning Web Components, Aura components, reports, list views, dashboards, custom metadata, and formula fields for the at-risk pattern. Managed packages can depend on it too, which is another reason to raise Winter ’27 readiness with your vendors early.

A few things the documentation does not put in bold. View All Profiles is the fallback, not the fix, and granting it broadly simply reopens the visibility the update was closing. Per Salesforce’s own Limit Profile Details to Required Users documentation, seven other permissions still expose profile names even with filtering on: Customize Application, Manage Users, Manage Profiles and Permission Sets, Create and Set Up Experiences, Manage Customer Users, Manage External Users, and Delegated External User Administrator. With filtering enabled, users also cannot create or edit login flows without View All Profiles, because assigning a flow requires reading the profile name. You can turn profile filtering on in a sandbox from User Management Settings to test all of this safely before it enforces. If you run Experience Cloud, pay particular attention here, because profile filtering was designed in part to stop guest and site users from reading your internal profile names.

Change 3: Email verification loses its escape hatch

For years, if you needed to move a block of users to a new email domain, you could ask Salesforce Support to switch off email change verification so the system would not challenge every updated address. Winter ’27 retires that ability. Support will no longer be able to disable the check, and going forward you verify each domain yourself with an active DKIM key or an authorized email domain, in both sandbox and production.

This one affects orgs that update user email addresses in bulk, which in practice means migrations, mergers, and domain renames. But the more important point is architectural. Email is now an authenticated channel in Salesforce. The platform already began dropping outbound mail from unverified domains earlier in 2026, and this change removes the last human override on the user email side of that same system.

The failure mode is what makes it worth attention. Some features check the domain first and show the user an error they can act on. Others hand the message to the mail server and log a 550 5.7.1 delivery not authorized, message discarded. There is no exception and no bounce, so if an automation sends that email, nothing surfaces the failure and error-count monitoring never sees it. The only record is in Setup under Email Logs. The takeaway for admins is to alert on successful delivery, not on failure, because a silent drop produces no failure to alert on.

To prepare, verify each of your email-sending domains and subdomains. Salesforce prefers a DKIM key because it also signs your outbound mail, and it rotates the key automatically once active. If you cannot get the DNS record added, an authorized email domain configured in Setup satisfies the requirement without the deliverability benefit. Salesforce Ben’s walkthrough on the difference between the two methods is a useful companion if you are choosing between them. To minimize disruption for users whose domains you cannot verify, such as consultants and Experience Cloud site users, enable the substitute email domain option on the Deliverability page so Salesforce relays their mail on your behalf.

Change 4: Instanced URLs in API traffic stop resolving

Salesforce has been redirecting API calls aimed at an instance host, such as na45.salesforce.com, to your org’s My Domain host. That redirect ends on a rolling basis shortly after Winter ’27 deploys. The call, the payload, and the endpoint path all stay identical. Only the host matters, and only the instance host is the problem. A call to na45.salesforce.com/services/data stops working, while the same call to acme.my.salesforce.com/services/data keeps working.

Using an instance name has been an anti-pattern for a long time, because your instance can change and the instance host presents a larger attack surface than your dedicated My Domain. This update was first introduced in Summer ’25 and has been postponed twice, which is why teams stopped tracking it. A third postponement is unlikely, partly because the redirect itself consumes Salesforce infrastructure that they would like to stop running. Tom Bassett’s Salesforce Winter ’27 release guide on Salesforce Ben covers this change alongside the other three if you want the full release context.

The difficulty is that the offending host is usually buried in configuration you do not look at often: middleware and ETL connection settings, standing scripts, managed package settings you cannot read as a subscriber, and Apex or Visualforce making callbacks with a hard-coded instance name. Login history offers clues about entry points in some cases, but it will not catch everything. The reliable move is to test rather than guess. In Setup under My Domain, Redirections, there is an option to block API traffic that uses an incorrect instanced URL. Turn it on in a sandbox and watch what fails, then fix each caller to use your My Domain before you enable it anywhere near production.

The permissions-in-profiles retirement was cancelled, but the work remains

If you spent the last few years planning to move every permission out of profiles, stop and read this carefully, because the deadline is gone. On June 6, 2026, Salesforce confirmed in a knowledge article that the retirement of permissions in profiles is cancelled. Not delayed, cancelled, citing customer feedback and remaining feature gaps.

What did not get cancelled is the direction. Salesforce still recommends a permission set led model, with profiles carrying only baseline settings such as default apps, page layout assignments, and login hours. All future investment is going into permission sets and permission set groups, and profiles are done receiving new features. According to the SF Ben Admin Survey 2026, only 20.5 percent of organizations have fully moved to a permission set led model, which means nearly eight in ten orgs are still running on a model Salesforce has been steering away from for years. The forced date is gone. The security case for least privilege is not, and the phishing-resistant MFA scope that rolled out this summer proved the point, because those admin-level permissions travel through permission sets, not just the system administrator profile.

What to do before September

Treat the enforcement calendar as an input, not as architecture. Salesforce delayed the instanced URL change twice, cancelled the profile permission retirement after nearly four years, and paused and restarted the MFA rollout inside a few weeks. Design for the control, and let the date be the deadline that finally makes the work happen. Tom walks through each of these audits in the full session.

Start with discovery, because you cannot fix what you have not found. Query the OauthToken object and filter login history on OauthUsernamePassword, and name an owner for every result. Revoke every OAuth grant to a third-party app that has no current business owner, because an abandoned, over-permissioned grant is exactly how these breaches start. Email every managed package vendor for their Winter ’27 statement, since you cannot read their configuration yourself. And search your Apex, Visualforce, middleware, and ETL configs for hard-coded instance hosts.

Then do the remediation while you still have runway before your instance upgrades. Rebuild each affected integration as an External Client App on the client credentials or web server with PKCE flow, bound to a scoped permission set. Scan your metadata for Owner.Profile.Name and equivalent references, then refactor them rather than papering over the change with View All Profiles. Configure a DKIM key or authorized email domain in both sandbox and production. Enable the incorrect instanced URL block in a sandbox and regression test every integration against it. Then check Trust for your instance’s actual upgrade date, because Winter ’27 rolls out as a range, not a single day.

You will know you are finished when every integration authenticates through an External Client App with a scoped permission set, every sending domain is verified, every OAuth grant is owned and dated, and no code resolves another user’s profile name. That is the durable posture these four changes are collectively pushing your org toward, and reaching it is the point.

Bring your toughest Salesforce Security questions to the next Office Hours

Reading about these changes is one thing. Working out which of them apply to your org, in what order, and what breaks if you get the sequence wrong is another, and it is a lot faster with a Salesforce security expert on the line. That is what Salesforce Security Office Hours is for. Every session pairs Matt Meyers, CTA and CoFounder and CEO of EzProtect, with a guest who works this material daily, and every session is built to send you back to your org with something you can action the same day. You can raise your hand, put your specific situation in front of the room, and leave with an answer rather than a reading list. Register for the next one and bring your toughest Salesforce security questions.