The straight-and-easy path to security in your application

As the IoT proliferates, billions of cloud-connected products are expected to be designed, manufactured and deployed over the next decade. No one wants a product that is prone to hacking or theft, so security is more important than ever.

Ensuring that you have high-quality code is a mandatory step in making sure that your final product is secure. And using code analysis tools as an integrated part of your development process is a vital step. The quality of the product depends on the quality of the source code. On top, you also need to ensure that you have security from inception, so that all aspects of your development, manufacturing and update flows work together to ensure that your product is secure. Every company wants to protect their investment. This means all effort put in software design and engineering, when then becomes several months or years of development efforts needs to be protected. We are talking about the core of the company and the values.

Legislation and codes of practice

Government agencies are increasingly becoming aware of the threat posed by non-secure IoT products. Historically, IoT products have typically not included anywhere near sufficient security and thus the introduction of legislation is being driven by the industry's perceived lack of ability to self-regulate. Worldwide, the goal of authorities is to produce a new baseline security standard for companies creating IoT products to implement and hence protect end-users from cyber-criminals.

Government and industry bodies are thus now actively publishing codes of practice and other advice to assist companies in what they need to do when creating new IoT products. For instance, the "Code Of Practice for Consumer IoT Security" 1 published by the UK's Department for Digital, Culture Media and Sport provides 13 Guidelines for Consumer IoT Security, which is being used for the basis for much of the legislation being drawn up around the globe.

Another example is the “Consumer IoT Security Quick Guides” 2 released by the IoT Security Foundation (IoTSF). These guides are intended to help global organizations to better understand and comply with the various new international standards, regulations and national guidance on consumer IoT security.

But we are also no longer at the point where legislation “with teeth” will come - it is already here: in California and Oregon in the US, as well as the EU and UK, with many APAC countries not far behind.  Gartner's recent prediction that “75% of CEOs Will be Personally Liable for Cyber-Physical Security Incidents by 2024” 3 is likely to help further focus the minds of many companies on the level of the security they need to rapidly put into place in their IoT products.

IP theft is a major concern

So taking a step back from guidelines and legislation, there are several other important drivers for wanting to increase the level of security in your IoT product. Back in September 2019, we asked our customers what their number one security concern was and here is what they said:

What is your number 1 security concern

Figure 1: What is your number 1 security concern?

So obviously meeting legislative requirements is on there. But the biggest concern for our customers was intellectual property (IP) theft, followed by hacking devices and installation of malware as you can see in the graphics. So if we consider IP theft a little more, a major part of the cost of producing a typical IoT product will be the investment that goes into the design, production and testing of the software that drives the functionality of your device.

Therefore, an important part of adding security to your product should be including some form of “IP protection”. This should protect your software from unauthorized access by hackers or competitors and prevent your software from being stolen during production or once your devices are in the field. There are many reasons why your IP might be stolen, for example, a competitor who wants to reverse engineer your software. Another is a fraudulent manufacturer producing clones of your IoT product for the grey market, quite possibly costing you money in lost sales, as well as potentially affecting the reputation of your company.

When to add security?

If we consider a typical development into manufacturing flow, it might look something like:

Traditional Software Development flow

Figure 2: A traditional software development flow

Now theoretically, you could leave security as a “bolt-on” to be done at the end of your development with code analysis on the source code level and test cycles, just before you release your software and your device goes to manufacturing. But this approach is not a good idea! It often means that you will not be testing the system as it will be deployed into the field and it also means that it is more likely that security holes will be left that can be exploited after your product is released.

Security baked into your product

It is much better to include security right from the inception of your project so that it is baked into your product. Ideally, you can then have security fully integrated into your development tools and their workflow, meaning that you can be developing and testing with security measures already integrated into your product – greatly reducing the risk once your product reaches end-users.

The basis of a secure IoT product is the implementation of a Root of Trust (RoT). This is generally the minimal set of software, hardware and data that you can trust. On the hardware side, the MCU being used needs to have the ability to disable debug (at time of production), have the capability of locking the memory, and providing a unique identity. On the software side, a secure boot manager builds upon the underlying MCU hardware capabilities to provide a robust root of trust for a device, securing the overall boot process, protecting the device against the injection of malicious software and enabling and protecting a secure update mechanism.

Adding in security data, such as Public Key Infrastructure (PKI) keys and certificates, provides the MCU system with its security context profile which should be provisioned into each device. This can all be made straightforward by using a development tool that can create and configure the elements of the security context using its knowledge of the capabilities of the MCU device being targeted.

Once the MCU is provisioned with its security context, the main development team can get on with developing the reliable and high quality code from the main user application. If knowledge of security is built into the development tools being used, then the workflow being followed by the engineers carrying out this development work should be mainly unchanged from that which would be followed for a system without security. And this should help to ensure that development and testing timescales remain unaffected.

Security Software Development flow

Figure 3: Software development flow with security

Once development of the future proof code and test are complete, the final production security context and encrypted application will need to be delivered to your secure programming facility, or for small runs perhaps using a secure desktop programming system. But again the tools and facilities being used here are key to ensuring that your IoT product stays secure.


Security for connected devices is more important than ever. The threats are real – incidents of attacks, counterfeiting and cloning are growing, and governments are getting involved with legislation and policies. The ramifications could break companies that are not prepared.

High-quality code analysis tools combined with the use of coding standards are designed to promote secure coding practices. By building on top of code quality, the available security measures, such as encrypting the codebase and setting manufacturing limits, will substantially reduce this risk of counterfeiting and cloning during production aside of the security legislation compliance. IoT security needs to be straightforward, scalable and sustainable, and security must be integrated from inception, because adding security late in the development process rarely works.

Written by Andy Beeson, Senior Product Manager, Secure Thingz / Senior Product Manager, Embedded Security Solutions, IAR Systems




Det här innehållet finns tyvärr inte på svenska.

Vår webbplats finns främst på vårt koncernspråk engelska, förutom det innehåll för investerare som vi är lagstadgade att kommunicera på svenska. Vi rekommenderar att du besöker vår globala webbplats på engelska för att få en bättre upplevelse.

Vi stöder inte längre Internet Explorer. För att få bästa möjliga upplevelse av rekommenderar vi att du uppgraderar till en modern webbläsare som Chrome eller Edge.