Manufacturers & product owners
Your name or brand is on the product — including products developed or manufactured by others. Start with ownership, product boundaries and the lifecycle.
Cybersecurity · Product security
Cyber Resilience Act.
Build security into products.
From initial scoping to practical processes and evidence: we help manufacturers, product owners and engineering teams implement the CRA.
Personally led by Matthias Totzauer · Connecting management, engineering and operations
Start with the actual product
What is your role?
The CRA generally covers hardware and software with digital elements supplied commercially on the EU market and connected directly or indirectly to devices or networks. Exceptions and transitional rules require product-specific review.
Importers & distributors
You bring products into the EU or distribute them. Clarify your own checks, supplier evidence and escalation duties.
Engineering & software teams
You develop software, connected devices or components. Connect security requirements to development, releases, dependencies and support.
CRA, NIS2 and BCM address different concerns: the product lifecycle, the security of covered organisations, and business continuity and recovery. Several can be relevant to the same business.
How ITCST helps
From requirements to working processes.
A clear remit for management and delivery. We agree the products, scope, evidence and responsibilities at the outset.
01Scope & responsibility
Map the product portfolio, market roles, dependencies and potential exceptions. Prepare a documented product classification and clarify points that need legal or specialist assessment.
Deliverable: product scope and responsibility matrix.
02Gap assessment & roadmap
Compare development, support and evidence with the relevant CRA requirements. Prioritise gaps by product risk, market plans and feasibility.
Deliverable: prioritised action plan with owners and milestones.
03Secure development & supply chain
Bring product risk assessment, security requirements, development gates, component inventories and the SBOM process into one workflow. Coordinate evidence from suppliers and engineering.
Deliverable: agreed lifecycle controls and evidence structure.
04Vulnerability handling & reporting
Define intake, triage, escalation, product-security responsibilities and coordinated disclosure. Prepare the reporting workflow and rehearse a representative case.
Deliverable: product-security playbook, roles and reporting checklist.
05Updates & support
Plan secure update delivery, support commitments and product end-of-support communication together with product management and operations.
Deliverable: support and update concept with clear ownership.
06Documentation & implementation tools
Organise technical documentation and traceability. Where useful, build product inventories, ticket workflows, evidence registers and dashboards with Digital Solutions. Prepare the evidence needed for the applicable conformity process.
Deliverable: structured evidence workspace and handover package.
Reporting readiness since 11 September 2026
A clear process matters when an event occurs.
Detect & assess
Assess the affected product, active exploitation or severe incident. Assign owners and deputies.
24 h / 72 h
From awareness: early warning within 24 hours, notification within 72 hours. Final reports follow according to the type of report.
Report & follow through
Use ENISA’s single reporting platform to notify the responsible CSIRT and ENISA. Coordinate corrective action and user information.
Article 14 reporting obligations also cover in-scope products placed on the market before 11 December 2027.
A practical starting point
Start with one product.
For the first conversation, describe the product, your market role, development stage and existing security processes. We then agree the scope of review and implementation.
- 01
Scope
Clarify the product, role, market and open questions.
- 02
Baseline
Review development, reporting, support and evidence.
- 03
Roadmap
Agree priorities, owners, milestones and acceptance criteria.
- 04
Delivery
Introduce processes, organise evidence and support implementation.
Digital Solutions
Keep evidence usable.
Product and component registers, vulnerability tickets, approvals and support dates can be integrated into existing systems or delivered as a focused application.
Automate security & CRA workflows →Plan supporting tools →
Key distinctions.
Does every web application fall under the CRA?
No blanket classification is appropriate. Product boundaries, commercial supply, connectivity and exceptions matter. A remote processing solution required for a product function can be included. Pure services, internal developments and open-source scenarios need their own assessment.
Does ISO 27001 demonstrate CRA conformity?
An ISMS can provide useful processes and evidence. It does not replace the product-specific requirements and applicable conformity assessment under the CRA.
What is an SBOM?
A Software Bill of Materials records software components and their dependencies. We help establish ownership, generation and maintenance, so it supports vulnerability handling throughout development and support.
Is five years of support always sufficient?
The support period must reflect expected use. It must generally be at least five years; shorter expected use can justify a shorter period. Products expected to be used longer can require longer support.
Does ITCST issue a CRA certificate?
ITCST supports readiness, implementation and preparation of documentation. Legal advice, independent conformity assessments and certification are outside this engagement. The applicable procedure and any required notified body are clarified for the product.
Official sources
Content reviewed: 11 October 2026. The regulation and requirements applicable to the specific product govern.
Your next step
How CRA-ready is your product?
Together, we clarify your starting point, pending decisions and a useful first engagement.