MFA Salesforce 2026 : préparer l’enforcement sans bloquer vos utilisateurs

Mise à jour du 29 juillet 2026. Salesforce a commencé à imposer techniquement l’authentification multifacteur pour les utilisateurs internes, selon un calendrier qui dépend de l’instance. Les comptes privilégiés doivent en plus utiliser une méthode résistante au phishing. Pour une DSI, un RSSI ou un responsable Salesforce, la question n’est donc plus « avons-nous activé la MFA ? », mais « avons-nous prouvé que chaque population pourra se connecter avec la bonne méthode le jour de l’enforcement ? ».

Une organisation peut être conforme sur le papier et provoquer malgré tout un incident. Son SSO peut demander une authentification forte sans transmettre à Salesforce le signal attendu. Des administrateurs peuvent utiliser uniquement Salesforce Authenticator ou une application TOTP, alors que leur niveau de privilège exige désormais une passkey ou une clé de sécurité compatible. Un compte d’intégration peut aussi être considéré comme non interactif, tout en continuant à ouvrir l’interface pour certaines opérations.

La préparation utile consiste à réunir cinq preuves : l’instance et sa date, les populations concernées, la force des méthodes enregistrées, les signaux SSO réellement reçus et un parcours de récupération testé.

Ce qui change avec la MFA Salesforce en 2026

Salesforce impose l’enforcement aux utilisateurs internes qui accèdent à l’interface des organisations de production et des sandbox. Cela inclut les connexions directes et les connexions via SSO.

Deux niveaux doivent être distingués.

Pour un utilisateur interne standard, Salesforce accepte une MFA standard ou une méthode résistante au phishing. Salesforce Authenticator et les applications qui génèrent un code TOTP restent des méthodes de MFA standard.

Pour un utilisateur privilégié, Salesforce exige une méthode résistante au phishing. Il s’agit principalement d’une passkey associée à un authentificateur intégré, comme Touch ID, Face ID ou Windows Hello, ou d’une clé de sécurité compatible WebAuthn ou FIDO2.

Cette distinction change la nature de l’audit. Vérifier qu’un utilisateur possède « une MFA » ne suffit plus. Il faut vérifier que la force de la méthode correspond à son niveau d’accès.

Salesforce considère notamment comme privilégié un utilisateur qui possède le profil System Administrator ou au moins l’une des permissions suivantes :

• Modify All Data ;
• View All Data ;
• Customize Application ;
• Author Apex.

La liste doit être calculée à partir des profils et des permission sets réellement attribués. Une liste d’administrateurs tenue à la main ne capture ni les permissions indirectes, ni les anciens prestataires encore actifs, ni les comptes techniques utilisés ponctuellement dans l’interface.

Le calendrier dépend de l’instance, pas du pays

Salesforce publie un calendrier par release group. Au 29 juillet 2026, les premières vagues de production ont commencé et d’autres s’étendent jusqu’au début septembre.

Ce tableau ne permet pas, à lui seul, de dater une organisation. Il faut identifier son instance, retrouver son release group dans la table officielle puis vérifier la fenêtre publiée. Salesforce indique que la table peut évoluer. La date doit donc être relue juste avant la communication aux utilisateurs.

La preuve attendue peut tenir dans une ligne de pilotage :

« Nous sommes en Europe » ou « nous utilisons Hyperforce » n’est pas une preuve suffisante. L’instance exacte et sa correspondance officielle le sont.

Pourquoi le SSO peut encore déclencher une invite Salesforce

Le SSO ne dispense pas automatiquement de la MFA Salesforce. L’identity provider doit indiquer à Salesforce la méthode réellement utilisée grâce aux signaux AMR, pour Authentication Methods References, ou ACR, pour Authentication Context Class Reference.

Salesforce classe ensuite la connexion selon le niveau reconnu :

• MFA résistante au phishing ;
• MFA standard ;
• MFA faible ou absence de MFA reconnue.

Si l’identity provider applique une méthode forte mais transmet une valeur absente ou mal classée, Salesforce ne peut pas déduire que l’exigence est satisfaite. Un administrateur peut alors être invité à créer une passkey dans Salesforce, même si l’équipe IAM estime que le SSO est correctement sécurisé.

Le bon test ne consiste donc pas seulement à réussir une connexion. Il doit répondre à cinq questions :

1. quel facteur l’identity provider a-t-il réellement demandé ?
2. quelle valeur AMR ou ACR a-t-il transmise ?
3. comment Salesforce a-t-il classé cette valeur ?
4. quel parcours voit un utilisateur standard ?
5. quel parcours voit un administrateur ou un utilisateur privilégié ?

Les valeurs ACR peuvent être observées dans l’historique de connexion et les login events. Cette lecture transforme une hypothèse d’architecture en preuve exploitable. Elle peut être intégrée à un audit Salesforce pour relier l’identité, les permissions et les parcours utilisateurs.

Les populations à cartographier avant l’enforcement

Tous les utilisateurs ne suivent pas le même chemin de connexion. Une cartographie utile sépare au minimum :

• les utilisateurs standards en connexion directe ;
• les utilisateurs standards en SSO ;
• les utilisateurs privilégiés en connexion directe ;
• les utilisateurs privilégiés en SSO ;
• les utilisateurs qui peuvent contourner le SSO ;
• les comptes d’intégration qui ouvrent aussi l’interface ;
• les accès aux sandbox, notamment après un refresh ;
• les utilisateurs internes qui passent par un site Experience Cloud.

Les utilisateurs externes disposant de licences Experience Cloud, Chatter External ou Chatter Free ne sont pas couverts de la même manière par l’exigence générale. En revanche, les populations internes qui utilisent un site ou une communauté restent à qualifier selon leur licence et leur parcours réel.

Les connexions API ne reçoivent pas d’invite MFA interactive. Cela ne dispense pas un même compte de l’exigence lorsqu’il accède aussi à l’interface. Le contrôle doit séparer les flux véritablement non interactifs des comptes humains ou techniques qui utilisent encore l’UI.

La checklist de préparation en neuf étapes

1. Identifier l’instance et la date

Relever l’instance de chaque organisation de production et sandbox. Associer chaque instance à son release group officiel. Conserver la date et le lien de vérification.

2. Cartographier les modes de connexion

Documenter les connexions directes, le SSO, les accès de secours et les exceptions. L’objectif est de ne pas confondre une politique d’entreprise avec les chemins encore ouverts dans Salesforce.

3. Identifier les utilisateurs privilégiés

Extraire les utilisateurs actifs qui possèdent le profil System Administrator ou l’une des quatre permissions privilégiées citées par Salesforce. Vérifier les permissions directes, celles des profils et celles des permission sets.

Cette liste doit avoir un propriétaire métier et technique. Un ancien prestataire qui se connecte rarement reste un risque s’il conserve des permissions puissantes.

4. Inventorier les méthodes enregistrées

Pour chaque population, contrôler les méthodes disponibles et déjà enregistrées. Pour les utilisateurs privilégiés, confirmer qu’une passkey ou une clé compatible est prête. Pour les autres, vérifier qu’au moins une méthode acceptée sera utilisable le jour de la bascule.

Lorsque le niveau d’exigence le permet, enregistrer une méthode de secours réduit le risque de blocage après une perte de téléphone ou un changement de poste.

5. Contrôler AMR et ACR pour le SSO

Demander à l’équipe identité quelle méthode est appliquée et quel signal est transmis. Vérifier ensuite ce que Salesforce reçoit réellement. Une documentation de l’identity provider ne remplace pas un login event observé et classé au bon niveau.

6. Tester des scénarios représentatifs

La recette doit couvrir au minimum :

• un utilisateur standard en connexion directe ;
• un utilisateur standard en SSO ;
• un utilisateur privilégié en connexion directe ;
• un utilisateur privilégié en SSO ;
• un utilisateur sans méthode préenregistrée ;
• une récupération après perte du facteur principal.

Le test est réussi lorsque chaque personne entre avec la méthode attendue et que les parcours non conformes sont refusés ou réorientés de manière contrôlée.

7. Préparer le support et la récupération

Documenter qui peut aider à enregistrer une méthode, déconnecter un ancien facteur, générer un code temporaire lorsque le cas est autorisé et contacter Salesforce Support si le dernier administrateur est bloqué.

Éviter le point de défaillance unique. Une organisation avec un seul administrateur capable de récupérer les accès ne possède pas encore un plan de continuité.

8. Communiquer par population

La communication doit préciser la date liée à l’instance, la méthode attendue, les appareils compatibles, le temps nécessaire à l’enregistrement, la procédure en cas d’échec et le canal de support.

Un message générique « la MFA devient obligatoire » ne permet pas à un administrateur, un utilisateur standard et un collaborateur sans appareil compatible de se préparer correctement.

9. Produire la preuve après bascule

Dans les 24 heures suivant l’enforcement, contrôler les échecs de connexion, les tickets de support, les utilisateurs privilégiés non conformes, les signaux AMR ou ACR reçus, les méthodes de récupération utilisées et les comptes qui n’ont pas suivi le parcours prévu.

Cette étape complète utilement un Salesforce Health Check : le score de configuration ne montre pas, à lui seul, si les connexions réelles fonctionnent et sont prises en charge.

Le tableau de pilotage qui évite les angles morts

L’historique de connexion et les événements peuvent ensuite être intégrés à une démarche d’Event Monitoring Salesforce pour suivre les anomalies au-delà du jour de la bascule.

Les cinq erreurs qui créent le plus de blocages

Penser que le SSO suffit. Il faut vérifier le signal transmis, pas seulement l’existence du SSO.

Traiter tous les utilisateurs de la même manière. Les comptes privilégiés ont une exigence plus forte que les autres utilisateurs.

Attendre l’écran d’enforcement pour enregistrer les méthodes. Le préenregistrement réduit la charge du support et les interruptions.

Conserver un seul administrateur de secours. Un facteur perdu peut devenir un incident critique si personne d’autre ne peut intervenir.

Confondre compte API et compte interactif. L’absence d’invite sur une API ne dispense pas le même compte de l’exigence lorsqu’il ouvre l’interface.

Faut-il demander une extension ?

Salesforce documente des extensions temporaires pour certains cas. Elles ne doivent pas devenir la stratégie par défaut.

Une extension peut modifier temporairement le comportement attendu, mais elle ne remplace ni l’inventaire des utilisateurs ni la préparation des méthodes. Pour un cas légitime, notamment certaines automatisations, la voie documentée passe par Salesforce Support.

L’ordre opérationnel reste simple :

1. corriger la configuration ;
2. préparer les utilisateurs ;
3. tester le parcours ;
4. utiliser une extension uniquement comme mesure transitoire documentée.

Conclusion : la MFA devient une preuve d’exploitation

L’enforcement 2026 ne se résume pas à activer un bouton. Il oblige les équipes Salesforce, sécurité, identité et support à partager la même preuve : qui doit utiliser quoi, à quelle date, par quel chemin de connexion, avec quel signal SSO et avec quelle procédure de récupération.

Une organisation prête sait répondre à ces cinq questions avant que le premier utilisateur ne voie l’écran d’enregistrement.

Cloud Girafe peut réaliser un audit express de cette préparation : instances et calendrier, utilisateurs privilégiés, méthodes MFA, SSO AMR/ACR, scénarios de test et plan de récupération. Le livrable est une liste d’écarts priorisés, chacun avec un propriétaire et une preuve attendue.

Pour une préparation plus large de l’instance, la page Intégrateur Salesforce en France présente l’accompagnement Cloud Girafe sur l’audit, la reprise, la TMA et l’intégration.

Questions fréquentes

La MFA Salesforce 2026 concerne-t-elle aussi le SSO ?

Oui. Salesforce annonce l’enforcement pour les connexions directes et SSO des utilisateurs internes. Pour éviter une invite supplémentaire, l’identity provider doit transmettre un signal AMR ou ACR que Salesforce reconnaît au niveau requis.

Salesforce Authenticator suffit-il pour un administrateur ?

Non pour l’exigence résistante au phishing des utilisateurs privilégiés. Salesforce Authenticator est une MFA standard. Un administrateur concerné doit utiliser une méthode résistante au phishing, comme une passkey intégrée ou une clé de sécurité compatible.

Comment savoir quand notre organisation est concernée ?

Il faut identifier l’instance Salesforce, consulter sa correspondance dans la table officielle des release groups, puis appliquer la fenêtre publiée pour ce groupe. La table doit être revérifiée car Salesforce indique qu’elle peut évoluer.

Les connexions API nécessitent-elles une MFA interactive ?

Non, Salesforce n’impose pas une invite MFA aux connexions API. En revanche, un compte technique qui accède aussi à l’interface doit satisfaire l’exigence applicable à cette connexion interactive.

Que faire si le seul administrateur est bloqué ?

Préparer ce scénario avant l’enforcement. Un autre administrateur peut aider à déconnecter une ancienne méthode ou à générer un code temporaire dans les cas documentés. S’il n’existe aucun autre administrateur disponible, il faut contacter Salesforce Support.

Sources officielles

1. Prepare for MFA Enforcement for All Employee Users
2. Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins
3. Understand MFA Requirements
4. MFA Verification Methods for Direct Salesforce Login
5. Added, Removed, and Reclassified SSO Authentication Signals for MFA
6. Enable MFA for Direct Login
7. Prepare Your Org for Salesforce MFA Enforcement