Most PACS security programs focus on what happens to an image after it lands in storage: encryption at rest, key rotation, access logs; far fewer scrutinize the wire itself, the DICOM associations that carry pixel data between a CT scanner, a PACS server, and a radiologist’s workstation. That is where a surprising amount of exposure actually lives. A PACS DICOM network that trusts every device on the local subnet by default is one misconfigured firewall rule away from an unauthenticated C-STORE request landing in the archive. Securing DICOM network traffic means treating every association, not just every file, as something that has to earn its place on the network.
Most imaging networks were built around a simple assumption: if a device is plugged into the radiology VLAN, it is trusted. That assumption predates modern threat models, and it survives in a lot of production PACS deployments today. Modalities ship with DICOM services listening on open ports, DIMSE traffic often moves in plaintext by default, and Application Entity Titles function more like a directory listing than an access control.
None of that mattered when imaging networks were physically isolated. It matters now, when remote reading, cloud PACS, and multi-site sharing all put DICOM traffic on networks that touch the internet somewhere. Closing that gap structurally, rather than patching it after an audit finding, is exactly what a cloud-native platform like OmniPACS is built around.
How DICOM Associations Actually Work: SCP, SCU, and AE Titles
Every DICOM exchange happens inside an association, a negotiated connection between two Application Entities (AEs) that agrees on which services and data formats both sides support before a single image moves. Two roles matter here:
- Service Class User (SCU): the initiator. A modality querying a worklist, a PACS pushing a study to an archive, or a viewer pulling images all act as the SCU for that exchange.
- Service Class Provider (SCP): the receiver. The system that accepts the association request and performs the requested service, most commonly a PACS server accepting incoming studies.
A single system can hold both roles depending on the transaction. A PACS server is typically the SCP when a modality sends a study, but becomes the SCU when it forwards that study to a teleradiology partner. Each AE identifies itself with an AE Title, a short text label configured on both ends of the connection. DICOM’s built-in authentication for AE Titles is close to none: an SCU can claim almost any AE Title it wants unless the SCP is configured to verify it against a known list.
Ports matter too. DICOM’s well-known port is 104, though most modern deployments run services on the registered port 11112 to avoid the privileged-port restrictions port 104 carries on Unix-like systems. When TLS is in use, DICOM associations conventionally move to port 2762, registered as dicom-tls, keeping encrypted and unencrypted traffic on separate listeners rather than negotiating encryption mid-stream.
None of this is exotic. It is the plumbing every PACS, modality, and viewer relies on, including the C-FIND exchange used every time a modality is querying a worklist for its next scheduled patient. That plumbing was standardized in an era when being on the hospital network was treated as synonymous with being authorized, and it does little to challenge that assumption unless an administrator configures it to.
Why Legacy DICOM Traffic Is a Network-Level Risk
Two things make unencrypted, unauthenticated DIMSE traffic a real risk rather than a theoretical one. First, DICOM associations carry full patient identifiers, accession numbers, and pixel data together, so a passive network capture on an unencrypted segment is a HIPAA-scale exposure, not a partial one. Second, C-STORE and C-FIND, the services used to push and query studies, will typically accept requests from any SCU that can reach the listening port and present a plausible AE Title, because AE Title verification and IP-based restrictions are configuration choices, not defaults.
Security researchers have repeatedly found PACS servers reachable from the open internet with no authentication in front of the DICOM listener at all, usually the result of a firewall rule opened for a legitimate remote-access need and never scoped back down. Inside a hospital network, the same gap shows up differently: a compromised workstation or an unmanaged device on the same VLAN as imaging modalities can often open a DICOM association with the PACS server without ever touching a login screen, because nothing at the network layer asked it to prove it belonged there.
Hardening the PACS DICOM Network Layer
Closing these gaps is core DICOM security work: less about specialized tooling and more about applying standard network security discipline to a protocol that was not originally designed with it in mind. Four controls cover most of the exposure.
TLS on DICOM Associations
DICOM’s current transport security profile for associations requires servers and clients to support TLS 1.2 and prefer TLS 1.3 when both sides support it, with servers required to support bidirectional mutual authentication so the SCP can verify the SCU’s certificate rather than just its claimed AE Title. Every modality, PACS server, and viewer needs a valid certificate, issued from an internal certificate authority rather than a public one, since DICOM TLS authenticates machines to each other rather than browsers to websites. The profile also keeps DICOMweb and DIMSE traffic on separate TCP ports, so a facility running both should not assume one TLS configuration covers both paths.
Legacy modalities without TLS support are the usual blocker; segmenting them behind a TLS-terminating proxy is a reasonable interim step while vendor firmware catches up. A cloud PACS platform such as OmniPACS is built around encrypted connections from the start, removing the modality-by-modality guesswork legacy on-premise deployments carry when TLS gets enabled piecemeal.
AE Title and IP Allowlisting
An AE Title alone is not an access control; it is an identifier. Pairing it with IP allowlisting on the SCP side, so a given AE Title is only accepted from its known modality’s IP address, closes the gap where a spoofed title alone gets an association accepted. Most PACS platforms support rejecting any C-STORE or C-FIND request where the claimed AE Title and source IP do not match a configured pairing. Facilities that want this kind of connection-level control built into the platform, rather than configured modality by modality, can Check Out OmniPACS Services to see how role-based access and authenticated connections fit into a cloud PACS architecture built around least-privilege by default.
Network Segmentation and VLANs for Modalities
Every imaging modality, PACS server, and DICOM-speaking workstation belongs on its own segmented VLAN, isolated from general hospital IT traffic, guest networks, and unmanaged devices. A modality that only ever needs to talk to the PACS server and the worklist broker has no legitimate reason to reach the internet directly or to be reachable from the general clinical network. Segmentation limits blast radius: a compromised nurse workstation on the general network should not be able to open a DICOM association with a CT scanner, and a compromised modality should not be able to reach anything beyond the PACS server and worklist source it actually talks to. Firewall rules between segments should allow only the specific DICOM ports, 104, 11112, or 2762 for TLS, between known device pairs, not open ranges between subnets.
Closing Open C-STORE and C-FIND Access
Audit every PACS-facing firewall rule that predates the current security team. Remote-access rules opened for a vendor support session or a one-time migration have a tendency to outlive their purpose by years. Any C-STORE or C-FIND listener reachable from outside the segmented imaging VLAN, especially anything reachable from the internet, should be treated as a finding requiring immediate remediation, not a backlog item. Where remote facilities or teleradiology partners genuinely need to exchange studies, a VPN tunnel or a dedicated DICOM gateway with its own authentication and logging is the correct pattern, not a firewall hole punched directly to the PACS server’s DICOM listener.
| Layer | Control | Closes |
|---|---|---|
| Transport | TLS 1.2/1.3 with mutual auth on associations | Plaintext capture, unauthenticated peers |
| Identity | AE Title paired with IP allowlisting | Spoofed AE Titles |
| Network | Segmented VLAN per modality class | Lateral movement from compromised hosts |
| Perimeter | Remove stale open C-STORE/C-FIND rules | Internet-reachable DICOM listeners |
Applying Zero Trust Principles to Imaging Networks
Zero trust reframes all of the above around one premise: no device, association, or network segment is trusted by default, including ones inside the hospital’s own walls. For imaging networks specifically, that means three things in practice. Every DICOM association authenticates, regardless of whether the connection originates inside or outside the facility, so a modality on the radiology VLAN gets no more implicit trust than one connecting over a site-to-site VPN.
Access is scoped to what a device actually needs, so a mammography workstation does not need a standing path to every archive on the network, only the ones its workflow actually touches. And verification is continuous rather than one-time, so a certificate or AE Title pairing that was valid at deployment gets re-checked, not assumed to still be valid a year later when the device may have been repurposed or compromised.
A recent practice guide for implementing zero trust architecture lays out reference patterns most of this maps to directly: policy enforcement points that sit in front of resources rather than at a network perimeter, and continuous authentication rather than a single login event. Applied to an imaging network, the PACS server itself becomes one of those enforcement points, checking every incoming association against policy rather than trusting anything that already made it onto the subnet. OmniPACS’s cloud architecture applies that same posture at the platform level: role-based access and authenticated connections rather than implicit trust for anything already inside the perimeter.
What This Means for Imaging IT Teams
None of this replaces the work covered elsewhere: encrypting stored studies and managing key lifecycles, or vetting a cross-org sharing partner before opening a connection to them. It is the layer underneath those decisions, the assumption that every association on the network has actually earned the right to be there. Start with a structured risk assessment: which modalities and workstations currently reach the PACS server without TLS, which AE Titles have no IP pairing behind them, and which firewall rules predate the current team. Fix the internet-reachable findings first, then work inward toward full segmentation and mutual TLS across the fleet.
Facilities evaluating how much of this a cloud PACS already handles, versus how much depends on a firewall rule someone configured years ago, can look at how OmniPACS Delivers Scalable Monthly Plans, built around encrypted connections and role-based access from the start rather than retrofitted after an audit finding.
Frequently Asked Questions
What is the difference between DICOM SCU and SCP?
SCU (Service Class User) is the initiator of a DICOM association, such as a modality pushing a study or a viewer querying for images. SCP (Service Class Provider) is the receiver that accepts the association and performs the requested service, typically a PACS server. A single system can act as either role depending on the transaction.
Does DICOM traffic need to be encrypted?
DICOM does not encrypt traffic by default. Unencrypted DIMSE associations transmit patient identifiers and pixel data in plaintext across the network. Current DICOM transport profiles require TLS 1.2 or higher and require servers to support mutual authentication for compliant deployments, and any connection crossing an untrusted network segment should use it.
What port does DICOM use?
DICOM’s well-known port is 104, though most modern PACS deployments use the registered port 11112 to avoid the privileged-port restrictions port 104 carries on Unix-based systems. When TLS is enabled, associations conventionally move to port 2762, registered as dicom-tls, keeping encrypted traffic on a separate listener.
What does zero trust mean for a PACS network?
Zero trust means no device or association is trusted by default, including ones already inside the hospital network. Every DICOM connection authenticates and is scoped to only the resources it needs, and that verification repeats continuously rather than being granted once at deployment and assumed permanent.