Question 1

Is my device a cyber device under Section 524B?

Accepted Answer

It is if all three conditions hold: the device includes software validated, installed, or authorized by the sponsor; it can connect to the internet; and it has technological characteristics that could be vulnerable to cybersecurity threats. A USB port, a Bluetooth radio, or a cloud dashboard is usually enough to pull a device in. When it applies, the full premarket cybersecurity package applies with it.

Question 2

Do the requirements change between 510(k), De Novo, and PMA?

Accepted Answer

The evidence set does not change; the review mechanics do. Every cyber device needs a cybersecurity plan, a threat model, a machine-readable SBOM, security architecture views, verification evidence, labeling, and a postmarket plan. De Novo adds special controls your postmarket program has to satisfy, and PMA adds supplement decisions for security-relevant changes after approval.

Question 3

Does Software as a Medical Device need the same package?

Accepted Answer

Yes, and usually a broader one. SaMD typically spans a cloud back end, APIs, and a companion mobile app, so the threat model and the SBOM have to cover the whole assembly rather than a single binary. Reviewers reject SaMD packages whose architecture views stop at the app boundary and never describe the server side.

Question 4

What about a device already on the market?

Accepted Answer

Section 524B applies to submissions, but postmarket obligations follow the device. You still need vulnerability monitoring against the shipped software, a disclosure channel, a patch path, and published end-of-support dates. For devices whose components can no longer be patched, document compensating controls and communicate the residual risk to customers rather than staying silent.

Question 5

What exactly goes in the cybersecurity section of the submission?

Accepted Answer

A cybersecurity management plan, a system-level threat model, security architecture views, a machine-readable SBOM with supplier and end-of-support metadata, a vulnerability assessment with VEX, security control descriptions traced to verification evidence, penetration and fuzz testing reports with stated scope, cybersecurity labeling, and a postmarket monitoring and patching plan.

Question 6

What makes a threat model acceptable to a reviewer?

Accepted Answer

Completeness and traceability. Decompose the whole system into data flows and trust boundaries, apply a named method such as STRIDE per element, score each threat in patient-harm terms using ANSI/AAMI SW96:2023, and trace every threat to a control, a verification test, and a residual-risk entry in the ISO 14971 file. Incomplete trust-boundary coverage is the most common driver of first-cycle deficiencies.

Question 7

What does an FDA-acceptable SBOM have to contain?

Accepted Answer

Machine-readable CycloneDX or SPDX, covering commercial, open-source, and off-the-shelf components down to transitive dependencies, with supplier, component name, version, unique identifier, dependency relationship, author, timestamp, support level, and end-of-support date. A human-readable spreadsheet submitted in its place is a common Technical Screening failure.

Question 8

Do we need a penetration test, and what scope?

Accepted Answer

Yes for any cyber device. Scope it from the threat model rather than from convenience: every external interface, wireless radio, physical port, companion app, and cloud service in the trust boundary. Report the methodology, tooling, duration, findings, and disposition. A web application test submitted for a device whose risk sits in firmware will draw a deficiency.

Question 9

When should cybersecurity work start?

Accepted Answer

At concept, before the architecture freezes. The threat model generates security requirements, and security requirements are design inputs. Teams that start after verification typically discover an unsigned update path or an unauthenticated interface they cannot change without reopening design controls and repeating testing.

Question 10

What is AAMI CR515:2025 and does it apply to us?

Accepted Answer

CR515:2025, published June 23, 2025 and added to the FDA Recognized Consensus Standards database in March 2026, is a consensus report on cybersecurity considerations specific to machine learning-enabled medical devices. It supplies the ML threat catalog and asset taxonomy that generic threat modeling misses: training-data poisoning, adversarial evasion, model inversion, membership inference, model extraction, and pipeline compromise. If your device ships a model, it applies as method.

Question 11

Can we declare conformity to CR515?

Accepted Answer

No. A consensus report contains no shall-statements and has no conformity assessment path, so there is nothing to conform to. Cite it as the method your ML threat model follows and show the resulting threats in the security risk file. Claiming conformity invites a reviewer question with no upside.

Question 12

How does Good Machine Learning Practice fit with cybersecurity?

Accepted Answer

GMLP is the lifecycle discipline; cybersecurity is one of the risks it has to control. The GMLP principles on data management, training and test independence, model monitoring, and change control produce exactly the records a reviewer wants when they ask how you prevent poisoning or detect drift. Map your GMLP evidence to the cybersecurity questions rather than filing two unrelated stories.

Question 13

How does a PCCP change the cybersecurity package?

Accepted Answer

It moves work earlier. A Predetermined Change Control Plan authorizes future model updates without a new submission, but only if the premarket package defines the cybersecurity envelope of those updates: the threat model, SBOM scope, and test boundary must cover the modifications the PCCP allows, and each modification needs a security testing gate and a rollback plan. Reviewers reject PCCPs whose cybersecurity package treats the model as static.

Question 14

Is an AIBOM different from an SBOM?

Accepted Answer

It is an extension, not a replacement. The SBOM inventories software components; the AIBOM adds the AI-specific artifacts an attacker cares about: pretrained models, weight files, ML frameworks, training and evaluation datasets, and hosted inference endpoints. Ship them as one linked inventory so a reviewer does not have to reconcile two documents.

Question 15

Do AI/ML devices need different testing?

Accepted Answer

They need conventional testing plus adversarial testing. Keep the application, firmware, and infrastructure testing, then add evasion attacks against the deployed model, robustness checks under distributional shift, artifact integrity tests, and where relevant, model extraction and inversion attempts. Report both in one methodology so reviewers are not reconciling two reports.

Question 16

What triggers most cybersecurity deficiency letters?

Accepted Answer

Five patterns dominate: an SBOM missing supplier, version, or end-of-support fields; a threat model that stops at the device boundary; penetration testing with no stated scope or methodology; security controls that trace to no verification evidence; and a postmarket plan with no vulnerability intake path. All five are visible before you file if someone checks.

Question 17

How should we respond to a cybersecurity deficiency?

Accepted Answer

Answer in the reviewer's own structure, one deficiency at a time, with the evidence attached rather than promised. Where you disagree, supply the technical justification and the data behind it. Arguing without new evidence is the reliable way to spend another review cycle on the same question.

Question 18

Can cybersecurity cause a Refuse To Accept?

Accepted Answer

Yes. Technical Screening checks whether the Section 524B elements are present at all. A missing SBOM, an absent postmarket plan, or an SBOM that is not machine-readable can stop the submission before substantive review begins, which costs weeks before a reviewer has read a single technical argument.

Question 19

What does postmarket cybersecurity monitoring actually require?

Accepted Answer

Map every SBOM component to CVE feeds and the CISA KEV catalog, triage each hit against the device's intended use, publish a VEX statement for the ones that are not exploitable, and record the ones that are as risk file entries with a remediation timeline. Monitoring without triage produces an unbounded CVE list nobody can action.

Question 20

How often do we have to patch?

Accepted Answer

Section 524B(b)(2) requires updates and patches on a regular cycle, plus out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risk. Publish the cadence so hospitals can plan, and pre-scope a regression suite for security releases so an urgent fix does not trigger a full verification cycle.

Question 21

Do we need a coordinated vulnerability disclosure process?

Accepted Answer

Yes, and it has to be staffed. Publish an intake address or portal, state your acknowledgment and response timelines, and define how findings enter CAPA and the risk file. A disclosure policy that routes to an unmonitored inbox is worse than none, because it creates a documented failure to respond.

Question 22

What happens if we get postmarket cybersecurity wrong?

Accepted Answer

Enforcement escalates predictably: an inspection observation on Form 483, then a Warning Letter, then import alerts, seizure, injunction, or a consent decree. In parallel, hospital procurement pauses purchases and future submissions attract closer scrutiny. The regulatory penalty is rarely the largest cost.

FDA medical device cybersecurity, answered.

Scope and applicability

Premarket evidence

AI/ML devices, CR515, GMLP, and PCCPs

Review, deficiencies, and holds

Postmarket obligations

Keep going

Get FDA cleared without the cybersecurity headaches.