Connected Medical Devices: 7 Cybersecurity Decisions That Should Start at the Design Stage
Key takeaways
Medical device cybersecurity is a patient safety issue, not only an IT or data issue.
Architecture, components and update methods are hard to change after development, so security has to be decided during design.
Seven early decisions set how secure a connected device will be across its whole life.
Regulators, especially the US FDA, now expect a security plan, an SBOM and a patching process in the premarket submission.
A connected medical device does not stop being a medical device because it is online. An infusion pump, a patient monitor, a glucose sensor or a diagnostic wearable still has to deliver the right therapy or the right reading. Once it connects to a hospital network, a phone app or the cloud, it also becomes something that can be probed, misused or attacked.
The consequences go beyond stolen data. A compromised device can give wrong readings, stop working at a critical moment or become an entry point into a hospital network. That is why medical device cybersecurity has to be treated as part of product safety.
Many teams still handle it late, as a test before launch. By then the hardware is chosen, the software architecture is fixed and the cost of change is high. The better approach is to treat security as a design input, in the same way you treat usability, sterilisation or biocompatibility.
This guide is written for CTOs, engineering leaders, connected-device startups and medical device companies. It covers seven decisions to make at the design stage, how to make them, and the mistakes to avoid.
Why the design stage matters
Every product goes through a point after which changes become expensive. For hardware, it is tooling and component selection. For software, it is the architecture and the platform choice. For regulated devices, it is also verification and validation, because a change can mean repeating tests and updating documents.
Security decisions sit in exactly these areas: which processor and operating system to use, how components talk to each other, how updates are delivered, what is stored on the device. If these choices are made without security in mind, fixing them later usually means redesign, not a patch.
For a view of how the full lifecycle fits together, see What Is the Medical Device Development Process? 9 Steps From Idea to Manufacturing.
Decision 1: Define the threat model before the design is final
What to decide: Who could attack the device, through which routes, and what harm could result.
Why it matters: Without a threat model, security work becomes a list of generic controls. With one, you spend effort where the real risk is.
How to do it:
Draw the system, including the device, its sensors, the mobile app, the cloud service, the hospital network and any service tools.
List every interface: USB, Bluetooth, Wi-Fi, cellular, serial ports, debug ports, APIs.
List who touches the system: patients, nurses, biomedical engineers, service technicians, IT teams.
For each interface, ask what could go wrong. A structured method such as STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) helps you cover the ground.
Link each threat to a patient safety outcome and rate it. This connects security to the risk management you already do under ISO 14971.
Common mistakes:
Doing the threat model once and never updating it when features change.
Considering only external hackers and ignoring misuse by insiders or accidental errors.
Keeping security risk separate from safety risk, so the two teams never meet.
If you are still shaping the concept, Before You Build a Medical Device: 7 Questions Every Innovator Should Ask is a good place to start.
Decision 2: Design an architecture that limits the damage
What to decide: How the system is divided, and what happens when one part fails or is compromised.
Why it matters: It is wise to assume that some component will eventually be compromised. Good architecture makes sure that a failure in one place does not become a patient safety event.
How to do it:
Separate critical from non-critical functions. The part that controls therapy should not share a process or memory space with the part that handles Wi-Fi or a display app.
Apply least privilege. Each component gets only the access it needs.
Use a secure boot process. The device should check that its firmware is authentic before running it. A hardware-backed root of trust is stronger than a software-only check.
Close what you do not use. Disable debug ports, unused services and test interfaces in production units.
Fail safely. If a connection drops or data looks corrupted, the device should move to a defined safe state and keep delivering essential function where possible.
Common mistakes:
Leaving debug interfaces open on shipped units.
Running everything on one processor with no separation.
Choosing a low-cost component without checking whether it supports secure boot or encryption.
Decision 3: Build authentication and access control that clinicians will actually use
What to decide: Who can do what on the device, and how they prove who they are.
Why it matters: Shared or default passwords are one of the most common weaknesses in connected devices. At the same time, security that slows clinical work gets bypassed.
How to do it:
No default or shared passwords. Each device should have unique credentials, or require setting them at first use.
Use role-based access, for example clinician, technician and administrator, with different rights.
Protect service and maintenance modes with stronger authentication, since these usually have the most power.
Think through emergency access. In a critical situation a clinician must be able to act, so define a controlled way to do that and keep a record of it.
Log security-relevant events such as logins, failed attempts, configuration changes and updates.
Test with real users. A control that works on paper can fail on a busy ward. This is one of the reasons technically strong medical devices still fail in hospitals. The principles in Lessons in Human-Centered Design: Why the Best Healthcare Products Feel Invisible apply to security as much as to the interface: the safest control is the one people can use without thinking.
Common mistakes:
Forcing long passwords on a touchscreen used with gloves.
Hard-coding one service password across all devices.
Adding no logging, which makes any later investigation impossible.
Decision 4: Protect data at rest, in transit and in the cloud
What to decide: What data the device collects, where it lives, how it moves and who can see it.
Why it matters: Health data is sensitive, and the integrity of the data matters as much as privacy. A reading that has been changed in transit can lead to a wrong clinical decision.
How to do it:
Collect only what is needed. Data you never collect cannot be leaked.
Encrypt data in transit using established protocols such as TLS, and encrypt stored data on the device and in the cloud.
Use standard, proven cryptography. Do not design your own algorithms.
Manage keys properly. Store them in protected hardware where possible and make sure each device has its own keys, so one compromised device does not expose all others.
Check integrity. Use signatures or checksums so the receiving system can detect changed data.
Plan for privacy law. In India, the Digital Personal Data Protection Act, 2023 sets duties for handling personal data. If you sell abroad, other regimes such as HIPAA in the US or GDPR in Europe may apply.
Common mistakes:
Using the same encryption key in every device.
Encrypting in transit but leaving data readable on a stolen device.
Sending data to third-party cloud services without checking their security.
Decision 5: Plan secure software updates from day one
What to decide: How the device receives fixes after launch, and how that is kept safe.
Why it matters: Vulnerabilities will be found after launch, in your code or in the components you use. What matters is whether you can fix them quickly and safely. In 2017, the FDA announced a firmware update for around 465,000 implantable pacemakers to address cybersecurity vulnerabilities. Many patients had to visit a clinic to receive it. A built-in, safe update path makes this kind of response easier.
How to do it:
Sign every update. The device should accept only firmware that is verified as authentic.
Support rollback. If an update fails, the device should return to a working version.
Protect therapy. Updates should not interrupt critical treatment, and the device should be clear about when it is safe to update.
Decide the delivery method. Over-the-air updates are convenient but need strong protection. Updates by a technician on site are slower but sometimes safer for critical devices.
Plan the regulatory side. Know in advance which kinds of updates are routine and which need a regulatory review.
Common mistakes:
Shipping with no update mechanism because it adds cost.
Accepting unsigned firmware over a local connection.
Updates that need the device to be taken out of service for long periods, which hospitals then avoid.
Decision 6: Keep a software bill of materials (SBOM)
What to decide: How you will track every software component in the device and its version.
Why it matters: Modern devices rely heavily on third-party and open-source software, such as the operating system, libraries and communication stacks. When a new vulnerability is announced in one of these, you need to know within hours whether your device is affected. An SBOM makes that possible.
How to do it:
Generate the SBOM as part of the build process, so it stays current instead of being a document written once.
Record component names, versions, suppliers and licences.
Match the SBOM against vulnerability databases regularly.
Ask suppliers for their own component lists and their support timelines.
Avoid components that are no longer maintained.
Regulatory link: In the US, Section 524B of the Federal Food, Drug, and Cosmetic Act applies to “cyber devices”. Manufacturers must include in their premarket submissions a plan to monitor and address vulnerabilities, processes to provide updates and patches, and an SBOM. The FDA has been enforcing this for new submissions since 2023.
Common mistakes:
Treating the SBOM as paperwork done only at submission time.
Ignoring components pulled in indirectly by other libraries.
Using an old operating system version because it was already approved.
Decision 7: Plan post-market monitoring and end-of-support
What to decide: Who watches for new threats after launch, how customers are informed, and how long each version is supported.
Why it matters: A device may stay in a hospital for ten years or more, while the threats keep changing. Hospitals also need to know when a product will no longer receive security updates, so they can plan replacement.
How to do it:
Name an owner for post-market security, with a process to receive vulnerability reports from researchers and customers. This is often called a coordinated vulnerability disclosure policy.
Define how quickly you will assess and respond to different levels of severity.
Prepare customer communication in advance: what to tell hospitals, how fast and through which channel.
Publish the support period for each product version, and the end-of-support plan.
Share security information with customers, including recommended network setup and what the hospital IT team is expected to do.
Common mistakes:
No contact point for reporting a vulnerability.
No agreed owner, so a report sits in an inbox.
No end-of-support date, so hospitals keep using an unsupported device without knowing the risk.
Seven decisions at a glance
Decision | What to settle early | Risk if skipped |
Threat model | Attackers, interfaces, safety impact | Gaps found late, costly redesign |
Architecture | Separation of critical functions, secure boot | One breach reaches patient safety |
Access control | Roles, unique credentials, emergency access | Misuse or workarounds in the ward |
Data protection | Encryption, key management, data minimisation | Privacy exposure, altered data |
Secure updates | Signed firmware, rollback, delivery method | Devices that cannot be patched |
SBOM | Component and version list | Slow response to new vulnerabilities |
Post-market plan | Monitoring, disclosure policy, support timeline | Unmanaged risk after launch |
Decision | What to settle early | Risk if skipped |
When to do what in the development process
Development stage | Security activity |
Concept and requirements | Initial threat model, security requirements, regulatory plan |
Architecture and design | Secure architecture, access control design, key management |
Development | Secure coding, code review, SBOM generation, dependency checks |
Verification | Security testing, vulnerability scanning, penetration testing |
Design transfer and launch | Final SBOM, update process ready, customer security documentation |
Post-market | Vulnerability monitoring, patching, end-of-support communication |
Remember that security items should be locked in before the design is transferred. What Actually Changes Between Prototype and Production in Medical Devices explains why late changes at this point are so costly.
Regulations and standards to know
The details depend on your device class and target market. The main references are:
US FDA: Premarket cybersecurity guidance, which expects a secure product development framework, a threat model, a security risk assessment and an SBOM, together with the requirements of Section 524B.
EU MDR: The general safety and performance requirements include software lifecycle and IT security expectations. The Medical Device Coordination Group has issued guidance on cybersecurity.
IEC 81001-5-1: Security activities in the health software lifecycle.
IEC 62304: Medical device software lifecycle processes.
ISO 14971: Risk management, which should cover security-related harm.
IEC 60601-4-5: Security requirements for medical electrical equipment.
AAMI TIR57: Principles for medical device security risk management.
IMDRF guidance: International principles and practices for medical device cybersecurity.
If you plan to sell in both India and the US, it helps to understand how the approval routes differ. Our comparison, FDA 510(k) vs CDSCO Approval: 7 Key Differences If You Want to Sell in the US and India, covers this. Always confirm current requirements for your device with a regulatory consultant before you finalise your plan.
Common mistakes to avoid
Treating security as a final test. By then, the architecture is already fixed.
Separate teams for safety and security. Both look at the same hazards and should share one risk process.
Relying on the hospital network alone. Hospital networks can be compromised, so the device needs its own protection.
Ignoring old components. An unmaintained library in your product is your responsibility.
No plan after launch. Security is a continuing duty, not a one-time task.
Making security hard to use. Controls that get bypassed provide no protection.
Final Thoughts: Build Medical Device Cybersecurity Into the Design, Not Around It
Strong medical device cybersecurity is not one feature. It is the result of many connected decisions made early: a clear threat model, an architecture that limits damage, usable access control, protected data, safe updates, a living SBOM and a plan for the whole product life. Teams that make these decisions at the design stage spend less on redesign, move through regulatory review with fewer surprises and give hospitals a device they can trust.
For a wider view of the choices that shape a product, read Medical Device Design: 7 Decisions That Can Make or Break a Product. If you are building a connected device and want security designed in from the start, talk to our team through iNSPIRE Engineering – service page link.
FAQs
1. What is medical device cybersecurity?
It is the set of design choices and processes that protect a medical device, and the data it handles, from unauthorized access, misuse or attack, while keeping the device safe and effective for patients.
2. Why should cybersecurity start at the design stage?
Architecture, components and the update method are difficult to change after development. Deciding them early costs less and lowers the risk of redesign or delay in approval.
3. What is an SBOM in a medical device?
A software bill of materials is a list of all software components in the device, including third-party and open-source ones, with their versions. It helps a manufacturer respond quickly when a new vulnerability is found.
4. Does cybersecurity apply to devices that are not implantable?
Yes. Any device that connects to a network, a phone or the cloud, or that holds software and data, can carry cybersecurity risk. This includes monitors, pumps, imaging systems and wearables.
5. Who is responsible for medical device cybersecurity, the manufacturer or the hospital?
Both. The manufacturer is responsible for secure design, updates and communication. The hospital is responsible for its network, user management and applying updates. Clear documentation from the manufacturer makes this shared responsibility work.
About the Author
Kunal Bijlani is the Co-founder of Inspire Design, a product design and engineering company working with clinicians, startups and healthcare companies on medical device design and development.
Through Inspire Design's work across 60+ healthcare product development projects, Kunal has worked with teams moving from early clinical ideas through product design, engineering, prototyping and Design for Manufacturing.
Comments