Le Cyber Resilience Act vise des produits comportant des éléments numériques mis sur le marché de l'Union, pas les services en tant que tels. Un éditeur purement SaaS n'est donc pas mécaniquement dans le champ. Il peut y entrer dès lors qu'il met sur le marché un logiciel, un composant, un agent installé chez le client, ou une solution de traitement de données à distance nécessaire au fonctionnement d'un produit. Cette qualification détermine si vos valeurs d'authentification par défaut deviennent des caractéristiques réglementées.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. La qualification de votre offre au regard du règlement (UE) 2024/2847 est une analyse à part entière, qui doit être conduite et confirmée avec vos conseils.
Un éditeur SaaS est-il dans le champ ? La question à instruire sérieusement
Le réflexe fréquent — « nous ne vendons pas de matériel, nous ne sommes pas concernés » — est trop rapide. Le point de bascule n'est pas la présence de matériel : c'est le fait de mettre sur le marché un produit comportant des éléments numériques, ou une composante à distance sans laquelle ce produit ne fonctionnerait pas.
| Cas de figure | Pourquoi la question se pose | Ce que cela changerait côté authentification |
|---|---|---|
| Application multi-tenant, accès navigateur seul | Le service est consommé, rien n'est distribué | Analyse à mener ; les obligations produit ne s'imposent pas de ce seul fait |
| Agent ou connecteur installé chez le client | Un composant s'exécute hors de votre infrastructure | Valeur par défaut de l'agent, secret d'appairage, mise à jour |
| Bibliothèque, SDK ou image distribuée | Vous fournissez un élément numérique intégré ailleurs | Authentification par défaut des appels, secrets d'exemple |
| Composant embarqué chez un client industriel | Votre logiciel devient partie d'un produit vendu | Exigences répercutées par votre client, contractuellement ou non |
| Traitement à distance nécessaire au produit | Le produit ne fonctionne pas sans votre service | Continuité de l'authentification, révocation, durée de support |
Aucune de ces lignes ne tranche à votre place : elles indiquent où porter l'analyse. Deux erreurs sont à éviter symétriquement — conclure qu'un modèle SaaS exclut le règlement, ou l'appliquer par précaution à toute l'offre. La qualification se conduit offre par offre, avec vos conseils. Le raisonnement général du texte est repris dans notre lecture des obligations d'authentification du Cyber Resilience Act.
La valeur par défaut à la livraison : le vrai sujet d'un éditeur
Pour un fabricant de matériel, « pas de mot de passe par défaut » évoque une étiquette sous un boîtier. Pour un éditeur, l'équivalent est plus diffus, donc plus dangereux : ce sont les états initiaux qu'un client hérite sans les avoir choisis.
Le compte d'administration initial d'un tenant
À la création d'un espace client, quelqu'un devient administrateur. Trois pratiques courantes méritent réexamen : l'envoi d'un secret provisoire par courriel, le second facteur laissé facultatif pour ne pas freiner l'adoption, la conservation d'un compte de support dans le nouveau tenant. Le premier administrateur peut créer tous les autres : c'est l'accès dont la valeur par défaut compte le plus.
Les clés d'API générées à l'installation
Une clé créée automatiquement à l'ouverture d'un compte, affichée une fois puis oubliée, cumule souvent quatre défauts : portée maximale, absence d'expiration, aucun rattachement à une personne, et présence dans un dépôt de code quelques semaines plus tard. Une clé est un identifiant au même titre qu'un mot de passe, mais elle échappe aux politiques d'accès humaines. Des portées restreintes par défaut, une durée de validité et un inventaire consultable par le client pèsent plus qu'une recommandation en documentation.
Les environnements de démonstration
Bac à sable, instance d'essai, préproduction accessible aux commerciaux : comptes connus, mots de passe partagés en interne et, trop souvent, données réelles. Ces environnements sont rarement inclus dans le périmètre de conformité alors qu'ils exposent les mêmes mécanismes d'authentification. La règle est simple : si un client peut s'y connecter, cela compte.
La chaîne de composants tiers et open source
La gestion documentée des vulnérabilités sur la durée de support suppose de savoir ce que contient ce que vous livrez. La difficulté vient rarement du code écrit en interne : elle vient des bibliothèques embarquées, des images de base, des dépendances transitives et des composants d'authentification tiers.
Trois points de vigilance côté identité :
- une bibliothèque d'authentification qui vieillit dans un agent installé chez des centaines de clients ne se met pas à jour à votre rythme, mais au leur ;
- les exemples de configuration livrés avec un composant contiennent souvent des secrets de démonstration qui finissent en production ;
- révoquer une clé compromise suppose de savoir partout où elle a été distribuée.
L'inventaire des composants n'est pas un exercice documentaire : c'est la condition pour répondre en quelques heures quand une vulnérabilité touche une brique d'authentification.
La documentation de sécurité que vos clients vont exiger
Vos clients régulés répercutent leurs obligations par contrat, souvent plus vite que le calendrier réglementaire. L'effet est déjà visible dans les questionnaires de sécurité, qui se déplacent de « proposez-vous une double authentification ? » vers « quel est l'état par défaut d'un tenant, et comment le prouvez-vous ? ».
Quatre éléments seront demandés : l'état par défaut d'un espace nouvellement créé ; le fonctionnement du support lorsqu'il agit au nom d'un client, trace comprise ; la politique de portée et d'expiration des clés d'API ; le processus de publication d'un correctif et la durée de support annoncée. Les mêmes attentes se retrouvent dans les démarches de certification, ce que détaille notre lecture d'ISO/IEC 27001 côté éditeur.
Lorsque la valeur par défaut doit être relevée sans refondre le parcours existant, un déploiement en overlay d'une authentification déjà en place — comme le permet l'authentification cognitive de HIAsecure — évite de bloquer la feuille de route produit.
Par où commencer
- Faites qualifier l'offre, composant par composant, en listant tout ce qui quitte votre infrastructure : agents, SDK, images, extensions, connecteurs.
- Ouvrez un tenant vierge et documentez son état exact : comptes présents, second facteur actif ou non, clés existantes, accès de support.
- Inventoriez les clés d'API vivantes et leur portée réelle, puis fixez des valeurs par défaut restrictives pour les nouvelles.
- Traitez les environnements de démonstration comme des livraisons : mêmes règles d'accès, aucune donnée réelle.
- Écrivez la durée de support de chaque composant distribué, et vérifiez que l'authentification tient sur cette durée.
FAQ
Notre application est accessible uniquement par navigateur : sommes-nous hors champ ?
Ni automatiquement hors champ, ni mécaniquement dedans. Le règlement vise des produits mis sur le marché ; un service consommé à distance ne s'y assimile pas de plein droit, mais un composant distribué ou un traitement à distance nécessaire au fonctionnement d'un produit change l'analyse. À confirmer avec vos conseils.
Une clé d'API est-elle concernée par l'absence de mot de passe par défaut ?
Elle relève de la même logique : c'est un identifiant d'accès livré avec le produit. Une clé générée automatiquement, à portée maximale et sans expiration, constitue une valeur par défaut faible, même si on ne l'appelle jamais « mot de passe ».
Que faire de la fonction de support qui agit au nom d'un client ?
Elle n'a pas à disparaître, mais elle doit être encadrée : activation à la demande, rattachement nominatif à l'agent de support, information du client et journalisation exploitable par lui. C'est l'un des points les plus regardés dans les questionnaires de sécurité.
Nos clients nous imposeront-ils ces exigences avant l'échéance ?
C'est le scénario le plus probable. Les obligations principales portent à horizon fin 2027, mais les achats et les renouvellements de contrat intègrent les exigences bien avant.
Aller plus loin : NIS2 pour les éditeurs et hébergeurs · bourrage d'identifiants chez les éditeurs · poser une MFA en overlay d'un IdP existant · comptes à privilèges et PAM