About this example
This is a fictional device with invented IDs. It is not a client project and makes no claim about any FDA decision. It shows how each planned change in a PCCP links to the threat model, the security risk assessment, and the tests that prove the change is still secure. For the document format behind it, see the PCCP cybersecurity appendix.
1. The device
| Device | CardioPatch (fictional): a wearable ECG patch that flags possible atrial fibrillation |
|---|
| Parts | Patch with Bluetooth Low Energy, patient phone app, cloud service, and a clinician web portal |
|---|
| Software | On-patch firmware, an AI detection model running in the cloud, phone app, and web portal |
|---|
| Worst credible harm | A missed or false atrial fibrillation alert that delays or misdirects care |
|---|
| Pathway | 510(k) for a cyber device under FDA Section 524B, with a PCCP included |
|---|
2. Description of Modifications: the planned changes
The plan groups changes into four classes. Each class has an ID that the rest of the plan refers back to.
- MC-01, AI model retraining: Retrain the detection model on new labeled ECG data, same inputs, outputs, and intended use.
- MC-02, Cryptographic library update: Minor or patch updates to the TLS and crypto library in the phone app and cloud service.
- MC-03, Patch firmware security fix: Firmware fixes for known vulnerabilities in the Bluetooth stack or real-time operating system, with no new features.
- MC-04, Cloud operating system and container updates: Routine base image and operating system updates for the cloud service.
3. Impact Assessment and Modification Protocol, class by class
For each class: what it touches in the threat model, which threats could change, the risk impact traced to the ISO 14971 file, the tests, the pass criteria, and what takes the change outside the plan.
MC-01: AI model retraining
- Threat model elements
- Cloud training pipeline (DF-6), model storage (DS-3), model deployment to the inference service (DF-7).
- Threats that could change
- T-21 poisoned training data, T-22 swapped or tampered model file, T-23 unauthorized model deployment.
- Risk impact
- Integrity loss could cause missed or false alerts (harm H-02). Severity unchanged; exploitability must stay at or below the current rating.
- Security tests
- Data source provenance check; model file signature verified at deployment; access review of who can approve a release; security regression tests for T-21 to T-23.
- Pass criteria
- All training data from approved sources with logged provenance; unsigned or mismatched model rejected in test; only named release approvers can deploy.
- Outside the plan if
- New data type, new input such as a second sensor, or any change to intended use.
MC-02: Cryptographic library update
- Threat model elements
- Phone app to cloud link (DF-3), portal to cloud link (DF-5); entry points EP-3 and EP-5.
- Threats that could change
- T-07 spoofed cloud endpoint, T-11 session hijack, T-12 downgrade to a weak cipher.
- Risk impact
- Exploitability may drop (fixes) or rise (changed defaults). Harms H-03 and H-05 unchanged.
- Security tests
- SBOM diff and vulnerability check; TLS configuration scan; regression tests for T-07, T-11, and T-12.
- Pass criteria
- No new high or critical vulnerability; TLS 1.2 or later only; certificate checks still enforced; all regression tests pass.
- Outside the plan if
- Major version change, new cipher suites, or any change to how certificates or logins work.
MC-03: Patch firmware security fix
- Threat model elements
- Patch to phone link (DF-1), firmware update path (DF-2); entry points EP-1 and EP-2.
- Threats that could change
- T-02 unauthenticated pairing, T-04 malicious firmware image, T-05 Bluetooth denial of service.
- Risk impact
- Availability loss could stop recording (harm H-01). A bad update could brick patches across the fleet, so the multi-patient view applies.
- Security tests
- Firmware signature and rollback protection tests; Bluetooth fuzz regression; staged rollout check; SBOM diff.
- Pass criteria
- Unsigned or older firmware refused; no crash or lockup in fuzz regression; recording resumes after update; staged rollout halts on error.
- Outside the plan if
- New Bluetooth services or characteristics, a new radio, or changes to the update or signing process.
MC-04: Cloud operating system and container updates
- Threat model elements
- Cloud hosting environment (trust boundary TB-3), data store DS-2.
- Threats that could change
- T-15 exposed patient data, T-16 privilege escalation in the cloud service.
- Risk impact
- Mostly confidentiality (privacy harm H-06) and availability of alerts to clinicians (H-04).
- Security tests
- Container image scan; configuration baseline check; access control regression; restore test from backup.
- Pass criteria
- No new high or critical finding; baseline unchanged; restore completes within the stated recovery time.
- Outside the plan if
- Moving to a new cloud provider or region, or adding a new outside service that handles patient data.
4. Triggers for a full reassessment
Any of these sends the change back to the full threat model and risk assessment instead of the PCCP route:
- A new entry point, interface, or trust boundary
- A new type of data, or patient data going to a new place
- A change to authentication, authorization, or the update signing process
- A residual risk that would no longer meet the acceptance criteria
- A new outside service or component that is not already in the SBOM
5. How it fits with postmarket work
Urgent fixes for newly found vulnerabilities follow the postmarket cybersecurity plan, whether or not they match a PCCP class. Each change released under the plan updates the SBOM, the matching Threat Table rows, and the risk file, and records which tests ran and their results. Labeling and customer notices are updated when the change affects how hospitals set up or patch the device.
FAQ
- Is this a real client submission?
- No. CardioPatch is a made-up device, and every ID in this example is invented. It shows how we structure the cybersecurity content of a PCCP. It does not describe any client or any FDA decision.
- Which FDA documents does this follow?
- The FDA's December 2024 final PCCP guidance sets out the three parts of a plan: a Description of Modifications, a Modification Protocol, and an Impact Assessment. The FDA's February 3, 2026 premarket cybersecurity guidance sets the security expectations. This example fills in the security content of each part.
- Why are security fixes in a PCCP at all?
- Many vulnerability fixes can ship under your postmarket cybersecurity process without a PCCP. Planned, repeating changes such as library updates and model retraining are where a PCCP helps, because the security tests and limits are agreed up front.
- Can I copy this for my device?
- Use it as a starting point. Your classes, threat IDs, harms, and pass criteria must come from your own threat model and ISO 14971 file. The free PCCP Builder helps with a first draft.
- Does a PCCP written this way get authorized?
- The FDA decides whether to authorize a PCCP. A clear structure makes the security content easier to review, but no format guarantees an outcome.
