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.
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.
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 sourceWith 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 sourceNIST 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 sourceNIST 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 sourceThe 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 sourceCycloneDX 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 sourceFDA'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
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
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
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. |
Each of these belongs in your premarket threat register with a scenario, mitigation, and citation. The threat model builder generates a STRIDE-mapped register tailored to your model type and deployment.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.