Munic certifie le device. Vous ne possédez que ce que vous ajoutez.

Déjà en production

Nous ne démarrons pas le CRA en 2027 — une grande partie est livrée aujourd'hui.

Les devices Munic sont certifiés CE RED — les exigences de cybersécurité de la directive sur les équipements radio (RED) font partie intégrante du marquage CE, et non d'un label distinct. Obligatoires depuis le 1 août 2025, Munic y répond au titre des normes harmonisées EN 18031-1:2024 (protection du réseau) et EN 18031-2:2024 (protection des données personnelles et de la vie privée), et les livre en produit depuis. Elles recouvrent largement les exigences essentielles du CRA, de sorte que l'écart vers la conformité CRA complète est incrémental, pas une reconstruction.

La date limite 2027

Quand vous pouvez vous auto-certifier — et quand un labo est exigé.

Le CRA classifie le device, pas le système d'exploitation. La plupart des devices s'auto-certifient, et Munic le réalise. Un audit et un labo ne sont exigés que lorsque le device porte une fonction de sécurité réglementée.

Les normes harmonisées qui débloquent l'auto-évaluation pour les devices à fonction réglementée ne sont pas encore publiées. Jusqu'à leur publication, cette classe emprunte une voie organisme notifié — et Munic la porte de toute façon, basculant en auto-évaluation dès que la norme paraît. Les devices de tracking et de télématique standard s'auto-certifient dès aujourd'hui, quoi qu'il en soit.

Seconde monte ou première monte

Même device — le régime applicable peut changer avec l’hôte.

Munic livre ses produits aussi bien en seconde monte autonome qu’en première monte intégrée. Ce qui régit le device dépend de l’endroit où il atterrit : seul, ou à l’intérieur d’un hôte réglementé.

La frontière exacte — surtout pour une unité livrée à un constructeur comme intrant de réception par type plutôt que vendue seule — se détermine produit par produit. Nous la cadrons programme par programme.

Comment nous aidons

Un projet de conformité pluriannuel, réduit à une fusion de documentation.

• Un device certifié — nous menons l'évaluation de conformité et apposons le marquage CE sur le matériel que nous fabriquons.

• Un OS pré-durci qui répond d'emblée aux exigences de sécurité produit.

• Un SBOM par release que vous intégrez directement dans votre dossier technique.

• Un verrouillage continu des CVE et des licences — les problèmes détectés à la fusion, pas à l'audit.

• Un canal de mise à jour signé qui sous-tend l'obligation pluriannuelle de mises à jour de sécurité.

• Un PSIRT géré et un pipeline de signalement des incidents pour la couche plateforme.

• Un pack de documentation technique pour le device, prêt pour votre dossier.

Intégré, pas ajouté

La conformité est une propriété runtime.

Les obligations CRA sont appliquées à la couche OS — pas via un processus ou un audit a posteriori.

• Noyau durci + rootfs immuable

  Image OS en lecture seule. Aucun paquet installé à l'exécution.

• Secure Boot + coffre-fort de clés ancré matériel

  Vérification d'image signée à chaque boot. Clés stockées dans un TEE (Trusted Execution Environment) sur le matériel supporté.

• Conteneur sandbox par micro service

  Moindre privilège par construction. Isolé par conteneur par micro service.

• Vérification cryptographique des mises à jour

  Livraison OTA (Over-the-Air) signée. Anti-rollback appliqué.

• Détection de falsification + intégrité firmware

  Vérification d'intégrité au boot ; les échecs bloquent le démarrage.

Comment le SDK l'applique →

Hygiène OSS

Dépendances open source — scannées, testées et contrôlées par licence.

Chaque micro service du catalogue est livré avec une posture d'hygiène open source (OSS) explicite — pas uniquement un pin de version.

• Nous scannons les OSS pour les CVE

  Le scan des avis CVE s'exécute en CI sur chaque micro service et bloque sur les avis critiques — aucune fusion jusqu'à la résolution ou l'acquittement explicite de l'avis.

• Nous testons les dépendances OSS

  Le comportement des dépendances transitives est exercé via les mêmes suites de tests CI de plateforme qui conditionnent chaque release. La surface OSS n'est pas supposée sûre par simple pin de version.

• Nous prévenons les licences contaminantes

  La liste d'autorisation est permissive uniquement — MIT, Apache-2.0, BSD-2/3-Clause, ISC, MPL-2.0, et équivalents. Exemple : LGPLv3 est bloqué car il exige la divulgation du source du binaire lié, incompatible avec la livraison d'une image firmware propriétaire sur le device du client.

L'hygiène OSS est l'une des raisons pour lesquelles les équipes conformité choisissent MOS4. Le contexte posture de conformité est à pourquoi-mos4 → posture de conformité. Le catalogue complet de micro services — chaque entrée avec son statut conformité — est à /fr/components. Les synthèses conformité et la justification de la liste d'autorisation sont disponibles à /fr/resources/whitepapers.

Mapping CRA

Les obligations — et ce que MOS4 fournit.

MOS4 couvre les obligations de sécurité produit que le CRA place à la couche OS. Le mapping ci-dessous est au niveau capacité ; les références exactes des articles figurent dans la synthèse conformité que nous partageons sous NDA.

PSIRT (Product Security Incident Response Team)

Divulgation responsable — et l'horloge de signalement du CRA.

Cycle de vie des données

Effacez les données personnelles sur commande — et prouvez-le.

Un seul événement de réinitialisation des données, typé, se propage à travers l'OS : chaque micro service détenant des données conducteur, véhicule ou diagnostic efface son propre état, et l'action est enregistrée. Un seul mécanisme pour trois tâches que votre programme doit déjà gérer.

La réinitialisation est déclenchée par configuration ou commande distante et se propage via les hooks de cycle de vie de la plateforme — diagnostics, données véhicule et le store persistant effacent chacun leur état, et le store applique en plus une rotation sur une politique de rétention configurable. Chaque réinitialisation est journalisée comme tout autre changement d'état, ce qui rend l'effacement prouvable après coup.

Alignement standards

Là où les contrôles MOS4 s'appliquent.

FAQ

Questions fréquentes

• Les devices Munic sont-ils déjà certifiés en cybersécurité aujourd'hui ?

  Oui. Les devices Munic sont certifiés CE RED — les exigences de cybersécurité de la directive sur les équipements radio (RED) font partie intégrante du marquage CE, et non d'un label distinct. La conformité est démontrée selon les normes harmonisées EN 18031-1:2024 (protection du réseau) et EN 18031-2:2024 (protection des données personnelles et de la vie privée), obligatoires depuis le 1 août 2025. Ces exigences recouvrent largement les exigences essentielles du CRA, de sorte qu'une grande partie du travail CRA est déjà construite et sur le terrain. La Déclaration de conformité RED est disponible sur demande.

• Ai-je besoin d'un audit par organisme notifié d'ici 2027, ou puis-je m'auto-certifier ?

  Cela dépend du device, pas du logiciel. Les devices de tracking et de télématique standard s'auto-certifient — et Munic le réalise — disponible dès aujourd'hui. Les devices dotés d'une fonction de sécurité réglementée (réseau, identité, classe VPN) ne s'auto-certifient qu'une fois qu'une norme harmonisée est publiée ; d'ici là ils empruntent une voie organisme notifié. Les devices critiques pour la sécurité nécessitent toujours un labo. Munic porte la voie dans tous les cas.

• Si je mets ma propre marque, mes conteneurs ou mon cloud sur le device, qu'est-ce qui devient de ma responsabilité ?

  Munic certifie toujours le device — matériel, OS, conformité, marquage CE et l'engagement de mises à jour de sécurité. Vous ne prenez en charge que ce que vous ajoutez : la conformité du code de vos propres conteneurs, votre propre cloud si vous l'exploitez, et votre nom comme fabricant désigné si vous marquez ou rebrandez le produit, par-dessus notre travail de conformité.

• Quels verrous CI s'exécutent sur chaque pipeline de micro service ?

  Scan de vulnérabilités connues (bloquant sur critique), verrou de politique de licences (bloque la fusion sur licences non autorisées), analyse du code non sûr, analyse statique (SAST) et génération de SBOM lisible par machine (informatif). Les 52 micro services héritent de ces verrous depuis un seul modèle CI partagé.

• Que contient le SBOM par release ?

  Un SBOM lisible par machine couvrant chaque dépendance open source du micro service. La publication du SBOM est informative ; les verrous de vulnérabilités et de licences sont les contrôles bloquants.

• Quelles sont les cibles de réponse aux patches ?

  Cibles internes : Critique 7 jours, Haute 30 jours, Moyenne 90 jours, Basse prochaine release. Ce sont des cibles internes — les SLA contractuels sont convenus par programme.

• Comment signaler une vulnérabilité ?

  Divulgation responsable via security@munic.io. Accusé de réception sous 5 jours ouvrables.

• La signature OTA est-elle disponible ?

  Oui. OTA avec paquets signés — chaîne de clés enracinée chez Munic. Le schéma de partition A/B conserve l'image précédente connue-bonne disponible pour un rollback automatique.

• Quel est le statut de l'alignement UNECE R155/R156 ?

  Les contrôles MOS4 sont auto-alignés avec R155/R156. L'évaluation formelle est conduite par programme — pas une certification générale.

• Que porte Munic vs ce que le client documente ?

  Munic porte le patching des CVE noyau, l'intégrité OTA, la publication SBOM, Secure Boot, le runtime sandbox et les verrous de sécurité appliqués en CI. Le client documente les menaces de logique métier, la politique de gestion des données, la couverture de tests applicatifs et le registre des risques spécifique au domaine.

AI Act

Posture AI Act européen.

MOS4 AI Language fournit des preuves structurées pour l'AI Act européen — enregistrements du manifeste d'audit pour les obligations de gouvernance des données §10, verrous du modèle de menace quantifiés pour la transparence §13, et découplage du cycle de vie matériel agnostique au silicium.