Security overview
ThingsBoard provides multiple layers of security for platform access, user authentication, and data protection. This page summarizes the available mechanisms and links to detailed configuration guides.
User authentication
Section titled “User authentication”ThingsBoard authenticates users via username and password by default. Administrators can enhance sign-in security with additional methods:
| Method | Description |
|---|---|
| Username and password | Default sign-in method. Configure password complexity, expiration, and account lockout rules in security settings. |
| Two-factor authentication | Adds a second verification step after entering credentials. Supports TOTP authenticator apps, email, SMS, and backup codes. See Two-factor authentication. |
| OAuth 2.0 / SSO | Allows sign-in via external identity providers like Google, Auth0, Keycloak, Okta, and Azure AD. See OAuth 2.0 support. |
| Self-registration | Lets tenants expose a sign-up page so customers can create their own accounts. See Self-registration. |
Programmatic access
Section titled “Programmatic access”Applications and scripts authenticate to the ThingsBoard REST API using one of two methods:
| Method | Description |
|---|---|
| JWT tokens | Obtained by calling the login endpoint with username and password. Tokens expire periodically and must be refreshed. Configure token lifetime in security settings. See the REST API reference for details. |
| API keys | Long-lived credentials that bypass the login flow. Ideal for third-party integrations, scripts, and automation. See API keys. |
Infrastructure security
Section titled “Infrastructure security”Web UI and REST API
Section titled “Web UI and REST API”| Topic | Description |
|---|---|
| HTTPS / SSL | Encrypt traffic between clients and the ThingsBoard server using TLS certificates. See HTTPS (TLS) configuration. |
| Custom domains | Bind custom domain names with automatic SSL certificate provisioning. See Domains. |
Device transport security
Section titled “Device transport security”Each device connectivity protocol supports encrypted transport and one or more authentication methods:
| Protocol | Encryption | Authentication methods | Reference |
|---|---|---|---|
| MQTT | TLS (port 8883) | Access Token, MQTT Basic credentials, X.509 certificate | MQTT getting connected |
| HTTP | TLS / HTTPS (port 443) | Access Token | HTTP getting connected |
| CoAP | DTLS (port 5684) | Access Token, X.509 certificate | CoAP getting connected |
| LwM2M | DTLS (ports 5686, 5688) | Pre-Shared Key (PSK), Raw Public Key (RPK), X.509 certificate | LwM2M getting started |
| SNMP | USM authentication + encryption (v3) | Community string (v1/v2c), USM username with auth and privacy passphrases (v3) | SNMP getting connected |
All protocols support one-way TLS (client verifies the server). MQTT, CoAP, and LwM2M also support mutual TLS, where both sides authenticate using X.509 certificates. For fleet provisioning, you can use certificate chains so that devices sharing a common CA are automatically trusted.
Administration and compliance
Section titled “Administration and compliance”| Topic | Description |
|---|---|
| Security settings | Configure account lockout policies, password requirements, and JWT token parameters. See Security settings. |
| Audit log | Track user actions across the platform for compliance and troubleshooting. See Audit log. |
| Secrets storage | Encrypted vault for storing sensitive values like API tokens, passwords, and certificates used in integrations and rule chains. See Secrets storage. |