Le 30 juillet 2026, Salesforce a activé la step-up authentication sur les paramètres de sécurité de Marketing Cloud Engagement. Concrètement, chaque enregistrement réalisé dans Setup → Settings → Security Settings déclenche désormais une revérification d'identité, même lorsque votre session est déjà ouverte. Ce n'est pas une option : aucun mécanisme de contournement n'existe côté MCE. Pour les équipes CRM et martech, ce petit changement d'interface a des conséquences opérationnelles bien réelles. Dans cet article, nous décryptons ce que Salesforce a réellement activé, le calendrier de déploiement par release group, et surtout comment préparer vos administrateurs pour éviter tout blocage au pire moment.

Ce que Salesforce a activé le 30 juillet 2026

La step-up authentication est une couche de vérification supplémentaire imposée avant certaines actions sensibles. L'idée est simple : une session ouverte ne suffit plus à prouver que vous êtes bien la personne autorisée à modifier des réglages critiques. Avant d'enregistrer une modification sur la page Security Settings, Salesforce vous demande de confirmer à nouveau votre identité, généralement via votre méthode d'authentification multifacteur (MFA).

Le périmètre est précis : toute action réalisée sous Setup → Settings → Security Settings peut déclencher un challenge de revérification. Cela couvre notamment les listes d'adresses IP autorisées, les politiques de mot de passe, les durées d'expiration de session ou encore les paramètres de connexion. Ce sont précisément les leviers qu'un attaquant cherche à manipuler après avoir compromis une session.

Le calendrier de déploiement

Le déploiement est échelonné par release group. L'activation a commencé le 30 juillet 2026 et s'est poursuivie jusqu'au 5 août ; les organisations du groupe R1, par exemple, ont basculé le 3 août 2026. Point important : la revérification s'applique d'abord aux connexions directes. L'application aux flux SSO fédérés est prévue plus tard, ce qui crée une fenêtre pendant laquelle vos environnements ne seront pas tous logés à la même enseigne.

Pourquoi ce changement, et pourquoi maintenant

Ce durcissement s'inscrit dans une refonte plus large de la sécurité Salesforce en 2026, avec la généralisation de la MFA et l'arrivée de méthodes résistantes au phishing. La logique est celle du zero trust appliquée aux actions à fort impact : on ne fait plus confiance à une session sur la seule base de son ancienneté.

Le vecteur d'attaque visé est bien identifié. Un cookie de session volé, une machine laissée déverrouillée ou un poste infecté permettent à un tiers d'agir sous une identité légitime. En exigeant une preuve d'identité fraîche au moment précis de la modification, Salesforce neutralise les sessions périmées ou détournées avant qu'elles ne servent à ouvrir une brèche, par exemple en ajoutant une plage IP malveillante à la liste d'autorisation.

La step-up authentication ne protège pas contre l'intrusion initiale : elle empêche une session déjà compromise de transformer un accès volé en changement de configuration durable. C'est une dernière ligne de défense sur vos réglages les plus sensibles.

Concrètement, qu'est-ce qui déclenche une revérification

Tout enregistrement sur la page Security Settings est susceptible de déclencher le challenge. En pratique, vos administrateurs le rencontreront lors des opérations suivantes :

• Ajout, modification ou suppression d'une plage d'adresses IP dans la liste d'autorisation.
• Changement des règles de complexité ou d'expiration des mots de passe.
• Modification de la durée de vie ou du délai d'inactivité des sessions.
• Ajustement des paramètres de connexion et des exigences MFA.

Si aucune méthode MFA n'est correctement enrôlée pour l'administrateur concerné, le risque est réel : le challenge peut se transformer en blocage. D'où l'importance de vérifier l'enrôlement avant que le besoin de modifier un réglage ne se présente en urgence.

Préparer vos équipes et vos accès

La bonne nouvelle, c'est que ce changement se prépare en quelques étapes concrètes. Voici la feuille de route que nous recommandons à nos clients.

Auditer les rôles et les administrateurs

Commencez par cartographier qui possède réellement des droits sur les Security Settings. Le principe du moindre privilège s'applique : moins vous avez d'administrateurs, plus la surface d'attaque est réduite. Vous pouvez récupérer la liste des utilisateurs et de leurs rôles via l'API REST de Marketing Cloud.

// 1. Obtenir un token via le package API installé (Server-to-Server)
POST https://YOUR_SUBDOMAIN.auth.marketingcloudapis.com/v2/token
Content-Type: application/json

{
  "grant_type": "client_credentials",
  "client_id": "YOUR_CLIENT_ID",
  "client_secret": "YOUR_CLIENT_SECRET",
  "account_id": "YOUR_MID"
}

// 2. Lister les utilisateurs de la Business Unit
GET https://YOUR_SUBDOMAIN.rest.marketingcloudapis.com/platform/v1/users
Authorization: Bearer {access_token}

Croisez ces résultats avec les rôles attribués. Tout compte administrateur inactif, générique ou partagé doit être désactivé ou converti en compte nominatif avec MFA.

Vérifier l'enrôlement MFA de chaque administrateur

Assurez-vous que chaque administrateur susceptible de toucher aux Security Settings dispose d'une méthode MFA active et à jour : application d'authentification, clé de sécurité ou méthode résistante au phishing. Documentez une procédure de secours (compte de break-glass) pour éviter tout verrouillage total en cas de perte d'appareil.

SSO fédéré : ce qui vient ensuite

Si vos administrateurs se connectent via un fournisseur d'identité (SSO fédéré), sachez que la step-up n'est pas encore appliquée à ces flux, mais qu'elle le sera. Anticipez en vérifiant que votre IdP est capable de déclencher une revérification (par exemple via une politique de réauthentification) afin d'éviter une mauvaise surprise lors de l'extension du dispositif.

Les angles morts à surveiller

Trois points méritent une attention particulière. D'abord, les automatisations : la step-up cible les actions humaines sur l'interface, mais elle ne dispense pas d'auditer vos intégrations Server-to-Server, qui restent une cible privilégiée. Ensuite, la documentation interne : si vos procédures de changement de configuration ne mentionnent pas la revérification, vos équipes perdront du temps face à un challenge inattendu. Enfin, la coordination multi-BU : dans une architecture à plusieurs Business Units, les dates d'activation peuvent varier selon le release group, d'où l'intérêt d'un suivi centralisé.

Pour aller plus loin, un audit de sécurité de votre tenant SFMC est souvent l'occasion de rationaliser les rôles, de nettoyer les intégrations dormantes et de fiabiliser vos listes d'IP. Si vous souhaitez un accompagnement sur ces sujets, notre équipe est disponible via notre formulaire de contact.

À retenir

1. Un changement déjà actif. Depuis le 30 juillet 2026, toute modification des Security Settings de Marketing Cloud Engagement exige une revérification d'identité, sans contournement possible côté MCE.

2. Un périmètre ciblé. Listes d'IP, politiques de mot de passe, durées de session et paramètres de connexion sont concernés : ce sont les leviers que visent les attaquants.

3. La MFA d'abord. Vérifiez que chaque administrateur dispose d'une méthode MFA active avant d'en avoir besoin, et prévoyez un compte de secours documenté.

4. Le SSO fédéré arrive. La step-up sera étendue aux flux SSO : anticipez la configuration de votre fournisseur d'identité dès maintenant.

5. L'occasion d'un audit. Profitez-en pour appliquer le moindre privilège, réduire le nombre d'administrateurs et sécuriser vos intégrations Server-to-Server.