An AI-enabled device ships a model, and the model is the output of a data pipeline: acquisition, annotation, verification and validation, training, evaluation, packaging. Attacks land anywhere along that pipeline, and most of them land before the device exists. ELTON maps the pipeline into the digital twin, tests it as infrastructure, and manages what it finds for the life of the product.
Every system that consumes data has an integrity problem, and every security program already knows how to handle a tampered input at runtime. Machine learning is different in one way only: it consumes data to become the software. The training set is the source code. Whatever was in it, the model learned, and a violation of that data's integrity during training is not a bug you patch later. The run is over. You start again from zero.
A conventional device is defined by its code, and its data flows through it. An AI-enabled device is defined by the data it was trained on. Anyone who can write to the training set can write to the product, without touching a line of code or a single build server.
The V&V phase is where the pipeline decides what is true: which samples are clean, which labels stand, which split is held out. Everything downstream trusts that decision. An attacker with write access there does not need to poison millions of records. They need to change what passes.
Once a poisoned or corrupted sample has been trained in, it lives in the weights. There is no patch that removes it. The only remedy is to discard the run and retrain from a clean set, which means the cost of an integrity failure is the cost of the whole run, and for a shipped device, the cost of a release.
The integrity risk is the same for every model. What differs is when the bill arrives. A frontier LLM costs millions to train once, so a poisoned run is catastrophic at training time. A model retrained every night on live data barely notices, because tomorrow overwrites today. A medical device model can be cheap to train and still carry the LLM's problem, because once it ships, changing it means a field update, a validated release, and a conversation with a regulator.
Federated learning moves the model to the data, so the training set never leaves the hospitals that hold it. It also means the pipeline now spans sites you do not control, every site is a place an update can be poisoned, and the aggregation step becomes the integrity choke point for the whole model. The surface grows, and the verification has to grow with it.
Every hospital procurement will eventually ask why it should buy a device whose model cannot be updated when a better one arrives, and what happens when the current one degrades. An updatable model is a pipeline that runs after shipping, which means the pipeline is part of the product's attack surface for its whole service life, not just its development.
A model assumes the inputs it sees in the field are drawn from the same world as its training data. That assumption fails quietly. A site switches to new imaging instrumentation. A sensor ages and its noise floor shifts. Hardware starts to fail in ways that never appeared in the training set. Patient populations change, and biology itself changes over time, so the detector trained on one body sees another. The colon cancer model stops detecting colon cancer, and nothing in the device tells anyone.
Inputs shifted away from the training distribution. The model is doing exactly what it learned, on data it never learned. FDA names this as threat seven, performance drift, and IEC PAS 63621 requires data quality analysis across the product lifecycle precisely because data that met requirements at verification can stop meeting them later.
The data, the pipeline or the artifact was changed. The model is doing what an attacker taught it. From the output alone this is indistinguishable from drift, which is why an incident that starts as a performance complaint can be a security incident that nobody has recognized yet.
Two documents now describe the same pipeline from opposite ends. FDA's January 2025 draft guidance for AI-enabled device software functions lists seven cybersecurity threats specific to AI in Section XII, and expects sponsors of AI-enabled cyber devices under section 524B to document them premarket and manage them postmarket. IEC PAS 63621:2026 lays out the data lifecycle a manufacturer has to run for any data used to train, test or validate a device model. Read together, they are a threat list and a control list for the same infrastructure.
ELTON treats the training environment as part of the device. The pipeline goes into the digital twin next to the firmware and the interfaces, the same agentic testing that runs against the device runs against the pipeline's infrastructure, and every finding is verified, traced to a component and to the FDA-named threat it answers, then carried forward across every retrain and release.
From the documentation the QMS already produces, including the IEC PAS 63621 dataset descriptions, ELTON models the pipeline as infrastructure: data sources and storage, annotation tooling, verification and validation jobs, training and evaluation runs, the model registry, packaging and the field update path. Trust boundaries and access paths go in with them.
Agentic vulnerability testing runs against the pipeline the way it runs against the device: access control on dataset storage and cloud buckets, integrity of revision control, authentication on annotation platforms, artifact signing and registry access, secrets in training infrastructure. Then the test that matters most: can a tampered sample pass verification and validation and reach training?
Findings are verified for exploitability on the real pipeline, rated with the qualified MDDT methodology, and dispositioned with the test case attached. Pipeline components are monitored for new CVEs like any other part of the device, and every retrain or release re-enters the pipeline and is retested against what ELTON already knows.
Bring one AI-enabled product. We map the pipeline that built its model into the twin, test it as infrastructure, and show you which of the seven threats actually reach it.
Is the training pipeline in scope for FDA cybersecurity review?
Yes. Section XII of FDA's January 2025 draft guidance for AI-enabled device software functions names seven AI-specific threats, and six of them live in the data and the pipeline that produce the model: data poisoning, model inversion and stealing, data leakage, overfitting, model bias and performance drift. Sponsors of an AI-enabled cyber device under section 524B are expected to document these risks in the submission.
Why is an integrity violation during training worse than a runtime bug?
A runtime bug is patched in code. A poisoned training set is learned by the model, and there is no way to cut the bad data back out of the weights after the fact. The run is discarded and started again from zero. For a medical device that has already shipped, that restart is a validated release and a regulatory event, which is why the cost lands after shipping.
How do you tell model drift from tampering?
From the outside they look the same: a model that starts returning wrong answers. Drift comes from the world moving, such as new instrumentation, aging sensors or a patient population that no longer matches the training set. Tampering comes from someone changing the data, the pipeline or the artifact. The way to separate them is evidence about the pipeline itself: integrity of the dataset versions, access to the registry, and test results that show whether a tampered sample could have passed verification. ELTON produces that evidence.
What does IEC PAS 63621 require that touches security?
IEC PAS 63621:2026 sets a data lifecycle framework for data used to train, test or validate an AI model in a medical device. It asks for revision control with integrity protection so data is authentic and unchanged, unique immutable identifiers for every data item, provenance and annotator identity for labels, documented storage security and access permissions, and data quality analysis across the product lifecycle that accounts for drift. Every one of those is a control an attacker would target and a test ELTON can run.
Does ELTON test the model, or the pipeline?
Both, and the split matters. Model evasion is tested on the deployed device, over TestLink or in our lab. The other six threats are tested against the pipeline as infrastructure: dataset storage, annotation tooling, verification and validation jobs, training runs, the registry and the release path. Findings trace to a component in the digital twin and to the FDA-named threat they answer.
What about federated learning?
Federated training moves the model to the data instead of the data to the model, so the pipeline now spans sites you do not control. Every site is a place an update can be poisoned and the aggregation step becomes the integrity choke point. ELTON models the federation topology in the twin and tests the update and aggregation path the same way it tests a central pipeline.