Comprendre les coûts du MFA dans les environnements OT et on-premise

Déployer le MFA (Multi-Factor Authentication) dans un environnement OT ou on-premise coûte environ 30 à 60 $ par utilisateur en matériel, 0 à 6 $ par utilisateur et par mois en licences logicielles, et environ un tiers du budget projet en opérations, ce qui couvre la formation, le helpdesk et les cas limites absents des pages tarifaires cloud.

Pour les sous-traitants de la défense, les opérateurs d'utilités et les industriels soumis aux obligations CMMC, NIS2 et NERC CIP, le MFA n'est pas optionnel. La vraie question est de savoir comment le budgéter sans dépenser excessivement en formats d'authentification qui ne tiennent pas en environnement de production.

Trout propose une autre approche : déplacer le MFA au niveau du micro-segment réseau, et permettre aux opérateurs de s'associer à des enclaves flexibles pour la durée d'une tâche ou d'un poste.

Cet article décompose les coûts directs et indirects, compare les six approches entre lesquelles il faudra réellement choisir, et présente une démarche de budgétisation qui résiste au contact des opérateurs.

Comparaison des six approches MFA en OT

La plupart des sites finissent par combiner deux ou trois des options ci-dessous. La question n'est pas vraiment « laquelle ». C'est « quel mélange, pour quel rôle ».

Un sous-traitant de la défense combinera typiquement des cartes PIV sur les postes d'ingénierie avec un système badge+PIN sur les cellules HMI. Une utilité utilisera des clés FIDO2 sur le chemin d'accès distant des fournisseurs et des lecteurs de badge partout ailleurs. Le mélange dépend du rôle et du site, pas d'un standard d'entreprise unique.

Pourquoi les déploiements OT et on-premise coûtent plus

Quelques contraintes invalident le modèle de coût IT avant même la moindre tarification.

• Postes partagés : un seul HMI est utilisé par dix ou douze personnes sur trois équipes. La facturation à la place suppose un humain par poste, ce qui ne reflète pas la réalité de la production. Soit vous payez en sessions concurrentes, soit vous provisionnez chaque opérateur individuellement en acceptant la surcharge de connexion.
• Sites air-gappés : les notifications push d'un IdP cloud supposent que l'appareil peut atteindre Internet. Beaucoup de sites OT ne le peuvent pas. Les alternatives sont un IdP on-premise, un cache local d'identifiants ou des tokens matériels qui ne nécessitent pas de réseau. Chaque option a sa propre structure de coût.
• Exigences de latence : un aller-retour cloud de deux secondes à chaque connexion est acceptable pour la finance ou les RH. Il ne l'est pas pour un opérateur qui réagit à une alarme. L'authentification en environnement de production doit se résoudre localement, ce qui implique généralement un palier de licence différent ou une infrastructure auto-hébergée.
• Gants et badges : les opérateurs portent des gants. Les écrans tactiles, les lecteurs d'empreintes et la plupart des dispositifs biométriques grand public ne fonctionnent pas à travers. Les badges RFID associés à un PIN distinct restent l'option pratique la plus courante.
• HMI hérités : une part importante des HMI en production fonctionne sous Windows 7, XP-embarqué ou une pile fournisseur figée à un niveau de correctif précis. Ils ne peuvent pas héberger un agent d'authentification moderne. La solution est généralement un proxy : un jump host, un reverse proxy ou des contrôles d'accès au niveau réseau en amont du HMI. C'est une ligne budgétaire distincte.

Coûts indirects et réalités opérationnelles

Au-delà des chiffres affichés en matériel et licences, les déploiements OT comportent des coûts indirects qui déterminent souvent si un projet tient le budget.

• Attrition des tokens : les tokens en atelier sont perdus, lavés ou abîmés. Prévoir 8 à 12 % de réémission par an sur des sites mêlant intérieur et extérieur.
• Friction lors des passages de poste : si le MFA ralentit le passage de relais, les opérateurs contourneront : session partagée, porte calée, post-it. Soit l'UX absorbe la friction par une ré-authentification rapide, soit la posture de sécurité l'absorbe par des accès non tracés.
• Cycle de vie PKI : les cartes à puce exigent une émission, une révocation et un renouvellement de certificats continus. Prévoir au moins un ETP dédié sur un parc moyen, avec des cycles de re-cartage tous les deux ou trois ans.
• Itération du pilote : le premier pilote sur un site révèle systématiquement des cas non anticipés : imprimantes nécessitant des comptes de service exemptés, ordinateurs portables fournisseurs qui n'arrivent pas à s'enrôler, bâtiments sans couverture. Prévoir 15 à 25 % du coût projet pour ces itérations imprévues.
• Pic au helpdesk : prévoir un pic de tickets multiplié par 3 à 5 durant les six premières semaines. Un support sous-dimensionné est l'endroit où les contournements MFA non autorisés apparaissent.

Cadres réglementaires et obligations de conformité

Le MFA en OT n'est plus une décision purement sécuritaire. Quatre cadres en font une obligation contractuelle :

• NIST 800-171 §3.5.3 (repris dans CMMC niveau 2) : MFA pour les comptes privilégiés et non privilégiés, pour les accès locaux et réseau, sur les systèmes traitant des informations non classifiées contrôlées (CUI). Pas d'exception pour le réseau d'usine.
• Directive NIS2 (secteurs Annexe I) : exigences MFA explicites pour les entités essentielles et importantes, dont l'énergie, l'eau, l'alimentation, le transport et la fabrication de produits critiques. La transposition varie d'un État membre à l'autre, mais le seuil reste constant.
• NERC CIP-007 R5.7 : MFA pour les accès distants interactifs aux BES Cyber Systems d'impact Moyen ou Élevé. Les écarts documentés sont désormais sanctionnés par des pénalités à sept chiffres.
• IEC 62443-3-3 SR 1.1 : identification et authentification des utilisateurs humains, de plus en plus citée dans les questionnaires sécurité des clients et les contrats à proximité du DoD.

Si un site relève de l'un des cadres ci-dessus, la question n'est plus de savoir s'il faut déployer le MFA, mais comment le faire sans acheter des outils qui ne correspondent pas à la réalité opérationnelle.

L'approche Trout du MFA entre IT et OT

Le tableau des coûts change lorsque le MFA est appliqué au niveau réseau plutôt que sur chaque poste. Trout déploie une enclave autour de l'ensemble des systèmes auxquels un opérateur doit accéder, avec une authentification à la frontière de l'enclave plutôt qu'à l'intérieur de chaque HMI, PLC ou jump host.

Concrètement, un opérateur s'installe à n'importe quel poste, se connecte une fois avec son MFA, et sélectionne en deux ou trois clics les machines qu'il utilisera durant son poste. Ses permissions sont appliquées à ces machines au niveau réseau, et chaque commande émise pendant cette session est journalisée sous son identité. À la fin de la session, l'enclave est libérée.

Le même modèle s'étend de l'IT à l'OT sans modification, parce que l'application ne dépend pas de ce que le poste peut exécuter. Cela retire le principal moteur de coût des déploiements OT, à savoir les équipements hérités qui ne peuvent pas héberger d'agent d'authentification, et le remplace par un unique point de contrôle au niveau réseau.

Budgéter un déploiement MFA en OT

Trois pratiques améliorent systématiquement les résultats budgétaires :

1. Piloter une seule zone avant le déploiement complet. Un pilote de 30 jours sur une cellule ou une grappe de HMI fait remonter la plupart des surprises de coût pour une semaine d'ingénierie. Les déploiements de site sans pilote sont l'endroit où les itérations imprévues se multiplient.
2. Standardiser un seul format de token par rôle. Maintenir simultanément des clés FIDO2, des cartes à puce et des authentificateurs mobiles pour la même population d'opérateurs triple la charge du helpdesk et la logistique de réémission.
3. Allouer un tiers du budget aux opérations. Le matériel et les licences sont visibles dès le départ ; le coût opérationnel reste invisible jusqu'au déploiement. Une répartition raisonnable pour un premier déploiement est de 35 % matériel, 30 % licences et logiciels, 35 % opérations et formation, à ajuster après la première année avec les données réelles du helpdesk.

Trout consolide le contrôle d'accès, la segmentation, l'application du MFA et la journalisation d'audit dans un seul déploiement on-premise dont le client est propriétaire de bout en bout. Ajouter un site ou un groupe d'opérateurs est un changement de configuration au niveau réseau, pas un déploiement par appareil ; le coût opérationnel de la mise à l'échelle n'augmente donc pas avec la taille du parc.

Conclusion

Le MFA en environnements OT et on-premise coûte plus que ne le suggère la page tarifaire cloud, mais le coût reste très inférieur à la moyenne de 4,45 millions de dollars d'une violation de données et aux pénalités réglementaires désormais en vigueur sous CMMC, NIS2 et NERC CIP. Un budget défendable commence par un pilote sur une seule zone, une stratégie de token standardisée par rôle, et une allocation honnête pour le travail opérationnel qui n'apparaît sur aucune page tarifaire fournisseur.