Navigating the EU Data Act for IoT Solutions: Part 1- Healthcare Industry lens

Introduction

In the evolving landscape of healthcare technology, the intersection of Internet of Things (IoT) devices and data regulation presents both unprecedented opportunities and complex challenges. The European Union (EU) Data Act became applicable in September 2025, marking a new regulatory milestone for how IoT-generated data is managed, shared, and protected within the EU.

For manufacturers of IoT devices, understanding and preparing for the EU Data Act is of utmost priority. The Act introduces new requirements to strengthen users’ rights to access and share data generated from their usage of IoT devices that will fundamentally alter how they approach data management in IoT-enabled healthcare solutions.

In this blog post, we’ll delve into the impact of the EU Data Act on Healthcare IoT. As healthcare organizations face unique challenges in balancing data accessibility with patient privacy, we’ll explore how AWS has developed a reference framework that can be used to address this new challenge. Using ultrasound device data management as an example, we’ll showcase how AWS services—including Amazon Macie, AWS Glue, and Amazon Comprehend Medical—can be used by customers to create data workflows to support their efforts to meet EU Data Act requirements.

We will also walk through the EU Data Act’s core requirements and present example architectures that can help organizations align with the Act. Regardless of industry, if you are a device manufacturer or an organization deploying IoT solutions operating in the EU, this blog will provide valuable insights to help you navigate the new regulatory landscape.

Join us as we explore how organizations are transforming these regulatory requirements into opportunities for enhanced patient care, improved data governance, and technological advancement in the IoT healthcare landscape.

The EU Data Act: A new era in data governance

The European Union’s Data Act entered into force on January 11, 2024, but its provisions became directly applicable on September 12, 2025, marking a transformative shift in data governance.

The Act seeks to foster innovation by increasing access to and reuse of data generated using connected products and related services. For healthcare organizations and medical device manufacturers, understanding and complying with this Act is crucial, particularly given its intersection with existing regulations, such as the EU’s General Data Protection Regulation (GDPR).

The Data Act covers “connected products” – physical IoT devices (hardware) that collect or generate data and can communicate it electronically. In the healthcare context, it’s possible that personal, medical, and telemetry data for appliances are not clearly separated and classified, especially in legacy systems. Consequently, a thorough audit of what and how data is being collected is a top recommendation.

While GDPR focuses on personal data protection, the Data Act governs non-personal and IoT device data and emphasizes data sharing obligations. Compliance strategies must consider both laws, enabling data portability and sharing while maintaining strong privacy controls. This requires customers to consider a range of new features and security controls that healthcare organizations must implement carefully, especially when handling medical device data and any Personally Identifiable Information (PII) or Patient Health Information (PHI) data that the devices may store and transmit.

The legislation also introduces new provisions for public sector access, allowing government bodies to request access to data directly from IoT vendors, including privately held data, in specific situations such as public emergencies (e.g., during a public health crisis). Organizations should have procedures to handle such government data requests while still upholding data protection obligations.

For the healthcare sector specifically, the Act may have relevance for medical IoT devices, including wearables, implantables, and diagnostic equipment like ultrasound machines. Organizations must consider how these requirements intersect with existing healthcare data regulations while maintaining the integrity and accessibility of clinical data. Furthermore, the Act’s pre-sale transparency requirements regarding the type of data collected by these devices add another layer of complexity.

Healthcare organizations must now implement robust systems to enable user access to their usage data if they manufacture “connected products” or provide “related services” under the EU Data Act. These systems must not only comply with technical requirements but also maintain the high standards of data protection essential in healthcare settings.

Example Use Case: Ultrasound device data management

Modern ultrasound devices generate Digital Imaging and Communications in Medicine (DICOM) data including high-resolution medical images, metadata, patient demographics, patient measurement data, timestamps, location data, log data, and clinical annotations that can contain PII and PHI data requiring secure, efficient handling and storage. In a typical healthcare setting, these devices capture images in DICOM format, which then need to be processed, stored, and made accessible to healthcare providers while maintaining strict compliance and security standards.

Data Flow Diagram

The data flow diagram below describes the actors, devices, and systems that are involved in the processing of ultrasound scanner data. For those of you who are not familiar with STRIDE data flow diagrams and threat modeling, these diagrams create a simplified view of a system so that you can focus on where and what is processing your data. See the workshop Threat Modeling for builders if you want to dive deeper on how to create your own data flow diagrams and threat models.

Figure 1 – Ultrasound data flow diagram

For data flow 1 in this diagram, we can see that the hospital staff utilize the ultrasound scanner via a local app. This local app has a data store and clients for AWS IoT Core and Simple Storage Service (S3). In data flow 3 these clients allow the scanner to send data to the AWS Cloud. As the data is passed from system to system, it travels through a trust boundary which is shown by the dotted line. A trust boundary is a point where the ownership of data transitions between actors in a system. It is also the most likely place for a potential threat to impact the confidentiality, integrity, and availability of the system.

Other actors we see in the hospital environment are data flow 2 for onsite support engineers when the vendor needs hands-on access to the device, and data flow 8 which represents the patient data being uploaded as they are scanned. An additional flow available to the hospital staff is data flow 9, which allows the hospital staff to examine the data for all machines in the hospital via a web app. The web app also allows hospital staff to delegate access to the data to trusted third parties as shown by data flow 7. The ultrasound scanner vendor can delegate access to Public Sector actors representing the EU public health authorities who can, under special circumstances, request access to data, for example during a national health crisis such as COVID-19. This is represented by data flow 6.

On the vendor side we can see the Ultrasound Vendor Data API which acts as the controller for access to the raw data store. Data flow 4 is used by actors on the vendor side including system admins and remote support staff. They use different tooling that is not represented in this diagram. To implement this system, we will design AWS solution architectures to represent the various components. The diagram does not show us the identity provider for the IoT vendor; however, you should assume that one exists and that the Ultrasound Vendor Data API has role-based access control (RBAC) security implemented in its code.

Data Ingestion Pipeline

The example AWS solution creates a pipeline for managing ultrasound data. Starting at the device level, ultrasound machines connect to AWS IoT Core for secure data transmission. Because this data transmission crosses a trust boundary and is coming from a remote device, you should implement security controls including mTLS authentication for the scanner and attach the device to a least privilege role in AWS IoT Core. Telemetry messaging for the appliance is passed using raw MQTT messages because they are small enough for AWS IoT Core to process directly. When an image upload is required, the scanner sends an upload request message via MQTT, which is then routed to a Lambda function that generates an S3 upload URL which is returned to the scanner. The scanner app then uploads the image using this URL. The raw DICOM images are initially stored in Amazon S3 buckets with server-side encryption using AWS Key Management Service (AWS KMS) keys (SSE-KMS), and access controls using bucket policies that enforce encryption with that CMK. A serverless processing pipeline, built using AWS Lambda and AWS Step Functions, handles image optimization, metadata extraction, and format validation. This processed data is then made available through a secure Ultrasound Vendor API, implemented using an Amazon API Gateway endpoint for integration with hospital information systems and viewing applications.

For enhanced security and compliance, all data transfers in the solution occur over TLS, and the solution implements RBAC using strict AWS IAM policies and comprehensive audit logging through Amazon CloudWatch. Healthcare providers can access the processed images through secure web interfaces, while administrators can monitor system performance and usage patterns through custom CloudWatch dashboards. The entire architecture is designed to be HIPAA-compliant, and it uses a serverless architecture that can scale to hundreds of thousands of active devices and high volumes of imaging data while maintaining performance and security.

This implementation significantly reduces on-premises infrastructure requirements, automates routine data management tasks, and provides healthcare providers with rapid access to critical diagnostic images while helping customers comply with their regulatory obligations and data security requirements. The solution can be easily integrated with existing Picture Archiving and Communication Systems (PACS) and hospital Electronic Medical Record Systems (EMRs) through standard healthcare protocols.

Figure 2 – Ultrasound device data management architecture

1. Ultrasound device connects to AWS IoT Core using MQTT
2. IoT Core validated the device identity using X.509 certificates managed by AWS Certificate Manager
3. IoT Core sends the data to an AWS Lambda that performs image validation/compression/metadata extraction
4. Processed data stored in Amazon Simple Storage Service (Amazon S3)
5. Metadata is stored in Amazon DynamoDB in parallel to step #4
6. Amazon CloudWatch logs and metrics are generated: Processing duration, Success/failure rates, Storage usage, Device connection status
7. Amazon QuickSight is used to analyze the data such as device usage patterns, processing times

Conclusion

The EU Data Act represents a significant shift in how healthcare organizations must approach IoT device data management. As we’ve explored, this legislation introduces new requirements for data access, sharing, and transparency that may directly impact medical device manufacturers and healthcare providers utilizing connected products. The intersection of these requirements with existing healthcare regulations creates a complex landscape that demands thoughtful implementation of technical solutions. The reference architecture we’ve outlined demonstrates how AWS services can help organizations build secure data pipelines that address these regulatory challenges while maintaining the high standards of data protection essential in healthcare settings.

In Part 2 of this series, we’ll delve deeper into practical implementation strategies for EU Data Act compliance. We’ll explore specific solution architectures for data discovery, classification, privacy controls, and access management.

Note: This blog post does not constitute legal advice and should not be relied on as legal advice. AWS encourages its customers to obtain appropriate advice on their implementation of privacy and data protection environments, and more generally, applicable laws relevant to their business. Customers are responsible for making their own independent assessment of the information in this blog post. This blog post: (a) is for informational purposes only, (b) represents current AWS product offerings and practices, which may be subject to change, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.