Selon l'entreprise, le poste s'appelle ingénieur sécurité embarquée, ingénieur cybersécurité produit, ingénieur sécurité IoT ou product security engineer. Il travaille avec les équipes firmware, électronique, cloud et industrialisation. Ses sujets reviennent d'une offre à l'autre : démarrage sécurisé et chaîne de confiance, mise à jour signée, stockage des secrets dans un TPM, un élément sécurisé ou TrustZone, cryptographie sur des ressources limitées, durcissement de Linux embarqué, analyse de menaces et gestion des vulnérabilités. Les questions d'entretien d'ingénieur sécurité embarquée couvrent ces sujets avec des cas de produit.
La réglementation a changé la demande. Depuis le 1er août 2025, les équipements radio connectés mis sur le marché de l'Union doivent respecter les exigences de cybersécurité de la directive RED. Le Cyber Resilience Act impose depuis le 11 septembre 2026 de signaler les vulnérabilités activement exploitées, et ses obligations principales s'appliquent au 11 décembre 2027. Un candidat à jour sait dire ce que ces textes changent pour un produit.
Attention aux CV qui listent des primitives cryptographiques sans cycle de vie. La révocation d'une clé, la ligne de fabrication et le SAV font partie de l'entretien. Le PDF reprend 30 questions sur six axes, avec un cas de 20 minutes et une grille de 1 à 4.
Briques et référentiels de la sécurité embarquée
Démarrage sécurisé et mise à jour signée
La ROM du SoC, MCUboot sur microcontrôleur ou le démarrage vérifié d'U-Boot sur Linux embarqué vérifient chaque étape avant de lui passer la main. La mise à jour reprend la même chaîne de signature, avec un compteur anti-retour. Le candidat doit savoir expliquer comment on révoque une clé.
TrustZone et Trusted Firmware-M
Sur les cœurs Arm Cortex-M33 et suivants, TrustZone sépare un monde sécurisé d'un monde non sécurisé. Trusted Firmware-M y fournit la cryptographie, le stockage protégé et l'attestation selon les API PSA. La certification PSA Certified sert de repère pour les puces et les produits.
TPM 2.0 et éléments sécurisés
Des composants dédiés qui génèrent et gardent les clés sans les exposer au processeur principal. Le TPM 2.0 est courant sur Linux embarqué, les éléments sécurisés (Microchip, NXP, Infineon, STMicroelectronics) sur microcontrôleur. Certains arrivent provisionnés par leur fabricant.
Cryptographie embarquée
Mbed TLS, wolfSSL ou les accélérateurs du SoC pour AES, ECC et les échanges TLS. Le poste demande de connaître les erreurs d'usage plus que les mathématiques : nonce réutilisé, mauvais aléa, comparaison qui fuit le temps, et l'arrivée des algorithmes post-quantiques normalisés par le NIST en 2024.
Durcissement de Linux embarqué
dm-verity pour l'intégrité du système de fichiers, SELinux ou AppArmor, seccomp, options de compilation durcies, services réduits. Ces mesures se décident avec l'ingénieur Linux embarqué et se vérifient par des tests automatisés.
Analyse statique et fuzzing
Règles CERT C ou MISRA C, analyseurs statiques, fuzzing des parseurs avec libFuzzer ou AFL++. Le candidat doit savoir où les placer dans la CI et quels résultats bloquent une version.
SBOM, VEX et CSAF
La SBOM liste les composants du firmware dans un format comme SPDX ou CycloneDX. Les déclarations VEX disent si une CVE touche réellement le produit, et CSAF met les avis de sécurité dans un format lisible par machine. Le PSIRT s'appuie sur les trois.
Référentiels produit
Les normes EN 18031 pour la directive RED, l'ETSI EN 303 645 pour l'IoT grand public, l'IEC 62443-4-1 et 4-2 pour les composants industriels. Le candidat n'a pas à les connaître toutes : il doit savoir laquelle s'applique au produit et ce qu'elle demande.
Cyber Resilience Act
Le règlement (UE) 2024/2847 impose aux fabricants la sécurité dès la conception, une durée de support, une SBOM et la gestion des vulnérabilités. Le signalement des vulnérabilités activement exploitées s'applique depuis le 11 septembre 2026, les obligations principales au 11 décembre 2027.
L'ingénieur sécurité embarquée se place entre la R&D, l'industrialisation et le support. Il n'écrit pas tout le firmware, mais il fixe l'architecture de sécurité, relit le code sensible, prépare les évaluations et tient la gestion des vulnérabilités avec le PSIRT. Les offres françaises parlent de cybersécurité produit embarqué, de cryptographie et de normes de conformité, avec des niveaux confirmé à expert. Le profil vient souvent du développement embarqué, plus rarement de l'audit. Le poste reste distinct de celui de pentester IoT, qui attaque le produit, et de celui d'ingénieur sécurité matérielle, spécialiste des canaux auxiliaires et de l'injection de fautes en laboratoire.
Ce que l'entretien d'un ingénieur sécurité embarquée doit établir
- Analyse de menaces et exigences produit
- Démarrage sécurisé, révocation et mise à jour
- Secrets, provisionnement et cycle de vie
- Cryptographie sous contraintes
- Durcissement et tests du firmware
- PSIRT, SBOM et réglementation produit
Cinq cas de produit pour un ingénieur sécurité embarquée
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
La R&D lance un nouveau capteur connecté. Comment menez-vous l'analyse de menaces, et que remettez-vous aux développeurs ?
Une bonne réponseIl décrit le produit : ce qu'il faut protéger (firmware, clés, données, fonctions), ses interfaces (radio, debug, USB, cloud, application mobile) et son cycle de vie, de la fabrication à la fin de vie en passant par le SAV. Il déroule les menaces interface par interface, avec STRIDE ou une méthode équivalente, distingue l'attaquant à distance de celui qui a l'objet en main, puis cote les risques. Les développeurs reçoivent des exigences testables reliées à chaque menace, avec les hypothèses d'usage. L'analyse est reprise à chaque évolution notable du produit.
Signal d'alerteL'OWASP IoT Top 10 recopié comme analyse, ou des exigences du type « le produit doit être sécurisé ».
Question 2 · senior
Vous concevez la hiérarchie de clés du démarrage sécurisé. Comment prévoyez-vous la révocation d'une clé de signature compromise sur des produits déjà vendus ?
Une bonne réponseLa racine de confiance, en ROM et en fusibles OTP, prévoit plusieurs empreintes de clés publiques, pour pouvoir en invalider une. La clé racine reste hors ligne dans un HSM et signe des clés intermédiaires, qui signent les images. Un compteur anti-retour en OTP empêche de réinstaller une ancienne version. La révocation passe par une mise à jour signée par une clé encore valide, qui grille l'emplacement compromis. Le scénario est essayé avant la mise sur le marché.
Signal d'alerteUne seule clé gravée sans possibilité de révocation, ou une clé de signature posée sur le serveur de build.
Question 3 · senior
Comment se passe l'injection des identités et des secrets sur la ligne de fabrication, quand celle-ci est chez un sous-traitant ?
Une bonne réponseIdéalement, la clé privée est générée dans l'élément sécurisé et n'en sort jamais, et seul son certificat est signé par une autorité de fabrication. Avec un sous-traitant peu sûr, il préfère des composants déjà provisionnés par leur fabricant (Microchip Trust&GO, NXP EdgeLock 2GO) ou un HSM de production qui limite le nombre de certificats émis et journalise chaque émission. Il rapproche les numéros de série émis des appareils produits et verrouille le debug juste après le provisionnement.
Signal d'alerteUn fichier de clés envoyé au sous-traitant par messagerie, ou la même clé pour tous les appareils.
Question 4 · confirmé
Un développeur utilise AES-GCM avec un compteur de nonce gardé en RAM. Qu'en pensez-vous ?
Une bonne réponseAprès un redémarrage, le compteur repart de zéro et le même nonce est réutilisé avec la même clé. Avec GCM, cela révèle le XOR des messages et permet de falsifier l'authentification. Il propose un compteur persistant écrit par blocs pour ménager la flash, des nonces aléatoires de 96 bits si le nombre de messages par clé reste faible, une clé de session renouvelée, ou un mode résistant à la réutilisation comme AES-GCM-SIV. Il vérifie aussi la source d'aléa.
Signal d'alerte« GCM est un standard, donc c'est sûr », sans voir le problème du redémarrage.
Question 5 · confirmé
Comment organisez-vous les tests de sécurité d'un firmware avant chaque version ?
Une bonne réponseDans la CI : analyse statique avec des règles comme CERT C ou MISRA C, analyse de composition et SBOM, fuzzing des parseurs (libFuzzer ou AFL++ sur hôte), tests de non-régression des fonctions de sécurité (refus d'une image non signée, anti-retour, debug verrouillé). S'y ajoutent une revue de code des parties sensibles, comme les parseurs, les protocoles et la mise à jour, et un test d'intrusion externe avant le lancement. Les critères bloquants sont fixés à l'avance.
Signal d'alerte« Un pentest une fois avant la sortie », sans tests automatisés ni critères de blocage.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Ingénieur sécurité embarquée : les questions fréquentes
Ingénieur sécurité embarquée ou pentester IoT : quelle différence ?
Le pentester IoT audite un produit fini et cherche ses failles. L'ingénieur sécurité embarquée conçoit la sécurité avant et après la sortie : architecture, exigences, provisionnement, correctifs. Pour construire un produit, c'est le second profil qui convient. Le premier est utile en complément, souvent chez un prestataire. Un candidat qui a fait les deux est précieux, à condition qu'il sache aussi parler d'exigences et de cycle de vie.
Faut-il un développeur embarqué de formation ?
Le plus souvent, oui. L'ingénieur sécurité embarquée doit lire du C, comprendre un bootloader, une carte mémoire et un RTOS, et discuter avec les équipes firmware sans traducteur. Un profil venu de la sécurité des SI peut réussir, mais il lui faudra du temps sur le matériel. En entretien, il explique ce qui se passe entre la mise sous tension et le premier octet de l'application.
Quel exercice est donné à un ingénieur sécurité embarquée ?
Un test technique court, fait en entretien, suffit : un extrait de code C qui vérifie une signature de firmware avec deux défauts (comparaison non constante, code retour ignoré), ou un schéma de produit dont il faut tirer les menaces et la hiérarchie de clés. Le candidat commente à voix haute. On voit s'il pense au démarrage, à la fabrication et à la mise à jour.
Le Cyber Resilience Act change-t-il le profil attendu ?
Il ajoute des tâches que beaucoup d'équipes ne faisaient pas : dossier technique, SBOM tenue à jour, durée de support annoncée, signalement des vulnérabilités exploitées dans des délais courts. Le candidat doit connaître ces obligations et savoir les traduire en processus d'ingénierie. Sans lui, la conformité repose sur le juridique, qui ne sait pas construire un firmware dans six ans.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
