FDA 510(k) for SaMD: Cybersecurity Documentation That Won't Get Returned
The FDA's premarket cybersecurity guidance for medical devices, finalised in September 2023 and operationalised through the 2024–2025 Refuse to Accept letters, raised the bar for what a Software as a Medical Device (SaMD) 510(k) submission must contain. Two years on, the pattern in submission outcomes is clear. SaMD submissions that incorporate cybersecurity documentation as a structured chapter clear on the first review cycle. Submissions that treat cybersecurity as a section to be cobbled together near the end produce Additional Information requests that delay clearance by 60 to 180 days.
This piece is the documentation pattern we use with SaMD vendors preparing 510(k) submissions, particularly those who have been through one cycle and now need to clear the bar. It is opinionated about what is non-negotiable and where the FDA's guidance has more flexibility than vendors usually realise.
What the 2023 final guidance actually requires
The premarket cybersecurity guidance specifies six documentation areas that must appear in a 510(k) submission for a SaMD with cybersecurity-relevant features. Most of the field has read the section headings; many fewer have internalised what the FDA actually expects in each.
1. Security risk management report. Not a checklist. A documented application of a structured threat-model methodology (the guidance names STRIDE, attack trees, and the AAMI TIR57/SW96 framework as acceptable) to the device's specific architecture. The FDA's reviewers are explicit in feedback letters that they look for evidence the threat model is applied, not just declared.
2. Threat model. A specific artefact: a system decomposition (data flows, trust boundaries, assets), a threat enumeration mapped to the architecture, mitigations mapped to threats, and a residual risk discussion. The single most common failure here is presenting a generic threat list pasted from a template rather than one specific to the architecture.
3. Cybersecurity risk assessment. The bridging artefact between security risks and the device's overall ISO 14971 risk file. The FDA's explicit position is that cybersecurity risks are device risks, and the evaluation should map to harm to the patient, not just to information asset compromise.
4. SBOM (Software Bill of Materials). Required at submission. Format must be machine-readable (SPDX or CycloneDX). Coverage must include all third-party software components, including open-source. Vulnerability tracking against the SBOM is implied; submissions without a stated process for ongoing vulnerability monitoring trigger AI requests.
5. Vulnerability and incident management plan. The post-market companion to the threat model. Must describe coordinated vulnerability disclosure, vulnerability assessment cadence, patch deployment, and incident notification. Must be operational, not aspirational.
6. Security architecture views. Diagrams and descriptions of the device's security architecture: authentication, authorisation, encryption (in-transit and at-rest), key management, audit logging, secure update mechanism, secure boot if applicable. Each control mapped to the threats it mitigates from the threat model.
These six are the core. There are additional elements depending on device classification and connectivity profile, but if the six above are weak, the rest does not save the submission.
The pattern that makes the difference
Submissions that clear on the first cycle share a structural pattern: the cybersecurity content is integrated with the engineering documentation, not appended to it. Submissions that get Additional Information requests usually have cybersecurity sections that cite engineering work that does not actually exist or is not actually traceable.
Concrete example: the threat model identifies an authentication threat. The mitigation is described as "device requires authentication with multi-factor for administrative functions." The FDA reviewer looks for: the requirements document where this is specified, the design document where the mechanism is described, the test protocol where it was verified, and the test report showing it passed. If any of these are missing or do not match what the threat model claimed, the submission fails. If they are present and traceable, the submission proceeds.
This is the difference between cybersecurity documentation that is a deliverable and cybersecurity documentation that is evidence. Evidence is what passes the review.
Where vendors routinely under-invest
Three areas show up consistently in the AI letters we have helped clients respond to.
SBOM coverage is shallow. Vendors deliver an SBOM that lists their direct dependencies but does not include transitive dependencies, OS-level components, or runtime libraries. The FDA's expectation is broader. Generate the SBOM with proper tooling (Syft, ORT, or equivalent) and verify the coverage against the running device, not against the build manifest.
Vulnerability monitoring is a future commitment. "We will monitor vulnerabilities in deployed devices" is not enough. The submission needs the actual operational plan: what feeds, what cadence, what triage process, what severity thresholds trigger which actions, what the notification path looks like, how patches are validated and deployed. The FDA wants the process, not the intent.
Threat model is generic. A threat model derived from a STRIDE template applied to a generic device archetype reads as boilerplate. The model needs to engage with this device's architecture, this device's data flows, this device's specific update mechanism. The FDA's reviewers are increasingly explicit about distinguishing applied threat modelling from template-filling.
These three are also the easiest to fix on a resubmission. Most of our work on AI letter responses involves rebuilding these three sections with operational evidence rather than refining the wording of the existing sections.
Connecting cybersecurity to ISO 14971
The most common structural failure we see is treating security risks and ISO 14971 patient-harm risks as separate registers. The FDA's guidance is explicit: they are not separate. A cybersecurity vulnerability is a hazard to the patient if it could lead to harm. The harm-mapping work is what connects security to patient safety, and it is the bridge the FDA looks for.
Practically, this means the threat model's residual risks should appear in the device's overall risk file (ISO 14971) with mapped harms, severity, and probability. The risk file should reflect cybersecurity considerations, not just clinical and mechanical ones. Vendors who maintain two separate registers are doing the work twice and producing inconsistent artefacts; vendors who maintain one integrated register produce evidence faster.
Where this connects to our practice
Pelican Tech's Regulatory Affairs practice builds 510(k) submissions for SaMD with cybersecurity documentation integrated from the start, working alongside the engineering team rather than as a downstream documentation function. We work with our MedTech team when the broader device-system context (clinical evaluation, design controls, software lifecycle per IEC 62304) matters to the submission, and with our QMS team when the underlying ISO 13485 quality system needs to be aligned with the cybersecurity processes the submission documents.
If you have received an Additional Information letter on a 510(k) submission and the cybersecurity sections are flagged, that is the engagement to start with before the next response cycle.