--- title: Security description: How ControlCom Connect secures traffic, devices, API access and user accounts: TLS, mutual TLS certificates, API keys, JWT sessions, MFA and audit logging. source: https://documentation.controlcomtech.com/references/security --- # Security This page describes the mechanisms ControlCom Connect uses to protect data and access: TLS on every connection, mutual TLS certificates for devices, API keys and session tokens for programmatic and user access, multi-factor authentication for accounts, and an audit log of changes. It is written for the person evaluating or operating a deployment who needs to know what is in place and how to use it. > **Workflow Stage: Integrate** ## Transport Security Every connection to the platform is encrypted in transit. Web and API traffic uses HTTPS; device traffic uses MQTT over TLS. ### HTTPS The web app and the REST API are served over HTTPS with TLS 1.2 or later. Cipher suites are limited to those with forward secrecy, and HTTP Strict Transport Security (HSTS) is enabled so browsers refuse to fall back to plain HTTP. Certificates are managed and renewed by the platform. ### MQTTS Devices publish to the platform's MQTT broker over TLS on port 8883. The broker supports QoS levels 0, 1 and 2, Last Will and Testament messages for connection monitoring, and configurable keep-alive intervals. Connection details for a device (endpoint, client ID and topic) are shown when the device is created and on its device page. See [Sending Data over MQTT](https://documentation.controlcomtech.com/build/sending-data/mqtt) for the payload and connection setup. ## API Security Tokens Programmatic access uses one of two credentials. An API key is a pair of values, a public ID and a secret, created under **Administration > API Keys** and sent as an HTTP Basic authorization header. A user's session is a JSON Web Token (JWT) sent as a Bearer token; this is what the web app itself uses, and it can be used directly against the API for scripts that act as a person. An API key has no permissions of its own. It inherits them from the role assigned at creation, the same roles used for team members, so a key for a read-only integration is created with a read-only role. The role can be changed later and takes effect on the next request, which is the fastest way to narrow a key that has more access than it needs. The secret is shown once, in the dialog that follows creation, and the platform stores only a hash of it. It cannot be displayed again or recovered; if it is lost, create a replacement key and retire the old one by moving it to a role with no permissions. See [Authentication](https://documentation.controlcomtech.com/api-reference/authentication) and [Settings](https://documentation.controlcomtech.com/platform/settings#api-keys) for the full creation flow. ## Device Secrets and Keys ### Mutual TLS Authentication (mTLS) ControlCom Gateways and Generic devices authenticate to the MQTT broker with mutual TLS. Creating a device provisions an X.509 certificate for it and opens the **Download Certificates & Secrets** dialog, which offers the device certificate, the public key, the private key and the Amazon root certificates the device needs to verify the broker. The private key is generated once and is not stored in a form the platform can hand back, so the dialog holds you there until you confirm the files are saved. With mTLS the broker verifies the device's certificate and the device verifies the broker's, so a connection is only accepted from a device holding a key that was issued for it. A device can hold two certificates at a time, which is how rotation works: generate the second on the device's **Certificates** tab, install it, confirm the device connects, then deactivate and remove the first. Deactivating or removing a certificate requires a verification code sent to you at the time. See [Device Administration](https://documentation.controlcomtech.com/platform/devices/administration#certificates-and-credentials) for the tab itself. ## Infrastructure Security The platform runs on Amazon Web Services. Services are isolated in VPCs with security groups and network ACLs, data is encrypted at rest, hosts are patched on a regular schedule, and monitoring and threat detection run continuously. Backups and disaster recovery procedures are automated. ## Multi-Factor Authentication Multi-factor authentication is available for every user account. When it is required for a member, signing in asks for a second factor from an authentication app in addition to the password. Administrators set the requirement per member on the **Permissions** tab of the team page, and the Users table can show an **MFA** column to see who has it enabled. See [Team & Access](https://documentation.controlcomtech.com/platform/team) for the controls. ## Additional Platform Security Features ### Audit Logging Changes made to an Organization are recorded in the **Logs** tab under Settings. Each entry carries the action (created, updated or deleted), the change itself with the API route it went through, when it happened, and who did it. The view opens on the last 30 days, can be widened with the date picker, filtered by message, route or user, and exported for retention outside the platform. See [Settings](https://documentation.controlcomtech.com/platform/settings#logs). ### Regular Security Assessments The platform is subject to periodic penetration testing and vulnerability scanning, and findings are addressed as part of the normal release cycle. ## Security Best Practices The mechanisms above do most of the work, but a few operating habits keep a deployment tight. Require MFA for every member, and review the Users table periodically so accounts that are no longer needed are removed. Give each integration its own API key with the narrowest role that covers its work, so a credential that has to be retired can be reduced to a role with no permissions rather than left with broad access. Rotate device certificates using the two-certificate flow rather than reusing a key across devices, and keep device firmware current. Finally, check the audit log now and then for changes you do not recognise; it is the quickest way to notice a credential being used in a way it should not be.