TL;DR — l'essentiel en 5 points
- Règlement UE 2024/2847 applicable aux produits avec éléments numériques mis sur le marché européen.
- Deux jalons : 11 septembre 2026 (signalement opérationnel) et 11 décembre 2027 (application complète, marquage CE-Cyber obligatoire).
- Exigences techniques : sécurité by design, SBOM tenu à jour 5 ans, VDP opérationnel, signature des artefacts, gestion des vulnérabilités avec MTTR maîtrisé.
- Sanction : sans marquage CE-Cyber conforme = plus de mise sur le marché EU, y compris mises à jour des produits déployés.
- Roadmap réaliste : 18 mois entre décision et conformité opérationnelle. Démarrer maintenant si vous ne l'avez pas fait.
Le contexte 2026
Le CRA est le règlement européen le plus impactant pour les éditeurs de logiciels en 2026-2027. Sa logique :
Élargissement du périmètre. Là où NIS et NIS2 ciblaient les opérateurs critiques, le CRA s'applique à tous les produits avec éléments numériques. SaaS B2B, IoT, applications mobiles, firmware, plugins commerciaux : la quasi-totalité du marché logiciel est concernée.
Exigences techniques précises. Pas seulement de la gouvernance — des contrôles techniques explicites : SBOM, VDP, signature, MTTR vulnérabilités, surfaces d'attaque limitées.
Verrou commercial. Sans marquage CE-Cyber au 11 décembre 2027, plus de mise sur le marché européen. Y compris pour les mises à jour des produits déjà commercialisés. C'est une barrière qui peut éjecter un éditeur entier du marché EU.
Êtes-vous concerné ?
Très probablement oui :
- Inclus : SaaS B2B, applications mobiles commerciales, IoT, firmware, librairies redistribuées commercialement, drivers, plugins commerciaux, jouets connectés.
- Exclus partiels : open source non commercialisé (mais obligations spécifiques pour les "open source stewards" — organisations qui maintiennent du logiciel open source à but commercial).
- Exclus : services purs sans composant logiciel embarqué (rare).
Si vous facturez du logiciel d'une manière ou d'une autre, présumez que vous êtes dans le périmètre.
Les classes de produits
Le CRA distingue trois classes selon le niveau de risque :
Produits standard
La majorité des SaaS B2B. Auto-évaluation de conformité par l'éditeur, documentation à la disposition des autorités.
Produits "important"
Listés en Annexe II. Exemples : routeurs, firewalls, gestionnaires de mots de passe, antivirus, navigateurs, systèmes industriels. Évaluation par un tiers ou autoréalisée selon le sous-classement.
Produits "critical"
Listés en Annexe III. Exemples : OS, processeurs sécurisés, dispositifs cryptographiques, smart cards. Audit obligatoire par organisme notifié.
Pour la majorité des SaaS B2B européens, vous êtes en classe standard. C'est important : le coût et la complexité de mise en conformité sont significativement moindres qu'en classe "important" ou "critical".
Le jalon 1 — 11 septembre 2026
À cette date, vous devez être opérationnel sur :
Programme de signalement de vulnérabilités (VDP)
- Canal : security.txt à la racine du domaine (RFC 9116), email security@, formulaire optionnel.
- Procédure : acknowledgment dans 48h, triage avec criticité, coordination avec le chercheur, correction.
- Politique publique : page /security/policy avec périmètre, règles d'engagement, hall of fame.
Voir Vulnerability disclosure CRA.
Notification ENISA
- Vulnérabilités activement exploitées : 24h.
- Incidents critiques : 24h (early warning), 72h (notification complète), 14 jours (rapport final).
Capacité opérationnelle requise : runbook d'incident à jour, contact ENISA / CSIRT national établi, templates de communication pré-rédigés.
Voir Gérer un incident cyber en 7 étapes.
Le jalon 2 — 11 décembre 2027
À cette date, application complète. Sans marquage CE-Cyber, plus de mise sur le marché EU.
Exigences essentielles (Annexe I, partie 1)
- Sécurité by design et configuration sécurisée par défaut.
- Protection contre les accès non autorisés.
- Confidentialité des données traitées.
- Intégrité du code, configurations, données.
- Surfaces d'attaque limitées (interfaces, services, ports).
- Observabilité (logs).
- Correctifs en temps voulu.
Cycle de vie (Annexe I, partie 2)
- Identification et documentation des vulnérabilités sur la durée de vie du produit (5 ans minimum).
- SBOM maintenu à jour, machine-lisible.
- Correctifs gratuits et en temps voulu.
- Information transparente sur les vulnérabilités traitées.
Documentation technique
Dossier complet pour démontrer la conformité, comprenant : description du produit, périmètre, classes de risque, architecture cyber, contrôles, SBOM, gestion des vulnérabilités, tests effectués, marquage CE-Cyber et déclaration de conformité UE.
Le SBOM CRA-compliant
C'est probablement l'exigence la plus opérationnelle du CRA. Voir SBOM CRA-compliant.
Spécificités CRA :
- Format machine-lisible : SPDX ou CycloneDX.
- Éléments minimaux : nom, version, fournisseur, identifiant unique (PURL/CPE), hash, licence, dépendances, auteur, date.
- Mise à jour continue : à chaque release, à chaque correction.
- Conservation sur la durée de support (5 ans).
- Disponibilité aux autorités à la demande, et aux utilisateurs pour produits critical.
- Provenance vérifiable pour produits critical : signature Sigstore, lien hash avec artefact, idéalement SLSA Level 2+.
Roadmap pratique sur 18 mois
Mai-Juin 2026 — Diagnostic
- Cartographie produits dans le périmètre CRA.
- Classification (standard / important / critical).
- Audit sécurité existant : écarts par rapport aux exigences essentielles.
- SBOM initial sur le produit principal.
- Désignation d'un référent CRA.
Juillet-Août 2026 — Outillage signalement
- Canal de signalement (security.txt + email + bug bounty optionnel).
- Process incident enrichi pour délais ENISA.
- Templates de communication client / autorités / médias.
Septembre 2026 — DEADLINE 1
- Capacité de signalement opérationnelle.
- Premier exercice de table-top avec scenario CRA.
Octobre 2026 — Mars 2027 — Industrialisation technique
- Sécurisation pipeline CI/CD (DevSecOps quality gates).
- SBOM automatisé sur toutes les builds, signé Sigstore.
- MTTR vulnérabilités < 30 jours pour Critical, < 90 jours pour High.
- Documentation technique structurée.
Avril 2027 — Septembre 2027 — Pre-audit
- Pre-audit interne ou externe.
- Closure des gaps identifiés.
- Formation des équipes.
Octobre 2027 — DEADLINE 2
- Pour produits "important" et "critical" : audit par organisme notifié.
- Pour produits standard : auto-évaluation documentée.
- Marquage CE-Cyber appliqué.
Articulation avec les autres règlements
CRA n'est pas isolé. Pour un éditeur SaaS B2B européen :
- NIS2 : conformité parallèle obligatoire si vous êtes EE/EI. Voir NIS2 transposition.
- DORA : si vous fournissez à des entités financières.
- AI Act : si vous embarquez de l'IA, double conformité.
- ISO 27001 : socle qui couvre 50-60% des exigences CRA. Démarche recommandée en parallèle. Voir ISO 27001 SaaS B2B.
Les pièges en mission
"On verra ça plus tard"
12 mois pour bâtir l'opérationnel, ce n'est pas long. Les organismes notifiés vont être saturés en 2027. Démarrer en 2027 = risque réel de ne pas être prêt à temps.
"On délègue à un cabinet juridique"
Le CRA est techniquement contraignant. Un cabinet juridique seul ne peut pas vous mettre en conformité. Il faut un duo juridique + technique.
"On a déjà ISO 27001"
ISO 27001 vous facilite environ 50-60% du chemin. Les 40-50% restants sont CRA-spécifiques : SBOM, VDP, signature, surfaces d'attaque limitées par construction.
"Le SBOM, on a un script"
Un SBOM CRA-compliant est : automatique, à jour à chaque build, exportable SPDX/CycloneDX, signé, lié à l'artefact, archivé 5 ans. Un script bash listant node_modules ne suffit pas.