Operating radio equipment in compliant modes is a reasonable thing to do. WiFi and GSM jammers are excellent examples of what might happen if radio equipment is not operated in compliant modes, rendering communication (based on GSM or WiFi in this case) impossible in a certain radius. Things can get even more delicate if GSM baseband firmware is modified so that it violates the GSM protocol in ways that allow for Denial of Service attacks on cell phone towers. Back in 2009, this was one of Apple’s claims on why it would need to take actions against jailbreaking iPhones (1), with a jailbreak being mandatory if users wanted to remove the built-in provider-lock. This unlock, in fact, tinkered with the baseband.
Of course, not all variants of non-compliant radio equipment operation have such drastic impact. Non-compliant behavior might as well “only” have legal implications and not impact security or service availability at all.

To exacerbate abusive behavior of radio equipment, in April 2014 the European Parliament and the Council agreed on a new “directive on the harmonization of the laws of the member states relating to the making available on the market of radio equipment” (2). On June 12th, 2017, member states will have to report on how this directive has been applied on a national level. At its core, it aims at securing radio equipment so that devices can only be operated in intended specified ways that have proven to be compliant. Manufacturers will be held responsible for ensuring, that only such software can be loaded into the radio equipment where the compliance of the combination of the radio equipment and software has been demonstrated (see article 3(3)(i)).

Nevertheless, the additional burden placed upon manufacturers to ensure that only compliant software can be loaded comes with implications. Concerns have been expressed, whether this is the end to community run projects like OpenWRT or LineageOS for example, which provide alternative open-source software for off-the-shelf hardware and are rendered useless if not able to operate radio equipment because it has been locked down by manufacturers.
Self determination and the prolongation of a device’s life cycle through provisioning of up-to-date software are not the only reasons why users might opt for alternative software. It has also proven to be attractive from a security perspective.

Every piece of software comes with product-specific implementation-related vulnerabilities (e.g. Netgear and Belkin firmwares), some of which take years to be detected and even more to be closed (e.g. CVE-2014-1635). In addition, it (i.e. the software) might suffer from vulnerabilities inherent to libraries, which are frequently used and affect millions of different products at once (e.g. OpenSSL). This is just as true for alternative software, as it is for stock software. Such vulnerabilities need to be fixed as soon as possible after their detection, which might occur more frequently than expected (again referring to OpenSSL). Depending on whether the vulnerability was found in the manufacturer’s code or an external library, manufacturers have to put considerable effort into fixing the code and have a new firmware built, tested and released. This might cause delay in provisioning of updates (see above), if provided at all, since the respective product might as well be end-of-life. In contrast, alternative open source software can easily be augmented with patches, though provided in a best-effort fashion without any liability. The example of Android shows that devices with out-dated software can account for a large proportion of the market (3) partly due to reluctant provisioning of updates (4). At the same time Android accounted for the most CVEs in 2016 (5), implicating that security updates are of utmost importance.

Still, claiming that directive 2014/53/EU will ultimately lock-out all other software is not necessarily correct, at least not yet. Depending on whether there will be any exceptions to the so far very general directive, that comprises all radio technology, be it transmitters or receivers, this whole matter might deescalate quickly. Additionally, depending on how much effort manufacturers and community projects are willing to put into it, solutions are available. It is not yet clear how compliance is supposed to be demonstrated and what requirements have to be fulfilled, so what sounds like a costly process might turn out to be feasible for cooperating manufacturers and community projects. Another, probably more advanced but also complex approach is to design and develop firmware and driver so that they provide an abstract interface to any kind of software running on the device as it is commonly done in virtualization. This way compatibility would be maintained and cost due to repetitive assessment reduced. On the other hand this approach might introduce entirely new vulnerabilities, as is often the case when complexity increases.