An imaging archive holds years of patient studies in one place, which is exactly what makes it worth attacking and exactly what makes it hard to lock down. DICOM, the protocol every study on that archive speaks, was written for a network where every device belonged to one hospital and nobody planned for the internet to reach it. Building a medical imaging secured archive server means building against that history: most of DICOM’s network services will accept a connection from anything that asks, with no authentication required, unless someone turns security on. The real work of securing an archive happens in the layers wrapped around the protocol, not inside it, and a lot of real deployments still run without them.
What DICOM Gives You, and What It Leaves to You
The standard is explicit about where its own responsibility ends. DICOM’s security specification states plainly: “The DICOM Standard does not address issues of security policies, though clearly adherence to appropriate security policies is necessary for any level of security.” That line draws the boundary an architect has to design around: DICOM will move the study, and the decision about who may ask for it lives outside the protocol. The standard “assumes that the Application Entities involved in a DICOM interchange are implementing appropriate security policies”, a premise it states rather than a condition it verifies.
Responsibility for that assumption lands on each system individually: “each Application Entity must insure that their own local environment is secure before even attempting secure communications with other Application Entities”. The mechanisms the standard does supply are all optional, and a system “can optionally utilize any of these mechanisms, depending on the level of trust they place in the communications channel”. Nothing in the protocol requires that trust to be earned cryptographically: two systems negotiating an association are only “agreeing to some level of trust in the other Application Entities”. An archive that never turns on the optional mechanisms is still, technically, speaking valid DICOM.
TLS on the Wire: What the Standard Specifies, and Where It Actually Gets Turned On
The current TLS profile for DICOM requires servers and clients to support TLS 1.2 at minimum, with 1.3 preferred where both sides support it. It also requires that a connection drop rather than fall back to an unencrypted or downgraded channel. Mutual authentication, where the archive verifies the calling system’s certificate and not just the other way around, is treated as the stronger option rather than the floor.
The profile puts it this way: “Servers shall support bi-directional mutual authentication. Clients are not required, but are encouraged, to support and use bi-directional mutual authentication. The server may be configured to not use bi-directional mutual authentication.”
A production archive can be fully conformant to the profile and still be running one-way authentication, or none. Whether TLS gets switched on at all is a separate question, and the standard’s security page is candid about the answer: “DICOM merely facilitates the use of encryption but does not mandate it.” The page continues: “Whether to employ encryption is a policy choice of the health facility and an implementation choice of the product vendor.” So the decision sits with two parties, and an archive vendor only controls one of them.
The same page notes that health facilities routinely choose a different path entirely: an encrypted VPN between sites, with the DICOM traffic itself left unencrypted inside that tunnel. That arrangement is “quite common between sites, but may, from a cybersecurity point of view, not be advisable.” TLS on a DICOM association is not automatic. It is a switch somebody has to find and flip, on both ends of the connection, before it does anything.
AE Titles Are an Identifier, Not a Password
Every DICOM association carries a calling and a called Application Entity title, the short strings that say which system is initiating a connection and which one is meant to receive it. A lot of real deployments lean on that title as their access control: an archive checks the calling AE title against a list of known, accepted systems and rejects anything not on it. That is a genuinely useful filter, and it stops opportunistic and misconfigured connections cold.
An AE title check is not authentication in any cryptographic sense, because the title is a self-declared string sent as part of the negotiation, not a secret only the real system could produce. Anything that speaks the association protocol correctly can claim whatever AE title it wants, and without TLS binding the connection to a certificate, the archive has no independent way to know the claim is true.
Even DICOM’s optional identity mechanisms can be thinner than they look. The Basic User Identity Association Profile accepts a username at association time, and accepts a username with a passcode as well, yet a conformant implementation “need not verify the passcode”. A separate profile, User Identity Plus Passcode, is the one that requires the passcode to be authenticated and the association rejected if authentication fails. AE title allow-listing and an unverified user identity both narrow who can connect, and neither one, on its own, proves who actually did.
Network Segmentation: Keeping the Archive Off the Flat Network
Because DICOM-layer identification can be this thin, where the archive sits on the network matters as much as what runs on it. NIST’s cybersecurity practice guide for picture archiving and communication systems built its reference architecture around exactly this gap. The guide calls for “network zoning that allows more granular control of network traffic flows and limits communications capabilities to the minimum necessary to support business function”.
The guide warns that PACS vulnerabilities could “expose an HDO to risks of significant data loss, malware and ransomware attacks, and unauthorized access to other parts of an HDO enterprise network.” An archive, a set of modalities, and the systems that route between them belong on their own segment, reachable only by what actually needs to reach them. Without that boundary, a weak or misconfigured AE title check can be the only thing standing between the studies and anyone else on the flat network.
The Audit Trail Requirement, and What ATNA Adds
HIPAA’s technical safeguards require audit controls outright. The audit controls standard reads in full: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”
DICOM’s audit specification gives that requirement a concrete shape for imaging systems, defining “the format of the data to be collected”. The records it defines cover “who accessed healthcare data, when, for what action, from where, and which patients’ records were involved”, which is what makes a log reviewable after the fact.
IHE’s Audit Trail and Node Authentication profile, ATNA, is what operationalizes that across a full imaging environment rather than one system at a time. IHE frames it broadly: “The Audit Trail and Node Authentication (ATNA) Profile specifies the foundational elements needed by all forms of secure systems: node authentication, user authentication, event logging (audit), and telecommunications encryption.” Many other IHE profiles require or recommend grouping with ATNA actors, so it rarely stands alone in a real deployment.
It is worth being precise about what ATNA does not guarantee on its own. The profile “permits the negotiation of no encryption to accommodate sites that prefer to use a different form of protection.” IHE is blunter still: “Compliance with the ATNA Profile alone, without also performing the other cybersecurity activities, is not sufficient to provide adequate cybersecurity.” An audit trail proves useful only if the logging actually runs and somebody actually reviews it.
Access Control for Service Accounts and Integrations
HIPAA’s person or entity authentication standard requires procedures “to verify that a person or entity seeking access to electronic protected health information is the one claimed”. A separate implementation specification, this one required rather than addressable, reads: “Assign a unique name and/or number for identifying and tracking user identity”. The Security Rule defines a user as “a person or entity with authorized access”, and the access control standard reaches “those persons or software programs that have been granted access rights”.
The language reads as though it were written for people logging into a viewer, but nothing in it stops at people. A service account that pulls studies for a viewer integration, or forwards them to a reporting system, is an entity with authorized access. It needs its own identity, not a shared credential borrowed from whichever engineer set the connection up first.
The stronger version of this is the same distinction NIST’s PACS guidance draws between authenticating people and authenticating machines: “multifactor authentication for care providers, certificate-based authentication for imaging devices and clinical systems”. A password embedded in a router’s configuration file, reused across every integration that needs it, fails the same way a shared login does. A certificate scoped to one integration, carrying only the operations that integration actually needs, can be revoked on its own without disrupting every other connection the archive maintains.
Encryption at Rest, and Where DICOM’s Own Coverage Stops
DICOM’s media security profile covers encrypting a DICOM file for exchange or removable storage, wrapping it so that confidentiality and integrity travel with the file itself. That is a different question from how an archive’s own disks or database are protected while a study sits there, unread, for years. The standard has nothing to say about that layer at all. It is infrastructure, not protocol, and it falls to whatever storage platform the archive is actually built on.
HIPAA addresses encryption at rest as an addressable, not automatically required, specification: “Implement a mechanism to encrypt and decrypt electronic protected health information.” Addressable does not mean optional. Under 45 CFR 164.306(d)(3), a covered entity has to assess the specification and implement it where that is reasonable and appropriate. Where it is not, the entity has to document why and put an equivalent alternative measure in place if that measure is reasonable and appropriate.
Full-disk or database-level encryption at the archive closes a gap that TLS and DICOM’s media profile were never built to reach. That gap is a stolen drive, a misplaced backup, or a storage volume copied outside the controls that were supposed to govern access to the studies.
What to Log So an Incident Is Reconstructable
Put the pieces above together and the practical checklist for an archive’s audit log follows directly. Every store, query, retrieve, and worklist operation should tie back to an AE title and, where a user identity is available, to a person. Failed association attempts belong in the log alongside successful ones, not as an afterthought to clean up later.
A pattern of rejected connections from an unfamiliar AE title is often the earliest signal that something is testing the perimeter. Export and disclosure events need their own distinct record, separate from routine internal access. That is the fact pattern a breach investigation has to answer: not just that a study moved, but who moved it, where it went, and whether that was ever authorized.
What This Means for Securing Your Archive Server
None of the layers above are exotic once named: TLS turned on and verifying the caller, AE title checks backed by more than a self-declared string, and a network segment not shared with everything else. The other three are a unique identity for every service account, an audit log that captures who and not just what, and encryption at rest that closes the gap DICOM’s media profile leaves open.
What EBM mAIn PACS® provides underneath all of it is a documented services list: native DICOM C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment. A partner evaluating the archive layer is evaluating against a stated surface rather than an adjective, on a platform designed to support HIPAA compliance. EPS Pi keeps a local backup via USB at the point of care as part of that same platform. Broader disaster recovery planning belongs in this conversation too, as a requirement worth asking any imaging vendor to spell out concretely rather than assume.
For a product or engineering team scoping this layer, the useful question is never whether an archive vendor “supports security.” It is whether TLS is on by default or something a customer has to request, and whether AE title checks are paired with certificate-based authentication or left standing alone. It is how service accounts get provisioned and rotated, and whether the audit log would answer, six months from now, who saw a specific study and why.
A vendor with a specific answer to each of those has built an archive meant to be defended. One with a single reassuring adjective has not.