Un éditeur de logiciel en mode service est concerné par NIS2 deux fois, pour des raisons différentes. D'un côté, le numérique figure parmi les secteurs couverts par la directive (UE) 2022/2555, ce qui peut faire de l'éditeur une entité concernée. De l'autre, et indépendamment de cette qualification, il est un maillon de la chaîne d'approvisionnement de ses clients concernés, lesquels doivent traiter le risque lié à leurs prestataires. La seconde lecture arrive presque toujours en premier, sous la forme d'un questionnaire sécurité envoyé au milieu d'un renouvellement.
Lecture opérationnelle et non avis juridique. NIS2 étant une directive transposée par chaque État membre, la qualification d'un éditeur en entité essentielle ou importante dépend du droit national applicable et doit être confirmée avec vos conseils.
La double casquette, et ce qu'elle change
| Vous, entité potentiellement concernée | Vous, prestataire d'une entité concernée | |
|---|---|---|
| Origine de l'exigence | Le texte national qui transpose la directive | Le contrat et le questionnaire de votre client |
| Déclencheur | Une qualification à confirmer avec vos conseils | Un renouvellement, un appel d'offres, un audit client |
| Périmètre visé | Votre propre organisation et vos systèmes | Le service que vous rendez et vos accès à leurs données |
| Ce qu'on vous demande | Des mesures de gestion des risques, dont l'authentification multifacteur ou continue | Des preuves : qui accède à quoi, comment c'est vérifié, comment c'est journalisé |
| Délai réel | Celui de la transposition applicable | Celui du cycle commercial, donc court |
La conséquence est contre-intuitive : même si l'analyse conclut que vous n'êtes pas une entité concernée, vos obligations opérationnelles ne diminuent pas — elles changent de véhicule et passent du réglementaire au contractuel. Pour le cadrage général, la synthèse des textes européens donne la vue d'ensemble ; la suite se concentre sur ce qui est propre à une architecture SaaS.
La console d'administration multi-tenant
C'est l'actif le plus critique d'un éditeur, et le plus souvent sous-protégé au regard de son pouvoir. Une console interne qui voit tous les clients concentre l'exposition de l'ensemble du portefeuille : un attaquant qui obtient une session d'administrateur ne cible plus un client, il les atteint tous. Trois écarts reviennent :
- La MFA de la console est celle de la messagerie. Le niveau d'exigence devrait suivre le pouvoir de l'outil, pas la commodité de l'annuaire.
- La session administrateur est longue. Un jeton volé reste utilisable après l'authentification initiale, ce qui rend la vérification d'entrée insuffisante à elle seule.
- Les actions destructrices ne sont pas réauthentifiées. Supprimer un tenant, exporter une base, modifier une rétention : ces opérations appellent une vérification au moment de l'action.
Les clés d'API et les comptes de service
Une plateforme SaaS manipule plus de secrets machine que de comptes humains. Jetons de service, clés d'intégration client, identifiants de la chaîne de déploiement continu ne s'authentifient pas comme des personnes, mais tombent sous la même question : qui les a créés, qui peut les utiliser, comment les révoque-t-on en urgence ? À instruire en priorité :
- des clés sans date de fin ni portée restreinte, créées pour un test ;
- des secrets partagés entre environnements, en particulier entre préproduction et production ;
- des préproductions alimentées par des données réelles, qui héritent d'une exposition de production avec un contrôle d'accès de recette ;
- l'absence de procédure de révocation en masse, alors qu'une fuite de dépôt de code en impose une dans l'heure.
La fonction de support qui prend l'identité du client
Presque toutes les plateformes permettent à un agent de support de voir l'interface comme un utilisateur client. C'est utile, et c'est le point le plus sensible du produit au regard des attentes sur les prestataires : un tiers — vous — accède aux données d'une entité concernée, potentiellement sans que celle-ci l'ait su. Ce qu'un client averti demandera :
- Le consentement est-il tracé côté client ? Une bascule déclenchée sans trace visible par le client est très difficile à défendre en audit.
- La bascule est-elle réauthentifiée ? Prendre l'identité d'un utilisateur est une action sensible : elle appelle une vérification dédiée, distincte de la session du matin.
- Le journal est-il exploitable par le client ? Un journal que seul l'éditeur peut lire ne suffit pas à démontrer la maîtrise côté entité concernée.
- La bascule expire-t-elle ? Une session d'usurpation persistante devient un accès permanent.
C'est le cas d'usage où la nuance entre authentifier une session et prouver une intention prend une valeur contractuelle. Un facteur qui atteste d'une action consciente au moment précis de la bascule, comme le facteur cognitif, répond directement à la question posée par l'auditeur du client.
Les questionnaires sécurité : préparer les preuves, pas les réponses
À mesure que les clients concernés structurent leur gestion du risque tiers, leurs questionnaires passent des déclarations aux preuves. Une réponse « nous avons la MFA » appelle désormais une contre-question sur la résistance de la méthode et sur son périmètre réel.
Ce qui se prépare une fois et sert à tous les clients : un inventaire des accès internes aux données client, la politique d'authentification par niveau de privilège, la description du mécanisme de support et de sa traçabilité, la procédure de révocation d'urgence, et la liste de vos propres sous-traitants — car la chaîne continue derrière vous. L'application d'ISO 27001 à un éditeur donne une structure d'accueil à ces preuves.
Séquence de mise en œuvre
- Classer les surfaces d'authentification par pouvoir : console interne, back-office client, application utilisateur, API, chaîne de déploiement.
- Élever l'exigence sur la console interne en premier, avec une méthode résistante au relais.
- Introduire la réauthentification sur action pour les opérations irréversibles et la bascule d'identité de support.
- Inventorier et faire expirer les secrets machine, à commencer par ceux qui traversent les environnements.
- Rendre les journaux d'accès consultables par le client : une charge d'audit devient un argument commercial.
- Vérifier les parcours de récupération de compte, support téléphonique compris : c'est le chemin le plus court pour contourner tout le reste.
FAQ
Si nous ne sommes pas une entité concernée, sommes-nous tranquilles ?
Non, et c'est la principale surprise pour les éditeurs. Vos clients concernés doivent traiter le risque lié à leurs prestataires, donc à vous. Les exigences arrivent par le contrat et les questionnaires, avec des délais commerciaux plus courts que ceux du droit.
Le SSO fédéré de nos clients couvre-t-il le sujet ?
Il couvre l'authentification de leurs utilisateurs, pas la vôtre. Vos administrateurs internes, votre support et vos automatismes de déploiement n'empruntent pas ce chemin : ce sont eux qu'un audit examine.
Faut-il de l'authentification multifacteur sur les clés d'API ?
La notion de facteur s'applique aux personnes, pas aux machines. Pour les secrets machine, l'exigence équivalente est ailleurs : portée restreinte, durée limitée, rotation documentée, révocation rapide et journalisation des usages.
Comment encadrer l'usurpation d'identité de support sans dégrader le service ?
En la traitant comme une action sensible et non comme un confort : déclenchement tracé et visible du client, vérification dédiée au moment de la bascule, durée limitée, journal remis au client. Le support reste rapide, mais il devient démontrable.
Aller plus loin : le CRA pour les éditeurs · NIST SP 800-63 appliqué au SaaS · vol de jeton de session · IAM et CIAM