How to Build IoMT Devices That Get Certified in 2026

Key takeaways

• The IoMT market is projected to reach $124 billion in 2026 and $1.9 trillion by 2034, driven by chronic disease management, telehealth adoption, and sensor miniaturization.
• 93% of healthcare organizations experienced a cyberattack in the past year, and the average breach now costs $7.4 million, making cybersecurity a foundational design requirement.
• The FDA’s June 2025 cybersecurity guidance raises the compliance bar, while the EU’s December 2025
• Medical Devices Regulation (MDR) simplification proposal streamlines the process but maintains rigorous technical standards.
• IoMT is a full-stack engineering challenge spanning hardware, firmware, connectivity, cloud, and EHR integration, and most organizations hit a “hardware ceiling” or “software ceiling” that only a compliance-first partner can bridge.
• Rust programming for safety-critical firmware and healthcare data lakes for predictive intelligence are the two investments that will separate leaders from laggards in the next five years.

The average hospital now operates more than 350,000 connected medical devices, from infusion pumps and cardiac monitors to MRI machines and smart inhalers. That number has grown by double digits every year for the past decade, and the Internet of Medical Things (IoMT) market is projected to reach $124 billion in 2026, up from roughly $100 billion in 2025. By 2034, industry analysts expect it to surpass $1.9 trillion.

Yet for every headline about growth, there is a quieter, more consequential story. 93% of healthcare organizations experienced at least one cyberattack in the past 12 months, and most hospital security teams still lack full visibility into the devices on their own networks. In 2025 alone, the healthcare sector recorded a 55% year-over-year surge in cyber incidents. The cost of a single healthcare data breach now averages $7.4 million.

At Yalantis, we work at the intersection of these two realities every day: explosive device adoption on one side, persistent security exposure on the other. In our recent article on integrating AI and ML into regulated medical devices, we explored how intelligent algorithms are entering the clinical workflow under strict FDA and EU regulatory oversight. This piece widens the lens to the Internet of Medical Things in healthcare as a whole, covering the engineering, IoMT security, and compliance decisions that determine whether a connected medical product reaches patients or stalls in regulatory review.

Below, we break down the IoMT landscape layer by layer, from market dynamics and core technologies to the regulatory shifts reshaping the field in 2026.

The Internet of Medical Things refers to the ecosystem of connected medical devices, software platforms, and health IT infrastructure that collect, transmit, and analyze patient data without requiring direct human-to-machine interaction at every step. It covers everything from a glucose monitor on a patient’s wrist to a cloud-based analytics engine that flags early signs of sepsis across an entire hospital network.

When we talk with engineering leaders about IoMT architecture, we frame it around three interdependent layers. Each one carries its own technical requirements, compliance obligations, and failure modes, and a weakness in any single layer can compromise the entire system.

Layer 1: Perception (devices and sensors)

This is the physical layer where Internet of Medical Things devices capture clinical data: smart sensors, wearable devices, implantable devices, and bedside monitoring systems. Examples include blood pressure monitors, smart inhalers that log medication adherence, connected imaging systems that stream diagnostic scans to remote specialists, and continuous glucose monitors that relay blood sugar levels every five minutes. Companies with in-house hardware R&D capabilities, including PCB design and firmware development, hold a significant advantage here because sensor accuracy and power management directly determine clinical utility.

Layer 2: Network (connectivity)

The perception layer only matters if data can move reliably and securely to the systems that act on it. That brings us to the connectivity infrastructure. The protocol choice depends on the clinical context:

• 5G networks – critical for latency-sensitive applications such as remote-assisted robotic surgery, where even a 50-millisecond delay can affect outcomes
• Bluetooth Low Energy (BLE) and Wi-Fi 6 – the standard for patient wearables and in-room monitoring, where power consumption matters more than raw bandwidth
• Near-Field Communication (NFC) – handles short-range data exchanges in point-of-care settings

Layer 3: Application (cloud, analytics, and EHR integration)

Once health data reaches the application layer, it needs to be processed, stored, and delivered to clinicians in a format they can act on. This is the Internet of Medical Things software layer, where cloud platforms, data lakes, and electronic health record (EHR) integrations turn raw medical data into actionable clinical intelligence. Interoperability standards like HL7 FHIR (Fast Healthcare Interoperability Resources) serve as the connective tissue between devices and enterprise systems such as Epic and Oracle Health (formerly Cerner). Without robust FHIR implementation, a connected device becomes an isolated data silo, which is exactly the opposite of what IoMT is supposed to accomplish.

The critical takeaway for decision-makers: IoMT is a full-stack engineering challenge. A wearable sensor is only as useful as the firmware that governs its sampling rate, the connectivity protocol that ensures reliable transmission, and the cloud architecture that processes sensitive data in compliance with HIPAA and GDPR. Understanding this from the outset shapes every architectural and partnership decision that follows.

With the three-layer architecture in mind, the next question is scale: how large is the opportunity, and where is it headed? The Internet of Medical Things market is expanding at a compound annual growth rate of roughly 24–25%, with North America accounting for the largest regional share at approximately $29 billion in 2026. The growth is driven by converging forces: the global rise in chronic disease prevalence, post-pandemic adoption of telehealth, an aging population requiring continuous monitoring, and advances in medical sensor miniaturization.

Two Internet of Medical Things trends in particular are reshaping the competitive landscape for our clients and the broader market. Both carry direct implications for how IoMT products should be engineered.

Trend 1: AI on the edge

TinyML, the deployment of artificial intelligence and machine learning models directly onto low-power microcontrollers embedded in medical devices, is reducing the need to stream raw data to the cloud for analysis. A smart cardiac monitor that can detect arrhythmia locally and only transmit an alert when it identifies an anomaly uses less bandwidth, reduces latency, and lessens the attack surface for cyberthreats. For device OEMs, this means firmware development is no longer a simple embedded-C exercise; it increasingly demands competency in edge inference frameworks and model optimization for constrained hardware.

Trend 2: The “hospital at home” model and RPM reimbursement

The second trend is financial as much as clinical. Remote Patient Monitoring (RPM) reimbursement codes in the United States now allow providers to bill over $1,000 per patient per year for qualifying remote monitoring services through CMS CPT codes 99453, 99454, 99457, and 99458. Medicare’s expansion of RPM eligibility has created direct financial incentives for healthcare systems to invest in telemedicine services and real time monitoring platforms that improve patient care. For digital health SaaS companies, this creates a clear path to revenue, but only if their platforms meet the interoperability and clinical evidence standards that payers and regulators require.

The market opportunity is real, but so is the execution gap. The medical internet of things challenges are substantial: building a connected medical device that passes regulatory review, integrates with existing hospital IT infrastructure, and withstands adversarial cybersecurity conditions is a fundamentally different challenge from building a consumer wearable or an industrial IoT sensor. Organizations that underestimate this difference tend to discover it at the FDA submission stage, which is an expensive place to learn. The next two sections explain why.

Connected medical devices that make it through regulatory approval and into clinical use share a common engineering discipline: their technology choices are driven by compliance and patient safety requirements, not by developer preference or time-to-market pressure. The market section above explained why IoMT is growing. This section addresses the Internet of Medical Things technology choices that determine how the devices that succeed are actually built.

Device-level engineering and IEC 62304

At the device level, sensor selection and integration determine clinical validity. A connected pulse oximeter intended for continuous SpO2 monitoring in an ICU faces different accuracy, sampling rate, and noise-rejection requirements than a consumer fitness tracker. The firmware controlling these IoMT devices must conform to IEC 62304 (the international standard for medical device software lifecycle processes), which mandates rigorous documentation, risk traceability, and verification at every stage of development.

Connectivity: choosing the right protocol

Connectivity choices flow directly from the clinical context. The table below summarizes the trade-offs we evaluate with clients when selecting a protocol:

Interoperability: FHIR as a market access requirement

Protocol selection gets data off the device, but interoperability determines whether that data reaches clinicians. HL7 FHIR has become the de facto standard for health data exchange. No healthcare system running Epic or Oracle Health will integrate a device that cannot communicate in FHIR. The U.S. 21st Century Cures Act’s information blocking provisions make it a legal requirement for healthcare providers to support standardized data sharing. For device manufacturers and platform developers, FHIR compliance is a market access requirement, not a feature request.

The Rust differentiator in safety-critical firmware

One technical differentiator gaining attention among engineering leaders is the use of Rust for safety-critical firmware development. Traditional medical device firmware has been written in C or C++, languages that offer low-level hardware control but are prone to memory safety errors such as buffer overflows and use-after-free bugs. In life-critical devices, these bugs can have fatal consequences. Rust eliminates entire categories of memory safety vulnerabilities at compile time. Few development partners currently offer production-grade Rust expertise for embedded medical systems, which makes it a meaningful capability differentiator. At Yalantis, we have invested heavily in Rust as part of our firmware engineering practice precisely because of this safety advantage.

The technology stack, then, defines the engineering foundation. But even a well-architected device will fail to reach the market if it cannot meet the security and regulatory standards that are tightening rapidly on both sides of the Atlantic.

Internet of Medical Things security is in a state of escalating crisis, and the numbers paint an urgent picture. Understanding these Internet of Medical Things risks is essential because of the architectural decisions that every IoMT project must make from day one.

The threat landscape in numbers

• 89% of healthcare organizations have the riskiest IoMT devices, those linked to active ransomware campaigns, on their networks
• $7.4 million: average cost of an Internet of Medical Things breach in 2025, making healthcare the most expensive sector globally
• 55% year-over-year surge in cyber incidents (8,903 total) targeting IoMT devices and healthcare systems in 2025

These numbers explain why healthcare regulations on both sides of the Atlantic are getting significantly stricter. Two developments in particular stand out.

United States: FDA’s June 2025 cybersecurity guidance

The FDA issued updated cybersecurity guidance on June 27, 2025, building on the statutory requirements established by Section 524B of the FD&C Act. The new framework makes cybersecurity a lifecycle obligation for all connected medical devices. Key requirements include:

• Software Bill of Materials (SBOM) as part of premarket submissions
• Threat modeling and risk assessment processes
• Secure design architecture demonstrated in submission documentation
• Vulnerability management programs maintained throughout commercial life

The FDA has stated it may refuse to accept premarket submissions that lack adequate cybersecurity documentation. In practical terms, a device manufacturer that treats IoMT security as a final-stage checklist item will face submission delays, additional information requests, or outright rejection.

European Union: the December 2025 MDR simplification proposal

On December 16, 2025, the European Commission published a legislative proposal to simplify the Medical Devices Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR). The proposal aims to reduce administrative burden, extend certificate validity, digitalize regulatory procedures, and introduce new pathways for breakthrough and orphan devices. It also reclassifies certain lower-risk medical software to Class I, reducing the conformity assessment burden for qualifying applications. The Commission estimates overall cost savings of approximately €3.3 billion per year from the revision. For device OEMs operating in European markets, this is a significant development: a more predictable and streamlined regulatory process, but one that still demands rigorous technical documentation and quality management under ISO 13485.

The practical implication: compliance-first architecture

Taken together, the threat data and regulatory direction point to a single conclusion. IoMT security, data security, and compliance must be engineered into the product architecture from the earliest design phase. The frameworks that matter most for IoMT devices:

• ISO 13485 – quality management systems for medical devices
• IEC 62304 – software lifecycle processes
• IEC 62443 – industrial network and system security controls
• HIPAA / GDPR – data protection frameworks

All of these must be part of the initial requirements specification. Treating them as separate workstreams that happen in parallel with product development is the most common source of costly rework. With this regulatory context established, the question becomes: where is IoMT delivering real results today?

Three Internet of Medical Things examples are already producing measurable clinical and financial returns: remote patient monitoring, smart hospital asset tracking, and cold chain logistics. We chose these three because they represent the most commercially mature use cases in the market today, and each one illustrates the full-stack, compliance-first approach we described above.

1. Chronic disease management through remote patient monitoring

Connected wearable devices like blood pressure cuffs, continuous glucose monitors, and pulse oximeters enable clinicians to track patients with hypertension, diabetes, and COPD from their homes, improving patient care by intervening before conditions deteriorate to the point of hospital admission. Published studies consistently show that these IoMT devices can reduce hospital readmission rates by 50% or more for high-risk patient populations. For health systems, the economics are compelling: RPM reimbursement codes, combined with avoided emergency department visits and shortened inpatient stays, generate measurable savings that often justify the platform investment within the first year of deployment.

2. Smart hospital operations and asset tracking

Real-Time Location Systems (RTLS) and other monitoring systems using RFID and Bluetooth beacons track the location and status of wheelchairs, infusion pumps, portable monitors, and staff across a hospital campus. Industry estimates indicate that large health systems can achieve millions of dollars in annual savings through RTLS-based asset management by reducing equipment search time, preventing hoarding, and improving operational efficiency in capital purchasing decisions. Connected infusion pump systems that integrate with pharmacy and EHR workflows reduce medication administration errors and create audit trails that satisfy Joint Commission requirements.

3. Pharmaceutical and vaccine supply chain monitoring

IoMT devices embedded in cold chain logistics track temperature, humidity, and location throughout the distribution process, generating continuous compliance documentation that regulatory agencies increasingly expect. For pharmaceutical companies requiring strict cold chain integrity, connected monitoring eliminates the risk of manual logging errors and provides real-time alerts when storage conditions deviate from acceptable ranges.

Across all three use cases, the value proposition depends on the same underlying capabilities: reliable device hardware, secure and standards-compliant data transmission, and seamless integration with the enterprise health IT systems that clinicians and administrators actually use. That brings us to a practical question that every organization in this space must answer.

In our experience building IoMT devices across dozens of engagements, the pattern is remarkably consistent: software teams underestimate hardware, hardware teams underestimate software, and both underestimate compliance. The decision to build in-house, buy off the shelf, or partner with a specialized firm comes down to where your core competencies end and your execution risk begins.

The software company’s problem

Software companies entering the medical device space consistently underestimate the hardware engineering challenge. Designing a PCB for a wearable cardiac monitor requires analog signal processing expertise, power management optimization for multi-day battery life, RF design for Bluetooth or cellular radios, and mechanical engineering for biocompatible enclosures. These are specialized disciplines that cannot be staffed on short notice.

The hardware company’s problem

Hardware companies face the mirror-image challenge. They can build the device but struggle with cloud architecture, data management, mobile application development, EHR integration, and the ongoing software maintenance that regulatory agencies now expect throughout a product’s commercial life. The FDA’s 2025 cybersecurity guidance makes it explicit: manufacturers must maintain vulnerability management programs and SBOM documentation for as long as the device is on the market.

What a full-cycle partner brings to the table

This “hardware ceiling” for software teams and “software ceiling” for hardware teams explains why a growing number of organizations building IoMT devices choose to partner with a firm that can own the entire stack. The capabilities that matter most:

• Hardware R&D – PCB design, prototyping, certification testing
• Embedded firmware – ideally with Rust and C/C++ expertise for safety-critical applications
• Cloud backend and data pipeline architecture
• Mobile and web application development
• Compliance engineering (ISO 13485, IEC 62304, HIPAA, GDPR) as a unified discipline

A compliance-first engineering approach is particularly valuable during the regulatory submission process. Automated documentation tools that generate traceability matrices linking requirements to design inputs, design outputs, verification, and validation artifacts can reduce FDA submission preparation time by months. For EU MDR submissions, having a partner already certified under ISO 13485 and familiar with notified body expectations eliminates one of the most common sources of delay.

The cost of a wrong partnership decision shows up at the worst possible moment: during regulatory review. Choosing a generalist software agency that lacks medical device experience typically results in gaps in design history files, incomplete risk management documentation, and architecture decisions that conflict with IEC 62304 classification requirements. The rework cost to fix these issues after the fact almost always exceeds the cost of working with a specialized Internet of Medical Things company from the beginning. For organizations committed to getting this right, the question becomes: what should you invest in now to stay ahead of the curve?

The future of Internet of Medical Things will be shaped by two technical investments that separate leaders from laggards over the next three to five years. We are already seeing early movers gain competitive advantages in both areas, and the regulatory trajectory suggests these advantages will compound over time.

Investment 1: Rust for safety-critical firmware

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the White House Office of the National Cyber Director have both called for a shift toward memory-safe programming languages in critical infrastructure, and medical devices fall squarely within that scope. Rust’s compile-time memory safety guarantees eliminate buffer overflows, dangling pointers, and data races, which are among the most common sources of exploitable vulnerabilities in embedded systems. For medical device firmware, where a memory corruption bug could affect drug dosing or patient monitoring accuracy, this is a patient safety improvement as much as a cybersecurity one. Organizations that invest in Rust capabilities now will be better positioned as regulatory expectations around memory-safe languages formalize.

Investment 2: Healthcare data lakes for predictive intelligence

Most IoMT deployments today focus on capturing and transmitting data. The next phase is turning that medical data into predictive models: early detection of patients at risk of deterioration before symptoms become clinically apparent, predicting device maintenance needs before failures occur, and generating population-level insights that inform public health decisions. This requires data engineering infrastructure that can ingest, normalize, and store health data from thousands of heterogeneous IoMT devices at scale, while maintaining the provenance, access controls, and audit trails that HIPAA and GDPR require.

The organizations that will capture the most value from IoMT in the coming decade are those building for both regulatory resilience and technical adaptability, investing in engineering disciplines, development processes, and technology choices that can absorb the inevitable changes in standards, threats, and clinical expectations without requiring a full architecture rebuild.

Capturing value in the IoMT space requires more than connecting a sensor to the cloud. Building IoMT devices that improve patient care demands a disciplined, compliance-first engineering approach that integrates hardware design, secure firmware development, standards-based interoperability, and regulatory documentation into a single coherent product development process.

The regulatory landscape is shifting fast. The FDA’s 2025 cybersecurity guidance raises the compliance bar, while the EU’s December 2025 MDR simplification streamlines the process but maintains rigorous technical requirements. Both demand that manufacturers build compliance into their architecture from day one.

At Yalantis, we combine in-house hardware R&D with Rust firmware engineering, ISO 13485-certified quality management, and full-stack cloud and mobile development under a single accountability structure. We hold a rare combination of certifications: ISO 13485 + ISO 27001 + ISO 27701. For medical device OEMs, digital health platforms, and hospital networks that need a development partner who understands both the engineering and the regulatory landscape, this integrated approach eliminates the coordination risk and compliance gaps that derail so many IoMT projects.