MQTT data residency is about knowing, and controlling, where your IoT messages are processed and stored on their way from device to application. This article explains which parts of an MQTT system touch data, which regulatory and contractual questions usually apply, and how region selection and bring-your-own-cloud deployments help you meet them. It is a practical engineering guide, not legal advice; involve your legal or compliance team for decisions.
What Data Residency Means for MQTT
Data residency is the requirement that certain data is stored or processed within a specific geography, such as a country or the European Economic Area. Related terms are often used loosely:
- Data residency: where data physically resides.
- Data sovereignty: which jurisdiction's laws apply to the data.
- Data localization: a legal mandate that data must stay in a country.
An MQTT broker is in the data path for every message. Even if your database is in the right country, a broker in another region still receives, processes and possibly stores those messages. Understanding what an MQTT broker does with your data is the starting point.
Where Data Lives in an MQTT System
Map every place a message can exist, not just your database:
| Location | What it holds | Residency question |
|---|---|---|
| Device | Readings before sending, buffered messages | Where are devices deployed? |
| Network path | Messages in transit | Is traffic encrypted with TLS end to end to the broker? |
| Broker memory | Messages being routed | In which region does the broker run? |
| Retained messages | Last value per topic | Stored where, and for how long? |
| Persistent sessions | Queued messages for offline clients | Stored where, and when do they expire? |
| Broker logs | Client IDs, IP addresses, sometimes topics | Do logs contain personal data, and where are they kept? |
| Subscribers and backends | Everything downstream | Where do your services and databases run? |
Two items are easy to overlook. First, retained messages and queued session messages are data at rest on the broker. Second, broker logs can contain IP addresses and client identifiers, which may be personal data under some regulations.
Regulatory and Contractual Drivers
GDPR and Personal Data
Under the EU General Data Protection Regulation, personal data can be transferred outside the EEA only with appropriate safeguards. Not all IoT data is personal, but much of it can be: location from a vehicle tracker, occupancy in a home, energy usage linked to a household, or health readings from a wearable. If a device can be linked to a person, its telemetry may be personal data.
Industry and Customer Requirements
Beyond privacy law, residency requirements often come from:
- Public-sector contracts that require in-country hosting.
- Critical infrastructure and utilities with national security rules.
- Healthcare and financial customers with their own policies.
- Enterprise procurement questionnaires asking where every subprocessor runs.
Often the strictest requirement is not a law at all but a clause in a customer contract. Collect those requirements before choosing a hosting model.
Reducing Residency Risk in Your Design
Engineering choices can shrink the problem regardless of where the broker runs:
- Minimize personal data in payloads. Send device IDs, not names or addresses. Resolve identities in your backend, in the right region.
- Keep personal data out of topic names. Topics appear in logs, explorers and debugging tools.
- Use TLS on every connection. Ports 8883 and 8084 encrypt data in transit.
- Limit data at rest on the broker. Use MQTT 5 message expiry and reasonable session expiry, and avoid retaining messages that contain personal data.
- Process at the edge. Aggregate or anonymize on a gateway before publishing to the cloud.
- Document the data flow. A diagram listing every component and its region answers most procurement questions.
Here is a Python example (paho-mqtt 2.x) that publishes pseudonymous telemetry with an MQTT 5 message expiry, so the broker discards it if no subscriber picks it up within ten minutes.
import json
import ssl
import time
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_start()
props = Properties(PacketTypes.PUBLISH)
props.MessageExpiryInterval = 600 # seconds
payload = {"device": "dev-4f9a", "kwh": 1.84, "ts": int(time.time())} # no names or addresses
info = client.publish("site-07/meter/dev-4f9a/telemetry", json.dumps(payload),
qos=1, properties=props)
info.wait_for_publish()
client.loop_stop()
client.disconnect()
Region Selection Trade-Offs
Choosing the broker's region is a balance of residency, latency and convenience:
- Residency: the region must satisfy your legal and contractual requirements.
- Latency: devices and consumers far from the broker see longer round trips; see MQTT broker latency by region.
- Co-location: placing the broker near your backend reduces cross-region data transfer.
- Multi-region fleets: if you sell in several jurisdictions, you may need one broker per region, with each device configured for its home broker.
The last point matters for architecture. A device fleet split across regions usually means separate brokers and separate backends per region, with only aggregated, non-personal data flowing to a global view.
Retention and Deletion
Residency questions usually come with retention questions. Decide how long each kind of data may live at every stage: on the device buffer, on the broker as retained or queued messages, in logs, and in your databases. Make deletion possible per device and per customer, because offboarding a customer or honoring a deletion request means removing data everywhere it was copied. Clearing a retained message is simple in MQTT: publish an empty retained payload to the same topic.
How BYOC Addresses Residency
The strongest answer to "where is our data?" is "in our own cloud account, in a region we chose." That is the bring-your-own-cloud model. With ConnectMQ BYOC, the broker runs in your cloud account and ConnectMQ manages it, so you decide the region, the network boundaries and the logging policy, while still avoiding the operational burden of self-hosting. The details are in our BYOC MQTT broker article.
Other ConnectMQ plans serve different needs. Serverless brokers on the shared cluster are ideal for development, pilots and data without residency constraints. A Dedicated plan gives you an isolated cluster. For both, ask ConnectMQ where the infrastructure runs and include the answer in your data flow documentation. Organizations that must run everything themselves can consider Self Managed Enterprise.
Whatever the plan, the client side does not change: MQTT 3.1.1 or 5.0 over TLS on port 8883, or Secure WebSocket on 8084 with path /mqtt. Moving a fleet from one hosting model to another is a matter of updating host and credentials.
A Residency Checklist Before You Launch
- List the jurisdictions where devices, users and customers are located.
- Classify payload fields: personal, pseudonymous or non-personal.
- Record the region of the broker, every subscriber and every database.
- Configure message expiry, session expiry and retained-message policy.
- Confirm TLS is mandatory for all clients.
- Decide whether BYOC or per-region brokers are required.
- Keep test data off public brokers; the free public MQTT broker area is readable by everyone and suitable only for non-sensitive experiments.
Get Started with ConnectMQ
Start building on the free Serverless plan at app.connectmq.com, no credit card required, using non-personal test data. When residency requirements firm up, talk to ConnectMQ about Dedicated or BYOC deployments. For a full overview of hosting models, read the cloud MQTT broker guide and the hosted MQTT broker comparison.
Frequently Asked Questions
Does MQTT data residency only matter for stored data?
No. Under many policies, processing counts too, and a broker processes every message. Retained messages, queued sessions and logs are also data at rest on the broker.
Is IoT telemetry personal data under GDPR?
It can be if it relates to an identifiable person, such as location or household energy use. Ask your data protection officer to classify your payloads.
How does BYOC help with data residency?
The broker runs in your own cloud account, in a region you choose, under your policies, while the provider operates it.
Can I use one broker for devices in several countries?
Technically yes, but if each country has residency rules you may need a broker per region, with devices assigned to their home broker.
