[{"data":1,"prerenderedAt":4329},["ShallowReactive",2],{"home-latest-posts":3},[4,1592,2232,3215],{"id":5,"title":6,"body":7,"date":1575,"description":1576,"extension":1577,"image":1578,"keywords":1579,"meta":1586,"navigation":98,"path":1587,"readTime":1588,"seo":1589,"stem":1590,"__hash__":1591},"blog/blog/cra-annex-i-essential-requirements-checklist.md","CRA Annex I Checklist for Firmware Engineers",{"type":8,"value":9,"toc":1535},"minimark",[10,14,17,20,25,28,35,41,44,49,56,63,66,70,74,80,85,125,128,132,137,141,179,185,189,194,198,241,245,250,254,287,291,296,300,327,330,334,339,343,397,401,406,410,443,453,457,462,466,499,503,508,512,545,549,554,558,595,611,615,620,624,663,667,672,676,703,707,712,716,737,741,744,748,772,776,807,811,838,842,863,867,914,918,939,943,970,974,1001,1005,1009,1012,1089,1093,1096,1174,1182,1186,1200,1203,1207,1212,1370,1375,1469,1477,1480,1486,1490],[11,12,13],"p",{},"Annex I of the Cyber Resilience Act is the core of the regulation. It defines the essential cybersecurity requirements that every product with digital elements must meet before it can carry a CE mark and be placed on the EU market.",[11,15,16],{},"The problem for firmware engineers: Annex I is written in regulatory language, not engineering language. It says things like \"appropriate level of cybersecurity\" and \"designed and manufactured to ensure an appropriate level of protection\" — which doesn't tell you what to implement.",[11,18,19],{},"This post translates every Annex I requirement into concrete firmware engineering tasks. Use it as a checklist to assess your current posture and track remediation work. Each requirement links to deeper coverage in our other posts where applicable.",[21,22,24],"h2",{"id":23},"how-annex-i-is-structured","How Annex I Is Structured",[11,26,27],{},"Annex I has two parts:",[11,29,30,34],{},[31,32,33],"strong",{},"Part I — Security requirements (13 items):"," These cover the product's design, development, and delivery. They address what the product itself must do.",[11,36,37,40],{},[31,38,39],{},"Part II — Vulnerability handling requirements (8 items):"," These cover the manufacturer's processes for managing vulnerabilities after the product is shipped. They address what your organisation must do.",[11,42,43],{},"Both parts must be satisfied. A product with excellent security engineering but no vulnerability management process is non-compliant, and vice versa.",[45,46,48],"h3",{"id":47},"harmonised-standards-en-18031","Harmonised Standards: EN 18031",[11,50,51,52,55],{},"CEN/CENELEC has developed harmonised standards relevant to cybersecurity for connected products. The EN 18031 series (EN 18031-1, EN 18031-2, EN 18031-3) was originally developed for the ",[31,53,54],{},"Radio Equipment Directive (RED)"," under Delegated Regulation 2022/30/EU. The series was finalised in August 2024 and harmonised references were published in the Official Journal of the EU in January 2025.",[11,57,58,59,62],{},"While EN 18031 was not developed specifically for the CRA, it serves as a foundation upon which CRA-specific harmonised standards are being built. Implementing EN 18031 provides a strong starting baseline for CRA compliance, particularly for connected products that also fall under the RED. CEN/CENELEC is developing additional CRA-specific standards that will provide a ",[31,60,61],{},"presumption of conformity"," with Annex I requirements once published.",[11,64,65],{},"In practice: if you implement EN 18031 and can demonstrate alignment with its requirements, you establish a solid technical baseline for CRA conformity, though the CRA-specific harmonised standards may add additional requirements. The requirements below reflect both the Annex I text and the EN 18031 standards where they provide useful clarification.",[21,67,69],{"id":68},"part-i-security-requirements","Part I: Security Requirements",[45,71,73],{"id":72},"requirement-1-designed-with-an-appropriate-level-of-cybersecurity","Requirement 1 — Designed with an appropriate level of cybersecurity",[11,75,76,79],{},[31,77,78],{},"Regulation text (paraphrased):"," Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks.",[11,81,82],{},[31,83,84],{},"What this means for firmware:",[86,87,90,107,113,119],"ul",{"className":88},[89],"contains-task-list",[91,92,95,100,101,106],"li",{"className":93},[94],"task-list-item",[96,97],"input",{"disabled":98,"type":99},true,"checkbox"," Conduct a risk assessment / ",[102,103,105],"a",{"href":104},"/blog/cra-threat-modeling-embedded/","threat model"," for your product before and during development",[91,108,110,112],{"className":109},[94],[96,111],{"disabled":98,"type":99}," Document security design decisions and their rationale",[91,114,116,118],{"className":115},[94],[96,117],{"disabled":98,"type":99}," Security requirements derived from the threat model are traceable to implementation",[91,120,122,124],{"className":121},[94],[96,123],{"disabled":98,"type":99}," Security is part of the development process, not bolted on after functional development",[11,126,127],{},"This is the overarching requirement. All subsequent requirements are specific instances of it.",[45,129,131],{"id":130},"requirement-2-no-known-exploitable-vulnerabilities","Requirement 2 — No known exploitable vulnerabilities",[11,133,134,136],{},[31,135,78],{}," Products must be delivered without known exploitable vulnerabilities.",[11,138,139],{},[31,140,84],{},[86,142,144,155,161,167,173],{"className":143},[89],[91,145,147,149,150,154],{"className":146},[94],[96,148],{"disabled":98,"type":99}," Run vulnerability scanning against all third-party components before each release (use your ",[102,151,153],{"href":152},"/blog/cra-sbom-firmware/","SBOM"," as input)",[91,156,158,160],{"className":157},[94],[96,159],{"disabled":98,"type":99}," Triage all CVEs affecting components in your firmware (VEX process)",[91,162,164,166],{"className":163},[94],[96,165],{"disabled":98,"type":99}," Patch or mitigate all exploitable vulnerabilities before shipping",[91,168,170,172],{"className":169},[94],[96,171],{"disabled":98,"type":99}," Document triage decisions for CVEs you've assessed as not exploitable (retain VEX records)",[91,174,176,178],{"className":175},[94],[96,177],{"disabled":98,"type":99}," Include vulnerability scan results in your release documentation",[11,180,181,184],{},[31,182,183],{},"Note:"," \"Known\" means vulnerabilities published in CVE databases for components you ship. You're expected to be monitoring.",[45,186,188],{"id":187},"requirement-3-integrity-protection","Requirement 3 — Integrity protection",[11,190,191,193],{},[31,192,78],{}," Protect the integrity of stored, transmitted, and processed data and software, including firmware.",[11,195,196],{},[31,197,84],{},[86,199,201,212,223,229,235],{"className":200},[89],[91,202,204,206,207,211],{"className":203},[94],[96,205],{"disabled":98,"type":99}," Implement ",[102,208,210],{"href":209},"/blog/cra-secure-boot-firmware-signing/","secure boot"," to verify firmware integrity at every boot",[91,213,215,217,218,222],{"className":214},[94],[96,216],{"disabled":98,"type":99}," Sign all ",[102,219,221],{"href":220},"/blog/cra-ota-firmware-updates/","firmware updates"," and verify signatures before installation",[91,224,226,228],{"className":225},[94],[96,227],{"disabled":98,"type":99}," Use authenticated encryption or HMAC for data stored in external flash/EEPROM",[91,230,232,234],{"className":231},[94],[96,233],{"disabled":98,"type":99}," Validate all data received from external interfaces before processing (input validation)",[91,236,238,240],{"className":237},[94],[96,239],{"disabled":98,"type":99}," Protect configuration data against unauthorised modification",[45,242,244],{"id":243},"requirement-4-confidentiality-protection","Requirement 4 — Confidentiality protection",[11,246,247,249],{},[31,248,78],{}," Protect the confidentiality of stored, transmitted, and processed data, including personal data and secrets.",[11,251,252],{},[31,253,84],{},[86,255,257,263,269,275,281],{"className":256},[89],[91,258,260,262],{"className":259},[94],[96,261],{"disabled":98,"type":99}," Encrypt sensitive data at rest (credentials, keys, user data) — use AES-256 or ChaCha20",[91,264,266,268],{"className":265},[94],[96,267],{"disabled":98,"type":99}," Encrypt data in transit — TLS 1.2+ for TCP, DTLS 1.2+ for UDP/CoAP on constrained devices",[91,270,272,274],{"className":271},[94],[96,273],{"disabled":98,"type":99}," Protect cryptographic keys in secure storage (hardware keystore, TrustZone, secure element) — never in plaintext flash",[91,276,278,280],{"className":277},[94],[96,279],{"disabled":98,"type":99}," Implement secure key derivation for session keys (HKDF or similar)",[91,282,284,286],{"className":283},[94],[96,285],{"disabled":98,"type":99}," Don't log or transmit sensitive data in debug output",[45,288,290],{"id":289},"requirement-5-minimise-data-collection-and-processing","Requirement 5 — Minimise data collection and processing",[11,292,293,295],{},[31,294,78],{}," Minimise the processing of data, including personal data, to what is necessary for the intended purpose.",[11,297,298],{},[31,299,84],{},[86,301,303,309,315,321],{"className":302},[89],[91,304,306,308],{"className":305},[94],[96,307],{"disabled":98,"type":99}," Only collect data necessary for the product's function (no telemetry beyond what's needed)",[91,310,312,314],{"className":311},[94],[96,313],{"disabled":98,"type":99}," Provide users with control over optional data collection",[91,316,318,320],{"className":317},[94],[96,319],{"disabled":98,"type":99}," Implement data retention limits — don't store data indefinitely",[91,322,324,326],{"className":323},[94],[96,325],{"disabled":98,"type":99}," Document what data your device collects and why",[11,328,329],{},"This requirement aligns with GDPR principles. For firmware teams, it typically means auditing your telemetry and logging to ensure you're not overcollecting.",[45,331,333],{"id":332},"requirement-6-minimise-attack-surface","Requirement 6 — Minimise attack surface",[11,335,336,338],{},[31,337,78],{}," Minimise the attack surface, including external interfaces.",[11,340,341],{},[31,342,84],{},[86,344,346,352,358,364,370,385,391],{"className":345},[89],[91,347,349,351],{"className":348},[94],[96,350],{"disabled":98,"type":99}," Disable all unused network services and protocols in production builds",[91,353,355,357],{"className":354},[94],[96,356],{"disabled":98,"type":99}," Disable debug interfaces (JTAG/SWD) in production firmware via OTP fuses or firmware configuration",[91,359,361,363],{"className":360},[94],[96,362],{"disabled":98,"type":99}," Close or disable unused UART, SPI, I2C, and other peripheral interfaces in software",[91,365,367,369],{"className":366},[94],[96,368],{"disabled":98,"type":99}," Remove debug logging, test endpoints, and development backdoors from production builds",[91,371,373,375,376,380,381,384],{"className":372},[94],[96,374],{"disabled":98,"type":99}," Compile with hardening flags (",[377,378,379],"code",{},"-fstack-protector-strong",", ",[377,382,383],{},"-D_FORTIFY_SOURCE=2",", ASLR where supported)",[91,386,388,390],{"className":387},[94],[96,389],{"disabled":98,"type":99}," Use MPU (Memory Protection Unit) to isolate privileged and unprivileged code where the MCU supports it",[91,392,394,396],{"className":393},[94],[96,395],{"disabled":98,"type":99}," Minimise the firmware binary — strip unused features, libraries, and drivers",[45,398,400],{"id":399},"requirement-7-secure-default-configuration","Requirement 7 — Secure default configuration",[11,402,403,405],{},[31,404,78],{}," Products must be delivered with a secure default configuration, including the possibility to reset to the original secure state.",[11,407,408],{},[31,409,84],{},[86,411,413,419,425,431,437],{"className":412},[89],[91,414,416,418],{"className":415},[94],[96,417],{"disabled":98,"type":99}," No default passwords — either unique-per-device credentials or force user setup on first boot",[91,420,422,424],{"className":421},[94],[96,423],{"disabled":98,"type":99}," All security features enabled by default (encryption, authentication, secure boot)",[91,426,428,430],{"className":427},[94],[96,429],{"disabled":98,"type":99}," Unnecessary services disabled by default (don't ship with telnet or HTTP debug server enabled)",[91,432,434,436],{"className":433},[94],[96,435],{"disabled":98,"type":99}," Factory reset restores the device to a secure state (not to a state with known-default credentials)",[91,438,440,442],{"className":439},[94],[96,441],{"disabled":98,"type":99}," Configuration changes that weaken security require explicit user action and generate a warning",[11,444,445,448,449,452],{},[31,446,447],{},"The \"no default passwords\" requirement is explicit and non-negotiable."," If your product ships with ",[377,450,451],{},"admin/admin"," or a common default across all units, you're in violation.",[45,454,456],{"id":455},"requirement-8-protection-against-unauthorised-access","Requirement 8 — Protection against unauthorised access",[11,458,459,461],{},[31,460,78],{}," Products must be designed to protect against unauthorised access through appropriate control mechanisms, including authentication.",[11,463,464],{},[31,465,84],{},[86,467,469,475,481,487,493],{"className":468},[89],[91,470,472,474],{"className":471},[94],[96,473],{"disabled":98,"type":99}," All remote access interfaces require authentication",[91,476,478,480],{"className":477},[94],[96,479],{"disabled":98,"type":99}," Authentication mechanisms are resistant to brute force (rate limiting, account lockout, exponential backoff)",[91,482,484,486],{"className":483},[94],[96,485],{"disabled":98,"type":99}," Credentials stored on device are hashed/salted (not plaintext)",[91,488,490,492],{"className":489},[94],[96,491],{"disabled":98,"type":99}," Session tokens have appropriate expiry",[91,494,496,498],{"className":495},[94],[96,497],{"disabled":98,"type":99}," Privilege separation — different access levels for user vs. admin vs. maintenance operations",[45,500,502],{"id":501},"requirement-9-availability-and-resilience","Requirement 9 — Availability and resilience",[11,504,505,507],{},[31,506,78],{}," Products must be designed to ensure availability, including resilience against denial-of-service attacks.",[11,509,510],{},[31,511,84],{},[86,513,515,521,527,533,539],{"className":514},[89],[91,516,518,520],{"className":517},[94],[96,519],{"disabled":98,"type":99}," Network stack handles malformed packets gracefully (doesn't crash or hang)",[91,522,524,526],{"className":523},[94],[96,525],{"disabled":98,"type":99}," Resource limits enforced — connection limits, message rate limits, buffer size limits",[91,528,530,532],{"className":529},[94],[96,531],{"disabled":98,"type":99}," Watchdog timer configured to recover from hangs",[91,534,536,538],{"className":535},[94],[96,537],{"disabled":98,"type":99}," Critical functions remain operational under network stress",[91,540,542,544],{"className":541},[94],[96,543],{"disabled":98,"type":99}," Stack and heap overflow protection enabled",[45,546,548],{"id":547},"requirement-10-secure-communications","Requirement 10 — Secure communications",[11,550,551,553],{},[31,552,78],{}," Products must ensure secure communication, including encryption of data in transit.",[11,555,556],{},[31,557,84],{},[86,559,561,567,577,583,589],{"className":560},[89],[91,562,564,566],{"className":563},[94],[96,565],{"disabled":98,"type":99}," TLS 1.2+ (or DTLS 1.2+) for all network communications carrying sensitive data",[91,568,570,572,573,576],{"className":569},[94],[96,571],{"disabled":98,"type":99}," Server certificate verification enabled (no ",[377,574,575],{},"verify=false"," in production)",[91,578,580,582],{"className":579},[94],[96,581],{"disabled":98,"type":99}," Strong cipher suites only — disable CBC mode ciphers, prefer AEAD (AES-GCM, ChaCha20-Poly1305)",[91,584,586,588],{"className":585},[94],[96,587],{"disabled":98,"type":99}," For constrained devices: DTLS 1.2 with PSK or certificate authentication over CoAP",[91,590,592,594],{"className":591},[94],[96,593],{"disabled":98,"type":99}," Certificate or PSK provisioning during manufacturing (not hardcoded shared secrets)",[11,596,597,600,601,605,606,610],{},[31,598,599],{},"Libraries:"," Mbed TLS (part of TrustedFirmware), wolfSSL, and BearSSL are common choices for MCU-based TLS. For Zephyr projects, Mbed TLS is the default. For ESP-IDF, mbedtls is bundled. (See our ",[102,602,604],{"href":603},"/blog/cra-compliance-zephyr-rtos/","Zephyr RTOS"," and ",[102,607,609],{"href":608},"/blog/cra-compliance-freertos/","FreeRTOS"," guides for RTOS-specific implementation details.)",[45,612,614],{"id":613},"requirement-11-logging-of-security-relevant-events","Requirement 11 — Logging of security-relevant events",[11,616,617,619],{},[31,618,78],{}," Products must log security-relevant events, where technically feasible.",[11,621,622],{},[31,623,84],{},[86,625,627,633,639,645,651,657],{"className":626},[89],[91,628,630,632],{"className":629},[94],[96,631],{"disabled":98,"type":99}," Log authentication attempts (success and failure)",[91,634,636,638],{"className":635},[94],[96,637],{"disabled":98,"type":99}," Log firmware update events (download, verification, installation, rollback)",[91,640,642,644],{"className":641},[94],[96,643],{"disabled":98,"type":99}," Log security configuration changes",[91,646,648,650],{"className":647},[94],[96,649],{"disabled":98,"type":99}," Log detected attacks or anomalies (malformed packets, repeated auth failures)",[91,652,654,656],{"className":653},[94],[96,655],{"disabled":98,"type":99}," Logs are tamper-protected (integrity-checked or stored in a protected region)",[91,658,660,662],{"className":659},[94],[96,661],{"disabled":98,"type":99}," For constrained devices where persistent logging isn't feasible: document why and what alternatives you provide (e.g., event counters, syslog forwarding)",[45,664,666],{"id":665},"requirement-12-secure-deletion-of-data","Requirement 12 — Secure deletion of data",[11,668,669,671],{},[31,670,78],{}," Provide the possibility for users to securely remove personal and configuration data from the device.",[11,673,674],{},[31,675,84],{},[86,677,679,685,691,697],{"className":678},[89],[91,680,682,684],{"className":681},[94],[96,683],{"disabled":98,"type":99}," Factory reset function that overwrites (not just marks as deleted) user data, credentials, and configuration",[91,686,688,690],{"className":687},[94],[96,689],{"disabled":98,"type":99}," Secure erase of cryptographic keys during factory reset",[91,692,694,696],{"className":693},[94],[96,695],{"disabled":98,"type":99}," Factory reset accessible without requiring authentication (for when credentials are lost)",[91,698,700,702],{"className":699},[94],[96,701],{"disabled":98,"type":99}," Document the factory reset procedure in user documentation",[45,704,706],{"id":705},"requirement-13-user-notification-of-security-issues","Requirement 13 — User notification of security issues",[11,708,709,711],{},[31,710,78],{}," Products must be capable of notifying users about security issues and available updates.",[11,713,714],{},[31,715,84],{},[86,717,719,725,731],{"className":718},[89],[91,720,722,724],{"className":721},[94],[96,723],{"disabled":98,"type":99}," Mechanism to inform users when a security update is available (LED indicator, companion app notification, web dashboard alert)",[91,726,728,730],{"className":727},[94],[96,729],{"disabled":98,"type":99}," Users can check the current firmware version easily",[91,732,734,736],{"className":733},[94],[96,735],{"disabled":98,"type":99}," Security advisories are published in an accessible location (product support page, security bulletin feed)",[21,738,740],{"id":739},"part-ii-vulnerability-handling-requirements","Part II: Vulnerability Handling Requirements",[11,742,743],{},"Part II requirements apply to your organisation's processes, not to the product itself. These must be in place and documented.",[45,745,747],{"id":746},"vh-requirement-1-identify-and-document-vulnerabilities-and-components","VH Requirement 1 — Identify and document vulnerabilities and components",[86,749,751,760,766],{"className":750},[89],[91,752,754,756,757,759],{"className":753},[94],[96,755],{"disabled":98,"type":99}," Maintain a machine-readable ",[102,758,153],{"href":152}," covering all product components",[91,761,763,765],{"className":762},[94],[96,764],{"disabled":98,"type":99}," SBOM updated with each firmware release",[91,767,769,771],{"className":768},[94],[96,770],{"disabled":98,"type":99}," SBOM in SPDX or CycloneDX format with NTIA minimum elements",[45,773,775],{"id":774},"vh-requirement-2-address-vulnerabilities-with-security-updates","VH Requirement 2 — Address vulnerabilities with security updates",[86,777,779,789,795,801],{"className":778},[89],[91,780,782,784,785,788],{"className":781},[94],[96,783],{"disabled":98,"type":99}," ",[102,786,787],{"href":220},"OTA update mechanism"," operational and tested",[91,790,792,794],{"className":791},[94],[96,793],{"disabled":98,"type":99}," Security updates delivered free of charge",[91,796,798,800],{"className":797},[94],[96,799],{"disabled":98,"type":99}," Patch timeline: critical/exploited vulnerabilities addressed within days/weeks, not months",[91,802,804,806],{"className":803},[94],[96,805],{"disabled":98,"type":99}," Update process documented and tested for failure scenarios",[45,808,810],{"id":809},"vh-requirement-3-regular-testing-and-review","VH Requirement 3 — Regular testing and review",[86,812,814,820,826,832],{"className":813},[89],[91,815,817,819],{"className":816},[94],[96,818],{"disabled":98,"type":99}," Regular vulnerability scanning of firmware components (at minimum, per release)",[91,821,823,825],{"className":822},[94],[96,824],{"disabled":98,"type":99}," Periodic penetration testing (annual for default category; more frequent for Class I/II)",[91,827,829,831],{"className":828},[94],[96,830],{"disabled":98,"type":99}," Code review process for security-sensitive changes",[91,833,835,837],{"className":834},[94],[96,836],{"disabled":98,"type":99}," Test results documented and retained",[45,839,841],{"id":840},"vh-requirement-4-public-disclosure-of-fixed-vulnerabilities","VH Requirement 4 — Public disclosure of fixed vulnerabilities",[86,843,845,851,857],{"className":844},[89],[91,846,848,850],{"className":847},[94],[96,849],{"disabled":98,"type":99}," Security advisories published for fixed vulnerabilities",[91,852,854,856],{"className":853},[94],[96,855],{"disabled":98,"type":99}," Advisories include CVE IDs, affected versions, fixed versions, and mitigation guidance",[91,858,860,862],{"className":859},[94],[96,861],{"disabled":98,"type":99}," Advisories published at the same time as the security update (not delayed)",[45,864,866],{"id":865},"vh-requirement-5-coordinated-vulnerability-disclosure-policy","VH Requirement 5 — Coordinated vulnerability disclosure policy",[86,868,870,880,891,897,903],{"className":869},[89],[91,871,873,875,876,879],{"className":872},[94],[96,874],{"disabled":98,"type":99}," CVD policy published and accessible (security.txt at ",[377,877,878],{},"/.well-known/security.txt",")",[91,881,883,885,886,890],{"className":882},[94],[96,884],{"disabled":98,"type":99}," Monitored security contact (",[102,887,889],{"href":888},"mailto:security@yourcompany.com","security@yourcompany.com"," or equivalent)",[91,892,894,896],{"className":893},[94],[96,895],{"disabled":98,"type":99}," Researcher acknowledgement policy defined",[91,898,900,902],{"className":899},[94],[96,901],{"disabled":98,"type":99}," Response timeline commitments documented (e.g., acknowledge within 5 business days)",[91,904,906,908,909,913],{"className":905},[94],[96,907],{"disabled":98,"type":99}," See our ",[102,910,912],{"href":911},"/blog/cra-article-14-vulnerability-reporting/","Article 14"," post for the full PSIRT setup",[45,915,917],{"id":916},"vh-requirement-6-sharing-vulnerability-information","VH Requirement 6 — Sharing vulnerability information",[86,919,921,927,933],{"className":920},[89],[91,922,924,926],{"className":923},[94],[96,925],{"disabled":98,"type":99}," Vulnerability information shared with affected parties when necessary",[91,928,930,932],{"className":929},[94],[96,931],{"disabled":98,"type":99}," ENISA notification process established for actively exploited vulnerabilities (Article 14)",[91,934,936,938],{"className":935},[94],[96,937],{"disabled":98,"type":99}," Process for notifying downstream customers when a vulnerability affects their deployment",[45,940,942],{"id":941},"vh-requirement-7-secure-distribution-of-updates","VH Requirement 7 — Secure distribution of updates",[86,944,946,952,958,964],{"className":945},[89],[91,947,949,951],{"className":948},[94],[96,950],{"disabled":98,"type":99}," Updates cryptographically signed",[91,953,955,957],{"className":954},[94],[96,956],{"disabled":98,"type":99}," Update distribution infrastructure secured (TLS, access controls)",[91,959,961,963],{"className":960},[94],[96,962],{"disabled":98,"type":99}," Update integrity verified before installation on device",[91,965,967,969],{"className":966},[94],[96,968],{"disabled":98,"type":99}," Update distribution documented in technical documentation",[45,971,973],{"id":972},"vh-requirement-8-no-undue-delay-in-distributing-security-patches","VH Requirement 8 — No undue delay in distributing security patches",[86,975,977,983,989,995],{"className":976},[89],[91,978,980,982],{"className":979},[94],[96,981],{"disabled":98,"type":99}," Patch development and release process with defined SLAs",[91,984,986,988],{"className":985},[94],[96,987],{"disabled":98,"type":99}," No gating of security patches behind feature releases or subscription payments",[91,990,992,994],{"className":991},[94],[96,993],{"disabled":98,"type":99}," Emergency patch process for critical/exploited vulnerabilities",[91,996,998,1000],{"className":997},[94],[96,999],{"disabled":98,"type":99}," Patch deployment tracking (what percentage of devices have been updated)",[21,1002,1004],{"id":1003},"using-this-checklist","Using This Checklist",[45,1006,1008],{"id":1007},"priority-order-for-firmware-teams","Priority Order for Firmware Teams",[11,1010,1011],{},"If you're starting from zero, this is the recommended implementation order:",[1013,1014,1015,1023,1032,1041,1047,1056,1065,1071,1077,1083],"ol",{},[91,1016,1017,1019,1020,879],{},[31,1018,153],{}," (VH1) — You need to know what's in your firmware before you can secure it. (",[102,1021,1022],{"href":152},"SBOM guide",[91,1024,1025,1028,1029,879],{},[31,1026,1027],{},"Secure boot"," (Req 3) — Foundation for firmware integrity. (",[102,1030,1031],{"href":209},"Secure boot guide",[91,1033,1034,1037,1038,879],{},[31,1035,1036],{},"OTA updates"," (VH2, VH7, VH8) — Ability to deliver fixes. (",[102,1039,1040],{"href":220},"OTA guide",[91,1042,1043,1046],{},[31,1044,1045],{},"Vulnerability monitoring"," (VH1, VH3) — Know when your components have CVEs",[91,1048,1049,1052,1053,879],{},[31,1050,1051],{},"CVD policy and PSIRT"," (VH5, VH6) — Handle external vulnerability reports. (",[102,1054,1055],{"href":911},"Article 14 guide",[91,1057,1058,1061,1062,879],{},[31,1059,1060],{},"Threat model"," (Req 1) — Document your security design rationale. (",[102,1063,1064],{"href":104},"Threat modeling guide",[91,1066,1067,1070],{},[31,1068,1069],{},"Secure defaults"," (Req 7) — No default passwords, services disabled by default",[91,1072,1073,1076],{},[31,1074,1075],{},"Encryption"," (Req 4, Req 10) — Data at rest and in transit",[91,1078,1079,1082],{},[31,1080,1081],{},"Access control"," (Req 8) — Authentication and authorisation",[91,1084,1085,1088],{},[31,1086,1087],{},"Everything else"," (Req 5, 6, 9, 11, 12, 13) — Important but lower priority for initial compliance",[45,1090,1092],{"id":1091},"mapping-to-product-classification","Mapping to Product Classification",[11,1094,1095],{},"The checklist applies to all CRA-classified products, but the evidence requirements differ:",[1097,1098,1099,1118],"table",{},[1100,1101,1102],"thead",{},[1103,1104,1105,1109,1112,1115],"tr",{},[1106,1107,1108],"th",{},"Requirement area",[1106,1110,1111],{},"Default (self-declare)",[1106,1113,1114],{},"Class I (CAB audit)",[1106,1116,1117],{},"Class II (notified body)",[1119,1120,1121,1135,1149,1160],"tbody",{},[1103,1122,1123,1126,1129,1132],{},[1124,1125,1060],"td",{},[1124,1127,1128],{},"Documented, internal review",[1124,1130,1131],{},"Reviewed by CAB",[1124,1133,1134],{},"Reviewed by notified body",[1103,1136,1137,1140,1143,1146],{},[1124,1138,1139],{},"Security testing",[1124,1141,1142],{},"Self-assessed test results",[1124,1144,1145],{},"Third-party test results may be required",[1124,1147,1148],{},"Formal penetration testing required",[1103,1150,1151,1153,1156,1158],{},[1124,1152,153],{},[1124,1154,1155],{},"Generated, on file",[1124,1157,1131],{},[1124,1159,1134],{},[1103,1161,1162,1165,1168,1171],{},[1124,1163,1164],{},"Process documentation",[1124,1166,1167],{},"Written, internal",[1124,1169,1170],{},"Audited by CAB",[1124,1172,1173],{},"Audited by notified body",[11,1175,1176,1177,1181],{},"See our ",[102,1178,1180],{"href":1179},"/blog/cra-product-classification/","product classification guide"," for which tier applies to your product.",[45,1183,1185],{"id":1184},"timeline","Timeline",[86,1187,1188,1194],{},[91,1189,1190,1193],{},[31,1191,1192],{},"11 September 2026:"," Vulnerability handling requirements (Part II) must be in place — specifically Article 14 reporting",[91,1195,1196,1199],{},[31,1197,1198],{},"11 December 2027:"," All Annex I requirements (Part I and Part II) must be met for products placed on the market",[11,1201,1202],{},"Start with Part II (vulnerability handling) since that deadline comes first.",[21,1204,1206],{"id":1205},"printable-summary","Printable Summary",[11,1208,1209],{},[31,1210,1211],{},"Part I — Security Requirements:",[1097,1213,1214,1227],{},[1100,1215,1216],{},[1103,1217,1218,1221,1224],{},[1106,1219,1220],{},"#",[1106,1222,1223],{},"Requirement",[1106,1225,1226],{},"Key firmware task",[1119,1228,1229,1240,1251,1262,1273,1284,1295,1305,1315,1326,1337,1348,1359],{},[1103,1230,1231,1234,1237],{},[1124,1232,1233],{},"1",[1124,1235,1236],{},"Appropriate cybersecurity level",[1124,1238,1239],{},"Threat model, security design",[1103,1241,1242,1245,1248],{},[1124,1243,1244],{},"2",[1124,1246,1247],{},"No known exploitable vulnerabilities",[1124,1249,1250],{},"CVE scanning, VEX triage",[1103,1252,1253,1256,1259],{},[1124,1254,1255],{},"3",[1124,1257,1258],{},"Integrity protection",[1124,1260,1261],{},"Secure boot, signed updates",[1103,1263,1264,1267,1270],{},[1124,1265,1266],{},"4",[1124,1268,1269],{},"Confidentiality",[1124,1271,1272],{},"Encryption at rest and in transit",[1103,1274,1275,1278,1281],{},[1124,1276,1277],{},"5",[1124,1279,1280],{},"Data minimisation",[1124,1282,1283],{},"Audit telemetry, retention limits",[1103,1285,1286,1289,1292],{},[1124,1287,1288],{},"6",[1124,1290,1291],{},"Minimise attack surface",[1124,1293,1294],{},"Disable debug ports, unused services",[1103,1296,1297,1300,1302],{},[1124,1298,1299],{},"7",[1124,1301,1069],{},[1124,1303,1304],{},"No default passwords, secure out of box",[1103,1306,1307,1310,1312],{},[1124,1308,1309],{},"8",[1124,1311,1081],{},[1124,1313,1314],{},"Authentication, privilege separation",[1103,1316,1317,1320,1323],{},[1124,1318,1319],{},"9",[1124,1321,1322],{},"Availability / resilience",[1124,1324,1325],{},"DoS protection, watchdog, resource limits",[1103,1327,1328,1331,1334],{},[1124,1329,1330],{},"10",[1124,1332,1333],{},"Secure communications",[1124,1335,1336],{},"TLS/DTLS, certificate verification",[1103,1338,1339,1342,1345],{},[1124,1340,1341],{},"11",[1124,1343,1344],{},"Security event logging",[1124,1346,1347],{},"Auth logs, update logs, anomaly detection",[1103,1349,1350,1353,1356],{},[1124,1351,1352],{},"12",[1124,1354,1355],{},"Secure data deletion",[1124,1357,1358],{},"Factory reset with secure erase",[1103,1360,1361,1364,1367],{},[1124,1362,1363],{},"13",[1124,1365,1366],{},"User notification",[1124,1368,1369],{},"Update availability notifications",[11,1371,1372],{},[31,1373,1374],{},"Part II — Vulnerability Handling:",[1097,1376,1377,1388],{},[1100,1378,1379],{},[1103,1380,1381,1383,1385],{},[1106,1382,1220],{},[1106,1384,1223],{},[1106,1386,1387],{},"Key organisational task",[1119,1389,1390,1400,1409,1419,1429,1439,1449,1459],{},[1103,1391,1392,1394,1397],{},[1124,1393,1233],{},[1124,1395,1396],{},"Component identification (SBOM)",[1124,1398,1399],{},"Automated SBOM generation in build pipeline",[1103,1401,1402,1404,1407],{},[1124,1403,1244],{},[1124,1405,1406],{},"Security update delivery",[1124,1408,787],{},[1103,1410,1411,1413,1416],{},[1124,1412,1255],{},[1124,1414,1415],{},"Regular testing",[1124,1417,1418],{},"Vulnerability scanning, penetration testing",[1103,1420,1421,1423,1426],{},[1124,1422,1266],{},[1124,1424,1425],{},"Public disclosure",[1124,1427,1428],{},"Security advisories with CVE IDs",[1103,1430,1431,1433,1436],{},[1124,1432,1277],{},[1124,1434,1435],{},"CVD policy",[1124,1437,1438],{},"security.txt, monitored inbox, response SLAs",[1103,1440,1441,1443,1446],{},[1124,1442,1288],{},[1124,1444,1445],{},"Information sharing",[1124,1447,1448],{},"ENISA reporting, downstream notification",[1103,1450,1451,1453,1456],{},[1124,1452,1299],{},[1124,1454,1455],{},"Secure update distribution",[1124,1457,1458],{},"Signed updates, TLS delivery",[1103,1460,1461,1463,1466],{},[1124,1462,1309],{},[1124,1464,1465],{},"Timely patch delivery",[1124,1467,1468],{},"Defined SLAs, no paywall on security patches",[11,1470,1471,1472,1476],{},"Use the ",[102,1473,1475],{"href":1474},"/","Stack Canary assessment tool"," to get a personalised assessment of which requirements you've already met and where to focus your remediation effort.",[1478,1479],"hr",{},[11,1481,1482],{},[1483,1484,1485],"em",{},"Based on Regulation EU 2024/2847 Annex I Parts I and II, EN 18031 series (finalised 2024, harmonised 2025), ENISA CRA implementation guidance (2025). This does not constitute legal advice.",[21,1487,1489],{"id":1488},"sources","Sources",[86,1491,1492,1500,1507,1514,1521,1528],{},[91,1493,1494],{},[102,1495,1499],{"href":1496,"rel":1497},"https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng",[1498],"nofollow","Regulation (EU) 2024/2847 — Cyber Resilience Act (full text)",[91,1501,1502],{},[102,1503,1506],{"href":1504,"rel":1505},"https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847",[1498],"CRA full text (HTML) — navigate to Annex I",[91,1508,1509],{},[102,1510,1513],{"href":1511,"rel":1512},"https://www.sgs.com/en/news/2025/02/safeguards-02625-eu-harmonizes-en-18031-standards",[1498],"EN 18031 harmonisation — EU Official Journal (January 2025)",[91,1515,1516],{},[102,1517,1520],{"href":1518,"rel":1519},"https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping",[1498],"ENISA — Cyber Resilience Act Requirements Standards Mapping",[91,1522,1523],{},[102,1524,1527],{"href":1525,"rel":1526},"https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation",[1498],"European Commission — Cyber Resilience Act implementation",[91,1529,1530],{},[102,1531,1534],{"href":1532,"rel":1533},"https://www.cencenelec.eu/news-events/news/2025/newsletter/ots-59-cybersecurity-standards/",[1498],"CEN-CENELEC — Cybersecurity standards development",{"title":1536,"searchDepth":1537,"depth":1537,"links":1538},"",2,[1539,1543,1558,1568,1573,1574],{"id":23,"depth":1537,"text":24,"children":1540},[1541],{"id":47,"depth":1542,"text":48},3,{"id":68,"depth":1537,"text":69,"children":1544},[1545,1546,1547,1548,1549,1550,1551,1552,1553,1554,1555,1556,1557],{"id":72,"depth":1542,"text":73},{"id":130,"depth":1542,"text":131},{"id":187,"depth":1542,"text":188},{"id":243,"depth":1542,"text":244},{"id":289,"depth":1542,"text":290},{"id":332,"depth":1542,"text":333},{"id":399,"depth":1542,"text":400},{"id":455,"depth":1542,"text":456},{"id":501,"depth":1542,"text":502},{"id":547,"depth":1542,"text":548},{"id":613,"depth":1542,"text":614},{"id":665,"depth":1542,"text":666},{"id":705,"depth":1542,"text":706},{"id":739,"depth":1537,"text":740,"children":1559},[1560,1561,1562,1563,1564,1565,1566,1567],{"id":746,"depth":1542,"text":747},{"id":774,"depth":1542,"text":775},{"id":809,"depth":1542,"text":810},{"id":840,"depth":1542,"text":841},{"id":865,"depth":1542,"text":866},{"id":916,"depth":1542,"text":917},{"id":941,"depth":1542,"text":942},{"id":972,"depth":1542,"text":973},{"id":1003,"depth":1537,"text":1004,"children":1569},[1570,1571,1572],{"id":1007,"depth":1542,"text":1008},{"id":1091,"depth":1542,"text":1092},{"id":1184,"depth":1542,"text":1185},{"id":1205,"depth":1537,"text":1206},{"id":1488,"depth":1537,"text":1489},"2026-04-02","Map all 13 CRA Annex I security requirements and 8 vulnerability handling obligations to concrete firmware engineering tasks. Embedded checklist.","md","/images/blog/previews/annex-i-checklist.svg",[1580,1581,1582,1583,1584,1585],"CRA Annex I checklist","CRA essential requirements","CRA compliance checklist firmware","CRA security requirements embedded","EN 18031 CRA","Annex I Part I",{},"/blog/cra-annex-i-essential-requirements-checklist","14 min",{"title":6,"description":1576},"blog/cra-annex-i-essential-requirements-checklist","ZzUXIYd7w3xIoXDLUbro8xdWYaGRZ0tRaTWmPSEcEBU",{"id":1593,"title":1594,"body":1595,"date":2216,"description":2217,"extension":1577,"image":2218,"keywords":2219,"meta":2226,"navigation":98,"path":2227,"readTime":2228,"seo":2229,"stem":2230,"__hash__":2231},"blog/blog/cra-article-14-vulnerability-reporting.md","CRA Article 14: Embedded Vulnerability Reporting",{"type":8,"value":1596,"toc":2196},[1597,1604,1611,1614,1618,1627,1631,1645,1648,1662,1665,1669,1680,1683,1703,1707,1718,1721,1738,1741,1745,1751,1771,1774,1777,1781,1784,1787,1792,1800,1805,1819,1829,1833,1836,1853,1858,1869,1872,1876,1883,1886,1906,1912,1916,1919,1922,1925,1933,1939,1943,1950,1953,1970,1975,1998,2001,2005,2008,2011,2015,2020,2040,2045,2056,2061,2099,2103,2106,2109,2124,2127,2131,2134,2142,2145,2148,2154,2156,2161,2163],[11,1598,1599,1600,1603],{},"Article 14 of the Cyber Resilience Act is the provision that will catch embedded product teams most off-guard. It's not the vulnerability-handling process itself (most firmware teams have some form of this, even if informal) — it's the ",[31,1601,1602],{},"mandatory external reporting chain with hard, legally-binding deadlines",".",[11,1605,1606,1607,1610],{},"The reporting obligation kicks in on ",[31,1608,1609],{},"11 September 2026",", more than a year ahead of full CRA enforcement. That means companies that are otherwise not CRA-ready still need to have their ENISA notification process working by September 2026.",[11,1612,1613],{},"This post breaks down the full Article 14 mechanism, clarifies the regulatory interpretation of \"actively exploited,\" and outlines a minimum viable PSIRT setup for small embedded teams.",[21,1615,1617],{"id":1616},"the-article-14-reporting-chain","The Article 14 Reporting Chain",[11,1619,1620,1621,605,1624,1603],{},"Article 14 establishes a multi-stage reporting obligation for two distinct event types: ",[31,1622,1623],{},"actively exploited vulnerabilities",[31,1625,1626],{},"severe incidents",[45,1628,1630],{"id":1629},"stage-1-24-hour-early-warning","Stage 1: 24-Hour Early Warning",[11,1632,1633,1634,1637,1638,1641,1642,1603],{},"Under Article 14(2)(a), upon becoming aware of an ",[31,1635,1636],{},"actively exploited vulnerability"," in their product, a manufacturer must submit an ",[31,1639,1640],{},"early warning"," to ENISA within ",[31,1643,1644],{},"24 hours",[11,1646,1647],{},"The early warning must contain:",[86,1649,1650,1653,1656,1659],{},[91,1651,1652],{},"Identification of the product (name, version)",[91,1654,1655],{},"Nature of the vulnerability (brief description)",[91,1657,1658],{},"Whether the manufacturer is aware of any malicious actors exploiting it",[91,1660,1661],{},"Whether corrective or mitigating measures are available",[11,1663,1664],{},"This is notification only—you don't need a patch ready. You need to notify.",[45,1666,1668],{"id":1667},"stage-2-72-hour-vulnerability-notification","Stage 2: 72-Hour Vulnerability Notification",[11,1670,1671,1672,1675,1676,1679],{},"Under Article 14(2)(b), within ",[31,1673,1674],{},"72 hours"," of becoming aware, the manufacturer must submit a more detailed ",[31,1677,1678],{},"vulnerability notification"," to ENISA.",[11,1681,1682],{},"This must include:",[86,1684,1685,1688,1691,1694,1697,1700],{},[91,1686,1687],{},"Product identifier",[91,1689,1690],{},"Affected versions",[91,1692,1693],{},"Nature of the vulnerability (CVSS-style severity, attack vector, conditions for exploitation)",[91,1695,1696],{},"Status of corrective measures (patch available, in development, or workaround only)",[91,1698,1699],{},"Planned timeline for patch release (if not yet available)",[91,1701,1702],{},"Any mitigating factors that reduce real-world exploitability",[45,1704,1706],{"id":1705},"stage-3-14-day-final-report","Stage 3: 14-Day Final Report",[11,1708,1709,1710,1713,1714,1717],{},"Under Article 14(2)(c), within ",[31,1711,1712],{},"14 days"," of becoming aware, the manufacturer must submit a ",[31,1715,1716],{},"final report"," (or \"vulnerability report\" in the regulation's terminology) to ENISA.",[11,1719,1720],{},"The final report must include:",[86,1722,1723,1726,1729,1732,1735],{},[91,1724,1725],{},"Full technical description of the vulnerability",[91,1727,1728],{},"CVE identifier (or request for one if not yet assigned)",[91,1730,1731],{},"Root cause analysis",[91,1733,1734],{},"Corrective measures taken or planned",[91,1736,1737],{},"Vulnerability impact assessment",[11,1739,1740],{},"After the 14-day report, ENISA may request additional information and can share relevant information with national cybersecurity authorities (CSIRTs and market surveillance authorities).",[45,1742,1744],{"id":1743},"the-severe-incident-track","The Severe Incident Track",[11,1746,1747,1748,1750],{},"Alongside the vulnerability reporting track, Article 14(3) creates a parallel requirement for ",[31,1749,1626],{},":",[86,1752,1753,1759,1765],{},[91,1754,1755,1758],{},[31,1756,1757],{},"24-hour early warning"," to ENISA upon becoming aware of a severe incident that has an impact on the security of the product",[91,1760,1761,1764],{},[31,1762,1763],{},"72-hour incident notification"," with fuller details",[91,1766,1767,1770],{},[31,1768,1769],{},"One-month final report"," following the incident",[11,1772,1773],{},"A \"severe incident\" is defined in the CRA as an incident that negatively affects the ability of a product with digital elements to protect the availability, authenticity, integrity, or confidentiality of data, or that has led or is capable of leading to the introduction of malicious code.",[11,1775,1776],{},"For most embedded firmware teams, the vulnerability reporting track (not the incident track) is the primary obligation to manage.",[21,1778,1780],{"id":1779},"what-actively-exploited-actually-means","What \"Actively Exploited\" Actually Means",[11,1782,1783],{},"This is the regulatory interpretation question that matters most for your triage process.",[11,1785,1786],{},"The CRA does not define \"actively exploited\" with precision in the text—this is an area where ENISA guidance and market surveillance practice will define the standard. Based on ENISA's published guidance (2025) and the regulation's intent, the working definition for compliance purposes is:",[11,1788,1789],{},[31,1790,1791],{},"A vulnerability is actively exploited when:",[86,1793,1794,1797],{},[91,1795,1796],{},"There is evidence that a threat actor has used the vulnerability against at least one system in the wild (not in a controlled research environment)",[91,1798,1799],{},"OR ENISA or a national CSIRT has flagged the vulnerability as actively exploited in their databases",[11,1801,1802],{},[31,1803,1804],{},"This is different from CVE \"known exploited\" standards in two important ways:",[1013,1806,1807,1813],{},[91,1808,1809,1812],{},[31,1810,1811],{},"Threat intelligence vs. public record:"," You don't need to wait for a CVE to appear on CISA's KEV list or similar databases. If your own threat intelligence, security researcher report, or customer incident report indicates exploitation in the wild, the 24-hour clock starts.",[91,1814,1815,1818],{},[31,1816,1817],{},"Your product specifically vs. the class of vulnerability:"," If a library you use has a known-exploited CVE (e.g., in CISA KEV), but that CVE is in a code path not present in your firmware build, it's likely not \"actively exploited in your product.\" However, if a CVE in a library you use has been exploited and the vulnerable code path is present in your firmware, the clock is running.",[11,1820,1821,1824,1825,1828],{},[31,1822,1823],{},"Practical implication:"," Your vulnerability triage process needs to determine within hours — not days — whether a newly disclosed CVE affects a code path that's actually present and exploitable in your firmware. This is one of the reasons VEX (Vulnerability Exploitability eXchange) documents are becoming important for CRA compliance. (See our post on ",[102,1826,1827],{"href":152},"SBOM and VEX for firmware",".)",[45,1830,1832],{"id":1831},"what-triggers-the-clock","What Triggers the Clock",[11,1834,1835],{},"Article 14(2) says the clock starts when the manufacturer \"becomes aware\" of the vulnerability. This has a specific regulatory meaning:",[86,1837,1838,1841,1844,1847,1850],{},[91,1839,1840],{},"Receipt of a vulnerability report from a security researcher",[91,1842,1843],{},"Internal discovery of a vulnerability via security testing or code review",[91,1845,1846],{},"Notification from a component vendor (e.g., a vulnerability in a chipset SDK)",[91,1848,1849],{},"Monitoring of CVE databases for software you ship",[91,1851,1852],{},"Customer incident reports indicating exploitation",[11,1854,1855],{},[31,1856,1857],{},"You cannot argue you \"weren't aware\" if:",[86,1859,1860,1863,1866],{},[91,1861,1862],{},"The vulnerability was published in a CVE database for a component you ship and you have no monitoring in place",[91,1864,1865],{},"A security researcher notified your published security contact and you didn't read it",[91,1867,1868],{},"Your vulnerability disclosure policy (VDP) inbox was unmanned",[11,1870,1871],{},"This means passive monitoring of CVE databases for all components in your firmware is a compliance requirement, not just good practice.",[21,1873,1875],{"id":1874},"the-enisa-single-reporting-platform","The ENISA Single Reporting Platform",[11,1877,1878,1879,1882],{},"Article 14(8) mandates that ENISA establish a ",[31,1880,1881],{},"single reporting platform"," for CRA vulnerability notifications. As of early 2026, ENISA has published the technical specification for this platform and is in the process of onboarding manufacturers.",[11,1884,1885],{},"Key practical points:",[86,1887,1888,1897,1900,1903],{},[91,1889,1890,1891,1896],{},"The platform will be available at a URL published by ENISA (check ",[102,1892,1895],{"href":1893,"rel":1894},"https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp",[1498],"ENISA's SRP page"," for registration details)",[91,1898,1899],{},"Notifications must be submitted via the platform, not via email to national CSIRTs",[91,1901,1902],{},"ENISA will route relevant information to the appropriate national CSIRT based on the manufacturer's location and the affected member states",[91,1904,1905],{},"API access will be available for automated submission (important for manufacturers with large vulnerability volumes)",[11,1907,1908,1911],{},[31,1909,1910],{},"Action item:"," Register your organisation on the ENISA reporting platform before September 2026. Don't wait until you have a vulnerability to report—the registration process takes time, and you don't want to be figuring out the platform mechanics during a 24-hour incident response window.",[21,1913,1915],{"id":1914},"article-14-and-coordinated-vulnerability-disclosure","Article 14 and Coordinated Vulnerability Disclosure",[11,1917,1918],{},"Article 14 interacts with coordinated vulnerability disclosure (CVD) in ways that create tension for security researchers and manufacturers.",[11,1920,1921],{},"Article 14(1) requires manufacturers to notify users of the affected product \"without undue delay\" after becoming aware of a vulnerability—potentially before a public disclosure or patch is available. This is different from standard CVD practice, where disclosure timing is coordinated between the researcher and vendor.",[11,1923,1924],{},"Recital 97 provides some nuance: manufacturers should coordinate with ENISA when disclosure timing affects security. In practice:",[86,1926,1927,1930],{},[91,1928,1929],{},"For vulnerabilities reported via CVD with an agreed embargo: the 24-hour ENISA notification can happen under embargo (ENISA is not required to make it public immediately)",[91,1931,1932],{},"The 14-day final report triggers ENISA information-sharing with national CSIRTs, but not necessarily public disclosure",[11,1934,1935,1938],{},[31,1936,1937],{},"For manufacturers operating a bug bounty or VDP:"," Your programme rules should explicitly mention CRA reporting obligations. Security researchers need to understand that disclosures to you trigger regulatory timelines.",[21,1940,1942],{"id":1941},"the-cvd-policy-requirement-annex-i-part-ii","The CVD Policy Requirement (Annex I, Part II)",[11,1944,1945,1946,1949],{},"Separate from but related to Article 14, Annex I Part II requires manufacturers to have a ",[31,1947,1948],{},"coordinated vulnerability disclosure policy"," as part of the essential requirements. This is distinct from the Article 14 reporting obligation.",[11,1951,1952],{},"Your CVD policy must:",[86,1954,1955,1961,1964,1967],{},[91,1956,1957,1958,1960],{},"Define a contact point for receiving vulnerability reports (e.g., ",[102,1959,889],{"href":888},", published in security.txt)",[91,1962,1963],{},"Describe the process for receiving, triaging, and handling reports",[91,1965,1966],{},"Set expectations for response timelines and researcher communication",[91,1968,1969],{},"Define your disclosure timeline and process",[11,1971,1972],{},[31,1973,1974],{},"Minimum viable CVD policy for small embedded teams:",[86,1976,1977,1983,1989,1992,1995],{},[91,1978,1979,1980,1982],{},"Publish a security.txt file at ",[377,1981,878],{}," pointing to your security contact",[91,1984,1985,1986,1988],{},"Maintain a monitored ",[102,1987,889],{"href":888}," inbox",[91,1990,1991],{},"Commit to acknowledging reports within 5 business days",[91,1993,1994],{},"Define a 90-day default disclosure timeline (aligned with industry norm)",[91,1996,1997],{},"Document the CVD policy on your product's security documentation page",[11,1999,2000],{},"The CVD policy must be published and accessible — it's part of the technical documentation reviewable by market surveillance authorities.",[21,2002,2004],{"id":2003},"setting-up-a-minimum-viable-psirt","Setting Up a Minimum Viable PSIRT",[11,2006,2007],{},"PSIRT stands for Product Security Incident Response Team. For large companies, this is a dedicated team. For small embedded product companies, it can be one or two people with defined responsibilities and documented processes.",[11,2009,2010],{},"The CRA doesn't use the term \"PSIRT,\" but the obligations in Article 14 and Annex I Part II effectively require PSIRT-equivalent capabilities.",[45,2012,2014],{"id":2013},"minimum-viable-psirt-for-a-1050-person-embedded-team","Minimum Viable PSIRT for a 10–50 Person Embedded Team",[11,2016,2017],{},[31,2018,2019],{},"Roles (can be combined):",[86,2021,2022,2028,2034],{},[91,2023,2024,2027],{},[31,2025,2026],{},"PSIRT Lead (1 person):"," Owns the vulnerability management process, makes triage decisions, signs off on ENISA notifications. This should be a senior engineer or security-aware engineering manager.",[91,2029,2030,2033],{},[31,2031,2032],{},"PSIRT Analyst (1 person):"," Monitors CVE databases, triages incoming reports, prepares notification drafts. Can be a developer with security interest.",[91,2035,2036,2039],{},[31,2037,2038],{},"Legal/Compliance contact:"," Notified for all ENISA submissions. Not necessarily a FTE—can be an external counsel relationship.",[11,2041,2042],{},[31,2043,2044],{},"Tooling (minimum):",[86,2046,2047,2050,2053],{},[91,2048,2049],{},"CVE monitoring: Subscribe to NVD feeds for all OS/library packages in your firmware. Tools like OSV-Scanner, CVSS tools, or integration into your CI pipeline.",[91,2051,2052],{},"Ticketing: A dedicated queue (Jira security project, GitHub private security advisories, or similar) for vulnerability reports—separate from general bug tracking, with appropriate access controls.",[91,2054,2055],{},"Runbooks: Written procedures for the 24-hour, 72-hour, and 14-day ENISA notifications. These should be checklists, not essays.",[11,2057,2058],{},[31,2059,2060],{},"Process (minimum):",[1013,2062,2063,2069,2075,2081,2087,2093],{},[91,2064,2065,2068],{},[31,2066,2067],{},"Inbound monitoring:"," Daily CVE feed review for all components in shipping firmware",[91,2070,2071,2074],{},[31,2072,2073],{},"Triage SLA:"," 48-hour triage decision for any new CVE affecting your firmware (affected or not, exploitable or not)",[91,2076,2077,2080],{},[31,2078,2079],{},"Escalation trigger:"," Any CVE with CVSS ≥ 8.0 or any CVE marked exploited in CISA KEV or ENISA databases triggers immediate PSIRT Lead review",[91,2082,2083,2086],{},[31,2084,2085],{},"ENISA notification trigger:"," Evidence of active exploitation → immediate 24-hour clock start",[91,2088,2089,2092],{},[31,2090,2091],{},"Patch SLA:"," Critical/actively-exploited vulnerabilities: patch within 30 days. High severity: 90 days. Medium/Low: next scheduled release.",[91,2094,2095,2098],{},[31,2096,2097],{},"Documentation:"," All triage decisions documented with rationale (needed for technical documentation file)",[45,2100,2102],{"id":2101},"the-end-of-life-security-update-obligation","The End-of-Life Security Update Obligation",[11,2104,2105],{},"Article 14(4) and Annex I Part II require manufacturers to deliver security updates for a period appropriate to the expected product lifetime. This is a standing obligation, not time-limited.",[11,2107,2108],{},"For firmware teams, \"deliver\" means:",[86,2110,2111,2118,2121],{},[91,2112,2113,2114,2117],{},"Having an OTA update mechanism (or documented manual update procedure) — see our guide on ",[102,2115,2116],{"href":220},"CRA-compliant OTA firmware updates"," for implementation details",[91,2119,2120],{},"Publishing security advisories with each security update",[91,2122,2123],{},"Maintaining a record of all security updates delivered",[11,2125,2126],{},"There is no prescribed minimum support lifetime in the CRA text itself, but market surveillance authorities will compare your stated support period against the \"expected product lifetime\" for your product category. For consumer IoT: 5 years is becoming a market norm. For industrial products: 10+ years is expected.",[21,2128,2130],{"id":2129},"article-64-fine-exposure","Article 64: Fine Exposure",[11,2132,2133],{},"Article 64 sets the penalty regime. Violations of the Article 14 vulnerability reporting obligations fall under Article 64(2), the same tier as Annex I essential requirements violations:",[86,2135,2136],{},[91,2137,2138,2141],{},[31,2139,2140],{},"Maximum fine:"," €15 million or 2.5% of worldwide annual turnover, whichever is higher",[11,2143,2144],{},"This is the highest fine tier in the CRA. Failure to notify ENISA is a discoverable, binary fact—if you didn't submit the notification, there's no ambiguity. The lower fine tier under Article 64(3) — €10 million or 2% of turnover — applies to violations of other obligations such as those in Articles 18–23, 28, and 30–33, but not to Article 14.",[11,2146,2147],{},"The September 2026 reporting deadline gives you limited time. Start building your PSIRT capability now, register on the ENISA platform before it goes live, and put your CVD policy in place this quarter.",[11,2149,2150,2151,2153],{},"The ",[102,2152,1475],{"href":1474}," will assess your current vulnerability handling practices and identify specific gaps against the Article 14 and Annex I requirements.",[1478,2155],{},[11,2157,2158],{},[1483,2159,2160],{},"Based on Regulation EU 2024/2847, Article 14, Article 64, Annex I Part II, and ENISA vulnerability reporting guidance (2025). This does not constitute legal advice. Consult qualified legal counsel for compliance decisions.",[21,2162,1489],{"id":1488},[86,2164,2165,2170,2176,2182,2189],{},[91,2166,2167],{},[102,2168,1499],{"href":1496,"rel":2169},[1498],[91,2171,2172],{},[102,2173,2175],{"href":1504,"rel":2174},[1498],"CRA full text (HTML) — see Article 14, Article 64",[91,2177,2178],{},[102,2179,2181],{"href":1893,"rel":2180},[1498],"ENISA Single Reporting Platform (SRP)",[91,2183,2184],{},[102,2185,2188],{"href":2186,"rel":2187},"https://digital-strategy.ec.europa.eu/en/policies/cra-reporting",[1498],"European Commission — CRA reporting obligations",[91,2190,2191],{},[102,2192,2195],{"href":2193,"rel":2194},"https://www.enisa.europa.eu/news/stepping-up-our-role-in-vulnerability-management-enisa-becomes-cve-root",[1498],"ENISA — Stepping up Vulnerability Management: ENISA becomes CVE Root",{"title":1536,"searchDepth":1537,"depth":1537,"links":2197},[2198,2204,2207,2208,2209,2210,2214,2215],{"id":1616,"depth":1537,"text":1617,"children":2199},[2200,2201,2202,2203],{"id":1629,"depth":1542,"text":1630},{"id":1667,"depth":1542,"text":1668},{"id":1705,"depth":1542,"text":1706},{"id":1743,"depth":1542,"text":1744},{"id":1779,"depth":1537,"text":1780,"children":2205},[2206],{"id":1831,"depth":1542,"text":1832},{"id":1874,"depth":1537,"text":1875},{"id":1914,"depth":1537,"text":1915},{"id":1941,"depth":1537,"text":1942},{"id":2003,"depth":1537,"text":2004,"children":2211},[2212,2213],{"id":2013,"depth":1542,"text":2014},{"id":2101,"depth":1542,"text":2102},{"id":2129,"depth":1537,"text":2130},{"id":1488,"depth":1537,"text":1489},"2026-03-19","CRA Article 14 vulnerability reporting: 24-hour, 72-hour, and 14-day deadlines explained, plus how to set up a minimum viable PSIRT for embedded teams.","/images/blog/previews/article-14.svg",[2220,2221,2222,2223,2224,1435,2225],"CRA Article 14","vulnerability reporting","CRA vulnerability disclosure","ENISA reporting","PSIRT","CRA compliance",{},"/blog/cra-article-14-vulnerability-reporting","10 min",{"title":1594,"description":2217},"blog/cra-article-14-vulnerability-reporting","oqIAWcOFvAyjgPiX7c7R2J45-im8i_cm5baY7bQH450",{"id":2233,"title":2234,"body":2235,"date":3199,"description":3200,"extension":1577,"image":3201,"keywords":3202,"meta":3209,"navigation":98,"path":3210,"readTime":3211,"seo":3212,"stem":3213,"__hash__":3214},"blog/blog/cra-compliance-zephyr-rtos.md","CRA Compliance for Zephyr RTOS Projects",{"type":8,"value":2236,"toc":3182},[2237,2240,2243,2249,2253,2256,2288,2291,2295,2297,2302,2315,2323,2327,2330,2338,2343,2346,2354,2357,2366,2372,2377,2385,2390,2393,2397,2416,2419,2425,2435,2440,2448,2453,2465,2470,2478,2482,2498,2503,2515,2520,2528,2533,2536,2540,2545,2552,2558,2561,2599,2608,2613,2621,2627,2632,2637,2641,2645,2648,2662,2666,2669,2673,2676,2747,2750,2754,2764,2768,2771,2782,2786,2791,2827,2832,2868,2873,2899,2904,2931,2935,2962,2966,2996,3001,3034,3038,3043,3057,3062,3076,3081,3095,3100,3120,3125,3127,3132,3134],[11,2238,2239],{},"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.",[11,2241,2242],{},"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.",[11,2244,2245,2246,1603],{},"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 ",[102,2247,2248],{"href":608},"FreeRTOS CRA compliance guide",[21,2250,2252],{"id":2251},"why-zephyrs-security-posture-matters","Why Zephyr's Security Posture Matters",[11,2254,2255],{},"Zephyr has invested more in built-in security than any other MCU-class RTOS:",[86,2257,2258,2264,2270,2276,2282],{},[91,2259,2260,2263],{},[31,2261,2262],{},"MCUboot integration"," is first-class — Zephyr's build system generates MCUboot-compatible images natively",[91,2265,2266,2269],{},[31,2267,2268],{},"Mbed TLS"," is the default TLS library, with PSA Crypto API support",[91,2271,2272,2275],{},[31,2273,2274],{},"MPU support"," across Cortex-M, RISC-V, and other architectures provides hardware memory isolation",[91,2277,2278,2281],{},[31,2279,2280],{},"MCUmgr"," provides a device management protocol for firmware updates via BLE, UART, or UDP",[91,2283,2284,2287],{},[31,2285,2286],{},"West manifest"," tracks all project dependencies with exact revisions",[11,2289,2290],{},"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.",[21,2292,2294],{"id":2293},"annex-i-mapping-to-zephyr-features","Annex I Mapping to Zephyr Features",[45,2296,69],{"id":68},[11,2298,2299],{},[31,2300,2301],{},"Requirement 1 — Appropriate cybersecurity level (threat model)",[11,2303,2304,2305,2310,2311,2314],{},"Zephyr doesn't provide a threat model for your product — that's your responsibility. However, Zephyr's own ",[102,2306,2309],{"href":2307,"rel":2308},"https://docs.zephyrproject.org/latest/security/",[1498],"security documentation"," and threat model can serve as a starting point for the RTOS layer of your product's threat model. See our ",[102,2312,2313],{"href":104},"CRA threat modeling guide"," for the full approach.",[86,2316,2317,2320],{},[91,2318,2319],{},"Zephyr provides: Documented security architecture, security-focused development process",[91,2321,2322],{},"You still need: Product-specific threat model, risk assessment",[11,2324,2325],{},[31,2326,131],{},[11,2328,2329],{},"Zephyr has an active CVE process and publishes security advisories. But you're responsible for monitoring and patching.",[86,2331,2332,2335],{},[91,2333,2334],{},"Zephyr provides: CVE tracking, security advisories, regular releases with fixes",[91,2336,2337],{},"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",[11,2339,2340],{},[31,2341,2342],{},"Requirement 3 — Integrity protection (secure boot, signed updates)",[11,2344,2345],{},"This is where Zephyr shines. MCUboot integration is mature and well-documented.",[86,2347,2348,2351],{},[91,2349,2350],{},"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",[91,2352,2353],{},"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",[11,2355,2356],{},"Kconfig options to enable:",[2358,2359,2364],"pre",{"className":2360,"code":2362,"language":2363},[2361],"language-text","# In your prj.conf or board overlay\nCONFIG_BOOTLOADER_MCUBOOT=y\nCONFIG_MCUBOOT_SIGNATURE_KEY_FILE=\"path/to/your/signing-key.pem\"\n\n# In MCUboot's prj.conf\nCONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256=y  # or ED25519, RSA\nCONFIG_BOOT_SWAP_USING_MOVE=y             # Preferred over scratch-based swap\nCONFIG_BOOT_UPGRADE_ONLY=n                # Allow revert on failure\n","text",[377,2365,2362],{"__ignoreMap":1536},[11,2367,1176,2368,2371],{},[102,2369,2370],{"href":209},"secure boot guide"," for the full pipeline.",[11,2373,2374],{},[31,2375,2376],{},"Requirement 4 — Confidentiality (encryption)",[86,2378,2379,2382],{},[91,2380,2381],{},"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)",[91,2383,2384],{},"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)",[11,2386,2387],{},[31,2388,2389],{},"Requirement 5 — Data minimisation",[11,2391,2392],{},"Not an RTOS concern — this is about your application's data collection practices.",[11,2394,2395],{},[31,2396,333],{},[86,2398,2399,2413],{},[91,2400,2401,2402,2405,2406,2409,2410,879],{},"Zephyr provides: Kconfig-based build — only compiled features are included, MPU configuration for memory isolation (",[377,2403,2404],{},"CONFIG_USERSPACE=y","), stack canaries and overflow detection (",[377,2407,2408],{},"CONFIG_STACK_SENTINEL=y"," or ",[377,2411,2412],{},"CONFIG_HW_STACK_PROTECTION=y",[91,2414,2415],{},"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)",[11,2417,2418],{},"Key Kconfig options for hardening:",[2358,2420,2423],{"className":2421,"code":2422,"language":2363},[2361],"CONFIG_HW_STACK_PROTECTION=y\nCONFIG_STACK_SENTINEL=y\nCONFIG_USERSPACE=y           # MPU-based isolation\nCONFIG_STACK_CANARIES=y\nCONFIG_FORTIFY_SOURCE=y\n",[377,2424,2422],{"__ignoreMap":1536},[11,2426,2427,2430,2431,2434],{},[31,2428,2429],{},"JTAG/SWD disable:"," This is platform-specific. For nRF devices, use ",[377,2432,2433],{},"CONFIG_NRF_APPROTECT_LOCK=y",". For STM32, RDP Level 2 is set outside Zephyr (via STM32CubeProgrammer or OTP configuration). Document which mechanism you use.",[11,2436,2437],{},[31,2438,2439],{},"Requirement 7 — Secure defaults",[86,2441,2442,2445],{},[91,2443,2444],{},"Zephyr provides: No default credentials in the RTOS itself",[91,2446,2447],{},"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",[11,2449,2450],{},[31,2451,2452],{},"Requirement 8 — Access control",[86,2454,2455,2462],{},[91,2456,2457,2458,2461],{},"Zephyr provides: Userspace/kernel separation via MPU (",[377,2459,2460],{},"CONFIG_USERSPACE","), system call interface for controlled kernel access",[91,2463,2464],{},"You still need: Application-level authentication for remote interfaces, role-based access if your product has multiple user levels",[11,2466,2467],{},[31,2468,2469],{},"Requirement 9 — Availability / resilience",[86,2471,2472,2475],{},[91,2473,2474],{},"Zephyr provides: Hardware watchdog support, thread priority management, kernel-level resource management",[91,2476,2477],{},"You still need: Watchdog configuration in your application, network stack DoS resilience testing, resource limit configuration for connections and buffers",[11,2479,2480],{},[31,2481,548],{},[86,2483,2484,2487],{},[91,2485,2486],{},"Zephyr provides: Mbed TLS for TLS 1.2/1.3 and DTLS 1.2, CoAP library with DTLS support, Bluetooth encryption (LE Secure Connections)",[91,2488,2489,2490,2493,2494,2497],{},"You still need: TLS/DTLS configuration with strong cipher suites (disable weak ciphers), server certificate verification (don't set ",[377,2491,2492],{},"mbedtls_ssl_conf_authmode"," to ",[377,2495,2496],{},"MBEDTLS_SSL_VERIFY_NONE","), certificate or PSK provisioning for your device fleet",[11,2499,2500],{},[31,2501,2502],{},"Requirement 11 — Security event logging",[86,2504,2505,2512],{},[91,2506,2507,2508,2511],{},"Zephyr provides: Logging subsystem (",[377,2509,2510],{},"CONFIG_LOG=y",") with multiple backends (UART, RTT, flash)",[91,2513,2514],{},"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",[11,2516,2517],{},[31,2518,2519],{},"Requirement 12 — Secure data deletion",[86,2521,2522,2525],{},[91,2523,2524],{},"Zephyr provides: Flash erase APIs",[91,2526,2527],{},"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)",[11,2529,2530],{},[31,2531,2532],{},"Requirement 13 — User notification",[11,2534,2535],{},"Not an RTOS feature — depends on your product's user interface (companion app, web dashboard, LED indicators).",[45,2537,2539],{"id":2538},"part-ii-vulnerability-handling","Part II: Vulnerability Handling",[11,2541,2542],{},[31,2543,2544],{},"VH1 — SBOM",[11,2546,2547,2548,2551],{},"Zephyr has a built-in SBOM generation command: ",[377,2549,2550],{},"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.",[11,2553,2554,2555,2557],{},"However, the raw ",[377,2556,2550],{}," 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.",[11,2559,2560],{},"Making the output useful requires an enrichment workflow:",[1013,2562,2563,2571,2577,2583,2593],{},[91,2564,2565,2570],{},[31,2566,2567,2568],{},"Run ",[377,2569,2550],{}," to generate the base SPDX documents from your build",[91,2572,2573,2576],{},[31,2574,2575],{},"Add CPE/PURL identifiers"," to every package so scanners can match against NVD and OSV",[91,2578,2579,2582],{},[31,2580,2581],{},"Add invisible components"," (Bluetooth stack, MQTT, cJSON) that are compiled in but not listed as discrete packages",[91,2584,2585,2588,2589,2592],{},[31,2586,2587],{},"Document binary blobs"," from vendor HALs with available version info and ",[377,2590,2591],{},"NOASSERTION"," for opaque contents",[91,2594,2595,2598],{},[31,2596,2597],{},"Merge the four SPDX files"," into a single document for submission and scanning",[11,2600,1176,2601,2605,2606,1603],{},[102,2602,2604],{"href":2603},"/blog/zephyr-sbom-cra-compliance/","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 ",[102,2607,1022],{"href":152},[11,2609,2610],{},[31,2611,2612],{},"VH2 — Security update delivery",[86,2614,2615,2618],{},[91,2616,2617],{},"Zephyr provides: MCUmgr for BLE/UART/UDP device management including firmware upload, MCUboot for A/B updates with revert",[91,2619,2620],{},"You still need: Update server infrastructure, fleet management, staged rollout capability",[11,2622,2623,2624,1603],{},"MCUmgr provides the on-device update mechanism, but fleet-scale OTA requires additional infrastructure. See our ",[102,2625,2626],{"href":220},"OTA updates guide",[11,2628,2629],{},[31,2630,2631],{},"VH3–VH8 — Vulnerability handling processes",[11,2633,2634,2635,1603],{},"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 ",[102,2636,1055],{"href":911},[21,2638,2640],{"id":2639},"gaps-in-zephyrs-cra-readiness","Gaps in Zephyr's CRA Readiness",[45,2642,2644],{"id":2643},"_1-no-built-in-fleet-management","1. No Built-In Fleet Management",[11,2646,2647],{},"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:",[86,2649,2650,2653,2656,2659],{},[91,2651,2652],{},"Update server (hawkBit, custom, or cloud IoT platform)",[91,2654,2655],{},"Device registration and inventory",[91,2657,2658],{},"Update targeting and staged rollout",[91,2660,2661],{},"Update status tracking",[45,2663,2665],{"id":2664},"_2-anti-rollback-requires-platform-support","2. Anti-Rollback Requires Platform Support",[11,2667,2668],{},"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.",[45,2670,2672],{"id":2671},"_3-secure-storage-varies-by-platform","3. Secure Storage Varies by Platform",[11,2674,2675],{},"Zephyr's trusted storage story depends heavily on the MCU:",[1097,2677,2678,2691],{},[1100,2679,2680],{},[1103,2681,2682,2685,2688],{},[1106,2683,2684],{},"Platform",[1106,2686,2687],{},"Secure storage mechanism",[1106,2689,2690],{},"Maturity in Zephyr",[1119,2692,2693,2704,2715,2725,2736],{},[1103,2694,2695,2698,2701],{},[1124,2696,2697],{},"nRF91/nRF5340",[1124,2699,2700],{},"TrustZone + KMU",[1124,2702,2703],{},"Good — SPE/NSPE split well-supported",[1103,2705,2706,2709,2712],{},[1124,2707,2708],{},"STM32L5/U5",[1124,2710,2711],{},"TrustZone + OTFDEC",[1124,2713,2714],{},"Moderate — TF-M integration available",[1103,2716,2717,2720,2723],{},[1124,2718,2719],{},"NXP LPC55S",[1124,2721,2722],{},"TrustZone + PUF",[1124,2724,2714],{},[1103,2726,2727,2730,2733],{},[1124,2728,2729],{},"ESP32",[1124,2731,2732],{},"Flash encryption + secure boot (ESP-IDF, not Zephyr-native)",[1124,2734,2735],{},"Limited — ESP32 Zephyr support is less mature for security features",[1103,2737,2738,2741,2744],{},[1124,2739,2740],{},"Generic Cortex-M4 (no TrustZone)",[1124,2742,2743],{},"Software-only, MPU isolation",[1124,2745,2746],{},"Weak — no hardware-backed secret storage",[11,2748,2749],{},"For MCUs without TrustZone or a secure element, you may need an external secure element (ATECC608, SE050) for CRA-compliant key storage.",[45,2751,2753],{"id":2752},"_4-sbom-tooling-requires-enrichment","4. SBOM Tooling Requires Enrichment",[11,2755,2756,2757,2759,2760,2763],{},"Zephyr's ",[377,2758,2550],{}," 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 ",[102,2761,2762],{"href":2603},"Zephyr SBOM tutorial"," for the full enrichment process.",[45,2765,2767],{"id":2766},"_5-debug-interface-lockdown-is-board-specific","5. Debug Interface Lockdown Is Board-Specific",[11,2769,2770],{},"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:",[86,2772,2773,2776,2779],{},[91,2774,2775],{},"Identify your MCU's debug disable mechanism (OTP fuse, register lock, AP disable)",[91,2777,2778],{},"Implement it in your board configuration or manufacturing provisioning",[91,2780,2781],{},"Document it in your technical documentation",[21,2783,2785],{"id":2784},"zephyr-specific-compliance-checklist","Zephyr-Specific Compliance Checklist",[11,2787,2788],{},[31,2789,2790],{},"Secure boot (MCUboot)",[86,2792,2794,2803,2809,2815,2821],{"className":2793},[89],[91,2795,2797,2799,2800,879],{"className":2796},[94],[96,2798],{"disabled":98,"type":99}," MCUboot enabled (",[377,2801,2802],{},"CONFIG_BOOTLOADER_MCUBOOT=y",[91,2804,2806,2808],{"className":2805},[94],[96,2807],{"disabled":98,"type":99}," Signing key generated and stored in HSM/KMS",[91,2810,2812,2814],{"className":2811},[94],[96,2813],{"disabled":98,"type":99}," Production images signed with production key (not the default development key)",[91,2816,2818,2820],{"className":2817},[94],[96,2819],{"disabled":98,"type":99}," Swap-based update with revert on failure",[91,2822,2824,2826],{"className":2823},[94],[96,2825],{"disabled":98,"type":99}," Anti-rollback counter configured for your platform",[11,2828,2829],{},[31,2830,2831],{},"Cryptography and TLS",[86,2833,2835,2841,2847,2853,2859],{"className":2834},[89],[91,2836,2838,2840],{"className":2837},[94],[96,2839],{"disabled":98,"type":99}," Mbed TLS configured with strong cipher suites only",[91,2842,2844,2846],{"className":2843},[94],[96,2845],{"disabled":98,"type":99}," TLS 1.2+ or DTLS 1.2+ for all network communications",[91,2848,2850,2852],{"className":2849},[94],[96,2851],{"disabled":98,"type":99}," Server certificate verification enabled",[91,2854,2856,2858],{"className":2855},[94],[96,2857],{"disabled":98,"type":99}," PSA Crypto API used for key management where supported",[91,2860,2862,2864,2865,879],{"className":2861},[94],[96,2863],{"disabled":98,"type":99}," Hardware crypto acceleration enabled (",[377,2866,2867],{},"CONFIG_MBEDTLS_PSA_CRYPTO_C=y",[11,2869,2870],{},[31,2871,2872],{},"Memory protection",[86,2874,2876,2885,2893],{"className":2875},[89],[91,2877,2879,2881,2882,2884],{"className":2878},[94],[96,2880],{"disabled":98,"type":99}," MPU enabled (",[377,2883,2404],{},") for applications with multiple privilege levels",[91,2886,2888,2890,2891,879],{"className":2887},[94],[96,2889],{"disabled":98,"type":99}," Stack protection enabled (",[377,2892,2412],{},[91,2894,2896,2898],{"className":2895},[94],[96,2897],{"disabled":98,"type":99}," Stack canaries or sentinels enabled",[11,2900,2901],{},[31,2902,2903],{},"Attack surface reduction",[86,2905,2907,2913,2919,2925],{"className":2906},[89],[91,2908,2910,2912],{"className":2909},[94],[96,2911],{"disabled":98,"type":99}," JTAG/SWD disabled in production builds",[91,2914,2916,2918],{"className":2915},[94],[96,2917],{"disabled":98,"type":99}," Unused Kconfig features disabled",[91,2920,2922,2924],{"className":2921},[94],[96,2923],{"disabled":98,"type":99}," Debug logging disabled or secured in production",[91,2926,2928,2930],{"className":2927},[94],[96,2929],{"disabled":98,"type":99}," Unused network protocols and services disabled",[11,2932,2933],{},[31,2934,1036],{},[86,2936,2938,2944,2950,2956],{"className":2937},[89],[91,2939,2941,2943],{"className":2940},[94],[96,2942],{"disabled":98,"type":99}," MCUmgr configured for firmware upload (BLE, UART, or UDP)",[91,2945,2947,2949],{"className":2946},[94],[96,2948],{"disabled":98,"type":99}," Update server infrastructure operational",[91,2951,2953,2955],{"className":2952},[94],[96,2954],{"disabled":98,"type":99}," Rollback tested and documented",[91,2957,2959,2961],{"className":2958},[94],[96,2960],{"disabled":98,"type":99}," Update signing key matches boot signing trust chain",[11,2963,2964],{},[31,2965,153],{},[86,2967,2969,2978,2984,2990],{"className":2968},[89],[91,2970,2972,784,2974,2977],{"className":2971},[94],[96,2973],{"disabled":98,"type":99},[377,2975,2976],{},"west.yml"," manifest parsed for all dependencies",[91,2979,2981,2983],{"className":2980},[94],[96,2982],{"disabled":98,"type":99}," CMake build output analysed for actual compiled components",[91,2985,2987,2989],{"className":2986},[94],[96,2988],{"disabled":98,"type":99}," SPDX or CycloneDX document generated per release",[91,2991,2993,2995],{"className":2992},[94],[96,2994],{"disabled":98,"type":99}," Binary blobs and external components documented",[11,2997,2998],{},[31,2999,3000],{},"Vulnerability management",[86,3002,3004,3010,3016,3022],{"className":3003},[89],[91,3005,3007,3009],{"className":3006},[94],[96,3008],{"disabled":98,"type":99}," Zephyr security advisory feed monitored",[91,3011,3013,3015],{"className":3012},[94],[96,3014],{"disabled":98,"type":99}," CVE monitoring for Mbed TLS, MCUboot, and all Zephyr modules",[91,3017,3019,3021],{"className":3018},[94],[96,3020],{"disabled":98,"type":99}," Patch/update process covers Zephyr upstream updates",[91,3023,3025,3027,3028,3030,3031,576],{"className":3024},[94],[96,3026],{"disabled":98,"type":99}," Zephyr version pinned in ",[377,3029,2976],{}," (not tracking ",[377,3032,3033],{},"main",[21,3035,3037],{"id":3036},"recommended-implementation-roadmap","Recommended Implementation Roadmap",[11,3039,3040],{},[31,3041,3042],{},"Phase 1 (Month 1–2): Foundation",[1013,3044,3045,3048,3051,3054],{},[91,3046,3047],{},"Enable MCUboot with proper signing (not development keys)",[91,3049,3050],{},"Enable MPU and stack protection",[91,3052,3053],{},"Disable JTAG/SWD in production board config",[91,3055,3056],{},"Generate initial SBOM from west manifest",[11,3058,3059],{},[31,3060,3061],{},"Phase 2 (Month 2–3): Communications and Updates",[1013,3063,3064,3067,3070,3073],{},[91,3065,3066],{},"Configure Mbed TLS with CRA-appropriate cipher suites",[91,3068,3069],{},"Set up MCUmgr for OTA updates",[91,3071,3072],{},"Implement update server infrastructure",[91,3074,3075],{},"Test and document rollback behaviour",[11,3077,3078],{},[31,3079,3080],{},"Phase 3 (Month 3–4): Vulnerability Handling",[1013,3082,3083,3086,3089,3092],{},[91,3084,3085],{},"Set up CVE monitoring for all Zephyr components",[91,3087,3088],{},"Establish PSIRT process and CVD policy",[91,3090,3091],{},"Register on ENISA reporting platform",[91,3093,3094],{},"Build VEX triage workflow",[11,3096,3097],{},[31,3098,3099],{},"Phase 4 (Month 4–5): Documentation and Testing",[1013,3101,3102,3107,3114,3117],{},[91,3103,3104,3105],{},"Conduct product ",[102,3106,105],{"href":104},[91,3108,3109,3110],{},"Run security testing against ",[102,3111,3113],{"href":3112},"/blog/cra-annex-i-essential-requirements-checklist/","Annex I requirements",[91,3115,3116],{},"Prepare Annex VII technical documentation",[91,3118,3119],{},"Prepare EU Declaration of Conformity",[11,3121,2150,3122,3124],{},[102,3123,1475],{"href":1474}," will identify your specific gaps and help prioritise your remediation roadmap based on your Zephyr project's current configuration.",[1478,3126],{},[11,3128,3129],{},[1483,3130,3131],{},"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.",[21,3133,1489],{"id":1488},[86,3135,3136,3141,3147,3154,3161,3168,3175],{},[91,3137,3138],{},[102,3139,1499],{"href":1496,"rel":3140},[1498],[91,3142,3143],{},[102,3144,3146],{"href":2307,"rel":3145},[1498],"Zephyr Project — Security documentation",[91,3148,3149],{},[102,3150,3153],{"href":3151,"rel":3152},"https://docs.zephyrproject.org/latest/develop/west/zephyr-cmds.html",[1498],"Zephyr Project — west spdx command",[91,3155,3156],{},[102,3157,3160],{"href":3158,"rel":3159},"https://docs.mcuboot.com/design.html",[1498],"MCUboot — Design documentation",[91,3162,3163],{},[102,3164,3167],{"href":3165,"rel":3166},"https://www.trustedfirmware.org/projects/mbed-tls/",[1498],"Mbed TLS — Documentation",[91,3169,3170],{},[102,3171,3174],{"href":3172,"rel":3173},"https://www.psacertified.org/getting-started/specifications/",[1498],"PSA Certified — Specifications",[91,3176,3177],{},[102,3178,3181],{"href":3179,"rel":3180},"https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/security/index.html",[1498],"Nordic Semiconductor — nRF Connect SDK security",{"title":1536,"searchDepth":1537,"depth":1537,"links":3183},[3184,3185,3189,3196,3197,3198],{"id":2251,"depth":1537,"text":2252},{"id":2293,"depth":1537,"text":2294,"children":3186},[3187,3188],{"id":68,"depth":1542,"text":69},{"id":2538,"depth":1542,"text":2539},{"id":2639,"depth":1537,"text":2640,"children":3190},[3191,3192,3193,3194,3195],{"id":2643,"depth":1542,"text":2644},{"id":2664,"depth":1542,"text":2665},{"id":2671,"depth":1542,"text":2672},{"id":2752,"depth":1542,"text":2753},{"id":2766,"depth":1542,"text":2767},{"id":2784,"depth":1537,"text":2785},{"id":3036,"depth":1537,"text":3037},{"id":1488,"depth":1537,"text":1489},"2026-03-05","Map CRA Annex I requirements to Zephyr's security ecosystem (MCUboot, Mbed TLS, PSA Crypto, MPU) and find the gaps you still need to build.","/images/blog/previews/zephyr-rtos.svg",[3203,3204,3205,3206,3207,3208],"CRA Zephyr RTOS","Zephyr CRA compliance","Cyber Resilience Act Zephyr","Zephyr RTOS security CRA","MCUboot CRA","Zephyr security",{},"/blog/cra-compliance-zephyr-rtos","13 min",{"title":2234,"description":3200},"blog/cra-compliance-zephyr-rtos","IT73m6bUOihX4cJH2kUrp6pcyrlnPY0V79AzTa6viS8",{"id":3216,"title":3217,"body":3218,"date":4315,"description":4316,"extension":1577,"image":4317,"keywords":4318,"meta":4324,"navigation":98,"path":4325,"readTime":3211,"seo":4326,"stem":4327,"__hash__":4328},"blog/blog/cra-compliance-freertos.md","CRA Compliance for FreeRTOS Firmware Projects",{"type":8,"value":3219,"toc":4300},[3220,3223,3226,3232,3236,3239,3243,3251,3268,3275,3298,3301,3305,3308,3352,3355,3359,3366,3392,3395,3400,3404,3406,3410,3415,3419,3457,3462,3467,3470,3541,3546,3550,3602,3607,3611,3623,3626,3630,3633,3637,3645,3649,3660,3664,3705,3710,3714,3717,3731,3737,3739,3743,3746,3752,3758,3775,3781,3786,3836,3841,3845,3853,3857,3860,3865,3891,3896,3922,3926,3929,3934,3948,3953,3967,3970,3974,3979,4016,4021,4056,4060,4086,4090,4123,4127,4157,4161,4200,4204,4238,4243,4245,4250,4252],[11,3221,3222],{},"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.",[11,3224,3225],{},"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.",[11,3227,3228,3229,1603],{},"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 ",[102,3230,3231],{"href":603},"Zephyr CRA compliance guide",[21,3233,3235],{"id":3234},"aws-freertos-vs-vanilla-freertos-kernel","AWS FreeRTOS vs. Vanilla FreeRTOS Kernel",[11,3237,3238],{},"This distinction matters enormously for CRA compliance:",[45,3240,3242],{"id":3241},"vanilla-freertos-kernel","Vanilla FreeRTOS Kernel",[11,3244,2150,3245,3250],{},[102,3246,3249],{"href":3247,"rel":3248},"https://github.com/FreeRTOS/FreeRTOS-Kernel",[1498],"FreeRTOS kernel"," (MIT licensed) provides:",[86,3252,3253,3256,3259,3262,3265],{},[91,3254,3255],{},"Pre-emptive and cooperative task scheduling",[91,3257,3258],{},"Binary and counting semaphores, mutexes, queues",[91,3260,3261],{},"Software timers",[91,3263,3264],{},"Memory management (heap_1 through heap_5)",[91,3266,3267],{},"MPU wrapper for Cortex-M (optional)",[11,3269,3270,3271,3274],{},"What the kernel does ",[31,3272,3273],{},"not"," provide:",[86,3276,3277,3280,3283,3286,3289,3292,3295],{},[91,3278,3279],{},"Networking (no TCP/IP, no TLS, no MQTT, no HTTP)",[91,3281,3282],{},"Cryptography (no AES, no RSA, no ECDSA, no hashing)",[91,3284,3285],{},"Secure boot (not a bootloader)",[91,3287,3288],{},"OTA updates (no update mechanism)",[91,3290,3291],{},"File system or persistent storage",[91,3293,3294],{},"SBOM generation tooling",[91,3296,3297],{},"Device management",[11,3299,3300],{},"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.",[45,3302,3304],{"id":3303},"aws-freertos-freertos-long-term-support","AWS FreeRTOS (FreeRTOS Long Term Support)",[11,3306,3307],{},"AWS provides a set of libraries designed to work with the FreeRTOS kernel and AWS IoT services:",[86,3309,3310,3316,3322,3328,3334,3340,3346],{},[91,3311,3312,3315],{},[31,3313,3314],{},"coreMQTT / coreMQTT-Agent:"," MQTT client with TLS support",[91,3317,3318,3321],{},[31,3319,3320],{},"coreHTTP:"," HTTP client",[91,3323,3324,3327],{},[31,3325,3326],{},"Mbed TLS (bundled):"," TLS and cryptographic operations",[91,3329,3330,3333],{},[31,3331,3332],{},"corePKCS11:"," Cryptographic key management interface",[91,3335,3336,3339],{},[31,3337,3338],{},"FreeRTOS OTA library:"," Over-the-air update client (works with AWS IoT Jobs)",[91,3341,3342,3345],{},[31,3343,3344],{},"FreeRTOS+TCP or lwIP:"," TCP/IP networking stacks",[91,3347,3348,3351],{},[31,3349,3350],{},"AWS IoT Device Shadow, Device Defender:"," Cloud device management",[11,3353,3354],{},"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.",[45,3356,3358],{"id":3357},"the-vendor-sdk-layer","The Vendor SDK Layer",[11,3360,3361,3362,3365],{},"Most real-world FreeRTOS projects don't use the vanilla kernel or pure AWS FreeRTOS. They use an ",[31,3363,3364],{},"MCU vendor SDK"," that bundles FreeRTOS with vendor-specific drivers, networking, and middleware:",[86,3367,3368,3374,3380,3386],{},[91,3369,3370,3373],{},[31,3371,3372],{},"STM32Cube + FreeRTOS:"," STM32 HAL, FreeRTOS kernel, optionally lwIP, mbedTLS, SBSFU bootloader",[91,3375,3376,3379],{},[31,3377,3378],{},"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",[91,3381,3382,3385],{},[31,3383,3384],{},"NXP MCUXpresso SDK + FreeRTOS:"," NXP drivers, FreeRTOS kernel, lwIP, mbedTLS, optional AWS libraries",[91,3387,3388,3391],{},[31,3389,3390],{},"TI SimpleLink SDK + FreeRTOS:"," TI drivers, FreeRTOS kernel, TI networking stack, TLS",[11,3393,3394],{},"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.",[11,3396,3397],{},[31,3398,3399],{},"For CRA compliance: your SBOM, vulnerability tracking, and security assessment must cover the vendor SDK as a whole, not just the FreeRTOS kernel.",[21,3401,3403],{"id":3402},"annex-i-mapping-to-freertos-variants","Annex I Mapping to FreeRTOS Variants",[45,3405,69],{"id":68},[11,3407,3408],{},[31,3409,2301],{},[11,3411,3412,3413,1603],{},"None of the FreeRTOS variants provide a product threat model. This is your responsibility. See our ",[102,3414,2313],{"href":104},[11,3416,3417],{},[31,3418,131],{},[1097,3420,3421,3431],{},[1100,3422,3423],{},[1103,3424,3425,3428],{},[1106,3426,3427],{},"Variant",[1106,3429,3430],{},"CVE tracking",[1119,3432,3433,3441,3449],{},[1103,3434,3435,3438],{},[1124,3436,3437],{},"Vanilla kernel",[1124,3439,3440],{},"FreeRTOS project publishes advisories; few CVEs (kernel is small and well-audited)",[1103,3442,3443,3446],{},[1124,3444,3445],{},"AWS FreeRTOS libraries",[1124,3447,3448],{},"AWS publishes advisories; coreMQTT, coreHTTP, etc. have their own CVE tracking",[1103,3450,3451,3454],{},[1124,3452,3453],{},"Vendor SDKs",[1124,3455,3456],{},"Vendor-specific advisory process (ST, Espressif, NXP, TI each have their own)",[86,3458,3459],{},[91,3460,3461],{},"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.",[11,3463,3464],{},[31,3465,3466],{},"Requirement 3 — Integrity protection (secure boot)",[11,3468,3469],{},"FreeRTOS does not include a bootloader. Secure boot is entirely dependent on your MCU platform:",[1097,3471,3472,3485],{},[1100,3473,3474],{},[1103,3475,3476,3479,3482],{},[1106,3477,3478],{},"MCU Platform",[1106,3480,3481],{},"Secure boot option",[1106,3483,3484],{},"FreeRTOS integration",[1119,3486,3487,3498,3508,3519,3530],{},[1103,3488,3489,3492,3495],{},[1124,3490,3491],{},"STM32",[1124,3493,3494],{},"SBSFU or MCUboot",[1124,3496,3497],{},"SBSFU integrates with STM32Cube FreeRTOS projects; MCUboot can be used independently",[1103,3499,3500,3502,3505],{},[1124,3501,2729],{},[1124,3503,3504],{},"ESP-IDF Secure Boot V2",[1124,3506,3507],{},"Built into ESP-IDF (which uses FreeRTOS kernel internally)",[1103,3509,3510,3513,3516],{},[1124,3511,3512],{},"NXP i.MX RT",[1124,3514,3515],{},"HAB (High Assurance Boot)",[1124,3517,3518],{},"Independent of RTOS; operates at ROM level",[1103,3520,3521,3524,3527],{},[1124,3522,3523],{},"Nordic nRF",[1124,3525,3526],{},"NSIB + MCUboot",[1124,3528,3529],{},"Via nRF Connect SDK (which supports FreeRTOS as an alternative to Zephyr)",[1103,3531,3532,3535,3538],{},[1124,3533,3534],{},"TI CC32xx",[1124,3536,3537],{},"Built-in secure boot",[1124,3539,3540],{},"Part of SimpleLink ROM; independent of RTOS",[11,3542,1176,3543,3545],{},[102,3544,2370],{"href":209}," for implementation details per platform.",[11,3547,3548],{},[31,3549,2376],{},[1097,3551,3552,3561],{},[1100,3553,3554],{},[1103,3555,3556,3558],{},[1106,3557,3427],{},[1106,3559,3560],{},"Crypto / TLS support",[1119,3562,3563,3570,3578,3586,3594],{},[1103,3564,3565,3567],{},[1124,3566,3437],{},[1124,3568,3569],{},"None — you must add a crypto library",[1103,3571,3572,3575],{},[1124,3573,3574],{},"AWS FreeRTOS",[1124,3576,3577],{},"Mbed TLS (bundled), corePKCS11 for key management",[1103,3579,3580,3583],{},[1124,3581,3582],{},"STM32Cube",[1124,3584,3585],{},"mbedTLS available via STM32Cube package",[1103,3587,3588,3591],{},[1124,3589,3590],{},"ESP-IDF",[1124,3592,3593],{},"mbedTLS bundled, hardware crypto acceleration",[1103,3595,3596,3599],{},[1124,3597,3598],{},"NXP MCUXpresso",[1124,3600,3601],{},"mbedTLS, hardware crypto via CASPER/DCP",[86,3603,3604],{},[91,3605,3606],{},"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)",[11,3608,3609],{},[31,3610,333],{},[86,3612,3613,3620],{},[91,3614,3615,3616,3619],{},"FreeRTOS kernel provides: MPU wrapper (",[377,3617,3618],{},"CONFIG_USE_MPU_WRAPPERS",") for Cortex-M memory isolation",[91,3621,3622],{},"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",[11,3624,3625],{},"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.",[11,3627,3628],{},[31,3629,2439],{},[11,3631,3632],{},"Not an RTOS concern — this is about your application's default configuration.",[11,3634,3635],{},[31,3636,2452],{},[86,3638,3639,3642],{},[91,3640,3641],{},"FreeRTOS kernel provides: MPU wrapper for kernel/user task separation",[91,3643,3644],{},"You still need: Application-level authentication, network service access control",[11,3646,3647],{},[31,3648,2469],{},[86,3650,3651,3657],{},[91,3652,3653,3654,879],{},"FreeRTOS kernel provides: Task watchdog (via software timer), stack overflow detection (",[377,3655,3656],{},"configCHECK_FOR_STACK_OVERFLOW",[91,3658,3659],{},"You still need: Hardware watchdog configuration, network DoS resilience testing, resource limits for connections and buffers",[11,3661,3662],{},[31,3663,548],{},[1097,3665,3666,3675],{},[1100,3667,3668],{},[1103,3669,3670,3672],{},[1106,3671,3427],{},[1106,3673,3674],{},"TLS/DTLS support",[1119,3676,3677,3684,3691,3698],{},[1103,3678,3679,3681],{},[1124,3680,3437],{},[1124,3682,3683],{},"None",[1103,3685,3686,3688],{},[1124,3687,3574],{},[1124,3689,3690],{},"Mbed TLS with TLS 1.2, MQTT over TLS",[1103,3692,3693,3695],{},[1124,3694,3590],{},[1124,3696,3697],{},"Mbed TLS with TLS 1.2/1.3, DTLS",[1103,3699,3700,3702],{},[1124,3701,3582],{},[1124,3703,3704],{},"mbedTLS with TLS 1.2",[86,3706,3707],{},[91,3708,3709],{},"You still need: Strong cipher suite configuration, server certificate verification, certificate provisioning for your device fleet",[11,3711,3712],{},[31,3713,2502],{},[11,3715,3716],{},"FreeRTOS doesn't include a logging framework. You need to implement or adopt one. Options:",[86,3718,3719,3722,3725],{},[91,3720,3721],{},"AWS IoT Device Defender provides security metrics reporting (AWS ecosystem only)",[91,3723,3724],{},"Custom logging to flash, UART, or syslog",[91,3726,3727,3728,879],{},"ESP-IDF has a built-in logging framework (",[377,3729,3730],{},"esp_log",[11,3732,3733,3736],{},[31,3734,3735],{},"Requirements 5, 12, 13"," — Data minimisation, secure deletion, user notification: These are application-level requirements, not RTOS features.",[45,3738,2539],{"id":2538},[11,3740,3741],{},[31,3742,2544],{},[11,3744,3745],{},"This is where FreeRTOS projects have the most complexity:",[11,3747,3748,3751],{},[31,3749,3750],{},"Kernel SBOM:"," Simple — one component (FreeRTOS-Kernel) with a clear version number and MIT license.",[11,3753,3754,3757],{},[31,3755,3756],{},"Full project SBOM:"," Complex — you need to enumerate:",[1013,3759,3760,3763,3766,3769,3772],{},[91,3761,3762],{},"FreeRTOS kernel version",[91,3764,3765],{},"All AWS FreeRTOS libraries (if used) with versions",[91,3767,3768],{},"Vendor SDK version and all components within it",[91,3770,3771],{},"Third-party libraries (lwIP, mbedTLS, fatfs, etc.)",[91,3773,3774],{},"Binary blobs from the MCU vendor",[11,3776,3777,3778,3780],{},"There's no native SBOM tooling in the FreeRTOS ecosystem. See our ",[102,3779,1022],{"href":152}," for approaches.",[11,3782,3783],{},[31,3784,3785],{},"VH2 — Security update delivery (OTA)",[1097,3787,3788,3797],{},[1100,3789,3790],{},[1103,3791,3792,3794],{},[1106,3793,3427],{},[1106,3795,3796],{},"OTA capability",[1119,3798,3799,3805,3812,3822,3829],{},[1103,3800,3801,3803],{},[1124,3802,3437],{},[1124,3804,3683],{},[1103,3806,3807,3809],{},[1124,3808,3574],{},[1124,3810,3811],{},"OTA library (works with AWS IoT Jobs)",[1103,3813,3814,3816],{},[1124,3815,3590],{},[1124,3817,3818,3821],{},[377,3819,3820],{},"esp_https_ota"," with A/B partition scheme",[1103,3823,3824,3826],{},[1124,3825,3582],{},[1124,3827,3828],{},"SBSFU provides update mechanism; no fleet management",[1103,3830,3831,3833],{},[1124,3832,3598],{},[1124,3834,3835],{},"Vendor-specific update libraries",[11,3837,3838,3839,1603],{},"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 ",[102,3840,2626],{"href":220},[11,3842,3843],{},[31,3844,2631],{},[11,3846,3847,3848,605,3850,1603],{},"Organisational requirements — same as any RTOS. See our ",[102,3849,1055],{"href":911},[102,3851,3852],{"href":3112},"Annex I checklist",[21,3854,3856],{"id":3855},"the-vendor-sdk-dependency-problem","The Vendor SDK Dependency Problem",[11,3858,3859],{},"For most FreeRTOS projects, the biggest CRA compliance challenge isn't the RTOS — it's the vendor SDK layer.",[11,3861,3862],{},[31,3863,3864],{},"Why this matters:",[1013,3866,3867,3873,3879,3885],{},[91,3868,3869,3872],{},[31,3870,3871],{},"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.",[91,3874,3875,3878],{},[31,3876,3877],{},"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.",[91,3880,3881,3884],{},[31,3882,3883],{},"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.",[91,3886,3887,3890],{},[31,3888,3889],{},"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.",[11,3892,3893],{},[31,3894,3895],{},"Mitigation strategies:",[86,3897,3898,3904,3910,3916],{},[91,3899,3900,3903],{},[31,3901,3902],{},"Pin and track:"," Record the exact vendor SDK version and the upstream versions of all bundled components (mbedTLS, lwIP, FreeRTOS kernel, etc.)",[91,3905,3906,3909],{},[31,3907,3908],{},"Contractual requirements:"," Push your MCU vendor for timely security patches and SBOM data for their SDK",[91,3911,3912,3915],{},[31,3913,3914],{},"Decouple where possible:"," If you can link mbedTLS directly (bypassing the vendor's bundled version), you can patch it independently",[91,3917,3918,3921],{},[31,3919,3920],{},"Monitor both layers:"," Watch both the vendor SDK advisories and the upstream component CVE feeds",[21,3923,3925],{"id":3924},"when-to-skip-freertos-entirely","When to Skip FreeRTOS Entirely",[11,3927,3928],{},"For some products, FreeRTOS adds complexity without proportional benefit for CRA compliance:",[11,3930,3931],{},[31,3932,3933],{},"Consider bare-metal if:",[86,3935,3936,3939,3942,3945],{},[91,3937,3938],{},"Your application is single-purpose (one main loop, no concurrent tasks)",[91,3940,3941],{},"You don't need networking (FreeRTOS doesn't provide it anyway)",[91,3943,3944],{},"Your MCU vendor's bare-metal SDK provides everything you need",[91,3946,3947],{},"The FreeRTOS kernel adds to your SBOM and attack surface without adding security value",[11,3949,3950],{},[31,3951,3952],{},"Consider Zephyr if:",[86,3954,3955,3958,3961,3964],{},[91,3956,3957],{},"You need built-in MCUboot, TLS, and device management integration",[91,3959,3960],{},"You want a more unified security ecosystem (less vendor SDK dependency)",[91,3962,3963],{},"Your team is starting a new project (rather than migrating an existing FreeRTOS codebase)",[91,3965,3966],{},"SBOM generation and dependency tracking are priorities",[11,3968,3969],{},"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.",[21,3971,3973],{"id":3972},"freertos-specific-compliance-checklist","FreeRTOS-Specific Compliance Checklist",[11,3975,3976],{},[31,3977,3978],{},"Kernel configuration",[86,3980,3982,3988,3998,4007],{"className":3981},[89],[91,3983,3985,3987],{"className":3984},[94],[96,3986],{"disabled":98,"type":99}," FreeRTOS kernel version pinned and recorded in project documentation",[91,3989,3991,3993,3994,3997],{"className":3990},[94],[96,3992],{"disabled":98,"type":99}," MPU wrapper enabled for Cortex-M (",[377,3995,3996],{},"configENABLE_MPU=1",") if memory isolation is needed",[91,3999,4001,4003,4004,879],{"className":4000},[94],[96,4002],{"disabled":98,"type":99}," Stack overflow detection enabled (",[377,4005,4006],{},"configCHECK_FOR_STACK_OVERFLOW=2",[91,4008,4010,784,4012,4015],{"className":4009},[94],[96,4011],{"disabled":98,"type":99},[377,4013,4014],{},"configASSERT"," enabled and routed to error handler (not disabled in production)",[11,4017,4018],{},[31,4019,4020],{},"Secure boot (MCU-dependent)",[86,4022,4024,4030,4036,4042,4048],{"className":4023},[89],[91,4025,4027,4029],{"className":4026},[94],[96,4028],{"disabled":98,"type":99}," Secure boot enabled using MCU vendor's mechanism (SBSFU, HAB, ESP-IDF secure boot, etc.)",[91,4031,4033,4035],{"className":4032},[94],[96,4034],{"disabled":98,"type":99}," Firmware signing key stored in HSM/KMS",[91,4037,4039,4041],{"className":4038},[94],[96,4040],{"disabled":98,"type":99}," Production images signed with production key",[91,4043,4045,4047],{"className":4044},[94],[96,4046],{"disabled":98,"type":99}," Anti-rollback protection configured",[91,4049,4051,4053,4054],{"className":4050},[94],[96,4052],{"disabled":98,"type":99}," See ",[102,4055,2370],{"href":209},[11,4057,4058],{},[31,4059,2831],{},[86,4061,4063,4069,4075,4080],{"className":4062},[89],[91,4064,4066,4068],{"className":4065},[94],[96,4067],{"disabled":98,"type":99}," TLS library integrated (mbedTLS, wolfSSL, or equivalent)",[91,4070,4072,4074],{"className":4071},[94],[96,4073],{"disabled":98,"type":99}," TLS 1.2+ configured with strong cipher suites",[91,4076,4078,2852],{"className":4077},[94],[96,4079],{"disabled":98,"type":99},[91,4081,4083,4085],{"className":4082},[94],[96,4084],{"disabled":98,"type":99}," Key storage uses hardware secure storage where available (TrustZone, SE, PUF)",[11,4087,4088],{},[31,4089,1036],{},[86,4091,4093,4099,4105,4111,4116],{"className":4092},[89],[91,4094,4096,4098],{"className":4095},[94],[96,4097],{"disabled":98,"type":99}," Update mechanism implemented (AWS OTA library, ESP-IDF OTA, vendor-specific, or custom)",[91,4100,4102,4104],{"className":4101},[94],[96,4103],{"disabled":98,"type":99}," A/B partition scheme with rollback on failure",[91,4106,4108,4110],{"className":4107},[94],[96,4109],{"disabled":98,"type":99}," Updates signed and verified before installation",[91,4112,4114,2949],{"className":4113},[94],[96,4115],{"disabled":98,"type":99},[91,4117,4119,4053,4121],{"className":4118},[94],[96,4120],{"disabled":98,"type":99},[102,4122,1040],{"href":220},[11,4124,4125],{},[31,4126,2903],{},[86,4128,4130,4136,4142,4147],{"className":4129},[89],[91,4131,4133,4135],{"className":4132},[94],[96,4134],{"disabled":98,"type":99}," JTAG/SWD disabled in production (MCU-specific configuration)",[91,4137,4139,4141],{"className":4138},[94],[96,4140],{"disabled":98,"type":99}," Unused peripherals and protocols disabled",[91,4143,4145,2924],{"className":4144},[94],[96,4146],{"disabled":98,"type":99},[91,4148,4150,4152,4153,380,4155,879],{"className":4149},[94],[96,4151],{"disabled":98,"type":99}," Compiler hardening flags enabled (",[377,4154,379],{},[377,4156,383],{},[11,4158,4159],{},[31,4160,153],{},[86,4162,4164,4170,4176,4182,4188,4193],{"className":4163},[89],[91,4165,4167,4169],{"className":4166},[94],[96,4168],{"disabled":98,"type":99}," FreeRTOS kernel version documented",[91,4171,4173,4175],{"className":4172},[94],[96,4174],{"disabled":98,"type":99}," All AWS/vendor/third-party libraries enumerated with versions",[91,4177,4179,4181],{"className":4178},[94],[96,4180],{"disabled":98,"type":99}," Vendor SDK version and bundled component versions recorded",[91,4183,4185,4187],{"className":4184},[94],[96,4186],{"disabled":98,"type":99}," Binary blobs documented with vendor and version",[91,4189,4191,2989],{"className":4190},[94],[96,4192],{"disabled":98,"type":99},[91,4194,4196,4053,4198],{"className":4195},[94],[96,4197],{"disabled":98,"type":99},[102,4199,1022],{"href":152},[11,4201,4202],{},[31,4203,3000],{},[86,4205,4207,4213,4219,4225,4231],{"className":4206},[89],[91,4208,4210,4212],{"className":4209},[94],[96,4211],{"disabled":98,"type":99}," CVE monitoring covers: FreeRTOS kernel, AWS libraries (if used), vendor SDK, all third-party components",[91,4214,4216,4218],{"className":4215},[94],[96,4217],{"disabled":98,"type":99}," Vendor SDK update process defined (how quickly can you adopt a new SDK version)",[91,4220,4222,4224],{"className":4221},[94],[96,4223],{"disabled":98,"type":99}," PSIRT process and CVD policy established",[91,4226,4228,4230],{"className":4227},[94],[96,4229],{"disabled":98,"type":99}," ENISA reporting registration completed",[91,4232,4234,4053,4236],{"className":4233},[94],[96,4235],{"disabled":98,"type":99},[102,4237,1055],{"href":911},[11,4239,2150,4240,4242],{},[102,4241,1475],{"href":1474}," assesses your full Annex I posture and identifies the specific gaps in your FreeRTOS project's CRA readiness.",[1478,4244],{},[11,4246,4247],{},[1483,4248,4249],{},"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.",[21,4251,1489],{"id":1488},[86,4253,4254,4259,4266,4272,4279,4286,4293],{},[91,4255,4256],{},[102,4257,1499],{"href":1496,"rel":4258},[1498],[91,4260,4261],{},[102,4262,4265],{"href":4263,"rel":4264},"https://www.freertos.org/Documentation/RTOS_book.html",[1498],"FreeRTOS — Official documentation",[91,4267,4268],{},[102,4269,4271],{"href":3247,"rel":4270},[1498],"FreeRTOS Kernel — GitHub repository",[91,4273,4274],{},[102,4275,4278],{"href":4276,"rel":4277},"https://docs.aws.amazon.com/freertos/latest/userguide/dev-guide-freertos-libraries.html",[1498],"AWS FreeRTOS — Libraries documentation",[91,4280,4281],{},[102,4282,4285],{"href":4283,"rel":4284},"https://docs.espressif.com/projects/esp-idf/en/stable/esp32/",[1498],"Espressif — ESP-IDF documentation",[91,4287,4288],{},[102,4289,4292],{"href":4290,"rel":4291},"https://www.st.com/en/embedded-software/stm32cube-mcu-mpu-packages.html",[1498],"STMicroelectronics — STM32Cube FreeRTOS integration",[91,4294,4295],{},[102,4296,4299],{"href":4297,"rel":4298},"https://www.nxp.com/design/design-center/software/development-software/mcuxpresso-software-and-tools-/mcuxpresso-software-development-kit-sdk:MCUXpresso-SDK",[1498],"NXP — MCUXpresso SDK",{"title":1536,"searchDepth":1537,"depth":1537,"links":4301},[4302,4307,4311,4312,4313,4314],{"id":3234,"depth":1537,"text":3235,"children":4303},[4304,4305,4306],{"id":3241,"depth":1542,"text":3242},{"id":3303,"depth":1542,"text":3304},{"id":3357,"depth":1542,"text":3358},{"id":3402,"depth":1537,"text":3403,"children":4308},[4309,4310],{"id":68,"depth":1542,"text":69},{"id":2538,"depth":1542,"text":2539},{"id":3855,"depth":1537,"text":3856},{"id":3924,"depth":1537,"text":3925},{"id":3972,"depth":1537,"text":3973},{"id":1488,"depth":1537,"text":1489},"2026-02-19","Map CRA Annex I requirements to FreeRTOS variants—vanilla kernel, AWS FreeRTOS, and vendor SDKs—and find the gaps the kernel doesn't cover.","/images/blog/previews/freertos.svg",[4319,4320,4321,4322,4323],"CRA FreeRTOS","FreeRTOS CRA compliance","Cyber Resilience Act FreeRTOS","FreeRTOS security CRA","AWS FreeRTOS CRA",{},"/blog/cra-compliance-freertos",{"title":3217,"description":4316},"blog/cra-compliance-freertos","JVswK3uSOpDkboMP5WDf7-vfLQ37yFubjMQQhLN4rLA",1775939691377]