Beyond the Device Key: Secure Identity and Trusted Access for IoT

Cloud services for IoT are commonly built around a central message broker in a star-like topology. Devices, mobile applications and other clients connect to the broker and authenticate with an API key, password or certificate. The broker then applies an access-control list (ACL) to decide which clients may publish to, or subscribe to, particular topics. A device may therefore be permitted to publish its sensor readings, while a user or application is permitted to subscribe to those readings or publish commands to the device.

The industry standard Transport Layer Security (TLS) protects the individual connections between each client and the broker. This is valuable: it protects messages in transit and allows the broker to authenticate its connections. But TLS terminates at the broker. The broker receives, processes and forwards the messages, and the broker’s ACL is what enforces the relationships between publishers and subscribers.

That creates a central trust boundary. The participants generally do not authenticate one another directly, nor can they independently verify that a message was produced by the claimed device or intended for the claimed recipient. They trust the broker to authenticate clients, enforce its ACL, preserve message confidentiality and route messages correctly. In effect, the broker becomes the trusted authority for the entire communication relationship. Even when the clients use mutual TLS, each client is primarily proving its identity to the broker; the subscriber is not necessarily verifying the publisher directly. Unless the payload is additionally signed or encrypted at the application layer, the broker remains able to inspect, alter, suppress or replay messages within the permissions granted by its ACL.

A common design is straightforward: the device stores a private key, proves possession of that key to a cloud service, and receives commands from an application or backend.

This model is a normal and useful way to implement distributed IoT systems. However, users of connected systems also need to answer a second question:

Which people, devices or software agents are allowed to use it, and what are they allowed to do?

The conventional device-key model

In a typical IoT deployment, each device receives a private key during manufacturing, installation or activation. Its corresponding public key, certificate or identity is registered with a cloud service or management platform.

During a connection, the device proves that it possesses the private key. This prevents an attacker from simply copying a public identifier and pretending to be the device. When the private key is protected by a secure element or hardware security module, it can also be made difficult to extract and clone.

This is the foundation of secure device identity and mutually authenticated communication. It is especially useful for device-to-cloud and machine-to-machine connections.

But the device key normally identifies the device itself to the cloud service. It does not, by itself, provide a complete answer for human or application end-to-end access. In practice, that additional layer may depend on a password, a shared administrator credential, a preconfigured mobile application, or a central service that maintains the access relationship.

What our approach adds

In our technology, the IoT device holds its own asymmetric key pair. The device can create or assign this identity when it is initialized, and use its private key to authenticate itself. In that respect, we are not offering a replacement for device keys.

The distinctive idea is that all system participants can create their own asymmetric key pairs and use them to build direct, one-to-one trust relationships. The message broker can still be used as a transport and discovery service, but it no longer has to be the sole source of trust. A recipient can verify a message or command using the sender’s public key, regardless of whether the message was delivered through a broker, a gateway or a direct connection.

The basic flow is:

1. The IoT device creates or assigns its own public/private key pair.
2. A user discovers the device, for example through a QR code, NFC, Bluetooth, a local network mechanism or another resource identifier.
3. The user device obtains executable code and uses it to create or access its own cryptographic identity.
4. The user device sends its public key and related contact information to the IoT device.
5. The IoT device authenticates the user device using public-key cryptography, potentially through challenge-response.
6. The IoT device checks whether an administrator has already been established and then grants, rejects or delegates access accordingly.

When using asymmetric keys for authentication, the private key belonging to the user device is never sent to the IoT device. The user device proves possession of it by signing a challenge, while the IoT device verifies that signature with the corresponding public key.

From device authentication to trusted access

This creates two separate cryptographic relationships:

IoT device private key  →  proves the identity of the IoT device
User device private key →  proves the identity of the user device

The IoT device can then associate the user device’s public key with an access decision. On first use, the first authorized connection can become the administrator. Once an administrator exists, later requests can be declined, referred to the administrator, or assigned a role with a defined level of access.

That is a meaningful change in the trust model. Access is no longer based on one shared secret that every operator or application must know. Each authorized phone, computer, vehicle or hardware token can have its own cryptographic identity and its own access relationship with the target device.

The approach also supports a bearer device, such as a smart card, SIM, hardware wallet or secure element, that performs cryptographic operations without exposing the private key. This allows the user identity to travel with a protected credential while the user interface can be provided by a different computing device.

Why first-use commissioning matters

IoT devices are often deployed in environments where it is impractical to preload every possible user, application or network configuration. A device may be installed in a home, factory, vehicle, parking facility or remote industrial location and need to be claimed by its operator.

We offer a model in which the user device obtains the required code at the time of connection. Discovery information can be supplied by the device itself or by a QR code, NFC tag, Bluetooth beacon, online service or other channel. This reduces the need for a device-specific application to be installed in advance and supports commissioning through ordinary user equipment.

The result is a compact onboarding pattern:

Discover device → obtain code → present user public key
       → authenticate → establish administrator or role

For low-resource devices, this separates the user experience from the embedded device software. The target device still performs the essential cryptographic verification and access decision, while the user-side code can be adapted to the phone, computer or other device being used.

What this does—and does not—solve

The approach strengthens the relationship between identity and authorization. It can reduce password exposure, avoid shared administrator credentials and make it possible to distinguish one authorized user device from another. Optional signed attestations can also associate a public key with claims from an external organization.

It does not mean that public-key cryptography automatically makes every deployment secure. The IoT private key still needs appropriate protection. The user-side private key must also be protected, and executable code obtained through a discovery mechanism must be authenticated and delivered through a trustworthy path. Revocation, recovery and administrator replacement remain important operational requirements.

The technology is best understood as an access architecture built on top of secure identity:

Secure identity → authenticated participant → trusted access decision

That is the connection between ControlThings’ Secure Identity and Trusted Access capabilities. A device key establishes who the device is. Per-user public-key identities and explicit access decisions establish who may use it. Together, they provide a foundation for connected systems in which devices can authenticate both their peers and the parties controlling them.

For reference

US 11,184,181 B2 System for assigning access rights to user device and method thereof.

View patent →