EU AI Act vs FDA AI/ML Cybersecurity for Devices

AI and machine learning medical devices face a cybersecurity regime that is sharper than standard SaMD on both sides of the Atlantic. This guide compares EU AI Act Article 15 cybersecurity obligations against the FDA's AI/ML SaMD framework and Section 524B as applied to AI/ML devices.

Last reviewed: May 2026 against the FDA February 2026 final guidance, the FDA AI/ML SaMD Action Plan and PCCP guidance, and EU AI Act (Regulation 2024/1689) provisions in force.

Community project: ai-samd.com is a free reference resource we sponsor for AI-SaMD-specific topics - model lifecycle, PCCPs, EU AI Act conformance. Use this guide for the cybersecurity narrative; use ai-samd.com for AI-SaMD lifecycle depth.

At a glance - How the regimes apply to AI/ML SaMD

Why AI/ML SaMD is a different cybersecurity problem

A connected infusion pump and an AI-driven diagnostic share the standard threat surface - network interfaces, OTA updates, SBOM hygiene. AI/ML SaMD adds threats that don't exist for traditional software:

• Model evasion - adversarial inputs crafted to flip the model's output (an image perturbed to look benign to a tumor classifier).
• Model inversion - extracting training data by querying the model (a privacy attack against PHI used in training).
• Membership inference - determining whether a specific record was in the training set.
• Model poisoning - corrupting training data or weights to introduce a backdoor.
• Model theft / extraction - querying the model to reconstruct it.
• Prompt injection (for LLM-based devices) - instruction smuggling that bypasses safety guardrails.
• Data drift - statistical shift between training and deployment data that degrades performance without any malicious actor.

Both regulators now expect these threats in your threat model. Neither will accept a threat model that treats AI/ML SaMD like a static binary.

The EU AI Act side

Classification

The EU AI Act (Regulation 2024/1689) creates four risk tiers. Medical devices regulated under MDR/IVDR are explicitly named in Annex III as high-risk AI systems when they are AI systems and intended to be used as a safety component of, or as themselves, a medical device. That covers most AI/ML SaMD.

Article 15 - accuracy, robustness, and cybersecurity

Article 15 is the cybersecurity anchor. It requires that high-risk AI systems be designed and developed to achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle, and to perform consistently in those respects.

Article 15(4) is explicit on cybersecurity: high-risk AI systems must be resilient against attempts to alter their use, outputs, or performance by exploiting system vulnerabilities. Technical solutions must address AI-specific vulnerabilities, including:

• Data poisoning - attacks on training datasets.
• Model poisoning - attacks on pre-trained components.
• Adversarial examples / model evasion - attacks on inputs at inference time.
• Confidentiality attacks - model inversion, membership inference, model theft.
• Flaws in the AI model itself.

Article 10 - data governance

Article 10 requires training, validation, and testing datasets to be subject to appropriate data governance - including examination for biases, gaps, and data integrity. From a cybersecurity perspective, training data lineage becomes a controlled artifact you must protect, audit, and version.

Article 72 - postmarket monitoring

Providers of high-risk AI systems must establish and document a post-market monitoring system proportionate to the system's nature and risks. For medical AI, this overlaps with the MDR PMS plan; you build one system that feeds both.

Article 73 - serious incident reporting

Providers must report serious incidents to market surveillance authorities. For medical AI, this overlaps with MDR vigilance reporting and the CRA 24/72/14 cadence.

Substantial modification

EU AI Act requires re-conformance if the system undergoes a "substantial modification" that affects compliance with Article 15 (or other Section 2 requirements). This is the EU analogue to the FDA's PCCP question.

The FDA side

Section 524B applies

If the AI/ML SaMD meets the Section 524B(c) cyber-device definition - and almost all do - the full 524B premarket package applies (see our FDA Premarket Cybersecurity Submission Checklist). The February 2026 final guidance does not carve out AI/ML; it adds expectations.

AI/ML SaMD framework

The FDA's AI/ML SaMD framework (Action Plan, 2021; SaMD Pre-Specifications guidance) anticipates that models change. The framework introduces:

• SaMD Pre-Specifications (SPS) - the anticipated modifications you plan to make.
• Algorithm Change Protocol (ACP) - how you'll evaluate and control those modifications.
• Predetermined Change Control Plan (PCCP) - the formal artifact you submit that combines SPS + ACP and binds you to a specific change-control approach.

PCCP and cybersecurity

The PCCP is where AI/ML cybersecurity gets specific. A PCCP that covers model updates must specify:

• How retrained models are validated for adversarial robustness (not just accuracy).
• How the SBOM and model card update with each release.
• How signing, integrity protection, and rollback work for model artifacts.
• How drift monitoring triggers a retraining cycle vs. a postmarket safety notification.

A PCCP that ignores cybersecurity is a deficiency magnet.

Pen testing scope for AI/ML

For AI/ML SaMD, the FDA-required third-party pen test must include AI-specific scenarios:

• Adversarial input crafting against the deployed model.
• Model extraction attempts via the inference API.
• Prompt injection (for LLM-based systems).
• Input validation under malformed or out-of-distribution data.
• Authentication and authorization on model update endpoints.

A pen test that only covers network/web/protocol surfaces and ignores the model is not a complete AI/ML pen test.

Postmarket: drift monitoring

The FDA postmarket plan for AI/ML SaMD must include drift monitoring - statistical surveillance of inputs and outputs to detect distribution shift. Drift can be benign (population change) or adversarial (poisoning at inference time). Your monitoring must distinguish.

Side-by-side: AI/ML cybersecurity deliverables

Build sequence for dual-market AI/ML SaMD

1. Build the threat model with AI-specific threats from day one. STRIDE plus ML-specific extensions (LINDDUN for privacy, MITRE ATLAS for AI-system attacks).
2. Lock training data lineage as a controlled artifact. Dataset versioning, integrity hashes, provenance documentation. Satisfies Article 10 and FDA design controls.
3. Design the PCCP to satisfy both regimes. A well-written PCCP doubles as the EU "substantial modification" control by defining what is in-scope (no re-conformance needed) and what is out-of-scope (substantial modification, re-conformance / new 510(k) submission).
4. Scope the pen test to include AI-specific scenarios. Adversarial inputs, extraction attempts, prompt injection, model update endpoint testing.
5. Run drift monitoring in production with two thresholds: statistical drift (retrain trigger) and integrity drift (security incident trigger). The latter feeds your 24/72/14 reporting clock.
6. Maintain a model card alongside the SBOM. Model card covers intended use, training data summary, performance characteristics, known limitations; SBOM covers software components. Both update on every release.

Common AI/ML cybersecurity failure patterns

1. Treating the model as a black box in the threat model. Threat models stop at the API and don't model attacks on the model itself. Both regulators now expect ML-specific threats addressed.

2. PCCP without cybersecurity. PCCP describes the model retraining cadence and validation but ignores the cybersecurity implications of releasing new model weights. PCCP is a security artifact, not just a performance artifact.

3. Drift = retrain only. Postmarket plan treats every drift signal as a retraining trigger. Adversarial drift is a security incident with a reporting clock - your monitoring must classify.

4. Training data not under change control. Training data lives in a data scientist's notebook, not the QMS. Article 10 and FDA design controls both expect documented lineage and integrity.

5. Generic web-app pen test. Pen test report covers the inference API as a web service but does no adversarial input testing or model extraction attempts. Not a complete AI/ML pen test.

FAQ

Does the EU AI Act apply on top of MDR?

Yes. For medical AI, both regulations apply. The AI Act layers additional obligations (Article 10 data governance, Article 15 robustness/cybersecurity, Article 72 monitoring, Article 73 reporting) on top of MDR/IVDR. The conformity assessment under MDR is the gateway; AI Act requirements are folded into the technical documentation.

Do I need a PCCP for the EU?

The EU doesn't have a PCCP construct, but the underlying need is the same: define which model changes are pre-authorized vs. which trigger re-conformance ("substantial modification"). A PCCP written for the FDA, with the substantial-modification thresholds called out, satisfies both.

What's MITRE ATLAS and should I use it?

MITRE ATLAS is the adversary tactics and techniques knowledge base for AI systems - the AI analogue of MITRE ATT&CK. It's the most actionable framework for building an AI-specific threat model. Neither regulator mandates it; both accept it.

Is ISO/IEC 42001 mandatory?

Not yet, but it's becoming the reference AI management system standard. Expect Notified Bodies to look for it (or NIST AI RMF, its U.S. analogue) as evidence of an AI governance program.

How do I test for adversarial robustness?

For image models: project gradient descent (PGD), FGSM, AutoAttack against the deployed model. For text/LLMs: prompt injection benchmarks, adversarial suffixes. For tabular: feature perturbation under model-specific constraints. The pen test report should include scope, methodology, and results - not just "we tested adversarial robustness."

What's the FDA postmarket reporting trigger for AI drift?

The FDA hasn't published a specific drift threshold. The expectation is that your postmarket plan defines the trigger - what statistical drift requires a notification, what counts as a reportable event under 21 CFR Part 803. Define it explicitly; reviewers will read it.

Where this fits in our content

• SaMD Cybersecurity Requirements - the base SaMD layer.
• FDA Premarket Cybersecurity Submission Checklist - the 524B baseline.
• EU MDR vs FDA Medical Device Cybersecurity - the non-AI dual-market crosswalk.
• STRIDE Threat Modeling for Medical Devices - extend with MITRE ATLAS for AI.
• ai-samd.com - community-sponsored AI-SaMD lifecycle reference.
• GMLP Controls Crosswalk for Medical Devices - each GMLP principle mapped to engineering controls.
• AAMI CR515:2025 and ML device cybersecurity - the ML threat catalog behind both regimes.

How Blue Goat Cyber helps

We build cybersecurity programs for AI/ML SaMD teams filing in the U.S., the EU, or both, and the dual-market work is mostly about generating one evidence set that satisfies two different review styles.

• Threat models that include the model. Training data poisoning, model extraction through the inference API, adversarial input crafting, and prompt or feature manipulation are enumerated as threats with owners, not mentioned as an AI caveat.
• Adversarial and conventional testing in one scope. The pen test covers the application and infrastructure; a separate work package probes model-specific behavior, including input perturbation and inference-boundary abuse, with results written into the same threat table.
• PCCP authoring that survives both regimes. The FDA wants bounded modifications with a validation protocol; the AI Act wants documented post-market monitoring of substantial modification. We write the plan once and present it twice.
• Drift-aware postmarket monitoring. Performance drift and security monitoring share one intake, because a degradation report and an exploitation report can look identical for the first 48 hours.

See FDA premarket cybersecurity services and EU Cyber Resilience Act services.

Sources & primary references

• Regulation (EU) 2024/1689 - Artificial Intelligence Act
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final guidance, February 2026)
• FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence/Machine Learning (AI/ML)-Enabled Device Software Functions (final guidance, 2024)
• FDA, Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) Action Plan (2021)
• Section 524B of the Federal Food, Drug, and Cosmetic Act
• MDCG 2019-16 Rev.1 - Guidance on Cybersecurity for Medical Devices
• NIST AI 100-1 - Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• MITRE ATLAS - Adversarial Threat Landscape for Artificial-Intelligence Systems
• ISO/IEC 42001:2023 - Information technology - Artificial intelligence - Management system

Free tools for this

• AI/ML Submission Timeline - sequence the AI/ML cybersecurity work from premarket through postmarket.
• AAMI CR515 Crosswalk - map CR515 clauses to GMLP, PCCP, AIBOM, and Section 524B evidence.