When designing Zero Trust IoT authentication, many security teams overlook a key factor: identity.
“Never trust, always verify” sounds great. But what exactly are you verifying?
In many IoT deployments, the answer is weaker than expected. Certificates are stored in firmware, private keys in flash memory, and identities can be copied if someone has physical access. This is the main weakness in the Zero Trust model.
The SIM solves this problem. Modern eUICCs are tamper-resistant secure elements that can generate and protect cryptographic keys. Technologies like GSMA’s IoT SAFE make these features easier to use, but the main idea goes beyond any one standard. The SIM can serve as a hardware root of trust that you own.
And ownership matters. Because Zero Trust isn’t really about verifying credentials. It’s about verifying identities you actually control.
The Problem with Certificate-Based Auth at IoT Scale
Certificates are excellent for the environments they were designed for: browsers, servers, cloud workloads, and managed laptops. IoT is different.
The model assumes reliable connectivity, managed devices, and private keys in protected storage. Most IoT deployments lack these luxuries.
Consider the private key first. A certificate is only as secure as where its private key is stored. On many IoT devices, this means firmware or an external flash chip. If someone can physically access the device or its image, they might be able to extract the key.
If a private key is leaked, it is not like a password you can simply reset. It becomes a valid, cloneable identity. To your Zero Trust policy engine, the attacker now appears as the device itself.
Then there’s the operational reality. Giving each device a unique certificate, rotating it before expiry, and revoking it if compromised might work for a small number of devices. But with hundreds of thousands deployed worldwide, many battery-powered, intermittently connected, and physically inaccessible, it becomes an operational burden most teams stop maintaining. The result is fleets running on certificates that are provisioned once and then forgotten.
Certificate-based authentication does not fail because of weak cryptography. It fails because its foundation is not strong.
What “root of trust” means in practice
Every trust decision ultimately depends on something you don’t verify. That’s the root of trust.
Every TLS session, policy check, authorization, and access control relies on one thing: that the underlying identity is genuine. If someone can copy or extract that identity, Zero Trust becomes meaningless. You end up verifying credentials that attackers can also use.
Zero Trust frameworks are not the issue. NIST SP 800-207 gets the architecture right. Trust nothing by default, authenticate all the time, and evaluate each request based on identity and context. However, the framework does not specify where the identity should be stored.
For users, the answer is clear. Laptops use Trusted Platform Modules (TPMs), and phones have secure enclaves. But with IoT devices, things become complicated.
Most deployments meet the framework requirements on paper but rely on firmware certificates for identity, which can be copied or extracted. The architecture may look solid, but its foundation is weak. You can follow the rules and still be at risk. A true root of trust must have a few essential properties:
- Tamper-resistant hardware.
- Non-exportable keys.
- Unique identity per device.
- Protection that survives an operating system compromise.
The question isn’t whether you’re “doing Zero Trust.” It’s whether the thing sitting underneath your trust chain is hardware or hope.
SIM as hardware-bound identity
Here’s what the industry keeps overlooking: the most widely deployed tamper-resistant secure element is already inside the device. It’s the SIM.
Modern eUICCs are certified secure elements, similar to the hardware used for payment protection. They already handle mutual authentication between the device and the network. This two-way authentication is important because it helps prevent attacks from rogue base stations and IMSI catchers. Certificate-based TLS to an application server does not provide this protection at the connectivity level.
IoT SAFE is the best-known example of extending those capabilities into application-layer authentication. The IoT SAFE applet enables key generation, protected storage, and TLS credential handling directly inside the eUICC, eliminating the need for separate security chips.
IoT SAFE is just one way to do this. The key point is not the applet but the security feature. Keys are created inside tamper-resistant hardware and never leave it. The device proves its identity using a secret even its own processor cannot access.
If a device is compromised, you can revoke its credential right away, instead of waiting for the next certificate rotation, which might never occur.
Another point the industry misses is that you cannot build Zero Trust on an identity you don’t own. If the operator owns the IMSI and cryptographic chain, your security boundary depends on theirs.
Their employees.
Their procedures.
Their incident response timelines.
With SGP.32 and an eUICC you control, you own the issuance, the key derivation, and the cryptographic chain underneath it. The same hardware root then authenticates the device across public cellular, private 5G, Wi-Fi through EAP-SIM or EAP-AKA, and satellite NTN.
One identity. One trust chain. Multiple bearers.
For Physical AI systems, connected vehicles, robots, industrial machines, and body cameras, identity is not just a security feature. It is also a safety boundary.
How Monogoto implements SASE + SIM-rooted Zero Trust
A hardware-bound identity gives you a credential you can trust. You still need a network that enforces least privilege once the credential is verified. That’s where Monogoto’s Secure Core comes in.
Monogoto uses a cloud-native packet core, so the SIM authenticates not just to a tower, but into a software-defined network managed end-to-end. Each customer receives a private APN with its own IP space, ensuring traffic does not cross between tenants. This is true micro-segmentation built into the network, not just added at the device level.
No flat networks. No default routes to the internet. No implicit trust.
Continuous monitoring adds extra protection. It can detect and contain behavioral anomalies, unusual traffic patterns, and geo-fencing violations before they turn into incidents.
Put the pieces together, and you get SASE for IoT:
- Hardware-rooted identity in the SIM.
- Policy enforcement at the core.
- Segmentation by default.
- Zero Trust connectivity across public cellular, private LTE, 5G, Wi-Fi, and satellite.
- One trust boundary from the device to the application.
The stakes rise when the device can act on its own
This topic is more important now than two years ago because much more is happening on the device itself. AI is driving real autonomy to the edge. Devices can sense their environment, make decisions, and act in the physical world without human involvement. This is the promise of Physical AI, and it changes what is at stake if a credential is compromised.
When IoT devices were just simple sensors, a stolen credential usually meant only data was at risk. But when the device is a robot, vehicle, edge AI system, or body camera, a stolen credential is much more dangerous. You are not just losing a sensor; you are losing control. As Physical AI advances, its identity becomes even more valuable to attackers.
This is why it is important to get it right from the start: you cannot add a hardware root of trust to a million devices already deployed. Even the most advanced AI model relying on a weak credential is simply a more sophisticated thing to hijack.
5 questions to ask your IoT security vendor
If you are choosing connectivity or security partners for your device fleet, these five questions will help you tell the difference between marketing claims and real root of trust architecture:
- Where does the private key live? Firmware and external flash are extractable. A tamper-resistant secure element is not. This single answer tells you most of what you need to know.
- Who owns the device identity? You can’t enforce Zero Trust on a credential whose keys and revocation sit inside someone else’s security boundary.
- Does one identity work across cellular, Wi-Fi, private 5G, and satellite, or do you re-provision per bearer? Fragmented identity is fragmented trust, and a re-provisioning step is an attack surface.
- How quickly can a compromised device be revoked? “Instantly, from the platform” and “next certificate-rotation cycle” are very different answers when a device is actively misbehaving.
- Is segmentation enforced in the network or only on the device? Per-tenant isolation and least-privilege policy in the core survive a device compromise. Device-side controls don’t.
Zero Trust Starts with Identity
Zero Trust is not just a dashboard, a certificate authority, or something you add after deployment. At its core, it is an identity problem.
The real question is not whether you are following Zero Trust principles, but what forms the base of your trust chain. If your foundation is a certificate stored in firmware, you are relying on software to protect software. If you use a hardware-bound identity inside a secure element you control, everything above it has a solid base.
The SIM is already the most widely used hardware root of trust in the world. It is already inside devices, tamper-resistant, and performing mutual authentication. The industry simply has not been viewing it this way.
