Cyber Resilience Act / EU product security

What importers should ask suppliers before CRA pressure increases

The supplier question is becoming a business question

For many connected-product importers, CRA-readiness will become practical before it becomes comfortable.

The first pressure point is often not a legal memo or a board presentation. It is a supplier conversation:

What exactly can this supplier prove about firmware, updates, support periods, vulnerability handling and product-security evidence before customers, partners or regulators start asking harder questions?

The Cyber Resilience Act changes the pressure around connected products in the EU. It does not only affect large manufacturers with internal cybersecurity teams. It also affects the wider product chain: importers, distributors, product managers, supplier managers and connected-product teams that depend on supplier-managed firmware, software, update mechanisms, cloud behaviour or embedded components.

The CRA entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027.

Source: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

The European Commission explains that, from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.

Source: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

Organisations should not wait until reporting pressure, customer pressure or event-driven market questions begin before they ask suppliers basic product-security questions.

Explore the Knowledge Hub

Why importers cannot rely on paperwork alone

Supplier paperwork can support a review, but the presence of a document alone does not show whether its information applies to the exact connected product, hardware revision, firmware or software version being supplied.

Importers may still need reviewable product security evidence about version context, firmware updates and the update mechanism, support-period information, vulnerability handling and the security contact route, plus component or SBOM context where relevant. These evidence needs vary by product and supplier.

Missing evidence needs an explicit owner and follow-up route. This makes CRA supplier evidence usable for connected product cybersecurity decisions, rather than leaving supplier questions scattered across brochures, declarations and email threads.

Core supplier evidence questions to prepare

CRA supplier evidence questions should reveal whether the organisation can identify, maintain and follow up the actual connected product being supplied. For importers, product teams and supplier managers, that means organising product security evidence around four practical areas rather than relying on generic compliance language.

Product identity & version context

Supplier evidence needs a clear product reference. Without it, teams may be unable to tell whether a document or answer applies to the model and version in front of them.

Which exact product model and hardware revision does the evidence cover?
Which firmware or software version is supplied?

Updates & support information

Connected product cybersecurity depends on understanding how the product can be maintained after delivery and for how long.

What update mechanism is available for the supplied product?
How will firmware updates or other security updates be delivered?
What support period applies to this model or version?

Vulnerability handling & security contact

A defined vulnerability handling route helps the organisation know where to send a security concern and how supplier follow-up will begin.

Which vulnerability handling process applies to this product?
Who is the security contact for reports and urgent follow-up?
How will importers or customers be notified about confirmed issues?

Component / SBOM context where relevant

Component visibility can support product review, but the available SBOM context, format and level of detail may differ by product and supplier.

Is an SBOM or another component inventory available?
Which product and version does that component information cover?
How are affected component versions communicated?

Supplier answers will differ by product and supplier. The goal is not a universal checklist, but a structured way to make missing evidence visible, reviewable and ready for supplier follow-up.

Firmware, updates and support-period questions

Firmware, update and support information sits at the centre of connected product cybersecurity. If the exact firmware or software version is unclear, product security evidence may relate to a different release. If the update mechanism is unclear, teams may not know how a security update will reach the product. If the support period or end-of-support position is unclear, maintenance and product-security planning become weaker.

In the CRA context, manufacturers determine a support period, handle vulnerabilities during that period and provide users with its end date. For importers and product teams, supplier evidence needs to make this product-specific position reviewable without assuming that every product uses the same update model.

Version and evidence match

A version reference connects technical documents, security notices and previous findings to the product actually being supplied. Without that match, teams may make decisions using evidence from another release.

Which firmware version or software version is installed on the units currently supplied?
How can the importer verify that version and link the available evidence to it?
How are version changes recorded and communicated?

Update delivery and security updates

The update mechanism determines how firmware updates and other security updates reach users or operators. Importers need enough information to understand the delivery route and coordinate supplier follow-up when an issue requires action.

Is the update mechanism manual, automatic or supplier-managed?
How are security updates authenticated, delivered and made available to users?
How are customers informed when an urgent update or mitigation is available?

Support period and end-of-support follow-up

A clear support period helps teams plan vulnerability handling, customer communication and product decisions over the expected use period. An unclear end-of-support position can leave the organisation without a defined route when a later security issue appears.

What support period and end-of-support date apply to this model or version?
What security-update and vulnerability-handling support is expected during that period?
Who owns supplier follow-up if the position is unclear or end of support is approaching?

In a PAXECT Readiness workflow, this supplier evidence can turn firmware, update and support-period uncertainty into reviewable product-security follow-up.

Vulnerability handling and security contact questions

Supplier evidence is also about what happens after a vulnerability or security concern is reported. If the security contact is unreachable or the vulnerability handling route is unclear, a valid concern can stall before assessment, leaving importers and product teams without a reliable path for fixes, patches, mitigations or customer communication.

ENISA describes coordinated vulnerability disclosure as a multi-party approach that supports reporting and coordinated disclosure after responsible parties have developed a fix, patch or mitigation. The exact process can differ between suppliers, but the contact and follow-up route should be understood before a supplier meeting, distributor review or product-security event makes it urgent.

Source: https://www.enisa.europa.eu/topics/vulnerability-disclosure

ENISA’s supply-chain cybersecurity work also provides context for treating supplier relationships and supply-chain risk as structured cybersecurity concerns.

Source: https://www.enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecurity

The CRA separately establishes manufacturer reporting for actively exploited vulnerabilities and severe incidents. This section focuses on supplier communication and reviewable follow-up, not legal reporting instructions.

Security contact and reporting route

A reachable security contact gives product teams a defined entry point for vulnerability disclosure. The route should be clear enough that a concern reaches the responsible function without depending on an informal personal contact.

Where should a product-security concern or vulnerability report be submitted?
Who monitors that security contact, and is there a fallback route?
Does the supplier maintain a vulnerability disclosure or coordinated vulnerability disclosure process?

Assessment, fixes and mitigations

Once a report is received, importers need enough supplier evidence to understand whether it has been acknowledged, assessed and connected to the affected product versions. They do not need the supplier’s internal incident-response playbook, but they do need a usable status and remediation path.

How does the supplier acknowledge, assess and track a vulnerability report?
How are affected products and versions identified?
How will available fixes, patches or mitigations be communicated?

Communication records and supplier follow-up

Confirmed issues can affect importers, distributors, customers or users in different ways. A reviewable communication record helps the organisation see what was known, what was sent, who owns supplier follow-up and whether an open action has been closed.

How are relevant parties notified when a security issue is confirmed?
Are security advisories, update notices and mitigation records retained?
Who provides status updates and closure evidence for unresolved actions?

In a PAXECT Readiness workflow, vulnerability-handling evidence can turn an unclear supplier contact route into reviewable product-security follow-up.

SBOM and component context: what to ask without overclaiming

A software bill of materials (SBOM) or other component information can help importers and product teams understand which software, packages, dependencies or hardware components may be present in a connected product. That context can strengthen product security evidence and component-vulnerability follow-up, but only when it can be linked to the product and release being reviewed.

The CRA includes manufacturer requirements related to component vulnerability handling and SBOM documentation. That does not mean every importer will receive the same SBOM, or that available information will always be complete, current, shareable or presented in one format. Missing or partial component evidence should be recorded rather than treated as if the product context were complete.

Component visibility and available evidence

Start with the component evidence that actually exists. Depending on the product and supplier, this may be an SBOM, component inventory, package information, dependency information or another maintained record.

Is an SBOM available and shareable for the supplied product?
If not, what component, package or dependency information can be provided?
When was the evidence last updated, and are any limitations or exclusions documented?

Product/version linkage

Component evidence becomes useful for connected product cybersecurity when its scope can be matched to an actual product model, firmware or software version and release history. A component list without that linkage may describe a different build.

Which product model, hardware revision and firmware or software version does the evidence cover?
How are changes to the component inventory recorded between releases?
Can the component information be matched to the relevant release history?

Vulnerability follow-up and affected versions

Component context can support CRA-readiness by helping teams connect component vulnerabilities to affected versions and supplier follow-up. It does not replace technical assessment, but it can show where a product-specific answer is still needed.

How does the supplier determine whether a component vulnerability affects the supplied product?
How are affected versions and unaffected versions communicated?
What update, mitigation or supporting evidence follows when a component is affected?

The goal is not to demand the same SBOM format from every supplier, but to make available, missing or limited component evidence visible and reviewable.

In a PAXECT Readiness workflow, SBOM or component context can turn unclear software-dependency information into reviewable supplier evidence and follow-up.

Where Supplier Requests fit

Supplier evidence gaps often appear across firmware, updates, support periods, vulnerability handling or SBOM and component context. If those gaps remain in email threads or informal notes, supplier follow-up can lose its product context, owner and next review step. Supplier Requests turn a documented evidence gap into a clear, product-specific question with assigned follow-up.

From Readiness Report finding to supplier question

Readiness Reports can show which reviewed findings or missing product security evidence require supplier input. A Supplier Request carries that gap forward with the relevant product, version and question, rather than restarting the investigation in a separate conversation.

A report cannot confirm the update route or support period, so the request identifies the exact model and evidence needed.
A component finding lacks affected-version context, so the request asks for version-specific clarification.

From supplier response to Evidence Dossier record

When a response arrives, the Evidence Dossier can keep it with the product context, supporting files, response date and unresolved points. Recording the response does not automatically validate it; it creates a reviewable evidence record.

Link the response to the relevant model, hardware revision and firmware or software version.
Record whether the requested evidence is complete, partial or still unanswered, together with the follow-up owner.

From reviewed gap to Remediation Guidance / follow-up direction

If the response confirms a product-security gap, or leaves a material question unresolved, Remediation Guidance can describe the follow-up direction for responsible review. This keeps the CRA-readiness workflow connected without turning guidance into an automatic decision or fix.

Request updated documentation or supplier clarification before closing the evidence review.
Route a confirmed connected product cybersecurity issue to the responsible organisation for a product decision.

These workflows organise supplier evidence and follow-up; they do not force supplier responses, validate supplier answers, certify compliance or replace the responsible organisation’s decision-making.

Why this matters across the EU market

The Cyber Resilience Act creates EU-market pressure, not a one-country issue. Products with digital elements can move through cross-border manufacturer, importer, distributor and supplier relationships, so CRA-readiness depends on product security evidence that remains understandable when ownership and product information are spread across organisations.

Practical supplier-evidence workflows therefore need to work for EU-wide product teams with different levels of cybersecurity maturity and compliance capacity, including organisations beyond large enterprise security environments. A usable workflow should help teams identify the product, record missing evidence and assign supplier follow-up without assuming that every organisation has the same internal resources.

NIS2 is a separate legal framework with its own scope. It reinforces the wider EU cybersecurity regulation context through risk-management requirements for covered entities and national policies that include supply-chain security, vulnerability management and cybersecurity awareness; it should not be treated as creating the same duties as the CRA for every connected-product organisation.

Source: https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

GDPR / EU data protection remains a secondary consideration where supplier-evidence workflows involve personal data. EU data-protection rules govern that processing, but they do not create CRA-style supplier-product evidence duties.

In a PAXECT Readiness workflow, reviewable supplier evidence and clear follow-up ownership can provide a consistent working method across importers, distributors and product teams without assuming identical capacity or legal scope.

What PAXECT does not claim

PAXECT does not provide a complete legal supplier checklist. It does not guarantee supplier compliance. It does not certify supplier evidence or validate supplier answers. It does not replace legal review, sector-specific assurance or CRA obligations for manufacturers, importers or distributors.

PAXECT also does not claim that every supplier must provide every evidence item in the same form. It does not claim that SBOM is always available or always required in the same way for every product.

The responsible organisation remains responsible for final product, legal, supplier and compliance decisions.

Practical next steps for importer teams

Importer teams can use these five steps to move from general supplier questions to a reviewable CRA-readiness workflow for the connected product being supplied.

1. Identify who controls product information

Map which supplier, manufacturer or technical partner controls the product identity, firmware or software baseline, update route, support information, vulnerability handling and component records. Record a responsible contact for each area so product security evidence does not depend on an unnamed team or an old email thread.

2. Ask for firmware, software, update and support evidence

Request evidence for the exact model and version being supplied: the installed firmware or software version, update mechanism, delivery of firmware updates or other security updates, and the applicable support period. Ask for document or release references where available, and record when the position is still unclear.

3. Ask for vulnerability handling and security contact details

Confirm the current security contact and vulnerability disclosure route before an issue appears. Ask how reports are acknowledged and assessed, how affected versions are identified, and how fixes, patches, mitigations or security advisories are communicated to relevant parties.

4. Ask for SBOM or component context where available

Ask whether an SBOM or other package, dependency or component information is available for the product version in scope. Record its date, coverage and stated limitations; if no component context is available, capture that as an evidence gap rather than assuming completeness.

5. Record missing evidence and assign follow-up ownership

Log each missing item with the product and version, the supplier question, the follow-up owner and the next review point. Keep the status visible as unanswered, partial or reviewed, and route material gaps to the responsible product, security or legal decision-maker rather than treating supplier silence as closure.

FAQ

What should importers ask suppliers for CRA-readiness?

Importer teams should start with the product model and version, then ask about firmware or software, the update mechanism, support period, vulnerability handling, security contact and SBOM or component context where relevant. Prioritise supplier questions where current records are incomplete or controlled by the supplier.

Do importers need supplier evidence?

Supplier evidence can be important when importers depend on supplier-managed firmware, updates, vulnerability handling or other product security information. The evidence needed will vary by product and role, but structured records can support review and supplier follow-up.

Is an SBOM always available?

No. SBOM availability, completeness, currency and format can vary. Ask what component information exists, which product version it covers and whether any limitations are documented.

What if a supplier cannot answer security questions?

Record the evidence gap against the relevant product and version, assign a follow-up owner and define the next review point. An unanswered supplier question remains unresolved evidence; it should not be treated as proof or closure.

Prepare supplier questions before CRA pressure increases.

Bring product-specific supplier evidence gaps into a structured review and follow-up process.

Request Early Access