If your medical device connects to anything — Wi-Fi, Bluetooth, cellular, USB, a hospital network, or a phone app — cybersecurity is now a premarket requirement, not a nice-to-have. The FDA expects a cyber device submission to include a threat model, a software bill of materials, security architecture documentation, evidence of security testing, a plan for monitoring and patching vulnerabilities after launch, and security information in the labeling. Devices that arrive without this documentation are a common cause of submission delays, and the fix is almost always architectural, which means it is expensive to retrofit.

Projects House is an engineering firm, not a regulatory consultancy. This article is educational only and is not regulatory advice; confirm current expectations with qualified regulatory support.

Why a regulator cares about your device's security

For a medical device, a security failure is a safety failure. A compromised infusion controller, a spoofed sensor reading, a disabled alarm, or a bricked implant programmer are patient-harm scenarios, not IT inconveniences. Regulators therefore treat security as a component of device safety and effectiveness rather than as a separate commercial concern.

There is a second dimension: the device sits on someone else's network. Hospital IT departments run security assessments before purchasing, and a device that cannot answer their questionnaire does not get bought no matter what its clearance says. In practice, hospital procurement enforces security at least as aggressively as the regulator does.

What is actually expected

  • A threat model. A structured analysis of assets, entry points, threats, and mitigations covering the whole system — device, app, cloud, and service interfaces — not just the firmware.
  • Security risk management, integrated with but distinct from safety risk management. Security risk is driven by adversary capability rather than probability of random failure, so it needs its own reasoning while feeding conclusions back into the ISO 14971 risk file.
  • A software bill of materials (SBOM). A machine-readable inventory of every third-party and open-source component with version and support status. This is now table stakes, and it must be maintained, not generated once.
  • Security architecture views. Diagrams and descriptions showing trust boundaries, data flows, authentication points, and update paths.
  • Security testing evidence. Vulnerability scanning, fuzz testing of interfaces, static analysis, and penetration testing appropriate to risk, with findings resolved or justified.
  • A post-market plan. How you will monitor vulnerability disclosures affecting your components, triage them, and deliver patches within a defined timeframe, plus a coordinated vulnerability disclosure process.
  • Labeling content. What the operator needs to know: network requirements, ports and protocols, hardening guidance, backup and recovery, and end-of-support dates.

Design principles that save pain later

  • Minimize the attack surface. Every interface you do not ship is an interface you never have to defend. Disable debug ports, unused radios, and default services in production builds.
  • Authenticate everything. No unauthenticated commands, no shared default credentials, no "trusted" local network assumption. Per-device credentials provisioned at manufacture.
  • Encrypt in transit and at rest, using standard vetted implementations with proper certificate validation. Rolling your own crypto is the classic self-inflicted wound.
  • Separate safety from connectivity. The most valuable architectural decision available: put safety-critical control on a component that cannot be reached from the network, with a simple validated interface between it and the connected side. Then a network compromise cannot directly command unsafe behavior. Choosing the right processor split is part of the microcontroller versus embedded Linux decision.
  • Fail safe, not open. Loss of connectivity, an expired certificate, or a rejected update must leave the device in a defined safe state.
  • Protect the boot chain and stored code, so an attacker with physical access cannot substitute firmware — see secure boot and firmware encryption.
  • Log security-relevant events in a way that survives a reboot and can be retrieved for investigation.

Secure by design starts at the block diagram

The reason security cannot be added late is that most of the important controls are architectural. Secure boot needs a processor with the right hardware features and a key provisioning step in manufacturing. Signed updates need a key management scheme and a factory process. Per-device credentials need a provisioning station on the production line. Separation of safety from connectivity needs a second processor. Each of these is a schematic-level and supply-chain-level decision, not a firmware sprint.

Choose components with security in mind from the start: a part with a hardware root of trust, secure key storage, and a vendor commitment to long-term support and security patches. Selection criteria are covered in how to choose a microcontroller, and the general principles transfer from consumer IoT — see IoT security for connected products.

Remote updates: mandatory, and handled carefully

A device you cannot patch is a device with a permanent vulnerability, so a working update mechanism is effectively required. But an update path is itself the most attractive attack surface on the product: whoever controls updates controls the device. The non-negotiables are cryptographic signature verification before installation, rollback protection against downgrade attacks, atomic installation with a recovery path if power is lost mid-update, and a defined behavior for a device in clinical use (never mid-therapy). Update behavior is also a validated function under design controls, not a convenience feature. Mechanics are covered in OTA firmware updates.

Documentation inside the design file

Security artifacts belong in the design history file, traced like any other requirement: security requirements derived from the threat model, design outputs that implement them, verification evidence that they work, and change records when they evolve. Built this way, the premarket security section is an extract from work you already did. Built afterwards, it is archaeology. The traceability discipline is the same one described in FDA design controls.

Balancing security against clinical usability

Security controls that clinicians route around provide no protection. A complex login on a device used during an emergency will be defeated with a taped-up note of the password. Good designs put strong authentication on configuration and data access while keeping the immediate clinical function fast, and handle authentication at the level of the department badge system or the hospital identity provider rather than inventing a new one. Usability engineering and security engineering must be done together, and both are documented.

After launch

Post-market security is an ongoing operational commitment: watch vulnerability feeds against your SBOM, maintain a disclosure channel, triage and patch on a defined clock, and report as required. It also means deciding and publishing a support lifetime, because a device sold with a five-year clinical life and a component whose vendor stops issuing patches after two years is a problem you created at design time. If the device handles patient data, privacy obligations run in parallel with security ones — the shape of that work is outlined in privacy compliance for connected products.

The bottom line for a founder

Budget cybersecurity as a real work package with real hours and a real testing line item, and make the architectural choices — processor split, root of trust, update path, provisioning — before the first schematic is released. That sequence costs a fraction of what the same decisions cost after a submission has already been questioned.

Projects House develops connected medical devices with the security architecture designed in from the block diagram, producing the threat model, SBOM, and verification evidence as the engineering happens. Tell us about your device through the contact form to discuss it.