CYBER RESILIENCE ACT
Cyber resilience across products, lifecycle and market access.
The Cyber Resilience Act establishes horizontal cybersecurity requirements for hardware, software and other products with digital elements placed on the Union market, extending across design, development, vulnerability handling, conformity and the product lifecycle.
OSTRAI advises organisations on the application and implementation of the CRA, from scope, product determination and economic-operator roles to cybersecurity risk assessment, product requirements, conformity, reporting, market access and continuing compliance.
Principal EU regime
Cyber Resilience Act
Scope · Product classification · Cybersecurity risk · Lifecycle · Vulnerabilities · Conformity · Reporting · Market access
Principal focus: European regulation · International perspective
Discuss a CRA regulatory matter
REGULATORY ARCHITECTURE
Product cybersecurity does not begin and end with technical security.
The CRA reaches across product design, cybersecurity risk, economic-operator responsibility, vulnerability handling, conformity and continuing obligations for products with digital elements made available on the Union market.
Analysis begins with applicability, the regulated product, the economic-operator role and classification. Software architecture, remote data processing, free and open-source software, integrated components, product changes and other Union legislation may affect that position.
SCOPE & PRODUCT POSITION
Products with digital elements · Software · Hardware · Components · Remote data processing · Exclusions
ECONOMIC-OPERATOR RESPONSIBILITY
Manufacturer · Importer · Distributor · CRA authorised representative · Other actors
RISK, LIFECYCLE & VULNERABILITIES
Cybersecurity risk · Product requirements · Components · Vulnerability handling · Support period · Product change
CLASSIFICATION, CONFORMITY & MARKET ACCESS
Core functionality · Product category · Technical documentation · Conformity · CE marking · Reporting · Market surveillance
CURRENT IMPLEMENTATION
The CRA applies through a phased timetable.
The Cyber Resilience Act is applying progressively. Certain institutional and manufacturer reporting requirements are already applicable. Most substantive product, manufacturer and conformity requirements apply from 11 December 2027.
Provisions concerning notification of conformity assessment bodies apply.
Manufacturer reporting obligations apply for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
The Cyber Resilience Act applies in full.
Reporting is now live
Mandatory manufacturer notifications are submitted through the ENISA CRA Single Reporting Platform.
The reporting regime also applies to in-scope products already placed on the Union market before full CRA application.
CRA ADVISORY & IMPLEMENTATION
From product scope to continuing compliance.
OSTRAI supports organisations in establishing the CRA regulatory position and translating the Regulation into a workable product, lifecycle, conformity and market-access programme.
SCOPE, SOFTWARE & PRODUCT DETERMINATION
Assessment of products with digital elements, standalone software, hardware/software combinations, components, connectivity, commercial activity, exclusions, product boundaries and CRA applicability.
REMOTE DATA PROCESSING, FOSS & DEPENDENCIES
Assessment of remote data processing, connected processing, external services, free and open-source software status, software stewardship, third-party components and product dependencies.
CORE FUNCTIONALITY, PRODUCT CLASSIFICATION & REGULATORY ROLES
Determination of the product's core functionality, assessment of ancillary and integrated functionality, classification as Default, Important Class I, Important Class II or Critical, and manufacturer/importer/distributor/CRA authorised-representative responsibility mapping.
CYBERSECURITY RISK & PRODUCT REQUIREMENTS
Product context, intended purpose, reasonably foreseeable use, cybersecurity risk assessment, applicable cybersecurity requirements, risk treatment, regulatory controls and implementation planning.
LIFECYCLE, EVIDENCE & VULNERABILITY HANDLING
Implementation evidence, component due diligence, SBOM, coordinated vulnerability disclosure, vulnerability contact points, security-update governance, support-period assessment, product monitoring, documentation and product-change analysis.
CONFORMITY, REPORTING & MARKET ACCESS
Technical documentation, conformity-pathway analysis, declaration of conformity, CE marking, conformity readiness, CRA reporting, ENISA platform support, user-notification support, corrective-action planning, market-surveillance interface and EU market access.
SPECIALIST CRA SERVICES
Focused support for specific CRA obligations.
Alongside our broader Cyber Resilience Act advisory practice, OSTRAI provides specialist support for regulatory representation and operational CRA reporting.
CRA AUTHORISED REPRESENTATIVE
Article 18 representation for manufacturers that choose to establish a defined EU regulatory interface from 11 December 2027.
Article 18 mandate · EU regulatory interface · Regulatory-documentation arrangements · Market-surveillance communications · Authority cooperation · Article 14(7) reporting-nexus analysis for manufacturers with no EU main establishment
Explore CRA Authorised RepresentativeCRA REPORTING & ENISA PLATFORM SUPPORT
Operational support for Article 14 reporting of actively exploited vulnerabilities and severe incidents.
Reportability assessment · 24-hour / 72-hour / final-report workflow · ENISA Single Reporting Platform · Assigned Representative support · Impacted-user communications · Regulatory follow-up
Explore CRA Reporting Support
SCOPE & PRODUCT DETERMINATION
The regulated product is not always obvious.
The CRA can apply to software, hardware and certain components where the relevant scope conditions are met. Analysis may require determining when a product is placed on the Union market, distinguishing products from remotely provided services, defining the product boundary and assessing how remote data processing and external dependencies affect that boundary.
Browser-accessed web applications and websites are not generally products with digital elements in themselves, although remote data processing may form part of another regulated product where the relevant CRA conditions are met.
STANDALONE SOFTWARE
Software supplied to users for installation or operation on their electronic information systems.
HARDWARE + SOFTWARE
Products whose functionality depends on software supplied separately or through another channel.
REMOTE DATA PROCESSING
Data processing at a distance that may form part of the regulated product where the relevant CRA conditions are satisfied.
EXTERNAL DEPENDENCIES
Services, infrastructure or third-party components that may sit outside the regulated product boundary but still generate cybersecurity risks requiring product-level assessment and mitigation.
REMOTE DATA PROCESSING
Where does the regulated product end?
Certain remote data processing can form part of the regulated product. The assessment turns on whether processing takes place at a distance, whether its absence would prevent the product from performing one of its functions, and whether the relevant software was designed and developed by or under the responsibility of the manufacturer.
Where a third-party remote solution does not form part of the regulated product, it may nevertheless create cybersecurity risks or dependencies that require product-level controls and due diligence.
- 01
IS PROCESSING PROVIDED AT A DISTANCE?
- 02
WOULD ITS ABSENCE PREVENT A PRODUCT FUNCTION?
- 03
WAS THE RELEVANT SOFTWARE DESIGNED AND DEVELOPED BY, OR UNDER THE RESPONSIBILITY OF, THE MANUFACTURER?
PART OF THE REGULATED PRODUCT
orEXTERNAL DEPENDENCY / COMPONENT ANALYSIS
OPEN SOURCE & COMPONENTS
Supply-chain responsibility extends into software components.
The CRA treats free and open-source software differently depending on whether it is supplied in the course of a commercial activity, whether an entity qualifies as an open-source software steward, and whether a downstream manufacturer integrates the component into its own product.
Manufacturers integrating third-party components must exercise appropriate due diligence and address cybersecurity risks arising from those components and their integration.
OSTRAI supports FOSS status and commercial-activity analysis, steward assessments, downstream responsibility analysis, component due diligence and integration of component risk into CRA implementation programmes.
FOSS status · Commercial activity · Steward analysis · Downstream responsibility · Component due diligence · SBOM
CORE FUNCTIONALITY & PRODUCT CLASSIFICATION
Classification turns on core functionality.
The CRA framework distinguishes Important Class I, Important Class II and Critical products. Products whose core functionality does not place them within those categories are treated here as the Default category.
Product classification depends on core functionality, meaning the product's main features and technical capabilities without which it would not be able to meet its intended purpose, rather than simply on every function, feature or component incorporated into it.
An integrated component or functionality associated with an Important or Critical category does not automatically classify the overall product that way. Conversely, ancillary functionality does not prevent that classification where the product's core functionality corresponds to the category.
OSTRAI supports manufacturers in determining core functionality, assessing the product against the applicable technical descriptions, distinguishing core from ancillary or integrated functionality, documenting the classification rationale and determining the resulting conformity pathway.
- 01
PRODUCT FUNCTION
What does the product actually do?
- 02
CORE FUNCTIONALITY
Which technical capabilities are central to its intended purpose?
- 03
TECHNICAL DESCRIPTION
Does that core functionality correspond to a regulated product category?
- 04
PRODUCT CATEGORY
Default · Important Class I · Important Class II · Critical
- 05
CONFORMITY PATHWAY
Determine the applicable route to demonstrate conformity.
PRODUCT CYBERSECURITY LIFECYCLE
Cybersecurity becomes a lifecycle obligation.
The CRA requires manufacturers to integrate cybersecurity risk assessment, product cybersecurity requirements and vulnerability handling into the product lifecycle rather than treating cybersecurity as a one-off market-entry exercise.
- 01
DEFINE & ASSESS
Product context · Intended purpose · Reasonably foreseeable use · Architecture · Cybersecurity risks
- 02
REQUIRE & DESIGN
Cybersecurity requirements · Secure design · Components · Dependencies · Controls
- 03
IMPLEMENT & VERIFY
Implementation evidence · Secure development and production · Verification · Validation · Technical documentation
- 04
SUPPORT & MONITOR
Vulnerabilities · Security updates · Support period · Components · Product monitoring · User information · Support-end transparency
- 05
REPORT & RESPOND
Actively exploited vulnerabilities · Severe incidents · User communications · Corrective action · Product change · Market surveillance
CYBERSECURITY RISK ASSESSMENT
Risk assessment drives the implementation pathway.
Manufacturers must assess product cybersecurity risks throughout planning, design, development, production, delivery and maintenance, considering intended purpose, foreseeable use, operating environment, assets, dependencies, threat exposure and applicable requirements.
The manufacturer's commercial risk appetite is not, by itself, the regulatory benchmark for accepting product cybersecurity risk.
OSTRAI supports risk-assessment structuring, product-context analysis, requirements mapping, risk-treatment documentation, implementation evidence and coordination with product, technical and security teams.
CONTINUING PRODUCT COMPLIANCE
Market entry is not the end of compliance.
Manufacturers must maintain vulnerability-handling processes during the support period and keep cybersecurity risk assessments and technical documentation current.
The support period reflects expected use, product nature, reasonable user expectations, dependencies and component support. It is at least five years unless expected use is shorter. Products reasonably expected to remain in use for longer should accordingly have longer support periods.
Manufacturers must also make the end date of the support period clear to users at the time of purchase and, where technically feasible, notify users when the support period has ended.
Security updates made available during the support period must remain available for at least ten years after issue or for the remainder of the support period, whichever is longer.
Updates, new functionality and other changes require assessment of their regulatory and substantial-modification consequences. Where a change constitutes a substantial modification and the modified product is made available on the market, it can trigger a new regulatory and conformity position.
Security updates that reduce cybersecurity risk without changing the intended purpose or introducing new cybersecurity risks are not automatically substantial modifications.
SUPPORT PERIOD
Expected use · User expectations · Product nature · Component support · Support-end transparency
VULNERABILITY HANDLING
Coordinated vulnerability disclosure · Vulnerability contact point · Remediation · Security updates · SBOM · User communications
PRODUCT CHANGE & CONTINUING CONFORMITY
Design changes · Development changes · New functionality · Cybersecurity impact · Substantial modification · Conformity consequences
POST-MARKET CORRECTIVE ACTION
Corrective measures · Product remediation · Withdrawal / recall strategy · Authority engagement
CONFORMITY ASSESSMENT & CERTIFICATION
Navigate the route from CRA requirements to market access.
CRA conformity assessment is not a single process.
The applicable route depends on the product category, its core functionality, applicable harmonised standards or common specifications and, where relevant, the availability of a qualifying European cybersecurity certification scheme.
OSTRAI supports manufacturers in determining the applicable route, preparing the conformity evidence and coordinating independent third-party assessment where required.
DEFAULT CATEGORY
Internal control is available for products in the Default category. Manufacturers may alternatively choose a stricter conformity route involving third-party assessment or, where applicable, a qualifying European cybersecurity certification route.
IMPORTANT CLASS I
Internal control can be available where the applicable requirements of the relevant harmonised standards, common specifications or qualifying cybersecurity certification scheme are applied in full and the relevant instrument adequately covers the cybersecurity risks associated with the product's core functionality.
Where those conditions are not met, including where the relevant instruments do not exist or are applied only in part, third-party conformity assessment is required.
- EU-type examination (Module B) followed by conformity to type (Module C)
- Full quality assurance (Module H)
IMPORTANT CLASS II
Important Class II products require third-party conformity assessment.
- EU-type examination (Module B) followed by conformity to type (Module C)
- Full quality assurance (Module H)
- Where available and applicable, a qualifying European cybersecurity certification scheme at the required assurance level
CRITICAL PRODUCTS
Critical products follow the applicable European cybersecurity certification route where such certification is mandated for the category.
Where that specific certification requirement does not apply, the conformity pathways available to Important Class II products apply.
Qualifying free and open-source products within the Important categories may use the general conformity routes, including internal control, where the required technical documentation is made publicly available when the product is placed on the market.
CONFORMITY-ROUTE ASSESSMENT
Determine the applicable Article 32 pathway based on the product classification, standards position and certification landscape.
ASSESSMENT READINESS
Assess whether the manufacturer’s cybersecurity risk assessment, Annex I evidence, technical documentation and processes are ready for conformity assessment.
TECHNICAL DOCUMENTATION
Prepare, structure and review the Article 31 / Annex VII documentation package and associated conformity evidence.
STANDARDS & EVIDENCE MAPPING
Map applicable harmonised standards, common specifications, cybersecurity certification schemes and other technical evidence against the relevant CRA requirements.
INDEPENDENT-BODY COORDINATION
Where third-party assessment is required or selected, OSTRAI can coordinate engagement with an appropriately scoped notified body or, where applicable, certification body.
FINDINGS & REMEDIATION
Support responses to assessment questions, evidence requests, identified gaps and remediation actions.
CRA IMPLEMENTATION & CONFORMITY
From CRA requirements
to implementation and assessment.
OSTRAI supports manufacturers not only in preparing for conformity assessment, but in translating the Cyber Resilience Act into the underlying compliance framework that the assessment must evidence.
Our work can extend from scope, classification and cybersecurity risk assessment through Annex I implementation, vulnerability handling, technical documentation, standards mapping, conformity readiness and independent assessment coordination.
The manufacturer retains the statutory responsibility for product compliance. OSTRAI supports the regulatory, governance, documentation and implementation work needed to build and evidence that compliance.
CRA IMPLEMENTATION
MANUFACTURER + OSTRAI
Build the compliance framework behind the product.
OSTRAI support may include:
- CRA scope and product determination
- economic-operator role analysis
- product classification
- cybersecurity risk assessment
- Annex I requirements mapping
- gap assessment
- implementation planning
- component due diligence
- SBOM framework
- coordinated vulnerability disclosure
- vulnerability-handling processes
- security-update governance
- support-period analysis
- product-change / substantial-modification analysis
- internal responsibilities and escalation
- regulatory documentation architecture
Where technical product controls must be designed or implemented, OSTRAI works with the manufacturer’s product, engineering and cybersecurity teams and, where appropriate, specialist technical providers.
The manufacturer remains responsible for the product and its CRA compliance.
CONFORMITY EVIDENCE & READINESS
MANUFACTURER + OSTRAI
Turn implementation into assessable evidence.
- Article 31 / Annex VII technical documentation
- cybersecurity risk-assessment evidence
- Annex I requirement-to-evidence mapping
- test and verification evidence
- vulnerability-handling evidence
- standards mapping
- conformity-route analysis
- EU declaration readiness
- CE-marking readiness
- notified-body readiness where applicable
- pre-assessment gap review
INDEPENDENT ASSESSMENT
WHERE REQUIRED
Where the applicable CRA conformity route requires or the manufacturer selects independent third-party assessment, OSTRAI can support identification and engagement of an appropriately scoped notified body or, where applicable, certification body.
OSTRAI can coordinate:
- engagement
- documentation package
- evidence submission
- assessment questions
- technical / regulatory clarifications
- findings
- remediation workstreams
- resubmission / follow-up
The independent body remains responsible for:
- its assessment
- findings
- approval or certification decision
- any certificate it issues
MARKET ACCESS & CONTINUING COMPLIANCE
MANUFACTURER + OSTRAI
Support the transition from assessment into continuing CRA compliance.
- EU declaration of conformity
- CE-marking support
- product-market placement
- support-period governance
- vulnerability handling
- Article 14 reporting
- security updates
- technical-documentation maintenance
- corrective action
- market-surveillance response
- product-change assessment
Conformity assessment: questions & answers
Does every CRA product require third-party certification?
No.
The required conformity-assessment route depends on the product category and applicable Article 32 conditions.
Some products can use manufacturer-led internal control, while important Class II products and certain other cases require third-party involvement. Critical products may also be subject to European cybersecurity certification where the relevant CRA conditions apply.
Does OSTRAI itself issue CRA certificates?
OSTRAI does not itself act as a notified body or independent certification body.
We support conformity-route analysis, assessment readiness, technical documentation, standards mapping and coordination with independent notified or certification bodies where required.
Can OSTRAI introduce or coordinate with a notified body?
Yes.
OSTRAI maintains professional relationships with relevant conformity-assessment and certification organisations and can coordinate engagement with an appropriately scoped independent body where required.
Selection remains dependent on the product, conformity route, notified scope, availability and independence requirements.
HARMONISED STANDARDS & REGULATORY EVIDENCE
Harmonised standards can translate CRA cybersecurity requirements into technical specifications and can materially affect how manufacturers demonstrate conformity.
Even where a harmonised standard is used, the manufacturer remains responsible for assessing the product's cybersecurity risks and addressing requirements or risks that fall outside the scope of the standard.
Standards mapping · Requirement-to-evidence analysis · Conformity-pathway assessment · Documentation strategy · Conformity readiness
Direct standardisation involvement
OSTRAI contributes directly to European standardisation work supporting implementation of the Cyber Resilience Act through CEN/CENELEC JTC 13.
This gives our regulatory work direct insight into how CRA cybersecurity requirements are being translated into European technical standards and conformity evidence.
The regulatory effect of a standard depends on its status and coverage. A presumption of conformity arises only to the extent that a harmonised standard referenced in the Official Journal covers the relevant CRA requirements.
See Standards & StandardisationCRA REPORTING
Product-security reporting is now operational.
Manufacturers are now subject to mandatory CRA reporting for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.
The reporting regime also applies to in-scope products placed on the Union market before full CRA application.
OSTRAI supports reportability assessment, internal escalation, coordination of technical and regulatory information, preparation and management of regulatory notifications, reporting timelines, impacted-user communications and the authority-facing process.
ACTIVELY EXPLOITED VULNERABILITY
- 24 hours
- Early warning
Without undue delay and in any event within 24 hours of awareness.
- 72 hoursWithin 72 hours of awareness
- Vulnerability notification
Product information · Nature of exploit and vulnerability · Corrective or mitigating measures · User mitigation information
- Final report
- No later than 14 days after a corrective or mitigating measure is available.
SEVERE INCIDENT
- 24 hours
- Early warning
Without undue delay and in any event within 24 hours of awareness.
- 72 hoursWithin 72 hours of awareness
- Incident notification
Nature of incident · Initial assessment · Corrective or mitigating measures · User mitigation information
- Final report
- Within one month after submission of the 72-hour incident notification.
USER COMMUNICATIONS
Following an actively exploited vulnerability or severe incident, manufacturers must inform impacted users and, where appropriate, other users about the vulnerability or incident and, where necessary, the risk-mitigation and corrective measures they can take.
ENISA Single Reporting Platform support
OSTRAI supports manufacturers with the management of CRA notifications through the ENISA Single Reporting Platform, including preparation and management of the Early Warning, 72-hour Notification and Final Report stages.
OSTRAI can provide Assigned Representative support through an appropriately authorised OSTRAI professional registered in the platform as the manufacturer's Assigned Representative. The registered representative can submit and update notifications on the manufacturer's behalf.
The manufacturer remains responsible for ensuring that its CRA reporting obligations are fulfilled.
The ENISA SRP Assigned Representative role is distinct from the CRA authorised representative role.
Explore CRA Reporting & ENISA Platform Support
EU MARKET ACCESS
Regulatory positioning across the product supply chain.
CRA responsibilities differ for manufacturers, importers, distributors and other economic operators. For third-country manufacturers, the EU importer has its own obligations before placing products on the Union market. From 11 December 2027, a manufacturer may separately appoint an EU-established CRA authorised representative for specified tasks under a written mandate.
OSTRAI advises manufacturers and EU economic operators on market-entry structure, regulatory-role allocation, documentation, conformity, market-surveillance interface and continuing obligations.
CRA authorised representation
From 11 December 2027, a manufacturer may appoint an EU-established CRA authorised representative for specified tasks under a written mandate. OSTRAI supports manufacturers preparing Article 18 representative structures and will provide authorised-representative services under agreed mandates once Article 18 applies.
REGULATORY INTERSECTIONS
Product cybersecurity does not operate in regulatory isolation.
The CRA may operate alongside AI, organisational cybersecurity, data-protection and sector-specific product frameworks. The correct regulatory position depends on the product, economic operator and applicable legislation.
AI ACT
Products with digital elements that are also high-risk AI systems can engage the specific CRA/AI Act interface for cybersecurity and conformity. Other requirements of the respective regimes remain distinct.
NIS2
The CRA regulates product cybersecurity, while NIS2 regulates cybersecurity risk management and incident obligations for entities within its scope. Organisations may need coordinated product and organisational cybersecurity programmes.
DATA PROTECTION
Where products process personal data, CRA cybersecurity requirements may operate alongside GDPR security, accountability and data-protection obligations.
SECTORAL PRODUCT REGULATION
CRA scope and conformity must be assessed alongside applicable Union product legislation, including relevant exclusions and overlapping sector-specific requirements.
REGULATORY INTELLIGENCE
CRA implementation continues to develop.
CRA implementation continues through Commission guidance, technical product descriptions, delegated and implementing measures, European standardisation, conformity infrastructure, ENISA reporting practice and market-surveillance activity.
OSTRAI follows these developments to assess how they affect product scope, classification, implementation, conformity, reporting and market access.
SPECIALIST CRA SUPPORT
Need support with a specific CRA function?
CRA AUTHORISED REPRESENTATIVE
Article 18 representation and EU regulatory interface.
Explore CRA Authorised RepresentativeCRA REPORTING & ENISA PLATFORM SUPPORT
Article 14 reporting, ENISA platform support and regulatory coordination.
Explore CRA Reporting SupportCYBER RESILIENCE ACT
Establish the CRA regulatory pathway for your product.
OSTRAI helps organisations determine what applies, establish the product and economic-operator position, and structure the pathway to cybersecurity implementation, conformity, reporting, market access and continuing compliance.