IoT security reviews keep failing on the same finding: device credentials that can be extracted. Keys in firmware get pulled off flash. Software keystores are only as strong as the OS around them. Dedicated secure-element chips fix the problem but add cost, board space, and a second supply chain. GSMA's IoT SAFE standard exists because there's a certified secure element already inside every cellular device — the SIM — and it defines how applications can use it.
This guide explains the standard neutrally, then gives you the questions that separate real implementations from brochureware. Yes, Telkoa sells one (SimX SAFE) — the questions below are the ones we’d want to be asked.
What IoT SAFE actually is
IoT SAFE ("IoT SIM Applet For secure End-to-end communication") is a GSMA-defined standard with a simple architecture:
An applet on the SIM/eSIM acts as a keystore and crypto engine: key generation and storage, signing, and cryptographic operations, all inside the SIM's tamper-resistant environment.
Device-side middleware bridges the applet to the device's TLS stack, so applications use SIM-held keys through standard interfaces.
Server-side components handle the cloud end of mutually authenticated sessions and credential lifecycle.
The design goal: private keys are generated and used on the SIM and never appear in device memory, firmware, or flash. Clone the firmware and you've cloned nothing.
What it's genuinely good for
Device identity that survives cloning — each device authenticates with keys physically bound to its SIM.
Device-to-cloud TLS — mutually authenticated sessions anchored in certified hardware, without a discrete secure element on the BOM.
Zero-touch onboarding — devices prove identity on first connection using pre-provisioned SIM credentials; no key ceremonies in the field.
Passing security review — a public, standardised reference model your customers' security teams can evaluate, instead of a proprietary scheme they have to trust.
HONESTY SECTIONWhat it doesn't do
IoT SAFE is a root of trust, not a security programme:
It doesn’t secure your cloud, your APIs, or your firmware update chain.
It doesn’t replace network-level security controls.
Crypto performance is SIM-class: fine for session establishment and signing, not for bulk encryption of high-throughput streams (TLS handles the bulk via session keys — that’s the design).
It requires SIM/eSIM compatibility and middleware integration work on the device side.
The questions to ask any vendor (including us)
01 · Card compatibility. Which Java Card versions and card profiles are supported? What happens with my existing fleet vs new SIMs? Ask for a compatibility assessment against your actual card profiles, not a datasheet.
02 · Credential lifecycle. How are keys provisioned at manufacture vs in the field? How do rotation and revocation work across a deployed fleet — and over what channel?
03 · Middleware reality. Which device OSes, modules, and TLS stacks does the device middleware support? How much application code changes? Ask for the integration guide, not a diagram.
04 · eSIM behaviour. What happens to credentials through eUICC profile switches and lifecycle events?
05 · Server side. Does the vendor supply the server middleware, or are you building it? How does it fit your existing PKI/CA arrangements?
06 · Operational model. Who holds which keys? Can the platform run in your cloud or on-premise? What's auditable?
07 · Proof. Ask for a live demonstration of key generation, signing, and a mutually authenticated TLS session on your target module — not a slide of one.
Where the SIM root of trust is heading
The same trust anchor that authenticates a device to your cloud is the natural anchor for the identity-class network APIs the industry is standardising. Anchoring device identity in the SIM today puts you on the right side of that direction.