Safeguarding the Future of Radiology

What does safeguarding the future of radiology mean?

Safeguarding the future of radiology means protecting imaging systems, from scanners and PACS to viewers, AI tools and teleradiology links, against attacks that could expose studies or stop scanning. It combines hospital controls such as segmentation and access management with device makers' duties under FDA section 524B.

Radiology is an attractive target for the same reason it is hard to defend: it is highly connected. Studies move from modality to PACS, to reading stations at home, to outside readers, to AI services and to patients, and each hop is a place where data can leak or where malware can spread.

The consequences are operational as well as legal. A department that loses its PACS or has to isolate its scanners diverts patients, delays reads and falls behind for days after systems return.

Why are radiology departments so exposed?

Radiology departments are exposed because their equipment has long service lives, runs vendor-controlled software that the hospital cannot patch freely, and relies on network protocols that were designed for trusted networks. Remote vendor access and remote reading add more paths in.

• Long-lived modalities: Scanners stay in service for many years, often on operating system versions their vendors no longer update.
• Locked platforms: Hospitals usually cannot install their own endpoint agents or patches on a modality without voiding validation.
• Legacy DICOM: Many devices still send and receive studies without encryption, identifying peers only by application entity title, IP address and port.
• Vendor remote access: Service engineers connect from outside, sometimes through always-on tunnels the hospital does not monitor.
• Home and outside reading: Radiologists read from home and teleradiology groups read at night, extending the perimeter to their networks.
• New services: Cloud archives and AI vendors receive copies of studies, each with its own access paths and retention.

Which risks sit in PACS and DICOM traffic?

The main risks in PACS and DICOM traffic are exposed listening ports, unencrypted transfers, weak peer identification and overly broad viewer accounts. Each lets an attacker read studies, inject data or move toward other systems.

• Exposed ports: DICOM listeners or web viewers reachable from the internet or from general hospital networks they should not serve.
• Plain-text transfer: Studies sent without TLS between buildings, to outside readers or to vendors.
• Weak peers: A PACS that accepts studies from any device presenting a known application entity title.
• Shared accounts: Generic viewer logins at reading stations, so access cannot be traced to a person.
• Stale integrations: Old routing rules sending copies of studies to systems or vendors no longer in use.
• Unmonitored archives: Long-term archives and backups that hold every study but sit outside security monitoring.

Start with an inventory of every DICOM node, route and destination. Most imaging teams find at least one forgotten destination still receiving copies of studies the first time they do this.

What does FDA section 524B require of device makers?

FDA section 524B requires makers of cyber devices to submit a plan for handling postmarket vulnerabilities, maintain processes that provide reasonable assurance of cybersecurity, make patches available, and provide a software bill of materials. It applies to premarket submissions for devices that meet the statute's cyber device definition.

Under 21 U.S.C. 360n-2, a cyber device is one that includes software validated, installed or authorized by the sponsor, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats. The sponsor must provide updates and patches on a reasonably justified regular cycle for known unacceptable vulnerabilities and, as soon as possible out of cycle, for critical vulnerabilities that could cause uncontrolled risks.

The same section requires a software bill of materials that includes commercial, open-source and off-the-shelf components. For hospitals, this gives a concrete request to put to imaging vendors: ask for the SBOM, the coordinated vulnerability disclosure process and the patch cadence before signing, not after an incident.

For companies building imaging software such as AI triage or reporting tools that are regulated as devices, 524B shapes the engineering process itself. Component tracking, vulnerability monitoring and a tested update path need to exist before the premarket submission, not be added afterward.

How should a hospital handle modality patching?

A hospital should handle modality patching through the device vendor's validated updates, scheduled with clinical operations, and use network controls to protect devices that cannot be patched quickly. Installing unvalidated patches on a scanner can break it or its regulatory status.

• 1. Inventory: Record each modality's make, model, software version, operating system, network location and service contract.
• 2. Vendor intake: Track vendor security bulletins and validated patches for each model, linked to the inventory.
• 3. Risk ranking: Rank devices by exposure and by the severity of their known vulnerabilities, not by age alone.
• 4. Scheduling: Plan patch windows with the imaging department so scanners are taken down in rotation, not all at once.
• 5. Compensating controls: Where no patch exists, restrict the device's network access to only the systems it must reach.
• 6. Verification: Confirm the new version is running and the device works end to end, from worklist to PACS, after each update.

End-of-support devices need a written plan. If a scanner will run an unsupported operating system until replacement, document its isolation, monitoring and replacement date, and review that decision every year.

How do you secure DICOM and DICOMweb traffic?

You secure DICOM and DICOMweb traffic by turning on TLS wherever devices support it, authenticating peers with certificates rather than application entity titles alone, and routing everything else through gateways that add protection the device cannot.

The DICOM standard defines how. PS3.15's BCP 195 TLS Secure Transport Connection Profile requires servers and clients to support TLS 1.2, prefers TLS 1.3 when both sides support it, requires encryption with integrity checks, requires servers to support mutual authentication, and recommends the registered port 2762 for DICOM over TLS.

• Conformance statements: Check each product's DICOM conformance statement for the TLS profiles it supports before planning the rollout.
• Certificates: Issue device and system certificates from a managed authority, with expiry tracking.
• Gateways: Place a DICOM gateway in front of devices without TLS, so traffic leaving the imaging network is encrypted.
• DICOMweb: Serve web access over HTTPS with token-based user authentication, separate from DIMSE ports.

What does a defensible imaging security architecture look like?

A defensible imaging security architecture separates modalities, PACS and viewers into their own network zones, allows only the flows each device needs, and routes outside access through monitored, authenticated gateways. Logging ties every study access to a person or system.

• Modality zone: Scanners talk only to the worklist broker, PACS and approved destinations.
• Core imaging zone: PACS, archive and routing engines, reachable from reading stations and integration engines only.
• Vendor access: Time-limited sessions through a monitored jump host, approved per visit, never permanent tunnels.
• Outside readers: Access through a viewer or gateway with named accounts and multi-factor authentication.
• Cloud and AI: Outbound connections from a gateway that de-identifies where possible and logs every transfer.
• Monitoring: Network and audit logs from imaging systems sent to the security operations team, with alerts for new DICOM peers.

What should imaging software teams build in from the start?

Imaging software teams should build component tracking, secure transport, named-user authentication, audit logging and a signed update mechanism into the first release. These are far cheaper to design in than to retrofit once hospitals have deployed the product and FDA reviewers are asking for evidence.

• Component tracking: Generate the SBOM in the build pipeline so it matches every release, not a spreadsheet updated by hand.
• Vulnerability monitoring: Match SBOM components against public vulnerability feeds and triage findings in the issue tracker.
• Secure defaults: Ship with TLS on, default passwords disabled and unused services off, so a rushed installation is still safe.
• Signed updates: Sign every update package and verify it on the device before installing.
• Audit trail: Record who viewed, exported or deleted each study, in a form hospitals can send to their own monitoring tools.
• Threat model: Keep a threat model for each release that covers the hospital network, remote service access and any cloud components.

Hospitals increasingly ask for this evidence in procurement. A vendor that can hand over an SBOM, a disclosure policy and a sample audit log during evaluation shortens the security review and stands out against vendors that cannot.

Where radiology security programs fall short

• Inventory gaps: Devices on the network that no one in IT knows about.
• Contract gaps: Purchase contracts with no terms on SBOMs, patch timelines or end-of-support notice.
• Flat networks: Modalities on the same network segment as general workstations.
• Permanent vendor tunnels: Remote access that is always on and rarely reviewed.
• Recovery not tested: Backups of PACS that have never been restored under time pressure.

Recovery deserves a drill. Practice reading from a downtime viewer and restoring recent studies to a clean PACS, so the department knows how long it can operate during an outage.

How Agnotic can help

Radiology security sits between hospitals and device makers, and both need engineering help. Agnotic Technologies builds medical device cybersecurity programs for imaging software makers, including SBOM generation, vulnerability monitoring and secure update paths for 524B submissions, and builds hardened DICOM gateways, routing and audit tooling for health systems.

For imaging AI and viewer vendors, Agnotic designs TLS-capable DICOM and DICOMweb services, certificate handling and de-identification pipelines so studies can move to the cloud without widening the attack surface.

Sources

• 21 U.S.C. 360n-2: Ensuring cybersecurity of devices (FD&C Act section 524B)
• DICOM PS3.15 B.12: BCP 195 TLS Secure Transport Connection Profile