Port 104: DICOM — The Port That Carries Your Body

Every CT scan of your chest. Every MRI of your brain. Every X-ray a technician takes at 2am in an emergency room. When those images travel across a hospital network from the scanner to the radiologist's workstation, they flow through port 104.

This is the port that carries DICOM: Digital Imaging and Communications in Medicine. It is the protocol that lets a GE scanner talk to a Siemens workstation, that lets a Philips MRI send images to a storage server built by a completely different company. Port 104 is the reason modern medical imaging works at all.

What Port 104 Does

Port 104 is the IANA-registered well-known port for the ACR-NEMA protocol, better known today as DICOM¹. When a medical imaging device (a CT scanner, an MRI machine, an ultrasound system) needs to send images to a PACS server (Picture Archiving and Communication System), it opens a TCP connection to port 104.

The protocol supports several core operations:

• C-STORE: Send an image to a server for storage
• C-FIND: Search for images matching specific criteria (patient name, date, body part)
• C-MOVE: Request that images be transferred from one location to another
• C-GET: Retrieve images directly

Because port 104 falls in the well-known range (0-1023), it requires root or administrator privileges on most operating systems. For environments where privileged port access isn't available, DICOM also uses port 11112 as a registered alternative². Two additional registered ports handle secured variants: port 2761 for DICOM over ISCL and port 2762 for DICOM over TLS.

How DICOM Works

DICOM builds on a subset of the OSI Application Layer, specifically the Association Control Service Element (ACSE)³. Before any images move, two DICOM Application Entities must establish an "association," a negotiated connection where both sides agree on what types of data they can exchange and what operations they support.

This negotiation matters. A CT scanner might produce images in a format that a particular workstation can't display. The association handshake ensures both sides agree on transfer syntaxes (how the data is encoded) and abstract syntaxes (what the data represents) before a single pixel moves across the wire.

Once the association is established, the sending device wraps each image in a DICOM object: the pixel data plus a rich set of metadata tags. Patient name. Date of birth. Hospital. Referring physician. Study description. Body part examined. Every DICOM object is self-describing, carrying everything needed to identify, display, and file the image correctly.

The History

The Tower of Babel Problem

In the late 1970s, computed tomography and other digital imaging modalities arrived in hospitals. For the first time, diagnostic images existed as digital data, not just film. But every manufacturer encoded those images differently. A Siemens CT scanner produced files that a GE workstation couldn't read. Printing images from one vendor's system on another vendor's printer was an exercise in frustration⁴.

Hospitals were drowning in incompatible formats. The dream of a "filmless" radiology department, where images could be stored, retrieved, and shared electronically, was blocked by the simple fact that the machines couldn't talk to each other.

The Committee Forms (1983)

The American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) recognized the problem and formed a joint committee in 1983. Their first meeting took place on November 12, 1983, at the Palmer House Hotel in Chicago⁵. What made this meeting remarkable was that it assembled competitors: radiologists, physicists, and engineers from rival equipment manufacturers, all sitting in the same room, agreeing that a shared standard was more valuable than proprietary lock-in.

ACR-NEMA 300 Version 1.0 (1985)

The committee's first standard, ACR/NEMA 300, was published in 1985. It specified a hardware interface for point-to-point image transmission over a dedicated cable, a data dictionary defining how information should be encoded, and a command set for initiating transactions⁶. It was a start. It was also, by the committee's own admission, vague and internally contradictory.

Version 2.0 (1988) and First Deployment (1992)

Version 2.0 arrived in 1988, specifying transmission over a dedicated 2-pair EIA-485 cable. The first demonstration happened at Georgetown University in May 1990. The first large-scale deployment came in 1992, when the US Army and Air Force rolled out PACS systems at major military medical facilities as part of the MDIS (Medical Diagnostic Imaging Support) program⁷.

DICOM 3.0: The Network Revolution (1993)

Everything changed with version 3.0 in 1993. The standard was renamed "Digital Imaging and Communications in Medicine," and for the first time, it specified networking over TCP/IP⁸. No more dedicated cables. Images could flow over standard hospital networks. Port 104 was registered with IANA as the well-known port for the protocol.

This was the version that made DICOM what it is today. It defined service classes that went beyond simple file transfer, created a mechanism for uniquely identifying information objects across networks, and laid the foundation for the PACS systems that now operate in virtually every hospital on Earth.

Expansion (1995-Present)

In 1995, the American College of Cardiology joined, and the standard expanded beyond radiology. Over the following decades, DICOM absorbed ultrasound, X-ray angiography, nuclear medicine, endoscopy, dermatology, dentistry, and ophthalmology. Today, DICOM supports DICOMweb, a suite of RESTful web services aligned with HL7 FHIR, bringing medical imaging into the modern web era⁹.

Security: The Crisis

Here is the truth about port 104: the protocol it carries was designed in 1983, before cybersecurity was a discipline. DICOM's original security model was physical. You needed access to a PACS workstation to communicate with other systems. The network was the security boundary¹⁰.

That assumption shattered when hospitals connected to the Internet.

No Authentication Required

DICOM, by default, requires no authentication. Anyone who can reach port 104 on a PACS server can request images. No username. No password. Just connect and ask¹¹.

The Scale of Exposure

In September 2019, researchers found thousands of vulnerable PACS servers accessible from the Internet within the United States alone. A follow-up study by German security firm Greenbone Networks found exposed servers in 52 countries, with 24 million medical records accessible to anyone who knew where to look¹².

As of 2021, approximately 130 health systems were exposing 8.5 million case studies representing over 2 million patients, with roughly 275 million images available for download. The leaked data includes not just images but patient names, dates of birth, social security numbers, diagnoses, and physician information¹³.

Beyond Theft: Manipulation

The threat goes beyond data theft. Researchers have demonstrated that attackers can modify DICOM images in transit, potentially altering scan results. A manipulated CT scan could lead to a misdiagnosis. A falsified MRI could change a treatment plan. The protocol that carries the images doctors use to make life-and-death decisions has no built-in mechanism to verify that those images haven't been tampered with¹⁴.

Why It Persists

Medical facilities have a tendency to "plug and play" their PACS systems without securing them. Equipment vendors ship systems configured for ease of installation, not security. The protocol itself, designed for a world of isolated hospital networks, offers TLS as an option (port 2762) but not a requirement. And upgrading medical imaging infrastructure is expensive, slow, and carries its own risks when patient care depends on the systems staying operational.

Related Ports