PACS and DICOM Security: The Practitioner's Guide

Introduction

DICOM was standardised in an era when the network it ran on was assumed to be trusted, physically controlled, and populated only by devices the department owned. Every security property the protocol lacks traces back to that assumption, and that assumption stopped being true decades ago.

The result is a protocol carrying some of the most sensitive data a hospital holds, with authentication, encryption, and authorisation all optional and frequently unused. Imaging systems are also among the least patchable devices on the network, which removes the control most security programmes rely on first.

This guide covers what the protocol does and does not give you, what an attacker can do with an unprotected imaging environment, and how to harden a real deployment without breaking clinical workflow.

1. What DICOM Assumes

The Association Model

A DICOM transaction begins with an association request: one node asks another to open a conversation, identifying itself with an Application Entity (AE) title. The receiver checks whether it recognises the AE title, the calling host, and the requested services, then accepts or rejects.

The critical property: the AE title is an identifier, not a credential. It is a string sent in the clear. Any device that can reach the port can claim any AE title. Configuring a PACS to accept associations only from known AE titles is a useful control against accidents and misconfiguration; it is not authentication, and it should never be described as such in a risk assessment.

What follows from this, on a network segment an attacker can reach:

C-FIND enumerates the archive — patient names, IDs, accession numbers, study descriptions. A query interface with no restriction is a patient-index disclosure.
C-MOVE / C-GET retrieves the images themselves.
C-STORE writes new objects into the archive — which is a data-integrity problem, not merely a storage one.

None of these require an exploit. They are the protocol working exactly as designed, used by a peer the system was configured to trust implicitly.

What the Standard Does Provide

DICOM does define security mechanisms; adoption is the problem, not availability.

TLS for the transport, including mutual certificate authentication — supported by most modern implementations, enabled in a minority of deployments
Audit logging (DICOM Supplement 95 / ATNA), which defines a structured audit message and a syslog transport
De-identification profiles (PS3.15 Annex E) for the removal of identifying attributes
Digital signatures on objects, which are genuinely rare in practice

Where a vendor supports these, the practical work is enabling and validating them. Where a vendor does not, that is a procurement finding worth recording.

2. Internet-Exposed Imaging Systems

Publicly reachable, unauthenticated DICOM endpoints are a recurring finding in healthcare security research, and the count of exposed systems has remained stubbornly non-zero for years. These are not exotic breaches — they are archives reachable from the open internet, answering queries from anyone.

They rarely get exposed deliberately. The recurring causes:

A firewall rule opened for a teleradiology partner, scoped to "any" source and never narrowed
A temporary rule added during a migration or go-live and never removed
A device placed on a segment with an unintended route to the internet
A vendor support tunnel left permanently open
A cloud-hosted instance deployed with a permissive default security group

Find your own before someone else does. Concretely:

Enumerate every public IP address the organisation owns — including cloud subscriptions and anything a department procured independently
Scan them from outside for DICOM ports (104, 11112, and any non-standard ports in use locally), plus DICOMweb over HTTP/HTTPS
Reconcile every open port against a documented, business-justified rule with a named owner and a review date
Repeat on a schedule, because rules accumulate

The reconciliation step is the one that gets skipped, and it is where the findings are. An open port with no documented owner is the finding.

3. TLS for DICOM: What It Does and Does Not Solve

What it gives you: confidentiality in transit, integrity against tampering, and — with mutual TLS — real peer authentication rather than a claimed AE title.

What it does not give you: authorisation. A peer authenticated by certificate is still authorised by your configuration. Mutual TLS proves who is connecting; your AE and service configuration still decides what they may do.

Practical considerations:

Not every modality supports it. Older devices frequently cannot do TLS at all. Where the device cannot, the compensating control is network segmentation, and that gap should be recorded on the risk register rather than quietly accepted.
Certificate lifecycle becomes an operational responsibility. An expired certificate on a clinical interface is an outage. Track expiry dates in the same system you use for other clinical dependencies, and alert well before expiry.
Performance impact is modest on modern hardware, but validate it on the diagnostic read path rather than assuming.
Enable it in stages. Start with the highest-value links — inter-site, external partners, anything crossing a segment boundary — rather than attempting a single cutover across every modality.

For paths where TLS is genuinely impossible, a VPN or dedicated circuit provides transport protection at a different layer. That is a legitimate architecture, provided it is documented as the control it is.

4. Access Control and the Break-Glass Problem

Imaging systems have an authorisation model that fits clinical reality poorly. Clinicians need broad access to patient images because care is unpredictable, which makes least-privilege hard to apply through role restrictions alone.

What works better in practice:

Role separation that reflects real duties. Radiologists, technologists, referring clinicians, administrators, and vendor support accounts have genuinely different needs. Vendor support in particular should not hold standing administrative access — it should be requested, time-bounded, and logged.

Break-glass access that is monitored rather than blocked. Emergency access to records outside a user's normal scope should be possible, explicitly labelled, and reviewed afterwards. Access that is technically prevented gets worked around; access that is visible gets used appropriately.

Detection instead of prevention for the inappropriate-access problem. The classic insider case — a staff member viewing a colleague's or a public figure's imaging — cannot be prevented by role restrictions without harming care. It is caught by audit review: same-surname access, VIP-flagged records, access with no corresponding order or encounter, and volume anomalies per user.

Account lifecycle discipline. Leaver accounts, shared logins at shared workstations, and vendor accounts that outlive the engagement are the recurring audit findings. Reconcile system accounts against HR and contract records on a schedule.

5. Audit Logging

Audit logs matter for two distinct purposes — regulatory demonstration and actual incident investigation — and a log that satisfies the first often fails the second.

At minimum, capture: who, what patient/study, what action, from where, when, and whether it succeeded.

Design points that determine whether the log is usable:

Forward logs off the system that generates them. Logs stored only on a compromised host are evidence an attacker controls.
Retain in line with your investigation window. Intrusions are frequently discovered months after the initial access; logs that roll over in thirty days cannot answer the questions that follow.
Make them searchable by patient and by user. A log you can only read sequentially will not be read.
Review proactively, at least by exception rule. Logs nobody looks at until an incident are a compliance artefact, not a control.

Where systems support ATNA-style structured audit messages over syslog, centralising them is substantially less work than parsing per-vendor formats after the fact.

6. Modalities: The Devices You Cannot Patch

Imaging devices run embedded operating systems that are often years behind, cannot be patched independently of the vendor, and may lose regulatory clearance or support if modified. Standard endpoint controls generally do not apply.

The workable strategy is compensating controls:

Segmentation. Modalities on a dedicated segment, with explicit rules for the specific flows required — the modality's DICOM traffic to the PACS, worklist queries to the RIS, and nothing else. This is the single most effective control available.

Egress restriction. A CT scanner has no reason to reach the internet. Denying outbound access by default removes an entire class of attack paths and does not affect clinical function.

Inventory that is actually complete. You cannot protect a device you do not know about. The inventory should record OS version, network location, AE title, vendor support status, and the patch commitment. Building it is tedious and is the prerequisite for everything else.

Vendor accountability in contracts. Patch commitments, vulnerability disclosure timelines, and support windows belong in the procurement agreement. This is the point of maximum leverage, and it passes once per device generation.

Monitoring in place of prevention. If you cannot harden the device, watch it. Unexpected outbound connections, unusual protocols, or traffic outside the device's normal pattern are detectable even when the device itself is opaque.

7. Hardening Checklist

Network

Modalities on a dedicated, isolated segment
Inter-segment rules documented per flow with named owners
No imaging system reachable from the internet without explicit, reviewed justification
External scan of all owned public ranges performed and reconciled on a schedule
Vendor remote access brokered, time-bounded, and logged
Modality egress to the internet denied by default

DICOM configuration

AE title allow-lists configured, with the understanding that they are not authentication
Unused DICOM services disabled per node
TLS enabled where supported, prioritising external and cross-segment paths
Certificate expiry tracked and alerted
Default and vendor-shipped credentials changed on every device
DICOMweb endpoints authenticated and rate-limited

Access

Roles reflect actual duties; administrative access is separate and limited
No shared accounts on systems that record clinical access
Break-glass access labelled and reviewed
Vendor accounts time-bounded and reconciled against contracts
Leaver process verified against imaging systems specifically

Audit and detection

Audit logging enabled on PACS, VNA, and RIS
Logs forwarded to central, tamper-resistant storage
Retention exceeds realistic time-to-detection
Exception rules configured (same-surname, VIP, out-of-hours, volume anomalies)
Alerting on unexpected modality network behaviour

Resilience

At least one immutable or offline copy of the archive
Restore tested and timed, with results recorded
Downtime procedures current and distributed
Incident response plan names imaging systems specifically