--- title: "AI medical device cybersecurity · AI SaMD Playbook" description: "SBOM and AI-BOM expectations, model-layer threats, and controls mapped to FDA Feb 2026 cyber guidance and EU AI Act Article 15." lang: en json-ld: | [ { "@context": "https://schema.org", "@graph": [ { "@type": "WebSite", "@id": "https://ai-samd.com/#website", "url": "https://ai-samd.com/", "name": "AI SaMD Playbook", "description": "Working reference for regulating AI/ML Software as a Medical Device: FDA, EU AI Act, MHRA, Health Canada and NMPA guidance, model risks, and cybersecurity for RA/QA teams.", "inLanguage": "en" }, { "@type": "Organization", "name": "Blue Goat Cyber", "url": "https://bluegoatcyber.com" } ] }, [ { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://ai-samd.lovable.app/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://ai-samd.lovable.app/cybersecurity" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is an SBOM enough, or do I really need an AI-BOM?", "acceptedAnswer": { "@type": "Answer", "text": "An SBOM alone no longer satisfies reviewers for AI/ML-enabled devices. FDA's Feb 2026 cybersecurity guidance, plus IMDRF CYBER WG/N60, expect coverage of model weights, training-data provenance, base-model versions, tokenizers, and inference dependencies · which is what an AI-BOM (CycloneDX 1.6 or SPDX 3.0 AI profile) adds." } }, { "@type": "Question", "name": "Which model-layer threats must a 510(k) or De Novo submission enumerate?", "acceptedAnswer": { "@type": "Answer", "text": "At minimum: training-data poisoning, adversarial evasion, model extraction, membership / attribute inference, weight or artifact tampering, and · for LLM / foundation models · prompt injection. Each should appear in the threat register with a scenario, mitigation, and citation to FDA Feb 2026 cyber, NIST AI 100-2, or EU AI Act Art. 15." } }, { "@type": "Question", "name": "How does EU AI Act Article 15 interact with FDA cybersecurity guidance?", "acceptedAnswer": { "@type": "Answer", "text": "Article 15 bundles accuracy, robustness, and cybersecurity into a single conformity requirement for high-risk AI systems. A robustness gap is therefore also a cybersecurity gap under EU law, and the same evidence (adversarial testing, drift monitoring, signed artifacts) can usually be re-used for an FDA submission with citation mapping." } }, { "@type": "Question", "name": "Do upstream foundation-model changes need to be reported post-market?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. If you rely on a third-party foundation model, a silent retrain or deprecation by the provider can change clinical behaviour. Pin the version, get a change-notification clause in the supplier contract, and treat any provider-driven change as a PCCP-scoped modification with a regression eval gate before re-deployment." } } ] } ] ] --- [AI SaMD Playbook ](/) Sections[Crosswalk](/#crosswalk)Tools Search Ctrl K[Talk to us →](https://go.bluegoatcyber.com/meetings/blue-goat-cyber/discovery-session) [Back to AI SaMD Playbook](/) Cybersecurity · FDA Feb 2026 · EU AI Act Art. 15 # AI medical device _cybersecurity_. The model is now part of the attack surface. This page covers what reviewers expect on SBOM and AI-BOM, the six model-layer threats you must enumerate, and the controls that map cleanly to FDA's Feb 2026 cyber guidance, IMDRF, and EU AI Act Article 15. [Open the threat model builder →](/threat-model)[Talk to Blue Goat Cyber ↗](https://bluegoatcyber.com/) Updated weekly Week of June 15, 2026 ## This week in AI device _cybersecurity_. This week, the FDA's new cybersecurity guidance for AI/ML devices takes center stage, while the EU AI Act continues to shape regulatory landscapes and NIST offers updated resources for robust AI/ML deployments. FDA FDA ### FDA Finalizes Cybersecurity Guidance for AI/ML-Enabled Medical Devices The FDA has finalized its highly anticipated cybersecurity guidance specifically for AI/ML-enabled medical devices. This guidance, which was under development for several years, provides crucial clarity on pre-market submission requirements, risk management, and post-market considerations, impacting all manufacturers preparing 510(k) and De Novo applications. [Read source](https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity) EU AI Act European Commission ### EU AI Act Article 15: Compliance Deadline Approaches for High-Risk AI Systems With the EU AI Act’s provisions coming into full effect, the deadline for compliance with Article 15 (accuracy, robustness, and cybersecurity) for high-risk AI systems is imminent. Manufacturers of AI/ML medical devices must ensure their systems meet these stringent requirements to maintain market access in the EU. [Read source](https://digital-strategy.ec.europa.eu/en/policies/atlantic-declaration-ai) NIST NIST ### NIST AI 100-2 (Adversarial ML) Update Includes New Threat MITIGATIONS NIST has released an update to AI 100-2, focusing on adversarial machine learning. The refreshed guidance includes new techniques and strategies for mitigating adversarial attacks, which is critical for maintaining the safety and effectiveness of AI/ML medical devices against sophisticated cyber threats. [Read source](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-100-2-adversarial-machine-learning-privacy-preserving-machine) NIST NIST ### NIST Publishes Enhancements to Secure Software Development Framework (SSDF) NIST has released an updated version of its Secure Software Development Framework (SSDF), incorporating specific considerations for AI/ML components. This update is vital for medical device manufacturers to integrate secure development practices throughout the AI/ML lifecycle, from design to deployment and maintenance. [Read source](https://csrc.nist.gov/projects/secure-software-development-framework) OWASP OWASP ### OWASP LLM Top 10 Revised: Focus on Prompt Injection and Supply Chain Risks The OWASP LLM Top 10 has been revised, putting a stronger emphasis on prompt injection and insecure AI supply chain vulnerabilities. For AI/ML medical devices utilizing large language models, these updated risks highlight critical areas for security assessments and defensive measures. [Read source](https://owasp.org/www-project-top-10-for-large-language-model-applications/) SBOM/AI-BOM CycloneDX ### CycloneDX 1.6 Released with Enhanced AI-BOM Capabilities CycloneDX 1.6 has been released, providing enhanced capabilities for generating AI-Bill of Materials (AI-BOMs). This update facilitates better transparency and management of AI/ML components in medical devices, aiding in compliance and supply chain security efforts. [Read source](https://cyclonedx.org/) The three pillars ## What changed when AI joined the device. ### Premarket cyber expectations FDA's Feb 2026 cybersecurity guidance now treats AI/ML models as a first-class attack surface. Submissions are expected to enumerate threats against the model itself · not just the network around it · and to map controls back to IEC 81001-5-1 and the SPDF. FDA Feb 2026 cyber · IEC 81001-5-1 · IMDRF/CYBER WG/N60 ### SBOM and AI-BOM An SBOM lists software components. An AI-BOM extends that to weights, training datasets, base models, tokenizers, and inference dependencies. Reviewers increasingly ask for both, with provenance, license, and known-vulnerability status for every line. FDA Feb 2026 cyber §IV.B · CycloneDX 1.6 · SPDX 3.0 AI profile ### Model-layer threats Poisoning, evasion, extraction, inversion, and prompt injection are no longer research curiosities. EU AI Act Article 15 explicitly names accuracy, robustness, and cybersecurity together · meaning a robustness gap is now also a cyber gap. EU AI Act Art. 15 · NIST AI 100-2 · OWASP LLM Top 10 SBOM + AI-BOM ## Two bills of materials · one device. Reviewers no longer accept a software-only SBOM for an AI/ML device. The AI-BOM extends coverage to the model itself · weights, training data, base models, tokenizers · with provenance, license, and known-vulnerability status for every line. CycloneDX 1.6 · SPDX 3.0 AI profile · IMDRF/CYBER WG/N60 Item What to record Software components OS, libraries, drivers, container layers · with CPE / PURL identifiers. Model weights File hash, source, training-data snapshot reference, signed by producer. Training datasets Provenance, version, license, de-identification method, hold-out canaries. Base / foundation models Provider, version pin, license, change-notification clause. Inference dependencies Tokenizers, embeddings, retrieval indices, post-processing code. Known vulnerabilities CVE / GHSA / model-card advisories, with severity and exploitability. Model-layer threats ## The six reviewers now expect to see enumerated. Each of these belongs in your premarket threat register with a scenario, mitigation, and citation. The [threat model builder](/threat-model) generates a STRIDE-mapped register tailored to your model type and deployment. ### Training-data poisoning Scenario · Adversary injects mislabeled or backdoored samples so the deployed model misclassifies a targeted input class · often silently and only at inference time. Control · Dataset provenance log, hash-anchored snapshots, statistical outlier detection on retraining batches, signed dataset releases. ### Adversarial evasion Scenario · Crafted input perturbations cause the model to flip its prediction without a clinician noticing the input is anomalous. Control · PGD / AutoAttack in V&V, input plausibility gates, confidence-calibrated rejection, periodic red-team round. ### Model extraction & inversion Scenario · Query-based attacks reconstruct decision boundaries, recover protected attributes, or infer membership of a specific patient record in the training set. Control · Per-tenant query rate limits, anomaly detection on query distribution, output coarsening, differential-privacy training where feasible. ### Prompt injection (LLM / foundation) Scenario · User-supplied or upstream-document content overrides the system prompt, exfiltrating data or triggering off-label clinical advice. Control · Strict input/output channel separation, allowlisted tools, output classifier, refusal eval suite, no tool execution on untrusted strings. ### Weight / artifact tampering Scenario · Model weights, tokenizer, or post-processing code are modified in storage or transit, producing silent behaviour drift after deployment. Control · Sigstore / cosign signatures on model artifacts, integrity check at load time, immutable artifact registry, AI-BOM coverage of weights. ### Upstream foundation-model drift Scenario · Third-party foundation provider silently retrains or deprecates the base model, breaking the locked behaviour assumed in the submission. Control · Pin model version + provider SLA, regression eval gate, fallback to last-validated snapshot, supplier change-notification clause. Submission-ready checklist ## Eight items that close the cyber gap. - Threat model covers STRIDE for the software and the AI-specific six (poisoning, evasion, extraction, inversion, prompt injection, weight tampering). - SBOM in CycloneDX 1.6 or SPDX 3.0, machine-readable, regenerated on every release. - AI-BOM lists weights, training data snapshot, base model version, tokenizer, embeddings · with hashes and licenses. - Model artifacts signed (Sigstore / cosign) and integrity-verified at load time. - Inference endpoint behind mutual TLS or OIDC, per-identity quotas, billing alarms on cost-amplification. - Append-only inference log: input hash, model version, weights digest, output, confidence, clinician ID · retained per local law. - Drift monitoring tied to PCCP thresholds, with automatic field safety escalation if breached. - Coordinated vulnerability disclosure policy published, with a 90-day patch SLA for critical model-layer issues. FAQ ## The questions reviewers and sponsors ask. Is an SBOM enough, or do I really need an AI-BOM?+ An SBOM alone no longer satisfies reviewers for AI/ML-enabled devices. FDA's Feb 2026 cybersecurity guidance, plus IMDRF CYBER WG/N60, expect coverage of model weights, training-data provenance, base-model versions, tokenizers, and inference dependencies · which is what an AI-BOM (CycloneDX 1.6 or SPDX 3.0 AI profile) adds. Which model-layer threats must a 510(k) or De Novo submission enumerate?+ At minimum: training-data poisoning, adversarial evasion, model extraction, membership / attribute inference, weight or artifact tampering, and · for LLM / foundation models · prompt injection. Each should appear in the threat register with a scenario, mitigation, and citation to FDA Feb 2026 cyber, NIST AI 100-2, or EU AI Act Art. 15. How does EU AI Act Article 15 interact with FDA cybersecurity guidance?+ Article 15 bundles accuracy, robustness, and cybersecurity into a single conformity requirement for high-risk AI systems. A robustness gap is therefore also a cybersecurity gap under EU law, and the same evidence (adversarial testing, drift monitoring, signed artifacts) can usually be re-used for an FDA submission with citation mapping. Do upstream foundation-model changes need to be reported post-market?+ Yes. If you rely on a third-party foundation model, a silent retrain or deprecation by the provider can change clinical behaviour. Pin the version, get a change-notification clause in the supplier contract, and treat any provider-driven change as a PCCP-scoped modification with a regression eval gate before re-deployment. Sponsor ## Need this scoped against _your_ device? Blue Goat Cyber has run penetration testing, threat modeling, SBOM, and AI/ML model security on 250+ FDA submissions · zero rejections. They sponsor this page and the threat model builder. [Book a discovery session ↗](https://go.bluegoatcyber.com/meetings/blue-goat-cyber/discovery-session) © 2026 AI SaMD Playbook · Sponsored by Blue Goat Cyber [Crosswalk](/crosswalk)[Colophon](/colophon) Editorial reference only. Not legal or regulatory advice.