On this page
Key Takeaways
- CR515:2025 is a consensus report (a CR), not a standard. You cannot declare conformity to it the way you can to IEC 62304 or IEC 81001-5-1. Cite it as the method behind your ML threat model, not as a certification.
- Its core contribution is the ML threat catalog: poisoning, evasion, inversion, membership inference, model extraction, and pipeline compromise. Generic STRIDE threat modeling misses all six.
- CR515 is additive to ANSI/AAMI SW96:2023, not an alternative. SW96 expresses security risk in patient-harm terms; CR515 tells you which ML-specific threats belong in that analysis.
- The model, its weights, its training and evaluation datasets, and its inference runtime are the assets CR515 protects. That inventory is your AIBOM, which is why the two documents only work together.
- Every model change your PCCP permits is a change to the attack surface CR515 describes. Retraining triggers a threat model review, not just a performance review.
AAMI CR515:2025 is AAMI's consensus report on cybersecurity for machine learning-enabled medical devices. It adds an ML-specific threat catalog (poisoning, evasion, inversion, membership inference, model extraction, pipeline compromise) to the risk method you already run under ANSI/AAMI SW96:2023, and it treats the model, its weights, and its data lineage as protected assets. It is a report, not a conformity-assessable standard, so you cite it as method, not as certification.
Most AI-enabled device submissions carry a threat model that would be equally valid if the device contained no model at all. It enumerates network interfaces, update channels, and stored credentials, and it says nothing about the thing the device actually is. CR515 exists to close that gap.
Last reviewed: September 2026 against the FDA February 3, 2026 final premarket cybersecurity guidance, the FDA PCCP guidance for AI-enabled device software functions, ANSI/AAMI SW96:2023, and AAMI CR515:2025.
Why this matters now
Two things changed at once. Machine learning moved from a differentiator into the core clinical function of a growing share of cleared devices, and the February 3, 2026 final premarket cybersecurity guidance made the threat model the spine of the submission rather than an appendix to it. A reviewer reading an AI-enabled submission now has a specific question in mind: if the model is what makes this device clinically useful, what happens when someone attacks the model?
Until CR515, there was no MedTech-specific document to answer that with. Teams borrowed from MITRE ATLAS, the NIST AI Risk Management Framework, and academic adversarial ML literature, none of which speak the patient-harm language the FDA expects. CR515 is the translation layer.
What CR515 actually is
The full title is Cybersecurity considerations unique to machine learning-enabled medical devices. AAMI published it on June 23, 2025, and the FDA added it to the Recognized Consensus Standards database in March 2026, listing it as the consensus report addressing cybersecurity threats unique to developing and deploying ML-enabled devices. Recognition is the reason it is now worth citing by name: a reviewer will know the document.
CR515:2025 is an AAMI consensus report. The distinction matters more than it sounds:
| Document class | Example | What you can claim |
|---|---|---|
| Statute | FD&C Act Section 524B | Compliance is mandatory for cyber devices |
| Consensus standard | IEC 62304, IEC 81001-5-1, ANSI/AAMI SW96:2023 | Declaration of conformity, clause-by-clause |
| Consensus report (CR) / TIR | AAMI CR515:2025, AAMI TIR57, AAMI TIR97 | "Our method follows the approach described in..." |
A consensus report captures the state of practice where the committee judged that requirements-language was premature. There are no shall-statements to audit against, no clause matrix to fill in, and no conformity assessment. What there is: a shared vocabulary and a threat taxonomy that a reviewer will recognize.
That is worth a great deal in a submission. A threat model that says "we assessed adversarial evasion, model inversion, and training-pipeline poisoning per the approach in AAMI CR515:2025" lands very differently from one that invents its own categories.
The ML threats generic threat modeling misses
This is the substance of CR515 and the reason a separate document was needed. A STRIDE pass over a system diagram surfaces spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege at trust boundaries. It does not surface any of the following, because none of them cross a conventional trust boundary:
Training data poisoning. An attacker who can influence what enters the training set can install behavior that survives every functional test. In MedTech this is rarely a movie-plot attacker; it is far more often an unvalidated data pipeline, a mislabeled contributed dataset, or a site whose export process changed without notice.
Adversarial evasion. Inputs perturbed so that the model's output flips while a clinician sees nothing unusual. The clinical consequence is a false negative or false positive that the device reports with full confidence.
Model inversion. Repeated querying used to reconstruct characteristics of the training data. When the training data is patient imaging or records, this is a confidentiality failure with regulatory consequences beyond the device file.
Membership inference. Determining whether a specific patient's record was in the training set. Lower impact than inversion, materially easier to execute, and a real privacy exposure.
Model extraction and weight theft. The weights are frequently the most valuable asset the company owns and are frequently shipped to the edge with less protection than the firmware around them.
Pipeline and supply chain compromise. Pretrained base models pulled from public hubs, unpinned framework versions, unsigned weight files, and training infrastructure outside the quality system. This is where the SBOM and AIBOM conversation and the CR515 conversation meet.
Drift as a safety, not security, event that looks identical from the outside. CR515 is useful here precisely because it forces the team to distinguish degradation from attack, which requires monitoring that can tell them apart.
How CR515 extends SW96 rather than replacing it
ANSI/AAMI SW96:2023 is the security risk management method: it substitutes exploitability for probability of occurrence and drives every security risk down to the patient-harm severity scale inherited from ISO 14971 and the device's essential performance. It is method-complete and threat-agnostic. It never tells you what to be afraid of.
CR515 supplies exactly that missing input for ML devices. The workflow:
- Enumerate the ML assets (model, weights, datasets, pipeline, runtime). This is the AIBOM.
- Apply the CR515 threat catalog to each asset.
- Score each resulting threat through the SW96 exploitability and patient-harm columns.
- Design controls, then re-score residual risk.
- Feed the controls that constrain future model changes into the PCCP.
Do not start a second threat model. One threat model, extended with ML asset rows and ML threat categories, is what reviewers want to read. Two parallel documents guarantee they disagree with each other by the second submission.
Model artifacts as inventory: the AIBOM link
Every threat in the CR515 catalog attaches to an asset, and an asset you have not inventoried is one you cannot assess. That inventory is the AI bill of materials: model artifacts and hashes, weights and checkpoints, training and evaluation datasets with provenance, frameworks and inference runtimes, preprocessing code, and any hosted or third-party model the device calls.
The practical consequence: the AIBOM is not documentation overhead added after the threat model. It is the asset register the threat model is built on, and it is the same artifact that makes a PCCP auditable, because without a versioned inventory you cannot demonstrate which model the cleared device shipped with. See AIBOM for medical devices for the field-level detail and the CycloneDX ML-BOM and SPDX 3.0 AI profile formats.
The CR515, GMLP, PCCP, and 524B interlock
Four documents, four jobs, one file. This is the mental model to carry into a submission:
| Layer | Document | Question it answers |
|---|---|---|
| Statutory obligation | FD&C Act Section 524B | Are we a cyber device, and have we produced the plan, the SBOM, the reasonable-assurance argument, and the postmarket process? |
| Lifecycle quality | Good Machine Learning Practice (GMLP) | Are the data, training, evaluation, and monitoring practices behind this model sound and evidenced? |
| Threat method | AAMI CR515:2025 (+ SW96 for scoring) | What can go wrong with the model, and what is the patient harm if it does? |
| Asset inventory | AIBOM (inside the SBOM) | What exactly is in this model, and which version shipped? |
| Change governance | PCCP | Which model changes can we make post-clearance without a new submission, and what keeps them safe? |
Read across the table and the dependency chain is obvious. GMLP without a threat model is quality without security. A threat model without an AIBOM is assessment without assets. A PCCP without either is a promise you cannot audit. Section 524B is the obligation all of it discharges.
Depth on each layer:
- GMLP controls crosswalk for medical devices - each GMLP principle mapped to an engineering control and its evidence.
- FDA PCCP and change control plans - how to scope modifications so the plan survives review.
- AIBOM for medical devices - the inventory format and minimum fields.
- The MedTech cybersecurity standards decoder - where CR515 sits in the wider standards chain.
- SaMD cybersecurity requirements - the baseline package before any ML content is added.
- EU AI Act vs FDA AI/ML cybersecurity - the same evidence presented to a second regulator.
To see the mapping row by row for your own device, the CR515 crosswalk tool lets you filter the CR515 topic areas against GMLP, PCCP, AIBOM, and Section 524B and export the result as a PDF or CSV for your design history file.
What you can and cannot claim in a submission
Be precise here, because overclaiming against a consensus report is an easy deficiency to earn.
You can say: our ML threat model follows the approach described in AAMI CR515:2025; the threat categories in Section X of our threat model are drawn from it; our ML asset inventory reflects its asset taxonomy.
You cannot say: the device conforms to AAMI CR515:2025; we are certified to CR515; CR515 conformity satisfies Section 524B. None of these are available claims for a consensus report, and the last one is wrong on its face because 524B is statute.
The practical framing that works: treat CR515 as the reason your threat model contains the rows it contains. The evidence a reviewer evaluates is still the threat model, the security risk analysis, the controls, and the test results. CR515 is why those artifacts have the shape they do.
How Blue Goat Cyber approaches ML device threat modeling
We run ML devices through one extended threat model rather than a bolt-on. The ML asset register is built first, from the AIBOM, so that every model artifact, dataset, and runtime is a named asset before any threat is written. The CR515 catalog is then applied asset by asset, and each surviving threat is scored through the SW96 exploitability and patient-harm columns so that the output is in the language the file already speaks.
Penetration testing for these devices includes adversarial input testing against the deployed inference path, not just the network surface around it, and the model artifact handling (signing, integrity verification at load, protection of weights at rest) is tested as an explicit control rather than assumed. Where a PCCP is planned, we work the change-control boundary from the threat side: which permitted modifications alter the attack surface, and what monitoring detects it when they do.
The deliverables land as sections of the existing submission package. Nothing here is a separate document that a reviewer has to reconcile against your main file.
Frequently asked questions
Is AAMI CR515:2025 mandatory?
No. It is a consensus report and carries no statutory force. What is mandatory for a cyber device is FD&C Act Section 524B: a cybersecurity plan, an SBOM, a reasonable-assurance argument, and postmarket monitoring and patching. CR515 helps you produce a threat model strong enough to support the reasonable-assurance argument for an ML-enabled device.
Can we declare conformity to CR515 in our submission?
No. Consensus reports and technical information reports have no shall-statements and no conformity assessment path. Reference it as the method your threat model follows. Declaring conformity to a document that cannot be conformed to invites a reviewer question you gain nothing from.
Does CR515 replace ANSI/AAMI SW96:2023?
No, and the two are not alternatives. SW96 is the security risk management method that expresses risk in patient-harm terms. CR515 is the ML threat catalog that feeds that method. Use both: CR515 to identify, SW96 to score.
Do we need a separate ML threat model?
No. Extend the existing one. Add the ML assets to the asset register and the ML threat categories to the analysis. Two documents drift apart, and reviewers notice when the system threat model and the ML threat model describe different architectures.
How does CR515 affect our PCCP?
Directly. Each modification your PCCP permits changes the model, and therefore changes the attack surface CR515 describes. The PCCP should state which permitted changes trigger a threat model review and what verification runs before the updated model reaches devices in the field.
What if we use a third-party or foundation model?
Then the model is a supplied component and the supply chain threats in the catalog become the dominant ones: provenance of the weights, integrity verification, version pinning, and what happens when the vendor changes the model behind an API. The component belongs in the AIBOM with its vendor, identifier, and version strategy recorded.
Does the FDA recognizing a document change what we have to do?
The FDA added CR515:2025 to the Recognized Consensus Standards database in March 2026. Recognition means a reviewer will recognize the reference and that citing it is a defensible shortcut through explaining your method from first principles. It does not convert a report into a requirement, and because there are no shall-statements, it does not create a declaration-of-conformity path the way recognition of IEC 62304 or IEC 81001-5-1 does.
Talk to us about your ML-enabled device
If your device's clinical function depends on a model and your threat model does not mention the model, that gap will surface in review. We build the ML asset register, run the CR515 threat catalog against it, score it through SW96, and hand back sections that drop into the submission you are already assembling.
Book a strategy session to scope it against your timeline.
Sources
- AAMI, CR515:2025, Cybersecurity considerations unique to machine learning-enabled medical devices (published June 23, 2025)
- FDA, Recognized Consensus Standards database entry for AAMI CR515:2025 (recognized March 2026)
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (final, February 3, 2026)
- ANSI/AAMI SW96:2023, Standard for medical device security: Security risk management for device manufacturers
- FDA / Health Canada / MHRA, Good Machine Learning Practice for Medical Device Development: Guiding Principles (October 2021)
- FD&C Act Section 524B (21 U.S.C. 360n-2)
