What Is DICOM? Medical Imaging Standard and Security Risks

Part of our Medical device vulnerability, threat, and attack-technique catalogue. For the full overview, start with The Top 50 Cybersecurity Issues with Medical Devices.

Direct Answer

DICOM is the standard format and communication protocol that lets imaging systems such as X-ray, MRI, CT, and ultrasound devices exchange images and associated patient metadata consistently across vendors. It enables interoperability with PACS, RIS, and EHR platforms, but the standard itself does not guarantee security, since encryption, authentication, and access control depend on how a manufacturer implements it. Under the FDA's February 3, 2026 premarket cybersecurity guidance, manufacturers must validate and document those DICOM implementation choices.

DICOM, short for Digital Imaging and Communications in Medicine, is the standard that lets medical imaging systems exchange images and related data in a usable format. If your device creates, stores, transmits, or displays diagnostic images, DICOM is usually part of the architecture, and part of the risk surface.

Why this matters

The stakes for DICOM implementation are high: improper handling can lead to significant cybersecurity risks, including unauthorized access to patient data, data tampering, and disruption of clinical operations. DICOM-enabled devices, by their nature, transmit and store sensitive patient information, making them prime targets for cyberattacks if not adequately secured.

The FDA, in its "Cybersecurity in Medical Devices" final guidance dated February 3, 2026, emphasizes that manufacturers must account for the security of medical device data during all phases of the product lifecycle, including adherence to established standards like DICOM for data exchange. This guidance mandates that manufacturers identify and mitigate cybersecurity vulnerabilities that could arise from standard protocols.

Relevant standards include IEC 80001-1 for risk management of IT networks incorporating medical devices, and elements of IEC 62304 for medical device software lifecycle processes, which indirectly apply to secure DICOM implementation. AAMI TIR57 / ANSI/AAMI SW96:2023 also provides valuable guidance on the principles of medical device security, which are directly applicable to securing DICOM communications and data storage.

Understanding the Basics of DICOM

DICOM defines both a file format and communication rules for exchanging medical images and associated information. The goal is interoperability: imaging systems, workstations, archives, and clinical platforms should be able to move data without custom one-off integrations for every vendor pairing.

DICOM is not just about pixels. It also carries metadata such as patient identifiers, study details, acquisition parameters, measurements, annotations, and reports. That context is what makes an image clinically useful and operationally traceable.

Defining DICOM in Medical Devices

DICOM is most closely associated with imaging devices such as X-ray systems, MRI scanners, CT scanners, ultrasound machines, and mammography platforms. These systems generate images in a standardized structure so downstream systems can store, retrieve, display, and analyze them consistently.

The standard supports more than simple 2D images. Depending on the modality and use case, DICOM can represent 3D reconstructions, multi-frame studies, waveforms, structured reports, and other data objects used across radiology, cardiology, oncology, orthopedics, and related specialties.

Why DICOM Matters in Healthcare

Without a shared standard, imaging data gets trapped in vendor silos. DICOM gives healthcare organizations a common format and protocol set so clinicians can access studies across devices and systems with less friction.

That matters for patient care, but it also matters for compliance and security. A DICOM implementation affects data integrity, traceability, authentication, encryption choices, workflow design, and how a device interacts with PACS, RIS, EHR platforms, and remote systems. For manufacturers, this is not just an interoperability feature. It is a design control and cybersecurity concern.

How DICOM Works

DICOM uses a network communication protocol known as TCP/IP for transport and defines its own application-layer services for moving and managing medical data. Devices and software exchange information using standardized commands and service classes, while the DICOM file structure stores image data and metadata in a predictable format.

A few technical concepts matter in practice:

Objects and metadata: DICOM packages images and related information together so the receiving system has clinical context, not just a bitmap.
UIDs (Unique Identifiers): Studies, series, and individual instances get unique identifiers so systems can track and reference data accurately.
Services and workflows: Systems can store, query, retrieve, print, and exchange worklists using defined DICOM services.
Modality worklists: Imaging devices can pull scheduled exam and patient information from systems such as Radiology Information Systems (RIS), reducing manual entry and the errors that come with it.

Key Features of DICOM

Several features explain why DICOM remains foundational in medical imaging:

Standardized formatting: It gives vendors a common structure for many image and data types.
Interoperability: It allows devices and software from different manufacturers to exchange data with less custom integration work.
Compression support: It can reduce storage and bandwidth demands, though compression choices must be validated for the intended clinical use.
Structured reporting: It supports standardized representation of findings and measurements.
Display conventions: Hanging protocols help define how images are presented for review.

Security is often discussed here, but manufacturers should be careful not to overstate what DICOM itself provides. Encryption, authentication, authorization, and secure deployment depend heavily on implementation choices, surrounding infrastructure, and system configuration, not just the presence of the standard.

The Role of DICOM in Different Medical Devices

DICOM in Imaging Devices

For imaging devices, DICOM is the backbone of image acquisition, storage, export, and review workflows. It helps ensure that a CT, MRI, ultrasound, or X-ray study can be sent to PACS, opened on a workstation, and interpreted without format translation chaos.

That interoperability supports clinical collaboration, but it also introduces attack paths. A networked imaging device that accepts inbound associations, exports studies, or queries archives is not operating in isolation. Manufacturers need to assess those interfaces the same way they assess any other external-facing functionality.

DICOM in Monitoring and Other Clinical Devices

DICOM is not limited to traditional imaging. Some monitoring and specialty devices use DICOM objects to transmit waveforms, measurements, and related patient data to enterprise systems or other compatible platforms.

That can improve visibility and continuity of care, especially when data needs to move across departments or facilities. It also expands the integration footprint. Once devices begin exchanging near-real-time clinical data across interconnected environments, interoperability and cybersecurity stop being separate conversations. They are the same design problem.

Benefits of Using DICOM in Medical Devices

Better Clinical Access to Data

DICOM makes it easier for clinicians to access studies across systems and compare imaging over time. That supports diagnosis, treatment planning, and follow-up, especially when multiple modalities or specialists are involved.

Smoother Operations and Integration

DICOM-compatible devices can integrate with Picture Archiving and Communication Systems (PACS), EHR systems, and departmental platforms with less manual handling. That reduces duplicate entry, cuts avoidable workflow errors, and makes imaging operations more scalable.

Interoperability also improves care continuity. When data can move cleanly between facilities and systems, clinicians spend less time chasing images and more time using them.

Better Support for Security and Privacy Controls

DICOM-based workflows can support strong security and privacy controls, but only when the implementation is engineered correctly. Transport encryption, access control, auditability, data minimization, and secure configuration all matter. So does lifecycle maintenance.

For device manufacturers, this is where checklist thinking causes problems. Saying a device “supports DICOM” or “uses encryption” is not enough for the FDA, hospital security teams, or procurement reviewers. You need to show how the implementation protects confidentiality, integrity, and availability in the real deployment context.

Challenges and Solutions in Implementing DICOM

DICOM implementation gets messy fast. Different vendors interpret optional elements differently. Legacy systems linger. Hospitals run mixed environments. And devices often need to interoperate with systems the manufacturer does not control.

Common DICOM Integration Problems

A few problems show up repeatedly:

Version and implementation differences: Two products may both claim DICOM support and still fail to interoperate cleanly.
Data mapping issues: Patient, study, and workflow fields do not always align across systems.
Legacy dependencies: Older archives, modalities, and viewers may support outdated behaviors that still need accommodation.
Scale and storage burdens: Imaging datasets are large, and retrieval performance matters in clinical environments.
Security gaps: Unencrypted transport, weak trust configuration, exposed services, and poor segmentation can turn interoperability into exposure.

How Manufacturers and Healthcare Organizations Can Address Them

The fix is not “buy a library and hope for the best.” It takes engineering discipline.

Use proven DICOM toolkits where appropriate, but validate behavior across the systems your customers actually use. Test normal workflows and failure conditions. Verify data integrity, authentication, encryption, error handling, logging, and timeout behavior. Document the security assumptions your device makes about the environment.

Manufacturers should also align DICOM design decisions with FDA expectations for secure product development. If a DICOM service is network-accessible, it belongs in your threat model. If it affects essential clinical performance, it belongs in your safety analysis. If it depends on configuration by the customer, that configuration needs clear, defensible guidance.

The Future of DICOM in Medical Devices

See also: How SPDF Maps to IEC 81001-5-1 Activities, IEC 81001-5-1 vs IEC 62304 for Medical Devices, and JSP2 vs SPDF vs IEC 81001-5-1: Framework Pick.

DICOM continues to adapt as healthcare infrastructure changes. Cloud-hosted workflows, remote collaboration, enterprise imaging, and connected device ecosystems all increase pressure for data to move cleanly across environments.

Emerging Trends in DICOM Technology

One notable shift is the growing use of web-based services and APIs alongside traditional DICOM networking. As cloud adoption increases and the Internet of Things (IoT) expands into healthcare, manufacturers will need architectures that support secure exchange across hybrid environments, not just inside a hospital network.

That raises the bar. Connectivity is useful, but every new interface adds trust decisions, authentication requirements, and monitoring needs.

The Impact of AI and Machine Learning on DICOM

AI and machine learning systems depend on well-structured, well-labeled data. DICOM provides much of that foundation by pairing images with metadata, measurements, and workflow context. That makes it useful for training, inference, triage, image analysis, and decision support applications.

But AI adds its own risks. Data provenance, model drift, preprocessing consistency, and integration security all matter. If your device uses DICOM to feed an AI feature-or receives AI-generated results through a DICOM-based workflow; you need to validate more than connectivity. You need to validate clinical and cybersecurity behavior together.

DICOM security options compared

Mechanism	What it protects	What it does not do	When to use it
AE title checking	Rejects associations from unexpected peers	Nothing an attacker cannot spoof on its own	Always, as a baseline, never as the only control
TLS on the DICOM association	Confidentiality and integrity in transit	Authorization of what the peer may request	Any link that crosses a segment or leaves the facility
User identity negotiation	Ties an operation to a user or system identity	Protection of data at rest	Where audit trails have to name a person
De-identification profiles	Removes identifiers before secondary use	Protection of the original study	Research exports, vendor support copies, test data sets
Storage encryption on the PACS	Data at rest on disks and backups	Anything once the application is running	Always, and state the key management in the submission

DICOM gives you the option of each of these. None of them is on by default, and that gap is what a reviewer looks for.

Conclusion

DICOM is the standard that makes modern medical imaging ecosystems work. It enables interoperability, supports clinical workflows, and creates the structure that downstream systems depend on. It also introduces meaningful security, integration, and compliance challenges that manufacturers cannot afford to treat as box-checking exercises.

If your device uses DICOM, you need to understand the protocol, the workflow, and the threat model. That is how you build something hospitals can trust, and something the FDA will not view as an afterthought.

As DICOM-connected products grow more integrated with enterprise systems, cloud platforms, and AI-driven workflows, the cybersecurity burden grows with them. Blue Goat Cyber helps medical device manufacturers assess those risks, test real-world exposures, and build evidence that stands up to customers and the FDA. Contact us today for cybersecurity help.

Hacking DICOM Images

Security researchers may not be as familiar with DICOM as with other protocols due to the narrow use cases and lack of application in day-to-day life outside of the medical field. This is a double-edged sword, as it means that hackers will typically understand it poorly, but it also means the same for defenders. The DICOM format rarely changes due to the massive overhaul that would be needed in hospitals around the world.

By nature of being used for medical imaging, DICOM files store extremely sensitive data. Regulations such as HIPAA have strict guidelines for how medical data is processed. With more well-understood formats, such as PDF or DOCX files, these guidelines may be more straightforward. This is just since far more people are comfortable with these files. DICOM files may be handled improperly far more frequently.

There are many different tools available for processing DICOM files to perform some sort of analysis. This analysis is often done on the image itself to identify potentially dangerous results, such as imaging to detect cancer. When processing like this is done, a commonly forgotten step is anonymizing data. This prevents files from being compromised and patient data from being leaked to the attackers.

A vulnerability specific to the DICOM format is preamble attacking. The DICOM preamble is a section of the file that facilitates transfers to other file formats. This is intended for transfer to other image formats, but it is possible to run executable files through DICOM images. An extremely dangerous part about this is the fact that antivirus is often told to avoid DICOM files due to the risk of PHI getting deleted. This means that attackers can often supply malware through DICOM files without getting detected.

Hacking DICOM Servers

DICOM servers are prone to many vulnerabilities and misconfigurations. Similar to many other file-share systems, data mishandling is pervasive. DICOM servers need to be well-hardened against attacks to prevent regulatory breaches. Aside from compliance problems, compromise of DICOM files can result in customer distrust. This can be damaging to the image and identity of the company.

In many cases, DICOM servers operate in a similar way to traditional web servers. This means that they are commonly associated with the same vulnerabilities that web servers are associated with. CVEs are regularly assigned to various DICOM servers as vulnerabilities are discovered. Many of these can be extremely dangerous, such as remote command execution or various buffer overflows. Not only will these vulnerabilities lead to compromise of the DICOM server, but they may lead to lateral movement into the internal network.

Misconfigurations are common in DICOM servers. DICOM servers may be exposed to the internet where attackers can attempt to interact with them. If the specific server has known vulnerabilities, this can lead to easy access to the internal network. There are rarely good reasons to expose these servers. Even if the server is fully patched, certain misconfigurations can lead to dangerous situations.

DICOM servers support queries to pass in or pull out data. This allows for transfer of information within a hospital, but when servers are exposed, it may be possible for hackers to extract data. These servers commonly have no form of authentication or very weak authentication. It is often trivial for hackers to simply query the server and receive sensitive patient data.

Another flaw that may be found in DICOM servers relates to how data is processed. Some servers may be configured to pass data over plaintext. When this is the case, a hacker would just need to be in a position to sniff network traffic and they could intercept DICOM transfers and see patient data in the clear. DICOM servers should always be configured to use TLS when transferring data for maximum security.

Notable DICOM and PACS Vulnerabilities

A handful of CVEs illustrate why DICOM and PACS deployments deserve sustained scrutiny rather than a one-time pen test:

CVE-2019-11687 (DICOM file preamble) - the 128-byte preamble defined by the DICOM Part 10 file format can hold an executable header, so a file can be a valid image and runnable malware at once (CISA ICS-ALERT-19-162-01).
CVE-2025-0896 (Orthanc) - Orthanc server before 1.5.8 did not turn on authentication by default when remote access was enabled, CVSS v3.1 9.8 (CISA ICSMA-25-037-02).
CVE-2021-41687 through CVE-2021-41690 (DCMTK) - memory leaks in DCMTK 3.6.6 and earlier that an unauthenticated sender could use to exhaust memory and deny service (NVD).
CVE-2026-50003 and four related flaws (DCMTK) - path traversal, memory exhaustion, and type confusion in DCMTK 3.7.0 and earlier, CVSS v3.1 up to 9.8 (CISA ICSMA-26-181-01).

The pattern is consistent: parser bugs in long-lived C/C++ toolkits (DCMTK, GDCM, dcm4che) plus default-open network services. To find these bugs in your own device first, see DICOM fuzzing for medical devices. Both vectors land squarely inside the FDA's expectations for SBOM disclosure and postmarket vulnerability management.

Securing DICOM - Practical Checklist

DICOM files should be monitored for malicious preambles. The preamble will be the first bytes of the file with the first four dictating what the file is meant to be transformed to. Seeing anything besides known imaging formats should immediately set off alarms that something is off. DICOM files should also be scanned by antivirus software. To prevent patient data from being deleted, questionable files should be flagged and quarantined.

Any DICOM servers should be confined to the internal network. There will rarely be situations where it is a good idea to leak them to the open internet. Even internal servers should be fully kept up to date and transfer data over encrypted communication channels. This prevents further compromise if an attacker gets into the internal network through other means. DICOM servers should also be configured to use appropriate authentication.

Concretely, for a device or PACS deployment that needs to hold up under FDA review and a hospital security questionnaire:

Enforce the DICOM TLS profile (or wrap C-STORE in mTLS via a gateway) - never run plaintext DIMSE over routable networks.
Require AE Title plus user-level authentication; disable anonymous queries on C-FIND / C-MOVE.
Segment imaging modalities and PACS onto a dedicated VLAN with allow-list firewall rules between modality, PACS, viewer, and any AI inference service.
Patch DCMTK / GDCM / dcm4che / Orthanc on the same cadence as your OS - track them in your SBOM and publish a VEX entry for any CVE you are not patching.
Scan inbound DICOM with malware tooling that inspects the preamble; alert on any preamble that is not a known imaging signature.
Log every association, query, and retrieve to a SIEM; PHI exfiltration via C-MOVE is otherwise invisible.
Fuzz your own DICOM parser (or your vendor's) - most exploitable bugs in this space are reachable from a single malformed dataset.

Check out our medical device cybersecurity FDA compliance package or our medical device penetration testing service if you need an external team to validate the DICOM attack surface on your device or PACS deployment.

How Blue Goat approaches this

Blue Goat Cyber assists medical device manufacturers in understanding and mitigating the cybersecurity risks associated with DICOM implementation. Our methodology includes detailed threat modeling specific to DICOM workflows, vulnerability assessments of DICOM-enabled devices, and secure configuration guidance. We help our clients identify potential attack vectors in data transmission and storage, ensuring adherence to regulatory requirements and industry best practices. Our team, comprised of CISSP-certified professionals, OSCP-holders, and ex-military red team experts, possesses a deep understanding of medical device security challenges.

We provide actionable recommendations to harden DICOM interfaces and integrate security controls into the device's architecture. Our services extend to assisting with premarket submissions, ensuring that cybersecurity documentation for DICOM is accurate and complete. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our services at Medical Device Penetration Testing.

Related reading: What Is PACS in Medical Devices and Why It Matters.

FAQ

What medical devices use DICOM?

Many medical devices use DICOM, including imaging modalities like X-ray, MRI, CT, and ultrasound systems. It is also used by Picture Archiving and Communication Systems (PACS), Radiology Information Systems (RIS), and some electronic health record (EHR) platforms or specialized clinical devices that exchange images or waveforms.

How does DICOM ensure data privacy?

DICOM itself defines how image data and metadata are structured and exchanged, but it does not inherently guarantee data privacy or security. Implementation choices, such as transport encryption, access controls, secure configurations, and proper network segmentation are necessary to protect patient information exchanged via DICOM.

Does the FDA regulate DICOM-enabled devices?

Yes, the FDA regulates medical devices that use DICOM. Manufacturers must demonstrate that their DICOM implementation supports safety and essential clinical performance, addressing cybersecurity risks as outlined in the February 3, 2026 final guidance on premarket cybersecurity for medical devices. This includes validating data integrity, interoperability, and secure operation.

What are DICOM's cybersecurity risks?

DICOM's cybersecurity risks stem from open network services, potential for unencrypted data transmission, and vulnerabilities in parsing or handling DICOM objects. Poorly secured DICOM implementations can lead to unauthorized access, data manipulation, or denial of service, impacting patient safety and data privacy if not properly mitigated through secure design and configuration.

Can DICOM be used with AI applications?

Yes, DICOM is foundational for AI and machine learning in healthcare because it provides structured image data and rich metadata. This standardized data is essential for training AI models, performing inference, and supporting AI-driven diagnostic or analytical tools. Secure integration and validation of AI workflows are essential.

What is a DICOM Conformance Statement?

A DICOM Conformance Statement is a document provided by a medical device manufacturer that details how its product implements the DICOM standard. It specifies the DICOM service classes, information objects, transfer syntaxes, and other capabilities supported by the device, helping users understand its interoperability with other DICOM-compliant systems.

YouTube