mTLS vs Token Authentication for IoT: Which Should You Use?

Every IoT device connecting to a management backend must prove its identity. The two dominant approaches are token-based authentication (API keys, bearer tokens, JWT, OAuth2) and mutual TLS (mTLS) certificate-based authentication. Choosing between them — or combining them — is a consequential architectural decision that affects your security posture, operational complexity, and scalability.

This article compares the two approaches across security properties, operational requirements, and IoT-specific constraints, and explains how SocketXP’s platform supports both while recommending mTLS on port 9444 for production fleet security.

For the complete implementation guide, see: Scaling mTLS IoT Security: The Developer’s Guide.

What Is Token-Based Authentication?

Token-based authentication uses a string value — an API key, bearer token, JSON Web Token (JWT), or OAuth2 access token — that the device presents to authenticate itself. The server validates the token (by checking a signature, querying a database, or calling an authorization service) and grants or denies access.

Common token formats in IoT:

• Static API keys: A long random string issued once and stored on the device. Simple to implement; no expiration unless manually rotated.
• JWT (JSON Web Tokens): A signed, base64-encoded JSON payload containing claims (device ID, permissions, expiration time). The server validates the signature without a database lookup.
• OAuth2 Bearer Tokens: Short-lived tokens issued by an authorization server after a device authenticates with credentials. Devices periodically refresh tokens.
• SocketXP Auth Tokens: The auth token used with socketxp login <auth-token> on the default port 9443. This is the standard SocketXP authentication mechanism — the token is a bounded-scope credential tied to your account.

Token authentication operates at the application layer. The transport layer (TLS) provides encryption and server authentication (the device verifies the server’s certificate), but the device itself is authenticated by the token it presents inside the TLS session.

What Is mTLS Authentication?

Mutual TLS authentication adds a second authentication at the transport layer. Both the device and the server present X.509 certificates during the TLS handshake, and both verify the other’s certificate against a shared Certificate Authority (CA) before any application data flows.

In SocketXP’s implementation, mTLS is enforced on gateway port 9444. Devices present their tls_server.crt certificate (issued by the BastionXP CA module) and operators present their tls_client.crt certificate (24-hour validity). The gateway validates both before the tunnel is established.

Security Comparison

Authentication Layer

Token Exposure Risk

A stolen or leaked token can be used by any machine on any network until it expires or is explicitly revoked. There is no cryptographic binding between the token and the physical device — a token extracted from device firmware is fully functional on an attacker’s laptop.

An mTLS certificate has no value without the corresponding private key. Even if the certificate file is extracted from a device (for example, by reading flash storage), it cannot authenticate without the private key. If the private key is stored in a TPM or Secure Element, the certificate cannot be used at all outside the original hardware.

Revocation Speed

Lateral Movement Risk

A compromised token from one device can potentially be used to authenticate as that device from a different network location. mTLS eliminates this risk: the certificate proves the device possesses the specific private key, and private keys cannot be replicated without compromising the storage mechanism (file, TPM, or Secure Element).

Operational Comparison

Implementation Complexity

Token auth is simpler to implement initially. Storing a string in a device’s configuration file and including it in an HTTP header or MQTT username field requires no cryptographic infrastructure.

mTLS requires a certificate authority (CA), certificate issuance, certificate storage on the device, and periodic renewal. SocketXP’s built-in BastionXP CA module eliminates most of this complexity for the remote access channel — socketxp ca login <token> --server <name> handles issuance in a single command.

Credential Rotation at Scale

mTLS has a significant advantage after a breach: certificates are per-device. Revoking one device’s certificate does not require rotating credentials for the entire fleet. With shared or weak token models, a breach often requires a simultaneous fleet-wide credential rotation.

Audit Trail

Both approaches can generate audit logs. mTLS provides stronger non-repudiation: since the private key never leaves the device, a logged mTLS connection to device device001.fleet.example cannot be disputed — only the physical device with that private key could have made it. Token-based logs can theoretically be attributed to any machine that held the token.

SocketXP: Token Auth on Port 9443, mTLS on Port 9444

SocketXP supports both authentication models:

Standard TLS with auth token (port 9443):

# Default connection — auth token authenticates the session
# Device certificate is NOT verified by the gateway
socketxp login 
socketxp connect tcp://127.0.0.1:22

Mutual TLS with device certificate (port 9444):

# mTLS connection — both auth token AND device certificate required
# Gateway validates the device certificate issued by BastionXP CA module
socketxp login  \
  --gateway-port 9444 \
  --mtls \
  --cert /var/lib/socketxp/tls_client.crt \
  --key /var/lib/socketxp/tls_client.key

socketxp connect tcp://127.0.0.1:22 \
  --gateway-port 9444 \
  --mtls \
  --cert /var/lib/socketxp/tls_server.crt \
  --key /var/lib/socketxp/tls_server.key

In both cases, the auth token authenticates the SocketXP account. The difference is that on port 9444, the device must also present a valid X.509 certificate issued by the BastionXP CA module. Both factors must be valid for the connection to succeed.

Combining mTLS and Tokens: Defense in Depth

The two approaches are not mutually exclusive. Many production IoT architectures use both:

1. mTLS at the transport layer ensures only certificated devices can establish any connection to the management infrastructure
2. Tokens at the application layer enforce per-request authorization (which APIs the device can call, which data it can read or write)

This defense-in-depth model means that:

• An attacker who intercepts a token cannot use it without also possessing the device’s private key (blocked by mTLS)
• An attacker who somehow obtains the device’s private key and certificate cannot access unauthorized APIs (blocked by token-level authorization)

SocketXP’s mTLS + auth token model on port 9444 implements exactly this pattern: the device’s certificate authenticates the hardware identity, and the auth token ties the session to a specific SocketXP account.

When to Use Token Auth vs mTLS

Use token auth (port 9443) when:

• You are in development or prototyping — simpler setup, no certificate management overhead
• Your devices lack the storage or compute to manage certificates
• You need quick, temporary access to a single device
• The threat model does not require hardware-bound device identity

Use mTLS (port 9444) when:

• Your fleet has a defined, finite set of authorized devices
• You need to enforce that only physically authorized hardware can connect
• You have compliance requirements mandating mutual authentication (IEC 62443, NIST SP 800-213)
• You are deploying at scale and need per-device revocation capability without fleet-wide credential rotation
• You operate in an environment where token interception is a realistic threat (shared networks, cloud environments with shared infrastructure)

For most production IoT fleet deployments, mTLS on port 9444 is the correct choice. The added operational complexity of certificate management is largely handled by SocketXP’s built-in BastionXP CA module, and the security gains — hardware-bound identity, per-device revocation, cryptographic non-repudiation — are not achievable with tokens alone.

Next Steps

• Scaling mTLS IoT Security: The Complete Developer Guide — full PKI architecture, certificate lifecycle, revocation (SCEP/CRL/OCSP), and BastionXP as alternate CA
• How to Implement mTLS in IoT — step-by-step mTLS setup with SocketXP
• Automating IoT Certificate Rotation with mTLS — fleet-scale certificate renewal pipelines
• Zero Trust Security for IoT Devices — the broader zero trust framework that mTLS underpins