AWS IoT Core EU Alternative 2026: Device Telemetry, CLOUD Act, and GDPR

Post #755 in the sota.io EU Compliance Series

AWS IoT Core is Amazon's managed MQTT message broker and IoT connectivity platform. Devices — wearables, industrial sensors, smart home equipment, connected vehicles, building management systems — connect to IoT Core over MQTT or HTTPS and publish telemetry messages. IoT Core routes those messages via configurable Rules to downstream services: Amazon S3, DynamoDB, Kinesis, SQS, Lambda, and others.

Amazon operates IoT Core in European AWS regions: eu-west-1 (Ireland), eu-central-1 (Frankfurt). The endpoints are regionally deployed. Device messages published to the Frankfurt MQTT broker are processed in Frankfurt infrastructure. Many IoT developers treat European endpoint selection as sufficient for GDPR compliance.

It is not. Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) requires US companies to disclose data stored anywhere in the world when served with a valid US government order. A subpoena served on Amazon in Seattle reaches your device telemetry in Frankfurt — the heart rate data from your medical wearables, the location pings from your asset trackers, the occupancy readings from your smart building sensors, and the behavioral patterns derived from all of them.

This is the same structural US jurisdiction problem documented across the AWS stack: AWS S3, AWS DynamoDB, AWS Kinesis, AWS Lambda. IoT Core adds a dimension unique to the stack: the data it handles is often generated by physical devices embedded in users' bodies, homes, vehicles, and workplaces — and often constitutes special-category data under GDPR Art.9.

What AWS IoT Core Stores About Your Devices and Users

IoT Core is not a simple message relay. It maintains persistent state, message history, and metadata about every device connected to the platform — and the personal data embedded in that state is frequently sensitive.

MQTT Message Broker: Device Telemetry Content

Every MQTT message published by a connected device passes through the IoT Core message broker. Messages are the raw telemetry: temperature readings, heart rate values, GPS coordinates, door-open events, motion detection alerts, medication dispenser actuations, blood glucose measurements.

The GDPR status of this data depends on whether the device can be linked to an identifiable individual — which in most consumer IoT deployments it can:

• Health wearables: A glucose monitor registered to a diabetic patient publishes blood glucose readings to IoT Core. These are health data under GDPR Art.9(1) — special-category data requiring explicit consent (Art.9(2)(a)) or another qualifying ground.
• Smart home devices: A smart thermostat linked to a household account publishes occupancy data, heating schedules, and behavioral patterns. Home as personal space; occupancy patterns as behavioral profiling (Art.22 risk).
• Asset trackers: A GPS tracker registered to an employee's vehicle publishes real-time location data. Location data = personal data under Art.4(1); workplace location tracking has specific legal basis requirements.
• Industrial wearables: A biometric safety wristband worn by a factory employee publishes heart rate and fall detection data. Employee health monitoring is Art.9 sensitive data requiring explicit consent and specific legal basis.
• Implantable devices: Insulin pumps and cardiac monitors connected via gateways publish clinical telemetry. This is unambiguously Art.9 health data.

Every one of these message types, published to AWS IoT Core in Frankfurt, flows through an Amazon infrastructure ultimately governed by Seattle, Washington — accessible under CLOUD Act compulsion.

Device Shadow: Persistent State Under CLOUD Act Exposure

AWS IoT Core provides a Device Shadow service — a persistent JSON document that stores the last-reported state of each device. Shadows are synchronized automatically: when a device reports its state, the Shadow is updated; when an application commands a new state, the desired state is stored in the Shadow until the device acknowledges it.

Device Shadows contain the current state of every connected device:

{
  "state": {
    "reported": {
      "heart_rate": 73,
      "spo2": 98,
      "activity": "sleeping",
      "location": { "lat": 48.1374, "lon": 11.5755 },
      "medication_dose_delivered": true,
      "battery": 84
    },
    "desired": {
      "alert_threshold_bpm": 100
    }
  },
  "metadata": {
    "reported": {
      "heart_rate": { "timestamp": 1746102029 }
    }
  },
  "version": 1847
}

This Shadow document exists permanently in AWS infrastructure for the lifetime of the device registration. A medical device Shadow contains a running record of patient health metrics. A smart lock Shadow contains access patterns. An insulin pump Shadow contains dosing history. All of it sits in Amazon's infrastructure — and all of it is reachable under CLOUD Act.

The Shadow is also queryable in bulk via the AWS IoT Fleet Indexing service, which indexes device Shadow state across an entire fleet. A single query can return the current health metrics of every registered patient device in a healthcare provider's fleet.

IoT Rules Engine: Telemetry Routing to US-Entity Services

IoT Core's Rules Engine evaluates SQL-like rules against incoming device messages and routes matching messages to downstream services. Rules are the primary mechanism for persisting and processing device data — and rules typically route to other AWS services:

• S3: Raw device telemetry archived in S3 buckets for long-term storage or ML training
• DynamoDB: Device readings stored in DynamoDB tables for real-time dashboards
• Kinesis Data Streams / Kinesis Firehose: High-volume device streams fed into analytics pipelines
• Lambda: Functions triggered by device events for real-time processing
• SQS/SNS: Alerts published when device readings cross thresholds

Every downstream service in this chain is an Amazon service — all subject to CLOUD Act jurisdiction. An IoT Rules Engine pipeline that archives glucose readings to S3, indexes them in DynamoDB, and triggers Lambda functions does not just create one CLOUD Act exposure point at IoT Core; it creates four simultaneous CLOUD Act exposure points. Each hop adds another US-entity service holding your patient data.

The Rules Engine also includes a republish action — routing device messages to other MQTT topics — and a CloudWatch Logs action for debugging. CloudWatch Logs for IoT Core rule execution logs contain device IDs, message payloads (configurable), and rule evaluation results. AWS CloudWatch already documented GDPR issues.

AWS IoT Registry: Device Identity and Metadata

The IoT Core Registry stores metadata about every registered device: device name (Thing Name), device type (Thing Type), attributes (key-value pairs), and certificates. Device metadata in the Registry frequently contains personally identifying information:

• Thing names like patient-device-12345 or employee-badge-DE-7832
• Attributes like { "owner_email": "patient@clinic.de", "ward": "cardiology" }
• Group membership linking devices to organizational units or patient cohorts

Device certificates stored in the Registry are the cryptographic identities used for mutual TLS authentication. The certificate includes the device's distinguished name and serial number — and the Registry maintains the revocation status and issuance history.

The Registry is the persistent device identity store. It holds the linkage between physical hardware and the human individuals associated with that hardware — making it the linchpin for pseudonymization risk analysis under GDPR Art.25.

The Art.9 Problem: IoT Is Disproportionately Special-Category Data

GDPR Art.9 defines special categories of personal data — data whose processing is presumptively prohibited except under specific legal grounds. The categories include health data, biometric data used for unique identification, and data revealing racial or ethnic origin.

IoT data intersects with Art.9 in ways that infrastructure engineers frequently underestimate:

Health data (Art.9(1)): Any measurement that relates to the physical or mental health of a natural person is health data. Heart rate is health data. SpO2 is health data. Sleep quality scores derived from accelerometer data are health data. Medication adherence data (did the pill dispenser open?) is health data. You do not need clinical-grade sensors for Art.9 to apply — a consumer fitness wristband publishing resting heart rate generates health data.

Biometric data for identification (Art.9(1)): Fingerprint readers, iris scanners, and facial recognition sensors connected via IoT gateways generate biometric data used for unique identification — explicitly Art.9.

Behavioral inference creating Art.9 risk: Smart home occupancy data, combined with other data, can reveal health conditions (irregular sleep patterns suggesting illness), religious practice (prayer time patterns), or sexual orientation (correlated occupancy patterns). The data itself is not Art.9 until combination creates inference — but the inference risk must be assessed under Art.25 (data protection by design).

Workplace monitoring inferring health: Wearables worn by healthcare workers that track physical activity, location within a hospital, and stress indicators (heart rate variability) combine workplace performance data with health indicators. This intersection of employee monitoring and health data creates Art.9 exposure.

AWS IoT Core is not equipped with Art.9-aware data handling. The Rules Engine does not differentiate between health-category telemetry and non-sensitive industrial sensor data. The Shadow service stores all fields uniformly. There is no mechanism for applying Art.9-required explicit consent workflows to specific device data types within IoT Core itself.

CLOUD Act Risk Scenarios for European IoT Deployments

The CLOUD Act exposure scenarios for IoT Core are particularly acute because IoT data is often continuous and longitudinal — devices publish readings every few seconds, creating detailed behavioral timelines that are more revealing than discrete query results.

Scenario 1: Healthcare Provider IoT Infrastructure A German hospital deploys a remote patient monitoring system using AWS IoT Core. Patient glucose monitors, cardiac telemetry devices, and medication dispensers publish readings continuously. The hospital selected the eu-central-1 region and believes data residency is EU-compliant.

US law enforcement investigating pharmaceutical distribution fraud obtains a CLOUD Act order directed at Amazon, Inc. The order targets IoT device data associated with a list of device IDs. Amazon, operating IoT Core as a US company, complies. The hospital receives no notification. Patient health data — Art.9 protected under German law, requiring strict confidentiality — is disclosed to US authorities without hospital knowledge or patient consent.

Scenario 2: Smart City Sensor Network A Dutch municipality deploys a smart city platform using AWS IoT Core to manage traffic sensors, environmental monitors, and pedestrian counters. Individual sensor readings may not be personal data — but the platform also integrates smart parking sensors that log vehicle presence, linked to license plates readable by cameras in the same infrastructure.

Vehicle location data linked to license plates is personal data. The longitudinal pattern — Vehicle X was at Location Y from 08:30 to 17:45 — constitutes behavioral profiling. The municipality's DPA (Autoriteit Persoonsgegevens) requires data sovereignty for such infrastructure. AWS IoT Core, as a US-controlled service, does not meet this requirement.

Scenario 3: Industrial Employee Monitoring A French manufacturing company deploys smart safety wearables for factory workers, publishing heart rate, location within the factory, and fall detection events via AWS IoT Core. The company argues the data is operational safety data, not health data.

Under CNIL guidance, employee health metrics — even collected for safety purposes — are health data under Art.9. The company lacks a qualifying Art.9(2) ground for processing on a US-entity platform without employee consent. The workers' union files a GDPR complaint. The company faces enforcement action not for collecting the data, but for routing it through AWS IoT Core without adequate legal basis for international transfer.

Art.5(1)(e) Storage Limitation: The Retention Default Problem

AWS IoT Core Message Broker does not itself retain device messages beyond delivery — messages are delivered to Rules Engine destinations and are not stored by the broker unless explicitly configured. This is better than some AWS services' retention defaults.

However, the Rules Engine destinations where messages are routed have their own retention problems:

• S3 buckets created by IoT Rules have no default lifecycle policy — objects are retained indefinitely unless explicitly configured
• DynamoDB tables have no TTL configured by default — items persist until explicitly deleted
• Kinesis Data Firehose archives to S3 with no default retention policy on the delivery bucket
• CloudWatch Logs for rule evaluation errors default to Never Expire retention

The practical result: teams deploy IoT Rules that route device telemetry to S3 "for analysis," and two years later the bucket contains the complete telemetry history of every patient device, every employee wristband, every consumer product. The retention was accidental — no decision was made to retain the data for two years; it simply accumulated because the destination service had no automatic deletion.

GDPR Art.5(1)(e) requires that personal data be kept "no longer than is necessary for the purposes for which the personal data are processed." An S3 bucket with two years of patient glucose readings, accumulated without an explicit retention decision, is not compliant — regardless of where the bucket's physical storage is located.

EU Alternatives for AWS IoT Core

HiveMQ — German-Native MQTT Platform

HiveMQ is an enterprise MQTT broker developed and headquartered in Landshut, Bavaria, Germany. HiveMQ Platform is a fully managed MQTT broker available as a cloud service on EU infrastructure, with self-hosted deployment options for on-premises or private cloud.

HiveMQ's legal structure is European. There is no US parent company creating CLOUD Act exposure. German data protection law applies to HiveMQ GmbH's operations in Germany.

HiveMQ supports the full MQTT 3.x and 5.x specification, shared subscriptions, MQTT over WebSockets, and enterprise features including ACL-based topic authorization, audit logging, and extensions for custom authentication and data transformation. HiveMQ Data Hub (available in Enterprise edition) provides a Rules Engine equivalent — message filtering, transformation, and routing to downstream systems — without US-entity jurisdiction risk.

For Art.9-heavy healthcare IoT deployments, HiveMQ's German jurisdiction and willingness to sign comprehensive DPAs makes it the preferred commercial alternative to IoT Core.

Eclipse Mosquitto + Self-Hosted Stack

Eclipse Mosquitto is the reference open-source MQTT broker under the Eclipse Foundation (a Canadian non-profit with European governance). Mosquitto is deployed as a container or binary on your own infrastructure — fully self-hosted, no third-party jurisdiction exposure.

A production-grade self-hosted MQTT platform typically combines:

• Mosquitto or EMQX as the MQTT broker
• TimescaleDB or InfluxDB for time-series telemetry storage
• Grafana for dashboards
• Node-RED or custom microservices for Rules Engine equivalent logic
• MinIO (EU-hosted) for bulk telemetry archiving

Self-hosted on EU VPS infrastructure (Hetzner, Scaleway, OVHcloud, Deutsche Telekom), this stack places all device data under European jurisdiction with no CLOUD Act exposure vector.

EMQX — High-Scale Open-Source MQTT Broker

EMQX is a high-performance open-source MQTT broker capable of handling millions of concurrent device connections. EMQX is available as self-hosted open source (Apache 2.0 license) or as EMQX Cloud managed service.

For GDPR compliance, self-hosted EMQX on EU infrastructure is the relevant deployment model. EMQX supports:

• MQTT 3.x, 5.x, MQTT-SN (sensor networks)
• Rule Engine with native integrations to PostgreSQL, MySQL, TimescaleDB, Kafka, Redis
• Authentication via JWT, mTLS certificates, HTTP hooks
• Data bridges for cross-cluster routing

EMQX's Rule Engine can replicate AWS IoT Core Rules Engine functionality on EU-sovereign infrastructure.

Thingsboard — Open-Source IoT Platform

Thingsboard is a full IoT platform — not just a message broker, but a complete device management, data visualization, and rule processing system. Open-source (Apache 2.0), self-hostable on EU infrastructure.

Thingsboard features relevant to GDPR compliance:

• Device provisioning and certificate management (IoT Registry equivalent)
• Device Shared Attributes (Device Shadow equivalent)
• Rule Chains (Rules Engine equivalent) with EU-hosted data destinations
• Telemetry storage in PostgreSQL/Cassandra on your EU infrastructure
• Dashboard editor for operational monitoring

Thingsboard is deployed on EU infrastructure by healthcare providers, industrial manufacturers, and smart city operators who require full data sovereignty.

Bosch IoT Suite — EU Industrial IoT

Bosch IoT Suite is a managed IoT platform from Robert Bosch GmbH, a German company headquartered in Stuttgart. The suite includes IoT Hub (MQTT/AMQP device connectivity), IoT Things (Device Registry), and IoT Rollouts (firmware management).

Bosch IoT Suite operates under German and EU law. Robert Bosch GmbH is subject to GDPR and German BDSG, not the CLOUD Act. For industrial IoT deployments — factory automation, supply chain monitoring, connected vehicles — Bosch IoT Suite provides an enterprise-grade EU-native alternative with relevant domain expertise.

Comparison Table

Migration Path from AWS IoT Core

Step 1: Inventory Device Telemetry and Data Classification

Before migrating, classify the data your devices publish:

• Does any telemetry constitute health data (Art.9)? Heart rate, SpO2, medication events, fall detection, sleep metrics — all Art.9.
• Are device identifiers linkable to natural persons? If a device can be associated with a specific individual, all telemetry from that device is personal data.
• What retention periods apply? Audit existing S3 buckets, DynamoDB tables, and Kinesis consumers receiving IoT telemetry for unexpired historical data.

This classification determines your Art.9 legal basis requirements and your data minimisation obligations.

Step 2: Choose Your EU-Native Broker Architecture

For commercial managed service with EU legal structure: HiveMQ Cloud on EU infrastructure, with DPA executed under German law.

For maximum sovereignty with self-hosted control: EMQX Community or Thingsboard on Hetzner, Scaleway, or OVHcloud EU compute. No third-party DPA required — you are the sole controller.

For industrial/manufacturing context: Bosch IoT Suite for domain-specific features and EU-entity enterprise support.

Step 3: Migrate Device Connectivity

AWS IoT Core uses standard MQTT over TLS with certificate-based mutual authentication. Most MQTT clients (Paho MQTT, Arduino MQTT, ESP-IDF MQTT) support configurable broker endpoints. Migration involves:

1. Provision new certificates from your EU-native broker
2. Update device firmware or gateway configuration with new endpoint and certificate
3. Test with a staging device cohort before fleet-wide rollout
4. For gateways: update the MQTT client configuration; field devices may not require firmware updates if they connect through a gateway

Certificate rotation for large device fleets (thousands of devices) requires careful orchestration. HiveMQ and Thingsboard both support bulk certificate operations.

Step 4: Migrate Device Shadow to EU-Native Equivalent

Replicate Device Shadow state to your EU-native equivalent:

• EMQX: Use EMQX's built-in retained message feature or external Redis/PostgreSQL state store
• Thingsboard: Device Shared Attributes directly mirror AWS Device Shadow functionality
• HiveMQ: HiveMQ Data Hub with a PostgreSQL backend for persistent device state

Export current Shadow state from AWS IoT Core before cutover. AWS IoT Core does not provide a bulk Shadow export API — you must query each device Shadow individually or use IoT Fleet Indexing to query device state in batches.

Step 5: Migrate Rules Engine Logic

The IoT Rules Engine is often the most complex migration target. Rules may have grown organically and may be undocumented.

Inventory all active Rules in the AWS IoT console. For each Rule:

• What SQL query does it evaluate?
• What action does it trigger (S3, DynamoDB, Lambda, etc.)?
• What data does it route?

Replicate each Rule in your EU-native broker's equivalent. For EMQX, this means EMQX Rule Engine SQL with actions to PostgreSQL, TimescaleDB, or Kafka topics. For Thingsboard, this means Rule Chains. For HiveMQ, this means Data Hub data policies.

Step 6: Update Your Art.30 Records and DPA

When migration is complete:

• Terminate the AWS DPA for IoT Core
• Execute a new DPA with your EU-native managed service provider (if applicable)
• Update Art.30 records to reflect the new data flows: device → EU broker → EU storage
• For Art.9 data: document the legal basis for each health data category, and ensure explicit consent or qualifying ground is in place

Practical Steps for European Companies

1. Classify your IoT telemetry for Art.9: Any device measuring health metrics (heart rate, SpO2, glucose, medication events) generates special-category data. Identify these data streams immediately.
2. Audit S3 buckets receiving IoT data: Rules Engine S3 destinations accumulate data indefinitely without lifecycle policies. Review and configure expiration.
3. Assess device-to-person linkability: Can any Device Thing Name, attribute, or certificate be linked to an identifiable individual? If yes, all telemetry is personal data under Art.4(1).
4. Evaluate CLOUD Act transfer risk: IoT Core is a US-entity service. Under current EU/US data transfer frameworks, this requires adequate safeguards (SCC) — but structural CLOUD Act exposure is not resolved by SCCs alone.
5. Plan EU-native migration by data category: Prioritize health-data device fleets for earliest migration; operational sensor networks with no personal-data linkage can follow later.
6. Consider EU-hosted managed services: HiveMQ Cloud eliminates operational overhead while maintaining EU legal structure; self-hosted EMQX/Thingsboard maximizes sovereignty.

Related posts in this series:

• AWS Kinesis EU Alternative: Streaming Data, CLOUD Act, and GDPR
• AWS S3 EU Alternative: Object Storage and the CLOUD Act
• AWS DynamoDB EU Alternative: NoSQL Under US Jurisdiction
• AWS Lambda EU Alternative: Serverless and the Execution Environment Problem
• AWS Secrets Manager EU Alternative: CLOUD Act on Your Secrets
• AWS SageMaker EU Alternative: ML Pipelines, Feature Store, and GDPR
• AWS CloudWatch EU Alternative: Logs, Metrics, and the GDPR Problem