DICOM and PACS Security: Protecting Imaging Pipelines
DICOM was designed for interoperability on a trusted network, and it shows: no authentication in the base protocol, PHI in every file header. What to do about exposed PACS, C-STORE abuse and the study data sitting on modality hard drives.
GuardsArm Team
Security Experts
DICOM is a 1980s interoperability standard that assumed the network it ran on was trusted. That assumption is baked into the protocol: in its base form there is no authentication worth the name, no encryption, and every image file carries patient identifiers in its header. It works beautifully for getting a scan from a modality to a radiologist, and it offers almost nothing against an attacker already on the network.
The three exposures that matter
1. AE Title is not authentication. A DICOM association is negotiated between Application Entities identified by an AE Title — a short string the connecting party asserts about itself. Many PACS are configured to accept any AE Title, or to accept a known list without verifying anything else. Anyone who can reach the port can usually talk to the archive.
2. C-STORE accepts what it is given. The store operation exists so modalities can push studies into the archive. Where it is open, an attacker can write arbitrary studies into the PACS — polluting the record, or planting a file that exploits a parsing bug in a downstream viewer.
3. The metadata is the breach. Even a single leaked image is a reportable disclosure, because the patient identifiers travel inside the file. De-identified research exports frequently miss private tags and burned-in text in the pixel data itself.
What the traffic should look like
Controls, in the order they pay off
| Control | Effort | Why it matters |
|---|---|---|
| Restrict DICOM ports by source IP | Low | Removes the entire remote-attacker class in an afternoon |
| Enforce an AE Title allow-list on the PACS | Low | Stops casual association from unknown peers |
| Disable C-STORE from anything but known modalities | Low | Closes the study-injection path |
| TLS for DICOM associations | Medium | Vendor support varies; do it where available |
| Verify de-identification on research export | Medium | Private tags and burned-in pixel text are routinely missed |
| Log and alert on C-FIND/C-MOVE volume | Medium | Bulk retrieval is the signature of exfiltration |
| Patch viewers and parsers | Ongoing | Image parsers are a classic memory-safety target |
De-identification is harder than it looks
Stripping the obvious tags is the easy part. What gets missed:
- Private tags — vendor-specific fields that often duplicate identifiers
- Burned-in annotation — text rendered into the pixels, which no tag removal touches
- Structured reports and presentation states — separate objects carrying names
- UIDs — study and series UIDs can correlate back to the source if not remapped
- Acquisition dates — enough, with a small amount of context, to re-identify
If you export imaging for research or vendor support, verify the output rather than trusting the tool's defaults.
Where to start
Run a port scan from an ordinary clinical workstation VLAN against your DICOM ports. If you get an association from a device that has no business talking to the archive, you have found the work. Restricting by source IP is the single highest-value change and needs no vendor involvement.
This sits alongside the wider device programme — see IoMT security for inventory and segmentation, which imaging depends on.
GuardsArm assesses imaging estates including DICOM configuration review and de-identification validation. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “DICOM and PACS Security: Protecting Imaging Pipelines”
Talk to the GuardsArm team about how these services apply to your environment.
