Many organisations rely daily on integrations between Salesforce and other systems. Consider forms on a website, donation pages, customer portals, marketing tools, payment providers, backup solutions, or bespoke applications. Often, these integrations have been working for years without much scrutiny.
But precisely there, an important security concern is now arising.
Salesforce is implementing significant security changes around Connected Apps and authentication starting in August and September. At the same time, Salesforce is moving further away from older connection methods where external systems gain access to Salesforce via a username, password, and optionally a security token. The OAuth username-password flow is discouraged by Salesforce because it involves sending credentials. Salesforce advises organisations to use more secure OAuth flows, such as the Client Credentials Flow for server-to-server integrations.
So for organisations, this is not just a technical topic. The real question is:
Will our processes continue to work as usual in August and September, and are our integrations set up securely enough?
What is it precisely about?
Salesforce is often linked to systems outside of Salesforce. For example:
- a website form that sends leads, donors or sign-ups to Salesforce;
- a customer portal that retrieves data from Salesforce;
- a donation or payment process that writes back data;
- a custom application that synchronises data periodically;
- external tooling for marketing, reporting, backup, or administration.
Modern integrations typically use OAuth 2.0. This grants an application access via tokens and well-configured client credentials, rather than via a standard Salesforce username and password.
The risk lies particularly with older or custom integrations that were once made to “just work”. Think of a web developer who linked a form to Salesforce years ago, an external portal provider retrieving data, or a technical user who gains access via an old authentication method.
What could go wrong?
There are two types of risks.
- The clutch stops working
If Salesforce blocks an outdated authentication method, or if a connected app no longer meets new requirements, an external integration may lose access. This could result in data no longer being received in Salesforce. Consider form submissions, donations, applications, portal data, or other operational data. - The coupling continues to work, but is not sufficiently secure
A working connection is not automatically secure. If an external application still works with a username and password, you are effectively managing sensitive login credentials outside of Salesforce. Salesforce advises against this approach, recommending more modern OAuth flows instead.
Which couplings do you need to check now?
In any case, check:
Website forms
Does information from your website automatically go into Salesforce? If so, how does that integration authenticate?.
Donation or payment flows
Are donations, transactions or payment details automatically processed in Salesforce? Check which party is the initiator of the connection and which authentication method is used.
Customer portal or member areas
Does an external portal retrieve data from Salesforce, or does it write data back? If so, that's an important point to consider.
Bespoke applications
Everything that is specifically built for your organisation deserves extra attention. It is precisely there that older authentication methods might still be in use.
AppExchange apps and standard packages
With well-known suppliers, there's a greater chance they will follow these changes, but don't assume this blindly. Check if the app is installed correctly, what authentication method is being used, and whether the supplier takes action where necessary.
What should you ask your supplier?
Send this question to your web builder, portal supplier, implementation partner, or software vendor:
We want to check if our Salesforce integration is set up securely and is future-proof in connection with the Salesforce security changes from August and September. Can you confirm which authentication method the integration uses? Is it still logging in with a Salesforce username, password, and possibly a security token, or are you using a modern OAuth 2.0 flow such as Client Credentials Flow, JWT Bearer Flow, or Authorization Code Flow with PKCE where relevant?
Could you also confirm whether the integration is suitable for Salesforce External Client Apps and the current Salesforce security guidelines?
Step-by-step plan
Step 1: List all Salesforce integrations
Think about websites, forms, donation platforms, portals, marketing tools, middleware, custom applications, and AppExchange solutions.
Step 2: Determine who the initiator is
Does the connection originate from Salesforce, or does an external system log into Salesforce? The latter especially warrants attention.
Step 3: Check if username-password is still in use
Explicitly ask if the integration is still using a Salesforce username, password, and, if applicable, a security token.
Step 4: Migrate to a modern OAuth flow where necessary
For server-to-server integrations, the Client Credentials Flow is often a logical option. Salesforce lists this flow as a more secure alternative to OAuth username-password in server-to-server scenarios.
Step 5: Test before August and September
Don't wait until just before the deadline or until a link actually stops working. Test to ensure forms, donations, portals and synchronisations continue to work correctly after security has been adjusted.
How TwoPurpose can help
TwoPurpose can assist with a targeted Salesforce Integration Security Check. Together, we will identify which external systems have access to Salesforce, which authentication method is used, and where action is required.
This is how you prevent a technical detail from suddenly becoming a process problem.
Do you want to know if your Salesforce integrations will continue to work securely from August and September? Have your integrations checked in time.
Sources and further information
This article uses the official Salesforce documentation on Connected Apps, OAuth authentication, and integration security.
-
Salesforce Help — Migrate from OAuth Username-Password to Client Credentials Flow Salesforce elaborates on why the OAuth Username-Password Flow is no longer the recommended method for integrations and how organisations can migrate to more modern authentication methods such as Client Credentials Flow.
-
Salesforce Help — Prepare for Connected App Usage Restrictions Change Salesforce describes a security change in which the use of uninstalled Connected Apps will be restricted from early September 2025. This update is part of Salesforce's move towards “secure-by-default”.
-
Salesforce Help — Block Authorisation Flows to Improve Security Salesforce indicates that the OAuth 2.0 user-agent flow and username-password flow are considered insecure and advises organisations to block these flows for improved security.
-
Salesforce Help — OAuth 2.0 Client Credentials Flow for Server-to-Server Integration Salesforce describes the Client Credentials Flow as a more secure alternative for server-to-server integrations, utilising client credentials and an integration user.
-
Salesforce Help — OAuth 2.0 Web Server Flow for Web App Integration Salesforce advises for web applications to use the Web Server Flow with PKCE as a more secure alternative to, among other things, the username-password flow in specific scenarios.
