Threats, controls, architecture views and the testing FDA asks for
Security risk runs beside safety risk rather than inside it — one register, rated on exploitability, joined to the harm exploiting it would cause.
Exploitability, not probability
A safety risk drops probability because software fails deterministically. A security risk drops it for the opposite reason: an attacker chooses when to act. There is no frequency to estimate, and a defence is worth what it costs to defeat.
One register, not two. Identifying a threat and assessing it are the same act, and splitting them produces two documents that must be kept in step. Where exploiting a threat could harm someone, it names the safety risk it creates — the join AAMI SW96 exists to make.
A control is a requirement
IEC 62304 §5.2.2 requires a control implemented in software to be a software requirement. So
controls points at requirement identifiers rather than restating the defence — and
§7.3 verification of risk control measures falls out of the trace that already exists. Nothing
is recorded twice.
A control that cannot be phrased as a requirement is not a software control. Say where it lives instead.
Controls grouped by FDA category
“We have security requirements” is not a coverage claim. A sweep across the eight categories FDA expects an adequate set to draw from is. A category with nothing under it is shown rather than hidden — either a control is missing, or there is a reason this product needs none, and only the sweep tells those apart.
| Category | What it covers |
|---|---|
| Authentication | Proving the origin of information and the identity of an endpoint or operator — at rest, in transit, and for software binaries |
| Authorization | What an authenticated party is permitted to do, enforced where the decision cannot be bypassed |
| Cryptography | Algorithms, key lengths and key management; and the discipline of not inventing any of it |
| Code, data and execution integrity | That code, data and commands are what they were, and that running software has not been altered |
| Confidentiality | Keeping information from parties who should not read it, in transit and at rest |
| Event detection and logging | Recording security-relevant events so an incident can be detected and later reconstructed |
| Resiliency and recovery | Continuing to operate safely under attack, and returning to a known-good state afterwards |
| Updatability and patchability | Delivering a fix to a deployed device securely, and being able to show it arrived |
Architecture views that are actually drawn
FDA names four view types — global system, multi-patient harm, updateability and patchability, security use cases — and asks for diagrams and explanatory text. A view that is prose alone is incomplete; so is an unlabelled arrow.
Every connector says what traverses it and over what protocol. Every figure carries a legend. Each view carries a communication-path table with the roughly nineteen details Appendix 2 asks for per path: what it carries, protocol and port, what authenticates and authorizes it, and the threats and controls on it.
The count is a floor, not a target. The guidance says plainly that a single global view need not carry every data flow — so one system-level overview, then a view per deployment.
Threat modelling, by the playbook
The MITRE/MDIC Playbook for Threat Modeling Medical Devices — FDA-commissioned, and still the current edition — is organised around four questions rather than one technique. SpecPad holds the output; the procedure governing how and when you model belongs in your quality system.
Walk STRIDE across each element of the design rather than listing attacks. That is what finds the threat in the seam between two controls, the one that needs no attacker at all, and the control category that is empty.
Security testing, tagged so it can be produced
FDA §V.C is explicit that cybersecurity controls need testing beyond ordinary verification. Each security test records which type it is, so “show me your fuzz testing” is answered by a filter rather than a search.
| Group | Types |
|---|---|
| Security requirements | security-requirements |
| Threat mitigation | threat-mitigation |
| Vulnerability testing | abuse-case malformed-input robustness fuzz attack-surface vulnerability-chaining known-vulnerability-scan composition-analysis static-analysis dynamic-analysis |
| Penetration testing | penetration |