Review risk-based update practices and manufacturer evidence. Architecture choices below are planning examples, not universal FDA requirements. Scores cannot establish compliance, risk acceptance, or submission requirements.
Reviewed by
Christian Espinosa
Founder & CEO, Blue Goat Cyber
Update Integrity & Authenticity
What stops a malicious or corrupted update from reaching the device.
Update images are signed with a manufacturer-controlled key
criticalAsymmetric signature, not just a checksum.
Device verifies signature before applying any update
criticalBootloader / OS verifies before commit.
Signing chain anchored in hardware or measured boot
highRoot key in HSM / secure element / TPM.
Signing keys live in an HSM with documented access controls
highNo keys on engineer laptops.
Update Transport & Distribution
How updates get from your build system to the device.
Update server uses mutual TLS or pinned certificates
highServer authenticates the device and vice versa.
Rollback protection (anti-downgrade) is enforced
highMonotonic version counter checked at boot.
Delta or differential updates use the same signing + verification path
mediumDeltas are a common bypass.
Update Deployment & Safety
How updates get applied without harming patients.
A/B (dual-bank) update with automatic rollback on boot failure
criticalDevice never bricks on a bad update.
Update preconditions checked (not in clinical use, battery, network)
highNo updates mid-procedure.
Operator / customer notification and consent workflow exists
mediumPer labeling requirements.
Staged / canary rollout supported
mediumCatch field-only issues before fleet-wide.
Lifecycle & Reporting
Risk-based lifecycle planning practices; individual controls and architectures are not universally prescribed by the FDA.
Documented SLAs for critical / KEV-relevant patch deployment
highAligned to Postmarket Cadence Calculator output.
Per-device update success / failure telemetry collected
highYou can prove fleet status to reviewers.
Audit log of every update (who, what, when, version, signature)
mediumTamper-evident.
Key compromise / revocation playbook exists and has been rehearsed
highIncluding emergency re-signing.
Cyber update support window stated in labeling (with EoS date)
mediumPer §524B and FDA premarket guidance.
What you'll see after you submit
Common misconceptions
Myth: TLS to the update server is enough.
Reality: TLS protects the channel. The FDA expects signature verification of the image itself, plus rollback protection - bytes on the device must be authenticated, not just the transport.
Myth: We don't need A/B partitions because we test thoroughly.
Reality: Field environments differ from labs. A/B partitions are one implementation option. Document recovery and rollback appropriate to the device and clinical risks; the FDA does not universally require dual-bank storage.
Myth: Signing keys can live on the build server.
Reality: Keys on a build server are one CI compromise away from being used to push a malicious update at scale. Consider secure key protection appropriate to the threat model; HSM/KMS and dual-control are examples, not universal FDA-prescribed architectures.
References & further reading
Tracked signals that change what reviewers expect. Items move on as new ones land.
RHEL 7 Extended Life Support phase ends - devices on RHEL 7 need a compensating-controls memo
AI-letter analysis - 62% of FDA cyber deficiencies cite a missing or stale CVD URL
AAMI TIR97:2019 errata published - clarifies postmarket triage SLAs
Draft an optional PCCP for manufacturer review; this questionnaire cannot enforce or authorize one.
Read PCCP BuilderPatch SLAs that go with your update mechanism.
Read Postmarket Cadence CalculatorSupport manufacturer review of remediation urgency using device-specific evidence.
Read Controlled vs Uncontrolled Risk ClassifierRun vulnerability response with the right SLAs in place.
Read Postmarket cybersecurity services