In short
A 30-slide workshop for MedTech engineering, product, QA and regulatory teams on five secure-by-design practices that satisfy both FDA reviewers and investor diligence: threat model first, control every interface, keep a living SBOM, score exploitability instead of guessing, and design the patch path before you ship.
Key takeaways
1. Threat model before you architect
A threat model written after the design freezes only documents decisions already made. Draw the data flow diagram first, classify threats with STRIDE, then score them with a separate rubric.
2. Control every interface
Service ports, Bluetooth and Wi-Fi, JTAG and UART, third-party APIs and companion apps each need a named control: authenticate, restrict, or disable. Network segmentation is not a substitute.
3. Treat the SBOM as living inventory
An SBOM generated once for the submission is stale the day it is filed. Record the level of support and end-of-support date per component and tie the SBOM to a vulnerability feed.
4. Score exploitability, not intuition
Use CVSS v4.0 and the FIRST calculator to rate exploitability, pair it with severity of patient harm, and name the protocol, algorithm and configuration instead of saying "it's encrypted."
5. Design the patch and disclosure path before you ship
Section 524B expects regular updates and out-of-cycle fixes for critical issues. Build the update mechanism, coordinated disclosure channel and CISA KEV monitoring into the device from the start.
View the slides
All 30 slides, free to view, download and share as a PDF.
Prefer the file? Open the PDF in a new tab.
Who the workshop is for
Technical founders, engineers, product managers, QA leads and regulatory affairs staff at early and growth-stage MedTech companies. It was delivered to the MedTech Innovator Asia Pacific cohort, where judges and investors assess technical readiness alongside regulators.
The scope check
The session opens with the three conditions in Section 524B(c) that make a product a cyber device: it includes software, it can connect to the internet, and it has characteristics that could be vulnerable to cybersecurity threats. If all three apply, the full premarket cybersecurity package is required.
Worked examples
Each practice is shown on the same fictional device, the Northwind CM-100 cardiac monitor: a DFD3 data flow diagram, a per-interface control map, a filled-out SBOM with two failing rows, an exploitability-by-severity matrix, and one trust boundary traced from threat to control, test and patient harm.
The five gaps we catch before submission
Threat models finished after the architecture froze, segmentation used as the only access control, SBOMs treated as a one-time snapshot, encryption claims with no protocol named, and no documented patch or disclosure path. Each one is a design problem that surfaces at submission.
Go deeper
More sessions on the talks and workshops page.