At a Glance
- mTLS (mutual TLS) requires both the IoT device and the server to prove their identity with X.509 certificates; standard TLS only proves the server’s identity.
- mTLSreplaces IP addresses with cryptographic identity, which is what makes it scale across thousands (or millions) of distributed devices.
- Paired with a Zero Trust overlay network, mTLS lets you close every inbound port on your IoT servers while authenticated devices still connect.
- NetFoundry uses mTLS as the identity layer for our OpenZiti-based Zero Trust IIoT connectivity, proven at scale across hundreds of millions of authenticated sessions.
Somewhere right now, a fleet of sensors on a factory floor, a set of smart meters in the field, and a bank of medical devices in a hospital are all trying to prove that they are who they say they are…and failing at it. Global IoT connections are on track to hit roughly 21.9 billion by the end of 2026, and every one of those devices is a potential front door for an attacker if authentication is an afterthought.
Passwords don’t scale to that number of endpoints. Static IP allowlists don’t survive a device refresh cycle. And “trust anything that can reach the port” is how IoT became a punchline in security conferences.
Mutual TLS (mTLS) is the fix most serious IoT deployments land on. But before we get into how to implement it, it’s worth settling exactly what mTLS is and isn’t, because a lot of the confusion around IoT security starts here.
What Is mTLS, and How Is It Different from Regular TLS?
Mutual TLS is an authentication method where both sides of a connection present and verify a digital certificate before any data moves — the device proves its identity to the server, and the server proves its identity to the device. At NetFoundry, we treat mTLS as a baseline identity requirement for IoT connectivity, not an optional hardening step.
Standard TLS (the padlock in your browser) only goes one direction. When you visit a website, the server proves who it is with a certificate; you, the client, prove nothing. That’s fine for browsing — the server doesn’t need to know your identity to show you a page. It’s not fine for an IoT server that’s about to accept commands or ingest sensor data from a device it has never verified.
Think of standard TLS as a bouncer who checks the venue’s liquor license but never looks at your ID. mTLS is like the bouncer checking your ID — and you get to check theirs, too.
Why IoT Authentication Breaks Down at Scale
The challenges of IoT authentication are important to understand, because they’re the reason most projects stall out once a pilot moves to production.
- Scalability: Provisioning and rotating credentials for a few hundred pilot devices is manageable. Doing it for tens of thousands of field-deployed devices, with no manual touch, is a different engineering problem entirely.
- Device heterogeneity: IoT fleets mix microcontrollers, gateways, and full Linux boxes across multiple vendors and OS versions, which makes a single, unified authentication approach hard to standardize.
- Interoperability: Without a common protocol and certificate standard, authentication ends up bolted on differently by every vendor in the stack.
- Credential security: Passwords, API keys, and shared secrets stored on resource-constrained devices are easy to extract and easy to reuse once stolen.
- Unreliable connectivity: Field devices drop on and off cellular or satellite links constantly, which breaks authentication schemes that assume a stable, always-on session.
Solving all five issues at once takes lightweight cryptography, an identity and access management (IAM) approach built for machines rather than humans, and a connectivity layer that can re-authenticate a device the instant it reconnects. That combination is exactly what mTLS inside a Zero Trust IIoT architecture is built to deliver.
How mTLS Authentication Works, Step by Step
Under the hood, mTLS extends the standard TLS handshake with an extra round of certificate verification. Here’s the sequence:
- Device initiates the connection. The IoT device opens a connection to the server (in a Zero Trust architecture, this is always an outbound-only connection — the server never has to accept unsolicited inbound traffic).
- Server presents its certificate. The server sends its X.509 certificate, proving its identity to the device.
- Device verifies the server and challenges for proof of possession. The device checks the server’s certificate against a trusted Certificate Authority (CA) then confirms the server actually holds the matching private key before the session is authorized.
- Server requests a client certificate. This is the “mutual” part; the server asks the device to prove its own identity in return.
- Device presents its certificate. The device sends its own X.509 certificate.
- Server verifies the device and challenges for proof of possession. The server validates the device’s certificate against the CA, then confirms the device actually holds the matching private key before the session is authorized.
mTLS vs. TLS-Only, VPNs, and Firewall ACLs for IoT
None of these approaches are universally wrong. The right choice depends on how many devices you’re managing, how sensitive the data is, and how often your fleet changes.
mTLS vs. TLS-Only
If you can explicitly trust any device capable of reaching your server, and the data involved isn’t sensitive or valuable, TLS-only may be enough. But once you’re dealing with data worth attacking — patient telemetry, industrial control commands, financial transactions — mTLS becomes the default most security teams land on, provided the certificate and PKI management overhead is handled for them rather than by them.
mTLS vs. VPN or Private Mobile APN
VPNs and private APNs work reasonably well for a small, static number of sites. But they struggle once you’re managing thousands of endpoints, because every new site is another tunnel to provision and every topology change is a network re-design. mTLS paired with dynamic routing lets a single IoT gateway send and receive data from any number of authorized endpoints simultaneously, without backhauling everything through one central tunnel.
mTLS vs. Firewall ACLs
IP-based allowlists are a common stopgap for teams that want to protect an IoT server without standing up mTLS PKI. They hold up fine for a small, static set of endpoints with fixed public IPs. But they break down fast with overlapping private IP ranges, dynamic addressing, and port-forwarding requirements — and an IP address is a much weaker identity signal than a cryptographic certificate to begin with.
Architecture: mTLS Inside a Zero Trust Overlay Network
mTLS on its own authenticates a single connection, but it doesn’t make your server invisible to the network. Pair it with a Zero Trust overlay fabric, and the picture changes:
- The IoT device and the IoT server both connect outbound only to the private overlay fabric — no inbound firewall ports are opened on either side.
- The fabric authenticates both endpoints via mTLS before any session is established.
- Once authenticated, policy — not IP address — determines exactly which service each device is authorized to reach.
- The IoT server is never directly reachable from the public internet. It has no listening port for an attacker to find, scan, or exploit.
NetFoundry’s Zero Trust IIoT solution applies mTLS with the same Ziti fabric used across NetFoundry’s API, app-embedded, and IT remote access solutions, available for both self-hosted OpenZiti and managed NetFoundry Cloud deployments. The same identity-first model now secures a very different category of machine endpoint — AI agents and MCP servers — which is worth knowing if IoT isn’t the only machine-to-machine traffic your team is responsible for securing.
Implementing mTLS for IoT with OpenZiti
In an OpenZiti-based deployment, provisioning a new device identity and authorizing it to reach a specific service looks like this:
# 1. Create an identity for the IoT device in the Ziti network
ziti edge create identity device “sensor-floor2-001” -o sensor-floor2-001.jwt
# 2. Enroll the device using its one-time JWT
# (this generates the device’s X.509 certificate and private key)
ziti edge enroll sensor-floor2-001.jwt
# 3. Authorize the device to reach only the service it needs
ziti edge create service-policy “sensor-floor2-dial” Dial \
–identity-roles “@sensor-floor2-001” \
–service-roles “@iot-ingestion-service”
You (or NetFoundry, if you’d rather not run your own PKI) can also add your own Certificate Authority to the chain of trust, so device identity ties back into an existing enterprise CA rather than living in a silo.
Is mTLS the Silver Bullet for IoT Security?
No — and treating it as one is its own risk. The first question is always whether you need to secure IoT servers from network exposure at all. If you do, mTLS is one critical layer, not the whole architecture. But when combined with a Zero Trust overlay that keeps those servers unreachable until identity and policy authorize a connection, mTLS moves from “nice to have” to the backbone of how machine identity works at scale.
If your team is managing IoT authentication device by device, or backhauling everything through a VPN concentrator that wasn’t built for this many endpoints, NetFoundry’s Zero Trust IIoT solution is built to take that off your plate — with the same Identity-First Reachability™ model we use across APIs, AI agents, and site-to-site connectivity.
Talk to our team about what an mTLS-secured IIoT rollout would look like for your fleet.
Frequently asked questions
What is mTLS in IoT authentication?
Mutual TLS (mTLS) is an authentication method where both the IoT device and the server it’s connecting to verify each other’s identity using digital certificates, rather than the server alone proving its identity as in standard TLS. At NetFoundry, we use mTLS as the identity layer inside a Zero Trust overlay so IoT servers never have to open an inbound port to accept a device connection.
Is mTLS the same thing as TLS?
No. Standard TLS is one-directional — only the server proves its identity to the client, the way a website proves it’s legitimate to your browser. mTLS adds a second, reciprocal check: the client (in this case, the IoT device) must also present a certificate the server can verify before the connection is allowed.
Does mTLS work over unreliable or intermittent IoT network connections?
Yes. Because the certificate exchange happens fresh at the start of each session, a device that drops off a cellular or satellite link simply re-authenticates when it reconnects — there’s no persistent session state to lose or recover.
What’s the difference between mTLS and a VPN for securing IoT devices?
A VPN creates a tunnel between sites or networks and typically authenticates the tunnel endpoint, not each individual device behind it. mTLS authenticates each device individually via its own certificate, which scales far better across large, changing fleets and avoids backhauling all traffic through one central tunnel.
Do I need to manage my own PKI to use mTLS for IoT?
Not necessarily. Running certificate authorities, enrollment, and revocation yourself is possible but operationally heavy. Platforms like NetFoundry, built on OpenZiti, handle certificate issuance, enrollment, and lifecycle management as part of the connectivity layer, so your team doesn’t have to build a PKI practice from scratch.
