CRA en mode PME : par où commencer même sans RSSI ?

En 2025, le Cyber Resilience Act (CRA) ne concerne plus uniquement les grands éditeurs ou les industriels.

Les PME qui développent, exploitent ou distribuent un produit numérique (logiciel, SaaS, module, API, service cloud) sont directement concernées, même sans DSI ni RSSI interne.

📌 Le CRA impose en effet que la sécurité soit assurée et démontrable sur tout le cycle de vie du produit, de la conception à la fin du support.

👉 Bonne nouvelle : il est possible de démarrer simplement, sans expertise lourde, à condition d’adopter la bonne méthode.

🔍 Rappel essentiel : ce que le CRA attend réellement des PME

Contrairement à certaines normes, le CRA ne demande pas :

1. une certification,
2. un SOC,
3. ni une sécurité “militaire”.

Il exige surtout que l’éditeur ou le fournisseur soit capable de démontrer :

1. qu’il connaît ses produits,
2. qu’il maîtrise leurs vulnérabilités,
3. qu’il documente ses choix de sécurité,
4. qu’il assure un support et des mises à jour cohérents.

📎 Commission européenne (2024) :

“Manufacturers shall ensure that vulnerabilities are addressed throughout the expected product lifetime.”

✅ Mini-checklist CRA “PME ready” (sans RSSI)

🔹 1. Inventaire des produits et versions

Premier prérequis CRA : savoir ce que vous vendez.

Cela implique :

1. lister chaque produit ou service numérique,
2. identifier les versions actives,
3. préciser les composants majeurs (frameworks, dépendances critiques).

👉 Sans inventaire produit, aucune conformité CRA n’est possible.

🔹 2. Catalogage des vulnérabilités

Le CRA impose une gestion documentée des vulnérabilités, même simple.

Concrètement, une PME doit pouvoir montrer :

1. comment elle identifie les vulnérabilités (veille CVE, alertes éditeurs, retours clients),
2. comment elles sont qualifiées (critique / non critique),
3. comment elles sont corrigées ou contournées.

📊 Selon l’ENISA Threat Landscape 2024, plus de 60 % des incidents majeurs exploitent des vulnérabilités connues mais non suivies.

👉 Le suivi est aussi important que la correction.

🔹 3. Documentation de sécurité “by design”

Le CRA insiste fortement sur la sécurité dès la conception.

Sans jargon excessif, une PME doit pouvoir produire :

1. une description des principes de sécurité retenus,
2. des choix d’architecture défendables,
3. des mécanismes de protection de base (authentification, isolation, mises à jour).

👉 Il ne s’agit pas de documentation technique exhaustive, mais de justification raisonnée.

🔹 4. Plan de support & mises à jour

C’est l’un des points souvent sous-estimés par les PME.

Le CRA demande que vous puissiez expliquer :

1. combien de temps le produit est maintenu,
2. comment les correctifs sont diffusés,
3. comment les clients sont informés.

📌 Le support de sécurité fait partie intégrante de la conformité CRA, pas un bonus.

🧠 Le vrai enjeu pour les PME : les preuves, pas la technique

Dans la pratique, les contrôles CRA porteront sur :

1. la cohérence des informations,
2. la traçabilité des décisions,
3. la capacité à produire des preuves.

Sans outil structurant, les PME se retrouvent vite avec :

1. des documents dispersés,
2. des informations contradictoires,
3. une dépendance à une seule personne “qui sait”.

👉 C’est ici que la structuration fait toute la différence.

🚀 Structurer la conformité CRA sans RSSI avec CompliKey

CompliKey permet aux PME d’aborder le CRA comme un sujet de gouvernance produit, pas comme un chantier technique lourd.

La plateforme permet notamment de :

1. 📦 centraliser l’inventaire produits & versions,
2. 🐞 suivre les vulnérabilités et actions associées,
3. 📁 structurer la documentation sécurité by design,
4. 🔄 piloter le support et les mises à jour dans le temps,
5. 📊 disposer d’un tableau de bord CRA prêt pour audit.

👉 Même sans RSSI, la PME peut démontrer sa conformité de manière claire et défendable.