Blue Goat CyberBlue Goat CyberSMMedical Device Cybersecurity

    MEDICAL DEVICE REFERENCE

    FDA guidance comparison

    Medical-device cybersecurity, software, AI, and change-control documents: who they apply to, the evidence they recommend, and what is actually required by law.

    Reviewed . Selected relevant documents, not the entire FDA guidance library. Device-specific applicability and regulatory decisions remain with the manufacturer.

    Law and regulations

    Binding when applicable. Section 524B, submission rules, and reporting regulations must be assessed separately from guidance recommendations.

    Final guidance

    The FDA's current recommendations. Nonbinding unless a cited statute or regulation creates the obligation; an appropriate alternative approach may be used.

    Draft guidance

    Proposals for comment, not for implementation. Do not treat draft recommendations as final requirements.

    Section 524B: the legal baseline

    For covered cyber-device marketing submissions, including 510(k), PMA, PDP, De Novo, and HDE, Section 524B requires the following. Relevant supplements and Special or Abbreviated 510(k)s are also covered. IDE submissions are not covered by Section 524B; investigational-device cybersecurity is addressed separately in Appendix 3 of the 2026 guidance.

    • Submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits, including coordinated vulnerability disclosure and related procedures.
    • Design, develop, and maintain processes and procedures providing reasonable assurance that the device and related systems are cybersecure, and make updates and patches available on the statutory risk-based schedule.
    • Provide an SBOM including commercial, open-source, and off-the-shelf software components.

    The statute distinguishes known unacceptable vulnerabilities, addressed on a reasonably justified regular cycle, from critical vulnerabilities that could cause uncontrolled risk, addressed as soon as possible out of cycle. It does not set one universal patch deadline. Section 524B(b)(4) also covers other requirements the Secretary may require through regulation.

    FDA cybersecurity and Section 524B information

    Compare guidance documents

    7 documents

    FDA guidance documents, applicability, recommendations, evidence, and limitations
    Document and scopeKey recommendationsEvidence and boundaries
    Final guidance · Premarket

    Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions

    Devices with cybersecurity considerations; Section 524B duties apply specifically to covered cyber-device marketing submissions. Appendix 3 addresses investigational devices.

    FDA source
    • Integrate security risk management into device design and the quality management system; an SPDF is a recommended approach, not a mandated named framework.
    • Document threat modeling, security architecture, security controls, testing, and traceability appropriate to the device.
    • Include Global System, Multi-Patient Harm, Updateability/Patchability, and Security Use Case architecture views as recommended by the guidance.
    • Provide component and vulnerability evidence, security labeling, and lifecycle plans; VEX is not a blanket submission requirement.

    Evidence to prepare

    Threat model, architecture views, security risk file, SBOM, test results, labeling, and postmarket plan, scoped to the device and submission.

    Important boundary

    Supersedes the June 27, 2025 version. Recommendations are nonbinding; Section 524B obligations are law. IDEs are not covered marketing submissions under Section 524B.

    Final guidance · Postmarket

    Postmarket Management of Cybersecurity in Medical Devices

    Cybersecurity management for medical devices already distributed, including legacy devices.

    FDA source
    • Monitor vulnerabilities, assess exploitability and patient harm, and maintain a coordinated vulnerability disclosure process.
    • Distinguish controlled from uncontrolled risk using device-specific evidence and compensating controls.
    • Remediate vulnerabilities and communicate with affected users using a risk-based approach.
    • Assess corrections and removals under 21 CFR Part 806 separately; enforcement discretion depends on the guidance's conditions.

    Evidence to prepare

    Monitoring records, vulnerability assessments, disclosure records, remediation verification, user communications, and reporting assessments.

    Important boundary

    Not replaced by the 2026 premarket guidance. Conditional 30/60-day enforcement-discretion criteria are not universal patch deadlines or automatic reporting exemptions.

    Final guidance · AI and changes

    Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions

    Manufacturers proposing an optional PCCP for AI-enabled device software functions in a marketing submission.

    FDA source
    • Describe the planned modifications and their limits in a Description of Modifications.
    • Define development, verification, validation, and implementation methods in a Modification Protocol.
    • Assess benefits, risks, and interactions in an Impact Assessment.
    • Implement changes within the authorized plan and document whether its acceptance criteria are met.

    Evidence to prepare

    Proposed modifications, modification protocol, impact assessment, acceptance criteria, and implementation records.

    Important boundary

    PCCPs are optional and need FDA authorization. Changes outside a plan need a device-specific change assessment, not an automatic new-submission conclusion.

    Draft guidance · AI and changes

    Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations

    Proposed lifecycle and submission recommendations for AI-enabled device software functions.

    FDA source
    • Describe intended use, users, workflow, model design, and relevant data characteristics.
    • Assess performance, generalizability, bias, and risks across the intended population and use environments.
    • Plan transparency, user information, and performance monitoring across the lifecycle.
    • Address AI-specific cybersecurity risks where relevant to the device.

    Evidence to prepare

    Proposed planning evidence: data descriptions, performance evaluations, risk assessment, user information, and monitoring plans.

    Important boundary

    Draft, not for implementation. It is not a final mandatory checklist and does not require every AI device to have a PCCP.

    Draft guidance · AI and changes

    Predetermined Change Control Plans for Medical Devices

    Proposed broader PCCP approach for medical devices, beyond the final AI-specific guidance.

    FDA source
    • Define proposed planned modifications and the methods used to implement and evaluate them.
    • Bound changes to preserve safety and effectiveness and the device's intended use.
    • Include an impact assessment and records demonstrating that implemented changes meet the authorized plan.

    Evidence to prepare

    Proposed plan boundaries, modification methods, acceptance criteria, impact assessment, and change records.

    Important boundary

    Draft, not for implementation. Do not apply it as final guidance for every non-AI software or cybersecurity update; a PCCP remains optional.

    Final guidance · Premarket

    Content of Premarket Submissions for Device Software Functions

    Software documentation in marketing submissions for devices with software functions, whether or not they are cyber devices.

    FDA source
    • Determine the Basic or Enhanced documentation level using the guidance's risk-based criteria.
    • Describe software requirements, architecture, risk management, and development processes.
    • Provide software testing evidence, revision history, and unresolved anomaly information appropriate to the documentation level.

    Evidence to prepare

    Software documentation-level rationale, requirements, architecture, risk records, testing documentation, version history, and anomaly list.

    Important boundary

    Software documentation and cybersecurity evidence describe the same device but serve different review questions. This is not a claim that Blue Goat Cyber provides general software validation services.

    Final guidance · AI and changes

    Deciding When to Submit a 510(k) for a Software Change to an Existing Device

    Software changes to an existing device evaluated under the 510(k) change framework; not a substitute for PMA-specific change rules.

    FDA source
    • Assess whether a software change could significantly affect safety or effectiveness or constitutes a major change in intended use.
    • Use the decision flowchart and document the rationale, including risk and testing evidence.
    • Evaluate cybersecurity-only changes in context; other simultaneous changes can alter the submission decision.

    Evidence to prepare

    Change description, risk assessment, verification and validation evidence, and documented submission decision.

    Important boundary

    A cybersecurity patch does not automatically require, or automatically avoid, a new 510(k). The manufacturer owns the device-specific decision.

    Put the evidence into context