**5. Discussion**

In the current IoT security landscape, many institutions and entities are defining security requirements, but no industry-wide standard has been agreed upon. Device designers and vendors have their own proprietary solutions, which address some issues but miss the target in others. To the best of our knowledge, no solution addresses all the requirements presented in Table 1 out-of-the-box which generally leaves the solving of security problems mainly in the hands of the designing entity with the potential to create unsecured IoT devices.

Additionally, there is no industry wide standardization of the *level* of security needed, which would aid the designers of IoT devices. A different security level is required for traffic light control in a smart city than for an "intelligent" and connected toothbrush. This should also be part of the discussion and possibly even have a certification entity. Table 1 could be divided into different security levels and additionally be configurable within some of the requirements, that is, the key strength or chosen encryption algorithm should be implicitly standardized for different security needs.

Some solutions presented in Section 4 are, in theory, processor/architecture agnostic, but others like Arm TrustZone or Intel SGX are tied in with a specific architecture, which makes the security improvements dependent on the designing entity and the agility of their bug-fixing process. Additionally, the solutions in the current environment are generally divided into more hardware or software heavy, even though a combined solution of strong TEE and software process isolation with hardware cryptographic implementations and Hardware Root of Trust functionalities would seem to be the most secure. In our opinion, the discussed open-source solutions, Keystone and OpenTitan, could work together to create a highly secure prototype of a framework for IoT device protection, whilst being publicly attestable and with all the benefits of independence.

Many solutions in the present state-of-the-art fulfill a subset of secure IoT device requirements, but none adheres to all of them. No common approach is present for many application-level IoT requirements (Table 1), such as the return to a secure state, interface disabling in the SoC, automatic update by default and the logging of IoT device security events and others. This is an issue during the design of such devices and could have a real-world impact in the future. All current solutions focus on the wider trusted computing paradigm or on providing a hardware cryptographic acceleration, rather than being dedicated explicitly to IoT devices.

A comprehensive design framework is needed to assist in the design of secure IoT devices. Such a solution should take into consideration the most important security requirements shown in Section 3. We believe that it would, in a way, simplify the technology development and mitigate the problem of time-to-market/functionality trade-off in opposition to security. It should be possible to add, remove or configure IoT security on a block system level in accordance with the target application of the device.
