The search for a universal IoT security standard - Embedded.com

The search for a universal IoT security standard

“Why isn’t there a universal security standard for IoT?” It’s a pretty common question that our IoT solutions group hears quite a bit from IoT developers, decision makers and expert researchers alike, regardless of the level of expertise they have on the topic. And it’s a fair one, after all, there are standards for just about any technology environment out there, so why not IoT?

The easy answer is that IoT is too diverse to have a set standard. Although true, that doesn’t adequately explain the topic with the level of subtle detail that is warranted. We’ve found that there are at least three influencing factors that impact universal IoT standards: device heterogeneity, vertical specific standards, and emerging architectural concepts. Let’s look at each.

Heterogenous nature of IoT devices

IoT devices are diverse. While most people think of an IoT device as something they can see, touch and interact with such as a smart phone, they are in fact, so much more. Quite often they have no human interaction at all. They are sensors that interact with their environment to report temperature in controlled environments, convey when a door is open or shut in a remote facility, or inform about the on/off status of a light switch in a smart building. They are gateways that secure the communication pathways transferring data from an end point to the cloud or actuators that turn off those lights when no one is present. They are also critical infrastructure operations that power energy delivery, maintain manufacturing environments or serve telecommunication hubs.

There are countless types of IoT devices and how each is used inside its environment – its use case – is also unique. Each has different technical capabilities and can potentially be integrated with a number of IoT platforms. IoT environments and devices are sometimes limited in bandwidth or limited in device capacity (battery, storage, compute).  IoT device platforms also have tremendous diversity in their software platforms, as compared to desktop computing. In desktop computing you’re talking about only a handful of operating systems (OSs), whereas on the device side the number of embedded systems is much larger given the custom nature of many platforms.

Finding common standards among so much diversity is a challenge and hinders the development of universal IoT standards.

Industry leads with vertical specific standards

Despite the myriad of devices and their wide array of use cases, industry verticals are collaborating to create use case specific IoT security and connectivity standards. There are standards being proposed out there.

Sometimes those standards evolve over time. We can see that evolution if we look at PKI-based deployments within IoT and compare it to how PKI has been standardized within the web PKI world today. In web PKI we have public Certificate Authorities (CAs), the Certificate Authority/Browser (CA/B) Forum, and the web browsers themselves. There is an established and traditional use case way of securing web servers. That’s a well-accepted standard and standard use case for PKI where the CA/B Forum baseline requirements guide that. The need for a standard by browsers is driven by an open ecosystem of clients out in the environment – all of the web browsers and users need to connect to an open and broad set of servers.

As we consider PKI for IoT ecosystems, some of that changes. Whereas web PKI uses primarily public trust models, PKI for IoT tends to use more closed, private ecosystems.  In IoT ecosystems right now, the trust models in many of these ecosystems are much more closed in trust since it’s still so early in its deployment stage. Generally, an OEM will provide the entire stack from the device up to the cloud. They’re going to run the cloud or more likely, partner with someone to run the cloud, like Microsoft or Amazon. These ecosystem trust models are currently closed and siloed.

That configuration is still developing. We’re seeing evolutions of identity standards and IoT identity standards in more vertical specific ecosystems. For instance, we see standards emerging with groups that we’re members of like the Wi-SUN Alliance, an organization that drives the adoption of Interoperable Smart Ubiquitous Networks, and LXI Consortium (LAN eXtensions for Instrumentation), a group of top international test and measurement companies collaborating to develop and steer the communications standard for test and measurement instrumentation.

There are lots of other examples of these industry specific use cases that are driving consistency within their own domains, like in automotive or consumer home. This is something that we predicted would happen and something we considered when we started getting into the IoT space. We knew that we would see an initial divergence from where identity models are deployed in the web today. That it would move to closed ecosystems and then start growing into semi-private or semi-public ecosystems, and eventually grow into something that is broader and more equivalent as a general authentication or identity standard for those ecosystems. Industry verticals are helping to establish baseline standards that will likely emerge as broader standards as IoT matures.

Emerging architectural concepts

Every IoT vertical and use case has different architectural patterns. We are, however, seeing some commonality emerge there as well, which has materialized from the IEEE 802.1 AR specification and is finding traction in IoT ecosystems. It is around the broad and general conceptual components of an IDevID and LDevID.  These are applied in architectural concepts that are a bit more use case agnostic or vertical agnostic. 

An IDevID (initial device identity) is typically long lived, and ideally protected by secure hardware, and representative of the device’s core identity, like a birth certificate. An LDevID (local device identity), is a locally significant, access level certificate that is shorter duration and provides access into the environment, which could be considered akin to a driver’s license.  

This is one of the more vertical agnostic architectural identity patterns that we have used with several of our existing customers. It takes careful consideration of your supply chain to implement. First, we consider where and how the IDevIDs are securely provisioned into that device or component or chipset – at whatever level of the device platform that you want to conceive it at, as well as at what stage of the manufacturing process. Next, we consider how to potentially leverage some of those IDevID trust attributes that were ideally provisioned securely during the manufacturing into a locally significant, operational LDevID that can be used for allowing the device to connect and operate into the IoT ecosystem.  These LDevIDs are generally rotated more frequently through the device lifecycle.

This IDevID/LDevID pattern is one of those architectural identity blueprints that PKI is starting to lean on in IoT, and we’re using some of these concepts to protect devices and supply chains from emerging threats.

So, the answer to the question of “Why isn’t there a universal security standard for IoT?” is a bit nebulous and deserves more than a one-line reply. Not only is IoT too diverse to have one single standard, although that is one legitimate explanation, but it is also still emerging, growing and finding the common threads that may eventually lead to something more homogenous.


Lancen LaChance is vice president of product management, IoT solutions, and is responsible for driving overall IoT product strategy, partnerships and roadmap at GlobalSign. He joined the company in 2010 as a senior systems engineer. Prior to GlobalSign, he was an IT systems analyst for BAE Systems. He is actively involved in several IoT industry groups including the Industrial Internet Consortium.

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.