Munic certifies the device. You own only what you add.

Already shipping

We don't start the CRA in 2027 — much of it ships today.

Munic devices are CE RED certified — the Radio Equipment Directive's cybersecurity requirements are part of the CE mark, not a separate badge. Mandatory since 1 August 2025, Munic meets them under the harmonised standards EN 18031-1:2024 (network protection) and EN 18031-2:2024 (personal-data and privacy protection), and has shipped them in product since. These overlap much of the CRA's essential requirements, so the gap to full CRA conformity is incremental, not a rebuild.

The 2027 deadline

When you can self-certify — and when a lab is mandated.

The CRA classifies the device, not the operating system. Most devices self-certify, and Munic performs it. An audit and a lab are only mandated when the device carries a regulated security function.

The harmonised standards that unlock self-assessment for regulated-function devices are not yet published. Until they are, that class uses a notified-body route — and Munic carries it either way, switching to self-assessment the moment the standard lands. Tracking and standard telematics devices self-certify today regardless.

Aftermarket or factory-fit

Same device — the governing regime can change with the host.

Munic ships both as standalone aftermarket products and as factory-fit units. What rules the device depends on where it lands: on its own, or inside a regulated host.

The exact line — especially for a unit shipped to a vehicle maker as a type-approval input versus sold on its own — is a product-by-product determination. We scope it per programme.

How we help

A multi-year compliance project, reduced to a documentation merge.

• A certified device — we run the conformity assessment and CE-mark the hardware we build.

• A pre-hardened OS that meets the product-security requirements out of the box.

• A per-release SBOM you fold straight into your technical file.

• Continuous CVE and licence gating — issues caught at merge, not at audit.

• A signed update channel that underwrites the multi-year security-update duty.

• A managed PSIRT and an incident-reporting pipeline for the platform layer.

• A technical-documentation pack for the device, ready for your file.

Built in, not bolted on

Compliance is a runtime property.

CRA obligations are enforced at the OS layer — not via process or audit afterwards.

• Hardened kernel + immutable rootfs

  Read-only OS image. No shipping packages at runtime.

• Secure Boot + hardware-anchored key store

  Signed-image verification at every boot. Keys stored in a TEE (Trusted Execution Environment) on supported hardware.

• Sandboxed container per micro service

  Least-privilege by construction. Container-isolated per micro service.

• Cryptographic update verification

  Signed OTA (Over-the-Air) delivery. Anti-rollback enforced.

• Tamper detection + firmware integrity

  Boot-time integrity check; failed checks block startup.

How the SDK enforces this →

OSS hygiene

Open-source dependencies — scanned, tested, and licence-gated.

Every micro service in the catalog ships with an explicit open-source software (OSS) hygiene posture — not just a version pin.

• We scan OSS for CVE

  CVE advisory scanning runs in CI on every micro service and blocks on critical advisories — no merge until the advisory is resolved or explicitly acknowledged.

• We test OSS dependencies

  Transitive dependency behaviour is exercised through the same platform CI test suites that gate every release. OSS surface is not assumed-safe by version pin alone.

• We prevent contaminating licences

  The allow list is permissive-only — MIT, Apache-2.0, BSD-2/3-Clause, ISC, MPL-2.0, and equivalent. Example: LGPLv3 is blocked because it requires source disclosure of the linked binary, which is incompatible with shipping a proprietary firmware image to the customer's device.

OSS hygiene is one reason compliance teams choose MOS4. The compliance-posture context is at why-mos4 → compliance posture. The full micro service catalog — each entry compliance-flagged — is at /components. Compliance briefs and allow-list rationale are available at /resources/whitepapers.

CRA mapping

The obligations — and what MOS4 provides.

MOS4 covers the product-security obligations the CRA places at the OS layer. The mapping below is capability-level; the exact article references sit in the compliance brief we share under NDA.

PSIRT (Product Security Incident Response Team)

Responsible disclosure — and the CRA reporting clock.

Data lifecycle

Erase personal data on command — and prove it.

A single typed data-reset event fans out across the OS: every micro service holding driver, vehicle, or diagnostic data clears its own state, and the action is recorded. One mechanism, three jobs your programme already has to handle.

The reset is triggered by configuration or a remote command and propagates through the platform's lifecycle hooks — diagnostics, vehicle data, and the persistent store all clear their own state, and the store rotates on a configurable retention policy on top. Every reset is logged like any other state change, so the erasure is provable after the fact.

Standards alignment

Where MOS4 controls map.

FAQ

Frequently asked questions

• Are Munic devices certified for cybersecurity today?

  Yes. Munic devices are CE RED certified — the Radio Equipment Directive's cybersecurity requirements are part of the CE mark, not a separate badge. Conformity is demonstrated against the harmonised standards EN 18031-1:2024 (network protection) and EN 18031-2:2024 (personal-data and privacy protection), mandatory since 1 August 2025. These requirements overlap much of the CRA's essential requirements, so most of the CRA work is already built and in the field. The RED Declaration of Conformity is available on request.

• Do I need a notified-body audit by 2027, or can I self-certify?

  It depends on the device, not the software. Tracking and standard telematics devices self-certify — and Munic performs it — available today. Devices with a regulated security function (network, identity, VPN-class) self-certify only once a harmonised standard is published; until then they use a notified-body route. Security-critical devices always need a lab. Munic carries the route in every case.

• If I put my own brand, containers, or cloud on the device, what becomes my responsibility?

  Munic always certifies the device — hardware, OS, conformity, CE marking, and the security-update commitment. You take on only what you add: the compliance of your own container code, your own cloud if you run it, and your name as the named manufacturer if you brand or rebrand the product, on top of our conformity work.

• What CI gates run on every micro service pipeline?

  Known-vulnerability scan (blocking on critical), licence-policy gate (blocks merge on disallowed licences), unsafe-code analysis, static analysis (SAST), and machine-readable SBOM generation (informational). All 52 micro services inherit these from one shared CI template.

• What ships in the per-release SBOM?

  A machine-readable SBOM covering every open-source dependency in the micro service. SBOM publication is informational; the vulnerability and licence gates are the blocking controls.

• What are the patch response targets?

  Internal targets: Critical 7 days, High 30 days, Medium 90 days, Low next release. These are internal targets — contractual SLAs are agreed per programme.

• How do I report a vulnerability?

  Responsible disclosure via security@munic.io. Acknowledgement within 5 business days.

• Is OTA signing available?

  Yes. Signed package OTA — key chain rooted at Munic. A/B partition scheme keeps the previous known-good image available for automatic rollback.

• What is the status of UNECE R155/R156 alignment?

  MOS4 controls are self-aligned with R155/R156. Formal assessment is conducted per programme — not a blanket certification.

• What does Munic carry vs what does the customer document?

  Munic carries kernel CVE patching, OTA integrity, SBOM publication, Secure Boot, sandboxed runtime, and CI-enforced security gates. Customer documents business-logic threats, data handling policy, app-side test coverage, and domain-specific risk register.

AI Act

EU AI Act posture.

MOS4 AI Language provides structured evidence inputs for the EU AI Act — audit manifest records for §10 data-governance obligations, quantified threat-model gates for §13 transparency, and silicon-agnostic hardware lifecycle decoupling.