A machine learning model in a medical device is expected to change after clearance, and every change that is not planned, validated and controlled in advance can force a new FDA submission or put patients at risk. FDA has answered that with two documents: final guidance on Predetermined Change Control Plans (PCCPs) for AI-enabled device software functions, and draft guidance on lifecycle management and marketing submissions for those functions. Together they tell manufacturers what to document about data, models, validation, performance monitoring and cybersecurity, and how to pre-authorise future model updates. This guide explains scope, the key recommendations, current status, what happens when a manufacturer goes outside an authorised plan, and what the lifecycle approach means for the pipelines, service accounts and update credentials that change a model. It is for regulatory affairs, product security, ML engineering and quality teams at device manufacturers. For the statutory cybersecurity requirements under section 524B of the FD&C Act, read the FDA Medical Device Cybersecurity Guide first; this page does not repeat it.
Key takeaways
- The PCCP guidance is final. FDA's document on PCCPs for AI-enabled device software functions was originally issued on 4 December 2024 and reissued on 18 August 2025, as guidance for industry and FDA staff.
- The lifecycle guidance is still a draft. "Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations" (docket FDA-2024-D-4488, January 2025) is marked "Not for implementation" on FDA's page, checked 27 October 2026.
- A PCCP has three parts. A Description of Modifications, a Modification Protocol and an Impact Assessment, submitted as a standalone, versioned section of a 510(k), De Novo or PMA.
- Section 515C is the legal basis. Added by FDORA on 29 December 2022, it means a change consistent with an authorised PCCP needs no new 510(k) or PMA supplement; a change outside it generally does.
- The update pipeline is part of the device. Training data, re-training jobs and the credentials that sign and deploy model updates decide whether a modification is the one FDA authorised.
Scope: who and what is covered
Both documents apply to device software functions that implement one or more AI models, which FDA calls AI-enabled device software functions (AI-DSFs). That includes software as a medical device and software in a medical device, whether the model is locked or updated over time.
| Document | Status (checked 27 Oct 2026) | What it covers |
|---|---|---|
| Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions | Final guidance; issued 18 August 2025, originally issued 4 December 2024; nonbinding recommendations | What to include in a PCCP, which submissions can carry one, labelling, and how modifications are implemented under the quality system |
| Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations | Draft guidance, January 2025, docket FDA-2024-D-4488; "Not for implementation"; comments accepted at any time under 21 CFR 10.115(g)(5) | Contents of marketing submissions for AI-DSFs, a total product life cycle (TPLC) approach to risk, and optional design and development recommendations |
| Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices: Guiding Principles | Joint principles from FDA, Health Canada and the UK MHRA | Five principles: focused and bounded, risk-based, evidence-based, transparent, TPLC perspective |
| Artificial Intelligence-Enabled Medical Devices list | Updated periodically; FDA says it is not comprehensive | Authorised devices identified through AI-related terms in summaries and classifications; FDA says it will explore tagging devices that incorporate foundation models, including LLM functionality |
- Submission types for a PCCP: traditional and abbreviated 510(k); original De Novo requests; original and modular PMA, 180-day and panel-track supplements, and in some cases real-time supplements. A PCCP cannot be authorised through a Pre-Submission, although FDA encourages early feedback through the Q-Submission Program.
- Who acts on it: the manufacturer (sponsor) of the device. Hospitals deploying AI devices are not regulated by these documents, but labelling, performance information and update notices are written for them.
- Cyber devices: most AI-DSFs connect to networks or receive updates, so section 524B also applies to their submissions. See the FDA Medical Device Cybersecurity Guide.
Key obligations
The three components of a PCCP
| Component | What FDA asks for | Security and integrity angle |
|---|---|---|
| Description of Modifications | The specific planned changes, their characteristics and performance specifications, whether each is implemented automatically or manually, and whether it is global (all devices) or local (specific sites or users) | Automatic and local changes widen the set of systems and identities that can alter a deployed model; each needs its own control story |
| Modification Protocol | How each change is developed, validated and implemented: data management, re-training, performance evaluation and update procedures, with pre-defined acceptance criteria | Data provenance, segregation of training and test data, and an authenticated update path are where tampering would show up |
| Impact Assessment | Benefits and risks of the planned changes, including their combined effect, and the risk mitigations | Include cybersecurity risk from the change process itself, not only clinical performance risk |
Boundaries FDA sets on PCCPs
- Specific and verifiable: modifications must be specific enough to verify and validate, and keep the device within its intended use and generally its indications for use.
- Typical content: performance improvements from re-training on new data from the same intended population, certain input-related changes, and certain use-related changes such as authorisation for a subpopulation.
- Not a catch-all: changes that would not otherwise need a submission do not belong in a PCCP, some modifications are not appropriate for any device, and changing the authorised PCCP itself generally needs a new submission.
- Labelling: state that the device has an authorised PCCP, explain that it uses machine learning and that updates may change performance, inputs or use, update labelling as changes are implemented, and never describe changes that have not been implemented.
- Quality system: implement each change under the manufacturer's quality system and document it, including in the device master record.
What the draft lifecycle guidance asks a submission to contain
| Draft section | Content | Practical note |
|---|---|---|
| V Device Description; VI User Interface and Labeling | What the AI-DSF does, inputs and outputs, how users interact with it | Model role and automation level drive risk |
| VII Risk Assessment | TPLC risk management for the AI function | Link safety and security risk files |
| VIII Data Management | Data collection, quality, representativeness, separation of development and validation data (to avoid data leakage and overfitting); data storage should ensure security as addressed in Section XII | Training data stores are high-value targets; control who can write to them |
| IX Model Description and Development | Model architecture and training; points to the PCCP guidance and recommends early Q-Submission discussion for models that update automatically or continuously | Record model versions and the identities that produced them |
| X Validation | Performance validation of the AI-DSF | Validation data must stay independent of training data |
| XI Device Performance Monitoring | Monitoring for performance change, including shifts in input data, data drift, and input data integrity problems such as missing values, duplicate records and data type mismatches; plan kept in the Risk Management File | The same monitoring can surface pipeline tampering |
| XII Cybersecurity | A dedicated cybersecurity section for AI-enabled devices | Read alongside the 524B premarket guidance |
| XIII Public Submission Summary | Information for the public summary of the authorisation | Feeds FDA's transparency aims |
Because the draft may change before it is finalised, treat its section structure as FDA's current thinking rather than fixed requirements, and check FDA's guidance page before each submission.
Timeline and current status
| Date | Event |
|---|---|
| 29 December 2022 | FDORA adds section 515C to the FD&C Act, creating the statutory basis for PCCPs |
| 4 December 2024 | Final PCCP guidance for AI-enabled device software functions first issued |
| January 2025 | Draft lifecycle management and marketing submission guidance published (docket FDA-2024-D-4488) |
| 18 August 2025 | PCCP guidance reissued |
| 27 October 2026 (date checked) | Lifecycle guidance still shown as draft on FDA's page; PCCP guidance final |
Guidance documents represent FDA's current thinking and do not create binding obligations, but reviewers use them to decide whether a submission is complete. Sections 515C and 524B are statute.
Enforcement and penalties
Neither guidance sets penalties of its own. The consequences flow from the premarket framework:
- Outside the plan: the PCCP guidance treats implementing a modification by methods other than those in the PCCP, or failing its acceptance criteria, as a deviation that typically requires a new marketing submission.
- Change without authorisation: a significant change to a cleared or approved device that is not covered by an authorised PCCP or a new submission leaves the device marketed without the required authorisation, which exposes the manufacturer to FDA enforcement under the FD&C Act.
- Incomplete submissions: missing AI documentation or cybersecurity content can lead to additional information requests and delays; for cyber devices, section 524B documentation is mandatory. See the FDA Medical Device Cybersecurity Guide for that regime.
What it means for AI agents and non-human identities
An AI-DSF update is executed by machines: data ingestion jobs, training pipelines, model registries, signing services and device update servers. Each runs under a non-human identity, and each could introduce a modification FDA never authorised.
| Pipeline stage | Identity involved | Control that supports the PCCP |
|---|---|---|
| Training data ingestion | Service accounts and API keys for data sources and storage | Write access limited to the ingestion job; provenance records; alerts on out-of-pipeline writes |
| Re-training and evaluation | CI/CD runners and workload identities | Short-lived credentials; pinned dependencies; validation results bound to the model version |
| Model registry and approval | Release engineers and automated promotion jobs | Separation of duties so the job that trains cannot approve; acceptance criteria enforced as a gate |
| Signing and release | Code and model signing keys | Keys in an HSM or managed KMS, signing restricted to the release identity, signatures verified on device |
| Deployment to devices | Update server credentials and device identities | Mutual authentication, per-device certificates, rollback capability to the last authorised model |
If an AI agent or LLM assists with data labelling, code changes or evaluation, its access is part of the modification protocol too: scope its credentials to the tasks the protocol describes and log its actions. See the AI Model Provenance and Watermarking Guide and the CI/CD Pipeline Identity Security Guide.
Compliance steps
- Classify the AI functions: list every AI-DSF, whether it is locked or updated, and whether planned changes are automatic or manual, global or local.
- Decide on a PCCP: use one where you can specify modifications precisely and validate them against pre-defined criteria; discuss continuously learning models with FDA early through a Q-Submission.
- Write the three components: Description of Modifications, Modification Protocol and Impact Assessment, as a standalone, titled and versioned section.
- Map the draft submission sections: build data management, model, validation, performance monitoring and cybersecurity content even while the lifecycle guidance is draft, and align cybersecurity with 524B.
- Secure the change pipeline: inventory the non-human identities and keys that touch data, models and updates; apply least privilege and signing; keep the audit trail in the quality system.
- Test the rollback: show that a modification failing acceptance criteria can be reverted, as the guiding principles expect.
- Operate: implement each change under the quality system, update the device master record and labelling, and monitor performance and input integrity after release.
- Review status: check FDA's guidance pages before each submission for finalisation or revisions.
Framework mapping
| FDA expectation | Related framework | Reference |
|---|---|---|
| Data management and integrity | NIST SP 800-53 Rev. 5 | SI-7 Software, Firmware, and Information Integrity; SR-4 Provenance |
| Controlled implementation of modifications | NIST SP 800-53 Rev. 5 | CM-3 Configuration Change Control; CM-14 Signed Components |
| Pipeline and update identities | NIST SP 800-53 Rev. 5 | AC-6 Least Privilege; IA-9 Service Identification and Authentication |
| Performance monitoring | NIST SP 800-53 Rev. 5 | SI-4 System Monitoring |
| AI-specific threats to training and models | MITRE ATLAS | AML.T0020 Poison Training Data; AML.T0018 Manipulate AI Model |
Metrics
- Plan conformance: share of released model updates traced to a PCCP modification and passing all acceptance criteria (target 100 percent).
- Deviation rate: modifications found outside the PCCP methods per year.
- Pipeline credential hygiene: percentage of pipeline identities using short-lived credentials, and signing keys held in hardware.
- Rollback time: time to revert a field model to the last authorised version.
- Monitoring coverage: devices reporting input integrity and performance metrics.
Practitioner checklist
- Confirm the current status of both FDA documents on FDA's guidance pages before drafting a submission.
- Write the PCCP as a standalone, versioned section with all three components and pre-defined acceptance criteria.
- Keep every planned modification within the intended use and specific enough to verify and validate.
- Separate development and validation data and control who can write to each store.
- Inventory the service accounts, workload identities and keys in the data, training, signing and update pipeline.
- Sign models and verify signatures on the device; keep signing keys in hardware.
- Monitor deployed performance and input data integrity, and test rollback to the last authorised model.
- Align the AI cybersecurity section with the 524B premarket evidence and update labelling as changes ship.
Standards and references
- FDA: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions
- FDA: Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations (draft)
- FDA: Lifecycle Management draft guidance document
- FDA, Health Canada and MHRA: Predetermined Change Control Plans for Machine Learning-Enabled Medical Devices: Guiding Principles
- FDA: Artificial Intelligence-Enabled Medical Devices
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATLAS: Training Data Poisoning
Related NHI Mgmt Group resources: FDA Medical Device Cybersecurity Guide · AI Model Provenance and Watermarking Guide · CI/CD Pipeline Identity Security Guide · Medical Device Security Guide. This guide summarises FDA guidance on AI-enabled device software functions and is not legal or regulatory advice.