De handhaving is afgerond. Salesforce rolde de nieuwe authenticatie-eisen vanaf 20 juli 2026 per release group uit over de productieorganisaties, en op 3 september 2026 was de laatste groep aan de beurt. Dat MFA in Salesforce verplicht is in 2026 is daarmee geen aankondiging meer, maar de stand van zaken in uw eigen org. Dit artikel loopt langs wat er nu geldt en hoe u nagaat of u eraan voldoet.

Wat er nu in elke org geldt

Twee eisen gelden naast elkaar en volgden dezelfde kalender: preview-sandboxes vanaf 10 juli 2026 en productie vanaf 20 juli 2026, uitgerold per release group tot en met 3 september 2026.

  • MFA voor alle medewerkersaccounts. Iedere interne gebruiker die inlogt, via de gebruikersinterface of via single sign-on, moet een MFA-methode gebruiken.
  • Phishing-bestendige MFA voor privileged users. Voor die groep zijn de gewone methoden niet langer genoeg.

Een gebruiker valt in de tweede categorie bij het profiel System Administrator, of bij een van de rechten Modify All Data, View All Data, Customize Application en Author Apex. Dat is in de praktijk een ruimere groep dan alleen uw beheerders: ook een ontwikkelaar of consultant met Author Apex hoort erbij.

Welke methoden nog meetellen

Phishing-bestendig betekent bij Salesforce gebaseerd op FIDO2 en WebAuthn. Deze methoden kwalificeren:

  • security keys, zoals een hardwaretoken;
  • ingebouwde authenticators, zoals Windows Hello, Touch ID en Face ID;
  • passkeys die via een wachtwoordmanager worden gesynchroniseerd;
  • certificaatgebaseerde authenticatie met een x.509-clientcertificaat.

Wat voor privileged users niet meer meetelt: de Salesforce Authenticator-app, codes uit een TOTP-app zoals Google Authenticator of Microsoft Authenticator, en verificatie via sms of e-mail. Een privileged user zonder geldige methode komt niet meer binnen tot er een is geregistreerd. Een respijtperiode is er niet.

Drie dingen die stil misgaan

  • Single sign-on dekt het niet automatisch. Logt uw org in via een externe identity provider, dan bent u alleen uitgezonderd als die provider het MFA-signaal echt meestuurt volgens de ACR- of AMR-standaard. Doet hij dat niet, dan vraagt Salesforce er zelf om.
  • Het recht Waive Multi-Factor Authentication for Exempt Users vrijwaart niet meer. Gebruikers met dat recht krijgen alsnog de vraag zich te registreren. Heeft u een echte uitzondering nodig, bijvoorbeeld voor testautomatisering, dan moet die via Salesforce Support worden goedgekeurd.
  • Integraties lopen tegen de netwerkblokkade aan. Salesforce blokkeert verbindingen via anonimiserende VPN’s, proxy’s en IP-adressen met een slechte reputatie, sinds 24 april 2026 ook voor al het verkeer van connected apps en de API. Het account wordt dan bevroren en de OAuth-refreshtokens ingetrokken. Herstellen vraagt dus niet alleen het account vrijgeven, maar ook een nieuwe autorisatie van de connected app.

Daarnaast kan Salesforce bij afwijkend gedrag om extra verificatie vragen bij gevoelige handelingen, zoals het exporteren van een rapport. Zorg daarom dat elke gebruiker ten minste een geregistreerde verificatiemethode of een actueel e-mailadres heeft staan, anders loopt zo’n export vast zodra het systeem iets ongebruikelijks ziet.

Hoe u dit nu controleert

Begin bij de lijst met privileged users en vraag u per gebruiker af of die rechten er horen. Author Apex of View All Data dat ooit tijdelijk is toegekend, verzwaart nu ook de inlogeis. Kijk daarna welke verificatiemethoden per gebruiker geregistreerd staan, en of uw serviceaccounts en integraties nog een geldig autorisatiepad hebben.

Wilt u dit systematisch laten nalopen in plaats van wachten tot iemand vastloopt? Onze consultancy loopt de rechten- en authenticatie-instellingen van uw org langs en legt vast wat wel en niet klopt. Werkt u ook met publieke portalen, kijk dan naar de rechten van uw Experience Cloud-gastgebruikers: een andere controle, met een ander risico.

Twijfelt u of uw org eraan voldoet? Neem contact met ons op en we lopen het met u door.