Modernizing legacy medical device software without re-triggering a full re-verification
Practice · Legacy Modernization
Every third-party or legacy component in a medical device is SOUP (Software of Unknown Provenance) under IEC 62304 until its SOUP evaluation is done, and modernization runs through 2 clauses, §6.1's software maintenance plan and §8.1.2's SOUP identification, so an unmaintained SOUP component with a known anomaly is a release blocker, not a line item to revisit later.
How do you modernize legacy device software without full re-verification?
Every third-party or legacy component is SOUP under IEC 62304 until its SOUP evaluation is done. Modernization evaluates and replaces SOUP inside documented architectural boundaries, so a change does not re-trigger verification of unaffected safety-classified units.
Modernization work succeeds by evaluating and replacing SOUP inside documented architectural boundaries, so a change doesn't re-trigger verification for unaffected safety-classified units.
SOUP is a documented evaluation, not a label
For MedTech device software, IEC 62304 Clause 8.1.2 requires that every SOUP item — any software component not developed under the same lifecycle process, including open-source libraries, legacy in-house modules with no surviving records, and third-party SDKs — have its title, manufacturer, version, relevant functional/performance requirements, and known anomalies documented in a SOUP evaluation, with an assessment of whether those anomalies could contribute to a hazardous situation.
The remediation triage that actually works
- Can it be upgraded without re-triggering full-system re-verification? Check the blast radius against the architecture's documented interfaces — a component isolated behind a stable interface can often be swapped with unit + integration re-verification only, not a full system re-test.
- If not upgradable, is the anomaly's risk contribution acceptable? This requires a documented rationale in the risk analysis, not an informal "it's been fine so far."
- If neither holds, it's a release blocker — not a backlog item.
Why architecture boundaries determine modernization cost
The Bare Metal fieldbook's brownfield-migration guidance applies directly here: a legacy component with a narrow, well-defined interface is cheap to replace because re-verification scope is bounded by that interface. A legacy component with informal, undocumented coupling to the rest of the system is expensive to replace precisely because nobody can bound what re-verification the change actually requires — the architecture itself is the cost driver, not the age of the code.
SOUP evaluation ledger
A working template — one row per component, generated below.
Component | Version | Supplier | Known anomalies | Safety impact | Verification approach | Status
----------|---------|----------|-----------------|----------------|------------------------|-------
(one row per SOUP item -- see the downloadable full template)Engineering reference only. Not formal regulatory counsel. Consult IEC 62304 Clause 8.1.2 directly and your own quality system for a specific SOUP evaluation.
Artifact: soup-evaluation-ledger-template.md
Generated client-side; no server round-trip, no account required.
# SOUP Evaluation Ledger (template, v1.0.0)
Software of Unknown Provenance (SOUP) evaluation per IEC 62304 Clause 8.1.2.
Engineering reference template only.
| Component | Version | Supplier/Source | Known anomalies (per Clause 8.1.2) | Safety classification impact | Verification approach | Status |
|---|---|---|---|---|---|---|
| | | | | | | Evaluated / Needs review / Rejected |
## Required per Clause 8.1.2, for every SOUP item
- [ ] Title, manufacturer, and version uniquely identified
- [ ] Functional and performance requirements relevant to safety documented
- [ ] Known anomalies that could contribute to a hazardous situation identified
- [ ] Hardware/software environment requirements for the SOUP item documented
## Remediation triage (for legacy SOUP with unresolved anomalies)
1. Can the component be upgraded without re-triggering full-system
re-verification? (Check the blast radius against the architecture's
documented interfaces.)
2. If not upgradable, is the anomaly's contribution to a hazardous
situation acceptable per the current risk analysis, with a documented
rationale?
3. If neither, the component is a release blocker until replaced or the
risk analysis is formally updated.
Useful next step
Provenance & review state
- Last reviewed
- Sources
-
- IEC 62304:2006+AMD1:2015 Clause 8.1.2 — International Electrotechnical Commission
- ISO 14971:2019 — International Organization for Standardization
- Ingested from
-