FDA Medical-Device Cybersecurity Submission Workspace
One-line thesis: Build a focused FDA cybersecurity submission workspace for small connected-device manufacturers and regulatory/cybersecurity consultancies that turns SBOMs, threat models, vulnerability-process evidence, and eSTAR-ready attachments into an audit-ready premarket submission pack.
Classification: opportunity / idea_filter.
Primary buyers are small and mid-sized medical-device manufacturers submitting 510(k), De Novo, PMA/HDE supplements, or PMAs for connected/software-enabled devices, plus the regulatory affairs and specialist cybersecurity consultancies that shepherd multiple clients through FDA-regulated submissions. The best early buyer is probably a consultancy or fractional regulatory/cybersecurity lead managing several submissions: they feel the repeated client-handoff pain, have urgency around FDA holds, and can standardize evidence packs across clients.
This should not be a broad QMS, requirements, or product-security platform. The narrow wedge is “FDA cyber submission evidence room”: bring together SBOM intake, threat-model artifacts, cybersecurity risk assessment, vulnerability-management procedures, known-vulnerability disposition, eSTAR cybersecurity attachments, reviewer-question response history, and final pack export.
The urgency is real, but it must be framed with the latest FDA baseline. FDA’s current guidance page is dated February 2026 and says “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions” supersedes the June 27, 2025 final guidance. The FDA cybersecurity hub records the policy arc: section 524B of the FD&C Act took effect March 29, 2023; the September 2023 guidance was superseded by the June 2025 final guidance; the current guidance page is now February 2026.
FDA’s FAQ is concrete about submissions. Section 524B applies to cyber-device premarket applications/submissions including 510(k), PMA, PDP, De Novo, HDE, Special and Abbreviated 510(k), and PMA/HDE supplements. A “cyber device” is a device that includes sponsor-validated software, can connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats. FDA says sponsors have been required to submit the section 524B information starting March 29, 2023; beginning October 1, 2023, FDA expected sponsors to have had sufficient preparation time; and 510(k) eSTAR submissions can be placed on Technical Screening hold if the Cybersecurity section lacks accurate responses and relevant attachments.
The statutory requirements map directly to workflow objects a small software product can manage:
The FDA guidance also creates evidence-workflow gravity around threat modeling, cybersecurity risk assessment, unresolved anomalies, third-party software components, architecture views, cybersecurity testing, labeling/transparency, and cybersecurity management plans. For SBOMs, FDA recommends machine-readable SBOMs consistent with NTIA baseline attributes; for each component it also recommends support/maintenance level and end-of-support date, and it expects known vulnerabilities, including CISA Known Exploited Vulnerabilities, to be identified and dispositioned.
This is a coordination and evidence-pack problem, not just a scanner problem.
1. SBOM intake is messy. FDA wants machine-readable SBOMs, baseline attributes, support status, end-of-support dates, and known-vulnerability disposition. FDA’s own cybersecurity resource page highlights MITRE work on SBOM data-normalization challenges, signaling a live problem: SBOM data arrives from different tools, suppliers, naming conventions, and formats, and normalization is hard enough to warrant dedicated sector guidance.
2. Threat modeling is not optional paperwork. FDA recommends threat modeling throughout design, inclusive of all system elements, and says premarket submissions should include threat-modeling documentation showing how the device/system was analyzed for security risks that could affect safety and effectiveness. MITRE/MDIC’s medical-device threat-modeling playbook exists because the ecosystem needed a shared method and examples.
3. Vulnerability-process documentation has to be credible before market authorization. FDA recommends cybersecurity management plans in premarket submissions so it can assess how manufacturers will maintain safety and effectiveness after authorization. The plan should identify responsible personnel, monitoring sources and frequency, CISA KEV handling, periodic testing, patch timelines, update processes, patching capability, coordinated vulnerability disclosure, and customer communications.
4. eSTAR turns missing evidence into a submission-operational problem. FDA’s FAQ says 510(k) eSTAR submissions can be put on Technical Screening hold when the Cybersecurity section lacks accurate responses and relevant attachments. That gives regulatory teams a concrete reason to preflight completeness before submission.
5. Consultant/client handoff is structurally painful. A small manufacturer may have engineering-owned SBOMs, a security consultant’s pen-test report, a regulatory consultant’s eSTAR checklist, quality-system SOPs, supplier questionnaires, architecture diagrams, Jira/GitHub release notes, and management approvals spread across email, SharePoint, Google Drive, and spreadsheets. FDA reviewers do not want the internal mess; they want coherent evidence.
6. Vendor behavior validates spend. MedCrypt sells FDA-readiness, SBOM/vulnerability management, threat modeling, penetration testing, regulatory strategy, and process optimization specifically for medical-device cybersecurity. Cybellum markets SBOM management, vulnerability triage, product-risk management, and “audit-ready” evidence creation for FDA/ISO/CRA. Greenlight Guru and Qualio validate medtech willingness to pay for regulated workflow/QMS systems, but their broad platforms leave room for a more focused cyber-submission workspace.
The “why now” is a combination of law, process, and tool fragmentation:
Build the “submission evidence room” first; avoid trying to replace QMS, SCA, threat-modeling, or eSTAR.
1. Device profile and pathway triage: connected/software characteristics, submission type, cyber-device applicability, product versions, related systems, environments of use.
2. FDA cyber checklist: current-guidance/eSTAR-derived checklist for SBOM, threat model, risk assessment, security architecture, testing, unresolved anomalies, vulnerability plan, CVD, patch/update process, labeling/transparency, and known-vulnerability disposition.
3. SBOM intake and normalization lite: upload CycloneDX/SPDX/CSV, merge supplier SBOMs, flag missing baseline fields, collect support/end-of-support data, link component vulnerabilities and CISA KEV disposition evidence.
4. Threat-model evidence binder: upload diagrams/tables, tag threats to device functions, hazards, mitigations, verification tests, residual-risk decisions, and reviewer-ready rationale.
5. Vulnerability-management procedure pack: templates and evidence slots for monitoring sources, frequency, responsible roles, patch timelines, CVD, customer communications, postmarket update process, and KEV handling.
6. Consultant/client portal: advisor can request artifacts from engineering, quality, suppliers, and executives; every evidence item has owner, status, due date, comments, approval, and export label.
7. Submission pack export: reviewer-friendly ZIP/PDF/Word/Excel package mapped to FDA/eSTAR questions, with missing-items report, decision log, and source traceability.
8. Reviewer-response loop: track Additional Information questions, map each response to evidence objects, and preserve the final accepted rationale for the next submission.
A weekend prototype could be a secure web app with device records, checklist templates, file evidence slots, SBOM CSV/CycloneDX parsing, known-vulnerability disposition table, and export. The high-value wedge is not perfect automation; it is reducing “where is the evidence?” and “is this attachment FDA-ready?” panic.
Start with consultancies, not individual one-off manufacturers.
Pricing hypothesis: $400-$1,500 per submission workspace for small manufacturers, $3k-$12k/year for boutique consultancies based on active client/device count, or service-assisted packages at $3k-$10k where the software produces the audit-ready pack. The consultancy route is more plausible than pure SMB self-serve because regulatory trust and liability matter.
Current substitutes fall into four buckets:
The wedge is narrow: a lightweight, consultant-friendly workspace that sits between engineering security outputs and regulatory submission packaging. It should integrate with SBOM/scanner tools and QMS/document repositories rather than trying to be all of them.
Overall critique: this is attractive if framed as a workflow/evidence layer for consultancies and small manufacturers under active FDA expectations. It is less attractive as a standalone SBOM scanner or broad QMS challenger.
1. Interview 5 regulatory affairs consultants and 5 medical-device cybersecurity consultants who have touched FDA cyber submissions since October 2023.
2. Ask for their current artifact request list, eSTAR Cybersecurity pain points, SBOM normalization process, and common reviewer questions.
3. Prototype one device workspace with SBOM table, threat-model binder, vulnerability plan checklist, and FDA/eSTAR export map.
4. Test paid pilot language: “cyber submission preflight pack in 10 business days” vs “multi-client evidence workspace.”
5. Validate whether consultants want white-label client portals and reusable templates more than manufacturers want direct SaaS.
6. Do not build vulnerability scanning until users prove they will pay for the evidence-management layer.