Plataforma · Cumplimiento del CRA
Munic certifica el dispositivo. Usted solo posee lo que añade.
El Reglamento de Ciberresiliencia de la UE (CRA) será obligatorio el 11 de diciembre de 2027. Munic fabrica el hardware y el sistema operativo, y lleva el dispositivo a través de la conformidad — evaluación, archivo técnico, marcado CE, gestión de vulnerabilidades y el compromiso de actualizaciones de seguridad. Sea lo que sea que ejecute encima, la caja llega certificada. Usted solo documenta la capa que añade.
Ya en producción
No empezamos el CRA en 2027 — buena parte se entrega hoy.
Los dispositivos Munic están certificados CE RED — los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos (RED) forman parte integral del marcado CE, no son un sello distinto. Obligatorios desde el 1 de agosto de 2025, Munic los cumple conforme a las normas armonizadas EN 18031-1:2024 (protección de red) y EN 18031-2:2024 (protección de datos personales y de la privacidad), y los envía en producto desde entonces. Cubren buena parte de los requisitos esenciales del CRA, de modo que la brecha hacia la conformidad CRA completa es incremental, no una reconstrucción.
Certificado CE RED
Los dispositivos actuales llevan marcado CE conforme a la Directiva de Equipos Radioeléctricos (RED), demostrado según EN 18031-1:2024 (protección de red) y EN 18031-2:2024 (protección de datos personales y de la privacidad) — obligatorios desde agosto de 2025. La Declaración de conformidad RED está disponible a solicitud.
El ciber de RED se solapa con el CRA
Los controles ciber de RED se asignan directamente a los requisitos de seguridad de producto del CRA — de modo que buena parte del CRA ya está construida, probada y en el campo.
Por delante de la fecha límite
La distancia hasta la conformidad CRA completa es incremental, no una reconstrucción — y Munic la asume, mucho antes del 11 de diciembre de 2027.
La fecha límite de 2027
Cuándo puede autocertificarse — y cuándo se exige un laboratorio.
El CRA clasifica el dispositivo, no el sistema operativo. La mayoría de los dispositivos se autocertifican, y Munic lo realiza. Una auditoría y un laboratorio solo se exigen cuando el dispositivo lleva una función de seguridad regulada.
Rastreo puro
Sin laboratorio — autocertificación
Un producto por defecto. Solo ubicación y conectividad celular — sin función de seguridad regulada.
- Celular / GNSS — Sin laboratorio
- Sin cámara — Sin impacto
- Software estándar — Totalmente nuestro
Telemática + visión
Sin laboratorio — autocertificación
Las cámaras y el WiFi/BLE no añaden una función de seguridad del CRA. La privacidad se gestiona mediante anonimización en el dispositivo; la radio ya está cubierta por nuestra certificación CE RED (EN 18031-1/-2).
- Visión — Sin laboratorio — anonimizada en el dispositivo
- WiFi / BLE — Sin laboratorio — radio CE RED
- Sus contenedores — Su capa — sin laboratorio de dispositivo
Robótica / autónoma
Laboratorio — evaluado por programa
Las funciones críticas para la seguridad o de elemento seguro pueden requerir un organismo notificado, y el dispositivo forma parte de una pila más amplia. Munic asume la evaluación y el laboratorio.
- Funciones críticas para la seguridad — Puede requerir laboratorio
- Elemento seguro — Laboratorio requerido
- Pila más amplia — Reglamento de Máquinas + Reglamento IA
11 de septiembre de 2026
Comienzan las obligaciones de notificación — vulnerabilidades explotadas activamente e incidentes graves. Munic opera el pipeline de notificación de la plataforma.
11 de diciembre de 2027
Se aplican todas las obligaciones — evaluación de conformidad, marcado CE, archivo técnico, periodo de soporte. La fecha límite a la que todos se refieren con "CRA 2027".
Los estándares armonizados que desbloquean la autoevaluación para los dispositivos con función regulada aún no se han publicado. Hasta que lo hagan, esa categoría usa una vía de organismo notificado — y Munic la asume en cualquier caso, pasando a la autoevaluación en el momento en que el estándar llegue. Los dispositivos de rastreo y de telemática estándar se autocertifican hoy en todo caso.
Posventa o montaje de fábrica
El mismo dispositivo — el régimen que lo rige puede cambiar con el anfitrión.
Munic entrega ambas modalidades: como productos de posventa independientes y como unidades de montaje de fábrica. Lo que rige el dispositivo depende de dónde acabe: por sí solo, o dentro de un anfitrión regulado.
Posventa / retrofit
Aplica el CRA
Vendido como producto independiente, el dispositivo es por sí mismo un producto con elementos digitales. El CRA aplica — y Munic lo certifica.
Montaje de fábrica — vehículo de carretera
Régimen de automoción
Integrado en un vehículo con homologación de tipo, la unidad queda bajo la homologación de tipo del vehículo y su gestión de ciberseguridad de automoción (UNECE R155/R156) — el CRA cede el paso. Munic aporta la evidencia de ciberseguridad que el fabricante del vehículo incorpora a su sistema de gestión.
Montaje de fábrica — fuera de carretera / maquinaria
CRA + Máquinas
Aquí no hay exclusión por homologación de tipo de vehículo: el CRA sigue rigiendo la ciberseguridad, junto al Reglamento de Máquinas para la seguridad. Munic asume la capa ciber.
La línea exacta — especialmente para una unidad entregada a un fabricante de vehículos como insumo de homologación de tipo frente a una vendida por sí sola — es una determinación producto por producto. La acotamos por programa.
Quién hace qué
Munic certifica el dispositivo. Tres cosas deciden el resto.
El hardware, el sistema operativo y la conformidad del dispositivo son siempre nuestros. Lo que usted asume depende de tres decisiones — y en la mayoría de las configuraciones la respuesta es nada.
Software en la caja
- Estándar Munic Nada — totalmente nuestro.
- Munic + su configuración Nada — la configuración no es una modificación.
- Munic + sus contenedores El código de sus contenedores — su capa de aplicación.
Nube
- Nube Munic Nada — cubierto en la postura del dispositivo.
- Munic + su nube Sus servicios en la nube.
- Su nube (no estamos conectados) Su procesamiento remoto de datos.
Marca
- Marca Munic Nada.
- Su marca Su nombre como fabricante designado — sobre nuestro trabajo de conformidad.
- Recambio de marca del cliente final La relación de cambio de marca — estructurada para que nuestra conformidad siga respaldando el producto.
Lo único que recae alguna vez en usted es la capa que construye — sus contenedores, su nube, el nombre de su marca sobre nuestro trabajo de conformidad. Todo lo que hay debajo está certificado y documentado por Munic.
Cómo le ayudamos
Un proyecto de cumplimiento plurianual, reducido a una fusión de documentación.
-
Un dispositivo certificado — ejecutamos la evaluación de conformidad y marcamos CE el hardware que fabricamos.
-
Un SO pre-reforzado que cumple los requisitos de seguridad del producto de fábrica.
-
Un SBOM por versión que integra directamente en su archivo técnico.
-
Control continuo de CVE y licencias — los problemas se detectan en la fusión, no en la auditoría.
-
Un canal de actualización firmado que respalda el deber plurianual de actualizaciones de seguridad.
-
Un PSIRT gestionado y un pipeline de notificación de incidentes para la capa de plataforma.
-
Un paquete de documentación técnica del dispositivo, listo para su archivo.
Integrado, no añadido después
El cumplimiento es una propiedad de tiempo de ejecución.
Las obligaciones del CRA se aplican en la capa del SO — no mediante procesos o auditorías posteriores.
-
Kernel reforzado + rootfs inmutable
Imagen del SO en solo lectura. Sin instalación de paquetes en tiempo de ejecución.
-
Secure Boot + almacén de claves anclado en hardware
Verificación de imagen firmada en cada arranque. Claves almacenadas en un TEE (Trusted Execution Environment) en hardware compatible.
-
Contenedor en sandbox por micro service
Mínimo privilegio por construcción. Aislamiento en contenedor por micro service.
-
Verificación criptográfica de actualizaciones
Entrega OTA (Over-the-Air) firmada. Anti-rollback aplicado.
-
Detección de manipulación + integridad del firmware
Verificación de integridad en el arranque; los controles fallidos bloquean el inicio.
Controles de seguridad en CI
Una plantilla compartida. 52 micro services.
Todos los micro services heredan el escaneo de avisos de CVE, el control de licencias, el análisis de código inseguro, la generación del SBOM y el SAST (Static Application Security Testing) de una única plantilla de CI compartida y versionada. Una corrección de seguridad llega a todos los consumidores en un único bump de versión — sin mantenimiento de pipeline por micro service.
| Control | Alcance | Condición de fallo |
|---|---|---|
| Lista de materiales (SBOM) | Legible por máquina, cada dependencia, por versión | Informativo — no es un control bloqueante |
| Escaneo de vulnerabilidades conocidas | Base de datos de avisos, cada dependencia | Un aviso crítico bloquea la compilación |
| Control de política de licencias | Cada dependencia de código abierto | Una licencia no permitida bloquea la fusión |
| Análisis de código inseguro | Superficie de seguridad de memoria | Una violación de política bloquea la compilación |
| Análisis estático (SAST) | Antipatrones de seguridad en el código fuente | Un hallazgo de alta severidad bloquea la compilación |
Los controles de vulnerabilidades y licencias bloquean en caso de violación. La publicación del SBOM es actualmente informativa — el control está en su lugar; el nivel de aplicación está bajo revisión.
Higiene OSS
Dependencias de código abierto — escaneadas, probadas y con control de licencias.
Cada micro service del catálogo se entrega con una postura explícita de higiene de software de código abierto (OSS) — no solo un pin de versión.
-
Escaneamos OSS para CVE
El escaneo de avisos de CVE se ejecuta en CI en cada micro service y bloquea en avisos críticos — sin fusión hasta que el aviso se resuelve o se reconoce explícitamente.
-
Probamos las dependencias OSS
El comportamiento de las dependencias transitivas se ejercita a través de las mismas suites de pruebas de CI de plataforma que controlan cada versión. La superficie OSS no se asume segura por pin de versión únicamente.
-
Prevenimos licencias contaminantes
La lista de permitidos es solo de licencias permisivas — MIT, Apache-2.0, BSD-2/3-Clause, ISC, MPL-2.0 y equivalentes. Ejemplo: LGPLv3 está bloqueada porque requiere la divulgación del código fuente del binario enlazado, lo que es incompatible con enviar una imagen de firmware propietaria al dispositivo del cliente.
La higiene OSS es una razón por la que los equipos de cumplimiento eligen MOS4. El contexto de postura de cumplimiento está en por qué MOS4 → postura de cumplimiento. El catálogo completo de micro services — cada entrada marcada con su estado de cumplimiento — está en /es/components. Los informes de cumplimiento y la justificación de la lista de permitidos están disponibles en /es/resources/whitepapers.
Mapeo del CRA
Las obligaciones — y lo que MOS4 proporciona.
MOS4 cubre las obligaciones de seguridad de producto que el CRA sitúa en la capa del SO. El mapeo siguiente es a nivel de capacidad; las referencias exactas de artículo se encuentran en el informe de cumplimiento que compartimos bajo NDA.
| Obligación del CRA | Lo que MOS4 proporciona |
|---|---|
| Seguridad por defecto | Contenedor en sandbox por micro service. Mínimo privilegio por construcción. |
| Minimización de datos | Anonimización en vivo en el plano de frames. Retención configurable. |
| Protección de integridad | Secure Boot + detección de manipulación + OTA verificado criptográficamente. |
| Gestión de vulnerabilidades | PSIRT en security@munic.io, divulgación coordinada, objetivos internos de parche, CVE rastreados por versión. |
| Documentación técnica | Por versión: SBOM, evaluación de riesgos, descripción de arquitectura, registro de cambios, evidencia de pruebas de seguridad. |
| Obligaciones de notificación | Flujo de notificación de incidentes. Listo para EU CSIRT. Plantilla de notificación al cliente disponible. |
Objetivos de parche
Objetivos internos — SLA contractuales por programa.
| Severidad | Objetivo | Base del SLA |
|---|---|---|
| Crítico | Objetivo interno — 7 días | SLA contractual por programa |
| Alto | Objetivo interno — 30 días | SLA contractual por programa |
| Medio | Objetivo interno — 90 días | SLA contractual por programa |
| Bajo | Próxima versión | SLA contractual por programa |
El CRA exige la remediación "sin demora indebida" y un periodo de soporte de actualizaciones de seguridad de al menos cinco años — no fija un plazo numérico de parche. Los objetivos anteriores son los objetivos internos propios de Munic, más estrictos que la redacción del reglamento; los SLA contractuales se acuerdan por programa y no son compromisos implícitos de esta página.
PSIRT (Product Security Incident Response Team)
Divulgación responsable — y el reloj de notificación del CRA.
Repórtenos una vulnerabilidad
security@munic.io
Divulgación coordinada. Acusamos recibo de un reporte entrante en 5 días hábiles — luego corre el reloj regulatorio de la derecha.
Lo que el CRA exige — y Munic opera
- · Alerta temprana a las autoridades en un plazo de 24 horas desde una vulnerabilidad explotada activamente.
- · Notificación completa en un plazo de 72 horas.
- · Informe final en un plazo de 14 días desde que hay una corrección disponible.
- · Usuarios afectados informados sin demora indebida.
División de responsabilidades
Lo que gestionamos. Lo que usted documenta.
Capa del SO — Munic gestiona
- · Parcheo de CVE del kernel y correcciones de seguridad de la capa del SO.
- · Integridad del pipeline OTA — entrega de paquetes firmados.
- · Generación y publicación del SBOM por versión.
- · Secure Boot + almacén de claves anclado en hardware (TEE) en hardware compatible.
- · Runtime de micro services en sandbox con aislamiento por contenedor aplicado.
- · Controles de CVE y licencias aplicados en CI en 52 micro services.
- · Cortafuegos de egreso — disponible en el hardware compatible.
Capa de aplicación — El cliente documenta
- · Modelo de amenazas de la lógica de negocio.
- · Política de manejo y retención de datos del cliente.
- · Cobertura de pruebas y evidencia del lado de la aplicación.
- · Registro de riesgos específico del dominio.
- · Superficie de divulgación de la capa de aplicación.
Las capacidades del día 2 — observabilidad, seguridad, OTA, control remoto, ciclo de vida — se presentan juntas en /es/platform/operations. Las políticas de seguridad impulsadas por configuración en lugar de a nivel de código se cubren en /es/platform/no-code.
Ciclo de vida de los datos
Borre datos personales bajo demanda — y demuéstrelo.
Un único evento tipado de restablecimiento de datos se propaga por todo el SO: cada micro service que almacena datos de conductor, vehículo o diagnóstico borra su propio estado, y la acción queda registrada. Un mecanismo, tres trabajos que su programa ya tiene que gestionar.
Cambio de vehículo / traspaso de conductor
Cuando un vehículo cambia de manos, borre los viajes, ubicaciones e historial de diagnóstico del conductor anterior antes del primer encendido del siguiente — sin visita de campo, sin purga manual.
RMA y reacondicionamiento
Antes de que un dispositivo abandone el campo para su devolución o reacondicionamiento, borre los datos del cliente bajo demanda para que nada personal viaje con el hardware.
Derecho de supresión del RGPD
Atienda una solicitud de eliminación de datos del interesado desde la nube — el dispositivo borra el estado correspondiente y devuelve un registro de auditoría que puede entregar al solicitante.
El restablecimiento se activa mediante configuración o un comando remoto y se propaga a través de los hooks de ciclo de vida de la plataforma — diagnósticos, datos del vehículo y el almacén persistente borran su propio estado, y el almacén rota según una política de retención configurable además. Cada restablecimiento se registra como cualquier otro cambio de estado, de modo que el borrado es demostrable a posteriori.
Alineación con estándares
Dónde se asignan los controles de MOS4.
Directiva de Equipos Radioeléctricos (RED)
Los dispositivos están certificados CE RED — los requisitos de ciberseguridad de la directiva forman parte integral del marcado CE. Demostrado según EN 18031-1:2024 (protección de red) y EN 18031-2:2024 (protección de datos personales y de la privacidad), obligatorios desde el 1 de agosto de 2025. Declaración de conformidad disponible a solicitud.
UNECE R155 / R156
Alineado con los controles R155/R156 — evaluación formal por programa.
FMCSA ELD
ELD certificado por FMCSA mediante el micro service hours-of-service .
Aplicación HOS disponible en junio de 2026 — ekkofleet.com.
GDPR
Anonimización en vivo en el plano de frames (difuminado de caras y matrículas por política en tiempo de arranque). Controles de retención configurables.
CRA (EU 2024/2847)
Munic lleva el dispositivo a través de la conformidad y el marcado CE; usted solo documenta la capa que añade.
Robótica y autonomía
Para máquinas móviles y autónomas, el CRA es la base ciber dentro de una pila más amplia — la Directiva de Equipos Radioeléctricos, el Reglamento de Máquinas y el Reglamento de IA de la UE. Munic asume la capa ciber y se alinea con el resto.
FAQ
Preguntas frecuentes
-
¿Están los dispositivos Munic certificados en ciberseguridad hoy?
Sí. Los dispositivos Munic están certificados CE RED — los requisitos de ciberseguridad de la Directiva de Equipos Radioeléctricos (RED) forman parte integral del marcado CE, no son un sello distinto. La conformidad se demuestra según las normas armonizadas EN 18031-1:2024 (protección de red) y EN 18031-2:2024 (protección de datos personales y de la privacidad), obligatorias desde el 1 de agosto de 2025. Estos requisitos cubren buena parte de los requisitos esenciales del CRA, por lo que gran parte del trabajo del CRA ya está construido y en el campo. La Declaración de conformidad RED está disponible a solicitud.
-
¿Necesito una auditoría de organismo notificado para 2027, o puedo autocertificarme?
Depende del dispositivo, no del software. Los dispositivos de rastreo y de telemática estándar se autocertifican — y Munic lo realiza — disponible hoy. Los dispositivos con una función de seguridad regulada (red, identidad, clase VPN) se autocertifican solo una vez publicado un estándar armonizado; hasta entonces usan una vía de organismo notificado. Los dispositivos críticos para la seguridad siempre necesitan un laboratorio. Munic asume la vía en todos los casos.
-
Si pongo mi propia marca, contenedores o nube en el dispositivo, ¿qué pasa a ser mi responsabilidad?
Munic siempre certifica el dispositivo — hardware, SO, conformidad, marcado CE y el compromiso de actualizaciones de seguridad. Usted solo asume lo que añade: el cumplimiento del código de sus propios contenedores, su propia nube si la opera, y su nombre como fabricante designado si pone marca o cambia la marca del producto, sobre nuestro trabajo de conformidad.
-
¿Qué controles de CI se ejecutan en cada pipeline de micro service?
Escaneo de vulnerabilidades conocidas (bloqueante en críticos), control de política de licencias (bloquea la fusión en licencias no permitidas), análisis de código inseguro, análisis estático (SAST) y generación de SBOM legible por máquina (informativo). Los 52 micro services heredan esto de una única plantilla de CI compartida.
-
¿Qué incluye el SBOM por versión?
Un SBOM legible por máquina que cubre todas las dependencias de código abierto del micro service. La publicación del SBOM es informativa; los controles bloqueantes son los de vulnerabilidades y licencias.
-
¿Cuáles son los objetivos de respuesta a parches?
Objetivos internos: Crítico 7 días, Alto 30 días, Medio 90 días, Bajo en la próxima versión. Estos son objetivos internos — los SLA contractuales se acuerdan por programa.
-
¿Cómo reporto una vulnerabilidad?
Divulgación responsable mediante security@munic.io. Acuse de recibo en 5 días hábiles.
-
¿Está disponible la firma OTA?
Sí. OTA de paquetes firmados — cadena de claves con raíz en Munic. El esquema de partición A/B mantiene disponible la imagen buena anterior para rollback automático.
-
¿Cuál es el estado de la alineación con UNECE R155/R156?
Los controles de MOS4 están auto-alineados con R155/R156. La evaluación formal se realiza por programa — no es una certificación general.
-
¿Qué gestiona Munic frente a lo que documenta el cliente?
Munic gestiona el parcheo de CVE del kernel, la integridad OTA, la publicación del SBOM, Secure Boot, el runtime en sandbox y los controles de seguridad aplicados en CI. El cliente documenta las amenazas de la lógica de negocio, la política de manejo de datos, la cobertura de pruebas del lado de la aplicación y el registro de riesgos específico del dominio.
Reglamento IA
Posicionamiento ante el Reglamento de IA de la UE.
MOS4 AI Language proporciona entradas de evidencia estructuradas para el Reglamento de IA de la UE — registros del manifiesto de auditoría para las obligaciones de gobernanza de datos del §10, controles cuantificados de modelo de amenazas para la transparencia del §13 y desacoplo del ciclo de vida del hardware independiente del silicio.
Manifiesto de auditoría como evidencia §10/§13
Cada respuesta de la plataforma AI Language publica un registro completo de procedencia: IDs de fragmento, rutas de documento, versión del modelo, puntuaciones de similitud y motivo del rechazo. Retención rotativa de seis meses. Este registro está estructurado como entrada de evidencia para las obligaciones de gobernanza de datos (§10) y transparencia (§13) del Reglamento de IA de la UE.
Modelo de amenazas T1–T5 con controles cuantificados
La plataforma AI Language incluye cinco categorías de amenaza, cada una con un control de criterio de aceptación: umbrales de confianza de RAG (Retrieval-Augmented Generation) (T1), tasa de deflexión de inyección de prompts ≥ 95 % en red team de 20 prompts (T2), suelo de ruido STT (Speech-to-Text) WER (Word Error Rate) ≤ 15 % a 70–75 dB (T3), completitud del registro de auditoría (T4) y prevención de escalada de herramientas MCP (Model Context Protocol) (T5). Todos los controles son comprobables y verificables por máquina.
Ciclo de vida del hardware y transparencia
La plataforma AI Language es independiente del silicio por encima del umbral de 1 GB de RAM. Los ciclos de vida de software y hardware están desacoplados: un cambio de generación de silicio no requiere un cambio de modelo ni un cambio de código de aplicación. El SBOM cubre la pila de IA completa, incluida la procedencia del modelo. Vea la página de hardware para el detalle por nivel de silicio.
Traiga su cuestionario de seguridad.
Ingeniería lo completará a partir de la evidencia de cumplimiento existente — no se necesita un compromiso de auditoría específico para la capa del SO.