Authentication in IoT (Internet of Things) is hard.
Authenticating devices and users face challenges like scalability, resource constraints, device heterogeneity, interoperability issues, credential security, unreliable network connectivity, and lifecycle management.
IOT Authentication Challenges include:
- Scalability: IoT networks often consist of a vast number of devices. Managing and authenticating each device in such a large-scale environment can be complex and resource-intensive
(Cyber Security News) . - Heterogeneity: IoT environments typically involve a wide variety of devices with different capabilities, operating systems, and communication protocols, complicating the implementation of a unified authentication system
(Cyber Security News) . - Interoperability: Ensuring seamless authentication across different platforms and ecosystems requires universally accepted and implemented standards and protocols, which is often lacking in the IoT space
(Comparitech) . - Security of Credentials: Storing and managing credentials securely on devices that may have limited security capabilities increases the risk of credential theft and unauthorized access
(Expert Insights) . - Network Connectivity: Many IoT devices operate in environments with intermittent or unreliable network connectivity, posing challenges for continuous authentication and real-time security updates
(Konverge) .
Addressing these challenges requires a combination of lightweight cryptographic techniques, secure and reliable connectivity and networking, robust identity and access management (IAM) frameworks, and industry-standard protocols tailored for the IoT landscape.
IoT Authentication using mTLS
NetFoundry solves many of these IoT challenges using Mutual TLS (mTLS) which is now globally available in our IoT remote management and networking solution. It is the same Ziti platform capability used for our API solution, app-embedded secure networking, and IT remote access solutions, so it has hundreds of millions of sessions under its belt. It is available for both OpenZiti (open source zero trust networking platform) and NetFoundry Cloud, (NetFoundry’s managed Ziti NaaS with hosted Ziti network fabric).
In this post, we take a step back to describe mTLS and the differences between TLS and mTLS. We then outline criteria by which you can determine if the mTLS option matches your IoT use case needs. We discuss how mTLS itself generally works, specifically as part of a Ziti-powered IoT zero trust overlay network.
Do you care about mTLS for IoT?
Most of us are familiar with TLS from the web. TLS tells our client/browser that the website we are visiting has proven (via a cryptographically authenticated X.509 certificate) that the web server is who it says it is. Think of this as the validation of the identity of one party.
Mutual TLS also validates the identity of the IoT client (in addition to validating the IoT server). So mTLS helps your IoT server validate that the IoT clients are who they say they are. It looks like this:
In a solution like NetFoundry’s, which combines IoT mTLS with an IoT overlay network fabric which only accepts authenticated endpoints, the net result is your IoT server no longer needs to be open to the Internet – you deny all inbound traffic (your IoT servers and clients both open outbound sessions to its private IoT overlay network fabric).
So, if you *don’t* care about IoT server security or management, then this post is probably not for you. If you *do* manage IoT servers, then this post is for you.
Is mTLS for IoT a better solution than TLS, VPN (or private mobile APN) or firewall ACLs?
Engineering answer: it depends. With that out of the way, let’s look at general guidelines for the use (or not) of mTLS in IoT.
IoT mTLS versus TLS
TLS will generally be simpler and easier, and simpler can mean more secure and scalable. If you can explicitly trust any device that can connect to your IoT server, and the data you are dealing with is not very valuable or sensitive, then TLS may be for you.
If you are concerned with attacks on your IoT server, for example, because you are dealing with sensitive or valuable data, then mutual TLS is a great solution. In fact, most IoT operators would default to mTLS in that situation, except managing certificates and PKI is often difficult and complex (which is why NetFoundry customers asked us to build it into its IoT solution). Note: we are using PKI as shorthand for the set of tools, policies, and procedures needed to mint, enroll, manage, distribute, update, and revoke digital client certificates (like X.509s).
IoT mTLS versus VPN or private mobile APN
This comparison mainly hinges on the number of sites, the amount of change, and the latency requirements. At one extreme, if you have a few sites and they are relatively static, then you can probably afford the operational overhead of VPN. Likewise, if you are okay with site #1 tunneling all of its data to site #2, then VPN backhaul may be okay for you (split tunneling can be done but is made difficult by VPN architectures).
Mutual TLS scales far better, e.g. across 10s to 1000s of sites. And, if mTLS is paired with dynamic routing (it is in the NetFoundry IoT remote management and networking solution), then one IoT endpoint or gateway can simultaneously send (or receive) data from (n) number of other endpoints (eliminate backhaul). This is important for IoT deployments that need latency reduction (avoid VPN or private APN backhaul), or cost reduction (avoid backhauling all data to one cloud and then paying extra cloud egress costs to get the data to where it actually needs to go). Note: Private mobile APNs and VPNs are essentially the same in the context of this conversation – both result in a default single tunnel backhaul VPN to one site.
IoT mTLS versus firewall ACLs
IP-address-based ACLs have become somewhat of a default solution for folks who want to protect their API servers but don’t want to implement mTLS (prior to the availability of solutions like the NetFoundry solution, which provides the IoT mTLS PKI). ACLs can work well for a limited number of endpoints with static public IPs and a low rate of change.
Dependencies on IP addresses and ACLs become difficult for large deployments (lots of IPs), overlapping RFC 1918 space, the need to get static public IPs (or do port forwarding), and dealing with IP address changes. Meanwhile, IP addresses are weak security identifiers (compared to mTLS X.509s…more on that below).
So, similar to VPNs, IoT mTLS is often the better choice for deployments with many endpoints, strict security and compliance requirements, or high rates of change.
IoT mTLS security model
Let’s not claim mutual TLS is more secure than TLS, VPN or firewall ACLs without describing the solution so you can judge for yourself.
Most security models should start with identity. Mutual TLS is no different. Specifically, X.509 certificates replace the use of IP addresses for identity (the certs can be other types but X.509 is dominant). These certs authenticate IoT client and device connections. In the NetFoundry solution, without this authentication, the devices can’t connect to the Ziti overlay network fabric, which means they can’t connect to your IoT servers (your IoT servers are no longer open to the Internet – you close the inbound firewall ports – and instead your servers will now only talk to mTLS authenticated clients, with all communication initiated outbound.
Why are X.509 certificates a good basis for identity and authentication? First of all, X.509 certificates enable asymmetric keys, taking advantage of the power of public-private key cryptography. You can store private keys in places like TSMs so that the cryptographic material never leaves your device. Because the private key never leaves the device, it is far stronger than credentials that can be hijacked, phished or brute forced such as passwords or codes passed by text message. Furthermore, they don’t require human interaction with the IoT device.
In the case of the NetFoundry solution, the Ziti controllers will validate the cert against its Certificate Authority (CA). You can optionally add your own CA to the chain of trust. The Ziti controller challenges the client for proof of ownership of the private key that corresponds to the public key contained in the certificate. Part of the magic of the solution is making the PKI (enrollment, validation, and management process) simple. Check out this blog post series if you want more details on it.
IoT option summary – is mutual TLS a silver bullet for IoT security?
No. The first question is if you need to secure your IoT servers. Even if you do, then mTLS is just one important layer. Whether IoT mTLS is for you depends largely on the factors listed above. If you do need IoT mTLS, and you want to combine it with an IoT network overlay in order to remove your IoT servers from any network exposure, then NetFoundry’s IoT management and networking solution is likely the answer.
IoT Authentication and mTLS
In summary, NetFoundry uses mutual TLS (mTLS) to ensure secure and authenticated communication between clients and servers. By requiring both parties to present and verify digital certificates, mTLS establishes a trusted connection, encrypts data in transit, and protects against unauthorized access and man-in-the-middle attacks. This enhances security by verifying identities at both ends of the communication channel, ensuring that only authenticated devices can access the network and its resources.
