The FDA's January 2025 AI-Enabled Device guidance identifies seven AI-specific cyber threats. Only one of them, model evasion, lives at runtime on the device. The other six attack the pipeline: training data, model registries, evaluation logic, and deployment.
Most testing programs today only cover the deployed model. That means they are addressing one-seventh of what the FDA is explicitly asking about. Data poisoning, model inversion and stealing, data leakage, overfitting, model bias, and performance drift all sit upstream of the running model.
Our approach expands the digital twin to include the full AI pipeline as an associated system, then structures testing to cover the whole lifecycle. Runtime testing stays focused and purpose-built. Every test case maps back to a specific FDA-identified threat, executed against real pipeline components, producing defensible evidence for premarket and postmarket.
This is not "test the model." It is "test everything that touches the model."
A model is trained off the device, and so is most of the evidence that it is safe. The version that ships is the last frame of a long process, and cybersecurity that stops at that frame misses where the risk was built.
Well over a thousand AI-enabled devices sit on the FDA's public list, and most premarket submissions scoped cybersecurity to the deployed model alone. The January 2025 draft says the scope is the whole lifecycle.
Section XII of the January 2025 draft names seven cybersecurity threats specific to AI-enabled devices. Six of them attack the data and the pipeline that produce the model. Only one, model evasion, happens at runtime.
Inauthentic or maliciously modified data injected into the training set.
Forged or altered inputs used to infer training data from, or replicate, the model.
Inputs crafted to deceive the model as it runs on the device.
Access to sensitive training or inference data.
AI components pushed with adversarial input so a narrowly fit model returns skewed outcomes.
Training data manipulated to introduce or amplify bias.
The underlying data distribution shifted so the model degrades over time.
Most of the seven threats are decided months before a device ships. Poisoning resistance, bias, and generalization are properties of how the model was trained, not switches you can flip at submission time.
The FDA draft does not stand alone. A wave of AI and data standards has landed recently, each reaching a US submission from a different angle, none of them yet aligned with the others.
It governs data across its whole lifecycle: provenance, integrity, and confidentiality, with protection against tampering and loss. It introduces Data of Unknown Provenance, or DOUP, for data whose source, date, or validity cannot be confirmed, and integrity insurance, the set of measures that keep data accurate and unaltered end to end. Six of the FDA's seven threats attack exactly this layer, which is why a data-management standard is now a cybersecurity document.
Management system for artificial intelligence: the governance wrapper around how an organization builds and runs AI.
Risk management guidance for AI, the AI-specific companion to enterprise risk practice.
Privacy-enhancing data de-identification, referenced inside IEC PAS 63621 for the confidentiality of datasets.
Guidance on applying ISO 14971 risk management to machine learning in medical devices.
The US framework for identifying and managing AI risk across the lifecycle.
International good machine learning practice, the harmonization effort regulators are converging toward.
None are harmonized. All of them still reach you.
A defensible AI cybersecurity package does one thing well. It maps each test and each control back to a specific named threat, across the pipeline and the deployed model, so a reviewer can follow it.
Model the training data, the registries, the evaluation logic, and deployment as associated systems inside the device, not as somebody else's problem. That is what lets testing cover the lifecycle instead of the last version.
Every test case and result points at the specific FDA-named threat it answers, premarket and postmarket. Coverage becomes a list a reviewer can read, not a claim they have to take on faith.
Model evasion is still a runtime threat on the real device, so that testing keeps its place. The guidance widens the scope, it does not shift it. The instruction is not to test the model, it is to test everything that touches the model.
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.
The FDA's January 2025 AI-Enabled Device guidance names seven AI-specific cyber threats: data poisoning, model inversion and stealing, data leakage, overfitting, model bias, performance drift, and model evasion. Only model evasion lives at runtime on the device. The other six attack the pipeline that produces the model.
No. A program scoped to the deployed model covers one of the seven threats the FDA names, model evasion. The other six sit upstream in training data, model registries, evaluation logic and deployment, which means runtime-only testing addresses roughly one seventh of what the guidance asks about.
The AI pipeline is everything that touches the model before it runs: training data, model registries, evaluation logic and deployment. Treating that pipeline as an associated system inside the device model is what lets testing cover the whole lifecycle instead of stopping at the version that ships.
Map every test case back to a specific FDA-identified threat and execute it against real pipeline components. That mapping is what turns test activity into evidence a reviewer can follow for premarket and postmarket, because each result points at the named threat it answers.
No. Runtime testing stays in scope and stays focused, because model evasion is a runtime threat. The guidance widens the scope rather than shifting it. The instruction is not to test the model. It is to test everything that touches the model.
IEC PAS 63621, published in 2026, is a data-management specification for AI-enabled medical devices. It asks manufacturers to govern data across its lifecycle: establish provenance, maintain integrity and confidentiality, control access, and protect against tampering and loss. It introduces Data of Unknown Provenance, or DOUP, for data whose source cannot be confirmed, and integrity insurance for keeping data accurate end to end. Because six of the FDA's seven threats attack the data layer, it reads as a cybersecurity document as much as a quality one.
The guidance is draft, but it reflects what reviewers are already asking about AI-enabled devices, and the underlying obligation is law: a device that meets the section 524B definition of a cyber device must address cybersecurity in its submission. Published standards like IEC PAS 63621 are already in force, and premarket evidence for AI properties has to be captured during development, not reconstructed later. Waiting for the final guidance does not buy back the training-time evidence you would have needed to collect.
Several, and they are not yet harmonized. IEC PAS 63621 covers AI data management. ISO/IEC 42001 and ISO/IEC 23894 cover AI management systems and AI risk management. ISO/IEC 27559 covers dataset de-identification. AAMI CR34971 applies ISO 14971 risk management to machine learning, and the NIST AI RMF and IMDRF good machine learning practice add US and international framing. Each reaches a US submission from a different angle, so a program built around the FDA's seven threats gives you a spine the other standards map onto.