Medical imaging systems routinely expose patient images and identities because DICOM allows encryption and authentication but does not require them, and many picture archiving and communication systems (PACS) still accept any connection that presents a known application entity title. Investigations have repeatedly found PACS servers answering queries from the open internet with no password, and DICOM files themselves can carry executable code in their preamble. This guide explains how DICOM and PACS communicate, where the security gaps are, which DICOM security profiles to enable, how to lock down archives, viewers, DICOMweb and removable media, and what to monitor. It is for radiology IT teams, clinical engineering, hospital security teams and PACS administrators. For the wider medical device programme, see the Medical Device Security Guide; this page goes deeper on imaging.
Key takeaways
- DICOM leaves security to the operator. The DICOM Standards Committee states that DICOM facilitates encryption but does not mandate it; TLS for DIMSE and HTTPS for DICOMweb must be enabled deliberately by vendor and hospital.
- An AE title is not a password. Most PACS decide who may query, retrieve and store by calling application entity title and IP address, both of which any host on the network can claim.
- Internet-exposed PACS are a recurring breach. In 2019 investigators found 187 unprotected US servers holding data for more than 5 million patients, and problems in at least 52 countries.
- DICOM files can be executables. CVE-2019-11687 describes how the 128-byte preamble of a Part 10 file can hold Windows or Linux executable headers, so imaging files on media and in archives need malware scanning and blocked execution.
- The archive is the high-value system. PACS and vendor neutral archives hold years of identifiable data and service accounts that reach every modality, so they need the same privileged access, backup and monitoring as any Tier 1 clinical system.
How DICOM and PACS communicate
DICOM (Digital Imaging and Communications in Medicine) defines both a file format (Part 10) and network services. Imaging devices, archives and workstations are DICOM application entities, each identified by an AE title, host and port. A typical imaging workflow involves several distinct flows, each of which needs a security decision.
| Flow | DICOM service | Typical port | Security concern |
|---|---|---|---|
| Modality fetches the worklist from RIS | Modality Worklist (C-FIND) | 104 or 11112 | Patient demographics in cleartext; spoofed worklist entries |
| Modality sends images to PACS | C-STORE | 104 or 11112; 2762 for DICOM TLS | Unauthenticated store; images in cleartext |
| Workstation queries and retrieves | C-FIND, C-MOVE, C-GET | 104 or 11112 | Any host claiming a known AE title can query and pull studies; C-MOVE sends data to a destination named by AE title |
| Connectivity test | C-ECHO | 104 or 11112 | Confirms a live DICOM service to scanners and attackers alike |
| Web viewers and integrations | DICOMweb (QIDO-RS, WADO-RS, STOW-RS) | 443 | Web application and API security, tokens, viewer authentication |
| Sharing with other sites and patients | Media (CD, DVD, USB), email, cloud image exchange | Not applicable | Malicious files, lost media, unencrypted transfers |
IANA registers port 11112 for DICOM and 2762 for DICOM TLS (2761 for the older ISCL profile); port 104 is the historic well-known port and is still widely used. The DIMSE protocol has no mandatory authentication: an association request names the calling and called AE titles, and the receiving application decides whether to accept it, usually from a configured list of AE titles and IP addresses.
DICOM security profiles worth enabling
DICOM PS3.15 (Security and System Management Profiles) contains the mechanisms the standard offers. Products declare which ones they support in their DICOM conformance statement, and the hospital's job is to require the right ones in procurement and switch them on.
| Profile (PS3.15) | What it gives you | Recommendation |
|---|---|---|
| B.9 to B.13 BCP 195 TLS Secure Transport Connection Profiles (including the RFC 8996 and 9325 variants and the Non-Downgrading profile) | TLS for DIMSE associations following IETF best current practice; mutual certificate authentication is possible | Require current BCP 195 profile support in procurement; prefer non-downgrading behaviour; avoid the retired B.1 Basic TLS profile |
| B.4 to B.7 User Identity Association Profiles | Passing a user name, passcode, Kerberos ticket or SAML assertion in the association | Use Kerberos or SAML where both ends support it so queries are tied to a person, not just a workstation |
| A.5 to A.7 Audit Trail Message Format and Transmission (SYSLOG-TLS, SYSLOG-UDP) | Standard audit messages for access, query, export and security events | Send audit messages over SYSLOG-TLS to the SIEM or an audit repository |
| Annex C Digital Signature Profiles | Signatures over DICOM objects and structured reports | Use for reports and where integrity of exchanged objects matters |
| Annex D Media Storage Security | Encapsulating DICOM files in secure (CMS) files on media and email | Use for media and email exchange where recipients support it |
| Annex E Attribute Confidentiality Profiles | Standard de-identification, with options such as Clean Pixel Data | Use for research, teaching and AI training exports; validate burned-in text separately |
| G.1 Basic Time Synchronization | NTP time for consistent audit timestamps | Enable everywhere so audit trails correlate |
The DICOM committee also notes that sites sometimes run unencrypted DICOM over an encrypted VPN between sites, and that this may not be advisable from a cybersecurity standpoint: it protects the link but not the endpoints or the internal network.
Locking down the PACS and archive
- Never expose DIMSE to the internet: block 104, 11112 and 2762 at the perimeter. Remote reading belongs behind a brokered remote access service or a hardened, authenticated web viewer, not a port forward. Check regularly with an external scan of your own address ranges.
- Restrict associations: configure the PACS to accept associations only from listed AE title and IP pairs, and only for the services each peer needs (a modality stores, it does not need query and retrieve). Reject unknown AE titles rather than accepting them as anonymous.
- Constrain C-MOVE destinations: allow retrieve only to destinations defined in the PACS, so a caller cannot ask the archive to push studies to an arbitrary AE title and address.
- Turn on TLS where supported: start with links that leave the imaging network (to cloud archives, teleradiology and other sites) and with archive to workstation traffic, then extend to modalities as firmware allows.
- Harden the operating system and database: PACS servers commonly run Windows and a commercial database. Apply vendor-approved patches, remove local administrator rights from service accounts, and follow the vendor's MDS2 form for supported security settings. See the MDS2 and Medical Device SBOM Guide for Hospitals.
- Segment imaging: put modalities, PACS, RIS and reading workstations in dedicated zones with allow-listed flows; see the Hospital Clinical Network Segmentation Guide.
- Back up the archive offline: imaging archives are large, so backup is often a replicated second copy online. Keep at least one immutable or offline copy and test restoring a full study set, because a ransomware attack that stops the PACS delays diagnosis.
DICOMweb and web viewers
Modern PACS, vendor neutral archives and cloud imaging platforms expose DICOMweb RESTful services and zero-footprint viewers over HTTPS. These move the risk from DIMSE to web application security.
- Authentication: require single sign-on with MFA for viewers, and OAuth 2.0 access tokens (for example SMART on FHIR style launches) for integrations rather than static API keys or basic authentication.
- Authorisation: scope QIDO-RS queries and WADO-RS retrieval to the studies a user or integration is entitled to; broken object level authorisation on study and series identifiers is the classic API failure. See the OWASP API Top 10 API1 Broken Object Level Authorization Guide.
- Share links: patient and referrer image sharing links should expire, be single purpose and be logged.
- Exposure: publish viewers only through a reverse proxy or web application firewall, and include them in external vulnerability scanning and penetration testing.
Malicious DICOM files and removable media
A DICOM Part 10 file starts with a 128-byte preamble that the standard leaves unspecified so that dual-purpose files (for example TIFF and DICOM in whole slide imaging) can exist. CVE-2019-11687 describes how that space can hold Portable Executable or ELF headers, producing a file that is both a valid image and a runnable program, even with a .dcm extension. Exploitation needs someone or something to execute the file, and the record notes that anti-malware configurations in healthcare often ignore medical imagery. The DICOM committee points out that the network protocol does not transmit the preamble, so the risk is in files: media, email, downloads and file shares.
- Scan imaging files: remove blanket anti-malware exclusions for DICOM folders where the vendor allows, or scan at the import point instead.
- Import media on a dedicated station: disable autorun and file execution when importing CDs and DVDs, as the DICOM committee recommends, and import through software that rewrites or zeroes the preamble.
- Application control: block execution from media and from image import and cache folders on workstations and servers. See the Application Allowlisting Guide.
- Prefer network exchange: cloud image exchange or DICOMweb with authentication removes much of the media risk.
Where identity fits
Imaging runs on non-human identities. Each modality, router, AI analysis node and archive is an AE title with network trust; integration engines, cloud archives and AI vendors hold service accounts and API tokens with access to whole archives; and PACS administrators often share vendor support accounts. Keep an inventory of AE titles and their permitted services, give each integration its own scoped credential, store DICOMweb client secrets in a vault, require named accounts with MFA for vendor support access, and review all of them at least annually. See the Healthcare Identity Security Guide and the OT Remote Access Guide for vendor access patterns.
Implementation roadmap
- Discover: list every DICOM node (AE title, host, port, services, software version) from PACS configuration and passive monitoring, and run an external scan for any DICOM or viewer service visible from the internet.
- Close exposure: remove any internet-reachable DICOM ports immediately and move remote reading to authenticated access.
- Tighten association rules: move from accept-all to listed AE title and IP pairs with least-privilege service permissions; test in a maintenance window with radiology present, and keep the previous configuration export for rollback.
- Enable audit: turn on DICOM and IHE ATNA audit messages over SYSLOG-TLS and send them to the SIEM.
- Encrypt: enable DICOM TLS on external and archive links first, then on modalities as vendors support it; use procurement to require current BCP 195 profiles.
- Fix files and media: dedicated import stations, scanning and execution controls.
- Measure and repeat: report the metrics below quarterly to the clinical risk group.
Decision guidance
- Small practice or imaging centre: a hosted or cloud PACS with SSO and MFA often gives better security than a self-run server; focus on internet exposure, modality segmentation and media handling.
- Large hospital or group: standardise association policies across sites, centralise audit, and require TLS and user identity profiles in every new modality and archive contract.
- Legacy modalities without TLS: keep them on an isolated VLAN that can reach only the PACS on the store port, and terminate TLS at a gateway or the PACS for anything leaving the zone.
Detection and measurement
| Signal | Source | Why it matters |
|---|---|---|
| Association rejected for unknown calling AE title | PACS logs, DICOM audit messages | Scanning, misconfiguration or spoofing |
| Large C-FIND or C-MOVE volumes from one node or user | DICOM audit, network monitoring | Bulk exfiltration of studies |
| C-MOVE to a destination outside the defined list | PACS logs | Data redirection |
| Inbound DICOM or viewer connections from the internet | Firewall and external scans | Exposure of the archive |
| Executable content in DICOM preambles | Anti-malware, file inspection at import | Polyglot malware described in CVE-2019-11687 |
| New service account or vendor login to PACS | Directory and PACS audit | Persistence or unauthorised support access |
Metrics
- Number of DICOM or imaging viewer services reachable from the internet (target zero).
- Percentage of DICOM peers governed by an explicit AE title, IP and service allow list.
- Percentage of external and archive links using DICOM TLS or HTTPS.
- Share of imaging systems sending audit messages to the SIEM.
- Time to restore a representative set of studies from offline backup.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK (Enterprise) |
|---|---|---|---|
| Remove internet exposure; segment imaging | SC-7 Boundary Protection | PR.IR-01 | T1190 Exploit Public-Facing Application; T1133 External Remote Services |
| DICOM TLS and HTTPS | SC-8 Transmission Confidentiality and Integrity | PR.DS-02 | T1557 Adversary-in-the-Middle; T1040 Network Sniffing |
| AE title allow lists and user identity profiles | IA-3 Device Identification and Authentication; IA-2 Identification and Authentication; AC-3 Access Enforcement | PR.AA-05 | T1078 Valid Accounts |
| Audit trail profiles | AU-2 Event Logging; AU-12 Audit Record Generation | DE.CM-01 | T1005 Data from Local System |
| Malicious file and media controls | SI-3 Malicious Code Protection; MP-6 Media Sanitization | PR.PS-05 | T1204.002 User Execution: Malicious File; T1091 Replication Through Removable Media |
| Offline archive backups | CP-9 System Backup | PR.DS-11 | T1486 Data Encrypted for Impact |
For HIPAA-regulated organisations, these controls support the Security Rule's access control, audit control and transmission security standards; see the HIPAA Security Rule Guide.
Common failure patterns
- Accept-any-AE configuration: the PACS accepts associations from any calling AE title so new modalities "just work", which also lets any laptop query and retrieve every study.
- Port forwarding for remote reading: a firewall rule opened for a radiologist or teleradiology partner years ago that still exposes DIMSE or an unauthenticated viewer to the internet. This is the pattern behind the 2019 exposure findings, where some servers were connected directly to the internet without a VPN or firewall.
- Trusting the VPN instead of the endpoint: unencrypted DICOM over a site-to-site VPN, with no controls on what each site can reach once inside.
- Imaging folders excluded from anti-malware: blanket exclusions for performance that leave polyglot DICOM files unscanned on workstations that also browse and read email.
- Shared vendor and service accounts: one support account used by every engineer, with domain admin rights on the PACS server and no MFA.
- Online-only archive replicas: a second archive copy that ransomware can encrypt as easily as the first.
Practitioner checklist
- Scan your external ranges for ports 104, 11112, 2762 and imaging viewers, and close anything found.
- Inventory every AE title with host, port, permitted services and owner.
- Configure the PACS to accept only listed AE title and IP pairs, with least-privilege services and fixed C-MOVE destinations.
- Enable DICOM TLS (current BCP 195 profile) on external and archive links and require it in procurement.
- Require SSO with MFA for web viewers and scoped OAuth tokens for DICOMweb integrations.
- Send DICOM audit trail messages over SYSLOG-TLS to the SIEM, with time synchronisation.
- Scan imaging files, use dedicated media import stations and block execution from media and import folders.
- Give each integration and vendor its own credential with MFA, and review them annually.
- Keep an offline or immutable archive copy and test full restores.
Standards and references
- DICOM Standards Committee: Security and DICOM
- NEMA: DICOM PS3.15 Security and System Management Profiles
- IANA: Service Name and Transport Protocol Port Number Registry
- CVE Program: CVE-2019-11687 DICOM Part 10 preamble
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Exploit Public-Facing Application
- ProPublica: Millions of Americans' Medical Images and Data Are Available on the Internet
Related NHI Mgmt Group resources: Medical Device Security Guide · Hospital Clinical Network Segmentation Guide · HL7 v2 and Clinical Interface Engine Security Guide · Healthcare Identity Security Guide · FDA Medical Device Cybersecurity Guide