On this page
Published: · Updated:
Key Takeaways
- The January 2025 AI lifecycle draft gives seven non-exhaustive risk examples; the February 2026 final cybersecurity guidance recommends threat modeling.
- Assess risks across the ML lifecycle and distinguish cybersecurity threats from clinical performance issues.
- Evaluate each example for applicability and document relevant threats, controls, and verification evidence.
- Generic application security controls are not sufficient, AI threats need AI-specific controls.
- Assess clinical performance drift and bias through device-specific performance monitoring; investigate cybersecurity causes where relevant. The January 2025 AI lifecycle draft proposes monitoring recommendations, while Section 524B addresses cybersecurity vulnerabilities and exploits.
- Maintain traceable cybersecurity risk-management evidence in your quality system. The February 2026 guidance recommends an SPDF but permits other suitable approaches.
The FDA’s January 2025 draft AI lifecycle guidance gives seven non-exhaustive examples of AI risks that can be impacted by cybersecurity threats: poisoning, inversion/stealing, evasion, leakage, overfitting, bias, and drift. Section 524B establishes statutory duties for covered cyber devices; the February 3, 2026 final guidance contains nonbinding recommendations. Evaluate relevant risks for the device. The draft is not for implementation and does not create a universal seven-threat checklist.
Published June 29, 2026
Why This Matters
The February 3, 2026 final premarket cybersecurity guidance provides nonbinding recommendations supporting applicable cybersecurity obligations, including Section 524B. Separately, the January 7, 2025 AI lifecycle draft, Section XII, gives seven non-exhaustive examples of AI risks that can be impacted by cybersecurity threats. It proposes AI-specific risk-management, testing, and documentation recommendations; it is draft guidance, not for implementation. Evaluate the examples against the actual device and document relevant attack paths, controls, and verification evidence. Neither document establishes a universal seven-item clearance checklist.
The final cybersecurity guidance and AI lifecycle draft address related but distinct topics. Use the examples to inform device-specific analysis; neither document makes poisoning or evasion a universal prerequisite or prescribes a particular deficiency finding. Suitable standards can inform controls without converting draft recommendations into statutory duties.
The seven examples below come from the draft AI guidance’s cybersecurity section. The draft is not for implementation. Some risks also occur without malicious activity; assess cybersecurity causes where relevant. The controls and evidence tables are company examples, not prescribed submission artifacts.
At-a-Glance: 7 Threats → Test Types → Standards
This company matrix maps the draft’s seven risk examples to possible tests and practitioner frameworks. Select activities based on actual device risks; it is not an FDA-prescribed testing checklist. Every technique ID is from MITRE ATLAS; attack classes map to NIST AI 100-2 E2023, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations; practitioner test lists are from OWASP ML Top 10 and, for LLM-backed devices, OWASP LLM Top 10.
| # | FDA threat | Test types to run | NIST AI 100-2 class | MITRE ATLAS | OWASP |
|---|---|---|---|---|---|
| 1 | Data Poisoning | Training-data provenance verification; signed-manifest negative tests; backdoor / trigger scans on imported weights; canary-sample detection; red-team poisoning injection against drift/outlier detector | Poisoning (targeted, backdoor, availability) | AML.T0020 Poison Training Data; AML.T0018 Backdoor ML Model | ML02 Data Poisoning; LLM03 Training Data Poisoning |
| 2 | Model Inversion & Stealing | Membership-inference tests; attribute-inference tests; model-extraction / surrogate-fidelity tests under a defined query budget; rate-limit and auth pen tests against inference endpoint; output-minimization verification | Privacy (membership inference, model extraction, attribute inference) | AML.T0024 Exfiltration via ML Inference API; AML.T0044 Full ML Model Access; AML.T0057 LLM Data Leakage | ML05 Model Theft; ML03 Model Inversion; LLM10 Model Theft; LLM06 Sensitive Information Disclosure |
| 3 | Model Evasion | Adversarial robustness testing with FGSM, PGD, AutoAttack, C&W, adversarial patches; modality-specific attacks (audio, waveform, tabular); OOD-detector validation; confidence-threshold fallback tests; certified-robustness bounds where warranted | Evasion (white-box, black-box, transferability) | AML.T0015 Evade ML Model; AML.T0043 Craft Adversarial Data | ML01 Input Manipulation Attack; LLM01 Prompt Injection (for LLM-backed devices) |
| 4 | Data Leakage | Authenticated + unauthenticated pipeline pen test (object storage, feature store, model registry, logs, caches); IAM and encryption config scans; inference-endpoint verbose-output tests; debug-log PHI-exfiltration tests | Privacy (data reconstruction, side-channel) | AML.T0035 ML Artifact Collection; AML.T0025 Exfiltration via Cyber Means | ML06 AI Supply Chain Attacks (storage/logs); LLM02 Insecure Output Handling; LLM06 Sensitive Information Disclosure |
| 5 | Overfitting | Held-out and external-cohort validation; train/val gap thresholds gated in CI; decision-boundary sharpness tests; adversarial-overfitting simulations after training-data refresh; reproducible-training pipeline verification | Poisoning (availability) + robustness generalization | AML.T0018 Backdoor ML Model (as exploit path); AML.T0031 Erode ML Model Integrity | ML04 Membership Inference (indirect indicator); ML08 Model Skewing |
| 6 | Model Bias | Stratified subgroup performance tests (sensitivity, specificity, calibration by demographic and clinical subgroup); disparity-threshold gates; backdoor / trojan scanning on imported checkpoints; ML-SBOM provenance verification; postmarket subgroup-drift monitoring validation | Poisoning (backdoor); abuse (bias amplification) | AML.T0019 Publish Poisoned Datasets; AML.T0010 ML Supply Chain Compromise | ML07 Transfer Learning Attack; ML08 Model Skewing; LLM05 Supply Chain |
| 7 | Performance Drift | Drift-detector validation against benign vs. adversarial shifts; reference-distribution regression tests; signed-update negative tests (unsigned rejected); rollback tests; postmarket telemetry-integrity tests | Availability / integrity (adversarial drift) | AML.T0031 Erode ML Model Integrity; AML.T0034 Cost Harvesting | ML09 Output Integrity Attack; LLM04 Model Denial of Service |
GenAI / LLM-backed devices should additionally run: prompt-injection suites (direct and indirect), jailbreak suites, insecure-output-handling tests, and tool-abuse tests. Tooling: IBM Adversarial Robustness Toolbox (ART), Foolbox, CleverHans, Microsoft Counterfit, NVIDIA Garak for LLMs, Microsoft PyRIT for GenAI red-teaming, and Giskard for ML testing. Each table gives example quality-system evidence. Clinical performance validation remains the manufacturer’s responsibility, separate from Blue Goat Cyber’s security testing.
1. Data Poisoning
What it is. Cyber attackers deliberately inject inauthentic or maliciously modified records into training, fine-tuning, or feedback data so the model learns the wrong thing, for example, labeling malignant lesions as benign or shifting decision boundaries in a sepsis predictor.
Why it is a 524B issue. Data poisoning is not just bad data hygiene; it is an integrity attack on the model's training pipeline. The FDA treats the training pipeline as part of the device's attack surface when training artifacts or update channels affect the deployed model.
Mitigations.
- Cryptographically signed dataset manifests and per-record hashes; reject any training run whose corpus does not match the manifest.
- Role separation between data engineers, label reviewers, and model owners; least-privilege access to the training bucket and feature store.
- Statistical drift and outlier detection on inbound training and feedback data, gated before the next training run.
- A documented retrain/revert procedure with a known-good model baseline if poisoning is suspected post-deployment.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Training-data provenance policy + signed manifest schema | Manifest-signature validation test (negative case rejected) | Data-integrity test report referenced in eSTAR Security Architecture section |
| Secure implementation | Access-control matrix for training infra and feature store | IAM/least-privilege review + log review | Access-review record and IAM export attached to threat model |
| Secure verification | Statistical drift / outlier detector on inbound data | Red-team poisoning injection against detector | Adversarial-test report; STRIDE/ATLAS row "Tampering, AML.T0020 Poison Training Data" |
| Secure release & response | Retrain-from-known-good runbook | Tabletop on poisoning incident | Postmarket response plan + runbook version in submission |
For a deeper treatment, see our dedicated post on AI data poisoning in medical devices.
2. Model Inversion and Model Stealing
What it is. An attacker queries the deployed model with crafted inputs to either (a) reconstruct sensitive attributes of the training data, model inversion, or (b) replicate the model's behavior in a surrogate, model stealing. Both attacks turn the inference endpoint into a side channel.
Why it is a 524B issue. Inversion can leak PHI used during training, which can create confidentiality risks relevant to Section 524B compliance. Stealing exposes proprietary weights and creates a parallel model an attacker can then attack offline at no cost, accelerating every other threat on this list.
Mitigations.
- Authentication, authorization, and per-user/per-device rate limiting on every inference endpoint.
- Output minimization: return the class or score the clinician needs, not full logits, embeddings, or attention maps.
- Differential-privacy or noise-injection techniques where training data is sensitive.
- Query-pattern anomaly detection for high-volume probing or adversarial query distributions.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Inference-API threat model entry (Information Disclosure) | Architectural review against ATLAS "AML.T0024 Exfiltration via ML Inference API" | Threat-model row + data-flow diagram |
| Secure implementation | AuthN/AuthZ, rate-limit, and output-minimization config | Endpoint pen test with stolen credentials and probing harness | Pen-test report (AI scope) |
| Secure verification | Model-stealing simulation (query budget, fidelity score) | Surrogate-model fidelity test below documented threshold | Verification report with fidelity metrics |
| Secure release & response | Inference-log retention + anomaly alert rules | Incident tabletop on detected probing campaign | Postmarket monitoring plan section |
See Medical Device AI Model Inversion for the full breakdown.
3. Model Evasion
What it is. An attacker crafts or perturbs an input, often imperceptibly to a clinician, so the model misclassifies it. A pixel-level perturbation on a dermatology image, an adversarial patch on an ECG waveform, or carefully chosen noise in a radiology scan can flip a prediction.
Why it is a 524B issue. Evasion attacks degrade the reliability of clinical output, which the FDA treats as patient-safety-relevant. The draft AI guidance names evasion as a cybersecurity threat, so expect reviewers to ask how your controls protect the integrity of model predictions, not only the system around the model.
Mitigations.
- Adversarial robustness testing against published attack libraries (FGSM, PGD, patch attacks, modality-specific attacks).
- Input validation, range checks, and out-of-distribution (OOD) detection on raw inputs and intermediate features.
- Confidence thresholds with human-in-the-loop fallback when confidence is low or OOD detection fires.
- Adversarial training or certified-robustness techniques where the harm rating warrants it.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Adversarial-robustness requirement tied to hazard analysis (ISO 14971) | Threat-model row "Tampering, AML.T0015 Evade ML Model" | Hazard-to-control traceability table |
| Secure implementation | OOD detector + confidence-threshold logic in inference path | Unit + integration tests for OOD fallback | Code-review record + test results |
| Secure verification | Adversarial test plan (FGSM, PGD, patch, modality-specific) | Robustness benchmark vs. clean accuracy delta | Adversarial-test report appended to risk-based testing summary |
| Secure release & response | Field-collected misprediction triage workflow | Tabletop on adversarial input cluster in production | Postmarket surveillance plan |
See AI Model Evasion in Medical Devices for examples and test patterns.
4. Data Leakage
What it is. Cyber threats exploit vulnerabilities to access sensitive training data, fine-tuning data, or inference-time data, for example, through misconfigured object storage, over-broad model endpoints, debug logs, or cached intermediate tensors.
Why it is a 524B issue. Data leakage is a direct confidentiality failure under 524B's expectations for protecting electronic information. It may also raise issues under HIPAA, where the manufacturer is a covered entity or business associate, and applicable international privacy regimes, but the FDA cybersecurity reviewer will judge it on 524B grounds.
Mitigations.
- Encryption in transit and at rest for every store that holds training, validation, or inference data.
- Strict separation of training infrastructure from production patient data; documented data-minimization at each stage.
- Tamper-evident access logging that captures who read which dataset and when.
- Pen testing that explicitly probes the data pipeline and the inference endpoint, not only the device firmware.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Data-flow diagram with classification labels (PHI, derived, model artifact) | Architecture review against 524B "protect electronic information" | Architecture section of submission |
| Secure implementation | Encryption + IAM config for every data store and bucket | Config scan and IAM review | Cryptographic-controls summary |
| Secure verification | Pipeline pen test (storage, logs, caches, inference) | Authenticated and unauthenticated tests with leakage findings | AI penetration testing report |
| Secure release & response | Incident-response runbook covering PHI exposure | Tabletop with disclosure and notification path | IR plan + breach-notification SOP |
5. Overfitting
What it is. A model is trained too closely to its training set and generalizes poorly. A cyber attacker can deliberately push a model toward overfitting by injecting narrow patterns into training data, then exploit the brittle decision surface with adversarial inputs at inference time.
Why it is a 524B issue. Overfitting is normally a model-quality concern, but the FDA includes it here because attackers can cause it deliberately and then exploit it. That makes overfitting an indicator of compromise as well as a quality defect.
Mitigations.
- Held-out validation across demographically and clinically diverse cohorts; cross-validation results in the submission.
- Train/validation gap and decision-boundary sharpness treated as security-relevant alerts, not only data-science metrics.
- Regularization, dropout, and ensemble strategies documented in the model card.
- Re-evaluation of overfitting indicators after every training-data refresh or PCCP-authorized update.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Generalization requirement linked to clinical performance acceptance criteria | Review against intended-use population | Performance requirements traceability |
| Secure implementation | Regularization + ensemble configuration captured in model card | Reproducible training pipeline test | Model card + training-pipeline artifact |
| Secure verification | Subgroup + external-dataset validation; train/val gap threshold | Validation report with diverse cohorts | Clinical/non-clinical performance section |
| Secure release & response | Overfitting-alert rule tied to retraining triggers | Tabletop on suspected adversarial overfitting | Postmarket monitoring plan |
See AI Overfitting Cybersecurity Threats in Medical Devices for detection patterns.
6. Model Bias
What it is. Bias enters when training data under-represents populations, when labels carry historical inequities, or when an attacker deliberately skews fine-tuning data, embeds backdoors, or distributes pre-trained models that already carry bias to be amplified downstream.
Why it is a 524B issue. The draft AI guidance lists model bias introduced through manipulated training data or other exploits as a cybersecurity threat. Backdoor triggers and adversarial bias amplification fall into this category. FDA guidance recommends that bias monitoring be integrated with security monitoring, not run as a separate fairness exercise.
Mitigations.
- Provenance and integrity of any third-party datasets or pre-trained checkpoints; SBOM-style accounting for ML artifacts.
- Subgroup performance reporting (sensitivity, specificity, calibration by demographic and clinical subgroup) in the premarket submission.
- Backdoor scanning on imported model weights and a procedure for re-training if a backdoor is found.
- Postmarket bias monitoring tied to the device's postmarket cybersecurity program.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | ML-SBOM listing datasets, checkpoints, licenses, versions | Review of artifact provenance against SBOM/supply chain requirements | ML-SBOM in submission |
| Secure implementation | Backdoor / trojan scan in CI on imported weights | Negative test with planted trigger | CI scan report |
| Secure verification | Subgroup performance + fairness metrics | Subgroup test report with predefined thresholds | Performance section of submission |
| Secure release & response | Bias-monitoring rules in postmarket telemetry | Tabletop on detected subgroup drift | Postmarket plan |
7. Performance Drift
What it is. Cyber attackers shift the input data distribution over time, through compromised upstream sensors, manipulated EHR fields, or slow injection of skewed feedback, so the model's accuracy decays. Drift can also arise naturally; the threat is that an attacker can cause it on purpose and hide it as ordinary degradation.
See also: Medical Device Cybersecurity: Nanotech, Home Use vs Hospital Device Cybersecurity Requirements, and Infusion Pump Cybersecurity: FDA Expectations.
Why it is a 524B issue. Performance drift connects directly to postmarket cybersecurity obligations. FDA guidance recommends that manufacturers detect drift, decide whether it is benign or adversarial, and respond within their PCCP or change-control process.
Mitigations.
- Continuous performance monitoring against a held-out reference distribution; alarm thresholds documented in the SPDF.
- Distinction between data drift, concept drift, and adversarial drift, with investigation playbooks for each.
- Integrity controls on the update channel so legitimate retraining cannot be hijacked.
- Reporting paths into the FDA when drift indicates a cybersecurity issue affecting safety or effectiveness.
SPDF control / test mapping.
| SPDF activity | Control artifact | Verification test | Submission evidence |
|---|---|---|---|
| Secure design | Drift-monitoring requirement + reference distribution definition | Architectural review of telemetry path | Postmarket monitoring architecture |
| Secure implementation | Signed update channel + rollback control | Negative test: unsigned update rejected | CI/CD security gates evidence |
| Secure verification | Drift-detector validation against benign and adversarial shifts | Adversarial-drift simulation | Verification report |
| Secure release & response | Drift triage playbook + FDA reporting decision tree | Tabletop covering benign vs. adversarial drift | Postmarket plan + reporting SOP |
See AI Performance Drift in Medical Devices for the monitoring architecture.
Mapping the 7 Threats to Your SPDF and Threat Model
Our example organizing approach connects relevant cybersecurity threats across these records; three separate locations or files are not prescribed:
- Threat model. Use STRIDE or a STRIDE-plus-MITRE-ATLAS overlay so AI-specific threats sit alongside conventional ones. ATLAS gives you the adversarial ML tactics and techniques; STRIDE keeps the framing consistent with the rest of the device. See our step-by-step threat modeling guide.
- SPDF risk and control matrix. Each threat ties to one or more controls, each control ties to one or more verification activities, and each verification activity produces an artifact that goes into the submission.
- Postmarket monitoring plan. Monitor device-specific cybersecurity vulnerabilities and exploits. Address clinical drift and bias through the appropriate performance program and investigate malicious causes where relevant.
Support relevant cybersecurity threats with traceable controls, verification, and response evidence. Explain nonapplicable examples rather than treating all seven as mandatory.
What FDA Guidance Recommends for AI Device Cybersecurity in 2026
Three FDA documents shape AI device cybersecurity in 2026, and they carry different weight. Section 524B of the FD&C Act sits underneath all three for cyber devices and is the only one that is law.
| Document | Status | What it asks for on security |
|---|---|---|
| Premarket cybersecurity guidance (February 3, 2026) | Final | Threat model, security risk assessment, architecture views, SBOM, testing, and update plan for all device software, AI included |
| AI PCCP guidance | Final, updated August 18, 2025 | Recommended methods and impact assessment when proposing an optional PCCP; authorization is needed for the specified-change pathway |
| AI-enabled device software functions guidance (January 2025) | Draft, not for implementation | Gives seven non-exhaustive risk examples and proposes documenting applicable cybersecurity risks |
The February 2026 premarket guidance
This guidance does not have an AI chapter, and it does not need one. It covers all device software, so the AI parts of your system go into the same threat model, risk assessment, architecture views, and test report as everything else. In practice that means the model, the training pipeline, the model registry, any outside AI service, and the update path each appear as components with trust boundaries. Model files and AI libraries belong in the SBOM. Penetration testing should reach the AI parts, not stop at the app and cloud around them. If the model can be updated, the secure update process the guidance describes applies to model updates too.
PCCPs and security
A PCCP is optional. Once the FDA authorizes it, specified modifications implemented consistently with the authorized plan may be made without another marketing submission. The PCCP guidance focuses on performance and data, but a change that skips security review can undo the controls in your original submission. For each proposed change, assess cybersecurity impacts and describe appropriate release controls, threat-model review, and testing. Signing is one possible control, not a universally mandated technology. Changes that add a new data source, a new outside service, or a new release path usually need a fresh look at the threat model. See our fictional PCCP cybersecurity example for how this reads in a plan.
The draft AI device guidance
The January 2025 draft is the FDA's clearest statement of how it thinks about AI-specific threats. It names the seven threats covered above and expects the cybersecurity section of a submission to explain how each one that applies is handled. Because it is a draft, it is not a binding requirement, and the final version may change. It is still a good map of the questions reviewers are likely to ask, so most teams address its threats now rather than wait.
What this means for your submission
- One threat model for the whole system, with AI parts as components and the applicable AI threats as entries.
- Controls for each AI threat, traced to tests and results.
- Model files, AI libraries, and outside AI services listed in the SBOM.
- If proposing an optional PCCP, cybersecurity impact assessment and controls appropriate to the specified modifications.
- Cybersecurity monitoring plus device-appropriate clinical performance monitoring, keeping their respective duties and recommendations distinct.
Our AI/ML Medical Device Security service covers threat modeling, testing, and submission documentation for each of these. For hands-on detail, see threat modeling AI-enabled devices (worked example), AI training data security, AI model integrity, generative AI device security, and hospital security questions for AI devices.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our AI/ML Medical Device Security service or book a discovery call.
How Blue Goat Cyber Approaches AI Threat Modeling
Our ThreatGoat threat-modeling workflow helps assess relevant AI risk examples and trace threats to controls. Our team uses suitable methods, including STRIDE and MITRE ATLAS where useful, to plan evidence-backed security testing. These are company methods, not mandatory FDA taxonomies or seven-entry templates. Our AI penetration testing service then exercises the controls against the actual deployed model, so the evidence in your submission reflects how the system behaves under attack, not only how it is designed.
If you are preparing a 510(k), De Novo, or PMA for an AI-enabled device, the fastest path through a clean cybersecurity review is a threat model and SPDF that already speak the language of the Feb 3, 2026 premarket guidance and the draft AI guidance.
If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.
Related reading: MedTech Cyber Standards Every Device Team Must Know.
FAQ
Related Deep-Dives on the 7 AI Threats
Each of the threats above has a dedicated post with detection patterns, controls, and test evidence:
- Data Poisoning, Safeguarding Medical Device AI from Data Poisoning
- Model Inversion & Stealing, Medical Device AI Model Inversion: Threats and Solutions
- Model Evasion, Protecting Medical Devices from AI Model Evasion
- Data Leakage, AI Penetration Testing for Medical Devices (covers data-pipeline leakage paths)
- Overfitting, AI Overfitting Cybersecurity Threats in Medical Devices
- Model Bias, How to Respond to an FDA Cybersecurity AI Request (discusses device-specific performance and cybersecurity evidence)
- Performance Drift, Understanding AI Performance Drift in Medical Devices
Supporting reading: Threat Modeling Connected and Implantable Devices · FDA Section 524B Subsections Explained
Sources & References
FDA and statute
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Final Guidance, February 3, 2026).
- FDA, Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (Draft, January 2025).
- FDA, Predetermined Change Control Plans for Machine Learning-Enabled Device Software Functions (Final, originally issued December 4, 2024; updated August 18, 2025).
- Section 524B of the Federal Food, Drug, and Cosmetic Act (added by the Consolidated Appropriations Act, 2023).
AI-attack taxonomies and testing frameworks
- NIST, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (NIST AI 100-2 E2023).
- NIST, AI Risk Management Framework (AI RMF 1.0) and the Generative AI Profile (NIST AI 600-1).
- MITRE ATLAS (Adversarial Threat Landscape for AI Systems) - tactic and technique catalog cited in the matrix above.
- OWASP Machine Learning Security Top 10.
- OWASP Top 10 for Large Language Model Applications.
Medical-device standards
- AAMI CR34971:2023, Application of ISO 14971 to Machine Learning in Artificial Intelligence. See our CR34971 explainer.
- AAMI TIR57:2016 (R2023), Principles for medical device security - Risk management.
- ANSI/AAMI SW96:2023, Standard for medical device security - Security risk management for device manufacturers.
- IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security - Part 5-1: Security - Activities in the product life cycle.
- ISO 14971:2019, Medical devices - Application of risk management to medical devices.
- ISO/IEC 23894:2023, Artificial intelligence - Guidance on risk management.
- ISO/IEC 27090 (in development), Cybersecurity - Artificial Intelligence - Guidance for addressing security threats to artificial intelligence systems.
Testing tooling referenced above
- IBM Adversarial Robustness Toolbox (ART), Foolbox, CleverHans, Microsoft Counterfit, NVIDIA Garak, Microsoft PyRIT, Giskard.
Need help building an SPDF and threat model that covers all seven of these AI threats? Talk to Blue Goat Cyber about a 524B-ready AI cybersecurity engagement, or start with our ThreatGoat threat-modeling workflow.
About the author, The Blue Goat Cyber team specializes in cybersecurity for FDA-regulated medical devices, including AI/ML-enabled systems subject to section 524B of the FD&C Act. We help manufacturers ship clean premarket submissions and run defensible postmarket programs.
Related on FDA Section 524B
- FDA Section 524B: complete cybersecurity requirements guide
- Does Section 524B apply to my auto-injector?
- Does Section 524B apply to legacy devices?
- Documenting update cadence for a 524B submission
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- January 7, 2025 AI lifecycle draft- U.S. FDA
- MITRE ATLAS- MITRE
- NIST AI 100-2 E2023, *Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations*- NIST
- OWASP LLM Top 10- OWASP
- Premarket cybersecurity guidance- U.S. FDA
- AI PCCP guidance- U.S. FDA
- AI-enabled device software functions guidance- U.S. FDA
- *AI Risk Management Framework (AI RMF 1.0)*- NIST
- *Generative AI Profile (NIST AI 600-1)*- NIST