AI/ML-enabled medical devices carry every traditional device cybersecurity risk plus a new class of threats: adversarial inputs, training-data poisoning, model theft, and silent drift that can degrade safety without triggering conventional alarms. This guide covers what to add to your SPDF, threat model, 524B package, and postmarket monitoring when a model is inside the device.
Answer three quick questions and get a tailored, saveable checklist mapped to FDA 524B, the Feb 3, 2026 guidance, and PCCP expectations. Your answers and progress persist in this browser.
Every deployed model artifact (weights, tokenizer, preprocessing pipeline) is a software component. Version-pin the model checkpoint, record its training-data provenance, and include it in your SBOM as a first-class entry. Reviewers increasingly expect this even before FDA formalizes model-BOM guidance.
Extend STRIDE with an ML-specific pass: evasion (adversarial examples), poisoning (training-time corruption), model inversion (privacy leakage), model extraction (IP theft), and membership inference. For clinical models, focus first on evasion and poisoning — they map most directly to patient-safety harm.
A Predetermined Change Control Plan can cover model retraining, threshold tuning, and expanded data — but explicitly exclude changes to authentication, cryptography, transport, or SBOM composition. Retraining that pulls in new libraries or new data sources should trigger a return to the 524B process, not proceed under the PCCP.
Cryptographically sign model artifacts and verify signatures before loading. This defends against on-device model tampering and gives you a clean audit trail for postmarket investigations.
Traditional postmarket vulnerability monitoring assumes discrete software versions. For ML devices, add continuous monitoring for distribution shift, prediction confidence anomalies, and input patterns consistent with adversarial probing. Drift can be a safety event and a security signal at the same time.
Reviewers want to see: provenance of every training dataset, controls on data ingestion (poisoning defense), retention and deletion policy, PHI handling, and a documented split between training, validation, and test sets. Poor data governance is the fastest path to a cyber deficiency letter on an ML device.
If your device incorporates a large language model or generative component, treat prompt injection and jailbreaks as first-class threats. Layered defenses (input filtering, output validation, tool-call allowlists, and human-in-the-loop for high-risk actions) belong in the security architecture — not the marketing FAQ.
A vulnerable model is not always patchable with a code fix. Your incident response plan should include: rapid rollback to a prior model version, ability to disable the ML feature and revert to non-ML behavior, and a communication pathway that distinguishes model behavior changes from software vulnerabilities.
Test AI/ML models against evasion, poisoning, and model-extraction attacks before submission. FDA reviewers now expect adversarial ML threats named explicitly in the threat model, with test evidence — not just a narrative acknowledgment.
Every clinically material model should ship with a model card (intended use, performance, known failure modes) and a datasheet for its training data (provenance, licensing, demographic coverage). These are increasingly requested in Q-Subs alongside the SPDF.
An SBOM covers software components; an MLBOM (ML Bill of Materials) covers model weights, training datasets, and inference dependencies. Provide both when your device has a substantive ML component — CycloneDX 1.5+ supports MLBOM natively.
Predefine the drift metrics (input distribution, output distribution, performance) and thresholds that trigger action. Small drift = retrain under PCCP; large drift or new data source = new submission. Document the decision tree in your postmarket plan.
Quick answers to the questions teams most often ask about this topic.
It adds a new threat surface on top of the traditional one. Adversarial inputs, training-data poisoning, model theft, and silent model drift are unique to learning-enabled devices. The traditional controls (auth, crypto, SBOM, CVD) still apply - you layer ML-specific defenses on top, not instead.
Yes. Section 524B applies to any 'cyber device' regardless of whether it uses ML. FDA's premarket cyber guidance and postmarket expectations cover ML-enabled devices, and Predetermined Change Control Plans (PCCPs) provide a mechanism for shipping model updates without a new submission, provided the changes are scoped and pre-authorized.
Yes. Model weights, tokenizers, and preprocessing pipelines are software components - version-pin them, record hashes, and include them in the SBOM. Reviewers increasingly expect a model-level entry, and it makes postmarket vulnerability triage far cleaner when a training-time issue is discovered.
Evasion (adversarial examples), poisoning (training-time corruption), model inversion (privacy leakage from the model), model extraction (stealing the model by querying it), and membership inference. For clinical AI, prioritize evasion and poisoning - they map most directly to patient-safety harm.
Scope the PCCP so it explicitly excludes changes to cyber-relevant components: authentication, cryptography, transport, or SBOM composition. Retraining alone should not change those. If a planned update crosses that line, it returns to the standard 524B process instead of proceeding under the PCCP.
An MLBOM (Machine Learning Bill of Materials) documents training data provenance, model architecture, hyperparameters, evaluation metrics, and known limitations. It is not yet mandated, but reviewers increasingly ask for it, and CycloneDX 1.5+ supports ML-BOM natively as a superset of the standard SBOM.
Define acceptance thresholds during premarket (sensitivity, specificity, calibration) and monitor them continuously in postmarket. When drift exceeds threshold, the response should follow the same change-control path as any other safety-relevant deviation: risk-assess, remediate, and disclose per your CVD/postmarket plans.
Jump to all guides for the lifecycle phase that fits where you are.