There are integrations connected to your Salesforce that have been running for years without anyone looking at them. A website form that brings in leads. A donation page that passes transactions. A customer portal that pulls records. They just work. Until they do not.
Since 2025, Salesforce has been rolling out a multi-year move toward “secure by default.” Some of those changes are already active. The rest are scheduled for 2026 and 2027. The message is consistent: integrations that log in with a username and password, or that are not formally registered as an app in your org, will be blocked or stop working. Not maybe. On a fixed deadline.
For most organizations we speak with, this is not something actively on the radar. That is precisely the risk.
What has already changed (September 2025)
Two changes are already in effect, with no switch to flip.
Uninstalled Connected Apps are blocked. Until recently, users could authorize an external app that was not formally installed in the org. That is no longer possible. Apps not installed via a package or via Setup are inaccessible to most users. Users who had already authorized such an app before the change can still use it. Anyone new cannot. This is exactly the pattern exploited in vishing attacks throughout 2024 and 2025, where employees were called and persuaded to authorize a malicious app.
The OAuth 2.0 Device Flow has been removed. As of September 2, 2025, permanently, with no exceptions. This flow let users approve an app on a different device using a code, the exact scenario that makes social engineering attractive. The old Data Loader relied on this flow. Updating to a newer version was the required fix.
What is coming: the hard deadlines
This is the part that requires action now.
Spring ’26: no new Connected Apps. Creating new Connected Apps is no longer possible. Existing apps continue to work, but for anything new, Salesforce directs you to External Client Apps (ECAs). These work “default closed”: an external application can only authenticate if it is explicitly defined or installed in the org. Building new integrations without ECAs is no longer an option.
Winter ’27: end of the OAuth username-password flow. This is the deadline we are warning organizations about right now. Every integration that still logs in with a Salesforce username, password, and security token stops working on this date. It hits exactly the integrations that were set up once and never touched again. They work fine today. After the deadline, they will not.
Summer ’27: end of SOAP API login(). The classic SOAP login method (API versions 31.0 through 64.0) is being retired. In new orgs, an early version of this restriction is already active: users need the Use Any API Auth permission to authenticate via SOAP. Many older middleware solutions and custom integrations still use this method, often without the current administrator knowing it.
Two ways this goes wrong
The integration stops working. That is the visible variant. Form submissions stop arriving. Donations go unprocessed. Portal data stops syncing. It fails silently, with no error message for the end user. What makes it particularly deceptive: a colleague who has been using the integration for years may notice nothing. Their authorization is grandfathered in. A new employee who tries the same thing gets blocked entirely. That kind of inconsistency takes months to be recognized as a structural problem.
The integration keeps working, but is insecure. A working integration is not automatically a safe one. If an external application is still logging in with a username, password, and security token, those credentials are being managed somewhere outside Salesforce, outside your security team’s visibility, outside automatic rotation. Salesforce is phasing this out deliberately. The fact that it works today only means the deadline has not arrived yet.
Which integrations to check now
A quick inventory starts with one question: which external systems talk to our Salesforce, and how do they log in? Website forms that push leads or requests, donation and payment flows, customer portals and member environments, marketing tools that sync contacts, custom-built applications developed specifically for your organization: these are the places where old authentication methods survive the longest.
In Salesforce itself, you can do a quick check via Setup, Connected Apps OAuth Usage. Any app showing an Install button is not formally installed and is at risk. That is the starting point for the audit.
For integrations you did not build yourself, send your web developer, portal provider, or software vendor one concrete question: is the integration still using a Salesforce username, password, and security token to log in, or are you authenticating via a modern OAuth flow such as Client Credentials, JWT Bearer, or Web Server Flow with PKCE? And is the integration ready for External Client Apps?
Modern authentication: what the difference is
The username-password flow has existed for twenty years and was never designed as a permanent solution for server-to-server integrations. The secure alternatives are available and well-established. Client Credentials Flow is the right choice for machine-to-machine integrations where no user is involved. JWT Bearer Flow handles situations where you need to act on behalf of a specific user. Web Server Flow with PKCE is the standard for web applications where an end user signs in. None of these flows require storing a password outside Salesforce.
Want to know which of your integrations are at risk? Blazeforce runs a targeted integration audit: we map which external systems have access to your Salesforce, what authentication method they use, and what needs to change before the 2027 deadlines. Get in touch for a no-obligation conversation.