The Cyber Resilience Act for Embedded Teams: Requirements, Engineering Practices and Tooling

By Facundo Zingarelli and Mikhail Seliadtsou, embedded engineers at iomico.

Key points

• The EU Cyber Resilience Act (Regulation (EU) 2024/2847) applies to almost every embedded product that can connect to a device or network, including through USB or UART. Reporting of actively exploited vulnerabilities applies from 11 September 2026; the main product-security obligations apply from 11 December 2027, to each unit placed on the market.

• Annex I describes outcomes, not mechanisms. The engineering work is choosing practices (threat modeling, vulnerability scanning, secure coding, secure updates, vulnerability handling, identity and provisioning) that achieve each outcome on a specific device, and documenting why.

• Most of these decisions are cheaper before the hardware is fixed: the threat model before component selection, the update scheme before the flash is sized, provisioning together with the hardware, and the SBOM as a build output.

The Cyber Resilience Act (CRA) is the first EU regulation to set horizontal cybersecurity requirements for products with digital elements. Its scope is defined by a product's ability to connect to a device or network rather than by industry, so it reaches virtually the whole range of embedded products on the market, from industrial controllers to consumer devices. For most embedded manufacturers, it is the first time cybersecurity obligations apply to the product itself as a condition for placing it on the EU market.

This article introduces what the CRA requires and how an embedded team can meet it in practice. It starts with the regulation's scope, deadlines, and how it relates to standards already in use; then works through the engineering practices that address each obligation; and finally the tooling that produces the supporting evidence. It is an overview rather than a compliance checklist: the aim is to map each requirement to a control a team can implement, verify, and maintain.

1. Understanding the Cyber Resilience Act

The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, makes cybersecurity part of the conditions for placing hardware and software products on the EU market. Manufacturers must address security during development and maintain a process for handling vulnerabilities after release. These responsibilities extend from the product's initial design through its declared support period.

For an embedded manufacturer, this means documenting product risks, implementing appropriate protections, and planning how deployed devices will receive security fixes. Before placing an in-scope product on the market, the manufacturer must complete the applicable conformity procedure, draw up an EU declaration of conformity, and affix the CE marking.

Non-compliance with the essential cybersecurity requirements or the manufacturer obligations in Articles 13 and 14, including vulnerability and incident reporting, can attract substantial penalties. For businesses, fines can reach €15 million or 2.5% of worldwide annual turnover for the preceding financial year, whichever is higher.

CRA scope and key deadlines

The CRA covers products whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to another device or network. A device does not need its own internet connection to qualify. Physical interfaces such as USB or UART can be relevant to this scope test. The product can also include a cloud backend developed under the manufacturer's responsibility where that backend is necessary for one of its functions.

Exclusions include products covered by specified medical-device and vehicle legislation, certified civil-aviation products, and equipment covered by the Marine Equipment Directive. Products developed or modified exclusively for national security or defence are also excluded; ordinary dual-use products are not automatically exempt.

Three dates define the rollout:

• 11 June 2026: provisions governing the notification of conformity assessment bodies began applying.

• 11 September 2026: manufacturers' reporting obligations began applying.

• 11 December 2027: the main product-security and manufacturer obligations become applicable.

Reporting requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident affecting product security, followed by a fuller notification within 72 hours and a final report within the deadlines set by Article 14. Manufacturers submit through ENISA's Single Reporting Platform to the relevant coordinating CSIRT and ENISA. These obligations also reach in-scope products already on the market.

The Commission's FAQs on the Cyber Resilience Act, version 1.4, dated 4 September 2026, clarifies in section 7.2 that the transition applies to individual units, not product models. A model launched in 2022 does not exempt new units first placed on the EU market on or after 11 December 2027. Units placed before that date generally fall outside the main obligations unless substantially modified afterwards, while remaining subject to reporting obligations.

Where the CRA fits among existing regulations and standards

Industrial teams may already work with IEC 62443. Within that series, IEC 62443-4-1 addresses secure development processes, while IEC 62443-4-2 defines technical security requirements for components. These give teams an established structure for organising lifecycle activities and product controls.

Following an existing standard does not, by itself, establish CRA conformity. For standards to provide a legal presumption of conformity under the CRA, their references must be published in the EU Official Journal for that purpose. The presumption covers the relevant requirements addressed by those standards. The Commission's CRA standardisation programme includes both general and product-specific standards.

Within that programme, amendments to EN IEC 62443-4-1 and EN IEC 62443-4-2 are being developed to support operational-technology product standards. Their supporting role should be distinguished from the Official Journal citation needed to establish presumption of conformity.

Radio-equipment manufacturers also need to account for RED 3.3 / EN 18031. EN 18031-1 addresses internet-connected radio equipment; Part 2 addresses privacy and personal-data protection for specified categories, including wearables and childcare equipment; Part 3 addresses fraud protection for internet-connected equipment handling money, monetary value, or virtual currency. Their harmonised references include restrictions. For example, EN 18031-1 does not confer presumption of conformity where its specified password clauses allow users to avoid setting and using a password.

Delegated Regulation (EU) 2026/339 repeals the RED cybersecurity Delegated Regulation (EU) 2022/30 from 11 December 2027. Until then, covered radio equipment must continue to meet the applicable RED cybersecurity requirements. Equipment placed on the market between 1 August 2025 and 10 December 2027 remains subject to market surveillance against those requirements after the repeal. The wider Radio Equipment Directive continues to apply.

For automotive engineers, ISO/SAE 21434 provides a lifecycle framework for cybersecurity risk management in vehicle electrical and electronic systems. CRA scope still needs a separate check because the exclusion follows the applicable vehicle legislation. An aftermarket telematics unit or an EV charger therefore needs its own scope review to determine whether the specific product falls under an excluded legal regime.

What manufacturers need to demonstrate

Manufacturers must document the risks their product presents, the protections they have implemented, and how they will handle vulnerabilities during its support period. Technical documentation should make these decisions traceable and explain the basis for claiming compliance.

The conformity route depends on the product's classification. For example, Annex III lists routers and microcontrollers with security-related functionality as important Class I products. For this class, self-assessment is conditional on using the applicable harmonised standards, common specifications, or qualifying certification route; otherwise, third-party assessment is required.

Two obligations have direct implications for firmware planning. First, the support period must generally be at least five years, unless expected use is shorter. Five years is a minimum, and longer-lived products may need longer support.

Second, manufacturers must produce a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies. Annex VII connects the SBOM to technical documentation, including provision following a reasoned request from a market-surveillance authority. This is not a general requirement to publish the SBOM for everyone.

For the engineering team, a useful starting question is: can we connect each security requirement to an implemented control, a verification result, and an owner responsible for maintaining it? The following section applies that question to embedded development, from threat modeling and secure coding to updates, provisioning, and vulnerability handling.

2. What the CRA means for embedded teams

Annex I of the CRA is written as outcomes. Part I lists thirteen security properties a product is expected to have; Part II lists eight vulnerability-handling processes the manufacturer is required to run. The regulation rarely names a mechanism: no bootloader, cipher, storage technology or tool.

For an embedded team, the work is to choose practices that achieve each outcome on a specific microcontroller or SoC, and to document why. This section maps the relevant articles and annex points to those practices:

• Threat modeling and risk assessment

• Vulnerability scanning

• Secure coding practices

• Secure updates

• Security processes and vulnerability handling

• Identity and provisioning

Threat modeling and risk assessment

This is the one area where the CRA prescribes the activity itself. Article 13(2) requires manufacturers to assess the cybersecurity risks of their product and take the outcome into account from planning to maintenance. Under Article 13(3), the assessment is documented, kept up to date during the support period, and indicates whether and how each requirement in Annex I, Part I, point (2) applies. Article 13(4) asks for a clear justification for any requirement considered not applicable. The risk assessment therefore sets the scope of everything that follows.

The method is not prescribed. In embedded practice, the analysis usually starts from the hardware: the assets worth protecting, such as firmware, keys, credentials and user data, and the interfaces that reach them, such as JTAG and SWD debug ports, UART consoles, USB, CAN bus, external flash, radios and the cloud backend. STRIDE, attack trees and the Threat Analysis and Risk Assessment (TARA) process from ISO/SAE 21434 are common choices, all producing threats ranked by impact and feasibility, each tied to a mitigation or an accepted residual risk.

A typical mistake is writing the threat model after the PCB layout is finished, when the microcontroller, the secure element and the debug pin routing are already fixed. We recommend a first pass before component selection and a review at each major release.

Vulnerability scanning

Annex I, Part I, point (2)(a) expects products to be made available without known exploitable vulnerabilities. Part II requires the manufacturer to identify and document vulnerabilities and components, including through an SBOM (point 1), and to apply effective and regular security tests (point 3). The CRA does not name scanning, but checking components against public vulnerability data is the most common way to address these points. Since obligations apply per unit placed on the market, a scan at first release says little about units shipped a year later.

Embedded firmware complicates this. A Zephyr RTOS or Yocto build compiles only the sources its configuration selects, while vulnerability databases record CVEs (Common Vulnerabilities and Exposures) against package versions, so name-and-version matching can flag drivers that are not in the binary. Vendor blobs, such as Wi-Fi or modem firmware, are the opposite case: they often carry no identifier a scanner can match.

Point (2)(a) refers to known exploitable vulnerabilities, so exploitability analysis is part of the work. A typical mistake is treating the raw scanner report as the result: hundreds of unfiltered findings either block the release or get ignored. We recommend scanning from the build output and recording a decision per finding (affected, fixed, or not affected with the reason), for example in VEX (Vulnerability Exploitability eXchange) format. Tools are covered in the Tooling section.

Secure coding practices

The CRA does not mention coding standards or specific mitigations. The closest points are Annex I, Part I, point (2)(j), limiting attack surfaces including external interfaces, and point (2)(k), reducing the impact of an incident through exploitation mitigation techniques. With the regular security tests of Part II, point (3), these are commonly addressed with three groups of practices:

• Reducing what can be reached: disabling unused peripherals, shells, debug logging and services in production builds, mostly through Kconfig or image configuration.

• Making memory errors harder to exploit: options include stack canaries and hardware stack guards (in Zephyr RTOS, CONFIG_STACK_CANARIES and CONFIG_HW_STACK_PROTECTION), non-executable RAM through the Memory Protection Unit (MPU), and compiler hardening flags for Linux user space (in Yocto, security_flags.inc).

• Finding defects before release: static analysis, coding standards such as MISRA C or SEI CERT C, and fuzzing of external inputs.

The risk assessment decides which apply and to what depth. A typical mistake is shipping the development configuration, such as a UART root console or an open debug port, because development and production builds were never separated. We recommend defining the production configuration early and building it in CI alongside development builds.

From our projects. On an OpenWrt-based high-power cellular router, the security work included kernel security patches, hardened toolchain flags and additional build-time security flags, together with secure boot and image signing. Making hardening part of the build means every release inherits it, instead of depending on someone remembering a manual step.

Secure updates

Annex I, Part I, point (2)(c) expects that vulnerabilities can be addressed through security updates, where applicable automatic by default, with an opt-out. Part II requires secure distribution mechanisms (point 7) and, where technically feasible, security updates separate from functionality updates (point 2). Article 13(9) requires each security update to remain available for at least ten years after issue, or the rest of the support period if longer.

The CRA does not define a secure update mechanism. In embedded practice, it is usually mapped to properties tied to other Annex I points:

• Authenticity: a signature check before running new firmware, supporting the integrity of programs in point (2)(f).

• Anti-rollback: refusing older signed images with known vulnerabilities, supporting point (2)(a).

• Robustness: an interrupted update does not leave the device unusable, supporting availability in point (2)(h).

Common implementations are MCUboot on microcontrollers and A/B schemes with RAUC, SWUpdate or Mender on embedded Linux. They have a hardware cost: two slots roughly double the flash used by the application, and anti-rollback typically relies on a monotonic counter in OTP (one-time programmable) fuses or protected storage. A typical mistake is leaving the update path for later and finding the flash too small for two slots. We recommend sizing memory for the update scheme during component selection. Our article on secure OTA firmware updates covers the design in depth.

From our projects. On a marine 5G router, we implemented OTA updates with Mender. The bootloaders verify the integrity of new firmware and refuse corrupted images, and an external flash keeps a known-good image so a failed update can be rolled back. Because we also designed the router's hardware, that extra flash could be planned into the board.

Security processes and vulnerability handling

Part II of Annex I is mostly about processes. The manufacturer is required to enforce a coordinated vulnerability disclosure policy (point 5), provide a contact for reporting vulnerabilities (point 6), remediate without delay (point 2), disclose fixed vulnerabilities once an update is available (point 4), and distribute security updates without delay and, as a rule, free of charge (point 8). Article 13(6) adds a duty toward upstream: vulnerabilities found in integrated components, including open-source ones, are reported to their maintainers.

The reporting deadlines described in the previous section put this process under time pressure. A report is much easier to prepare when the team can quickly tell which firmware versions contain the affected component and whether the vulnerable code is reachable. An archived SBOM per release is a common way to answer that in hours rather than days.

A typical mistake is leaving vulnerability handling to whoever reads the security mailbox. Without an owner and a record of decisions, the Article 14 deadlines are hard to meet. We recommend naming an owner and a backup, defining severity criteria and response times, and rehearsing on a past CVE. A security.txt file on the company website is a common way to publish the contact and policy.

Identity and provisioning

Annex I, Part I, point (2)(d) expects protection from unauthorised access through authentication, identity or access management. Point (2)(e) expects the confidentiality of data to be protected, "such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means". Points (2)(b) and (2)(m) expect a secure default configuration, a reset to the original state, and secure removal of user data. None of these specifies a mechanism; the risk assessment decides what is appropriate.

On connected devices, a common way to address points (2)(d) and (2)(e) is a unique credential per unit, typically a private key and X.509 certificate for TLS. Where the threat model includes physical access, teams often keep that key in a secure element, a Trusted Platform Module (TPM) or the microcontroller's key storage, out of reach of debug ports and external flash. A shared secret compiled into every image does the opposite: extracting it from one device exposes the fleet.

Provisioning brings these decisions to the production line: injecting keys, signing certificates, enabling secure boot and locking debug ports, each followed by a check. A typical mistake is treating provisioning as a manufacturing detail and shipping units with open debug access and a fleet-wide key. We recommend designing the provisioning flow together with the hardware.

From our projects. On an automotive Android system built on the NXP i.MX8M Plus, secure boot (NXP AHAB with signed SPL, U-Boot and kernel images, plus Android Verified Boot 2.0) was implemented together with ARM TrustZone for cryptographic operations and key storage, and a Factory Mode for secure provisioning and production locking, delivered as part of the same platform work.

What this produces

Each practice leaves evidence for the technical documentation, and much of it comes from the build and release pipeline. The next section looks at those tools, starting with SBOM generation and scanning.

3. Tooling

Generating and scanning a firmware SBOM

A connected device can have several firmware versions behind a single product release. Take a controller that runs a Zephyr application, boots through MCUboot, and uses a cellular modem with its own firmware. The modem firmware can change between releases even when the application stays the same. If the modem supplier publishes a security advisory, which releases shipped the version it names?

A software bill of materials (SBOM) is a machine-readable inventory of software components and their dependencies. For this controller, it links each product release to the application, bootloader, and modem firmware versions that shipped together. The build supplies the component inventory for the application and bootloader. For the modem, the team records the supplier's firmware version and, where available, links it to the supplier's SBOM. The Cyber Resilience Act (CRA) requires the SBOM to cover at least the product's top-level dependencies. Recording deeper dependencies helps when an advisory names a library inside the modem. The team can trace that library to a modem firmware version and then to the product releases that shipped it. That lookup matters when a supplier reports active exploitation.

If the modem supplier reports that attackers are exploiting a vulnerability, the SBOM helps the team trace the affected firmware to specific product releases. Once the manufacturer becomes aware that its product contains an actively exploited vulnerability, Article 14 requires an early warning without undue delay and within 24 hours. A CVE appearing in a scan does not, by itself, trigger that reporting duty.

SPDX and CycloneDX are two standard formats for exchanging an SBOM. In Yocto, the output of create-spdx depends on the release. Yocto 5.0 (Scarthgap) defaults to SPDX 2.2 and packages the linked documents in a .rootfs.spdx.tar.zst archive. Keep the whole archive so the references between documents can be resolved. Yocto 5.1 (Styhead) switched the default to SPDX 3.0, with the image inventory in a single .rootfs.spdx.json file.

In Zephyr RTOS 4.5 and later, build the production configuration for the target board with CONFIG_BUILD_OUTPUT_META=y, then run west spdx -d build. The build now requests the CMake data it needs automatically. SPDX 2.3 is the default output, and --spdx-version 3.0 selects SPDX 3.0. In Zephyr 4.4 and earlier, enable CONFIG_BUILD_OUTPUT_META=y and run west spdx --init -d buildbefore configuring the build; the --init step is deprecated in 4.5 and scheduled for removal in Zephyr 5.0. With sysbuild, enable the metadata for each image you want to inventory and point west spdx -d at that image's own build directory, such as build/<app-name> or build/mcuboot.

The build is only part of the picture when several images ship together. Suppose an update contains a Zephyr application, an MCUboot bootloader, and modem firmware supplied as a binary. Use the update manifest to account for all three. Collect the application and bootloader records, then request the modem SBOM from the supplier as part of component due diligence. If the supplier provides only a version and a binary, retain the version and image hash. Those let you identify releases named in a modem advisory. For a vulnerability in a library inside the modem, ask the supplier to confirm whether its firmware is affected. Binary analysis can also help identify the component.

SPDX 3.0 support varies between tools and versions. Before relying on a scanner, import an actual Yocto image SBOM and check that expected packages appear in its vulnerability analysis. For Dependency-Track, supply a CycloneDX copy and keep the original SPDX output. syft convert is one conversion option for supported input versions.

A useful import check is to pick a C library that ships in the product and search for it under the name used in upstream advisories. A vendored library may appear in the build under an internal repository name and commit hash. In Zephyr's SPDX 2.x output, modules-deps.spdx is the place to inspect module identifiers, including Package URLs (PURLs) and Common Platform Enumeration (CPE) names. It covers modules in the west manifest, including ones the build did not use. Check the source and build relationships to establish which code went into the image, and add a curated upstream identifier where a fork would otherwise be difficult to match.

Keep the SBOM with the release image and date each scan separately. If a scan flags the Linux kernel, the version match is a starting point. A vendor may have backported the fix, in which case the recipe's patch and the shipped source revision are the evidence to check. If the advisory concerns a particular driver, Yocto's SPDX_INCLUDE_COMPILED_SOURCES option records the compiled files in the kernel's SPDX document. It uses source-file information collected during do_package, so the kernel build needs debug information even if you strip the symbols from the production image. For linux-yocto, Yocto documents the features/debug/debug-kernel.scc fragment for this purpose. On releases that include vex.bbclass, you can also export the recipe's CVE_STATUS annotations for external analysis.

A Vulnerability Exploitability eXchange (VEX) statement ties the review decision to a particular product version. Available formats include CycloneDX VEX, OpenVEX, and CSAF VEX. In OpenVEX, a verified backport supports fixed. If build evidence shows that the vulnerable driver code was excluded, record not_affected with the justification vulnerable_code_not_present. Use affected when the vulnerability applies and under_investigation while the review is open. Keep the patch reference or build evidence with the decision so a customer receiving the statement can see why it applies to that release.

Why the framework and its ecosystem matter

Most of the code in an embedded product usually comes from outside the team: the RTOS or kernel, HALs and drivers, network stacks, crypto libraries, the bootloader. Under the CRA the manufacturer is responsible for all of it, and Article 13(5) requires due diligence when integrating third-party components. How well that code is maintained largely decides how much of the vulnerability handling, SBOM work and patching the team can share with upstream, and how much it has to tackle itself. That makes the framework and its ecosystem a compliance decision as much as a technical one.

The table describes what to look for, from the ideal case down to what turns a component into a liability.

Observations

• Dependency tracking in bare-metal projects is usually manual. There is rarely a common build system that knows every component: libraries are often copied into the tree and built with project-specific makefiles or IDE projects. Modern languages offer package managers that record every dependency and its version, which makes SBOM generation and dependency tracking straightforward even for bare-metal projects. Examples include Rust with Cargo, TinyGo with Go modules and Zig with its build system. Their embedded ecosystems are less mature, though, and depending on the project's needs they may not cover everything the product requires, for example drivers, vendor support or certified components. For C and C++, package managers such as Conan or vcpkg provide similar tracking, but they are still uncommon in embedded projects, and adopting one usually means restructuring an existing build.

• A security team does not guarantee coverage of the software. Some security processes focus mainly on hardware, so it is worth checking whether the SDK or framework itself is in scope. Past advisories are the most direct evidence: whether they exist, how fast they followed the report, and whether they list affected versions.

• How a component is consumed matters as much as the component. A well-maintained framework copied into the tree once and never updated moves to the liability column for that product. Keeping a clean path to upstream releases is part of the choice.

• Maintenance windows rarely match the support period. Article 13(8) sets the support period to at least five years unless the product is expected to be in use for less. Upstream LTS windows are often shorter, and the gap becomes the manufacturer's work. This is a reason to have an update process that can update not just the application but also the kernel and other dependencies, where applicable.

From our projects. On an OpenWrt-based cellular router, we moved the firmware from a customized fork to the official stable OpenWrt release (23.05.5) and isolated the product's own logic into separate packages, scripts and kernel patches. Keeping custom code apart from the upstream base is what keeps future OpenWrt upgrades, and the security fixes that come with them, a manageable step rather than a project.

A typical mistake is choosing hardware on features and cost, and finding afterwards that its software ecosystem sits mostly in the minimum or liability columns. We recommend rating each major software component against this table during component selection, and recording where it falls short and who covers the gap.

4. Conclusions

The CRA does not tell a team which bootloader, cipher or tool to use. It describes outcomes and asks the manufacturer to choose how to reach them on a given device and to document why. Most of the decisions in this article are cheaper to make early: the threat model before component selection, the update scheme before the flash is sized, the provisioning flow together with the hardware, and the SBOM as a build output. Leaving them for later usually means reworking hardware or shipping a configuration that is hard to defend.

The obligations also do not stop at first release. They apply to each unit placed on the market across a support period of at least five years, so the controls and the evidence behind them have to be kept current, not produced once. A practical way to stay on top of that is to ask, for each requirement, whether it maps to an implemented control, a verification result, and a named owner. The requirements that cannot be answered that way are the ones to work on first.

FAQ

When does the Cyber Resilience Act apply to embedded products?

Reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026, including for products already on the market. The main product-security and manufacturer obligations apply from 11 December 2027. They apply per unit, not per model: a model launched years earlier does not exempt new units first placed on the EU market on or after that date.

Does a device without an internet connection fall under the CRA?

It can. The CRA covers products whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to another device or network. A device does not need its own internet connection, and physical interfaces such as USB or UART can be relevant to the scope test. Medical devices, vehicles, certified aviation products and marine equipment covered by their own legislation are excluded.

Does the CRA require us to publish our SBOM?

No. Manufacturers must produce an SBOM in a commonly used, machine-readable format covering at least top-level dependencies, and keep it in the technical documentation. It must be provided to a market-surveillance authority on a reasoned request, but there is no general obligation to publish it.

Does following IEC 62443 or EN 18031 make a product CRA-compliant?

Not by itself. A standard gives a legal presumption of conformity under the CRA only once its reference is published in the EU Official Journal for that purpose, and only for the requirements it covers. IEC 62443-4-1/4-2 and EN 18031 give teams a useful structure, but the CRA conformity assessment still has to be done.

How long must security updates be supported under the CRA?

For the declared support period, which must generally be at least five years unless the product is expected to be in use for less. Each security update must also remain available for at least ten years after it is issued, or for the rest of the support period if that is longer.

Preparing a connected product for the Cyber Resilience Act?

iomico works on these questions day to day, across microcontroller and embedded Linux products, from threat modeling and SBOMs through secure updates, provisioning and vulnerability handling. If you are preparing a product for the CRA, or would like a review of an existing design, get in touch.

Talk to an iomico engineer →

Sources

1. Cyber Resilience Act, Regulation (EU) 2024/2847

2. European Commission, FAQs on the Cyber Resilience Act

3. Commission Delegated Regulation (EU) 2026/339

4. Yocto Project: SBOM generation

5. Yocto Project: Linux kernel vulnerabilities

6. Zephyr RTOS: Software Bill of Materials (west spdx)

7. Zephyr RTOS 4.5 migration guide