Laboratoire d'essais et conseil · Granges-Paccot

Réserver un appel

Règlement (UE) 2024/2847 · Logiciels

Logiciels et Cyber Resilience Act

Logiciels installés, applications mobiles, micrologiciels, logiciels fournis avec un appareil : le Cyber Resilience Act s'applique aux logiciels comme au matériel. Analyse de risques, SBOM, correction des vulnérabilités, mises à jour pendant la période d'assistance, signalement : Säfeli vous aide à savoir ce qui s'applique à votre logiciel et à le mettre en place avant le 11 décembre 2027.

Réserver un appel de 30 minVoir nos prestations
Signalement des vulnérabilités exploitées
11.09.2026
Application complète
11.12.2027
Assistance minimale, pas une valeur par défaut
5 ans
Nomenclature lisible par machine
SBOM

Pour qui

Quels logiciels sont concernés

  • Logiciels installés

    Applications de bureau, outils téléchargés, extensions de navigateur.

  • Applications mobiles

    Distribuées dans les boutiques d’applications, autonomes ou compagnons d’un appareil.

  • Micrologiciels

    Logiciel embarqué fourni avec un appareil ou mis sur le marché séparément.

  • Logiciels libres monétisés

    Éditions payantes, modèles « open core », assistance commerciale.

Nos prestations

Votre logiciel face au CRA

Du champ d’application aux processus qui doivent fonctionner pendant toute la période d’assistance.

Boîte de verre lumineuse diffusant des données vers un ordinateur, un smartphone et un appareil
Champ et classe

Votre logiciel est-il un produit ? De quelle classe ?

Mode de fourniture, activité commerciale, services distants nécessaires au logiciel, versions et variantes, fonctionnalité principale : nous déterminons si le CRA s'applique, si votre logiciel est important de classe I ou II et quelle procédure d'évaluation suivre.

Ce que vous recevez

  • Analyse du champ d’application
  • Classe et procédure d’évaluation
  • Périmètre des services distants

Références

  • CRA, art. 3 et 7 ; annexe III
  • Guide de la Commission C(2026) 5252
Puce électronique protégée par plusieurs couches de boucliers lumineux
Exigences

Analyse de risques et exigences essentielles

Sécurité par défaut, contrôle d'accès, chiffrement, intégrité, surface d'attaque, journalisation, effacement des données : sur la base d'une analyse des risques de cybersécurité, nous vérifions chaque exigence de l'annexe I et définissons les mesures à prendre.

Ce que vous recevez

  • Analyse de risques documentée
  • Tableau des exigences et justifications
  • Mesures de conception

Références

  • CRA, art. 13, par. 2 à 4
  • CRA, annexe I, partie I
L’analyse de menaces (TARA)
Graphe lumineux de dépendances logicielles avec un composant vulnérable en orange
SBOM et composants

SBOM et composants tiers

Nomenclature des logiciels lisible par machine, au moins pour les dépendances de premier niveau, diligence sur les composants tiers et libres, analyse de composition logicielle, signalement des vulnérabilités aux mainteneurs : vous savez en permanence ce que contient votre logiciel.

Ce que vous recevez

  • SBOM au format SPDX ou CycloneDX
  • Processus de diligence sur les composants
  • Suivi des vulnérabilités connues

Références

  • CRA, annexe I, partie II, point 1
  • CRA, art. 13, par. 5 et 6
Paquet scellé de mise à jour distribué par un faisceau lumineux vers de nombreux appareils
Mises à jour

Mises à jour, assistance et signalement

Période d'assistance justifiée et annoncée à l'achat, mises à jour de sécurité séparées des nouveautés quand c'est possible, distribution sécurisée, politique de divulgation coordonnée, signalement à l'ENISA en 24 heures, documentation technique : nous mettons en place les processus avec vous.

Ce que vous recevez

  • Période d’assistance justifiée
  • Politique de divulgation coordonnée
  • Processus de signalement et documentation

Références

  • CRA, art. 13, par. 8 à 10 et 19
  • CRA, art. 14 ; annexes II et VII
Le Cyber Resilience Act en détail

Et aussi

Champ d'application

Produit ou pas ? Les cas du guide de la Commission

Le guide d'application publié par la Commission le 27 juillet 2026 précise quand un logiciel est un produit au sens du CRA. Il n'est pas contraignant, mais c'est la référence des autorités.

  • Application mobile

    Téléchargée et installée depuis une boutique d’applications : c’est un produit au sens du CRA.

    Guide de la Commission, exemple 3

  • Application de bureau

    Même construite avec des technologies web, une application installée localement est un produit.

    Guide de la Commission, exemple 4

  • Application web dans le navigateur

    Accessible uniquement par un navigateur, elle n’est pas un produit à elle seule, sauf si elle sert une fonction d’un produit.

    Guide de la Commission, §20-21, exemple 5

  • Logiciel fourni avec un appareil

    Pilote, application de commande : il fait partie du produit, même s’il est téléchargé par un autre canal.

    Guide de la Commission, §25, exemples 8 et 9

  • Code source licencié

    Fourni à un client comme produit, il est mis sur le marché. Code d’exemple ou dépôt public non monétisé : non.

    Guide de la Commission, §22-24

  • Nouvelle version

    Chaque version est mise sur le marché à sa date. Une mise à jour non substantielle ne change rien ; une modification substantielle, si.

    Guide de la Commission, §13-15

Normes

Formats et normes utiles

Le CRA fixe les exigences ; ces formats et normes aident à les mettre en œuvre et à les démontrer.

RôleNormeObjet
SBOMSPDX 2.2.1 (ISO/IEC 5962:2021)Format de nomenclature logicielle ; SPDX 3.0 en cours de normalisation
SBOMCycloneDX 1.7 (ECMA-424, 2e éd.)Format de nomenclature logicielle, décembre 2025
SBOMBSI TR-03183-2 v2.1.0Directive technique allemande sur la SBOM, non contraignante
VulnérabilitésCVSS v4.0Système de notation de la gravité des vulnérabilités (FIRST)
CRAFprEN 40000-1-2*Principes, gestion des risques produit et activités du cycle de vie
CRAprEN 40000-1-3*Gestion des vulnérabilités
DéveloppementIEC 62443-4-1:2018Cycle de développement sécurisé des produits

* Projets en cours d'approbation au CEN et au CENELEC au 1er octobre 2026, non publiés et non cités au Journal officiel. Le CRA n'impose aucun format de SBOM ; la Commission peut en préciser un par acte d'exécution (art. 13, par. 24).

Logiciels libres

Logiciels libres et ouverts

Le CRA ne vise le logiciel libre que s'il est fourni dans le cadre d'une activité commerciale. Mais tout fabricant qui intègre des composants libres en reste responsable.

  • Non monétisé

    Un logiciel libre fourni sans activité commerciale n’est pas couvert. Les contributeurs ne sont pas visés.

    CRA, considérant 18

  • Monétisé

    Binaires payants, édition entreprise, version payante d’un modèle « open core » : l’éditeur est fabricant.

    Guide de la Commission, §51-57

  • Intendants de logiciels ouverts

    Fondations et entités qui soutiennent durablement un logiciel libre : régime allégé, sans marquage CE ni amende.

    CRA, art. 24 et 64, par. 10

  • Vous intégrez du libre

    Diligence raisonnable sur chaque composant, signalement des vulnérabilités trouvées à son mainteneur.

    CRA, art. 13, par. 5 et 6

Notre méthode

Votre logiciel conforme au CRA en quatre étapes

  1. Appel de découverte

    Votre logiciel, sa distribution, vos clients et votre calendrier. 30 minutes.

  2. Analyse des écarts

    Champ, classe, exigences, processus de développement et de mise à jour.

  3. Mise en conformité

    Analyse de risques, SBOM, processus de vulnérabilités, tests.

  4. Dossier

    Documentation technique, informations utilisateur et déclaration UE.

Marché suisse

Éditeurs suisses et CRA

Un logiciel suisse vendu ou distribué dans l'UE doit respecter le CRA comme tout autre. En Suisse, le Conseil fédéral prépare une loi fédérale sur la cybersécurité qui couvrira les logiciels et le matériel, sur la base du CRA, avec un projet attendu d'ici juin 2027.

Source : OFCS, communiqué du 25.09.2026.

Questions fréquentes

Questions fréquentes sur le CRA et les logiciels

Votre logiciel soulève une question particulière ? Posez-la directement à un ingénieur.

Réserver un appel
Une application web est-elle concernée ?

Une application web exécutée à distance et utilisée uniquement dans un navigateur n'est pas, à elle seule, un produit au sens du CRA. Elle le devient si elle sert une fonction d'un produit, par exemple le pilotage d'un appareil ou la configuration d'un logiciel installé : c'est alors un traitement de données à distance qui fait partie du produit.

Sources : Règlement (UE) 2024/2847, art. 3, point 2 ; guide de la Commission C(2026) 5252, §19 à 21

Mon logiciel est-il un produit important ?

C'est sa fonctionnalité principale qui compte. Classe I : gestion des identités et des accès privilégiés, navigateurs, gestionnaires de mots de passe, antivirus, VPN, systèmes de gestion de réseau, SIEM, gestionnaires de démarrage, infrastructures à clé publique, interfaces réseau virtuelles, systèmes d'exploitation. Classe II : hyperviseurs et environnements d'exécution de conteneurs, pare-feu, y compris applicatifs, et systèmes de détection et de prévention des intrusions. Intégrer un navigateur dans votre application ne rend pas celle-ci importante.

Sources : Règlement (UE) 2024/2847, annexe III ; règlement d’exécution (UE) 2025/2392 ; guide de la Commission, §136 à 144

Quand mon logiciel est-il « mis sur le marché » ?

Quand une version est terminée et fournie pour la première fois dans l'UE dans le cadre d'une activité commerciale. Toutes les copies de cette version sont réputées mises sur le marché à cette date, quel que soit le moment du téléchargement. Une version publiée à partir du 11 décembre 2027 doit donc être conforme.

Sources : Guide de la Commission C(2026) 5252, §13 et 14

Une mise à jour impose-t-elle une nouvelle évaluation de conformité ?

Seulement si elle constitue une modification substantielle, c'est-à-dire si elle change le niveau de risque d'une manière non prise en compte dans votre analyse de risques. Une mise à jour de sécurité ne l'est généralement pas ; une nouvelle interface accessible, un nouveau flux de données ou une nouvelle dépendance à un service tiers peuvent l'être.

Sources : Guide de la Commission C(2026) 5252, §104 à 110

Faut-il corriger les anciennes versions ?

Pas forcément. Vous pouvez ne corriger les vulnérabilités que dans la dernière version substantiellement modifiée, si les utilisateurs des versions antérieures peuvent y passer gratuitement et sans coûts supplémentaires d'adaptation de leur environnement. Chaque version garde sa propre période d'assistance.

Sources : Règlement (UE) 2024/2847, art. 13, par. 10 ; guide de la Commission, §128 à 131

Quel format pour la SBOM ?

Le CRA n'impose aucun format : il demande une nomenclature des logiciels dans un format couramment utilisé et lisible par machine, couvrant au moins les dépendances de premier niveau. SPDX et CycloneDX sont les deux formats de référence. La directive technique allemande BSI TR-03183-2 recommande CycloneDX 1.6 ou SPDX 3.0.1 au minimum, sans valeur contraignante. La Commission peut préciser le format par acte d'exécution.

Sources : Règlement (UE) 2024/2847, annexe I, partie II, point 1, et art. 13, par. 24 ; BSI TR-03183-2 v2.1.0

Les tests d’intrusion sont-ils obligatoires ?

Le CRA exige des tests et examens de sécurité efficaces et réguliers, et leurs rapports font partie de la documentation technique ; il ne nomme pas le test d'intrusion, mais la FAQ de la Commission le cite parmi les moyens adaptés. « Réguliers » ne veut pas dire répéter la même campagne à intervalle fixe : la fréquence et la profondeur suivent le profil de risque.

Sources : Règlement (UE) 2024/2847, annexe I, partie II, point 3, et annexe VII, point 6 ; guide de la Commission, §238 à 240

Réserver un appel

Parlez-nous de votre logiciel

Choisissez directement un créneau de 30 minutes avec un ingénieur. Pas d'échange d'e-mails : vous choisissez l'heure, nous préparons l'échange.

Choisir un créneau

Coordonnées

Adresse
Säfeli Sàrl
Route d'Englisberg 3
1763 Granges-Paccot
Téléphone
+41 79 737 37 93
Langues
Français, allemand, anglais
Réserver un appel