Scope and inventory
Map the product, variants, releases, software components and available technical material.
Cyber Resilience Act technical assessment for firmware, software and connected products
Review firmware, software and updates to identify missing evidence and technical priorities for the CRA journey.
How we can help
SBOM and dependencies
A baseline that makes components, libraries and the relationship between builds and product releases readable.
Security and updates
Review boot, hardening, interfaces, updates, signing, rollback, logs and vulnerability handling.
How we work
Product and scope
Define the product, versions, assessment boundaries, available material and technical stakeholders.
Technical review
Review architecture, builds, components, interfaces, updates and lifecycle-management practices.
Gaps and priorities
Identify technical gaps and order actions by risk, impact and feasibility.
Report and action plan
Deliver the report, technical evidence and roadmap; where needed, start the priority work on firmware, software or infrastructure.
A new idea or an existing project? Tell us where you are starting from.
The service in detail
Open a topic to explore activities, technical choices and scope.
From requirements to the real product
A requirements list is not enough unless it is connected to actual variants, versions, builds, components and procedures. The work starts from the product and produces a technical baseline that engineering, product teams and compliance specialists can use together.
- Firmware, bootloaders, RTOS, embedded Linux, applications, gateways, backends and apps connected to the product.
- Hardware variants, software releases, repositories, builds, toolchains, libraries and third-party components.
- Local and network interfaces, credentials, debug ports, exposed services, telemetry and logging.
- Updates, signing, rollback, vulnerabilities, end-of-support and field lifecycle operations.
Technical evidence that supports decisions
The goal is not generic paperwork. It is to make the information needed to address technical gaps traceable. The level of detail is calibrated to the product, team maturity and available material.
- A product, version and component map that can be maintained over time.
- An initial SBOM and software-dependency baseline, including items that need verification or normalization.
- Technical review of build, release, update, logging and vulnerability-management practices.
- A report with priorities, constraints, recommended actions and a realistic intervention roadmap.
Technical support, not certification
Silicon LogiX does not issue certifications, CE markings, declarations of conformity or legal opinions. The manufacturer remains responsible for decisions and applicable obligations. We provide technical analysis and evidence that help teams work with quality functions, legal specialists and competent bodies where needed.
- No promise of automatic compliance or regulatory suitability.
- No legally binding classification of scope or assessment procedure.
- Verifiable product-specific analysis, implementation and technical documentation.
Gaps and roadmap
- Gaps and roadmap
- Technical priorities, risk, dependencies and an actionable intervention plan for the internal team or our support.
Frequently asked questions
Do you issue a Cyber Resilience Act certification?
No. The service provides technical analysis, evidence and implementation work; it does not issue certifications, declarations of conformity or CE markings.
Can you determine whether our product is in scope for the Cyber Resilience Act?
We can clarify the product’s technical perimeter and prepare information useful for assessment, but we do not provide a legally binding opinion. The manufacturer and qualified specialists remain responsible for that decision.
Can you produce an SBOM?
Yes. We start from available source code, builds, packages and components to create or normalize an SBOM linked to a specific release.
Can you work on legacy firmware and software?
Yes. The assessment is designed to reconstruct components, builds, dependencies and risks even when documentation is incomplete.
Are secure boot and OTA always required?
There is no one-size-fits-all answer. The need and form of an intervention depend on the architecture, exposed surface, use scenario and expected lifecycle.
Can you analyse the device, firmware, cloud and app together?
Yes. The scope can include the digital elements that affect security and product operation: device, embedded software, gateway, backend, dashboard and app.
Let’s discuss your project
Tell us your goal, what is already available and what needs to improve. We can then assess the next step together.