Device identity and authentication

Key takeaways

Every connected device that sends data to the cloud is making a claim: "I am who I say I am, and you should trust this data." But how does your backend actually verify that claim? By the end of this page you will understand how IoT devices establish and prove their identity, and why getting this right is one of the most critical decisions in designing a cellular IoT system.

What you'll learn

Why device identity matters before your system acts on data

Before your platform acts on a reading, it needs to answer three questions: Is this device real, or is someone impersonating a device in your fleet? Is this device authorized to send data to this endpoint? Has this message been tampered with in transit? Device identity is the foundation that lets you answer all three. Without a verifiable, unique identity for each device, you cannot build a trustworthy system.

How the SIM anchors device identity in cellular IoT

In cellular IoT, device identity starts with the SIM. Every SIM, whether a removable card, a soldered MFF2 chip, or an integrated iSIM, contains a unique identifier called the IMSI (International Mobile Subscriber Identity) and a secret key called the Ki. These values are provisioned during manufacturing and are used by the cellular network to authenticate the device before it is granted network access.

How SIM-based authentication (AKA) verifies a device on the network

The cellular network uses a protocol called AKA, Authentication and Key Agreement, to verify a device. At a high level:

• The device sends its IMSI to the network.
• The network looks up the corresponding Ki in its authentication database.
• The network sends a random challenge to the device.
• Both the device and the network independently compute a response using the Ki and the challenge.
• If the responses match, the device is authenticated.

The critical point is that the Ki never leaves the SIM. It is computed on-chip, so even if someone intercepts the radio communication they cannot extract the secret key. This is hardware-based security at its most fundamental level. Using a soldered SIM in MFF2 form factor also removes the SIM slot as a physical attack vector, so an attacker cannot simply pull the card out and clone it.

How certificate-based mutual TLS (mTLS) authenticates a device to the cloud

SIM-based authentication gets your device onto the cellular network, but authenticating to your cloud platform is a separate problem, most commonly solved with mutual TLS (mTLS). In standard TLS (Transport Layer Security), only the server proves its identity to the client. In mutual TLS the authentication goes both ways: the device also presents a certificate, and both sides verify each other before any data is exchanged. Each device is provisioned with:

• A client certificate: A signed document that proves the device's identity.
• A private key: Stored securely on the device, used to prove it owns the certificate.
• A CA (Certificate Authority) certificate: Used to verify the server's identity.

Server-only authentication is insufficient for IoT because devices often operate in physically accessible environments where an attacker could set up a rogue endpoint.

When token-based authentication is the right fit

For simpler deployments or devices with limited processing power, token-based authentication is an alternative. The device authenticates using a pre-shared API key or a signed JSON Web Token (JWT). The trade-offs:

• API keys are static. If compromised, they must be rotated across the fleet.
• JWTs can include expiration times and claims, making them more flexible.
• Neither provides the same cryptographic assurance as mTLS.

In practice, many systems use a hybrid approach: SIM-based authentication for network access, and mTLS or token-based authentication for cloud communication.

Why a Hardware Root of Trust protects your keys

Whichever mechanism you choose, the security of the whole system depends on how well you protect the cryptographic keys. A Hardware Root of Trust is dedicated hardware that stores keys in isolated, protected memory. Store keys in hardware-isolated storage, not plain flash. Options include:

• ARM TrustZone: A hardware isolation feature built into many modern MCUs (like the nRF9160) that creates a secure execution environment.
• Dedicated secure elements: Separate chips designed for cryptographic operations and key storage.
• The SIM/eUICC itself which already functions as a secure element for cellular credentials.

Lesson 6.1 Self-assessment

Frequently asked questions