IoT component vulnerabilities: suppliers, decisions and fixes

The Cyber Resilience Act requires manufacturers to identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies.

Generating the file does not finish the work. An SBOM becomes operationally useful when the team can move from a component to a real product release, vulnerability, impact decision, remediation and verification evidence.

What the CRA says about SBOMs

Part II of Annex I requires manufacturers to identify and document vulnerabilities and product components, including by drawing up an SBOM.

Annex VII links the SBOM to the technical documentation for vulnerability-handling processes. A market-surveillance authority may also request the relevant SBOM where it is necessary to verify compliance with the essential cybersecurity requirements.

One important distinction: the Regulation does not say that every manufacturer must publish the full SBOM to every user. Annex II asks for information on where an SBOM can be accessed if the manufacturer decides to make it available to the user.

File format is only the first decision

CycloneDX and SPDX are widely used SBOM formats. Selecting a format does not solve lifecycle management.

For each SBOM artefact, record at least:

product;
release/version;
generation time;
tool and generating process;
scan scope;
format version;
storage location;
artefact identifier or hash;
validation status.

Without a release link, it may be impossible later to establish whether a component was actually shipped to a customer.

The workflow that creates value

component → component version → product release → vulnerability → impact assessment → decision → action → fix → test → evidence → communication

Example:

tooling identifies library X in release 4.8.1;
a vulnerability is disclosed for specified versions of X;
the team confirms whether the affected code is present and relevant in the product;
an impact assessment and prioritisation decision are recorded;
remediation is linked to a specific change and product release;
a test verifies the result;
verification evidence is attached to the case;
if Article 14 criteria are met, the separate CRA reporting workflow starts.

Neither a CVE entry nor the SBOM itself decides product impact for the team.

SBOMs and suppliers

A component may come from open source, a commercial supplier or another internal team. A mature process therefore connects the dependency to:

supplier or source;
maintenance status;
vulnerability-information source;
person responsible for updating it;
replacement path if the component becomes unsupported.

This also matters for support-period decisions. The CRA allows manufacturers to consider support periods of integrated third-party components providing core functions.

Describe the product that was shipped

Our recommended starting point is the released product, not the developer’s workstation. A dependency file from a source repository may contain test tools, build utilities and optional modules that were never included in the delivered artefact. Conversely, a delivered image can contain binaries or bundled components that the source dependency list does not describe. Identify what the SBOM generation process actually examines and retain that scope with the artefact.

For a hypothetical connected device, the delivered product might include firmware, an operating system image and an application package. A separate desktop management tool may have its own release record. Decide how those records relate, and make the boundary visible in the documentation. A file called “complete SBOM” is not useful if the team cannot explain whether it covers all those elements or only the application repository.

The CRA sets a minimum concerning top-level dependencies in the SBOM. A manufacturer may choose deeper coverage where this supports its risk assessment and vulnerability handling. That is an engineering decision, not a reason to relabel every optional enhancement as a statutory obligation. Record known coverage limits and the means used to investigate components beyond them. The important operational question is whether the team can identify relevant product dependencies when new vulnerability information arrives.

Keep generation reproducible and the artefact stable

A practical generation record should identify the release input, tool, configuration and output. If a later reviewer regenerates a file against changed package repositories or a different build configuration, the result may not describe the original delivery. Retain the generated artefact rather than relying solely on the ability to run the scanner again. Associate it with a stable release identity and record checks that establish whether the output is usable.

Check identifiers, component versions and obvious omissions. A machine-readable file may still have missing versions or generic names that prevent reliable matching. Select a supported format and validate it using appropriate tooling. CycloneDX and SPDX provide official specifications; their names alone do not establish that a particular file conforms to the selected specification. Retain the format and version actually produced, together with any validation result.

When a rebuild changes the delivered components, treat it as a changed artefact even if a commercial product name remains the same. Compare the component changes and determine whether the security assessment needs review. This recommended control avoids a common blind spot: the application code is unchanged, but a base image or bundled library has moved. The product record should explain which customers or deployments received that build where such information is available.

A vulnerability match is the start of a decision

Suppose, in a hypothetical example, an advisory refers to a library version listed in the SBOM for release 4.8.1. The team first confirms identity: similarly named packages are not necessarily the same component. It then checks whether the affected code or configuration is present and whether the disclosed conditions can occur in the product. Keep the supporting facts, not just the scanner’s final label.

Separate component presence, technical product impact and regulatory reportability. A component may be present without the vulnerable function being used. A reachable vulnerability may require urgent remediation without meeting Article 14 reporting criteria. Credible information about active exploitation may change the regulatory assessment. Each conclusion has its own evidence and responsible person. Collapsing all three into one status called “affected” makes later decisions difficult to explain.

Where impact remains uncertain, assign the investigation and record the temporary risk handling. Do not use “not exploitable” as a convenient closure label without a reason. Likewise, do not promise users that all components are free of vulnerabilities because a scan returned no matches. A scan is evidence with a scope and a date. New disclosures or improved component identification can change the result after the release.

Connect remediation to every relevant supported release

Manufacturers may maintain several branches, customer-specific builds or hardware variants. A fix in the newest branch does not demonstrate that an older supported release has been addressed. Use the component-to-release relationship to establish where the same vulnerability assessment is needed. Record an explicit result for each relevant family, or document why a shared decision applies to a clearly defined group.

For each corrective action, identify the proposed component version, the product change and verification evidence. Check that the replacement remains compatible with the product and that the update process itself works. A dependency upgrade can remove one weakness while introducing a functional regression. Technical testing should therefore cover the security objective and the relevant product behaviour. The GRC record should point to those results rather than treating a closed development ticket as sufficient proof.

After distribution, retain the new SBOM or changed component record and its relationship to the previous release. This allows a later advisory to be assessed against the version actually delivered. If a customer cannot update immediately, record available mitigation and the remaining risk accurately. These are practical lifecycle controls. They do not create a universal regulatory exemption for old versions or permit a manufacturer to ignore its applicable support obligations.

Supplier information must answer specific questions

Ask a component supplier for the information needed to identify and maintain the dependency. That may include the component version, included subcomponents, support arrangements, vulnerability contact and update channel. The request should match the purchased product and contract. A general assurance that the supplier “takes security seriously” does not identify which library is embedded or how the manufacturer learns that support has ended.

For an opaque commercial component, record what is known, what is missing and who is obtaining the missing information. Consider the risk of relying on a component whose security status cannot be assessed adequately. The manufacturer’s process should address the gap; it should not silently fill the SBOM with invented identifiers. If replacement is being considered, document effort, compatibility constraints and the decision rather than pretending that substitution is immediate.

For an open-source component, distinguish the project’s actual maintenance state from its popularity. Record the source used for releases and advisories and the person responsible for following relevant changes. There may be no commercial support contract. That does not remove the manufacturer’s need to maintain its product. Avoid presenting upstream community activity as a contractual promise of support for the entire product lifetime.

Decide how artefacts are shared

SBOM information may reveal product architecture or commercially sensitive detail. Define internal access, external sharing and authority-response responsibilities without assuming that secrecy eliminates disclosure obligations. The CRA distinguishes required documentation and authority access from optional user availability of an SBOM. Customer contract requirements can add another practical sharing question. Assess each route on its own basis and retain which artefact was shared with whom and when.

Before distributing a file, verify that it describes the intended product and release and does not contain accidental internal paths or unrelated development content. Provide enough context for the recipient to interpret coverage. A customer receiving an SBOM should not have to guess whether a component belongs to runtime software, a build tool or a separate application. These are recommended quality checks for communication, not a requirement to publish every internal dependency record.

Test whether the process can answer a product question

A useful internal exercise is to select one supported release and one hypothetical advisory. Ask the team to find the artefact, confirm component identity, assess product impact, identify a decision owner and show a potential corrective path. Record the elapsed work and missing information. Do not require a predetermined “pass” result; the purpose is to find weaknesses in identification, release mapping and follow-up before a real case depends on them.

Our recommended review indicators are the proportion of supported releases with usable artefacts, unresolved component-identification gaps and overdue impact assessments. Define what “usable” means for your product rather than counting generated files. A smaller set of reliable release-linked records can be more useful than thousands of unvalidated outputs. The result of the exercise should be an actionable improvement list with owners, while actual engineering and regulatory decisions remain subject to their appropriate review.

Do not turn GRC into another scanner

Pulsar should not compete with software composition analysis tools, dependency scanners and SBOM generators. Those tools identify and describe components.

GRC adds value when it uses the output to support controlled decisions:

associate an artefact with the product and release;
link risk and action;
assign an owner and due date;
retain the decision;
attach remediation and test evidence;
provide history during review.

Use Pulsar to organize risks, actions, suppliers, documents, evidence and reports related to component handling. Agree support for CycloneDX/SPDX formats within your service scope before planning an SBOM import.

Check your current process

Can you identify the SBOM for a specific release?
Is its generation reproducible?
Does each critical component have an owner or source?
Can a vulnerability be tied to an affected product release?
Does a risk-acceptance decision have an approver and review date?
Does remediation have verification evidence?
Is there a clear rule for moving from vulnerability handling to CRA reporting assessment?

See Pulsar GRC on one evidence workflow

A synthetic IoT component vulnerability

Consider a fictional industrial sensor with a network-connected firmware component supplied by another company. The manufacturer receives a vulnerability notice naming that component. The exercise starts with that notice and ends with a reviewed decision and evidence. It does not assume that every product carrying the component is affected, or that an SBOM match proves exploitation.

Identify the product and firmware version distributed to users. Compare the component identity and version with the notice, then record the conditions under which the vulnerable function can be reached. Include the supported releases that need review. An upstream component name can be insufficient where the supplier has backported a fix or changed a build. Ask for the information needed to resolve that specific question.

Create a supplier record or link the existing supplier in Pulsar’s available workflow. Record a risk and an action to assess the notice. Name the product owner and the person reviewing the technical conclusion. Attach a synthetic notice and product-version description. Keep their fictional status visible so the exercise cannot be confused with an operational vulnerability report.

For the example, assume the technical review finds an affected configuration. Prepare an action to obtain and evaluate the corrected component. Define the test that will establish the result in the sensor’s actual operating conditions. A supplier saying “fixed” is relevant input, but the manufacturer still needs evidence that the version and configuration it ships meet the acceptance criterion.

After the test, attach the fictional result and record the reviewed decision. Link it to the affected release and any remaining deployment work. A fixed component in a test environment does not demonstrate that all deployed devices have been updated. Keep release, distribution and customer communication tasks distinct where they form part of the real process.

Review reporting obligations separately against the established facts and applicable CRA conditions. Since 11 September 2026, Article 14 reporting obligations apply to the specified actively exploited vulnerabilities and severe incidents for products in scope. Do not report every component match as an exploited vulnerability or treat this exercise as an official filing.

The trial evaluates whether Pulsar lets your team locate the product context, supplier question, owner, action and supporting evidence. It does not turn Pulsar into an SBOM generator, vulnerability scanner, firmware updater or automatic reporting service. Start with this one synthetic case during the 14-day trial, review its required payment method and cancellation terms, and decide whether the record supports your own product workflow.

Review terms and start the 14-day trial