CRA Compliance for FreeRTOS Firmware Projects

FreeRTOS is the most widely deployed RTOS in the world. It runs on everything from temperature sensors to industrial controllers to consumer electronics. And its CRA compliance story is more complicated than any other RTOS — because "FreeRTOS" means different things depending on which variant and ecosystem you're using.

The vanilla FreeRTOS kernel gives you a task scheduler, memory management, and inter-task communication. That's it. No networking, no cryptography, no OTA updates, no secure boot. Everything else comes from libraries you choose to add — either AWS's FreeRTOS libraries, your MCU vendor's SDK, or open-source components you integrate yourself.

This means your CRA compliance posture depends almost entirely on what you've built on top of the kernel. This post maps the Annex I requirements to the various FreeRTOS variants and identifies what you need to build or adopt for each. Using Zephyr instead? See our Zephyr CRA compliance guide.

AWS FreeRTOS vs. Vanilla FreeRTOS Kernel

This distinction matters enormously for CRA compliance:

Vanilla FreeRTOS Kernel

The FreeRTOS kernel (MIT licensed) provides:

• Pre-emptive and cooperative task scheduling
• Binary and counting semaphores, mutexes, queues
• Software timers
• Memory management (heap_1 through heap_5)
• MPU wrapper for Cortex-M (optional)

What the kernel does not provide:

• Networking (no TCP/IP, no TLS, no MQTT, no HTTP)
• Cryptography (no AES, no RSA, no ECDSA, no hashing)
• Secure boot (not a bootloader)
• OTA updates (no update mechanism)
• File system or persistent storage
• SBOM generation tooling
• Device management

For CRA compliance, the vanilla kernel alone covers almost none of the Annex I requirements. It's a scheduler. Everything security-relevant must come from additional components.

AWS FreeRTOS (FreeRTOS Long Term Support)

AWS provides a set of libraries designed to work with the FreeRTOS kernel and AWS IoT services:

• coreMQTT / coreMQTT-Agent: MQTT client with TLS support
• coreHTTP: HTTP client
• Mbed TLS (bundled): TLS and cryptographic operations
• corePKCS11: Cryptographic key management interface
• FreeRTOS OTA library: Over-the-air update client (works with AWS IoT Jobs)
• FreeRTOS+TCP or lwIP: TCP/IP networking stacks
• AWS IoT Device Shadow, Device Defender: Cloud device management

AWS FreeRTOS significantly improves the CRA compliance posture — but it ties you to the AWS IoT ecosystem, and many of the libraries only work well with AWS services.

The Vendor SDK Layer

Most real-world FreeRTOS projects don't use the vanilla kernel or pure AWS FreeRTOS. They use an MCU vendor SDK that bundles FreeRTOS with vendor-specific drivers, networking, and middleware:

• STM32Cube + FreeRTOS: STM32 HAL, FreeRTOS kernel, optionally lwIP, mbedTLS, SBSFU bootloader
• ESP-IDF (FreeRTOS-based): ESP-IDF uses a modified FreeRTOS kernel with ESP32-specific additions (SMP support, IPC), plus networking, TLS, OTA, and secure boot
• NXP MCUXpresso SDK + FreeRTOS: NXP drivers, FreeRTOS kernel, lwIP, mbedTLS, optional AWS libraries
• TI SimpleLink SDK + FreeRTOS: TI drivers, FreeRTOS kernel, TI networking stack, TLS

Each vendor SDK has a different security posture. The FreeRTOS kernel is the same across all of them, but the security-relevant components (TLS, bootloader, OTA, key storage) vary significantly.

For CRA compliance: your SBOM, vulnerability tracking, and security assessment must cover the vendor SDK as a whole, not just the FreeRTOS kernel.

Annex I Mapping to FreeRTOS Variants

Part I: Security Requirements

Requirement 1 — Appropriate cybersecurity level (threat model)

None of the FreeRTOS variants provide a product threat model. This is your responsibility. See our CRA threat modeling guide.

Requirement 2 — No known exploitable vulnerabilities

• You still need: Monitoring for all three layers (kernel + libraries + vendor SDK), VEX triage process, and a way to patch across all three layers. The vendor SDK layer is typically the hardest to patch quickly.

Requirement 3 — Integrity protection (secure boot)

FreeRTOS does not include a bootloader. Secure boot is entirely dependent on your MCU platform:

See our secure boot guide for implementation details per platform.

Requirement 4 — Confidentiality (encryption)

• You still need: Secure key storage (depends on MCU — TrustZone, secure element, or PUF), encryption of data at rest (no FreeRTOS variant provides this out of the box)

Requirement 6 — Minimise attack surface

• FreeRTOS kernel provides: MPU wrapper (CONFIG_USE_MPU_WRAPPERS) for Cortex-M memory isolation
• You still need: MPU configuration for your application's task isolation, JTAG/SWD disable (MCU-specific, not RTOS), disabled unused services and protocols, compiler hardening flags

The FreeRTOS MPU wrapper is less mature than Zephyr's userspace isolation. It provides basic task memory isolation but requires careful manual configuration of MPU regions per task.

Requirement 7 — Secure defaults

Not an RTOS concern — this is about your application's default configuration.

Requirement 8 — Access control

• FreeRTOS kernel provides: MPU wrapper for kernel/user task separation
• You still need: Application-level authentication, network service access control

Requirement 9 — Availability / resilience

• FreeRTOS kernel provides: Task watchdog (via software timer), stack overflow detection (configCHECK_FOR_STACK_OVERFLOW)
• You still need: Hardware watchdog configuration, network DoS resilience testing, resource limits for connections and buffers

Requirement 10 — Secure communications

• You still need: Strong cipher suite configuration, server certificate verification, certificate provisioning for your device fleet

Requirement 11 — Security event logging

FreeRTOS doesn't include a logging framework. You need to implement or adopt one. Options:

• AWS IoT Device Defender provides security metrics reporting (AWS ecosystem only)
• Custom logging to flash, UART, or syslog
• ESP-IDF has a built-in logging framework (esp_log)

Requirements 5, 12, 13 — Data minimisation, secure deletion, user notification: These are application-level requirements, not RTOS features.

Part II: Vulnerability Handling

VH1 — SBOM

This is where FreeRTOS projects have the most complexity:

Kernel SBOM: Simple — one component (FreeRTOS-Kernel) with a clear version number and MIT license.

Full project SBOM: Complex — you need to enumerate:

1. FreeRTOS kernel version
2. All AWS FreeRTOS libraries (if used) with versions
3. Vendor SDK version and all components within it
4. Third-party libraries (lwIP, mbedTLS, fatfs, etc.)
5. Binary blobs from the MCU vendor

There's no native SBOM tooling in the FreeRTOS ecosystem. See our SBOM guide for approaches.

VH2 — Security update delivery (OTA)

The AWS FreeRTOS OTA library is the most complete option, but it requires AWS IoT Core as the backend. For non-AWS deployments, you'll need to build or adopt an OTA solution. See our OTA updates guide.

VH3–VH8 — Vulnerability handling processes

Organisational requirements — same as any RTOS. See our Article 14 guide and Annex I checklist.

The Vendor SDK Dependency Problem

For most FreeRTOS projects, the biggest CRA compliance challenge isn't the RTOS — it's the vendor SDK layer.

Why this matters:

1. Patch latency: When a CVE is published for mbedTLS, the fix flows: mbedTLS upstream → vendor SDK team → vendor SDK release → your product update. This can take weeks to months for vendor SDKs with infrequent releases.
2. Version opacity: Vendor SDKs often bundle modified versions of open-source libraries. The mbedTLS version in STM32Cube may not match any public release — it's a vendor-patched fork. This complicates vulnerability matching.
3. SBOM difficulty: The vendor SDK is a monolithic package. Extracting individual component versions requires digging through release notes or header files, not a standard manifest.
4. Update coupling: Security updates to one component (e.g., mbedTLS) may require updating the entire vendor SDK, which may include breaking changes to HAL drivers or other components.

Mitigation strategies:

• Pin and track: Record the exact vendor SDK version and the upstream versions of all bundled components (mbedTLS, lwIP, FreeRTOS kernel, etc.)
• Contractual requirements: Push your MCU vendor for timely security patches and SBOM data for their SDK
• Decouple where possible: If you can link mbedTLS directly (bypassing the vendor's bundled version), you can patch it independently
• Monitor both layers: Watch both the vendor SDK advisories and the upstream component CVE feeds

When to Skip FreeRTOS Entirely

For some products, FreeRTOS adds complexity without proportional benefit for CRA compliance:

Consider bare-metal if:

• Your application is single-purpose (one main loop, no concurrent tasks)
• You don't need networking (FreeRTOS doesn't provide it anyway)
• Your MCU vendor's bare-metal SDK provides everything you need
• The FreeRTOS kernel adds to your SBOM and attack surface without adding security value

Consider Zephyr if:

• You need built-in MCUboot, TLS, and device management integration
• You want a more unified security ecosystem (less vendor SDK dependency)
• Your team is starting a new project (rather than migrating an existing FreeRTOS codebase)
• SBOM generation and dependency tracking are priorities

FreeRTOS is the right choice when you have an existing codebase, need maximum portability across MCU vendors, or are committed to the AWS IoT ecosystem. But for greenfield projects with CRA compliance as a priority, Zephyr's integrated security ecosystem offers a smoother path.

FreeRTOS-Specific Compliance Checklist

Kernel configuration

• FreeRTOS kernel version pinned and recorded in project documentation
• MPU wrapper enabled for Cortex-M (configENABLE_MPU=1) if memory isolation is needed
• Stack overflow detection enabled (configCHECK_FOR_STACK_OVERFLOW=2)
• configASSERT enabled and routed to error handler (not disabled in production)

Secure boot (MCU-dependent)

• Secure boot enabled using MCU vendor's mechanism (SBSFU, HAB, ESP-IDF secure boot, etc.)
• Firmware signing key stored in HSM/KMS
• Production images signed with production key
• Anti-rollback protection configured
• See secure boot guide

Cryptography and TLS

• TLS library integrated (mbedTLS, wolfSSL, or equivalent)
• TLS 1.2+ configured with strong cipher suites
• Server certificate verification enabled
• Key storage uses hardware secure storage where available (TrustZone, SE, PUF)

OTA updates

• Update mechanism implemented (AWS OTA library, ESP-IDF OTA, vendor-specific, or custom)
• A/B partition scheme with rollback on failure
• Updates signed and verified before installation
• Update server infrastructure operational
• See OTA guide

Attack surface reduction

• JTAG/SWD disabled in production (MCU-specific configuration)
• Unused peripherals and protocols disabled
• Debug logging disabled or secured in production
• Compiler hardening flags enabled (-fstack-protector-strong, -D_FORTIFY_SOURCE=2)

SBOM

• FreeRTOS kernel version documented
• All AWS/vendor/third-party libraries enumerated with versions
• Vendor SDK version and bundled component versions recorded
• Binary blobs documented with vendor and version
• SPDX or CycloneDX document generated per release
• See SBOM guide

Vulnerability management

• CVE monitoring covers: FreeRTOS kernel, AWS libraries (if used), vendor SDK, all third-party components
• Vendor SDK update process defined (how quickly can you adopt a new SDK version)
• PSIRT process and CVD policy established
• ENISA reporting registration completed
• See Article 14 guide

The Stack Canary assessment tool assesses your full Annex I posture and identifies the specific gaps in your FreeRTOS project's CRA readiness.

Based on Regulation EU 2024/2847 Annex I, FreeRTOS documentation, AWS FreeRTOS documentation, STM32Cube documentation, ESP-IDF documentation, NXP MCUXpresso documentation. This does not constitute legal advice.

Sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)
• FreeRTOS — Official documentation
• FreeRTOS Kernel — GitHub repository
• AWS FreeRTOS — Libraries documentation
• Espressif — ESP-IDF documentation
• STMicroelectronics — STM32Cube FreeRTOS integration
• NXP — MCUXpresso SDK