CRA Compliance for Zephyr RTOS Projects

Zephyr is the RTOS with the richest built-in security ecosystem in the embedded world. MCUboot for secure boot, Mbed TLS for cryptography and TLS, PSA Crypto API support, MPU-based memory isolation, and MCUmgr for device management — these aren't third-party add-ons; they're part of the project.

For CRA compliance, this is both an advantage and a trap. The advantage: many Annex I requirements can be met with features Zephyr already provides. The trap: having the features available doesn't mean they're configured, enabled, or documented in a way that satisfies the regulation. And there are genuine gaps where Zephyr's ecosystem doesn't cover the CRA requirement at all.

This post maps every relevant Annex I requirement to Zephyr features, identifies the gaps, and provides a Zephyr-specific compliance checklist. Using FreeRTOS instead? See our FreeRTOS CRA compliance guide.

Why Zephyr's Security Posture Matters

Zephyr has invested more in built-in security than any other MCU-class RTOS:

• MCUboot integration is first-class — Zephyr's build system generates MCUboot-compatible images natively
• Mbed TLS is the default TLS library, with PSA Crypto API support
• MPU support across Cortex-M, RISC-V, and other architectures provides hardware memory isolation
• MCUmgr provides a device management protocol for firmware updates via BLE, UART, or UDP
• West manifest tracks all project dependencies with exact revisions

But Zephyr is a framework, not a product. The security features need to be configured, tested, and documented for your specific product. CRA compliance is about what your product does, not what the RTOS it's built on is capable of.

Annex I Mapping to Zephyr Features

Part I: Security Requirements

Requirement 1 — Appropriate cybersecurity level (threat model)

Zephyr doesn't provide a threat model for your product — that's your responsibility. However, Zephyr's own security documentation and threat model can serve as a starting point for the RTOS layer of your product's threat model. See our CRA threat modeling guide for the full approach.

• Zephyr provides: Documented security architecture, security-focused development process
• You still need: Product-specific threat model, risk assessment

Requirement 2 — No known exploitable vulnerabilities

Zephyr has an active CVE process and publishes security advisories. But you're responsible for monitoring and patching.

• Zephyr provides: CVE tracking, security advisories, regular releases with fixes
• You still need: CVE monitoring for your specific Zephyr version and configuration, VEX triage for all components in your build, update mechanism to deliver patches

Requirement 3 — Integrity protection (secure boot, signed updates)

This is where Zephyr shines. MCUboot integration is mature and well-documented.

• Zephyr provides: MCUboot as the default bootloader with support for Ed25519, ECDSA P-256, and RSA signing algorithms, image swap and revert, hardware key storage integration for supported platforms
• You still need: Key management infrastructure (HSM/KMS for signing keys), anti-rollback configuration (MCUboot supports it but it needs platform-specific counter support), production key provisioning process

Kconfig options to enable:

# In your prj.conf or board overlay
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="path/to/your/signing-key.pem"

# In MCUboot's prj.conf
CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y  # or ED25519, RSA
CONFIG_BOOT_SWAP_USING_MOVE=y             # Preferred over scratch-based swap
CONFIG_BOOT_UPGRADE_ONLY=n                # Allow revert on failure

See our secure boot guide for the full pipeline.

Requirement 4 — Confidentiality (encryption)

• Zephyr provides: Mbed TLS for TLS/DTLS, PSA Crypto API for key management and cryptographic operations, hardware crypto acceleration on supported MCUs (STM32, nRF, NXP)
• You still need: Secure key storage configuration (depends on your MCU — TrustZone, secure element, or software-emulated), encryption of data at rest in external flash (Zephyr doesn't provide this out of the box)

Requirement 5 — Data minimisation

Not an RTOS concern — this is about your application's data collection practices.

Requirement 6 — Minimise attack surface

• Zephyr provides: Kconfig-based build — only compiled features are included, MPU configuration for memory isolation (CONFIG_USERSPACE=y), stack canaries and overflow detection (CONFIG_STACK_SENTINEL=y or CONFIG_HW_STACK_PROTECTION=y)
• You still need: JTAG/SWD disable in production (board-level Kconfig or OTP configuration), audit of enabled Kconfig options to remove unnecessary features, network stack hardening (disable unused protocols)

Key Kconfig options for hardening:

CONFIG_HW_STACK_PROTECTION=y
CONFIG_STACK_SENTINEL=y
CONFIG_USERSPACE=y           # MPU-based isolation
CONFIG_STACK_CANARIES=y
CONFIG_FORTIFY_SOURCE=y

JTAG/SWD disable: This is platform-specific. For nRF devices, use CONFIG_NRF_APPROTECT_LOCK=y. For STM32, RDP Level 2 is set outside Zephyr (via STM32CubeProgrammer or OTP configuration). Document which mechanism you use.

Requirement 7 — Secure defaults

• Zephyr provides: No default credentials in the RTOS itself
• You still need: Ensure your application doesn't ship with default passwords or hardcoded credentials, first-boot provisioning flow that forces credential setup, disable unnecessary services by default in your application

Requirement 8 — Access control

• Zephyr provides: Userspace/kernel separation via MPU (CONFIG_USERSPACE), system call interface for controlled kernel access
• You still need: Application-level authentication for remote interfaces, role-based access if your product has multiple user levels

Requirement 9 — Availability / resilience

• Zephyr provides: Hardware watchdog support, thread priority management, kernel-level resource management
• You still need: Watchdog configuration in your application, network stack DoS resilience testing, resource limit configuration for connections and buffers

Requirement 10 — Secure communications

• Zephyr provides: Mbed TLS for TLS 1.2/1.3 and DTLS 1.2, CoAP library with DTLS support, Bluetooth encryption (LE Secure Connections)
• You still need: TLS/DTLS configuration with strong cipher suites (disable weak ciphers), server certificate verification (don't set mbedtls_ssl_conf_authmode to MBEDTLS_SSL_VERIFY_NONE), certificate or PSK provisioning for your device fleet

Requirement 11 — Security event logging

• Zephyr provides: Logging subsystem (CONFIG_LOG=y) with multiple backends (UART, RTT, flash)
• You still need: Define which events are security-relevant for your product, configure log persistence (Zephyr logs are volatile by default), tamper protection for stored logs

Requirement 12 — Secure data deletion

• Zephyr provides: Flash erase APIs
• You still need: Factory reset implementation that securely erases user data, keys, and configuration, verification that erase actually clears data (not just marks sectors as available)

Requirement 13 — User notification

Not an RTOS feature — depends on your product's user interface (companion app, web dashboard, LED indicators).

Part II: Vulnerability Handling

VH1 — SBOM

Zephyr has a built-in SBOM generation command: west spdx. Run it after any build, and it produces SPDX 2.3 documents covering the source files and libraries that were actually compiled. This is more than most RTOSes offer.

However, the raw west spdx output isn't CRA-compliant on its own. It lacks CPE/PURL identifiers (so vulnerability scanners can't match components to CVEs), rolls subsystem components like Bluetooth and MQTT into the kernel package instead of listing them individually, and can't see inside vendor HAL binary blobs.

Making the output useful requires an enrichment workflow:

1. Run west spdx to generate the base SPDX documents from your build
2. Add CPE/PURL identifiers to every package so scanners can match against NVD and OSV
3. Add invisible components (Bluetooth stack, MQTT, cJSON) that are compiled in but not listed as discrete packages
4. Document binary blobs from vendor HALs with available version info and NOASSERTION for opaque contents
5. Merge the four SPDX files into a single document for submission and scanning

See our step-by-step Zephyr SBOM tutorial for the full enrichment workflow, including scripting CPE/PURL additions, CI/CD integration, and CycloneDX conversion. For broader SBOM context, see our SBOM guide.

VH2 — Security update delivery

• Zephyr provides: MCUmgr for BLE/UART/UDP device management including firmware upload, MCUboot for A/B updates with revert
• You still need: Update server infrastructure, fleet management, staged rollout capability

MCUmgr provides the on-device update mechanism, but fleet-scale OTA requires additional infrastructure. See our OTA updates guide.

VH3–VH8 — Vulnerability handling processes

These are organisational requirements, not RTOS features. You need a PSIRT, CVD policy, ENISA registration, and patch management process regardless of your RTOS choice. See our Article 14 guide.

Gaps in Zephyr's CRA Readiness

1. No Built-In Fleet Management

MCUmgr handles the on-device side of firmware updates, but there's no Zephyr-provided server component for managing updates across a fleet of devices. You need to build or adopt:

• Update server (hawkBit, custom, or cloud IoT platform)
• Device registration and inventory
• Update targeting and staged rollout
• Update status tracking

2. Anti-Rollback Requires Platform Support

MCUboot supports anti-rollback via a monotonic counter, but the actual counter implementation depends on the hardware platform. Not all Zephyr-supported boards have this configured. You need to verify that your specific MCU and board configuration supports hardware-backed monotonic counters, or implement a flash-based counter with integrity protection.

3. Secure Storage Varies by Platform

Zephyr's trusted storage story depends heavily on the MCU:

For MCUs without TrustZone or a secure element, you may need an external secure element (ATECC608, SE050) for CRA-compliant key storage.

4. SBOM Tooling Requires Enrichment

Zephyr's west spdx command generates SPDX documents, but the raw output lacks the CPE/PURL identifiers and component granularity needed for CRA-compliant vulnerability scanning. The tooling exists but requires a post-processing workflow to be useful. See our Zephyr SBOM tutorial for the full enrichment process.

5. Debug Interface Lockdown Is Board-Specific

Disabling JTAG/SWD must be done per-board and per-MCU. Zephyr's Kconfig doesn't provide a universal "disable debug interface" option. You need to:

• Identify your MCU's debug disable mechanism (OTP fuse, register lock, AP disable)
• Implement it in your board configuration or manufacturing provisioning
• Document it in your technical documentation

Zephyr-Specific Compliance Checklist

Secure boot (MCUboot)

• MCUboot enabled (CONFIG_BOOTLOADER_MCUBOOT=y)
• Signing key generated and stored in HSM/KMS
• Production images signed with production key (not the default development key)
• Swap-based update with revert on failure
• Anti-rollback counter configured for your platform

Cryptography and TLS

• Mbed TLS configured with strong cipher suites only
• TLS 1.2+ or DTLS 1.2+ for all network communications
• Server certificate verification enabled
• PSA Crypto API used for key management where supported
• Hardware crypto acceleration enabled (CONFIG_MBEDTLS_PSA_CRYPTO_C=y)

Memory protection

• MPU enabled (CONFIG_USERSPACE=y) for applications with multiple privilege levels
• Stack protection enabled (CONFIG_HW_STACK_PROTECTION=y)
• Stack canaries or sentinels enabled

Attack surface reduction

• JTAG/SWD disabled in production builds
• Unused Kconfig features disabled
• Debug logging disabled or secured in production
• Unused network protocols and services disabled

OTA updates

• MCUmgr configured for firmware upload (BLE, UART, or UDP)
• Update server infrastructure operational
• Rollback tested and documented
• Update signing key matches boot signing trust chain

SBOM

• west.yml manifest parsed for all dependencies
• CMake build output analysed for actual compiled components
• SPDX or CycloneDX document generated per release
• Binary blobs and external components documented

Vulnerability management

• Zephyr security advisory feed monitored
• CVE monitoring for Mbed TLS, MCUboot, and all Zephyr modules
• Patch/update process covers Zephyr upstream updates
• Zephyr version pinned in west.yml (not tracking main in production)

Recommended Implementation Roadmap

Phase 1 (Month 1–2): Foundation

1. Enable MCUboot with proper signing (not development keys)
2. Enable MPU and stack protection
3. Disable JTAG/SWD in production board config
4. Generate initial SBOM from west manifest

Phase 2 (Month 2–3): Communications and Updates

1. Configure Mbed TLS with CRA-appropriate cipher suites
2. Set up MCUmgr for OTA updates
3. Implement update server infrastructure
4. Test and document rollback behaviour

Phase 3 (Month 3–4): Vulnerability Handling

1. Set up CVE monitoring for all Zephyr components
2. Establish PSIRT process and CVD policy
3. Register on ENISA reporting platform
4. Build VEX triage workflow

Phase 4 (Month 4–5): Documentation and Testing

1. Conduct product threat model
2. Run security testing against Annex I requirements
3. Prepare Annex VII technical documentation
4. Prepare EU Declaration of Conformity

The Stack Canary assessment tool will identify your specific gaps and help prioritise your remediation roadmap based on your Zephyr project's current configuration.

Based on Regulation EU 2024/2847 Annex I, Zephyr Project documentation (v3.7+), MCUboot documentation, Mbed TLS documentation, and PSA Certified specifications. This does not constitute legal advice.

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)
• Zephyr Project — Security documentation
• Zephyr Project — west spdx command
• MCUboot — Design documentation
• Mbed TLS — Documentation
• PSA Certified — Specifications
• Nordic Semiconductor — nRF Connect SDK security