On this page
Key Takeaways
- Use this as the final pre-upload check against the February 2026 final premarket cybersecurity guidance.
- Every item below is a specific reviewer expectation - not a nice-to-have.
- AI/ML devices need the additional items in the AI section.
- If you cannot tick every box, you have a likely deficiency.
Talk to a MedTech cybersecurity expert
1. Security risk assessment
- Aligned to AAMI TIR57 / ANSI/AAMI SW96.
- Integrated with the ISO 14971 risk file (not parallel).
- Identifies asset, threat, vulnerability, control, residual risk per row.
- Maps each row to a patient-harm category.
- Signed and dated by the security risk lead.
2. Threat model
- Scope statement, asset inventory present.
- Four architecture views: global, multi-patient harm, updateability, security use-case.
- Trust boundaries consistent across views.
- STRIDE per element (or comparable methodology).
- Control catalog with implementation reference and verification evidence per control.
- Traceability matrix: threat → control → verification → residual risk → ISO 14971 harm.
3. SBOM
- Machine-readable: CycloneDX 1.4+ or SPDX 2.3+.
- NTIA minimum elements present per component.
- Transitive dependencies enumerated.
- Cloud backend components included.
- Mobile companion app components included.
- Vulnerability disclosure path per component.
- VEX or equivalent triage statement attached.
- Hash and EOS date per component.
4. Penetration test report
- Full attack surface coverage: firmware, hardware, wireless, mobile, APIs, cloud.
- White-box methodology documented.
- Letter of Attestation signed by engagement lead.
- Per-finding: severity (CVSS + clinical impact), reproduction, evidence, remediation, status.
- High/critical findings retested after remediation.
- Traceability appendix linking findings back to threat-model entries.
- Standards cited: NIST SP 800-115, OWASP MASVS/ASVS, FDA 2026 guidance, AAMI TIR57.
5. Architecture views (delivered as standalone artifact)
- Global system view diagram + narrative.
- Multi-patient harm view diagram + narrative.
- Updateability view diagram + narrative (key management, signing, rollback).
- Security use-case view (states, transitions, threat behavior).
- Each view annotated with trust boundaries and data classification.
6. Cybersecurity labeling
- Patient-facing security information present (where applicable).
- Clinician/operator-facing security information present.
- Network and connectivity assumptions documented.
- User-actionable security configuration steps documented.
- CVD program contact information.
7. Postmarket cybersecurity management plan
- Vulnerability monitoring sources defined.
- Triage SLA documented (target: 5 business days post-discovery).
- Patch deployment cadence by severity defined.
- CVD program documented with intake, triage, and disclosure SLAs.
- SBOM regeneration cadence (every build).
- End-of-support tracking process.
- Customer communication process for vulnerabilities and patches.
- Named owners for each function.
8. Predicate-comparison cybersecurity narrative (510(k) only)
- Predicate cyber surface enumerated.
- New-device cyber surface enumerated.
- Delta identified (every interface added beyond predicate).
- New threats arising from delta.
- Controls mitigating new threats.
AI/ML add-on items (when applicable)
- AI-DSF section per January 2025 draft guidance.
- Model card / transparency content in labeling.
- Subgroup performance breakdowns.
- AAMI CR34971 alignment in risk file.
- AI-specific cybersecurity threats addressed (data poisoning, evasion, inversion, prompt injection) with MITRE ATLAS / OWASP ML Top 10 mapping.
- Foundation models and third-party AI APIs in SBOM and supplier evaluation.
- PCCP if model will change postmarket.
- Performance and bias monitoring plan tied to PCCP.
Final reviewer-eye read-through
- A senior MedTech regulatory reader (not the author) can answer in 15 minutes from the package alone: what does the device do, what are the cyber threats, how are they controlled.
- Cross-references between artifacts resolve.
- Versions and dates consistent across artifacts.
- No "TBD" or placeholder content.
Frequently asked questions
How reviewers actually read the package
Reviewers do not read the cybersecurity section in the order you assembled it. In our experience they start with the threat model, look for the architecture views to confirm the boundaries the threat model claims, then jump to the test report to see whether the scope matches those boundaries, and only then read the risk assessment to see if the numbers are defensible.
That reading order has a practical consequence: any inconsistency between the threat model, the architecture views, and the test scope is found early and colors everything after it. If your architecture views show a Bluetooth interface that the pen test scope does not mention, the reviewer will assume the rest of the package is similarly incomplete and will look harder.
Assemble in whatever order suits your team. Review it in that order.
Three checks that catch most self-inflicted deficiencies
- Interface census. List every physical and logical interface on one page: radios, ports, service connectors, APIs, update channels, companion apps. Then confirm each appears in the architecture views, the threat model, the control list, and the test scope. Missing interfaces are the single most common structural gap.
- Claim-to-evidence sweep. Take every security claim in the labeling and find the evidence behind it. Labeling that promises encryption in transit while the architecture describes an unencrypted local link is a contradiction a reviewer will find.
- Date and version sweep. Confirm the SBOM, the test reports, and the architecture documents all describe the same software version. Artifacts generated against three different builds is a common and easily avoidable finding.
Where the extra week is best spent
If you have one week of slack before filing, do not spend it polishing prose. Spend it on the two things reviewers weight most heavily: traceability identifiers carried consistently across the threat model, risk assessment, control list, and test reports; and closing the gap between the tested build and the submitted build. Those two changes move a package from "complete" to "verifiable," which is the distinction that determines whether a letter arrives.
Where to go next
Checklists are easy to agree with and hard to act on, because a checklist tells you what must exist without telling you what to build first. Use this ordering.
Start with the architecture and data flow documentation, even though it is not the item reviewers comment on most. Every other artifact depends on it. If your data flow diagram does not show the mobile app, the cloud backend, the clinician portal, the update channel, and the service interface, then your threat model will be scoped too narrowly, your penetration test will be scoped from that narrow threat model, and your risk assessment will inherit both gaps. Fixing the diagram costs a day. Fixing everything downstream costs a filing cycle.
Second, build the threat model as a design input rather than a submission artifact. Reviewers can tell the difference. A model produced before design freeze contains mitigations that changed the architecture. A model produced after contains mitigations that were already there. The tell is that every threat has an existing control and no residual risk is interesting.
Third, scope penetration testing from the threat model and say so in writing. The scope statement should name the interfaces tested, the build and firmware version, the test dates, the tester independence basis, and the threat model IDs the testing exercises. Testing that cannot be traced back to specific claims reads as a generic assessment, no matter how good the testing was.
Fourth, run the traceability check before you assemble the eSTAR. Pick five threats at random and follow each one to its control, its verification test, its residual risk entry, and its labeling statement where applicable. If any of the five breaks, the rest of the package has the same defect and a reviewer will find it faster than you did.
Fifth, budget the last week for consistency rather than content. Version numbers, build identifiers, and dates that disagree across artifacts generate more deficiencies than genuinely missing controls.
If your filing is under sixty days out, do the traceability spot-check now. It is the cheapest predictor of whether you get a letter.
- How to Pass FDA 510(k) Cybersecurity on the First Submission - the sequencing and timing decisions behind a clean first pass.
- FDA Cybersecurity Deficiency Letter Response Playbook - what happens if a gap slips through, and how to close it inside 180 days.
- FDA Premarket Cybersecurity Service - the whole package built as one cross-traceable set rather than independent deliverables.
- FDA Cybersecurity Technical Screening Checklist - artifact formats and traceability reviewers check first.
