European standardisation organisations (ESOs) are currently being challenged by the revision of the European Standardisation Regulation. The Commission proposal substantially changes the European model, historically inspired by the Single European Act and the “New Approach”, by opening the system further to other standards development organisations where the ESOs are unable to deliver an appropriate result within the required timeframe (see A major reform of the Single Market framework).
A reading of the European Parliament’s draft ITRE report on the Cybersecurity Act 2 (CSA2), however, suggests that their role in the European regulatory system could be extended to certification: a misguided attempt to save the soldiers CEN, CENELEC and ETSI?
The central issue remains that maintaining a European certification scheme is not a standardisation exercise. This fundamental distinction, long recognised even within ETSI, nevertheless appears to be fading in the draft ITRE report.
Taken as a whole, and despite substantial improvements, the text contains a major contradiction. It confirms that ENISA is responsible for scheme maintenance, while simultaneously introducing an “ESO-first” logic under which technical specifications developed by the Agency would become subsidiary and temporary, pending standards produced by CEN, CENELEC or ETSI.
This contradiction appears to arise from confusion between the technical specification required to prepare, implement or maintain a scheme and the common specification used as a regulatory fallback under European standardisation law.
Three instruments that must not be confused
A European standard is developed by a standardisation organisation through a consensus-based process for common and repeated use. Where a harmonised standard is cited in the Official Journal of the European Union, its application may confer a presumption of conformity with the essential requirements it covers and thereby facilitate market access.
Under the new proposal for a European Standardisation Regulation, a common specification is a technical specification adopted by the Commission, compliance with which may confer a presumption of conformity. It is a fallback solution where the standardisation system fails to deliver an appropriate standard within the required timeframe and may be withdrawn once such a standard becomes available.
A CSA2 technical specification serves a different purpose. It is used to prepare, interpret, implement or maintain a certification scheme. It may contain evaluation methodologies, attack-potential ratings, rules for specific technical domains, or operational arrangements necessary for the scheme’s consistent application.
It is therefore not necessarily a standard, a temporary solution or a document intended to be fully public. Article 77(4) of the Commission proposal expressly provides for restricted distribution where its content could compromise the security of certified products, services or processes. The draft ITRE report appears to pay insufficient attention to this difference in nature.
The draft ITRE report applies the wrong model
The approach proposed in the draft ITRE report appears to import into CSA2 the mechanism applicable to common specifications.
ENISA would be able to develop a technical specification only where no appropriate European standard exists or where the Commission concludes that existing standards do not adequately cover the relevant requirements. The Commission would then have to request an ESO to develop a standard covering the same requirements. Once that standard had been cited, ENISA’s technical specification would cease to apply to new certifications no later than twelve months after the citation.
This mechanism may be justified where a common specification temporarily confers a presumption of conformity pending a harmonised standard. It is unsuitable for the continuous maintenance of a certification scheme.
The draft ITRE report therefore appears to confuse a temporary regulatory specification, intended to be replaced by a standard, with a living technical document required for the operation and evolution of the scheme.
Articles 17 and 75 nevertheless keep ENISA at the centre of maintenance. Article 75 notably covers the preparation, updating and endorsement of technical specifications. Conversely, Article 77, as amended in the draft ITRE report, would tend to make those same specifications temporary and dependent on an external standardisation process.
The problem is therefore not merely institutional. ENISA would retain legal responsibility for maintenance while gradually losing control over some of the technical instruments required to perform that task.
Certification and market access: avoiding a confusion of functions
By its nature, a European cybersecurity certification scheme is not intended to authorise the placing of a product or service on the market. It provides a framework for assessing a digital product, service or process against defined cybersecurity requirements and risk-based assurance levels. A certificate therefore acts as a trusted market signal, enabling customers and users to compare the level of assurance offered by different solutions.
Cybersecurity assurance must also be distinguished from functional safety. Functional safety addresses risks arising from system failures or malfunctions and seeks to ensure that a system remains in, or returns to, a safe state. Cybersecurity addresses the protection of products, services and processes against malicious or accidental compromise. The two disciplines increasingly overlap, particularly where a cyberattack could cause a safety hazard, but they do not rely on the same objectives, evaluation methods or evidence of conformity. A cybersecurity certification scheme may support a broader safety or conformity assessment, but it should not be treated as a substitute for it.
This function must be distinguished from assessing conformity with essential requirements laid down in European harmonisation legislation. Harmonised standards do not themselves define those requirements: they provide technical solutions for meeting them and may, when cited in the Official Journal of the European Union, confer a presumption of conformity.
The boundary between these two mechanisms is not impermeable. Sectoral legislation may make certification mandatory or recognise a certificate as a means of demonstrating conformity. This is the case, under different arrangements, in the NIS2 Directive, the Cyber Resilience Act and the European Digital Identity Framework. A certificate then becomes an instrument for demonstrating conformity, but it is the applicable legislation and not the scheme itself that determines its legal scope and any effects on market access.
Against this background, the draft ITRE report’s proposal to make certification mandatory in principle, unless otherwise expressly provided, reverses the current logic. It risks turning a graduated, risk-based assurance instrument into a horizontal market-access condition, irrespective of scheme maturity, available assessment capacity and the specific needs of each sector.
Such a development could also impair the schemes’ lifecycle and their ability to remain aligned with the evolving threat landscape. Once a scheme becomes a general regulatory condition for placing products on the market, every adjustment to its evaluation methodologies or technical specifications may have significant legal and economic consequences. This rigidity could slow down maintenance, even though cybersecurity certification must be able to incorporate new vulnerabilities, emerging attack paths and lessons learned from evaluations rapidly.
To date, European law has favoured a more targeted approach: the legislator mandates certification for specified uses or sectors on the basis of a risk assessment. This approach preserves the adaptability of schemes while making certification compulsory where it is genuinely necessary.
Cyber Maintenance is not static
The only European cybersecurity certification scheme currently in operation is EUCC, which is based on ISO standards, the Common Criteria ISO/IEC 15408 and the Common Evaluation Methodology ISO/IEC 18045. Its maintenance includes, in particular:
- evolving evaluation methodologies;
- updating attack-potential ratings;
- adapting attack methods and scenarios;
- managing technical domains;
- interpreting requirements for laboratories and conformity assessment bodies;
- handling vulnerabilities;
- …
These activities are continuous, technical and sometimes urgent. Some produce public documents. Others concern attack paths, exploitation techniques or information relating to vulnerabilities and require controlled access.
Although the contribution of ESOs remains necessary, their ordinary working structures are not necessarily equipped to meet the full range of these dynamic maintenance needs. Their membership arrangements, consensus-building procedures and usual levels of confidentiality are primarily designed for the development of broadly accessible standards, rather than for the rapid handling of highly sensitive operational material.
What, for example, would happen to a document describing detailed attack methods if it were introduced into a conventional ESO process? Without specific access controls, confidentiality rules and trusted expert groups, its circulation could expose precisely the knowledge that a certification scheme is intended to manage securely.
ESOs can therefore provide valuable standards and technical input, but they cannot by themselves replace a controlled, ENISA-led maintenance framework.
ISACs as trusted environments
Stakeholder cooperation remains necessary, but it cannot involve indiscriminate participation or be organised without appropriate safeguards. The recent development of the EUCC ISAC illustrates the relevance of the Information Sharing and Analysis Centre model for structuring this dynamic maintenance.
In this respect, the requirement in Article 75(1) of the Commission proposal for each European cybersecurity certification scheme to establish a dedicated maintenance strategy is a major step forward. Such a strategy can define the expected maintenance activities, identify the standards and technical specifications concerned, and organise interaction with the relevant stakeholders throughout the scheme’s lifecycle. Article 75(3) also allows ENISA to organise private-sector involvement through an ad hoc working group. The maintenance strategy should go further by explicitly recognising ISACs and other permanent trusted technical communities as contributors to scheme maintenance. Their role, access conditions, confidentiality obligations and relationship with ENISA, the ECCG and its maintenance subgroups should be clearly defined, rather than leaving their participation to informal or purely ad hoc arrangements.
An ISAC can bring together, in a trusted environment, the public and private actors possessing the relevant expertise and information: ENISA, national cybersecurity certification authorities (NCCAs), laboratories, conformity assessment bodies (CABs), industry and experts from the various technical domains.
The EUCC ISAC enables them to share experience, analyse difficulties encountered during evaluations and build technical consensus without disclosing information that could facilitate an attack. It can contribute, in particular, to technical interpretations, evaluation methodologies, attack-potential ratings and the maintenance of attack catalogues.
This governance is based on trust and participant diversity, as well as confidentiality, conflict-of-interest management, traceability of contributions and a clear distinction between public and restricted documents.
Openness and strategic autonomy
Openness is generally a strength of standardisation processes. It becomes a limitation, however, when the work concerns information that could be directly exploited for offensive purposes.
Depending on the organisation and committee concerned, participation in ESO activities may be very open, including to actors whose ownership, control or interests lie outside the Union. This openness is appropriate for developing public standards. It is less appropriate for maintaining attack catalogues, exploitation methodologies, attack-potential ratings or information concerning non-public vulnerabilities.
Insufficiently controlled access to these documents would create a risk to the security of European products and infrastructure. It would also raise an issue of strategic autonomy by potentially allowing actors from third countries to influence European evaluation methodologies or obtain privileged access to the knowledge underpinning their effectiveness.
This is not about closing standardisation processes or excluding all international contributions. It is about applying governance arrangements proportionate to the sensitivity of each document.
Putting maintenance governance back on track: standardisation for ESOs, certification for ENISA
Stakeholders should not replace ENISA. They should provide structured expertise and contribute to public-private consensus. NCCAs must also retain a central role: national knowledge and capabilities should be mobilised at the most appropriate level and then pooled at European level. Neither the Commission proposal nor the draft ITRE report appears to have found a fully satisfactory balance between European leadership, Member State responsibility and the participation of private experts.
The role of ESOs should not be distorted. They must remain the cornerstone of standardisation, not certification. Any improvements to their governance, responsiveness or contribution to Union policies should be addressed through the European Standardisation Regulation, not through CSA2. The latter should establish a risk-based and sufficiently agile certification framework, with scheme maintenance led by ENISA and supported by the ECCG.
ESOs should develop public, consensus-based standards, while ENISA’s ad-hoc working groups, ISACs and trusted technical communities provide the operational expertise required for maintenance.
The issue is not to oppose ENISA and the ESOs, but to avoid a category error: treating maintenance technical specifications as temporary common specifications pending the development of a standard.
ESOs have an essential role to play. But when it comes to maintaining certification schemes, they may be fighting the wrong battle.
