Platform
Secure by build. Safe by supervision.
Security and functional safety are not bolt-ons. They are properties of the platform — enforced at build time in CI, at start time by the supervisor, and at run time by the resource contract. The same controls run across every micro service, every release.
Platform properties
What the OS gives you on day one.
Secure
Secure by build.
Six controls cover supply-chain integrity, boot-chain integrity, runtime isolation, and coordinated disclosure. They run on every commit, every release, every micro service — from one shared CI template. Security is not a milestone; it is the default.
Secure Boot
Hardware-anchored root of trust. Signed boot chain on supported silicon. Keys stored in a TEE — never exposed to the application layer.
Signed A/B OTA
A/B partitions with cryptographically signed images. Attest-and-revert removes the field-broken-image failure class. Anti-rollback enforced.
CycloneDX SBOM
Machine-readable software bill of materials generated on every release. Downloadable from the customer portal for procurement evidence packs.
CVE + licence gates
Dependency CVE scan blocks merge on critical advisories. Open-source licence policy enforced as a CI gate, not a convention. Every commit, every micro service.
Sandboxed runtime
Each micro service runs in its own container with enforced cgroup CPU, memory, and IO limits. Least-privilege by construction. crun production runtime over cgroups v2.
PSIRT + responsible disclosure
Product Security Incident Response Team at security@munic.io. Responsible disclosure programme; signed advisories on the customer portal.
Safe
Safe by supervision.
Six controls cover isolation, supervision, determinism, and observability. They keep a misbehaving service from cascading into device failure. Safety properties belong to the platform — not to the application code, not to a separate ASIL or SIL initiative tacked on after the fact.
Supervisor watchdog
Per-service liveness monitoring with automatic restart on missed heartbeats. Restart count and exit code published to OpenTelemetry — anomalies surface in your dashboard before they spread.
Resource contracts at start time
CPU, memory, and IO limits are part of the start-time contract — a misbehaving service cannot starve the rest of the device. mos-container-manager enforces the envelope continuously.
Deterministic startup
Startup order derives from a declared dependency graph in the catalog. The registry refuses a misordered graph at build time. No race-condition class.
Typed interfaces, build-time validation
Every inter-service call rides a typed protobuf contract. buf lint + cargo build catch interface drift at compile time, not after a container restart in the field.
OpenTelemetry observability
Traces, metrics, and structured logs from every service on a unified surface. Fleet-scale anomaly detection. The day-2 layer is in the box, not a separate product.
Hot-swap with rollback
Replace one micro service at a time without rebooting the device. Failed swap auto-reverts. Updates are atomic per service — no half-broken devices in the field.
Where it shows up
Same controls, every page.
Compliance pack
CRA Article-by-Article mapping, SBOM samples, CVE-handling process, security update commitment, vulnerability disclosure policy. Downloadable from the customer portal.
Compliance deep-dive →Operations layer
Observability, safety, OTA, remote control, and lifecycle. Five day-2 capabilities, one platform, every device. OpenTelemetry surface. Signed advisories on the portal.
Operations layer →Architecture
Typed interfaces, registry-enforced startup ordering, hot-swap as framework properties. The dependency graph and resource contracts are platform mechanisms, not application concerns.
Architecture →Why MOS4
The full positioning — secure, safe, field-proven, and CRA-ready — in one page. The decision-maker's view of why MOS4 is the production choice for connected embedded Linux.
Why MOS4 →FAQ
What customers ask.
-
Is MOS4 certified for functional safety (ISO 26262 / IEC 61508)?
Functional-safety certification is performed per programme on the integrated system. MOS4 provides the supervision, isolation, and deterministic-startup properties required by safety analyses, and ships with the documentation (architecture dossier, dependency graph, resource contracts, OpenTelemetry surface) that certifying bodies expect to see. Engagements that target certification are handled by Munic engineering as part of the customer programme.
-
How does MOS4 prevent a misbehaving service from taking down the device?
Three layers: (1) container-level isolation with cgroup CPU/memory/IO limits enforced at start time by mos-container-manager; (2) supervisor watchdog with automatic restart on missed heartbeats; (3) deterministic startup order that prevents a misordered dependency graph from ever booting. The combination removes the "one bad service kills everything" failure mode common in flat-process Linux deployments.
-
What is the threat model?
MOS4 assumes a remote attacker with network access, an attacker with physical access to a powered device, and an insider with developer credentials. Mitigations: Secure Boot chain (physical), signed A/B OTA with anti-rollback (remote), CVE + licence gates (supply chain), TEE-backed key store (insider/extraction), least-privilege container per service (lateral movement). The compliance pack contains the full STRIDE mapping per service domain.
-
How does MOS4 align with the EU Cyber Resilience Act (CRA)?
CRA Article-by-Article mapping is included in the compliance pack. The artefacts the CRA requires — SBOM, CVE handling process, signed updates, vulnerability disclosure programme, security update commitment — are already in the platform, not a separate compliance project. CRA applies from 2027; the artefacts have been in the box since well before.
Bring your security + safety questions.
Procurement teams, compliance officers, and certifying bodies talk to Munic engineering directly — under NDA when needed. Get the full compliance pack, the architecture dossier, and the threat-model mapping.