Salesforce renforce sa posture sécurité en 2026 avec une série de contrôles qui vont s’appliquer progressivement sur les orgs. Cette évolution n’est pas un simple rappel de bonnes pratiques : elle marque un vrai changement de niveau, avec des exigences datées sur les domaines email, les connexions à risque, les anomalies de login, la MFA et les actions sensibles dans les rapports.
Pour les clients, cela signifie qu’il faut préparer les orgs avant que les contrôles ne s’imposent. Pour les consultants, architectes et intégrateurs, cela veut dire une chose très claire : il faut aider les organisations à passer d’une sécurité “déclarée” à une sécurité réellement mise en œuvre.
Pourquoi cette roadmap change la donne
Pendant longtemps, la sécurité Salesforce a souvent été perçue comme un sujet de configuration ou de conformité. En 2026, Salesforce pousse clairement vers un modèle plus exigeant, avec des mesures qui touchent à la fois l’identité, la messagerie, les accès techniques et les comportements utilisateurs.
Le message est simple : une org peut fonctionner parfaitement sur le plan métier tout en devenant vulnérable si ses domaines d’envoi ne sont pas vérifiés, si ses comptes privilégiés ne sont pas protégés correctement, ou si ses politiques d’accès n’ont pas été mises à jour.
Autrement dit, la sécurité n’est plus un sujet parallèle. Elle devient une partie intégrante de l’architecture Salesforce.
Les grandes échéances à connaître
La première vague concerne la vérification obligatoire des domaines email. Salesforce n’autorise plus l’envoi d’emails depuis des domaines non vérifiés, même si les adresses individuelles sont validées. La logique est désormais claire : si le domaine n’est pas vérifié via DKIM actif ou via une entrée dans la liste des domaines autorisés, l’envoi échoue.
Le calendrier est progressif. Pour les nouveaux domaines d’envoi et certains domaines existants, la vérification a commencé à être appliquée dès le printemps 2026, avec un déploiement par vagues dans les sandboxes puis dans les autres orgs, y compris la production.C’est un point très important pour les clients qui utilisent Salesforce pour des emails transactionnels, des workflows, des alertes ou des automatisations : il faut vérifier très vite ce qui part réellement de la plateforme.
En parallèle, Salesforce renforce la prévention contre les connexions depuis des VPN anonymisants, des proxies et des IP à haut risque. L’enforcement a commencé fin avril 2026 pour les usages liés aux connected apps et aux API.
C’est un signal fort : les connexions techniques et les intégrations ne sont plus considérées comme un simple sujet d’infrastructure, mais comme une surface de risque à contrôler activement.
Autre évolution importante : les Extended Login Anomaly Detections and Containment ont été renforcées au début du mois d’avril 2026. L’idée est d’identifier plus vite les comportements suspects et d’appliquer des mécanismes de confinement plus rapidement.
Pour les équipes sécurité et admin, cela signifie qu’il faut surveiller les impacts potentiels sur les faux positifs, les accès inhabituels et les utilisateurs qui se connectent depuis plusieurs environnements.
Ensuite viennent les changements les plus visibles pour les utilisateurs (voir salesforce) :
la step-up authentication pour certaines activités de reporting, avec disponibilité puis enforcement entre fin mai et mi-juin 2026 ;
les contrôles de step-up authentication pour comportement anormal sur l’export de rapports, à partir de juin/juillet 2026 ;
les Transaction Security Policy Enhancements, disponibles à partir de juin 2026 et réellement appliqués en production à partir de juillet 2026 ;
la MFA résistante au phishing pour les utilisateurs privilégiés, y compris les admins, à partir de fin juin en sandbox puis début juillet en production ;
et enfin la MFA pour tous les employés, avec un déploiement à partir de fin juin en sandbox et de fin juillet en production.
Ce que cela implique pour les clients
Le vrai sujet n’est pas seulement la date d’enforcement. Le vrai sujet, c’est la préparation.
Un client qui découvre ces exigences trop tard risque de devoir changer en urgence sa configuration, ses méthodes d’authentification ou ses pratiques d’envoi d’emails, avec un risque immédiat sur l’activité métier.
Les impacts les plus fréquents seront les suivants :
des emails qui ne partent plus si le domaine n’est pas correctement vérifié ;
des comptes admin ou privilégiés qui doivent passer sur une MFA plus robuste ;
des utilisateurs qui voient apparaître des contrôles supplémentaires au moment d’exporter des rapports ou d’effectuer certaines actions sensibles ;
des connexions API ou applicatives qui sont bloquées si elles utilisent des chemins jugés à risque ;
et, plus largement, une nécessité de revoir la gouvernance des accès et des comportements dans l’org.
Le rôle des partenaires Salesforce
C’est là que les partenaires, consultants et architectes prennent toute leur valeur. Ils ne doivent pas seulement relayer l’information ; ils doivent aider les clients à la traduire en chantier opérationnel.
Le bon réflexe consiste à démarrer par un audit d’impact :
quels domaines email sont utilisés par les automatisations, les flux, les apex et les notifications ?
quels comptes sont considérés comme privilégiés ?
quelles intégrations passent par des IP ou des accès sensibles ?
quelles actions métier pourraient être soumises à du step-up auth ?
quelles politiques de Transaction Security existent déjà, et sont-elles suffisantes ?
Ensuite, il faut construire un plan de remédiation priorisé. Certaines mesures se font vite, comme la vérification des domaines email ou la revue des comptes administrateurs. D’autres demandent plus de coordination, par exemple si le client utilise un SSO, un IdP externe ou des processus d’accès très intégrés au métier.
Enfin, le partenaire doit accompagner la conduite du changement. Une mesure de sécurité imposée sans préparation crée de la friction. Une mesure expliquée, testée en sandbox et communiquée en amont passe beaucoup mieux.
Les actions à lancer maintenant
Le plus efficace est de découper le sujet en quatre chantiers.
1. Email et délivrabilité
Identifier tous les domaines d’envoi, vérifier lesquels sont déjà couverts par DKIM ou par la liste des domaines autorisés, et repérer les automatisations qui pourraient être impactées.
2. Authentification et accès
Lister les comptes admin et les autres utilisateurs privilégiés, vérifier leur méthode d’authentification, et préparer le passage à la MFA résistante au phishing si ce n’est pas déjà le cas.
3. Comportements à risque
Analyser les connexions via VPN, proxy ou IP à risque, revoir les intégrations exposées et anticiper les effets possibles des détecteurs d’anomalies de login.
4. Sécurité transactionnelle
Identifier les activités sensibles dans les rapports et les exports, tester les mécanismes de step-up authentication, et revoir les politiques de sécurité transactionnelle déjà en place.
Une opportunité pour repositionner son rôle
Cette roadmap sécurité n’est pas seulement une contrainte technique. C’est aussi une vraie opportunité pour les intervenants de l’écosystème Salesforce de montrer une valeur plus stratégique.
Un consultant qui sait anticiper ces changements, les expliquer simplement et proposer un plan de traitement structuré devient beaucoup plus qu’un exécutant. Il devient un partenaire de confiance, capable de sécuriser l’usage de Salesforce dans la durée.
Ce qu’il faut retenir
La lecture la plus juste de cette roadmap, ce n’est pas “Salesforce complique les choses”. C’est plutôt : Salesforce impose désormais un niveau de sécurité plus explicite, plus mesurable et plus aligné avec les risques actuels.
Pour les clients, cela demande de l’anticipation. Pour les partenaires, cela ouvre un espace très concret pour proposer audit, remédiation, accompagnement et gouvernance.
Et c’est souvent là que se crée la vraie valeur ;-)