Cyber Resilience Act : quels profils sécurité recruter

Le Cyber Resilience Act change la nature de la sécurité pour tous ceux qui fabriquent du matériel ou du logiciel vendu dans l'Union européenne. Elle ne relève plus seulement de l'équipe qui protège le système d'information : elle devient une propriété du produit, à démontrer avant la mise sur le marché et à maintenir pendant des années. Cet article relie les exigences du règlement aux compétences à recruter, et propose un ordre de priorité pour un éditeur ou un industriel.

Le Cyber Resilience Act en bref

Le règlement (UE) 2024/2847, dit Cyber Resilience Act (CRA), est disponible sur eur-lex.europa.eu. Comme DORA, c'est un règlement : il s'applique directement dans tous les États membres. Il vise les produits comportant des éléments numériques mis à disposition sur le marché européen, qu'il s'agisse d'objets connectés, de composants matériels ou de logiciels.

Quelques points structurants :

Un calendrier progressif. Le texte est entré en vigueur fin 2024. Les obligations de signalement des vulnérabilités activement exploitées et des incidents graves s'appliquent depuis le 11 septembre 2026. L'essentiel des autres obligations s'applique à partir du 11 décembre 2027.
Des exigences essentielles. L'annexe I fixe d'une part des propriétés de sécurité du produit (configuration sécurisée par défaut, absence de vulnérabilités exploitables connues à la mise sur le marché, protection des données, réduction de la surface d'attaque), d'autre part des exigences de gestion des vulnérabilités tout au long de la vie du produit.
Des catégories de produits. La plupart des produits relèvent d'une auto-évaluation par le fabricant. Les produits dits importants (annexe III) et critiques (annexe IV) suivent des procédures d'évaluation de la conformité plus exigeantes, pouvant impliquer un organisme tiers.
Une période de support. Le fabricant détermine une période pendant laquelle il traite les vulnérabilités. Le texte prévoit qu'elle soit d'au moins cinq ans, sauf si la durée d'utilisation attendue du produit est plus courte.
Des exclusions. Certains produits déjà couverts par des règles sectorielles, comme les dispositifs médicaux ou les véhicules, sont exclus.

Cet article ne remplace pas une analyse juridique. Le classement de vos produits et les obligations qui en découlent sont à vérifier avec vos équipes conformité et juridiques.

Ce que le texte demande en pratique

Concevoir des produits sûrs

Le fabricant doit réaliser une évaluation des risques de cybersécurité du produit et en tenir compte dès la conception, le développement et la production. Cette évaluation figure dans la documentation technique. Autrement dit, la modélisation des menaces, les revues d'architecture et les tests de sécurité deviennent des preuves de conformité, pas seulement de bonnes pratiques.

Gérer les vulnérabilités dans la durée

La partie II de l'annexe I demande notamment :

d'identifier et de documenter les composants du produit, y compris en établissant une nomenclature logicielle (SBOM) ;
de traiter et corriger les vulnérabilités sans délai, en fournissant des mises à jour de sécurité ;
de tester régulièrement la sécurité du produit ;
de mettre en place une politique de divulgation coordonnée des vulnérabilités et un point de contact pour les signaler ;
de publier des informations sur les vulnérabilités corrigées.

Notifier vite

L'article 14 impose de signaler les vulnérabilités activement exploitées et les incidents graves ayant un impact sur la sécurité du produit, via une plateforme unique gérée par l'ENISA, au CSIRT désigné comme coordinateur. Le texte prévoit une alerte précoce sous 24 heures, une notification sous 72 heures, puis un rapport final. Ces délais supposent une veille et une capacité de qualification déjà en place.

Documenter et démontrer

Avant la mise sur le marché, le fabricant établit une documentation technique, mène la procédure d'évaluation de la conformité applicable, rédige une déclaration UE de conformité et appose le marquage CE. Il doit aussi surveiller la sécurité des composants tiers qu'il intègre, y compris open source.

Des exigences aux profils

Exigence CRA	Profil principal	Ce qu'il apporte
Pilotage du programme, arbitrages produit	Responsable sécurité produit (Product Security Officer)	Porte le sujet auprès de la direction et des équipes produit, fixe les priorités
Évaluation des risques, sécurité dès la conception	Architecte sécurité produit	Modélisation des menaces, revues d'architecture, exigences de sécurité
Absence de vulnérabilités connues, tests réguliers	Ingénieur sécurité applicative, pentester	Revues de code, tests automatisés, tests d'intrusion du produit
SBOM, composants tiers, chaîne de build	Ingénieur DevSecOps	Outillage de la chaîne CI/CD, inventaire et suivi des dépendances
Divulgation coordonnée, correctifs	Responsable PSIRT	Réception des signalements, tri, coordination des correctifs et des avis
Notification sous 24 et 72 heures	Analyste réponse à incident, profil PSIRT	Qualification rapide, chronologie factuelle, liaison avec le CSIRT
Documentation technique, conformité, marquage CE	Spécialiste conformité produit, profil GRC	Dossier technique, procédures d'évaluation, veille réglementaire
Produits embarqués et industriels	Ingénieur sécurité embarquée ou OT	Démarrage sécurisé, mises à jour signées, durcissement du matériel

Dans une PME, une même personne couvre souvent plusieurs lignes. L'important est qu'aucune ne reste sans responsable. Notre article sur les profils à recruter pour NIS2 suit la même démarche du côté des organisations, et celui sur DORA dans la finance pour le secteur financier.

Les profils les plus disputés

Le responsable sécurité produit

C'est la pièce centrale. Il connaît le cycle de développement, parle aux chefs de produit et aux juristes, et sait transformer un texte réglementaire en exigences de backlog. Les candidats viennent souvent de la sécurité applicative, de l'architecture ou du conseil. Évaluez sa capacité à arbitrer : un cas pratique où il doit choisir entre une date de sortie et une correction de vulnérabilité en dit plus long qu'une liste de normes.

Le responsable PSIRT

Beaucoup d'éditeurs n'ont jamais eu d'équipe dédiée à la réponse aux vulnérabilités de leurs produits. Le CRA la rend indispensable. Ce profil combine des réflexes de réponse à incident, une bonne compréhension technique du produit et un sens de la communication externe, car il échange avec des chercheurs, des clients et des autorités. Notre guide pour recruter un responsable de la réponse à incident donne une base d'évaluation à adapter.

L'ingénieur sécurité applicative et DevSecOps

Le SBOM, l'analyse des dépendances, les tests automatisés et la signature des mises à jour vivent dans la chaîne de développement. Il faut des ingénieurs capables de les y intégrer sans bloquer les équipes. Voir notre guide pour recruter un ingénieur sécurité applicative et nos questions d'entretien AppSec et DevSecOps.

L'architecte sécurité produit

Pour les produits importants ou critiques, la qualité de l'évaluation des risques et de la documentation technique pèse lourd. Un architecte capable de documenter des choix de conception et de les défendre devant un organisme tiers est un atout. Notre article pour recruter un architecte sécurité détaille les points à vérifier.

Prioriser ses recrutements

Pour un fabricant qui se prépare, voici un ordre qui fonctionne souvent :

Nommer un pilote. Un responsable sécurité produit, interne ou recruté, qui inventorie les produits concernés et leur catégorie.
Tenir la notification. Les obligations de signalement s'appliquent déjà. Un circuit de réception et de qualification des vulnérabilités, avec un responsable PSIRT, est la première urgence opérationnelle.
Outiller la chaîne de développement. Un ingénieur DevSecOps pour le SBOM, l'analyse des dépendances et les mises à jour de sécurité.
Renforcer la conception. Un architecte ou un ingénieur sécurité applicative pour les évaluations de risques et les revues de code.
Préparer la conformité. Un profil conformité produit pour la documentation technique et les procédures d'évaluation, en particulier si certains produits relèvent des annexes III ou IV.

L'ordre dépend de votre point de départ. Un éditeur déjà doté d'une équipe AppSec mature commencera par le PSIRT ; un industriel qui découvre le sujet commencera par le pilotage et l'inventaire.

Les pièges à éviter

Confier le CRA à la seule équipe sécurité du SI. Protéger le système d'information et sécuriser un produit sont deux métiers différents. Le second se joue avec les équipes produit et R&D.
Chercher « un profil CRA ». Ce métier n'existe pas. Partez des exigences non couvertes et recrutez les compétences correspondantes.
Sous-estimer la durée. La période de support engage le fabricant sur plusieurs années. Les recrutements doivent viser une capacité durable, pas une mission ponctuelle avant 2027.
Recruter sur le vocabulaire réglementaire. Un candidat qui cite les annexes n'est pas forcément capable de lire un SBOM ou de trier un signalement. Évaluez sur des cas concrets.
Oublier l'embarqué. Pour les objets connectés et les produits industriels, les compétences en sécurité matérielle et en mise à jour à distance sont rares. Anticipez ces recherches.

En résumé

Le Cyber Resilience Act fait de la sécurité une caractéristique du produit, à démontrer et à maintenir. Il rend indispensables des fonctions que beaucoup de fabricants n'avaient pas formalisées : un pilote de la sécurité produit, une équipe de réponse aux vulnérabilités, une chaîne de développement outillée et une documentation solide. Commencez par la notification, qui s'applique déjà, puis construisez la capacité durable qu'exige le reste du texte.

Vous préparez vos équipes produit au Cyber Resilience Act ? Chez Cyber Recrut, un recruteur et un praticien de la sécurité cadrent le poste avec vous et mènent la recherche ensemble. Nos candidats présélectionnés prouvent leurs compétences sur des labs pratiques adaptés au poste. Découvrez notre méthode ou partagez votre besoin.