Le Cyber Resilience Act — règlement (UE) 2024/2847 — traite l'authentification comme une caractéristique du produit, pas comme un réglage laissé à l'intégrateur. Deux exigences le résument côté accès : la sécurité dès la conception et l'absence de mot de passe par défaut. S'y ajoutent une gestion documentée des vulnérabilités sur la durée de support et des mises à jour de sécurité. Le règlement est en vigueur depuis fin 2024, ses obligations principales portent à horizon fin 2027 : les produits en cours de conception sont déjà concernés.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Le périmètre exact du règlement et la qualification de vos produits au regard de celui-ci doivent être confirmés avec vos conseils.
Un texte qui vise des produits, pas des organisations
C'est la différence la plus utile à saisir. Les autres textes européens de cybersécurité désignent des entités : une organisation entre dans le champ, puis met son système d'information en conformité. Le Cyber Resilience Act vise, lui, des produits comportant des éléments numériques mis sur le marché de l'Union, matériels comme logiciels. L'unité d'analyse n'est plus votre système d'information, c'est ce que vous vendez.
Trois conséquences pratiques :
- la conformité se démontre produit par produit, pas au niveau de l'entreprise ;
- elle engage des équipes hors de la boucle conformité habituelle : conception matérielle, firmware, développement, documentation, support ;
- elle ne s'arrête pas à la vente, puisqu'elle couvre la gestion des vulnérabilités et les mises à jour de sécurité pendant la durée de support.
La montée en charge est progressive : les obligations de notification s'appliquent avant les obligations principales.
L'authentification cesse d'être un paramètre de déploiement
Dans la pratique courante, l'authentification se décide après la conception : le client active ou non un second facteur, l'intégrateur configure le compte administrateur, l'exploitant change ou non les identifiants livrés. Le fabricant fournit une capacité, l'utilisateur assume le réglage.
Le règlement déplace ce curseur. La sécurité dès la conception signifie que l'état par défaut du produit fait partie du produit. Un équipement livré avec un compte administrateur commun à toute une série n'est pas mal configuré par son acheteur : c'est un produit dont la caractéristique d'authentification est défaillante à la source.
« Pas de mot de passe par défaut » : ce que l'exigence implique réellement
La formule paraît simple. Elle touche en réalité quatre zones, dont trois sont régulièrement oubliées.
La première mise en service
Il faut un mécanisme qui produise un secret propre à chaque unité, ou qui impose sa création avant tout usage. Cela suppose de traiter la mise en service sans réseau, sans écran ou sans clavier, situation banale sur des équipements embarqués. Renvoyer le problème à un « à changer après installation » mentionné dans la notice ne répond pas à l'exigence.
Le provisionnement d'usine
Les identifiants générés en production doivent être uniques, non déductibles d'un numéro de série et non conservés dans un référentiel exploitable. Une génération dérivée d'un identifiant matériel ressemble à de l'unicité sans en offrir la propriété : elle reste reproductible par quiconque connaît la règle.
Les comptes de secours
Tout produit prévoit un chemin de récupération : perte du secret, retour à la configuration d'usine, intervention après incident. Ce chemin est souvent le vrai mot de passe par défaut, parce qu'il ramène l'équipement dans un état connu et publiquement documenté. Il mérite autant d'attention que l'accès nominal, comme les règles de secret appliquées aux comptes sensibles.
Les comptes de maintenance constructeur
Compte de support du fabricant, accès de télémaintenance, séquence de dépannage partagée entre techniciens : ces accès existent dans le produit, ce sont donc des caractéristiques du produit. Leur existence n'est pas en cause ; leur caractère partagé, permanent et non tracé l'est.
Traduire les exigences en décisions d'authentification
| Exigence du règlement | Traduction concrète côté authentification | Question à se poser maintenant |
|---|---|---|
| Sécurité dès la conception | L'état livré est sûr sans action de l'acheteur | Que se passe-t-il si personne ne configure rien ? |
| Absence de mot de passe par défaut | Secret unique par unité, ou création forcée au premier usage | Deux exemplaires d'une même série partagent-ils un identifiant ? |
| Gestion des vulnérabilités sur la durée de support | Capacité à révoquer et renouveler un moyen d'accès sur le parc installé | Sait-on couper un accès de maintenance sans intervention sur site ? |
| Mises à jour de sécurité | Authentification des mises à jour et des comptes qui les déploient | Qui peut pousser un firmware, et comment le prouve-t-on ? |
| Documentation technique | Description des mécanismes d'accès, de récupération et de journalisation | La notice décrit-elle le chemin de récupération, ou l'évite-t-elle ? |
Le cycle de vie : ce qui se joue après la vente
Un produit conforme à la livraison peut cesser de l'être : la méthode d'authentification vieillit, les accès de maintenance s'accumulent, la documentation diverge du logiciel installé.
La révocation à distance. Sur un parc déployé, retirer un accès compte autant que l'accorder. Un identifiant technique valable indéfiniment sur des milliers d'unités relève d'un défaut de conception, pas d'un choix d'exploitation.
L'agilité des méthodes. Une méthode figée dans un firmware engage le produit pour toute sa durée de support. Prévoir de la remplacer — secret, certificat, passkey, facteur additionnel — coûte peu à la conception et beaucoup après coup.
Méthode de mise en conformité
- Inventoriez vos produits au sens du règlement, en distinguant ce que vous mettez sur le marché de ce que vous exploitez pour votre compte.
- Listez les accès embarqués : compte administrateur, comptes de service, port de console, interface de diagnostic, compte constructeur, télémaintenance.
- Éprouvez la sortie d'usine : sur une unité neuve, sans lire la notice, avec quel identifiant accède-t-on au produit ?
- Traitez le parcours de récupération avant le parcours nominal. Il est plus faible, et documenté publiquement.
- Fixez la durée de support et vérifiez que vos moyens d'authentification tiennent sur cette durée.
- Documentez les choix, pas seulement les fonctions : ce qui sera demandé, c'est la justification d'un niveau de protection adapté au risque.
Sur les accès les plus sensibles, une méthode non rejouable ne suffit pas toujours : il faut attester d'une intention humaine au moment de l'action, ce que vise l'approche d'authentification cognitive portée par HIAsecure.
FAQ
Le Cyber Resilience Act impose-t-il une technologie d'authentification ?
Non. Le règlement fixe des propriétés attendues — sécurité dès la conception, absence de mot de passe par défaut, gestion des vulnérabilités — sans prescrire de mécanisme. La charge de démontrer l'adéquation au risque revient au fabricant.
Un mot de passe unique par unité suffit-il ?
Il répond à l'exigence de non-réutilisation, ce qui est déjà un progrès net sur un identifiant de série. Il reste un secret transmissible, hameçonnable et rejouable, ce qui invite à regarder au-delà pour les accès d'administration.
Un produit déjà installé chez des clients est-il concerné ?
Le règlement porte sur la mise sur le marché, et les obligations de gestion des vulnérabilités s'inscrivent dans la durée de support annoncée. La situation d'un parc existant dépend de la qualification retenue et doit être instruite avec vos conseils.
Faut-il attendre fin 2027 pour agir ?
Non : le cycle de conception d'un produit dépasse souvent le délai restant, et la montée en charge est progressive, les obligations de notification arrivant avant les obligations principales.
Aller plus loin : panorama des textes européens · le CRA dans l'industrie · le CRA pour les éditeurs SaaS · supprimer les mots de passe