Voorbereiding op de verplichte MFA-wijzigingen Salesforcein 2026

Nu het stelen van inloggegevens en door AI aangestuurde phishingcampagnes steeds geavanceerder worden, Salesforce de lat voor zijn beveiligingsnormen Salesforce . Als Salesforce Owner, systeembeheerder of zelfs consultant zal het feit dat Salesforce strengere eisen Salesforce meervoudige authenticatie (MFA) voor alle directe UI- en Single Sign-On (SSO)-aanmeldingen gevolgen voor je hebben.

‍
Als Salesforce is het van cruciaal belang om te beseffen dat dit niet langer slechts een aanbeveling in de overeenkomst is, maar een technische maatregel die de toegang van gebruikers kan blokkeren als u hier niet goed op bent voorbereid. Hieronder vindt u een uitgebreide gids over de aanstaande wijzigingen, de gevolgen daarvan voor verschillende gebruikersgroepen en de concrete stappen die nodig zijn om deze wijzigingen soepel door te voeren.

‍
De belangrijkste gevolgen voor gewone gebruikers zijn dat, als je geen vorm van MFA gebruikt of als je tweefactorauthenticatie werkt via een code die naar een e-mailadres of via sms wordt verzonden, je verplicht wordt om een conform MFA-hulpmiddel te gebruiken, zoals Salesforce . De grootste impact zal te merken zijn bij „bevoorrechte gebruikers“. Dit zijn gebruikers met een systeembeheerdersprofiel of machtigingssets die de toegangsrechten „Alles bekijken“ en/of „Alles wijzigen“ bevatten (samen met enkele aanvullende criteria). De gevolgen zijn hier groter, omdat je je nalevingsniveau moet verhogen met een tool die aan deze vereisten voldoet. Dit zal een ingebouwde authenticator zijn die aan een apparaat zoals een computer of telefoon is gekoppeld om het token te genereren. Voorbeelden van applicaties die dit ondersteunen zijn Windows Hello of Apple Touch ID, maar je bent hier niet toe beperkt. Lees hieronder voor de technische vereisten.

‍
Tijdlijn en omvang van de wijzigingen

‍
De handhaving wordt stapsgewijs ingevoerd:

‍

• Sandboxes: De handhaving gaat in op 22 juni 2026 (gespreid over 7 dagen).
• Productie (bevoorrechte gebruikers): De handhaving gaat in op 20 juli 2026 (gespreid over 30 dagen).
• Productie (alle overige gebruikers onder het personeel): De handhaving gaat in op 20 juli 2026 (gespreid over 30 dagen).

‍
Wat niet onder deze maatregel valt: Deze maatregel geldt voor betaalde Production- en Sandbox-organisaties voor interne medewerkers. De maatregel geldt niet voor Experience Cloud-/Community-gebruikers, noch voor niet-betaalde omgevingen zoals de Developer Edition, proefversies of scratch-organisaties. Bovendien zorgt de machtiging „Multi-factor-authenticatie opheffen voor vrijgestelde gebruikers” er niet langer automatisch voor dat gebruikers worden vrijgesteld; beheerders moeten contact opnemen met Salesforce voor geldige uitzonderingen, zoals geautomatiseerde testtools.

‍

Gevolgen voor gebruikersgroepen

‍
Salesforce de authenticatievereistenSalesforce op basis van gebruikersrechten en hanteert daarbij strengere minimumnormen voor gebruikers met uitgebreide rechten.
‍

1. Bevoegde gebruikers (systeembeheerders)

‍
Een „bevoorrechte gebruiker“ wordt gedefinieerd als iedereen aan wie het profiel „Systeembeheerder“ is toegewezen, of iedereen met de volgende rechten (ook via rechten sets): „Alle gegevens wijzigen“, „Alle gegevens bekijken“, „Toepassing aanpassen“ of „Apex schrijven“. Met deze rechten kan de gebruiker naar eigen inzicht met de gegevens omgaan; hoewel ze in de juiste handen zeer krachtig zijn, kunnen ze in de verkeerde handen grote schade aanrichten.

‍

• De gevolgen: Standaard TOTP-authenticatie-apps (zoals Google Authenticator of Microsoft Authenticator) en mobiele pushmeldingen worden voor deze gebruikers niet langer geaccepteerd, omdat ze kwetsbaar zijn voor ‘Adversary-in-the-Middle’-phishingaanvallen en MFA-moeheid. Met andere woorden: dit zijn technieken waarbij een aanvaller de inlogcode overneemt en deze op zijn eigen apparaat kan gebruiken. De nieuwe vereiste tokens kunnen alleen worden gebruikt op het apparaat waarop ze zijn gegenereerd.
• De vereiste: Gebruikers met beheerdersrechten moeten gebruikmaken van phishingbestendige MFA. Hierbij wordt gebruikgemaakt van de WebAuthn- en FIDO-standaarden om het echte inlogdomein te verifiëren. Toegestane methoden zijn onder meer ingebouwde authenticatiemiddelen (bijv. Apple Touch ID, Face ID, Windows Hello) of fysieke hardwarebeveiligingssleutels (bijv. YubiKey, Google Titan).

‍

‍
2. Gebruikers zonder speciale rechten (gewone medewerkers)

‍
Deze groep omvat alle gebruikers die niet over de hierboven genoemde bevoegdheden beschikken.

‍

• De gevolgen: Deze gebruikers zijn onderworpen aan een technisch afgedwongen instelling die voor de hele organisatie geldt: „Vereis meervoudige authenticatie (MFA) voor alle directe aanmeldingen via de gebruikersinterface bij uw Salesforce ”.
• De vereiste: Gebruikers zonder speciale rechten mogen gebruikmaken van standaard MFA. Hieronder vallen de Salesforce , TOTP-oplossingen van derden, zoals de Google Authenticator-, Salesforce Authenticator- Salesforce Microsoft Authenticator-apps, of methoden die bestand zijn tegen phishing. Eenmalige toegangscodes die via e-mail, sms of telefoongesprekken worden verzonden, voldoen niet aan deze vereiste.

‍
3. Gebruikers van Single Sign-On (SSO)

‍
Als uw organisatie gebruikmaakt van een SSO-identiteitsprovider (IdP) zoals Okta of Azure AD, moet MFA op IdP-niveau worden afgedwongen.

‍

• De gevolgen: SSO alleen voldoet niet aan de vereiste. De IdP moet specifieke authenticatieclaims doorgeven in de SAML-payload of het OIDC-token — met name de AMR- (Authentication Methods Reference) of ACR- (Authentication Context Class Reference) signalen.
• De vereiste: Als Salesforce geldig signaal Salesforce dat overeenkomt met het vereiste beveiligingsniveau van de gebruiker (Standaard of Phishing-bestendig), wordt de gebruiker gevraagd om rechtstreeks in Salesforce een MFA-methode te registreren.

‍
(Opmerking: Hoewel de verstrekte bronnen uitgebreid ingaan op de configuratie Salesforce, is aanvullende informatie uit externe webbronnen — met name de documentatie van uw identiteitsprovider (bijv. Okta, Microsoft Entra ID) — nodig om de toewijzing van AMR/ACR-claims aan de SAML/OIDC-payload succesvol te configureren.)
‍

4. Gebruikers van Salesforce

De verplichte toepassing van MFA, zowel voor standaard- als voor phishingbestendige vereisten, is uitsluitend van toepassing op het inloggen van medewerkers via de gebruikersinterface. Daarom heeft deze wijziging geen invloed op aanmeldingen die uitsluitend via de API plaatsvinden.

‍

Voor uw systeemintegraties worden de verschillende authenticatieprocessen als volgt afgehandeld:

‍

• Stromen die niet worden beïnvloed: Aangesloten apps of externe client-apps die gebruikmaken van headless-stromen, zoals JWT Bearer- of Client Credentials-stromen, worden hierdoor helemaal niet beïnvloed, omdat hiervoor geen aanmelding via de gebruikersinterface nodig is.

• Betrokken procedures: Als uw integratie gebruikmaakt van de OAuth-webserver- of hybride-tokenprocedures, waarbij een gebruiker zich moet aanmelden bij de Salesforce om het autorisatieproces te voltooien, geldt voor die specifieke aanmeldingsstap in de gebruikersinterface de verplichte MFA-verificatie.

Implementatiestappen

‍
Om te voorkomen dat op een maandagochtend in juni of juli grote aantallen gebruikers worden buitengesloten, kunnen de volgende implementatiestappen worden uitgevoerd (let wel: deze moeten worden beschouwd als richtlijnen en niet als een gegarandeerd, vastomlijnd framework, aangezien andere factoren het resultaat kunnen beïnvloeden):

‍
Stap 1: Controleer de huidige toepassing van MFA en de gebruikersrechten

‍

• Voer de gratis MFA-vereistenchecker uit in Setup om de uitgangssituatie van je organisatie vast te stellen. Klik op hier. ​​
• Controleer de gebruikersrechten. Gebruik SOQL-query’s om alle gebruikers te identificeren die het profiel ‘Systeembeheerder’ hebben of de velden ‘PermissionsModifyAllData’, ‘PermissionsViewAllData’, ‘PermissionsCustomizeApplication’ of ‘PermissionsAuthorApex’.
• Controleer de inloggeschiedenis om na te gaan of uw SSO-provider momenteel geldige AMR/ACR-signalen doorgeeft.

‍
Stap 2: Schakel phishingbestendige methoden in tijdens de installatie

‍

• Ga naar Instellingen → Identiteitscontrole.
• Schakel de volgende instellingen in: „Gebruikers toestaan hun identiteit te verifiëren met een ingebouwde authenticator (passkey), zoals Touch ID of Windows Hello” en „Gebruikers toestaan hun identiteit te verifiëren met een fysieke beveiligingssleutel (passkey), zoals U2F of WebAuthn”.
• (Optioneel, maar aanbevolen): Schakel de optie „Wachtwoordloos inloggen met passkeys toestaan” in om het inlogproces te vereenvoudigen voor gebruikers die hardware-sleutels of biometrische gegevens gebruiken.

‍
Stap 3: Registratie van het apparaat van de gebruiker

‍

• Voor gebruikers met speciale rechten: laat hen naar Persoonlijke instellingen → Geavanceerde gebruikersgegevens gaan en de rij „Ingebouwde authenticatiemiddelen” of „Beveiligingssleutels” zoeken om hun apparaten te registreren. Het wordt ten zeerste aanbevolen dat beheerders ten minste twee methoden registreren (bijvoorbeeld biometrische authenticatie via een laptop of telefoon en een reservehardwaresleutel) om te voorkomen dat ze buitengesloten raken.
• Voor gebruikers zonder speciale rechten: Zorg ervoor dat zij de Salesforce of een goedgekeurde TOTP-app hebben gedownload en aan hun account hebben gekoppeld.

Stap 4: SSO-configuratie bijwerken

‍

• Werk samen met uw Identity Management-team om ervoor te zorgen dat uw SSO-provider zo is geconfigureerd dat deze geldige AMR- of ACR-attributen doorgeeft.
• Voor gebruikers met beheerdersrechten moet de SAML-payload signalen bevatten die phishing tegengaan (bijv. fido, hwk, passkey, vbm) om te voorkomen dat er een tweede Salesforce .

‍

Stap 5: Communicatie en testen

‍

• Test de volledige registratie- en SSO-aanmeldingsprocessen in een sandbox-omgeving vóór de ingangsdatum van 22 juni. Let op: zodra je de toegangscode hebt ingesteld, moet je je in sommige cases afmelden en het vakje ‘Onthoud mij’ aanvinken.
• Stuur uw gebruikers tijdig een bericht waarin u de nieuwe vereiste uitlegt en handleidingen verstrekt voor het registreren van hun authenticators of hardwaresleutels. Stel interne procedures op voor het herstellen van de toegang, zodat beheerders tijdelijke verificatiecodes kunnen genereren als een gebruiker is buitengesloten.

‍

Hulp nodig?

‍

Bij Gen25 helpen we organisaties hun huidige situatie in kaart te brengen, potentiële risico’s te identificeren en een praktisch stappenplan op te stellen om aan de vereisten te voldoen. Van beoordelingen van de gereedheid voor MFA en validatie van SSO tot het inwerken van gebruikers en verandermanagement: wij kunnen zorgen voor een soepele overgang met minimale verstoring van uw bedrijfsvoering.
Wilt u weten hoe wij uw organisatie bij deze veranderingen kunnen helpen? Neem dan contact op met ons team!

‍

Ryan Farnaby, commercieel directeur VK
r.farnaby@gen25.com
+447368 641599

‍

Joris van Wessem, Account Executive NL
j.vanwessem@gen25.com
+31611274732

‍