On this page
Key Takeaways
- A first-pass-clean cybersecurity package needs eight specific artifacts, structured exactly as the 2026 final guidance lays out.
- Predicate divergence is the most-cited deficiency in 510(k) cybersecurity - the predicate-comparison narrative must address every cyber surface added beyond the predicate.
- Run a 30-day pre-submission readiness check before eSTAR upload. Most rejections are visible in the package before it reaches the reviewer.
- Rapid response to deficiencies (when they happen) is a separate skill - have a playbook ready, not just hope.
Talk to a MedTech cybersecurity expert
The eight artifacts a clean 510(k) cybersecurity package contains
- Security risk assessment aligned with AAMI TIR57 / SW96.
- Threat model with four architecture views and traceability matrix.
- SBOM in CycloneDX or SPDX with vulnerability disclosure paths.
- Penetration test report with full attack surface coverage and Letter of Attestation.
- Architecture views (global, multi-patient harm, updateability, security use-case).
- Cybersecurity labeling and user-facing security information.
- Postmarket cybersecurity management plan.
- Predicate-comparison cybersecurity narrative.
Predicate divergence: the silent killer
The most common 510(k) cybersecurity deficiency is the same every cycle: the device has connectivity or features the predicate did not, and the submission does not address the resulting cybersecurity delta. Reviewers look for an explicit predicate-comparison cybersecurity narrative that lists every interface and data flow added beyond the predicate, identifies the new threats those create, and shows the controls that mitigate them. Without this narrative, even a strong threat model and pen test will draw a deficiency because the reviewer cannot tell what is 'new' from what was inherited.
The 30-day pre-submission readiness check
A focused review against the eight artifacts catches the 80% of issues that cause first-cycle deficiencies. Run it 30 days before planned eSTAR upload.
Day 1-5: Artifact completeness
- All eight artifacts present and version-controlled.
- Each artifact has clear authorship, date, and version.
- Cross-references between artifacts resolve (no broken links).
Day 6-15: Content depth
- Threat model: four architecture views present, trust boundaries consistent across views, STRIDE per element.
- Pen test: Letter of Attestation present, scope covers full attack surface, retest evidence for high/critical.
- SBOM: machine-readable, transitive deps, VEX or equivalent triage statement.
Day 16-25: Traceability
- Threat → control → verification → ISO 14971 harm chain unbroken.
- Predicate-comparison narrative present and complete.
- Postmarket plan describes monitoring cadence, vulnerability triage SLA, and patch deployment.
Day 26-30: Reviewer-eye read-through
A senior MedTech regulatory reader who did not write the package reads it cold. If they cannot answer "what does this device do, what are the cyber threats, and how are they controlled" in 15 minutes from the package alone, the package is not ready.
Common rejection patterns we still see in 2026
- IT-style threat model presented as medical device threat model - no patient-safety mapping.
- Pen test scoped to web app only because the device is "just a sensor with an app."
- SBOM present but cloud backend excluded.
- Postmarket plan describes monitoring intent without cadence, SLAs, or named owners.
- AI/ML feature added but no AI-specific cybersecurity content - no MITRE ATLAS mapping, no model-supply-chain review.
- Cybersecurity labeling missing entirely or buried in a single sentence in the IFU.
If a deficiency does come
You have 180 days. Fast response matters more than long response. See our Deficiency Letter Response Playbook for the structure that gets through second-cycle review without a third.
Frequently asked questions
What the first submission usually gets wrong
Across first-time 510(k) cybersecurity packages, the failures cluster into three shapes, and none of them are about missing documents.
The package is complete but not connected. Every artifact exists, and none of them reference each other. The threat model enumerates 60 threats, the risk assessment scores 44 risks, the control list names 31 controls, and no identifier appears in more than one document. A reviewer cannot verify that the mitigation for threat 17 was tested, so the whole set is treated as unverified.
Testing was scoped to the app, not the device. The pen test covers the mobile application and the cloud API, while the firmware, the debug port, the pairing sequence, and the update mechanism are untested. That gap is visible from the report's scope section in about ten seconds.
The postmarket plan describes an intention. It says vulnerabilities will be triaged promptly and patches released as needed, with no defined intake, no owner, no timeline, and no update mechanism described. Section 524B(b)(1) requires the plan to be real at clearance, not after.
A pre-flight test you can run in an afternoon
Hand the package to someone who did not write it, with one instruction: pick three threats at random from the threat model and trace each one to a scored risk, a named control, an implementation location, and a test result. Then pick two findings from the pen test report and trace each back to a threat and to a remediation record.
Five traces. If any one of them breaks, the reviewer's version of the same exercise breaks too, and that produces the traceability deficiency that costs a review cycle. This is a cheaper failure to find internally than to find in a letter.
The timing mistake that causes most first-submission delays
Teams schedule penetration testing to finish the week the submission goes out. Two things then go wrong. There is no time to remediate what the test finds, so the report ships with open findings and no fix evidence. And because the test ran against a build that was still changing, the report describes a version that no longer matches the submitted firmware.
Book independent testing to complete six to eight weeks before your target filing date. That leaves room for remediation, a focused retest of the fixed items, and a final report that matches the shipping build. Every other artifact can be finished in the last month; this one cannot.
Where to go next
Passing cybersecurity on the first 510(k) submission is mostly a calendar exercise. The technical work is well understood. What separates a clean clearance from a deficiency letter is whether the work happened in an order that let findings change something.
Set your dates backwards from the filing target. Nine months out, the architecture and data flow documentation should be stable enough to threat model against. Seven months out, the threat model should be complete, reviewed, and already reflected in design decisions. Five months out, penetration testing starts, scoped from that threat model. Three months out, findings are remediated and retested, and the report is final. The last two months are assembly, traceability checking, and labeling. Compress that timeline anywhere and the compression lands on remediation, which is the one phase you cannot skip without leaving open findings visible in your own report.
Decide the interface scope early and defend it in writing. The most common first-submission gap is a package that covers device firmware thoroughly and treats the mobile app, the cloud API, and the update mechanism as out of scope. Under the Feb 3, 2026 premarket guidance, the system boundary includes everything the device communicates with. If something genuinely is out of scope, write the justification into the scope statement rather than leaving the omission for a reviewer to notice.
Handle third-party and legacy components before they surprise you. An off-the-shelf module with an unmaintained upstream, a bootloader nobody has version information for, or a chipset stack you cannot inspect will each generate questions. Document what you know, what you cannot determine, and what compensating controls and monitoring you have in place. A documented limitation is a different conversation than a silent gap.
Use a Q-Sub if any of your scoping choices are genuinely debatable. A written answer from the agency costs you weeks. A deficiency letter costs you months.
If you are already inside six months, the highest-value move is booking penetration testing now and treating the threat model refresh as the input to that scope.
- FDA Premarket Cybersecurity Service - the sequenced package built against your filing date, with remediation time preserved.
- Premarket FDA Cybersecurity Submission Checklist - the item-by-item completeness standard to measure your package against.
- FDA Cybersecurity Deficiency Letter Response Playbook - the recovery path if a letter arrives anyway.
