Medical Device Penetration Testing for Imaging AI & SaMD
Penetration testing for imaging AI and SaMD - DICOM ingestion, model inference paths, cloud APIs, and PACS integration. FDA-aligned for AI/ML SaMD submissions.
Imaging AI and SaMD devices are software products that present as cloud services or PACS-integrated workstations, and their attack surface is mostly cloud, mostly DICOM, and mostly model-adjacent. The naive pen test treats them as web apps. The right pen test treats them as a pipeline: DICOM in → preprocessing → model inference → results out → PACS / EHR. Each hop has its own failure modes, and reviewers under FDA's evolving AI/ML guidance expect to see the whole pipeline modeled.
We test the DICOM ingestion path for malformed-tag handling (the historic source of imaging zero-days), C-STORE vs. STOW-RS authentication, and whether the de-identification step can be bypassed. On the model side we evaluate the inference path for adversarial-input behavior at the boundaries that matter clinically (not academic adversarial examples - clinically plausible perturbations the device must reject or flag), prompt-injection-style bypasses for any LLM-augmented reporting, and whether confidence/uncertainty outputs can be manipulated to suppress flags. We test cloud APIs for tenancy isolation across hospital customers (the most common high-severity finding in this segment), service-account scope creep, and storage permissions on intermediate buffers. Finally, the results-write path: how does the device write back to PACS, who can spoof results, and what audit trail survives a compromise? Findings are mapped to FDA's AI/ML PCCP expectations and ANSI/AAMI SW96.
Common findings in Imaging & AI/SaMD medical device penetration testing
The patterns we actually see in this segment, this service, again and again.
-
Cross-tenant data leak via shared inference cache
Inference results keyed by hash of pixel data. Two hospitals with the same study (rare but possible - phantom QA) saw each other's results.
-
DICOM C-STORE accepted without TLS or authentication
On-prem appliance variant exposed default DICOM AE on port 104, no association-level auth. Anyone on the hospital VLAN could push studies into the inference queue.
-
Model output writeback to PACS accepts spoofed source
DICOM SR (Structured Report) writeback uses a fixed AE title for the AI device. Any host that takes that AE title can push fake AI findings to the radiologist worklist.
-
Confidence-suppression via crafted metadata
Specific combinations of acquisition metadata cause the model to short-circuit and emit max-confidence 'normal' without inferring. Documented model-card behavior, undocumented security implication.
-
Service-account broad S3 IAM
Inference workers' role grants list/get on the entire studies bucket, not just the current job's prefix. A compromised worker reads every customer's pending studies.
Standard Medical Device Penetration Testing deliverables
These are the same deliverables the parent Medical Device Penetration Testing service ships with - tuned to your imaging & ai/samd architecture.
- Device, firmware, and embedded testing
- Companion app and cloud API coverage
- FDA-ready penetration test reports
- Remediation guidance and re-test included
Standards that apply
The Imaging & AI/SaMD standards baseline, plus the call-outs that matter for medical device penetration testing in this segment.
Segment-specific call-outs
FDA AI/ML PCCP guidance
Your Predetermined Change Control Plan is a security boundary, not just a regulatory one. We check that the model-update path can't be hijacked to ship an unapproved model under cover of an approved PCCP change.
DICOM PS3.15 (Security Profiles) and ANSI/AAMI SW96
DICOM has security profiles; most products don't enable them. Reviewers are starting to ask why not.
Scope a Medical Device Penetration Testing engagement for your imaging & ai/samd program.
A 30-minute call with a senior engineer who has done this in imaging & ai/samd before - not a sales rep.