NIS2 en 2026 : ce qui change pour la sécurité des SaaS

Où en est NIS2 en France

La directive devait être transposée au plus tard le 17 octobre 2024. En France, le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité porte cette transposition, et l’ANSSI prépare déjà les futures entités (pré-enregistrement, référentiel ReCyF). Le détail de l’état d’avancement est dans notre article sur la transposition de NIS2 en France. Restez prudent sur les délais et listes de contrôles tant que les textes d’application ne sont pas figés.

Deux situations existent pour un éditeur :

• Vous êtes vous-même une entité concernée, selon votre secteur, votre taille et votre activité (par exemple certains services d’informatique en nuage ou de services gérés).
• Vous êtes concerné indirectement parce que vos clients doivent évaluer la sécurité de leurs fournisseurs (article 21 de la directive, « sécurité de la chaîne d’approvisionnement »).

Dans les deux cas, la question posée par le client est la même : si votre produit est compromis, qu’est-ce que l’attaquant obtient chez moi ?

Les failles que NIS2 met en lumière

1. Isolation insuffisante entre clients

Dans un SaaS multi-tenant, tous les clients partagent la même base. Il suffit d’un paramètre tenant_id ou org_id accepté depuis le client sans vérification côté serveur pour qu’un utilisateur d’une collectivité lise les données d’un hôpital. C’est la faille la plus coûteuse pour un fournisseur, car elle transforme un incident chez un client en incident chez tous. Nous la détaillons dans l’isolation des clients dans un SIRH multi-tenant.

2. Accès support et comptes d’administration

Un compte support capable d’ouvrir n’importe quel espace client, protégé par un simple mot de passe, est la porte d’entrée idéale. Le phishing ou un poste infecté suffisent. L’impact est celui d’une attaque de la chaîne d’approvisionnement : un seul compte donne accès à des dizaines de clients.

3. Jetons d’intégration à longue durée de vie

Connecteurs vers la paie, l’annuaire ou la comptabilité : ces jetons ont souvent des droits larges et n’expirent jamais. Volés une fois, ils restent valables des mois.

4. Correctifs lents sur la stack

NIS2 demande une gestion des vulnérabilités. Un framework ou une dépendance exposée plusieurs semaines après la publication d’un correctif critique est exactement ce que les attaquants exploitent en masse.

5. Pas de journaux exploitables

Sans trace des accès aux données (qui a lu quoi, depuis quel compte), impossible de dire à un client ce qui a fuité. Or la directive impose aux entités une alerte précoce sous 24 heures et une notification sous 72 heures à l’autorité ; elles vous demanderont ces informations très vite.

Comment le tester

Ces vérifications sont faisables en une journée sur un environnement de préproduction, avec des comptes de test :

1. Isolation. Créez deux organisations de test. Depuis l’organisation A, rejouez chaque requête d’API en remplaçant l’identifiant de ressource ou d’organisation par celui de B. Toute réponse 200 avec des données de B est une faille critique.
2. Comptes support. Listez les comptes capables d’accéder à plusieurs clients. Vérifiez que l’authentification multifacteur est imposée, que l’accès exige un motif et qu’il est journalisé.
3. Jetons. Inventoriez les jetons d’intégration actifs, leur portée et leur date de création. Un jeton de plus d’un an sans rotation est un risque concret.
4. Correctifs. Comparez les versions de vos dépendances critiques (framework web, ORM, bibliothèque d’authentification) aux dernières versions corrigées. Mesurez le délai réel entre publication et déploiement sur vos trois derniers correctifs.
5. Journaux. Consultez la fiche d’un salarié de test, puis demandez à votre équipe de retrouver l’événement : qui, quand, depuis quelle adresse. Si la réponse prend plus d’une heure, vous ne tiendrez pas les délais.

Comment corriger

• Autorisation côté serveur sur chaque ressource, avec l’organisation déduite de la session et jamais d’un paramètre client. Des politiques RLS ou un middleware d’autorisation testé automatiquement.
• Accès support encadré : MFA obligatoire, accès limité dans le temps et validé, journalisation visible du client.
• Jetons à portée réduite et rotation planifiée.
• Délai de correction écrit pour les failles critiques, et veille sur vos dépendances.
• Journal d’accès aux données sensibles conservé et consultable.
• Dossier de preuves prêt pour les questionnaires de sécurité clients : résultats de tests récents, procédure d’incident, liste des sous-traitants.

Ce que ça change quand votre produit embarque un agent IA

Un assistant intégré au produit (recherche dans les dossiers, rédaction de courriers, réponses aux salariés) hérite de toutes ces failles et en ajoute une : il lit des contenus que l’attaquant peut contrôler. Un document importé ou un message reçu peut contenir une instruction qui pousse l’agent à chercher des données hors de son périmètre ou à les envoyer ailleurs. Si les outils de l’agent ne vérifient pas eux-mêmes l’organisation de l’utilisateur, l’isolation entre clients ne tient plus qu’au prompt.

Pour un client soumis à NIS2, cet agent fait partie de votre chaîne d’approvisionnement au même titre que votre API. Il doit être testé comme tel. Le Red Team Agent Express vous donne en cinq jours un rapport de preuves sur ce que votre agent laisse passer, réutilisable face aux questions de vos clients.