Er zijn koppelingen in jouw Salesforce die al jaren draaien zonder dat iemand ernaar heeft omgekeken. Een websiteformulier dat leads binnenbrengt. Een donatiepagina die betalingen verwerkt. Een klantenportaal dat gegevens synchroniseert. Ze doen het gewoon. Totdat dat niet meer het geval is.
Salesforce is bezig met een meerjarige beweging richting “secure by default”. Een deel van die wijzigingen is al actief. De rest staat gepland voor 2026 en 2027. De boodschap is steeds dezelfde: koppelingen die inloggen met een gebruikersnaam en wachtwoord, of die niet formeel als app in je org zijn geregistreerd, worden geblokkeerd of stoppen met werken. Niet misschien. Op een vaste deadline.
Voor de meeste organisaties die wij spreken staat dit niet bewust op de radar. Juist dat is het risico.
Wat er al is veranderd (september 2025)
Twee wijzigingen zijn al van kracht, zonder dat daar een knop voor omgezet hoeft te worden.
Niet-geïnstalleerde Connected Apps worden geblokkeerd. Een gebruiker kon tot voor kort zelf een externe app autoriseren die niet formeel in de org was geïnstalleerd. Dat kan niet meer. Apps die niet zijn geïnstalleerd via een package of via Setup, zijn voor de meeste gebruikers niet meer bereikbaar. Gebruikers die zo’n app al eerder hadden geautoriseerd, kunnen hem nog gebruiken. Iedereen daarna niet. Dit is precies het patroon dat in 2024 en 2025 werd misbruikt bij vishing-aanvallen, waarbij medewerkers telefonisch werden overgehaald om een kwaadaardige app te autoriseren.
De OAuth 2.0 Device Flow is verwijderd. Per 2 september 2025, definitief, zonder uitzonderingen. Deze authenticatiemethode maakte het mogelijk om een app op een ander apparaat goed te keuren via een code, precies het scenario dat social engineering zo aantrekkelijk maakt. De oude Data Loader gebruikte deze flow. Updaten naar een nieuwere versie was de vereiste stap.
Wat er nog aankomt: de harde deadlines
Dit is het deel dat nu actie vraagt.
Spring ’26: geen nieuwe Connected Apps meer. Nieuwe Connected Apps aanmaken is niet langer mogelijk. Bestaande apps blijven werken, maar voor alles wat nieuw is wijst Salesforce naar External Client Apps (ECA’s). Die werken “default closed”: een externe applicatie kan pas authenticeren als die expliciet in de org is gedefinieerd of geïnstalleerd. Nieuwe koppelingen bouwen zonder ECA’s is daarmee geen optie meer.
Winter ’27: einde van de OAuth username-password flow. Dit is de deadline waarvoor we organisaties nu al waarschuwen. Elke integratie die nog inlogt met een Salesforce-gebruikersnaam, wachtwoord en security token stopt op dit moment met werken. Het raakt precies de koppelingen die “ooit werkend zijn gemaakt” en sindsdien nooit zijn aangepast. Ze draaien vandaag nog prima. Na de deadline niet meer.
Summer ’27: einde van SOAP API login(). De klassieke SOAP-loginmethode (API-versies 31.0 tot 64.0) wordt uitgeschakeld. In nieuwe orgs is een voorloper al actief: gebruikers hebben de permissie Use Any API Auth nodig om via SOAP te authenticeren. Veel oudere middleware en maatwerk-koppelingen gebruiken deze methode nog, vaak zonder dat de huidige beheerder dat weet.
Twee manieren waarop dit misgaat
De koppeling stopt met werken. Dat is de zichtbare variant. Formulierinzendingen komen niet meer aan. Donaties worden niet verwerkt. Portaalgegevens synchroniseren niet. Het stopt stil, zonder foutmelding aan de eindgebruiker. Wat het extra verraderlijk maakt: een collega die de koppeling al langer gebruikt, ziet misschien niets. Diens autorisatie is grandfathered. Een nieuwe medewerker die hetzelfde probeert, komt nergens. Dat soort inconsistentie duurt maanden voordat het als structureel probleem wordt herkend.
De koppeling blijft werken, maar is onveilig. Een werkende koppeling is niet automatisch een veilige. Logt een externe applicatie nog in met gebruikersnaam, wachtwoord en security token, dan worden die inloggegevens ergens beheerd buiten Salesforce, buiten het zicht van je beveiligingsteam, buiten automatische rotatie. Salesforce faseert dit bewust uit. Het feit dat het vandaag werkt, betekent alleen dat de deadline nog niet is bereikt.
Welke koppelingen moet je nu controleren
Een snelle inventarisatie begint bij de vraag: welke externe systemen praten met onze Salesforce, en hoe loggen ze in? Websiteformulieren die leads of aanvragen insturen, donatie- en betaalstromen, klantportalen en ledenomgevingen, marketingtools die contacten synchroniseren, maatwerk dat specifiek voor jouw organisatie is gebouwd: dit zijn de plekken waar oude authenticatiemethoden het langst overleven.
In Salesforce zelf doe je een snelle check via Setup, Connected Apps OAuth Usage. Elke app met een Install-knop is niet formeel geïnstalleerd en loopt risico. Dat is het startpunt van de audit.
Voor koppelingen die je niet zelf hebt gebouwd, stuur je webbouwer, portalpartij of softwareleverancier één concrete vraag: gebruikt de koppeling nog een Salesforce-gebruikersnaam, wachtwoord en security token om in te loggen, of authenticeren jullie via een moderne OAuth-flow zoals Client Credentials, JWT Bearer of Web Server Flow met PKCE? En is de koppeling voorbereid op External Client Apps?
Moderne authenticatie: wat het verschil is
De username-password flow bestaat al twintig jaar en was nooit bedoeld als permanente oplossing voor server-to-server koppelingen. De veilige alternatieven zijn beschikbaar en bewezen. Client Credentials Flow is de juiste keuze voor machine-to-machine koppelingen waarbij geen gebruiker betrokken is. JWT Bearer Flow werkt voor situaties waarbij je namens een specifieke gebruiker wilt handelen. Web Server Flow met PKCE is de standaard voor webapplicaties waarbij een eindgebruiker inlogt. Geen van deze flows vereist het opslaan van een wachtwoord buiten Salesforce.
Wil je weten welke van jouw koppelingen risico lopen? Blazeforce voert een gerichte integratieaudit uit: we brengen in kaart welke externe systemen toegang hebben tot jouw Salesforce, welke authenticatiemethode ze gebruiken en wat er moet worden aangepast vóór de deadlines van 2027. Neem contact op voor een vrijblijvend gesprek.