Votre ERP concentre les données financières, RH et opérationnelles les plus sensibles de l’entreprise. En 2026, le rapport IBM Cost of a Data Breach 2026 chiffre le coût moyen d’une violation de données à 4,99 millions de dollars — un record absolu, en hausse de 12 % sur un an. Le rapport Verizon DBIR 2026 complète ce tableau : les identifiants compromis apparaissent dans 39 % des violations à un moment ou un autre de la chaîne d’attaque, même quand ils ne sont plus le vecteur d’entrée initial.
La question n’est donc plus de savoir si votre ERP sera ciblé, mais de décider comment vous allez gérer les accès avant que les attaquants ne le fassent pour vous. C’est précisément l’objet du modèle Zero Trust appliqué à l’ERP : ne jamais faire confiance par défaut à un compte, même interne, même derrière un VPN. Toujours vérifier. Toujours limiter.
Ce guide est structuré pour un DSI ou RSSI d’ETI qui doit passer de la théorie à l’action — avec des décisions concrètes sur l’IAM, le MFA et le PAM, et une feuille de route sur 12 mois.
1. Pourquoi Zero Trust est devenu incontournable pour les ERP en 2026
Le périmètre de sécurité ERP a explosé
Pendant longtemps, la sécurité ERP reposait sur un périmètre réseau clair : le serveur est dans la salle machine, les utilisateurs sont au bureau, le VPN protège les accès distants. Ce modèle est obsolète.
En 2026, un ERP typique est exposé à :
- Des accès multi-canal : interface web, app mobile, API, connecteurs EDI, passerelle bancaire
- Des utilisateurs distribués : télétravail, sites distants, consultants intégrateurs en mission, partenaires fournisseurs avec accès portail
- Des intégrations tierces : CRM, BI, e-commerce, plateforme RH, outil de paie, banque — chaque connecteur est une surface d’attaque
Dans ce contexte, faire confiance à un utilisateur parce qu’il est “dans le réseau” ne signifie plus rien. Un compte compromis d’un consultant externe peut traverser tout le SI sans déclencher la moindre alerte si les accès ne sont pas segmentés.
NIS2 et DORA : des exigences précises sur les identités
Deux textes réglementaires imposent désormais des mesures concrètes sur la gestion des accès ERP :
NIS2 (transposée en droit français en 2025) : l’article 21(2)(j) de la directive impose une authentification multi-facteurs “dans la mesure du possible”, avec une précision apportée par le cadre d’application : l’obligation couvre a minima tous les accès privilégiés et tous les accès distants aux systèmes critiques. Les pénalités pour non-conformité atteignent 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les entités essentielles, avec une responsabilité personnelle des dirigeants.
DORA (applicable depuis janvier 2025) : pour les entités financières et leurs prestataires TIC, DORA (article 9) impose une politique d’accès documentée couvrant tous les comptes ayant accès aux systèmes d’information — y compris les comptes de service et les clés API, pas seulement les comptes humains.
L’ERP est presque systématiquement classé “système critique” dans ces deux cadres. Votre projet IAM/PAM/MFA n’est donc pas seulement une bonne pratique : c’est une obligation réglementaire avec une échéance qui court.
Zero Trust : le principe et ce qu’il change pour l’ERP
Zero Trust ne signifie pas “tout bloquer”. C’est un changement de posture : au lieu de faire confiance à un utilisateur parce qu’il a présenté un mot de passe valide depuis un poste reconnu, vous vérifiez en continu le contexte de chaque accès — identité, appareil, localisation, comportement — et vous n’accordez que les droits strictement nécessaires pour la durée strictement nécessaire.
Appliqué à l’ERP, cela se traduit par trois piliers opérationnels :
- IAM (Identity and Access Management) : qui peut accéder à quoi, selon quelles règles, avec quelle traçabilité
- MFA (Multi-Factor Authentication) : preuve d’identité renforcée à chaque connexion sensible
- PAM (Privileged Access Management) : protection spécifique des comptes à droits élevés — administrateurs, consultants, comptes de service
2. IAM : les bases incontournables pour votre ERP
2.1 SSO (Single Sign-On) : centraliser l’authentification
La première brique d’un IAM solide est le SSO : toutes les authentifications à l’ERP passent par un annuaire d’entreprise centralisé. Concrètement, l’utilisateur s’authentifie une seule fois auprès de votre Identity Provider (IdP), et l’ERP reconnaît cette session sans lui demander un deuxième mot de passe.
Les solutions d’IdP les plus répandues dans les ETI en 2026 :
- Microsoft Entra ID (anciennement Azure AD) : dominant dans les environnements Microsoft 365, intégration native avec SAP, Dynamics 365, Business Central
- Okta : solution SaaS agnostique, large catalogue de connecteurs ERP (SAP, Odoo, NetSuite, Sage X3)
- Ping Identity : positionnement enterprise, souvent retenu dans les secteurs régulés
Les protocoles d’authentification fédérée :
- SAML 2.0 : standard historique, privilégié par SAP Fiori, Sage X3, Microsoft Dynamics
- OAuth2/OIDC : plus moderne, utilisé par Odoo (v16+), NetSuite, les API REST
Le choix du protocole n’est pas anodin : vérifiez la compatibilité avec votre version d’ERP avant de sélectionner votre IdP. Un intégrateur qui promet du “SAML” sur une version Odoo Community sans module IdP n’a probablement pas lu la documentation.
La revue d’habilitations est la contrepartie indispensable du SSO : si tous les accès sont centralisés, vous pouvez aussi produire facilement un rapport trimestriel de “qui a accès à quoi dans l’ERP”. Ce rapport est la base des contrôles NIS2 et DORA sur la gestion des accès. Sans SSO, produire ce rapport demande des extractions manuelles de chaque module ERP.
2.2 Provisioning automatique avec SCIM
SCIM (System for Cross-domain Identity Management) est le protocole qui automatise la création, modification et suppression des comptes ERP en fonction des événements RH dans votre annuaire.
L’arrivée d’un collaborateur : dès que le compte est créé dans Active Directory ou Entra ID avec le bon profil (service, poste, localisation), SCIM provisionne automatiquement le compte ERP avec les droits correspondant au profil du poste. Le collaborateur peut travailler dès le premier jour, sans ticket DSI.
Le départ d’un collaborateur : dès que le compte RH est désactivé dans l’annuaire, SCIM désactive le compte ERP dans les minutes qui suivent. C’est le scénario le plus critique en termes de sécurité : un compte oublié après un départ est une porte d’entrée parfaite pour un ex-salarié malveillant ou pour un attaquant qui a récupéré les identifiants.
La plupart des grands ERP supportent SCIM en 2026 : SAP S/4HANA (via SAP Identity Management ou Entra ID), Microsoft Dynamics 365, NetSuite, Odoo Enterprise (v17+). Pour Sage X3, le support SCIM passe souvent par un middleware ou un connecteur d’intégration.
3. MFA : ce que votre ERP doit imposer
Niveau de criticité et exigences de contrôle
Tous les modules ERP ne présentent pas le même niveau de risque. La logique Zero Trust impose de calibrer le niveau d’authentification au niveau de sensibilité des données et des actions accessibles :
| Module ERP | Niveau de criticité | Exigence MFA recommandée |
|---|---|---|
| Finance / Comptabilité | Critique | MFA obligatoire, phishing-résistant |
| Ressources Humaines / Paie | Critique | MFA obligatoire, phishing-résistant |
| Achats / Fournisseurs | Élevé | MFA obligatoire |
| Administration / Paramétrage | Critique | MFA obligatoire + session enregistrée |
| Logistique / Production | Moyen | MFA fortement recommandé |
| Consultation seule (BI, reporting) | Standard | MFA recommandé |
Les méthodes MFA et leur robustesse
Trois niveaux de robustesse, du moins sécurisé au plus sécurisé :
SMS / OTP par SMS : toujours utilisé, mais explicitement déconseillé par les régulateurs européens et non conforme à une lecture stricte de NIS2. Vulnérable au SIM swapping et au phishing en temps réel (attaque AiTM).
Authenticator app / TOTP (Time-based One-Time Password) : Microsoft Authenticator, Google Authenticator, Authy. Bon niveau de sécurité pour la majorité des utilisateurs. La notification push (avec vérification du numéro affiché) est préférable au TOTP classique pour résister aux attaques par fatigue MFA.
FIDO2 / Passkeys / clés de sécurité matérielles : Yubikey, clés FIDO2 certifiées. Seul niveau reconnu comme “phishing-résistant” par les guides NIS2 et les recommandations de l’ANSSI. Obligatoire pour les comptes d’administration ERP dans les environnements soumis à NIS2 ou DORA.
Activation MFA dans les principaux ERP
SAP S/4HANA / Fiori : le MFA est géré au niveau de l’IdP (Entra ID, Okta). SAP Cloud Identity Services (IAS) permet de configurer des politiques d’authentification adaptatives par groupe d’utilisateurs. L’activation ne touche pas à la logique ERP et ne demande pas de montée de version SAP.
Microsoft Dynamics 365 : le MFA est géré par Entra ID. Si votre tenant Microsoft 365 est déjà configuré avec Entra ID P2 (environ 10 USD/utilisateur/mois selon le tarif en vigueur en août 2026), l’accès conditionnel vous permet d’imposer le MFA uniquement sur les accès à Dynamics et de calibrer les exigences selon l’appareil et la localisation.
Odoo 18 : le module web_enterprise intègre le TOTP depuis la v15. L’activation est paramétrable par groupe d’utilisateurs. L’intégration SSO/SAML avec Entra ID ou Okta pour un MFA centralisé demande le module auth_saml (disponible sur l’Odoo Apps Store pour les instances Community, natif en Enterprise).
Sage X3 : le MFA s’appuie sur l’IdP tiers via SAML. Sage recommande l’usage de Microsoft Entra ID ou Okta pour les clients qui disposent déjà de ces solutions. Une configuration Sage X3 avec SAML + FIDO2 est possible mais demande une expertise spécifique en intégration.
Cas particulier : les utilisateurs de terrain et les accès mobiles
Un technicien de maintenance qui accède à l’ERP depuis une tablette industrielle, un commercial qui consulte les stocks depuis son téléphone : le MFA doit fonctionner pour eux aussi, sans bloquer l’activité.
La solution la plus opérationnelle est la combinaison accès conditionnel + appareil géré (MDM). Si l’appareil est inscrit dans votre MDM (Microsoft Intune, Jamf) et conforme à la politique de sécurité, le MFA peut être satisfait par la possession de l’appareil (certificat). L’utilisateur ne saisit pas de code supplémentaire — la vérification est transparente.
4. PAM : protéger les comptes superadmin de l’ERP
Les comptes à risque que l’on sous-estime
Les comptes d’administration ERP sont rarement ceux qui font l’objet du plus d’attention dans les audits. Pourtant, ce sont les plus dangereux en cas de compromission :
- Administrateurs base de données (HANA, Oracle, SQL Server) : accès direct aux tables ERP, possibilité d’extraire ou modifier n’importe quelle donnée sans passer par les contrôles applicatifs
- Comptes de service ERP : utilisés par les batch nocturnnes, les interfaces avec la banque, les synchronisations EDI — souvent avec des mots de passe qui n’ont pas changé depuis le déploiement initial
- Comptes consultants intégrateurs : créés pour un projet, souvent jamais désactivés après la fin de mission
- Compte “BASIS” ou super-admin ERP : compte générique d’administration partagé entre plusieurs administrateurs, sans traçabilité individuelle
La recherche Verizon DBIR 2026 confirme que les comptes privilégiés restent un vecteur central dans les attaques sophistiquées : même quand l’intrusion initiale passe par une vulnérabilité, l’escalade vers un compte privilégié intervient dans la grande majorité des incidents graves.
Ce que fait concrètement une solution PAM
Un PAM (Privileged Access Management) résout quatre problèmes spécifiques aux comptes à haut privilège :
1. Vault de mots de passe : les mots de passe des comptes privilégiés ne sont plus connus des administrateurs. Ils sont stockés dans un coffre chiffré, injectés automatiquement à la connexion via le PAM, et tournés selon une politique définie (toutes les 24h, 7 jours, etc.).
2. Enregistrement de session : chaque session d’un compte privilégié est enregistrée (vidéo + logs de commandes). En cas d’incident, vous savez exactement ce qui a été fait, par quel compte, à quelle heure — même si le compte était générique.
3. Just-In-Time access : plutôt que de laisser les droits admin actifs en permanence, le PAM les accorde uniquement pendant la durée de l’intervention, sur demande explicite, avec un workflow d’approbation. Un consultant qui demande un accès DB pour une intervention de 2h ne reçoit les droits que pour ces 2h.
4. Audit et reporting : exports automatiques des sessions, alertes sur les comportements anormaux (connexion à 3h du matin, accès à une table non habituelle, volume d’extraction anormal).
Solutions PAM du marché et budget indicatif
Les trois acteurs majeurs du PAM enterprise en 2026 :
CyberArk : référence du marché, budget 2 400 à 4 800 USD par utilisateur privilégié et par an pour Privilege Cloud Standard (CyberArk Pricing 2026). Positionnement enterprise, fonctionnalités les plus complètes, déploiement plus long. Requis pour les environnements SAP de grande taille.
BeyondTrust : 15 à 35 % moins cher que CyberArk sur des périmètres comparables. Fort sur le PAM Windows et la sécurisation des postes d’administration. Bien adapté aux environnements Dynamics 365 et Microsoft-centric.
Delinea (ex-ThycoticCentrify) : 30 à 45 % moins cher que CyberArk, déploiement plus rapide. Entrée de gamme PAM enterprise recommandée pour les ETI de 100 à 500 utilisateurs dont les besoins PAM ne justifient pas un CyberArk.
Pour une ETI avec 10 à 20 comptes privilégiés ERP, un budget PAM entre 25 000 et 60 000 euros par an (licensing + implémentation initiale) est réaliste avec Delinea ou BeyondTrust. CyberArk sur le même périmètre débuterait plutôt à 60 000-100 000 euros.
5. Plan de mise en oeuvre Zero Trust ERP : 4 phases sur 12 mois
Un projet Zero Trust ERP ne se déploie pas en un week-end. Il suit une séquence logique qui évite de paralyser la production tout en progressant rapidement sur les risques les plus critiques.
Phase 1 (Mois 1-2) : Inventaire et cartographie des accès
Avant toute solution technique, il faut savoir ce qu’on protège :
- Inventaire des comptes ERP : comptes actifs, comptes dormants (dernière connexion > 90 jours), comptes génériques, comptes de service
- Cartographie des droits : qui a accès à quels modules, quelles transactions, quelles entités légales
- Identification des comptes privilégiés : tous les comptes ayant un accès admin, BD, batch ou intégration
- Recensement des accès externes : consultants, auditeurs, partenaires avec accès direct ou via VPN
Livrable : une matrice des accès ERP, base de la politique IAM et de la configuration PAM.
Phase 2 (Mois 3-4) : SSO centralisé + activation MFA
- Connexion de l’ERP à l’IdP (Entra ID, Okta selon l’existant) via SAML ou OIDC
- Activation du MFA en commençant par les comptes finance et RH (criticité maximale), puis extension à tous les utilisateurs
- Configuration SCIM pour le provisioning automatique des arrivées/départs
- Désactivation des comptes dormants identifiés en Phase 1 (quick win sécurité)
Risque principal : les ERP legacy sans support SAML. Prévoir un connecteur middleware si nécessaire, ou traiter le cas via un accès conditionnel réseau en attendant une migration.
Phase 3 (Mois 5-6) : PAM pour les comptes privilégiés
- Déploiement de la solution PAM sur les comptes administrateurs, BD et de service
- Migration des mots de passe dans le vault PAM (fin des mots de passe connus des admins)
- Activation de l’enregistrement de sessions pour toutes les connexions privilégiées ERP
- Mise en place du Just-In-Time access pour les consultants et prestataires externes
- Formation des administrateurs aux nouveaux workflows d’accès
Phase 4 (Mois 7-12) : Monitoring continu et revue trimestrielle
- Intégration ERP/PAM dans le SIEM (Splunk, Sentinel, Elastic) pour la corrélation des événements
- Configuration des alertes comportementales : connexion hors horaires habituels, volume d’accès anormal, tentative d’accès à des modules non autorisés
- Revue trimestrielle des habilitations (obligatoire NIS2) : rapport automatique depuis l’IdP + validation manager
- Tests de scénarios d’attaque : simulation de compromission d’un compte utilisateur, vérification que le PAM bloque l’escalade de privilèges
6. Budget et ROI : combien coûte une architecture Zero Trust ERP ?
Coûts indicatifs pour une ETI de 100-300 utilisateurs ERP
| Composant | Solution | Budget annuel indicatif |
|---|---|---|
| IdP / SSO | Entra ID P2 | ~10 USD/user/mois (annuel) |
| IdP / SSO | Okta Workforce Identity | ~10-14 USD/user/mois |
| PAM (10-20 comptes privilégiés) | Delinea Secret Server | 20 000-40 000 € (licensing) |
| PAM (10-20 comptes privilégiés) | BeyondTrust | 25 000-50 000 € (licensing) |
| PAM (10-20 comptes privilégiés) | CyberArk Privilege Cloud | 50 000-100 000 € (licensing) |
| Implémentation IAM + SSO | Intégrateur | 15 000-30 000 € (one-shot) |
| Implémentation PAM | Intégrateur | 20 000-40 000 € (one-shot) |
Pour une ETI de 150 utilisateurs ERP avec 15 comptes privilégiés, un budget total d’implémentation de 80 000 à 120 000 euros (licensing 1 an + services) est une fourchette réaliste avec Delinea ou BeyondTrust.
ROI : comparer avec le coût d’un incident
L’IBM Cost of a Data Breach 2026 établit le coût moyen mondial d’une violation à 4,99 millions de dollars. Pour une ETI européenne, le coût est proportionnellement plus faible mais inclut :
- Frais de réponse à incident et de restauration des systèmes
- Interruption d’activité pendant la remise en état (facturation bloquée, production arrêtée)
- Notification RGPD à la CNIL et aux personnes concernées
- Amendes potentielles NIS2 (jusqu’à 2 % du CA mondial pour les entités essentielles)
- Coût réputationnel et perte de clients
Un projet IAM/PAM/MFA complet absorbe généralement 2 à 3 semaines d’interruption d’activité évitée. Pour la plupart des ETI, l’équation est favorable dès la première année.
Aides disponibles
BPI France : les ETI soumises à NIS2 peuvent bénéficier des prêts et garanties BPI dans le cadre du plan de souveraineté numérique. Renseignez-vous auprès du référent BPI de votre région.
Fonds FEDER cybersécurité : selon votre région et votre secteur, des cofinancements européens peuvent prendre en charge jusqu’à 40 % des investissements cybersécurité qualifiants.
France Num / programme Cyber PME ANSSI : subventions et accompagnements pour les démarches de mise en conformité NIS2.
Checklist Zero Trust ERP : par où commencer demain matin
Si vous ne deviez retenir qu’une action par pilier :
IAM : activez le SSO entre votre ERP et votre annuaire d’entreprise. Si Entra ID est déjà en place pour Microsoft 365, la configuration SAML vers votre ERP est souvent une demi-journée de travail pour un administrateur expérimenté.
MFA : activez le MFA sur les comptes Finance et RH de votre ERP cette semaine. Ce sont les comptes les plus ciblés et les plus exposés financièrement et réglementairement.
PAM : faites auditer les mots de passe de vos comptes de service ERP. Si un consultant a participé à votre dernier projet ERP et que son compte n’a pas été désactivé, désactivez-le aujourd’hui.
Gouvernance : planifiez votre première revue trimestrielle des habilitations ERP. Exportez la liste des comptes actifs, demandez aux managers de valider que chaque compte est légitime. C’est gratuit, c’est traçable, et c’est la base de toute démarche de conformité NIS2.
Pour approfondir la sécurité de votre ERP dans une perspective globale, lisez notre guide cybersécurité ERP et notre analyse des obligations DORA pour les ERP du secteur financier. Si vous pilotez un projet de conformité NIS2, notre article sur les contrôles de séparation des tâches dans l’ERP vous donnera les 12 contrôles à implémenter avant votre prochain audit.
