Understanding Radio Equipment Directive: What it means for FOSS and SBOMs.

Do you deliver Electronic Equipment with Radio components to the EU? Then the following new Regulation is relevant for you:

The Radio Equipment Directive (RED)¹, formally known as Directive 2014/53/EU, is the European Union’s framework for regulating devices that communicate via radio waves. Its main objective is to ensure that radio equipment placed on the EU market is safe, does not interfere with other devices, and uses the radio spectrum efficiently. RED applies to a wide range of electronic devices that use wireless communication, including smartphones, laptops, Wi-Fi routers, wearables, smart home gadgets. Essentially, if a device sends or receives radio signals like Bluetooth, Wi-Fi, mobile data, or GPS, it’s likely covered. A key goal of RED is also to ensure that compliant devices can be freely traded across the EU internal market².

On August 1, 2025, the enforcement of the Radio Equipment Directive’s Delegated Act (EU) 2022/30 came into effect, imposing new cybersecurity obligations on manufacturers of radio-enabled products. Alongside this, the EU has resumed work on another significant provision of the same directive. Article 3(3)(i), which may soon lead to software control mechanisms on devices. Together, these developments raise complex legal and technical questions on integrating Free and Open Source Software (FOSS) in the European device market.

Understanding Software Freedom and Tivoization

Free and Open Source Software (FOSS) is defined not just by access to source code, but by four essential freedoms:³

Freedom 0 – The freedom to run the program as you wish, for any purpose.
Freedom 1 – The freedom to study how the program works and change it.
Freedom 2 – The freedom to redistribute copies.
Freedom 3 – The freedom to distribute modified versions.

These freedoms ensure that users have control over the software they use, not just in theory, but in practical, technical terms.⁴ However, these freedoms can be undermined by technical barriers, such as preventing users from installing modified software on their devices.

To understand the context, it helps to revisit the past. The story of “Tivoization” dates back to the early 2000s, when TiVo, a U.S. manufacturer of digital video recorders, built its devices using the Linux kernel. While TiVo complied with the GPLv2 license by publishing the source code, it also locked its devices in such a way that users could not install modified versions of the software. This hardware-level restriction gave rise to the term “Tivoization” and sparked a philosophical and legal debate about what it means to truly respect software freedom.⁵

In response, the Free Software Foundation introduced the GPLv3 license in the year 2007.⁶ This version added a critical new clause known as “Installation Information,“ which refers to any methods, procedures, authorization keys, or other information required to install and execute modified versions of the covered work in that User Product from a modified version of its Corresponding Source. This clause means manufacturers must provide users with the necessary information, such as keys or procedures, to install and execute modified versions of the software on the device, ensuring that users are not technically prevented from exercising their freedom to modify and reinstall the program. The aim was to close a loophole: providing source code alone is not sufficient if users are technically prevented from exercising their rights to modify and reinstall that code.

Article 3(3) (i) RED

The tivoization conversation is resurfacing in the context of RED. Article 3(3)(i) of the RED proposes that certain categories of radio devices must be constructed in a way that ensures only compliant software can be loaded. This would likely involve mechanisms such as secure boot or cryptographic signature enforcement, which would prevent end users from installing modified firmware unless it has been formally approved. From a legal persepctive, this creates a direct conflict with licenses like GPLv3, AGPLv3 and LGPLv3, all of which require that users be able to install modified versions of the software on devices they own.⁷ If Article 3(3)(i) is activated, manufacturers may find themselves unable to comply with both RED and these FOSS licenses. The Free Software Foundation Europe (FSFE) has long warned that Article 3(3)(i), if activated without safeguards, could lead to technical restrictions that undermine user freedom and the legality of distributing devices with copyleft-licensed software. Their concern is that requiring only „compliant software” to be installable could be used to justify bootloader locking, effectively blocking users from running modified firmware.⁸ RED’s own recitals also reveal a conflict between security and software openness. Recital 16 justifies restricting software loading to ensure ongoing compliance with essential requirements like safety and spectrum use. But Recital 19 cautions that such restrictions must not be abused to block third-party software or lock out independent developers.⁹

As of now, Article 3(3)(i) remains dormant. It is legally part of RED, but it does not apply to any product class until the European Commission adopts a delegated act specifying which categories of equipment are subject to the requirement. This process was initially paused in 2021 due to the introduction of the Cyber Resilience Act (CRA), which also deals with software security and digital product safety.¹⁰ However, in 2023, the Commission resumed work on Article 3(3)(i), narrowing its scope to focus on ensuring that software updates do not interfere with radio spectrum compliance.¹¹ A new impact assessment study is currently underway and is expected to form the basis for future activation of the provision. The Commission also launched a call for evidence to assess the potential impacts of activating the Article 3(3) (i).¹² Notably, the supporting study for this initiative emphasized the importance of tracking third-party software components and maintaining transparency throughout the software lifecycle.¹³ The concept of Software Bill Of Materials (SBOM) was highlighted as a key mechanism to manage compliance and risk in software-defined radio systems.

In its response to this call for evidence, Bitkom (Germany’s digital industry association) argued that manufacturers are already ensuring software conformity under Article 3(2) of RED, either by technically blocking the installation of non-compliant software or by explicitly specifying compliant software in their declarations and user documentation.¹⁴ As such, they view additional obligations under Article 3(3)(i) as redundant. Bitkom recommended that the Commission focus on clarifying existing guidance, rather than imposing new rules. They also urged the Commission to clearly define the product categories and the scope of “software” affected by any future activation of Article 3(3)(i).

The Bootloader Lockdown case: From EU to the US

In July 2025, Samsung removed the bootloader unlock option in One UI 8 for its devices in several regions, including the EU.¹⁵ Although the company has not officially cited RED, the timing just days before the RED cybersecurity provisions took effect, has led observers to conclude that RED compliance pressures may be behind the decision. Critics argue that such moves, whether due to RED or not, harm innovation, prevent repairability, and user control¹⁶. Other vendors have maintained bootloader unlocking support, illustrating that RED compliance can be achieved without sacrificing user control.

This EU case has clear parallels in the United States where bootloader locking is already widespread, with many smartphones including Samsung devices restricting users from installing modified operating systems.¹⁷ While U.S. copyright law (specifically DMCA Section 1201) allows exemptions for jailbreaking and rooting personal devices, it does not compel manufacturers to make unlocking easy or legally permit the distribution of jailbreak.¹⁸ This tension is illustrated in the most recent case of Echelon, a fitness equipment maker that pushed a firmware update to restrict its bikes and treadmills to subscription-based usage via its own servers, effectively blocking previously functional devices unless users pay.¹⁹ Although a developer successfully jailbroke the bikes to restore offline functionality, he cannot legally share the workaround due to DMCA restrictions. Cases like this highlight a growing concern in the U.S. as well: users may own their hardware, but control over the software increasingly remains with the vendor.²⁰ Another example of this conflict is visible in the case of John Deere. As the Software Freedom Conservancy (SFC) has documented, the company has repeatedly failed to comply with the GPL, despite using copyleft-licensed software in its farming equipment. Farmers are legally entitled to source code and build scripts under the license terms, but are denied access in practice.²¹ Like bootloader locking, these trends raise broader questions about software freedom and user control over the devices they own.

RED’s cybersecurity provisions and SBOM requirements

While Article 3(3)(i) awaits further action, another part of the RED has already come into force. The Delegated Act of 2022 activated Articles 3(3)(d), (e), and (f), introducing mandatory requirements for network protection, personal data safeguards, and fraud prevention in all new radio-enabled devices.²² These rules apply from August 1, 2025, and are already impacting the software supply chain. These obligations raise important compliance questions. Manufacturers must now ensure that network stacks, encryption libraries, and data-handling code meet EU standards for security and privacy. Code that may have been functionally safe yesterday might now present unacceptable regulatory risks. In practice, compliance with RED Articles 3(3)(d), (e), and (f) is operationalized through the newly harmonized EN 18031 standards, which define concrete technical requirements for network protection, data security, and fraud prevention.²³ Notably, EN 18031 requires manufacturers to document and maintain a SBOM for each device, covering both open source and commercial components. This requirement is tied directly to the lifecycle management of software vulnerabilities and secure update mechanisms. The SBOM allows for transparency, traceability, and conformity validation, particularly in the context of vulnerability disclosures and software maintenance obligations.

What can be done?

The combined effect of RED and CRA developments raise concerns about the integration of FOSS in connected devices. For manufacturers, the risks extend beyond potential license violations to include cybersecurity vulnerabilities, and legal uncertainty.

One way, manufacturers can prepare for these challenges is by maintaining an accurate and up-to-date Software Bill Of Materials (SBOM). To manage security risks and ensure regulatory compliance, manufacturers must maintain full visibility into the software components running on their devices. This is critical for identifying known vulnerabilities, assessing licensing obligations, and maintaining trust in the supply chain. SBOMs support this by providing a structured inventory of all software elements including open source and third-party components..

Both RED and CRA frameworks increasingly rely on SBOMs as a foundational compliance mechanism. As emphasized in the EU’s study on reconfigurable radio systems, manufacturers are expected to maintain transparency over all third-party components from development kits to embedded firmware to demonstrate product security and regulatory alignment over time.

At Bitsea, we support companies navigating these complexities through detailed code audits, license assessments, and software component mapping, and generate detailed SBOMs as part of our audit process.

Timeline

29th of April – 27th of Mai 2025 – The European Commission holds a Call for Evidence on Article 3(3)(i) to gather stakeholder feedback on regulatory impacts.

1st of August 2025 – The Delegated Regulation (EU) 2022/30 enters into force. All new radio-enabled devices placed on the EU market must comply with Articles 3(3)(d), (e), and (f) on cybersecurity.

Q2 2026 (planned) – The Commission is expected to adopt a Delegated Act on Article 3(3)(i), specifying more details on the provision.

Sources