Side-by-side breakdown
| Dimension | SaMD | SiMD |
|---|---|---|
| Definition | Software as a Medical Device - runs independently (often on a phone, web, or cloud). | Software in a Medical Device - integral to a hardware device (firmware, embedded controllers). |
| Update mechanism | Standard app/OS update channels (App Store, web deploy). | OTA firmware updates, often gated by safety and downtime constraints. |
| Threat surface | Mobile OS APIs, cloud backend, third-party SDKs, network. | Physical access, firmware extraction, side-channel, hardware tamper, RF interfaces. |
| Pen-test scope | App + API + cloud + auth flow. | Above plus hardware-level testing (JTAG/UART, glitching, RF fuzzing) for implantables. |
| Postmarket cadence | Frequent patching is easy and expected. | Patching is slower; secure update mechanism must be designed in from day one. |
| Submission pathway | 510(k) or De Novo (most); rare Class III via PMA. | All classes; PMA common for implantables. |
When to use which
For SaMD, focus the threat model on the mobile + cloud + identity stack. Treat the platform OS as a trust boundary you do not control - certificate pinning and runtime integrity checks are now table stakes.
For SiMD, invest early in a signed-update mechanism. The FDA increasingly questions any cyber device that ships without a documented secure-update path and rollback protection.