The practical value of CRA harmonised standards is traceability. A manufacturer can use a recognised technical route for covered requirements, document whether the standard is applied fully or partly and focus additional evidence on requirements or product risks not covered by that standard. The critical legal checkpoint is the Official Journal reference, not simply the existence of a published European or international standard.
Article 27 Creates the Presumption of Conformity Framework
Article 27 states that products with digital elements and manufacturer processes conforming to harmonised standards, or parts of them, whose references have been published in the Official Journal are presumed to conform with the Annex I essential cybersecurity requirements covered by those standards or parts. The presumption reduces the burden of demonstrating those covered requirements from first principles, but it does not extend beyond the scope actually covered.
- Confirm Official Journal publication.
- Identify covered Annex I requirements.
- Record full or partial application.
- Keep uncovered requirements in the compliance plan.
A Published Standard Is Not Automatically a CRA Harmonised Standard
CEN, CENELEC, ETSI, ISO, IEC and other organisations publish standards that can be technically relevant to cybersecurity. For CRA Article 27 presumption of conformity, the important legal event is publication of the harmonised standard reference in the Official Journal. Companies should therefore maintain separate fields for technical standard use and Article 27 harmonised status instead of treating them as the same thing.
- Record the standard and version.
- Record whether it is harmonised for CRA purposes.
- Record the Official Journal reference where applicable.
- Record the CRA requirements covered.
Presumption of Conformity Is Limited to Covered Requirements
A harmonised standard can cover only part of Annex I or only particular product-security questions. Article 27 ties the presumption to the requirements covered by the standard or part. Manufacturers should therefore build a requirement-level matrix rather than mark the entire product as compliant because one harmonised standard has been applied.
- Map clauses to Annex I requirements.
- Identify scope limitations.
- Identify product-specific residual risks.
- Collect separate evidence for uncovered requirements.
CRA Standardisation Includes Horizontal and Product-Specific Work
The Commission states that standardisation request M/606 contains 41 standards, including horizontal and product-specific work. Horizontal standards are intended to support common processes and technical approaches across product categories. Product-specific standards can translate CRA requirements for particular technologies and risk profiles. Manufacturers should watch both because a horizontal process standard and a vertical product standard may address different parts of the same compliance case.
- Track horizontal requirements.
- Track product-specific requirements.
- Identify which standards apply to the product family.
- Avoid double-counting overlapping evidence.
Harmonised Standards Can Affect Conformity Assessment Routes
Article 32 links the availability and application of harmonised standards, common specifications and certain European cybersecurity certification schemes to conformity assessment options for important and critical products. A standards decision can therefore affect more than technical design. It can also affect whether a manufacturer may rely on internal control or must use a third-party route for particular essential requirements.
- Connect standards status to product classification.
- Connect standards application to the Article 32 route.
- Reassess the route if standards status changes.
- Keep the decision in conformity documentation.
Technical Documentation Must Record Standards Applied
Annex VII requires technical documentation to include a list of harmonised standards applied in full or in part, together with common specifications or relevant certification schemes. Where those routes are not applied, the manufacturer must describe the solutions used to meet the Annex I essential cybersecurity requirements. Standards mapping should therefore feed the technical file directly rather than exist only in an engineering spreadsheet.
- List standards and versions.
- State full or partial application.
- Identify covered requirements.
- Describe alternative solutions where standards are not applied.
Standards Do Not Replace the Article 13 Risk Assessment
Article 13 requires a cybersecurity risk assessment and requires its outcome to be considered throughout the product lifecycle. Applying a harmonised standard can support technical and process requirements, but it does not remove the need to understand the product's assets, intended purpose, reasonably foreseeable use, threats and residual risks. A standard should be used as part of the product-specific compliance argument, not as a substitute for it.
- Maintain product-specific risk assessment.
- Use standards as controls and evidence.
- Assess residual risk after standard application.
- Update the risk assessment when the product changes.
Standards Versions and References Need Change Control
Article 13 requires manufacturers to take account of changes in harmonised standards, certification schemes and common specifications by reference to which conformity is declared or verified. A company should therefore track the exact standard version, Official Journal status, transition information and product releases that rely on it. Standards management becomes part of continued conformity rather than a one-time pre-market task.
- Track exact versions.
- Track Official Journal status.
- Assess amendments and replacements.
- Connect changes to affected product releases.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.