Cybersecurity for SaMD, AI/ML diagnostics, and medical imaging.
AI/ML-driven SaMD has unique cyber concerns: model integrity, training-data provenance, and the interfaces SaMD uses to ingest DICOM, FHIR, and PACS data. We deliver FDA-aligned threat models that explicitly cover model-supply-chain risks alongside conventional appsec.
Imaging AI and SaMD products are inferential and cloud-tethered. The model, the data pipeline, the training corpus, and the runtime are all in scope for FDA cybersecurity expectations - and increasingly for the GMLP and PCCP guidance as well.
Hospital security teams treat SaMD as a SaaS product: they want SOC 2 / HITRUST evidence, an SBOM, an API security summary, and clarity on the cloud shared-responsibility split before they let it touch PACS or EHR.
Typical clinical uses
Key data flows & integrations
Trained model artifacts must be signed, version-pinned, and verified at load - supply-chain tampering is now an FDA review topic.
Parser bugs and authorization gaps in clinical interfaces are a leading source of SaMD vulnerabilities.
Tenant separation, key scoping, and audit trails must be designed and tested, not assumed.
AI SaMD that consumes DICOM and writes back structured reports has a narrower physical surface than a connected device - but a richer software surface. Model weights, the DICOM listener, and multi-tenant isolation dominate the threat model.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
DICOM, PACS, and AI-assisted imaging platforms have produced an unusually rich set of public advisories - and they're now joined by ML-specific concerns FDA reviewers explicitly call out under the 2026 premarket guidance and PCCP framework.
Historical incidents
Researchers disclosed six vulnerabilities affecting GE CARESCAPE patient monitors, telemetry servers, and clinical information centers - including default/hardcoded credentials and unauthenticated network services. Several products integrate with imaging and clinical-IT pipelines that AI/SaMD vendors consume.
CISA ICSMA-20-023-01CVE-2020-25179
Public research demonstrated that valid DICOM files could embed executable PE/COFF payloads in the 128-byte preamble while remaining standards-compliant - meaning malware could persist inside genuine medical images traversing PACS, AI ingestion pipelines, and EHR archives.
FDA and CISA have issued multiple advisories affecting Philips IntelliSpace and related imaging platforms over recent years (privilege escalation, hardcoded credentials, weak authentication) - the same platforms many AI/SaMD products integrate against.
CISA ICSMA-21-238-01 and related
Active threat scenarios
Inputs crafted to evade a model can change triage or detection output - a documented concern for radiology and pathology AI.
Unauthenticated model-fetch endpoints, container images with embedded weights, and over-permissioned cloud roles enable IP theft and supply-chain replacement.
Malformed DICOM objects targeting parser bugs or the PE/COFF preamble path can compromise the ingestion node or persist as embedded malware.
Object-level authorization gaps (BOLA) across tenants are the most frequent critical finding in cloud-hosted diagnostic platforms.
What FDA reviewers cite
Imaging AI / SaMD is inferential and cloud-tethered - the model, the pipeline, and the data are all in scope for FDA cybersecurity expectations.
PCCPs let you update models post-clearance, but only with a documented and tested change-control + cyber-validation pipeline.
FDA still expects you to own end-to-end security even when running on AWS/Azure/GCP - the responsibility split must be explicit.
Standard pen testing won't catch evasion or poisoning attacks; you need ML-specific threat modeling and testing.
Training-data provenance, de-identification, and re-identification risk must be documented for both FDA and HIPAA.
What FDA scrutinizes
Predetermined Change Control Plans let you update models post-clearance, but only with a documented and tested change-control + cyber-validation pipeline.
Standard AppSec pen tests do not catch evasion or poisoning - reviewers expect ML-specific testing.
FDA still expects you to own end-to-end security on AWS / Azure / GCP - the responsibility split must be explicit in the SPDF.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the imaging & ai/samd-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
Machine-readable SBOM (CycloneDX/SPDX) plus VEX feed for every CVE that touches a listed component.
Continuous CVE / advisory monitoring against the SBOM, with a documented triage and disclosure path.
Black/grey-box testing across device, wireless interfaces, mobile apps, cloud APIs, and service tooling.
STRIDE-per-interface threat model with documented mitigations and residual-risk acceptance.
Signed firmware/software updates with rollback protection, integrity verification, and staged rollout.
Public CVD policy, intake channel, and SLAs for triage, fix, and customer communication.
If you have a PCCP, the cyber sections of the modification protocol must describe how security posture is maintained as the model is retrained, repackaged, or redeployed. That includes which changes can occur without re-review, how the SBOM is regenerated, how vulnerability and exploitability analyses are refreshed, how training-data lineage is reverified, and how the postmarket plan continues to apply across versions. We help you write those cyber elements explicitly so the PCCP doesn't accidentally invalidate the cleared cyber controls.
Both, scoped to clinical relevance. The surrounding software gets conventional appsec, API testing, BOLA/tenancy checks, and infrastructure review. The model itself gets supply-chain controls (signing, version pinning, load-time verification of weights and config), adversarial-input checks where a perturbation could plausibly change a clinical decision, and integrity controls for any in-product caching or fine-tuning. The depth of model-level testing is calibrated to the indication so we don't burn budget on cosmetic robustness for non-safety-critical features.
We document training-data lineage controls in the SPDF: source attestation, integrity at ingest, access scoping during labeling and training, deletion/right-to-be-forgotten handling where applicable, and audit logging across the training pipeline. FDA reviewers increasingly expect this to be addressed explicitly rather than waved at, particularly for AI/SaMD with diagnostic claims, and the EU AI Act adds aligned obligations for high-risk medical AI.
Each ingestion interface is enumerated with its protocol, authentication mechanism, and parser. DICOM C-STORE/C-FIND/C-MOVE and Eye Care service classes are fuzzed with explicit memory-safety evidence; HL7 v2 and FHIR endpoints are tested for authentication, authorization (especially BOLA and multi-tenant scoping), parser robustness under malformed and oversized payloads, and replay/order-injection resistance. SMART on FHIR scope handling and token revocation are verified separately.
No. SOC 2 covers operational controls and is useful for procurement conversations, but it does not satisfy FDA premarket cybersecurity content - SPDF, threat model, SBOM with VEX, security architecture views, security testing, MDS2, and a postmarket plan are still required. Where you have SOC 2, we make sure the controls referenced in your Type II report align with the SPDF so reviewers and procurement see one coherent story.
A full transitive SBOM in SPDX or CycloneDX, including model dependencies (weights, config, tokenizers), container base images, ML frameworks, inference runtimes, GPU/accelerator drivers in scope, and any third-party APIs in the inference path. The SBOM is paired with a vulnerability and exploitability analysis (VEX) and integrated into the postmarket plan under section §524B for continuous monitoring against NVD, vendor advisories, and CISA KEV.
Generative AI in clinical SaMD gets dedicated treatment: prompt-injection resistance, output handling and escaping (especially when output flows into another system or is auto-actioned), content provenance, hallucination handling tied to the indication's risk file, supply-chain controls on the model and its hosting, and explicit threat modeling for jailbreaks and indirect prompt injection. Where the model is a third-party API, the boundary is documented as an explicit untrusted-but-contractually-bound interface and tested for abuse and PHI leakage.
Model versioning, rollback, and reproducibility are treated as cybersecurity-relevant change controls under your QMS. Each deployed model has a verifiable identity (hash, signature), a documented provenance back to its training run, and a tested rollback path. The SPDF and the PCCP (if you have one) describe how a substituted, downgraded, or corrupted model is detected and rejected at load time, and how the audit trail proves which model produced any given inference.
Multi-tenant authorization is the dominant finding area in cloud SaMD, full stop. We exercise BOLA, parameter-tampering, IDOR, OAuth scope confusion, JWT claim tampering, soft-delete/undelete tenancy leaks, and cross-tenant search/export paths systematically. Findings are tied to specific code paths and to the threat-model entries that should have prevented them so remediation is unambiguous and reviewable.
Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (typically Class B or C depending on indication), ISO 14971, IEC 81001-5-1, ISO/IEC 23894 (AI risk management), and the GMLP principles. EU manufacturers add MDR Annex I §17.2, MDCG 2019-16, and the EU AI Act's high-risk obligations - we map artifacts across all three regimes so you don't redo work.
For a cloud-hosted AI/SaMD with image ingestion, model serving, and EHR integration, end-to-end premarket cyber work generally runs 6-12 weeks. Threat modeling and SBOM (including model dependencies) front-load in weeks 1-3, web/API/DICOM/integration pen testing and model-supply-chain review run in weeks 3-9, and the consolidated submission package, PCCP cyber elements, and postmarket plan close in the final weeks - all under a written deficiency commitment.
Model integrity, DICOM/PACS interface testing, and PCCP-aware documentation for AI imaging products.
"Blue Goat Cyber takes the burden off our engineers and makes FDA cybersecurity requirements easy to understand. Their expertise and smooth process mean we can focus on our product, not the paperwork. The organized documentation, perfectly formatted for eSTAR, saves us countless hours."
Cybersecurity for SaMD, AI/ML diagnostics, and medical imaging.
