PACS in Medical Devices: What It Is and How to Secure It

Reviewed September 17, 2026

A hospital can lose access to every prior study in its archive without a single imaging machine being touched. That is what makes PACS worth understanding as a device rather than as IT plumbing. It sits between the modalities that create images and the clinicians who read them, it holds years of patient studies, and it speaks a protocol that was designed for a trusted network in an era when hospital networks were assumed to be closed.

Manufacturers building imaging systems, viewers, AI triage tools, or cloud archives inherit that history. If your product sends, receives, or stores DICOM, your submission has to explain how the interface behaves when the network is not friendly. This page covers what PACS actually is, where it is exposed, and what regulators expect you to document.

Why PACS Security Matters More Than Most Imaging Components

PACS matters because it concentrates risk. A single modality produces studies for the patients scanned on it; the archive holds the studies for everyone. When the FDA's premarket cybersecurity guidance, issued February 3, 2026, asks manufacturers to consider multi-patient harm in their security architecture views, the archive is the clearest example of what that means in practice.

The exposure is not theoretical. Security researchers scanning for open DICOM services have repeatedly found unauthenticated systems reachable from the public internet, returning studies complete with patient names, dates of birth, and identifiers. Reporting on these scans, including work published by ProPublica in 2019 based on research by Greenbone Networks, documented millions of exposed images across multiple countries. The underlying cause is consistent: a protocol that permits open association requests, deployed on a network that was assumed to be private.

For a manufacturer, the regulatory consequence is straightforward. Section 524B of the FD&C Act applies to cyber devices, and a PACS product that connects to the internet and contains software falls squarely inside that definition. The archive is also a place where the availability half of security maps directly to clinical impact: when priors cannot be retrieved, diagnosis is delayed, and delayed diagnosis is patient harm under ISO 14971, not merely an IT outage.

What PACS Actually Does in a Clinical Workflow

PACS performs four functions: acquisition, archiving, retrieval, and distribution. A modality completes a study and pushes it to the archive. The archive stores it, indexes it against the patient record, and serves it back when a radiologist opens a worklist. That worklist usually arrives from a separate system, the RIS, and the order that created it usually originated in the EHR.

Understanding those boundaries matters because each one is an interface you must document.

[KEY REQUIREMENT] Every one of those arrows is an interface in your security architecture views. A submission that draws PACS as a single box labeled "archive" has not described its attack surface.

Is PACS Regulated as a Medical Device?

Yes. In the United States, a PACS is generally classified under 21 CFR 892.2050 as a medical image management and processing system, a Class II device that typically reaches market through the 510(k) pathway. That classification is why PACS vendors submit to the FDA at all, and why the cybersecurity documentation expectations in the February 3, 2026 premarket guidance apply to them.

The classification has practical consequences beyond paperwork. It means the software is subject to the Quality Management System Regulation, it means changes may require a new submission depending on their significance, and it means postmarket obligations under Section 524B, including vulnerability disclosure and the ability to deploy updates, apply to the archive just as they do to the scanner.

Cloud-hosted archives do not escape this. Hosting changes where the risk lives, not whether the product is a device. A cloud PACS adds tenancy isolation, key management, and provider shared-responsibility questions on top of everything an on-premises archive already had to answer.

Where DICOM Leaves the Door Open

DICOM is not an insecure protocol; it is a permissive one. The standard defines security mechanisms, including TLS transport and user identity negotiation, but it does not force a product to use them, and interoperability pressure has historically pushed vendors toward the most permissive configuration that works with the most equipment.

The practical failure modes follow from that.

The last row is the one most often skipped. Backward compatibility is a business requirement, not a security exemption, and a submission reads better when it says plainly that a legacy path was kept, why, and what compensating control surrounds it.

What the FDA Expects in a PACS Submission

The expectations are the same as for any cyber device, but the emphasis shifts toward data handling and multi-patient impact. Your threat model should show what an attacker gains from reaching the archive rather than a single endpoint, and your architecture views should show the archive's position relative to every system that reads from or writes to it.

See also: CVSS Scoring for Medical Devices: A Complete Walkthrough, Healthcare Cybersecurity Companies: A Buyer's Selection Guide, and Medical Device Software Development: A Compliance Guide.

Practically, a reviewer is looking for these elements to be present and consistent with each other:

Testing scope is where products most often come up short. A web-based viewer gets tested because it looks like a web application, while the DICOM listener, which is the interface an attacker on the network would actually reach first, goes untested. If your evidence package covers only the browser-facing component, expect a question about it.

How Interoperability Changes the Risk Picture

Modern imaging environments rarely stop at one vendor. A hospital may run an archive from one supplier, viewers from another, an AI triage tool from a third, and a vendor-neutral archive underneath all of it. Each integration adds a party that can read studies, and each one is a place where your product's security assumptions meet someone else's defaults.

Two principles keep this manageable. First, state your assumptions rather than relying on them silently. If your archive assumes the network segment it sits on is controlled, say so in the labeling and in the threat model, because an unstated assumption is an unverifiable one. Second, treat every third-party integration as an authenticated relationship with defined scope, not as a trusted peer with full access. An AI tool that needs to read chest CTs does not need the ability to delete studies.

Interoperability also affects your postmarket posture. When a vulnerability appears in a shared imaging library, your customers will ask whether your product is affected, and they will ask quickly. The SBOM you produced for the submission is what lets you answer in hours rather than weeks.

How Blue Goat Cyber Approaches This

We test PACS and imaging products the way an attacker on a hospital network would reach them: at the DICOM listener, at the web services, and at the trust relationships between the archive and everything connected to it. That means association handling, query behavior, authentication paths, transport protection, and the interfaces your viewer exposes, with findings written in terms a reviewer can map to your threat model.

If you are preparing an imaging submission, our medical device penetration testing work produces the testing evidence that supports it, and our threat modeling engagements make sure the archive appears in your architecture views as the multi-patient asset it is.

Frequently Asked Questions

Is PACS considered a medical device by the FDA?

Yes. PACS is generally regulated under 21 CFR 892.2050 as a medical image management and processing system, typically Class II, reaching market through the 510(k) pathway. Because it contains software and connects to networks, a PACS product also falls within the definition of a cyber device under Section 524B, which brings premarket cybersecurity documentation and postmarket update obligations with it.

What is the difference between PACS, RIS, and DICOM?

PACS stores and distributes images. RIS, the radiology information system, manages orders, scheduling, and reporting workflow. DICOM is the standard that defines both the image file format and the network protocol they use to exchange studies. They are commonly discussed together because a working imaging department needs all three, but they are distinct systems with distinct interfaces to secure.

Can DICOM traffic be encrypted?

Yes. The DICOM standard supports TLS for transport security, and DICOMweb services run over HTTPS. The obstacle is rarely technical capability and usually deployment practice, because encryption has historically been optional and disabling it removes interoperability friction with older equipment. A submission should state whether encryption is on by default and what happens when a peer does not support it.

Why do exposed PACS systems keep appearing on the internet?

Because DICOM services can accept connections without authentication, and because archives are sometimes placed on networks with more reachability than their owners realize. Research scans have repeatedly identified unauthenticated DICOM endpoints returning studies with patient identifiers. The fix is a combination of network placement, mandatory authentication, and configurations that do not accept associations from unknown peers.

Does a cloud-hosted archive reduce a manufacturer's responsibility?

No. Hosting shifts some controls to the cloud provider but leaves the manufacturer responsible for tenancy isolation, key management, access control, logging, and the security of the application itself. The FDA will expect the shared-responsibility boundary to be described explicitly, including which controls the customer must configure and which are yours.

What testing should a PACS product undergo before submission?

At minimum, penetration testing that exercises the DICOM interface directly, testing of any web viewer or API, authentication and authorization testing across user roles, and verification that the security requirements you wrote were actually implemented. Testing that covers only the browser-facing portion leaves the interface most reachable from the hospital network unexamined.

Get Your Imaging Product Reviewed Before the FDA Does

If your product stores, moves, or displays DICOM studies, the archive interface belongs in your threat model and your testing scope. We can tell you what a reviewer will ask and what an attacker would find. Book a strategy session and bring your architecture diagram.

---

Blue Goat Cyber specializes in medical device cybersecurity, from threat modeling and penetration testing through premarket submission support. Our team works exclusively with device manufacturers preparing FDA submissions. Learn more about Christian Espinosa, our founder and CEO.