FDA Product Code QIH: Automated Radiological Image Processing Software Cybersecurity

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.

An altered image or a swapped processing model can produce a plausible result that reaches a clinician without an obvious system failure. For manufacturers of radiological image processing software, cybersecurity therefore includes the integrity of the clinical workflow, not just the confidentiality of patient records. Availability matters too: an unavailable processing service can delay interpretation or force a workflow change during patient care.

Earlier versions of our QIH articles incorrectly treated the product code as an imaging acronym. This consolidated article replaces that framing with the FDA's actual classification and separates the category definition from product-specific regulatory decisions. It explains common deployment patterns, attack surfaces, patient-safety consequences, and the evidence manufacturers should consider. It also distinguishes enforceable statutory duties from guidance recommendations and explains why an AI change plan cannot substitute for secure deployment controls.

Why this matters

The FDA product classification record for QIH identifies Automated Radiological Image Processing Software, Class II, 21 CFR 892.2050, and the Radiology panel. The openFDA classification record supplies the same classification and describes software implementing artificial intelligence, including nonadaptive machine learning trained with clinical or artificial data. It explicitly excludes adaptive AI algorithms. These records were checked on October 18, 2026.

A product code is not a finding that every product shares the same interfaces, intended use, or cybersecurity obligations. Manufacturers must evaluate the actual device and submission. Nor does QIH mean the scanner itself: a software product processing CT images and the CT acquisition system can have different regulatory classifications and security boundaries.

The February 3, 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, addresses devices with cybersecurity considerations. Its recommendations connect secure development, risk management, testing, labeling, and lifecycle support to submission evidence. The revision principally aligns terminology with the Quality Management System Regulation, rather than creating new Section 524B duties. For an imaging software manufacturer, the practical question is whether that evidence explains how attacks could change clinical outputs, interrupt care, or undermine safe recovery in the proposed deployment environment.

What devices and workflows can fall within QIH?

The classification definition describes automated radiological image processing and analysis tools. Illustrative functions include software that segments anatomical structures, produces image-derived measurements, or processes images to support a clinician's assessment. A workstation application, a server-side processing component integrated with a hospital archive, or a cloud-hosted analysis service can each create different security boundaries. These are workflow examples, not determinations that every implementation belongs under QIH.

The intended use, indications, functionality, and labeling determine whether a particular product fits the code. Do not assume that all image analysis software, all radiology AI, or all quantitative imaging devices are QIH products. Classification should be confirmed against the applicable record and the product's submission strategy. A measurement tool also should not be described as an autonomous diagnostic system unless its authorized intended use supports that claim.

Map the clinical sequence before selecting controls: image acquisition, transfer, processing, review, and return of results. Identify who confirms the patient and study, which version of the algorithm runs, and where the output becomes part of the clinical record. A security boundary omitted from that sequence can leave an apparently protected application dependent on an unprotected upstream service.

Where are the DICOM and PACS attack surfaces?

DICOM in medical devices connects imaging objects and workflows, while a PACS stores and distributes studies. QIH software may receive studies through DICOM services, DICOMweb interfaces, file imports, or intermediary gateways. Treat each input path as a trust boundary rather than assuming the hospital network makes all received content trustworthy.

Malformed files can expose parsing defects. Modified metadata can associate an otherwise valid image with the wrong patient, study, orientation, or processing context. Replay of an old study or substitution of derived objects can mislead downstream review. Test how the software handles missing identifiers, duplicate objects, unexpected transfer syntaxes, oversized inputs, and partial transfers. Establish whether failures are visible to users and whether processing can continue safely.

Protect transport where supported, restrict peers and service permissions, and validate objects before using them. Network segmentation helps contain access but does not establish image provenance by itself. Document any reliance on hospital configuration, including certificate management and service accounts. For each control, identify its owner and the behavior when a dependency fails. A secure default matters less if installation instructions routinely require administrators to disable it for interoperability.

How should manufacturers protect AI model integrity?

A model file, preprocessing routine, or configuration threshold can change clinical behavior without changing the visible user interface. Threat modeling should consider unauthorized replacement, tampering with preprocessing, alteration of model selection logic, and compromise of the pipeline that packages an update. A checksum stored beside a model is not sufficient if an attacker can replace both.

Use authenticated release artifacts, controlled access to model repositories, separation of development and production permissions, and traceable approval records. Record the model and processing configuration associated with each result so an investigation can distinguish corrupted input from a changed algorithm. Protect training data provenance and access where those assets are part of the manufacturer's development environment. Our AI training data security discussion explains why that upstream boundary matters.

Security testing can assess whether unauthorized changes are blocked and detected. It does not establish clinical performance across patient populations. The manufacturer remains responsible for determining the clinical and regulatory evidence needed for each release. Monitoring should distinguish unauthorized manipulation from performance drift, ordinary data variation, and approved changes. These problems can overlap, but they require different investigations and should not be collapsed into a single model-accuracy metric.

What changes when processing runs in the cloud or receives updates?

Cloud deployment adds identity providers, tenant boundaries, storage permissions, job queues, APIs, and administrative interfaces to the device architecture. Check whether a user can retrieve another institution's study, alter a processing job, or access results through a predictable identifier. Test authorization at the object and operation level, not only at login. Limit privileged support access and record actions that could affect clinical data or processing behavior.

Define what happens when connectivity, an external identity provider, or the processing service becomes unavailable. Avoid displaying stale results as newly completed work. Recovery procedures should preserve patient association and distinguish incomplete jobs from completed studies. The manufacturer and healthcare organization need a shared understanding of backup, restoration, and incident communication responsibilities.

Updates introduce another trusted path. Authenticate packages, protect signing keys, restrict deployment permissions, and assess rollback behavior. A rollback that restores vulnerable code or mismatches a model with its preprocessing pipeline can create new risk. Maintain a software bill of materials that accounts for relevant third-party components, including those in the deployed cloud architecture. Use it to support vulnerability assessment, not as a substitute for analysis of exploitability and clinical consequences.

How can a cybersecurity failure affect patient safety?

A changed measurement could influence assessment or treatment planning. A swapped patient identifier could attach an analysis to the wrong record. Suppressed output or service disruption could delay review. These are plausible harm pathways to analyze, not claims that a particular QIH device has suffered those incidents. The severity depends on the device's role, the clinical workflow, and available independent checks.

See also: 8 FDA Cybersecurity Documentation Gaps to Review, FDA IDE Cybersecurity Requirements: 2026, and SBOM Diffing and CVE Correlation: A Practical Workflow Supporting Section 524B Duties.

Connect each threat scenario to a sequence of events, a hazardous situation, and potential harm. Consider whether clinicians can recognize the failure, whether the interface communicates uncertainty or missing results, and whether a fallback workflow is practical. A warning buried in an administrator log may not help the clinician making a time-sensitive decision.

Use medical device threat modeling to connect technical paths with clinical risk analysis. Preserve that traceability through control selection and security testing. Document residual risk decisions and deployment assumptions, including who accepts them. Technical severity scores alone do not explain the impact of incorrect processing on a specific clinical workflow, and a low-severity infrastructure finding can still matter when it enables a dangerous sequence of events.

What do Section 524B and the February 2026 guidance expect?

Section 524B of the FD&C Act is a binding statute. Its applicability depends on the cyber-device definition and a covered submission, not on the QIH code alone. Section 524B(a) covers 510(k), De Novo, PMA, PDP, and HDE submissions. IDE submissions are outside that subsection, although they are within the broader scope of the February 2026 guidance.

The statute addresses updates 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. Section 524B(b)(4) authorizes additional requirements through regulation; the guidance itself is not that rulemaking.

The February 3, 2026 guidance contains nonbinding recommendations and is the operative interpretation the FDA applies in submission review. It recommends evidence such as threat modeling, security architecture, cybersecurity risk assessment, security testing, and labeling. Alternative approaches need an adequate rationale and must satisfy applicable law. Describe what evidence supports the device rather than claiming that following a checklist guarantees clearance. The FDA makes the regulatory decision.

When is a PCCP relevant to QIH software?

A predetermined change control plan can be relevant when a manufacturer proposes planned modifications to an AI-enabled device. The FDA's PCCP guidance for AI-enabled device software functions describes the planned modifications, modification protocol, and impact assessment that support review. An authorized PCCP is bounded by its reviewed scope, not permission for arbitrary future changes.

This does not change the QIH classification record's exclusion of adaptive AI algorithms. A controlled manufacturer release under an authorized plan is not the same as assuming continuously learning software fits QIH. Classification, the particular modification, and the authorized plan must be evaluated together with the manufacturer's regulatory team.

Assess cybersecurity effects of model, dependency, input, and infrastructure changes before deployment. Update relevant threat scenarios, SBOM records, and release evidence when the architecture or attack surface changes. A PCCP does not replace secure update mechanisms, vulnerability response, or assessment of whether a modification falls outside the authorized plan and needs another submission. Keep clinical change evidence and cybersecurity change evidence coordinated without treating them as interchangeable.

How Blue Goat approaches this

Blue Goat Cyber starts with the actual architecture and intended clinical workflow, not a generic imaging checklist. We identify image ingress paths, DICOM/PACS connections, user roles, cloud services, model artifacts, and update mechanisms. Threat modeling then connects abuse cases to possible clinical consequences and records the assumptions that depend on hospital deployment or third-party services.

Penetration testing targets those boundaries in an agreed test environment. Work can include malformed image handling, authorization failures, model or package tampering, tenant isolation, and recovery behavior. SBOM review helps identify affected dependencies and focus vulnerability analysis on the deployed configuration. Findings describe reproducible evidence, impact, and remediation priorities so the manufacturer can make risk decisions and maintain submission traceability.

Retests focus on findings with uncontrolled risk. The manufacturer retains responsibility for clinical performance evidence, product acceptance, regulatory strategy, and residual risk decisions. Our work supports cybersecurity evidence; it does not guarantee clearance, eliminate every vulnerability, or replace the manufacturer's quality responsibilities. We distinguish observed test results from assumptions and untested conditions in the final deliverables.

FAQ

CTA

Planning a submission or an update for radiological image processing software? Discuss your device's cybersecurity scope with Blue Goat Cyber. Bring your architecture, intended use, deployment assumptions, and planned software changes so we can identify the threat modeling, penetration testing, and SBOM work relevant to your product.