Anna Mazzone de ServiceNow discute des obligations de la Cyber Resilience Act et des raisons pour lesquelles davantage d'entreprises de logiciels irlandaises pourraient être concernées que la plupart ne le pensent.
La première date limite de la loi européenne sur la cyber-résilience, le 11 septembre, a activé les obligations de déclaration de l'article 14 pour toute entreprise irlandaise qui développe des logiciels, ou les fait développer et les commercialise sous son propre nom.
Cela inclut les clients téléchargeables, les applications mobiles, les micrologiciels intégrés, les logiciels freemium et tout produit connecté à un appareil ou à un réseau. La définition de « fabricant » donnée par la loi est légale plutôt que descriptive, et les produits qu'elle couvre s'étendent au matériel et aux logiciels.
La loi exige que les produits soient sécurisés dès leur conception, sécurisés par défaut et sécurisés tout au long de leur cycle de vie. Rien de moins ne peut être mis sur le marché de l’UE. L’obligation de déclaration est arrivée en premier, plus d’un an avant les exigences techniques complètes attendues en décembre 2027.
En vertu du droit de l’UE, un fabricant est toute personne ou entreprise qui développe ou fait développer des produits comportant des éléments numériques et les commercialise sous son propre nom ou sa propre marque, qu’ils soient payants, monétisés ou gratuits.
Le qualificatif est l'activité commerciale. Les logiciels fournis en dehors d'une activité commerciale, y compris les logiciels libres et open source que leur éditeur ne monétise pas, ne sont pas soumis à la réglementation.
Il contient des composants freemium et open source monétisés par leur fabricant d'origine. Un produit comportant des éléments numériques est un produit logiciel ou matériel, ainsi que le traitement de données à distance dont il a besoin pour fonctionner.
Comparez cela à ce que les entreprises technologiques irlandaises expédient réellement. Le National Cyber Security Center (NCSC) répertorie les systèmes d'exploitation et les applications mobiles aux côtés des ordinateurs portables et de l'IoT industriel dans sa description des produits concernés.
Les services cloud autonomes sont soumis à des règles distinctes. Mais lorsqu’une fonctionnalité cloud fait partie intégrante du fonctionnement du produit, elle devient partie intégrante du produit aux fins de l’ARC.
Il n'y a pas de test sur la chaîne de production. Si vous écrivez un logiciel et que vous y mettez votre nom, vous êtes dans le champ d'application.
Ce qui s'applique maintenant
Deux choses déclenchent le chronomètre : une vulnérabilité activement exploitée dans l'un de vos produits ou un incident grave affectant la sécurité de ce produit.
A partir du moment où vous en avez connaissance, vous disposez de 24 heures pour déposer une alerte précoce et de 72 heures pour la faire suivre d'une évaluation de la gravité. Les deux périodes découlent de la conscience et non l'une de l'autre. Puis les deux déclencheurs se séparent. Une vulnérabilité nécessite un rapport final dans les 14 jours suivant la disponibilité d'un correctif, ce qui peut être des mois plus tard, voire jamais. Un incident nécessite un rapport final dans le mois suivant le dépôt de 72 heures.
Les rapports sont acheminés via la plateforme de reporting unique de l'ENISA vers l'équipe nationale de réponse aux incidents de sécurité informatique (CSIRT), qui, pour les entreprises qui prennent leurs décisions en matière de cybersécurité de leurs produits en Irlande, est le CSIRT-IE au sein du NCSC. Le NCSC a publié le 31 août des lignes directrices sur les rapports au titre de l'article 14 et gère un service d'assistance de l'ARC, bien qu'il indique clairement qu'il ne donnera pas de conseils sur la question de savoir si un produit donné est concerné.
Il y a plus que des rapports à rencontrer. Les exigences essentielles en matière de cybersécurité impliquent de protéger le produit contre tout accès non autorisé, de le prendre en charge et de le mettre à jour pendant sa durée de vie indiquée et de porter le marquage CE.
Chaque État membre désigne ses propres autorités de surveillance du marché, et elles peuvent exiger qu'un produit soit rectifié, retiré ou rappelé. Les amendes sont échelonnées. Les articles 13 et 14 se situent dans la fourchette la plus élevée à côté de ces exigences, au plus élevé de 2,5 % du chiffre d'affaires annuel mondial total de l'exercice précédent ou 15 millions d'euros. Décembre 2027 est le début des amendes.
La loi précède également la législation irlandaise en matière de cybersécurité.
Le projet de loi nationale sur la cybersécurité, qui transposera la directive NIS2, n'a pas encore été publié. Le Gouvernement prévoit de notifier la transposition d'ici fin 2026. La loi sur la cyber-résilience est un règlement plutôt qu'une directive, elle s'applique donc directement et n'attend pas le droit national.
Six pratiques qui vous mettent en mesure de vous conformer
Intégrer la conformité dans le développement de produits
Intégrez les évaluations des risques de sécurité dès la phase de conception et définissez les contrôles à partir de là. Les moderniser après l’expédition d’un produit coûte à chaque fois plus cher.
Suivez les marquages de sécurité et les engagements des fournisseurs
Assurez-vous que les fournisseurs vous donnent les mêmes assurances que celles attendues par vos clients et stockez ces réponses là où l'équipe chargée des incidents peut les trouver facilement.
Même si une vulnérabilité provient d'un composant que vous n'avez pas développé, vous en êtes toujours responsable. Le NCSC a désigné la sécurité de la chaîne d’approvisionnement comme l’un des trois risques systémiques dans son évaluation nationale des cyber-risques de 2025 et a recommandé dès le départ de renforcer les règles d’approvisionnement en matière de sécurité.
Intégrer la gestion des vulnérabilités
Recherchez en permanence les vulnérabilités, partagez ce que vous trouvez avec vos clients et maintenez un processus de mise à jour solide et bien défini. L’article 14 teste cela directement, car l’horloge de 24 heures démarre indépendamment du fait qu’un processus soit en place ou non.
Gouverner l'accès
Les produits doivent être protégés contre les accès non autorisés grâce à des mécanismes de contrôle appropriés, notamment l'authentification, la gestion des identités et des configurations par défaut sécurisées.
Testez régulièrement la résilience
Les tests continus de scénarios, d'impact et de tolérance valident la gestion sécurisée du cycle de vie plutôt que de la laisser sur papier.
Tenir à jour une nomenclature logicielle (SBOM)
Documentez et fournissez un inventaire complet des composants avec chaque produit que vous vendez. L'Open Source Security Foundation a découvert en juin que seuls 32 % des fabricants produisaient un SBOM pour chaque produit qu'ils expédiaient.
Ce que tu gagnes
Le gain apparaît la première fois qu’un rapport arrive. Savoir ce qu'il y a à l'intérieur de ce que vous expédiez transforme « ce composant dans un produit vivant » après une semaine d'enquête en quelques minutes.
Un seul enregistrement d'incident signifie que la notification dans les 72 heures s'appuie sur celle de 24 heures plutôt que de recommencer. L’exposition des fournisseurs que vous pouvez déjà voir est une chose de moins à rechercher dans la journée. Et un décideur nommé doté d'une réelle autorité signifie que vous ne passez jamais le temps à attendre qu'un appel monte de trois niveaux et revienne. C’est ce dernier facteur qui fait le plus souvent que les entreprises ne respectent pas les délais.
Ce travail rapporte au-delà du régulateur. Les clients demandent désormais un SBOM et une politique de divulgation des vulnérabilités lors de l'approvisionnement et lisent la réponse comme un signal indiquant si vous êtes un fournisseur sûr.
La loi demande aux éditeurs de logiciels de démontrer quelque chose que la plupart disent déjà à leurs clients. Depuis le 11 septembre, la réclamation est vérifiable.
Par Anna Mazzone
Anna Mazzone est vice-présidente de la résilience opérationnelle, des risques et de la sécurité pour la région EMEA chez ServiceNow et directrice non exécutive de la Global Legal Entity Identifier Foundation. En 2013, elle a fondé les premiers services partagés gérés KYC pour les marchés de capitaux mondiaux chez Thomson Reuters. En 2016, Anna a été nommée sur la « Women in Fintech Powerlist » d'Innovate Finance.
