The Cyber Resilience Act changes how hardware and software products are planned, developed, documented and operated throughout their lifecycle. Manufacturers must do more than place a secure product on the market. They must handle vulnerabilities during the support period, organise security updates, maintain technical evidence and be ready to report from 11 September 2026.
The key point is simple: the CRA is not a single CE work package at the end of development. It turns product security into a demonstrable organisational capability.
Regulation (EU) 2024/2847 has been in force since December 2024. The reporting obligations apply from 11 September 2026, while the main remaining requirements apply from 11 December 2027. On 27 July 2026, the European Commission published additional practical guidance covering, among other topics, scope, substantial modifications, support periods, risk assessments and reporting duties.
For businesses, the direction is clear: organisations making digital products available in the EU need to embed CRA implementation in product management, engineering, security, quality management, procurement and service operations now.
CRA readiness exists when the organisation can answer five questions at any time: Which product? Which risk? Which control? Which evidence? Which owner?
What the CRA changes in practice
The CRA generally applies to hardware and software products with digital elements that are made available on the EU market and whose intended or reasonably foreseeable use includes a direct or indirect connection to a device or network. It covers not only finished products, but also separately marketed components and necessary remote data processing solutions.
The scope therefore ranges from machine controls, gateways, IoT devices and embedded software to operating systems, applications, security products and digital components. Certain product categories are excluded where sector-specific EU legislation already imposes comparable cybersecurity requirements. The scope must therefore be determined for each product and product family.
Manufacturer obligations start before market access and continue after delivery:
- Before placing the product on the market, scope, risk assessment, security requirements, technical documentation and the conformity route must be defensible.
- At market placement, user information, the support period, the EU declaration of conformity and the CE marking must be correct.
- After market placement, vulnerabilities, updates, advisories, incidents, product changes and the installed base must be managed.
The CRA also distinguishes between the default category, important products and critical products. Products in the default category can generally use internal conformity assessment. Important Class I products face stricter conditions depending on the technical specifications applied. Important Class II and critical products generally require independent assessment or an applicable European cybersecurity certification scheme.
Classification is therefore not an administrative detail. It affects the programme plan, evidence requirements, testing strategy, budget and market launch.
Clarify roles before starting the checklist
A common mistake is to begin with an Annex I checklist before determining the economic role the organisation actually performs for each product.
Manufacturer
A manufacturer is the party that develops or has a product developed or manufactured and markets it under its own name or trademark. The manufacturer carries the central responsibility for risk assessment, security by design, technical documentation, conformity assessment, vulnerability management, support and reporting.
Importer
An EU-established importer that places a product from a manufacturer outside the EU on the Union market must verify in advance that the manufacturer has met the relevant obligations. This includes the conformity assessment, technical documentation, CE marking and vulnerability-handling processes.
Distributor
Distributors must verify, among other things, that the CE marking, manufacturer and importer information, user instructions and support period are present. A product with an apparent non-conformity must not continue to be made available.
Authorised representative
A manufacturer may appoint an EU-established authorised representative for clearly defined tasks, such as cooperation with market surveillance authorities. The fundamental manufacturer responsibility remains unchanged.
Open-source software steward
The CRA introduces a separate role for legal entities that provide sustained support for specific free and open-source software intended for commercial activities without placing it on the market as the manufacturer. These stewards have tailored obligations relating to secure development, vulnerability handling, cooperation with authorities and reporting.
Integrator or modifier
An integrator may become a manufacturer when it markets a product under its own name or makes a substantial modification. This is particularly relevant for machine retrofits, white-label products and deep software adaptations. Every substantial modification should therefore be treated as a product and compliance decision.
A clear division of work: the manufacturer develops, IT Kombinat runs the CRA process
External support can accelerate CRA implementation considerably. It does not transfer manufacturer responsibility.
The customer retains ownership of:
- product and architecture decisions
- development and implementation of product functions
- development, testing and approval of patches and product updates
- technical release approval
- acceptance of residual risk
- the conformity decision, EU declaration of conformity and CE marking
IT Kombinat can take responsibility for the methodological, technical and organisational orchestration around those decisions:
- establish the CRA programme, roles, milestones and decision paths
- perform and document risk assessments and threat modelling
- review security requirements, architecture and testing strategy
- track findings, actions, supplier evidence and deadlines
- structure the technical file, evidence register, release gates and audit readiness
- establish or operate PSIRT, reporting, SBOM/VEX and lifecycle processes
- provide management reporting, KPIs, CAPA and recurring reviews
Where requested, IT Kombinat can also prepare and conduct external communication with the relevant authorities and CSIRTs. This requires a defined mandate, agreed approval paths and approval of the content by the manufacturer, Legal or the responsible decision makers. Legal responsibility remains with the manufacturer.
This division protects engineering capacity: the customer focuses on product development and patching. IT Kombinat runs the CRA process, documents decisions and ensures that open issues, evidence and deadlines remain under control.
A practical model: PLAN – BUILD – SECURE – OPERATE
A robust CRA implementation connects the regulatory requirements to the real product lifecycle. IT Kombinat structures the work in four phases.
PLAN: Establish scope, roles, governance and the target state
The PLAN phase creates the foundation. Without a reliable scope, gaps will later appear in the risk assessment, SBOM, technical file and support model.
Typical work packages include:
- establish a product and variant register
- capture hardware, software, firmware, components and remote services
- define system boundaries, intended use and reasonably foreseeable misuse
- determine the organisation’s role and the roles of suppliers
- provisionally determine the product category and conformity route
- design the support period and end-of-support model
- assign responsibilities across management, product, engineering, security, quality/CE, procurement and service
- establish the CRA fit-gap, evidence model, milestones and decision register
IT Kombinat can deliver this phase as an initial assessment or as the setup of a complete CRA programme. The customer provides product knowledge, names the decision makers and approves scope, roles and the target state.
BUILD: Connect risk assessments, threat modelling and security engineering
Risk assessments and threat modelling are not supplementary compliance documents. They are the technical control system for CRA implementation.
This includes:
- analyse assets, threats, attack paths and impact
- consider security, safety and availability risks together
- include intended use, reasonably foreseeable misuse and the operating environment
- derive testable security requirements from the risk assessment
- design zones, communication paths, administration routes and trust boundaries
- define IAM, role models, MFA, PKI, cryptography and secret management
- design logging, monitoring, update, recovery and secure decommissioning
- integrate secure coding, code reviews, SCA, security testing and release criteria into the development process
- manage supplier requirements, support commitments and technical evidence
IT Kombinat supports this work through risk assessments, threat modelling, security architecture, IEC 62443 mapping, architecture reviews, requirements engineering and test concepts. Product development, implementation and patch creation remain with the manufacturer or its engineering partners.
In industrial environments in particular, IT, OT and safety must be considered together. A compliance matrix alone is not enough if network paths, remote maintenance, legacy components or update mechanisms remain technically unresolved.
SECURE: Control vulnerabilities, verify effectiveness and create evidence
The SECURE phase connects technical assurance, vulnerability management and evidence.
An SBOM is important, but it is only the inventory. The effective process starts afterwards:
- identify the product and release unambiguously
- capture components and dependencies in an SBOM
- correlate known vulnerabilities with the product
- document exploitability using VEX or an equivalent assessment
- decide the risk and required action
- implement a patch, mitigation, advisory or release blocker
- preserve the decision and effectiveness as evidence
The terminology matters. CVE identifies a publicly known vulnerability. CVD means Coordinated Vulnerability Disclosure and describes the controlled process for receiving, handling and coordinating disclosure. VEX records whether and why a vulnerability affects a specific product or is not exploitable in that product context.
IT Kombinat can run the process for SBOM intake, vulnerability triage, VEX, findings, advisories, technical evidence and release gates. The manufacturer provides product-specific technical information, assesses findings with its engineering owners and develops the required patches or mitigations.
The technical file is built in parallel. It should bring together the product description, system boundaries, risk assessment, architecture, security controls, development and test evidence, vulnerability processes, component information, user instructions and the conformity route in a traceable structure.
A robust release gate prevents a product from being released while critical findings, missing evidence or unresolved residual risks remain open.
OPERATE: Build reporting readiness, tracking and lifecycle control
The CRA requires product security after market launch as well. This depends on operational processes and current product data.
From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security. The process includes an early warning within 24 hours and a full notification within 72 hours. For actively exploited vulnerabilities, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For severe incidents, the final report is due within one month of the full notification.
A PDF procedure is not reporting capability. The following information and decision paths must work under time pressure:
- time and source of awareness
- affected products, versions and installed base
- technical triage and assessment of active exploitation
- responsible PSIRT, engineering, product, legal and management roles
- immediate measures, customer communication and advisories
- access to the CRA Single Reporting Platform
- evidence preservation and documented approvals
IT Kombinat can support this capability as a managed CRA process office: coordinate intake and triage, monitor deadlines, consolidate information, track approvals, prepare notifications, preserve evidence and support management and customer communication. Where requested and formally authorised, IT Kombinat can also conduct external communication with the relevant authorities.
The manufacturer remains the technical owner. It provides the product-specific assessment, develops patches, decides on releases and approves notifications and external statements.
The OPERATE model also includes supplier monitoring, support and end-of-support communication, change-impact assessment, internal audits, CAPA, KPIs and regular management reviews. Tabletop exercises test whether roles, data and decisions are actually available within the statutory deadlines.
Examples of supporting tools and technical components
CRA readiness does not depend on a particular tool or product. Tools and security components can accelerate implementation when their purpose is clearly defined and their effectiveness is verified.
Example 1: CRANE for governance and evidence
We reviewed, among other tools, CRANE – the CRA Norm Engine. CRANE is a self-hosted open-source platform that combines a product registry, SBOM analysis, vulnerability management, VEX, risk assessments, release gates, an Annex I matrix, technical documentation and an audit trail. The project remains in active development and currently recommends technical oversight for production use.
CRANE is therefore an example of tooling that can connect products, releases, risks, findings and evidence in a structured way. It does not replace professional assessment or the manufacturer’s decision.
Example 2: edge.PSL from TRIOVEGA as a technical security component
For machine-building environments, we also reviewed edge.PSL from TRIOVEGA. TRIOVEGA positions edge.PSL as a protective security layer that can be integrated as an inseparable software component of a machine and is intended to support access control, segmentation, logging and SBOM, vulnerability and patch processes.
A component of this kind can reduce the technical burden of the security lifecycle. It does not replace assessment of the complete product. Its contribution must be verified for each machine and product variant through architecture, configuration, integration testing, update and recovery procedures and reliable supplier evidence.
CRANE and edge.PSL are examples at two different levels: governance and evidence on the one hand, technical product controls on the other. Other solutions may be more appropriate depending on the product, architecture and existing tool landscape.
The IT Kombinat CRA service model
IT Kombinat connects governance, security engineering and operational lifecycle management. Services can be delivered as individual modules, a joint project team or a managed CRA process office.
PLAN
- initial CRA workshop
- product scope, role and classification assessment
- CRA fit-gap and prioritised roadmap
- governance, RACI, decision and evidence model
- support and supplier model
BUILD
- cybersecurity risk assessments
- threat modelling and attack-path analysis
- security architecture and architecture reviews
- derivation of testable security requirements
- IEC 62443 mapping and IT/OT security design
- secure-development and security-testing concepts
SECURE
- SBOM/VEX and vulnerability-management process
- findings, actions and deadline tracking
- coordination of security testing and technical evidence
- technical file and evidence register
- release gates, pre-audit and remediation governance
OPERATE
- PSIRT and 24/72-hour reporting process
- lifecycle, support and installed-base governance
- supplier monitoring, advisories and change impact
- audits, KPIs, CAPA and management reporting
- authority communication where requested and approved
The customer remains the manufacturer and technical owner. It develops the product, implements security requirements, creates patches and makes the final product, risk and conformity decisions. IT Kombinat can run, document and continuously track the process around that work.
IT Kombinat provides technical and organisational support. This does not replace legal advice, the work of a notified body, the EU declaration of conformity or the final manufacturer decision.
Initial CRA workshop: a structured starting point
The most effective starting point is not a broad transformation programme. It is a focused workshop involving the relevant product, engineering, security, quality/CE, service and management roles.
In the initial CRA workshop, we jointly clarify:
- which products, variants and remote services are in scope
- which CRA roles and preliminary product categories apply
- where the most significant risks and evidence gaps exist
- which risk assessments, threat models and technical reviews are required
- how responsibilities should be divided between the manufacturer and IT Kombinat
- whether individual work packages or a managed CRA process office are appropriate
- which decisions, data and actions are required next
The outcome is an agreed target state with scope, responsibilities, prioritised work packages and a defensible next step.
Conclusion
The Cyber Resilience Act shifts cybersecurity from an optional product feature to a binding manufacturer obligation. The main challenge is not reading the regulation. It is building an end-to-end product security lifecycle that connects risk, architecture, development, supply chain, evidence and operations.
Risk assessments, threat modelling and security engineering form the technical core. Process ownership, documentation and tracking ensure that those technical decisions remain auditable and do not disappear over a long product lifecycle.
CRA readiness does not result from a single tool, an SBOM or a technical security component. It results from the interaction of governance, engineering, evidence and operational accountability.
The five control questions remain straightforward:
- Which product is affected?
- Which risk was assessed?
- Which control was implemented?
- Which evidence demonstrates effectiveness?
- Who owns the decision?
IT Kombinat supports manufacturers from the initial workshop through risk assessment, threat modelling and security architecture to the operational management of documentation, findings, reporting processes and lifecycle evidence.
Further reading
- European Commission: Cyber Resilience Act overview
- European Commission: Practical CRA guidance published on 27 July 2026
- European Commission: Manufacturer obligations
- European Commission: CRA reporting obligations
- European Commission: Conformity assessment
- BSI TR-03183: Cyber Resilience Requirements for Manufacturers and Products
- CRANE – CRA Norm Engine
- TRIOVEGA edge.PSL
