In brief
Medical software increasingly embeds third-party components (SOUP), while expectations around cybersecurity and software supply-chain transparency (SBOM) keep rising, including under the European Cyber Resilience Act (CRA). For many medical device manufacturers, the topic is not only the CE-marked SaMD: a wellness app, patient portal or separately sold SDK may fall under the CRA while the device remains under the MDR. Two regulations, one Git repo, one product team.
This guide offers a practical path: inventory, classification, evidence and team routines, plus a product-by-product reading of the CRA and a mixed MD + wellness portfolio. The goal is to operationalize SOUP and SBOM in your existing flow, with a compliance layer that builds on your tools rather than forcing an ALM migration. This text does not replace the CRA, IEC 62304 or IEC 81001-5-1; always check the official texts for your obligations.
SOUP: what are we talking about?
SOUP (Software of Unknown Provenance) means, in IEC 62304 language, software that is already developed and generally available, that you did not develop yourself (or whose development lifecycle you do not fully control under your procedures). Open-source libraries, SDKs, middleware, runtimes, cloud components: many SaMD product elements fall into this category or nearby notions (OTS, third-party dependencies).
The critical point is not the “SOUP” label itself, but risk control: identification, evaluation (including security), requirements on the component, appropriate verification, monitoring of anomalies and updates. Without a reliable inventory, you cannot demonstrate that control in an audit or design review. For an operational mapping in common tools, see IEC 62304 with Jira and GitHub.
Scope of this guide
This text does not replace IEC 62304, IEC 81001-5-1 or the CRA regulation. For legal obligations and application dates, always check the official texts and, where needed, regulatory counsel. Here we share team practices to shrink the gap between “written policy” and “what happens in the Git repo”.
SBOM: software bill of materials transparency
An SBOM (Software Bill of Materials) is a structured inventory of the software components of a product or version: names, versions, origins, licenses, sometimes dependency relationships. Formats such as SPDX or CycloneDX support exchange and automation. The SBOM is not an end in itself: it is an artefact that feeds vulnerability analysis, license management, incident response and the demonstration that you know your supply chain.
For a SaMD team, the useful SBOM is the one generated at every significant build or release, versioned with the product, and linked to decisions (accept a risk, update, replace a component). An SBOM frozen once a year in an unmaintained PDF has little operational value.
Starting practices: generate the SBOM from CI; store the artefact with the release; cross-check against a vulnerability database; raise gaps in the same tool as the backlog (not in an isolated mailbox); link critical components to a SOUP record / risk evaluation.
CRA: what applies (and what does not)
The Cyber Resilience Act (CRA) aims to strengthen cybersecurity requirements for certain products with digital elements placed on the EU market. Depending on product category, the text requires secure-by-design practices, vulnerability management, documentation and, for some categories, reporting to authorities. Key dates to track in the official texts: reporting obligations from 11 September 2026, full application of essential requirements from 11 December 2027 (timeline as set out in the regulation; implementing acts may clarify certain details).
Why does this concern device manufacturers even with a CE-marked SaMD? Because the CRA does not replace the MDR on the device, but it may apply to other digital offers from the same manufacturer. And because cyber expectations on devices are also evolving: the proposed MDR revision (the “MDR + IVDR” package under discussion, not yet adopted law) explicitly aims to strengthen cybersecurity. Even without CRA on the SaMD, targeting IEC 81001-5-1 good practices (SBOM, SOUP, vulnerabilities) remains relevant for notified body audits and state of the art.
For products to which the MDR or IVDR apply, Article 2 of the CRA excludes them in principle from CRA scope: no double CRA CE marking on that medical device. Cybersecurity for the SaMD / device remains framed by the MDR (or IVDR), MDCG 2019-16 guidance, and standards such as IEC 81001-5-1. See also cybersecurity IEC 81001-5-1 and MDR.
That exclusion is per product, not per company. A SaMD manufacturer may still sell wellness offers, hospital admin tools, separately sold components / SDKs, or non-medical wearables that can fall within CRA scope. Do not assume “we are under MDR, so the CRA does not touch us” for the whole portfolio: this is a legal and product analysis, not an RA slogan.
Practical impact for the team: map each SKU / application / separately sold module, identify the regime (MDR, CRA, both, or neither), then align evidence. SBOM and vulnerability-management practices remain useful operationally even for a 100% MDR SaMD (state of the art, audits, anticipating convergences), without equating those routines with CRA legal obligations on the MDR product.
Two regulations, one portfolio: MD + wellness
The most common trap for device manufacturers with a wellness line: “Our SaMD is CE marked, so our wellbeing app is covered.” In reality, these are often two distinct products, two classifications, two conformity frameworks. The SaMD falls under the MDR (excluded from the CRA in principle). The wellness app, if it is not a device, may be a product with digital elements subject to the CRA. Sharing code, a team or a CI does not automatically merge the regimes.
Typical scenarios to audit explicitly: non-medical companion app; patient portal without a device function; SDK or API sold to third parties; “consumer” version of a clinical product; wearable without a claimed medical purpose. Each case needs product qualification (MDR, CRA, or other) before calibrating the dossier and release gates.
On the MDR side, the notified body expects cyber evidence in the technical file (MDCG 2019-16, IEC 81001-5-1). On the CRA side, conformity, marking and notification paths differ. Running both in parallel without a shared engineering trunk duplicates effort and multiplies inconsistency risks during an audit or incident.
Common trunk vs what changes
The goal is not two software factories, but a shared engineering core and conformity layers adapted per product line. Here is a useful workshop grid for RA / tech teams.
| Area | Common trunk (whole portfolio) | Adapt per product / line |
|---|---|---|
| SOUP / SBOM inventory | Same CI, SPDX or CycloneDX formats, versioning per release | Component scope, transitive depth depending on exposure |
| Vulnerability process | Same tooling, triage SLA, decision traceability | Criticality, risk acceptance, patch timelines by patient use |
| Release gates | Up-to-date SBOM, triaged alerts, traced SOUP changes | Documentation depth, signatures, regulatory “go” criteria |
| Security by design | Threat modeling, secrets, hardening, architecture review | Threats, assets and impact by clinical or consumer context |
| Conformity dossier | Exportable evidence, requirements ↔ tests ↔ releases link | MDR/IVDR technical file vs CRA dossier (structure, content) |
| Marking and reporting | Post-market traceability, cyber incident handling | Notified body (MDR) vs CRA authorities by product category |
In practice, investing once in the common trunk (automated SBOM, SOUP register, vulnerability process, CI gates) amortizes the cost of both regimes. Differences concentrate on the documentation layer and regulatory counterparts, not on repo engineering discipline.
Practical routine: from inventory to control
Step 1 · Inventory
Identify direct and, as far as possible, transitive dependencies. Tool your CI to produce an SBOM and block or alert if generation fails. Without inventory, the rest is cosmetic.
Step 2 · Classification
Separate critical components (patient impact, security, confidentiality) from non-critical ones. Link critical items to a documented evaluation (risk, requirements, tests). Do not treat every dependency with the same depth: prioritize by risk.
Step 3 · Evidence
For each critical component: source, version, use justification, relevant known anomalies, verification tests performed, update decision. Evidence must be retrievable, not scattered in personal folders.
Step 4 · Monitoring
Subscribe to CVE / advisory alerts for critical components. Define an internal triage SLA. Document “no immediate patch” decisions with a risk justification.
Step 5 · Release gate
Before a regulatorily significant release, check: SBOM up to date, critical components evaluated, open vulnerabilities triaged, SOUP changes traced. This gate can live in CI and be consolidated in the compliance layer.
IEC 81001-5-1: a useful baseline, even without CRA on the device
IEC 81001-5-1 provides a framework for the cybersecurity process of health software. Even when the CRA does not apply to your SaMD (MDR Article 2 exclusion), following its good practices remains a solid strategy: component inventory, security requirements, verification, post-market monitoring. It is the state of the art expected by notified bodies via MDCG 2019-16, and likely the direction of upcoming regulatory changes.
The proposed MDR revision (package under discussion at EU level, not yet adopted law) notably aims to strengthen cyber requirements on devices. Without assuming timeline or final wording, the direction is clear: converge towards expectations close to what the CRA requires of mainstream digital products. Investing today in SOUP, SBOM and vulnerability processes prepares tomorrow’s MDR dossier as much as a potential CRA product line.
Many teams try to copy the standard chapter by chapter into 80-page SOPs. Frequent outcome: unreadable documents that nobody applies. Better to map existing activities (architecture, verification, configuration management, post-market) to the standard’s expectations, close gaps, and keep short procedures linked to automated evidence. To go deeper on MDR mapping, see IEC 81001-5-1 and MDR.
SOUP and SBOM fit naturally into that mapping. Your eQMS keeps the policy; your ALM / CI produces the work; a compliance infrastructure (such as Qapsule) helps keep the link and the evidence without forcing an ALM change. To untangle these categories, see eQMS vs ALM vs compliance infrastructure.
Qapsule as an overlay
Rather than migrating the team out of GitHub, GitLab or Azure DevOps “for the CRA”, connect a layer that captures SBOM, component status and release controls. QARA PULSE / Qapsule position themselves on that compliance infrastructure: evidence and controls on what you already use.
Operational SOUP / SBOM checklist
- SBOM generated automatically at every build or release tag (machine-readable format).
- Inventory of critical components with a named owner.
- Evaluation record (or equivalent) for each critical SOUP / dependency.
- Vulnerability triage process with documented internal timelines.
- Explicit link between dependency updates and change control / impact evaluation.
- Release gate: no “go” without SBOM + review of relevant open alerts.
- Exportable evidence for audit (not screenshots only).
- Periodic SOUP list review (at least at each major release).
- Short developer training: why the SBOM is not “an RA thing”.
- CRA scope check via official texts for your product.
Conclusion
SOUP and SBOM are becoming engineering routines as much as RA/QA topics. The CRA reshapes the European cyber landscape for digital products outside the MDR, while device manufacturers must think portfolio, not slogans. The durable approach: an automated common trunk (inventory, vulnerabilities, release gates), conformity layers calibrated per product (MDR vs CRA), and IEC 81001-5-1 as a cyber baseline even when the CRA does not apply to the SaMD.
Going further
If you want to clarify your tool map (eQMS, ALM, CI/CD, SBOM) and identify where a compliance layer can build on what you already have without forced migration, the Qapsule team can discuss a concrete use case with you. QARA PULSE and Qapsule position compliance as cross-cutting infrastructure: evidence, traceability and controls, plugged into your existing tools. Contact QARA PULSE to start.
FAQ
Do you need an SBOM for every commit?
Not necessarily. Aim at least for every release candidate and every commercialized or deployed version. More often if your delivery cadence and vulnerability exposure justify it.
Are SOUP and open source the same thing?
No. Many SOUP items are open source, but the SOUP criterion is about provenance and control of development, not the license. A proprietary third-party component can also be SOUP.
Does the CRA replace the MDR for cybersecurity?
For a product to which the MDR/IVDR apply, Article 2 of the CRA excludes it in principle from CRA scope: no dual CRA cyber regime on that device. Cybersecurity remains under MDR + MDCG 2019-16 + IEC 81001-5-1. Other products from the same manufacturer (wellness, admin, separately sold components) may still fall under the CRA. Analyse product by product and check the official texts.
Our wellness app shares code with the SaMD: does the CRA apply?
Product by product. Shared code or a common CI does not merge regulatory regimes. Qualify each application (medical intent, claims, distribution model) and determine whether it is a device (MDR), a CRA product, or other. The wellness app may fall under the CRA even if the SaMD is excluded. Document separation or evidence sharing accordingly.
Should you document everything word for word like IEC 81001-5-1?
No. Map, close gaps, keep procedures usable. Living evidence in delivery beats an encyclopedic SOP that nobody follows.
QARA PULSE guide on SOUP, SBOM and the CRA for a DM + wellness portfolio. This is not a certification, nor personalized legal advice. Always check official texts and adapt practices to your product, QMS and notified body expectations.