Requirements by context
| Context | Authority / status | Who is affected | SBOM expectation |
|---|---|---|---|
| FDA cyber devices | Section 524B · statutory requirement | Sponsors of covered premarket applications/submissions | Provide an inventory of commercial, open-source and off-the-shelf components. |
| EU Cyber Resilience Act | Regulation (EU) 2024/2847 · staged application | Manufacturers of in-scope products | Creation obligation within vulnerability handling; broader application from December 2027. |
| U.S. federal procurement | OMB M-26-05 · agency risk-based policy | Agencies and suppliers under actual acquisition terms | Agencies may adopt SBOM-on-request contract terms. |
| Customer / supplier agreement | Contractual requirement | Parties and products identified in the agreement | Delivery, quality, access and updates depend on agreed terms. |
| CISA minimum elements | Government guidance | Organizations choosing or instructed to apply it | Current guidance is the published 2026 document. |
Source: FDA · Cybersecurity in Medical Devices FAQs.
Source: European Commission · CRA legislative summary.
Source: OMB · M-26-05, January 23, 2026.
Use precise labels
| Label | Meaning | What to record |
|---|---|---|
| Statutory requirement | A duty created by legislation | Provision, scope and applicability. |
| Regulation | A binding rule within its jurisdiction and scope | Text, dates, exclusions and amendments. |
| Government procurement policy | Instructions or terms affecting covered acquisitions | Current agency policy and solicitation terms. |
| Government guidance | Agency recommendations or interpretation | Final/draft status and issue date. |
| Standard | Published technical rules or model | Edition and the applicable conformance point. |
| Contractual requirement | A promise defined by an agreement | Delivery, acceptance, correction and remedies. |
| Buyer recommendation | A proposed purchasing safeguard | Business rationale and negotiable priority. |
A standard can become relevant through law, agency policy or contract. Its publication alone does not make every field mandatory for every software producer. A useful requirements register records both the originating source and the way it became applicable.
Build an applicability record
- Identify the product and its intended markets, users and distribution model.
- Identify your role: manufacturer, supplier, integrator, buyer or operator.
- Find the current primary authority and any scope exclusions.
- Record the exact provision, status and relevant application date.
- Define the artifact, recipient, accepted format and delivery timing.
- Assign an owner for interpretation and change monitoring.
- Translate the obligation into an evidence-producing workflow.
Keep assumptions visible. A connected medical device, a hospital’s purchased application and a standalone consumer product may have different duties even when they use the same library. An internal inventory policy can still apply to all three.
Do not confuse the artifact with the program
An inventory file can satisfy a particular delivery expectation while leaving vulnerability handling, configuration control or supplier monitoring unfinished. Conversely, a mature vulnerability program may still lack the artifact a regulator or customer requests. Assess those separately.
Map each required output to its generating process, validation gate, approval, delivery record and retention policy. If a supplier cannot provide an element, record the gap and its disposition under the applicable authority or agreement. Do not replace unknown information with a plausible value.
Where uncertainty remains
Product scope, legacy releases, connected services and modifications can require case-specific interpretation. Standards and implementation work continue to evolve. This resource provides source-based orientation; organizations need a documented applicability decision for their own facts.
The CRA implementation timeline and FDA publication record should be rechecked before a submission or launch. Federal solicitations may contain agency-specific terms. A generic checklist cannot determine the controlling contract.
Turn obligations into supplier terms
Name the baseline by document and date. Specify accepted formats and versions, the covered artifact, release mapping, quality criteria and correction process. Agree whether authorized security tools can process the data and whether support continues to include updated inventories.
Use the RFP matrix to request evidence of these capabilities from an SBOM platform. Use the readiness checklist to identify who owns the resulting process. The requirement matters only if the organization can produce and use the evidence when needed.
Primary sources
- FDA · Cybersecurity in Medical Devices FAQsAgency explanation of statute
- EUR-Lex · Regulation (EU) 2024/2847Binding EU regulation
- European Commission · CRA legislative summaryOfficial legal-text summary
- OMB · M-26-05, January 23, 2026Current federal policy memorandum
- CISA and partners · 2026 Minimum Elements (ACSC publication)Published government guidance