On 21 September 2026, representatives of European and national authorities, standardisation experts, manufacturers, industry, conformity assessment and legal practice met at Hilton Nicosia for “Building CRA Compliance through Horizontal Cybersecurity Standards”, organised by the Cyprus Organisation for Standardisation (CYS), with the support of the Digital Security Authority and within the framework of the STAN4CR initiative.

The timing gave the discussion particular relevance, because the CRA’s reporting obligations had started to apply only ten days earlier, on 11 September 2026, while the Regulation’s broader obligations will apply from December 2027, meaning that the debate has already moved beyond the question of what the CRA requires in principle and towards the more difficult issue of how those requirements will be translated into product development, conformity assessment, technical evidence and regulatory supervision in practice.

Conference stage and lectern displaying Building CRA Compliance through Horizontal Cybersecurity Standards.
Building CRA Compliance through Horizontal Cybersecurity Standards, Hilton Nicosia, 21 September 2026.

The horizontal standards are taking shape

At the centre of the conference was the work of CEN-CENELEC JTC 13 Working Group 9 on the horizontal cybersecurity standards that are intended to provide the common foundation for CRA implementation, covering terminology and definitions, cybersecurity principles, product risk management and lifecycle activities, vulnerability handling, and generic security requirements.

At the time of the conference, the vocabulary and product risk management standards were already progressing through Formal Vote, the vulnerability-handling standard was being finalised following further European Commission comments, and the generic security requirements remained at an earlier stage of development, although the discussions throughout the day made clear that the legal effect of these standards will not be identical.

Among the horizontal standards, prEN 40000-1-3 on vulnerability handling is the one intended to support a presumption of conformity with the corresponding CRA requirements, subject to the assessment process and eventual citation in the Official Journal of the European Union, while product-specific vertical harmonised standards are also being developed to support presumption of conformity within the product categories and requirements they cover.

The remaining horizontal standards perform a different but no less important function, because they provide the common concepts, processes and technical structure upon which implementation and assessment can build, even though they should not be treated as though their application, by itself, produces the same legal effect as a harmonised standard intended to confer presumption of conformity.

Security cannot be reduced to a checklist

Ben Kokx, Convenor of CEN-CENELEC JTC 13 WG9, used his presentation not simply to update participants on the progress of the standards, but to reflect on the principles and compromises underlying their development, with one of his central messages being that security is a process rather than a checklist.

That distinction is particularly important in the context of horizontal standards, because the same framework must be capable of accommodating products with very different functions, operating environments, threat models and consequences of compromise, which means that the drafting exercise cannot simply consist of identifying a fixed list of controls and applying them indiscriminately across the market.

As Mr Kokx explained, the difficulty is fundamentally one of proportionality, because a level of rigour that may be justified for a product used in critical infrastructure could be disproportionate for a much lower-risk product, while a standard designed around the lowest common denominator could equally fail to provide sufficient assurance where the consequences of compromise are materially greater.

The challenge for the horizontal standards is therefore to achieve sufficient precision to support assessment and legal certainty, while retaining enough flexibility to reflect product-specific risk and technological change, a balance that will remain central not only to the drafting of the standards themselves, but also to their application by manufacturers and conformity assessment bodies.

Mr Kokx also drew a useful boundary between standardisation and enforcement, noting that standards are intended to establish what manufacturers need to do and demonstrate in order to support conformity with legal requirements, whereas identifying and dealing with deliberately non-compliant operators remains a matter for market surveillance.

That distinction places harmonised standards in their proper regulatory context: they may structure and support the conformity assessment process, and in appropriate cases provide presumption of conformity, but they remain part of a wider legal and supervisory framework rather than a substitute for it.

The standard is not the starting point

The relationship between the standards and the Regulation itself was examined further during the afternoon “Dialogue with the Stakeholders” panel, which brought together perspectives from standardisation, industry, consultancy, conformity assessment and law, including Maria Raphael, Founder and Managing Director of OSTRAI.

Participants seated on stage for the Dialogue with the Stakeholders panel at the Cyprus CRA conference.
The “Dialogue with the Stakeholders” panel at Building CRA Compliance through Horizontal Cybersecurity Standards, Hilton Nicosia, 21 September 2026.

Approaching the discussion from the legal perspective, Ms Raphael cautioned against treating CRA implementation as a paperwork exercise, because the starting point for a manufacturer is not simply to identify a standard and begin documenting against it, but first to determine whether the CRA applies to the product, identify its core functionality, establish its classification and understand the conformity assessment procedure that follows from that classification.

Only once those questions have been addressed can the role of the relevant horizontal or vertical standards be properly understood, since the applicability of a standard, the requirements it addresses and the evidential or legal effect of relying upon it all depend on decisions that precede the application of the standard itself.

This led to a wider distinction between conformity assessment and compliance with the Regulation as a whole, because standards may provide an important technical framework through which conformity with particular essential cybersecurity requirements can be demonstrated, but they do not address every legal obligation imposed on manufacturers by the CRA.

Ms Raphael summarised the point succinctly:

“Conformity does not exhaust compliance.”

Reporting provides one of the clearest examples, since a vulnerability-handling standard may establish requirements concerning the identification, assessment and remediation of vulnerabilities, while the obligation to notify an actively exploited vulnerability contained in the product with digital elements, or a severe incident having an impact on the security of the product with digital elements, arises directly from the Regulation.

The same wider legal analysis applies to questions of scope, core functionality, intended purpose, reasonably foreseeable use, classification and the cybersecurity risk assessment, all of which require legal and technical judgment before the manufacturer can properly determine which standards are relevant, what they cover and what still needs to be addressed separately.

Risk assessment and evidence emerged as common ground

One of the clearest points of convergence across the legal, technical and conformity assessment discussions was the cybersecurity risk assessment, which was repeatedly presented not as an ancillary document prepared at the end of the process, but as the analytical starting point for understanding the product, its operating environment, the risks associated with it and the security measures adopted in response.

From the conformity assessment perspective, particular emphasis was placed on the need to preserve evidence as the compliance programme develops, including records of security testing, vulnerability analysis and the reasoning supporting security decisions, because evidence created contemporaneously with product development and risk management will be considerably more valuable than documentation reconstructed shortly before the CRA becomes fully applicable.

Ms Raphael addressed the same issue from the legal side, emphasising that the cybersecurity risk assessment is not merely supporting evidence for a conformity assessment body, but a legal obligation in its own right and a foundational element of CRA implementation, because the risks identified through that process inform product design, determine which requirements need to be addressed and shape the way those requirements are implemented.

The legal and technical dimensions of the CRA therefore meet at precisely this point, since the eventual technical documentation should not merely show that particular controls exist, but should make it possible to understand the relationship between the product, the risks identified, the measures selected and the evidence demonstrating how those measures were implemented.

What exactly does the standard cover?

The conference also highlighted a question that is likely to become increasingly important as the product-specific standards develop, namely the extent to which a particular standard actually covers the product and the relevant CRA requirements.

The existence of a vertical standard does not necessarily mean that every aspect of a composite product has been addressed, because a product-specific standard may focus on the product’s core functionality, while other functions, components or risks remain outside its scope and therefore require consideration through horizontal standards, other relevant technical specifications or additional assessment.

Similarly, even where a harmonised standard is ultimately cited in the Official Journal, the presumption of conformity it provides will relate only to the requirements covered by that standard and within the scope of its citation, which means that manufacturers will need to understand not merely whether a standard exists, but exactly what legal and technical work it performs.

The relevant question is therefore unlikely to be simply “Which standard applies to my product?”, but rather what that standard covers, which CRA requirements fall within that coverage, whether applying it gives rise to a presumption of conformity and what remains to be assessed or demonstrated separately.

This becomes particularly important for products that integrate third-party components, because evidence supplied by component manufacturers may contribute to the assessment of the final product, but it does not automatically resolve the risks created through integration, configuration or interaction between components once the composite product is placed on the market.

Manufacturers should not wait for a completed standards landscape

Another consistent message from the conformity assessment discussions was that the absence of a complete harmonised standards landscape does not prevent manufacturers from undertaking meaningful CRA work now, because much of the underlying preparation is independent of the final status of any particular standard.

Manufacturers can already perform cybersecurity risk assessments, review security testing and vulnerability-handling processes, identify technical evidence, examine component and supplier information, and assess how existing cybersecurity standards or certification frameworks may support the future conformity assessment process, while at the same time identifying the gaps that will still need to be addressed.

The practical task is therefore not to wait for the standards to answer every question, but to understand what evidence already exists, determine how it relates to the CRA and begin addressing the areas where additional work will be required, so that the eventual conformity assessment is supported by an established compliance process rather than by documentation assembled retrospectively.

Market surveillance will examine the reasoning behind the file

The second panel of the conference brought together national cybersecurity and market surveillance authorities, whose interventions reinforced the importance of being able to explain the reasoning underlying the manufacturer’s compliance position rather than merely producing a collection of standards, certificates and test reports.

Cyprus’ Digital Security Authority outlined its responsibilities under the CRA, including functions connected with conformity assessment bodies, market surveillance and the reporting framework, while the broader discussion among the national authorities emphasised that manufacturers should understand the Regulation itself, identify their obligations and maintain technical documentation capable of showing how the relevant risks and requirements were addressed.

From a market surveillance perspective, the technical file will therefore need to make it possible to understand what risks were identified, which measures were selected, which standards or technical specifications were relied upon, what evidence supports the implementation of those measures and how any remaining gaps were treated.

Applying a relevant standard may materially strengthen the manufacturer’s position, and where the conditions for presumption of conformity are satisfied it may have an important legal effect, but it does not remove the manufacturer’s responsibility for the overall regulatory position of the product.

Reporting obligations are already applicable

For manufacturers, one significant part of the CRA is no longer prospective, because Article 14 has applied since 11 September 2026 and requires manufacturers that become aware of an actively exploited vulnerability contained in the product with digital elements, or a severe incident having an impact on the security of the product with digital elements, to notify the relevant authorities through the CRA reporting framework.

The notification process is staged, beginning with an early warning submitted without undue delay and, in any event, within 24 hours of the manufacturer becoming aware of the relevant vulnerability or incident, followed by the further notifications and final reporting required by Article 14 within the applicable statutory periods.

These obligations require more than the existence of a written reporting policy, because manufacturers need an operational process capable of identifying the relevant event, escalating it internally, determining whether the legal threshold has been met, gathering the necessary information and completing the required notifications within the prescribed timeframe.

For organisations that are also subject to other cybersecurity regimes, internal incident-management processes may of course be coordinated where appropriate, but the CRA reporting obligation remains legally distinct, with its own terminology, thresholds, recipients and deadlines, and should therefore be treated as such.

From legislation to implementation

The discussions in Nicosia reflected a regulatory framework that is now moving decisively from legislative design into implementation, with the horizontal standards advancing through their respective development stages, product-specific standards progressing alongside them, conformity assessment bodies considering the evidence that manufacturers will need to produce, national authorities preparing their supervisory functions and the first CRA obligations already applicable.

Manufacturers therefore do not need, and should not expect, to wait until the entire standards landscape is complete before beginning substantive preparation, because many of the decisions that will ultimately determine their CRA position, including questions of scope, product classification, conformity assessment route, cybersecurity risk, vulnerability handling, technical evidence and supply-chain dependencies, can and should already be addressed.

In her closing contribution to the stakeholder panel, Ms Raphael returned to precisely this point, encouraging organisations to understand the Regulation as a whole rather than wait passively for the horizontal and vertical standards to be finalised, and to begin by knowing their products, understanding how they are classified and undertaking the cybersecurity risk assessment that will inform the remainder of the compliance process.

The standards will undoubtedly make conformity assessment more structured, more predictable and, in many cases, considerably more manageable, but the discussions in Cyprus also demonstrated that the manufacturer’s task extends beyond identifying and applying standards, because effective CRA implementation requires regulatory analysis, product risk, technical implementation, evidence and conformity assessment to operate as parts of the same process, with each element informing the others and with the manufacturer remaining responsible for ensuring that the resulting compliance position is coherent as a whole.

The emerging standards framework will provide an increasingly important part of that architecture, particularly as the horizontal and vertical standards mature and begin to interact in practice, but its value will ultimately depend on how well manufacturers understand the legal framework into which those standards fit, how early they begin building the processes and evidence needed to support their decisions, and how effectively they connect the technical work of cybersecurity with the regulatory obligations that the CRA now places on products with digital elements.

Event resources

Conference recording

Watch the full conference, Building CRA Compliance through Horizontal Cybersecurity Standards, on the CYS Standards YouTube channel.

Watch the conference recording ↗

Cyprus Organisation for Standardisation (CYS)

Post-event report covering the principal presentations, stakeholder panel, national-authority panel and the wider CRA standardisation context.

Read the CYS post-event report ↗

CEN-CENELEC / STAN4CR

Official event information and background on the conference and the European standardisation work supporting the CRA.

CEN-CENELEC event page ↗

STAN4CR event page ↗