Munic zertifiziert das Gerät. Sie verantworten nur, was Sie hinzufügen.

Schon im Einsatz

Wir beginnen mit dem CRA nicht erst 2027 — vieles davon ist heute schon im Einsatz.

Munic-Geräte sind CE-RED-zertifiziert — die Cybersicherheitsanforderungen der Funkanlagenrichtlinie (RED) sind integraler Bestandteil der CE-Kennzeichnung, kein separates Siegel. Verpflichtend seit dem 1. August 2025, erfüllt Munic sie auf Basis der harmonisierten Normen EN 18031-1:2024 (Netzwerkschutz) und EN 18031-2:2024 (Schutz personenbezogener Daten und der Privatsphäre) und liefert sie seitdem im Produkt aus. Sie decken einen großen Teil der grundlegenden CRA-Anforderungen ab, sodass der Weg zur vollständigen CRA-Konformität schrittweise ist, kein Neubau.

Die Frist 2027

Wann Sie selbst zertifizieren können — und wann ein Labor vorgeschrieben ist.

Der CRA klassifiziert das Gerät, nicht das Betriebssystem. Die meisten Geräte zertifizieren selbst, und Munic führt es durch. Ein Audit und ein Labor sind nur vorgeschrieben, wenn das Gerät eine regulierte Sicherheitsfunktion trägt.

Die harmonisierten Normen, die die Selbstbewertung für Geräte mit regulierter Funktion freischalten, sind noch nicht veröffentlicht. Bis dahin nutzt diese Klasse einen Weg über eine benannte Stelle — und Munic trägt ihn in beiden Fällen und wechselt in dem Moment zur Selbstbewertung, in dem die Norm erscheint. Tracking- und Standard-Telematik-Geräte zertifizieren ohnehin schon heute selbst.

Nachrüstung oder Werkseinbau

Dasselbe Gerät — das maßgebliche Regime kann sich mit dem Träger ändern.

Munic liefert das Gerät sowohl als eigenständiges Nachrüstprodukt als auch als werkseingebaute Einheit. Was für das Gerät gilt, hängt davon ab, wo es landet: für sich allein oder innerhalb eines regulierten Trägers.

Die genaue Grenze — insbesondere für eine Einheit, die einem Fahrzeughersteller als Beitrag zur Typgenehmigung geliefert wird, im Gegensatz zum eigenständigen Verkauf — ist eine Bestimmung von Produkt zu Produkt. Wir legen sie pro Programm fest.

Wie wir helfen

Ein mehrjähriges Compliance-Projekt, reduziert auf einen Dokumentations-Merge.

• Ein zertifiziertes Gerät — wir führen die Konformitätsbewertung durch und CE-kennzeichnen die Hardware, die wir bauen.

• Ein vorgehärtetes OS, das die Produktsicherheitsanforderungen out of the box erfüllt.

• Ein SBOM pro Release, das Sie direkt in Ihre technische Dokumentation übernehmen.

• Kontinuierliches CVE- und Lizenz-Gating — Probleme werden beim Merge erkannt, nicht erst beim Audit.

• Ein signierter Update-Kanal, der die mehrjährige Sicherheitsupdate-Pflicht absichert.

• Ein verwaltetes PSIRT und eine Incident-Reporting-Pipeline für die Plattformschicht.

• Ein technisches Dokumentationspaket für das Gerät, fertig für Ihre Akte.

Eingebaut, nicht aufgeschraubt

Compliance ist eine Laufzeit-Eigenschaft.

CRA-Verpflichtungen werden auf der OS-Schicht durchgesetzt — nicht nachträglich über Prozess oder Audit.

• Gehärteter Kernel + immutables rootfs

  Read-only OS-Image. Keine ausgelieferten Pakete zur Laufzeit.

• Secure Boot + hardware-verankerter Key-Store

  Signiertes-Image-Verifikation bei jedem Boot. Schlüssel in einer TEE (Trusted Execution Environment) auf unterstützter Hardware abgelegt.

• Sandboxed Container pro micro service

  Least-privilege by construction. Container-isoliert pro micro service.

• Kryptografische Update-Verifikation

  Signierte OTA-Auslieferung (Over-the-Air). Anti-Rollback durchgesetzt.

• Manipulationserkennung + Firmware-Integrität

  Boot-Time-Integritätsprüfung; fehlgeschlagene Prüfungen blockieren den Startup.

Wie das SDK dies durchsetzt →

OSS-Hygiene

Open-Source-Abhängigkeiten — gescannt, getestet und lizenz-gegated.

Jeder micro service im Katalog wird mit einer expliziten Open-Source-Software-(OSS)-Hygiene-Postur ausgeliefert — nicht nur einem Versions-Pin.

• Wir scannen OSS auf CVE

  CVE-Advisory-Scan läuft in CI auf jedem micro service und blockiert bei kritischen Advisories — kein Merge, bis das Advisory behoben oder explizit bestätigt ist.

• Wir testen OSS-Abhängigkeiten

  Das Verhalten transitiver Abhängigkeiten wird durch dieselben Plattform-CI-Testsuites geprüft, die jedes Release absichern. OSS-Oberfläche wird nicht allein durch Versions-Pin als sicher angenommen.

• Wir verhindern kontaminierende Lizenzen

  Die Allow-Liste ist ausschließlich permissiv — MIT, Apache-2.0, BSD-2/3-Clause, ISC, MPL-2.0 und gleichwertige. Beispiel: LGPLv3 ist blockiert, da es die Offenlegung des Quellcodes des verlinkten Binaries erfordert, was mit dem Ausliefern eines proprietären Firmware-Images an das Gerät des Kunden unvereinbar ist.

OSS-Hygiene ist ein Grund, warum Compliance-Teams MOS4 wählen. Der Compliance-Profil-Kontext liegt unter why-mos4 → Compliance-Profil. Der vollständige micro service-Katalog — jeder Eintrag mit Compliance-Kennzeichnung — liegt unter /de/components. Compliance-Briefings und Allow-Listen-Begründungen sind unter /de/resources/whitepapers verfügbar.

CRA-Mapping

Die Verpflichtungen — und was MOS4 bereitstellt.

MOS4 deckt die Produktsicherheitsverpflichtungen ab, die der CRA auf der OS-Schicht verortet. Das Mapping unten ist auf Fähigkeitsebene; die genauen Artikelreferenzen stehen im Compliance-Briefing, das wir unter NDA teilen.

PSIRT (Product Security Incident Response Team)

Responsible Disclosure — und die CRA-Meldeuhr.

Daten-Lebenszyklus

Personenbezogene Daten auf Befehl löschen — und es nachweisen.

Ein einzelnes typisiertes Datenlösch-Ereignis verteilt sich über das gesamte OS: Jeder micro service, der Fahrer-, Fahrzeug- oder Diagnosedaten hält, löscht seinen eigenen Zustand, und die Aktion wird protokolliert. Ein Mechanismus — drei Aufgaben, die Ihr Programm ohnehin erledigen muss.

Das Zurücksetzen wird per Konfiguration oder Remote-Befehl ausgelöst und verbreitet sich über die Lifecycle-Hooks der Plattform — Diagnose, Fahrzeugdaten und der persistente Speicher löschen ihren eigenen Zustand, und der Speicher rotiert zusätzlich nach einer konfigurierbaren Aufbewahrungsrichtlinie. Jedes Zurücksetzen wird wie jede andere Zustandsänderung protokolliert, sodass die Löschung im Nachhinein nachweisbar ist.

Standardausrichtung

Wo MOS4-Controls gemappt sind.

FAQ

Häufig gestellte Fragen

• Sind Munic-Geräte heute schon für Cybersicherheit zertifiziert?

  Ja. Munic-Geräte sind CE-RED-zertifiziert — die Cybersicherheitsanforderungen der Funkanlagenrichtlinie (RED) sind integraler Bestandteil der CE-Kennzeichnung, kein separates Siegel. Die Konformität ist nach den harmonisierten Normen EN 18031-1:2024 (Netzwerkschutz) und EN 18031-2:2024 (Schutz personenbezogener Daten und der Privatsphäre) nachgewiesen, verpflichtend seit dem 1. August 2025. Diese Anforderungen decken einen großen Teil der grundlegenden CRA-Anforderungen ab, sodass ein Großteil der CRA-Arbeit bereits gebaut und im Feld ist. Die RED-Konformitätserklärung ist auf Anfrage erhältlich.

• Brauche ich bis 2027 ein Audit durch eine benannte Stelle, oder kann ich selbst zertifizieren?

  Es hängt vom Gerät ab, nicht von der Software. Tracking- und Standard-Telematik-Geräte zertifizieren selbst — und Munic führt es durch — heute verfügbar. Geräte mit einer regulierten Sicherheitsfunktion (Netzwerk, Identität, VPN-Klasse) zertifizieren erst selbst, sobald eine harmonisierte Norm veröffentlicht ist; bis dahin nutzen sie einen Weg über eine benannte Stelle. Sicherheitskritische Geräte brauchen immer ein Labor. Munic trägt den Weg in jedem Fall.

• Wenn ich meine eigene Marke, Container oder Cloud auf das Gerät bringe, was wird zu meiner Verantwortung?

  Munic zertifiziert immer das Gerät — Hardware, OS, Konformität, CE-Kennzeichnung und die Zusage zu Sicherheitsupdates. Sie übernehmen nur, was Sie hinzufügen: die Compliance Ihres eigenen Container-Codes, Ihre eigene Cloud, falls Sie sie betreiben, und Ihren Namen als benannter Hersteller, falls Sie das Produkt branden oder umbranden — aufbauend auf unserer Konformitätsarbeit.

• Welche CI-Gates laufen auf jeder micro service-Pipeline?

  Scan auf bekannte Schwachstellen (blockierend bei Kritisch), Lizenz-Policy-Gate (blockiert Merge bei unzulässigen Lizenzen), Analyse unsicheren Codes, statische Analyse (SAST) und maschinenlesbare SBOM-Generierung (informativ). Alle 52 micro services erben diese aus einem gemeinsamen CI-Template.

• Was wird im Pro-Release-SBOM ausgeliefert?

  Ein maschinenlesbares SBOM, das jede Open-Source-Abhängigkeit im micro service abdeckt. SBOM-Veröffentlichung ist informativ; die Schwachstellen- und Lizenz-Gates sind die blockierenden Kontrollen.

• Was sind die Patch-Response-Ziele?

  Interne Ziele: Kritisch 7 Tage, Hoch 30 Tage, Mittel 90 Tage, Niedrig nächstes Release. Dies sind interne Ziele — vertragliche SLAs werden pro Programm vereinbart.

• Wie melde ich eine Schwachstelle?

  Responsible Disclosure über security@munic.io. Bestätigung innerhalb von 5 Werktagen.

• Ist OTA-Signierung verfügbar?

  Ja. Signiertes Paket-OTA — Schlüsselkette verankert bei Munic. A/B-Partitionsschema hält das vorherige bekannte gute Image für automatisches Rollback bereit.

• Wie ist der Status der UNECE R155/R156-Ausrichtung?

  MOS4-Controls sind selbst an R155/R156 ausgerichtet. Formale Bewertung erfolgt pro Programm — keine pauschale Zertifizierung.

• Was trägt Munic vs. was dokumentiert der Kunde?

  Munic trägt Kernel-CVE-Patching, OTA-Integrität, SBOM-Veröffentlichung, Secure Boot, Sandboxed Runtime und CI-durchgesetzte Sicherheits-Gates. Der Kunde dokumentiert Geschäftslogik-Threats, Datenhandhabungspolicy, app-seitige Testabdeckung und domänenspezifisches Risikoregister.

AI Act

EU-KI-Gesetz-Positionierung.

MOS4 AI Language liefert strukturierte Nachweis-Inputs für das EU-KI-Gesetz — Audit-Manifest-Datensätze für die Daten-Governance-Pflichten in §10, quantifizierte Bedrohungsmodell-Gates für die Transparenzpflichten in §13 und silizium-agnostische Entkopplung des Hardware-Lebenszyklus.