Compliance & Regulation

Common FDA cybersecurity AI deficiency questions

When an FDA reviewer has a problem with your cybersecurity documentation, you don't get a rejection. You get an AI letter, a request for Additional Information, and your review clock stops while you assemble an answer. To be clear for anyone arriving from a search engine: this has nothing to do with artificial intelligence. AI is the FDA's own shorthand for its deficiency correspondence.

We've supported more than 600 submissions, and the striking thing about AI letters is how little they vary. Reviewers work from templates. The same boilerplate questions appear across device types, submission pathways, and review divisions. Which is actually good news. A known question is a question you can answer before it's asked.

What AI letters keep asking forThreat model gaps524B(b)(2), methodology, full scopeTesting evidencescope, duration, methods, findingsSBOM completenessmachine readable, NTIA, EOL partsUnsupported scoringcontrols and ratings without methodOne root causeclaims don't traceto evidenceOne modelarchitecture, SBOM,findings, tests linked
Four question families, one complaint underneath: the documents don't trace to each other.

Four families cover most letters

Threat modeling comes first, and it arrives with statute attached. The boilerplate cites Section 524B(b)(2) and asks for your methodology and the justification for choosing it (STRIDE, attack trees, kill chain), coverage of every end-to-end system element including update infrastructure and cloud services, and diagrams showing where mitigations apply. Even manufacturers who submit a threat model get the follow-up: no hostile network assumptions, no supply chain risks, no interoperability coverage. "You provided a threat model, but it was not adequate."

Testing evidence is the second family. The letter language is blunt: a summary was provided rather than a full report. FDA expects the testers' independence and expertise, the scope, the duration, the methods, and the complete findings. Penetration testing is explicitly expected for connected devices, and a two-page attestation that testing occurred does not survive review.

SBOM and component questions form the third. SBOMs that aren't machine readable, that miss the NTIA minimum elements, or that arrive in a format the reviewer can't open. And the harder variant: your SBOM shows components past their end-of-support date. Unsupported software can't be patched, so the reviewer asks how you'll maintain it, or when you'll replace it.

The fourth family is unsupported claims about controls and scoring. You referenced TLS without versions or placement in the architecture. You called a checksum an integrity control, and non-cryptographic checksums don't qualify. You described privilege levels without defining them, left USB ports and default accounts out of the hardening story, or rated vulnerabilities without showing the method behind the ratings.

Every letter is the same letter

Read enough of these and the pattern is hard to miss. Underneath the specific asks, the reviewer is making one complaint: I cannot trace your claims to evidence. The threat model doesn't reference the architecture the SBOM describes. The test report doesn't map findings to controls. The risk management report doesn't connect to either. Documents written by different teams at different times tell different stories, and the AI letter is the FDA noticing.

An AI letter is rarely about a missing document. It's about documents that don't agree with each other.

That diagnosis points at the fix. We built ELTON around a digital twin of the device: one model that holds the architecture, the SBOM, the findings, the controls, and the test evidence, all linked. Threat model outputs, testing reports with methodology and scope, score rationales produced through the FDA-qualified MITRE rubric, and risk documentation all generate from that single model. Documents that come from one source can't contradict each other, and traceability stops being an assembly job.

The same linkage answers the postmarket questions too: continued support plans, coordinated disclosure procedures, patch timelines justified by exploitability rather than habit. Reviewers ask for all of these, usually in the same letter.

An AI letter stops your review clock and costs you months. And the questions are sitting in a hundred prior letters, essentially published. Getting one for a missing threat model or an unreadable SBOM in 2025 isn't bad luck. It's a process choice, and an avoidable one.

← All intelligence
Get started

See your device through ELTON.

Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.

Automate medical device vulnerability discovery and verification. FDA §524B methodologyExploitability proven on-device95% faster than legacy testing Book a Demo
Platform
Platform OverviewDigital TwinAutonomous TestingExploitability VerificationVulnerability GraphRemediation OptimizationELTON TestLink™Lifecycle & MetricsCVSSv4 Migration
Solutions
FDA §524BEU MDR/CRAEU REDNIS2IMDRF N60 / N73Postmarket SurveillanceIncident Response
Why ELTON
Why ELTONPricing
Resources
Intelligence & BlogRegulatory GuidesWebinarsWhitepapers
Company
AboutLeadershipCareersContact Book a Demo