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.
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.
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.
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.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
An AI letter is the FDA's request for Additional Information when a reviewer cannot verify something in your submission. It has nothing to do with artificial intelligence. AI is the agency's own shorthand for its deficiency correspondence, and the review clock stops while you assemble an answer.
The boilerplate cites Section 524B(b)(2) and asks for your methodology and the justification for choosing it, whether STRIDE, attack trees or kill chain, coverage of every end-to-end system element including update infrastructure and cloud services, and diagrams showing where mitigations apply. Missing hostile network assumptions, supply chain risk or interoperability draws the follow-up.
Because the FDA expects the full report: 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.
SBOMs that are not machine readable, that miss the NTIA minimum elements, or that arrive in a format the reviewer cannot open. The harder variant is components past their end-of-support date. Unsupported software cannot be patched, so the reviewer asks how you will maintain it or when you will replace it.
That the reviewer cannot trace your claims to evidence. The threat model does not reference the architecture the SBOM describes, the test report does not map findings to controls, and the risk management report connects to neither. An AI letter is rarely about a missing document. It is about documents that disagree.