Cybersecurity Risk Exposure of Radiology Practices and Imaging Centers
Why encryption challenges, legacy technology and large volumes of sensitive data make radiology practices targets.
Read articleCybersecurity for connected medical imaging devices
Imaging systems run in highly connected environments that mix old and new technology from different manufacturers. Medcrypt helps manufacturers secure communication and legacy systems in line with FDA cybersecurity guidelines.
Where medical imaging cybersecurity gets hard
- Legacy products built without encryption
- Multi-vendor data in transit
- Tampered images, wrong diagnoses
- Every site implements differently
Where medical imaging cybersecurity gets hard
Legacy products built without encryption
Many older imaging products were not designed with encryption in mind, because FDA did not enforce stringent security requirements at the time.
Multi-vendor data in transit
Imaging systems often combine old and new devices from various manufacturers. Without standardized, unified solutions, encryption in transit is implemented inconsistently.
Tampered images, wrong diagnoses
Malicious actors could manipulate imaging data, leading to incorrect diagnoses and treatment plans.
Every site implements differently
Communication protocols must be tailored to each healthcare delivery organization's workflows, with radiology, clinical engineering and IT all involved.
Where attackers get in
Hospital network & PACSImages and data moving between systems
WorkstationsOften older operating systems
The modalityThe scanner itself
Service accessRemote and on-site maintenance
How Medcrypt helps
Guardian for deployed systems
Certificate and key management, field provisioning via USB, and modern protocols in place of plaintext or deprecated TLS, without source code changes.
Data securityLegacy device cybersecurity
Risk assessments, SBOM lifecycle data, patch planning and FDA-focused expert support for devices already in the field.
Legacy device servicesThreat modeling
Threat models drafted from your device architecture and checked for submission readiness by former FDA reviewers.
Threat modeling
How an engagement works
- 1
Gap check
Know where your imaging submission stands, starting with a 1‑hour review.
- 2
Build the evidence
Threat model, SBOM, architecture views and testing, sized to your device.
- 3
Reviewer check
Former FDA reviewers go through the package before you file.
- 4
After you file
If FDA sends questions, we typically turn around a full cybersecurity response in about 10 days.
Case study
Securing a Legacy 3D Mapping System for Radiation Oncology
Secured authentication and encrypted communication across all system components, with no source code changes.
Read case studyFurther reading
The Critical Importance of Secure Communication in Medical Imaging
What makes secure communication between imaging devices and systems hard, and steps to start.
Read articleStandards we work to
- FDA premarket cybersecurity guidancewhat reviewers check
- Section 524Bthe law for cyber devices
- ISO 14971safety risk management
- IEC 62304software lifecycle
- IEC 81001-5-1secure development
- AAMI TIR57security risk management
- MDS2the security form hospitals ask for
FAQ
Many older imaging products were not designed with encryption in mind, because FDA did not enforce stringent security requirements at the time. Imaging systems also combine devices from various manufacturers and old and new technologies, which complicates securing data in transit.
In one Medcrypt project, a 3D mapping system used during surgery ran multiple independent codebases that could not be modified due to FDA clearances. Medcrypt deployed Guardian Agent without source code modifications, which preserved FDA approvals and secured authentication and encrypted communication across all system components.
Section 524B applies to cyber devices: devices that include software validated, installed, or authorized by the manufacturer, have the ability to connect to the internet, and could be vulnerable to cybersecurity threats. The test is whether the device is capable of connecting, not only whether its intended use involves connecting.