DICOM and PACS cybersecurity: why medical imaging still runs unauthenticated by default

Only as an optional add-on, not a default. DICOM (Digital Imaging and Communications in Medicine) is the NEMA-maintained standard behind how imaging modalities, PACS archives and viewing workstations exchange studies, and its core network protocol — the association and C-STORE/C-FIND/C-GET services that move images between Application Entities — was designed, per NEMA's own PS3.15 part of the standard, on the assumption that "Application Entities may not trust the communications channel by which they communicate with other Application Entities," yet does not itself mandate authentication, integrity checking or encryption on that channel. Security is addressed in a separate part, PS3.15 ("Security and System Management Profiles"), which the standard itself describes as a set of profiles an implementation "may claim conformance to" — entirely optional. In practice, this means a PACS server or modality can accept a C-STORE request from any Application Entity that knows its AE title and port, with no verification of who is actually sending it, unless an administrator has explicitly turned on one of PS3.15's secure-use profiles or added network-level protection like a VPN or firewall rule.

PS3.15 defines several Secure Use Profiles an implementation can conform to, each addressing a different part of the problem. The Online Electronic Storage Secure Use Profile, per the standard's own Annex A.1, requires that a transfer "occur on a Secure Transport Connection," that "the two Application Entities involved in the transfer shall authenticate each other and shall confirm via the authentication that the other supports" the same profile, and that the receiving Application Entity "reject the storage request and discard the received SOP Instance" if post-transfer integrity checks show it was altered in transit — i.e., mutual authentication plus transport encryption plus tamper detection, together. Separately, the Basic Digital Signatures Secure Use Profile addresses data-at-rest integrity: an implementation storing a SOP Instance must guard it against unauthorized tampering and, where possible, validate any digital signature already embedded in it. A third profile defines an Audit Trail Message Format — an XML schema for logging who accessed what imaging data, when, and from where, the kind of record HIPAA-covered entities need regardless of whether DICOM's own encryption is in use. None of this is enabled by default in the base protocol; a site has to choose to implement it, which is exactly the gap that lets a PACS ship and run with no authentication on its DICOM interface at all.

Documented at a scale that is hard to overstate. In a 2019 audit, security firm Greenbone Networks — working with reporting partners ProPublica and Bayerischer Rundfunk — scanned roughly 2,300 internet-connected PACS servers discovered via Shodan and Censys between July and September 2019, and found 590 of them required no authentication whatsoever to retrieve images. Those 590 servers alone exposed an estimated 24.3 million patient studies and 733 million medical images, of which about 399.5 million could be directly viewed or downloaded, spanning 52 countries, with the single largest concentration (187 servers, roughly 303 million images covering about 5 million patients) found in the United States. A November 2019 Greenbone follow-up found the number of exposed records had grown by more than half, to roughly 35 million patients and 1.19 billion scans. Greenbone's own conclusion was that the root cause was server and network misconfiguration — PACS deliberately exposed so remote physicians could reach them — rather than a flaw unique to DICOM or any single vendor's PACS software, which matches PS3.15's design: the standard offers the secure-use profiles, but nothing in base DICOM stops a site from running without them.

Three things, in rough order of what stops the most damage fastest. First, confirm no DICOM Application Entity — PACS archive, modality or viewer — is reachable from the public internet without a VPN or equivalent gateway in front of it; Greenbone's audits found exposure almost always traces to a PACS deliberately opened for remote access rather than an exotic attack path, so this is the single highest-value check. Second, patch imaging software and the DICOM toolkits it embeds: CISA's ICSMA-26-181-01 (published 30 June 2026) assigned five CVEs to OFFIS DCMTK — an open-source DICOM toolkit embedded in many commercial imaging products — including CVE-2026-50003 (CWE-22 Path Traversal, CVSS v3.1 9.8) where a malicious or compromised server can make a DCMTK client write files outside its intended output directory, and CVE-2026-52868 (CWE-22, CVSS v3.1 8.2) letting an unauthenticated attacker read worklist records across departmental boundaries — the kind of finding that reaches every product bundling that toolkit, not one vendor's codebase. Third, for anything older still relying on hard-coded or default credentials: CISA's ICSMA-18-037-02 (originally posted 6 February 2018, last revised 13 March 2018) covers GE Healthcare's Centricity PACS Server, RA1000 workstation and PACS-IW, all affected by CWE-287 Improper Authentication findings (CVSS v3 9.8) tied to default or hard-coded credentials, for which GE's own patches remained unavailable for three of the affected systems as of that revision — exactly the class of legacy gap [PSIRT and disclosure practices](/guides/first-psirt-services-framework/) exist to close before an advisory, not after a breach. Where a product is itself a medical device under FDA's 2025 premarket cybersecurity guidance, a PACS or imaging workstation's DICOM interface specifically needs its own authentication and penetration-testing evidence — see [FDA premarket cybersecurity for medical devices](/guides/fda-premarket-cybersecurity-medical-devices/) — rather than being covered implicitly by the product's general web-application security testing.