Conformité CRAPar AzertyUI Team

Le Cyber Resilience Act demande aux fabricants de corriger les vulnérabilités et de fournir des mises à jour de sécurité pendant toute la période de support. Sur un produit embarqué installé chez des clients, cela suppose une chaîne de mise à jour à distance (OTA) fiable et sûre.
1. Le démarrage sécurisé
Le secure boot vérifie, à chaque démarrage, la signature de chaque étage logiciel (chargeur d’amorçage, noyau, système). Il crée une chaîne de confiance ancrée dans le matériel : un logiciel modifié ne démarre pas.
2. Des mises à jour signées
Chaque paquet de mise à jour est signé par le fabricant ; le produit vérifie la signature avant installation. La clé privée de signature est protégée (idéalement dans un module matériel) et son usage est tracé.
3. Pouvoir revenir en arrière
Une mise à jour interrompue ou défectueuse ne doit pas rendre l’appareil inutilisable. Les schémas à deux partitions (A/B) installent la nouvelle version à côté de l’ancienne et ne basculent qu’après un démarrage réussi.
4. Empêcher les retours en arrière malveillants
À l’inverse, un attaquant ne doit pas pouvoir réinstaller une ancienne version vulnérable : une protection anti-retour (compteur de version) l’en empêche.
5. Relier les mises à jour au SBOM
Chaque version livrée a son SBOM : c’est ce qui permet de savoir quels appareils doivent être mis à jour quand une vulnérabilité est publiée.
Ces choix d’architecture sont difficiles à rattraper après coup : mieux vaut les valider tôt, lors d’une analyse d’écart CRA sur le produit.
Article informatif à jour au 29 septembre 2026. Les textes réglementaires et leurs calendriers évoluent : il ne constitue pas un avis juridique.
Tags Associés
- Code signing
- CRA
- Embedded software
- Logiciel embarqué
- OTA
- Secure boot
- Signature de code


