Navigating the CRA: A Brief Analysis of European Cyber Resilience Act

and Resulting Actions for Product Development

Peter Schoo

Independent Researcher, 82194 Gr

obenzell, Germany

Keywords:

Cyber Resilience Act, CRA, Product Security, Security Engineering, Harmonised European Standards,

Product Certiﬁcation.

Abstract:

This short-paper analyses the forthcoming European Cybersecurity Legislation, focusing on the Cyber Re-

silience Act (CRA), with an examination of the challenges in deﬁning the CRA addressing product security

requirements, life-cycle and supply chain protection, and product criticality classiﬁcation, that points to certi-

ﬁcation of product security. Stakeholders, including EU institutions, industry players and Open Source Soft-

ware (OSS) community, play pivotal roles. The discussion provides a concise but complete overview of the

regulatory content and context, the obligations and recommendations for action for companies and practical

recommendations for courses at universities, as they arise from the CRA.

1 INTRODUCTION

Enabling technologies are technically harmonised by

standards, mostly for ensuring product qualities or to

allow for interworking. Regulation determines the le-

gal constrains how products using such technologies

are placed on markets according to given standards.

Recently the European Union has focused on regulat-

ing IT security and data protection for product, plat-

forms and services, which is result of advances in

digitisation. For a subset, namely (industrial) cyber-

physical products that are placed on European mar-

kets the coming CRA will regulate expected and min-

imum IT security properties. When CRA enters into

force and after a transition period, all these products

that in the widest sense have digital communication

capabilities, will have to come with IT security pro-

tection, that will correspond to expected risks, and

the maintenance for this protection during the prod-

ucts life time.

The analysis carried out here focuses on the CRA

and its profound implications for product develop-

ment and the realm of IT security. The motivation

behind this discussion is to gain a comprehensive

understanding of the new legislation, particularly its

nuanced consequences for product development and

maintenance efforts. As the CRA was recently com-

pleted and will now become legally binding, this dis-

cussion portrays work in progress and discusses the

https://orcid.org/0009-0000-6147-2851

consequences for vendors that are accessing the Euro-

pean market. While larger enterprises may ﬁnd these

ramiﬁcations less pressing and have experiences what

is means to follow the security by design paradigm,

this discussion may have more signiﬁcance for Small

and Medium-sized Enterprises (SMEs). Addition-

ally, an educational lens will be applied, indicating

a thematic direction for security engineering in edu-

cational institutions.

The special topic of assessing the implementa-

tions of IT security security in a standardised for-

mat and from independent 3rd bodies is only touched

upon here and not comprehensively discussed. Be-

hind this lies a comprehensive ecosystem, additional

procedures, often speciﬁc government requirements

and further norms and standards that would go be-

yond the scope of this discussion.

The structure of the discussion is as follows. Com-

mencing with an overview of the legislative landscape

and key players involved, the essential ideas encapsu-

lated in the CRA, and subsequently the consequences

for the security controls of products are presented.

The consideration then extends to scrutinising the im-

pact on the development processes, mandated require-

ments throughout the product life cycle, and poten-

tial product-conformance assessment. The conclusion

ﬁnally consider indicated actions resulting from the

impending CRA, paving the way for a comprehen-

sive understanding of this pivotal cybersecurity legis-

lation.

Schoo, P.

Navigating the CRA: A Brief Analysis of European Cyber Resilience Act and Resulting Actions for Product Development.

DOI: 10.5220/0012690500003705

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 9th International Conference on Internet of Things, Big Data and Security (IoTBDS 2024), pages 245-251

ISBN: 978-989-758-699-6; ISSN: 2184-4976

245

2 UPCOMING EUROPEAN

CYBERSECURITY

LEGISLATION

In anticipation of secure products for the digital mar-

ket, the European Commission (EC) has taken deci-

sive steps to bolster cybersecurity, culminating in the

EU legislation framework (Figure 1). This legislation

encompasses a broad set of regulations, addressing

the European market’s digital landscape with a fo-

cus on products and operational infrastructures. Of

this legislation only a subset is discussed here, namely

that subset needed here in the discussion for the un-

derstanding of the CRA. Initially, the legislation cen-

tres with the CSA (European Union, 2019) on a non-

sector-speciﬁc certiﬁcation framework for a diverse

range of Information and Communications Technol-

ogy (ICT) devices, processes, and services, exclud-

ing regulations on Social Networks platforms. It then

extends to cover the protection of Critical Infrastruc-

tures (CIs) in European operational sectors and the

security of products equipped with networking capa-

bilities, acknowledging with the CRA the increasing

relevance of connected industrial IoT devices.

Initially in this legislative initiative, EC published

its CRA proposal in 2022 (European Commission,

2022). As result of the consultation process and of the

legislative handling in the trilog with the EU institu-

tions , in December 2023 a compromise text (Gen-

eral Secretariat of the Council, 2023) was agreed.

The legal text has its entry into force 20 days after

Cybersecurity

Act

2019

NIS2

2022

CRA

2023

Technologies

Standards

Regulations

direct

application

transposition

i.e. national

implementation

Product Security

Protection of CIs

socially important

sectors, criticality

certification,

security assurance,

criticality classes

essential security req.,

development process,

certification when needed,

security support

during life cycle

some of these products

will be used in CIs

Figure 1: Simpliﬁed EU legislation overview. Acts are di-

rectly applicable, Regulations are to be transferred into na-

tional legal framework. Cybersecurity Act (CSA) deﬁned

in 2019 certiﬁcation regulation. NIS2 deﬁned in 2022 ad-

dresses operation of CI, and draft of December 2023 CRA

focuses on security for products that shall be placed in EU

market.

being published in the Ofﬁcial Journal of the Euro-

pean Union (OJEU), i.e. the transition period of 36

months and 21 months resp. starts counting. There

are two applicability dates the CRA deﬁnes. The ear-

lier date is when vendors have to follow security re-

porting obligation (cmf. Section 3.2). Only after three

years the CRA the full applicability will begin for all

products placed on the European market by manufac-

turers, distributors or importers, for selling products

to customers or to businesses. For consumers this will

be indicated by the CE mark on products to then also

including cybersecurity as immanent product proper-

ties.

This regulation applies to products with

digital elements whose intended or reasonably

foreseeable use includes a direct or indirect

logical or physical data connection to a device

or network (European Commission, 2022, Ar-

ticle 2).

Such products can also be colloquially referred to

as cyber-physical products, which is used in he fol-

lowing as synonym.

The CRA relates also to other regulations the EC

is committed to and that also address security and data

protection. In the three-part criticality grading of AI

systems set out in the AI Act

, the legislature re-

quires that high-risk systems receive IT security pro-

tection and resilience as speciﬁed by the CRA. This

includes AI-speciﬁc threats such as data poisoning

or adversarial attacks and also risks of fundamental

rights. Similar with the Machinery Directive

that

originally harmonised primarily health and safety re-

quirements for machines, and products that use net-

working capabilities to support creating data for the

European Health Data Space. These machines or de-

vices are considered products with digital elements so

that the CRA with its essential requirements to IT se-

curity protection is to be applied. Not so Software-

as-a-Service (SaaS), Platform-as-a-Service (PaaS) or

Infrastructure-as-a-Service (IaaS) that do not have

a cyber-physical counterpart. For product develop-

ments it then also includes the General Data Protec-

tion Regulation (GDPR), to extend the paradigm Se-

curity by Design to also Privacy by Design.

Including in this regulatory trajectory is Network

and Information Systems Directive (NIS2) (European

Union, 2022), concentrating on the safeguarding se-

lected critical infrastructures, which are societal cru-

cial for operational continuity. Member states play

a pivotal role in deﬁning national implementation

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri

=CELEX:52021PC0206 (in progress)

http://data.europa.eu/eli/reg/2023/1230/oj

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

246

plans, tailoring them to the signiﬁcance and scale of

operators within their jurisdictions.

This above arrangement of regulations presents a

coherent and streamlined overview of the evolving

European cybersecurity landscape over legal frame-

works.

3 COMPREHENSIVE

REGULATION AFFECTING

TECHNICAL IT SECURITY OF

PRODUCTS AND THEIR

DEVELOPMENT PROCESSES

The CRA represents a new era in European cyberse-

curity legislation, ending the current practice of sim-

ply ignoring the IT security of products. Rather the

CRA addresses both technical product properties to

build according to Security by Design principles and

enforce vendors’ business processes to maintain secu-

rity during the life time of products. This is ambitious

for a legal framework and builds on scientiﬁc grounds

and proven security engineering principles and will

impact a broad spectrum of products with networking

capabilities, including OSS, necessitating a compre-

hensive set of security disciplines to strengthen the

EU market digital landscape. These measures to im-

prove product security are complemented by market

monitoring carried out by EC to see how the regula-

tion created by the CRA will work and what accep-

tance and changes will result.

3.1 Risk-Based Product Cybersecurity

Requirements

The cornerstone of the CRA lies in the deﬁnition of

product security requirements depending on the risks

a product will be exposed to, e.g. underpinned by a a

thorough threat analysis and risk assessment (TARA)

that identiﬁes potential threats and results in under-

standing the products’ risks. Dependent on the ven-

dor’s risk appetite or the environment the product

shall be used in and shall be ﬁt for, the IT security

concept for the protection of the product is to be de-

signed and developed.

This can involve documenting crucial security-

related decisions, such as the documentation of the

TARA and the followed security concept, utilisation

of standards, internal security validation, or testing

efforts. By requesting such design (intermediate) re-

sults, the legislation seeks to establish a robust foun-

dation for the security posture of networked cyber-

physical products.

3.2 Maintaining Product Cybersecurity

Security support for products brought to market is

a complementing security management aspect in the

context of products life-cycle, encompassing the def-

inition of a security support period of ﬁve years for

vulnerability handling, a well-deﬁned vulnerability

disclosure process, and reporting obligations to rele-

vant authorities. Product owners are mandated to ad-

here to vulnerability handling obligations

• providing products to the market that do not have

known actively exploited vulnerabilities, and

• ensuring a swift and effective response to identi-

ﬁed vulnerabilities

that is expected to release secure products and to

help maintaining their protection.

Recognising the interconnected nature of the dig-

ital supply chain, the legislation extends its reach

to safeguard third-party components, including OSS,

against threats such as e.g. potential back-doors, as

an responsibility of the product owner. This involves

implementing security management practices and in-

troducing a formalised Software Bill of Materials

(SBOM). This documentation concept formalises the

product construction from components and can also

be a chance for the development processes and tools,

supporting processing of information about compo-

nents and enhances transparency within the supply

chain.

3.3 Product Cybersecurity

Conformance

A signiﬁcant measure introduced by the CRA is the

classiﬁcation of products based on their criticality

(cmf. Figure 2). This nuanced approach acknowl-

edges that certain components, like a ﬁrewall, carry

a higher level of criticality than others, such as e.g.

user desktop settings. Compliance with standards

and the presentation of fulﬁlled security requirements,

whether claimed or independently assessed by third

parties, become paramount in this context. The CRA

introduces three classes of products depending on

their criticality and an extra class for which EU certi-

ﬁcation is made mandatory.

It is expected by EC that the majority of prod-

ucts will fall into the class that can self-declare se-

curity properties and use of standards. These stan-

dards can be de jure standards or, a subset of it, spe-

ciﬁc European standards. However, the identiﬁcation

of such European standards required by the CRA is

Navigating the CRA: A Brief Analysis of European Cyber Resilience Act and Resulting Actions for Product Development

247

Figure 2: Conformity Assessment Classes. Source: Euro-

pean Commission.

in progress to date and their identiﬁcation is not yet

completed by the European Standards Organisations

(ESOs). CEN, CENELEC were asked by the EC to

identify and name harmonised standard.

With the coming CRA the ESOs will be ask to

take into account existing international

and European standards for cybersecurity

that are in place or under development in or-

der to simplify the development of harmonised

standards (General Secretariat of the Council,

2023, Article 18)

This means that it can be assumed that existing or up-

coming standards that can technically meet the essen-

tial safety requirements of the CRA will become Eu-

ropean standards on which products should then be

based accordingly. Advantageously, such harmonised

standards then allow the presumption of conformity

for products in the Class “Default Category”, i.e. con-

formity with the essential requirements of CRA can

be reasonably assumed. However, it cannot be ruled

out that further harmonisation will be necessary in ex-

ceptional cases. A risk comparable to the chance that

an existing standard will be revised and thereby es-

tablish new requirements. In summary, unless a prod-

uct falls into other classes than “Default Category”,

the CE mark requires a self-declaration only

, which

is named to be “internal product control”. Rationals

must be part of the vendor’s product documentation

that can be presented in case of dispute.

3.4 Critical Product Classes

A self-declaration will not be suitable, however, for

critical products, e.g. a ﬁrewall. In Annex III the

CRA deﬁnes the three classes of product types that

are critical products with digital elements (Critical

Class I), critical products with digital elements (Crit-

ical Class II) and highly critical products with dig-

ital elements. The (Critical Class II) includes e.g.

Micro-controller and -processors, Industrial Automa-

tion and Control Systems according to the norm IEC-

according to EU Decision 768/2008/EC, “Module A”

62443, IIoT (Industrial Internet of Things), robots

and smart meter. To assure that such critical prod-

ucts come with claimed security controls that they are

suitable according to a given criticality, elements of

these classes are more thoroughly assessed. Critical

Class I products will require a EC type examination

according to the “Module B” and performed by an

independent party concerning the conformity to Eu-

ropean standards. Critical Class II of critical products

will be validated by independent parties according to

given security protection proﬁles that deﬁne security

requirements and objectives, which are deﬁned inde-

pendent of the product owner. The highest criticality

class is foreseen to assess those products being used

in CIs.

To prevent over-regulation and ensure coherence

within the legal landscape, the CRA aligns also with

other relevant legal acts or directives. Notable con-

nections include the NIS2 for critical infrastructures,

the AI Act, and machinery/product safety regulations

as mentioned in Section 2.

All of these classiﬁcations are based on the as-

sumption that not only the classiﬁcation is mean-

ingful, but also that (i) compliance with the speciﬁc

safety requirements is checked uniformly and corre-

sponding to existing certiﬁcation schemes, and (ii)

that there are sufﬁcient capacities to carry out the con-

formance assessments. For industry both points are

most critical in the phase until the CRA enter the full

applicability.

3.5 Observe CRA Effect on Market

To monitor and assess the effectiveness of cyberse-

curity regulations, the CRA introduces a market ob-

servation mechanism. With this initiative EC aims

to scrutinise the application and impact of the leg-

islation, deciphering its relevance and adaptability

of the ever-evolving vulnerabilities of product and

ow vendors accordingly act in the European digital

landscape. It is a political decision which European

agency will receives the responsibility to carry out

this market observation.

4 DISCUSSION: CRA

CHALLENGES AND

OPPORTUNITIES

With completion of the CRA legislation, attention

turns to the missing standardisation and opportunities

it presents for market stakeholders and the necessary

complementary implementation measures.

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

248

4.1 Procedure Deﬁning the CRA

Deﬁning the CRA within the European legislative

framework presents a multifaceted set of challenges.

As this legal initiative took shape, the European insti-

tutions, comprising the EC, the member states Coun-

cil of the European Union, and the European Parlia-

ment, engage as usual in a collaborative process. The

EC proposes the legislation, and subsequent discus-

sions involve the Council and Parliament, culminating

in a co-decision that shall ensure consensus across all

member states and European institutions. Unlike di-

rectives, the CRA is a regulation, instantly applicable

across member states without the need for national

transposition. One of the ambitious task was to com-

plete this initiative in a short period of time and within

current parliamentary term of EP and EC, which is,

however, not achieved to date as publication in the

OJEU has not been done and is only planned.

The distinctive focus on cyber-physical prod-

ucts heightens the complexity of formulating a le-

gal framework, adhering to principles of proportion-

ality and necessity, that addresses essential cyberse-

curity maintained throughout the life-cycle of prod-

ucts capable of networking, encompassing both hard-

ware and software. On the technical side, the de-

sired essential safety properties for the affected prod-

ucts are already sufﬁciently covered by R&D, which

of course should not exclude any research for further

progress. However, the formulation of legal require-

ments proved to be difﬁcult due to the diverse areas of

application of existing products in the consumer sec-

tor and for industrial use and due to the different exist-

ing business models. A challenge emerged in crafting

a framework that genuinely enhances the IT security

of diverse products with varying applications and use

cases.

Compounding this difﬁculty was the limited tech-

nical security expertise of those formulating and dis-

cussing the legal text, overseeing the consequences

in applying IT security and for security engineering,

and product development to a limited extend only. To

bridge this gap, reliance was placed on external se-

curity expertise provided by governmental agencies

like e.g. ANSSI or German BSI, standardisation bod-

ies, product manufacturing companies, operators of

technical systems including the affected OSS commu-

nity that contributed. For example, The Apache Soft-

ware Foundation participated in the legislative pro-

cess as a representative of the OSS community and

expresses no fundamental dissatisfaction with the out-

come of how future IT security requirements for OSS

were legally designed (Milinkovich, 2023; van Gu-

lik, 2024). NGOs and civil society were involved to a

very limited extent only.

4.2 Standards and Certiﬁcation

The effectiveness of the CRA legal framework hinges

on its alignment with the original goals set by the EC

to enhance product security without hindering the Eu-

ropean market. Market development will be closely

monitored, and the reporting obligations embedded in

the CRA and also the NIS2 are expected to signiﬁ-

cantly improve over the next years observations and

statistics of security incidents in both products and

deployments. ESO and certiﬁcation authorities play a

pivotal role in the CRA’s effectiveness, as the speed of

uptake and the establishment of European norms and

standards by ESO will be vital. While the set of har-

monised European standards is open to date (Har, ) re-

garding the norms the CRA wants to see applied, how

shall vendors cope this product development risks in

the next years? This will cause enormous uncertain-

ties for industry.

Similar the question for validating and assessing

conformity of critical product classes: the develop-

ment of capabilities and capacities for formal assess-

ments or potential certiﬁcations is imperative, as Eu-

rope has only very limited organisation (so-called ac-

credited Notiﬁed Bodies) that are legitimate to assess

the deﬁned conformity. The market at the time be-

ing does not have a suitable capacity for assessing

the conformity. There are too few companies having

been designated to carry out conformity assessment

according to a EU directives and it is today question-

able if their capacity will be good enough for the mas-

sively increasing demand of industry and SMEs. Cer-

tiﬁcation schemes are under way in Europe and it be-

comes clear that the interest of EC and the affected

industries go in different directions. For example, the

derived experiences made in applying Common Cri-

teria certiﬁcation is that this scheme does not ﬁt well

to neither evolving ICT systems nor the industrial IoT

technology. Evolving ICT systems receive also in fu-

ture updates that may affect certiﬁed security prop-

erties. What does this mean for the conformity as-

sessment? Further, IoT systems are build today from

many components, from lowest layer processors to

eventually user-oriented control components, which

establishes a demand for conformity assessments that

can follow in a way such component based composi-

tions, avoiding duplication of efforts for security as-

surance.

Navigating the CRA: A Brief Analysis of European Cyber Resilience Act and Resulting Actions for Product Development

249

4.3 Security Engineering

In order for future products to meet the requirements

of CRA, manufacturers and organisations involved in

the development of ICT products are obliged to in-

clude IT security as early as possible (security by de-

sign) and to maintain this protection over the entire

product lifespan (security life cycle). It is necessary

to deﬁne, establish and assess processes of product

development, including the supply chains, such that

they are compliant to the upcoming regulation. This

means ﬁrst becoming aware of the risks a product

must be able to deal with and how the necessary se-

curity mechanisms should be designed. Formally, a

TARA is required that serves as the basis for the de-

velopment of a risk-based security concept, which, at

the same time, helps avoiding to over-engineer pro-

tection efforts.

There are numerous approaches to carry out re-

quired threat analysis and risk assessment, e.g. in-

cluded in EN ISO/IEC 62443, (Common Criteria Or-

ganisation, 2017), etc.). There is no agreed method

exists for industry or in science, only good practice.

Anyhow, it is agreed that the basic scheme follows

the scheme:

Risk ←− T hreats × Probability × Impact

The assessment of risks is based on the quality of

the threats for (mostly technology induced) attacks,

the probability that such threats are expected to come

and the expected impact of the attack. To date, such

TARA are carried out by experts, however, over time

and for given technologies catalogues of threat my be

agreed in industry sectors and maintained to follow

latest vulnerabilities and identiﬁed security ﬂaws, as

proposed (Sommer et al., 2019) for the automotive

domain to support ISO/SAE 21434.

In order for the security concept to be maintained,

it is necessary to be able to update the product or to be

able to carry out future updates of used components.

This will not necessarily be always successful, espe-

cially for legacy products, as examples for an early

product end of life indicate. If security support can no

longer be provided and updates cannot be made avail-

able, then decision may be required for such products

to exit the market

The product classes discussed in Section 3.4 help

to guide the design of the security concept. Priori-

tising proven norms and standards not only enhances

In another industry, an automaker production of a vehi-

cle type is discontinued because cybersecurity requirements

can no longer be fulﬁlled: https://de.wikipedia.org/wiki/Po

rsche Macan or https://www.motor1.com/news/706105/por

sche-continuing-gas-macan-sales/ accessed 2024-03-10

product security but also simpliﬁes self-declarations,

especially for critical product classes, helping to keep

certiﬁcation costs low. This illustrates how important

it is harmonised European standards exists and that

they are used in products. On the other hand, Class I

and below do not require harmonised European stan-

dards and can build on standards that are state of the

art. This is very important for legacy products that

were built but the standards used never fall into the

group of harmonised European standards.

All such design and standards application deci-

sions have to be documented well, as it will be needed

in case of dispute with market survey agencies. The

use of tools for managing product artefacts will help

to meet documentation requirements and presents an

opportunity to streamline processes for automation,

as seen in parts with the SBOM. Speciﬁcally when

components in the supply chain of a product will be

compromised, the product owner is expected to react

swiftly and mitigate or eliminate security ﬂaws.

The reporting obligations encompassed in the

CRA and that will become early on affecting as

mentioned above, will certainly require organisations,

vendors and importers adopt their business processes.

Practising reporting processes and vulnerability han-

dling within given timelines, aligning such reporting

decision processes with also the GDPR obligations in-

dicates some preparation demand and efforts.

4.4 Education and Training

The coming application of the CRA creates demand

and impetus for education and training of future

IT specialists, speciﬁcally in IT security and data

protection. The wide-ranging application inﬂuences

within companies product development, processes,

and methods. This includes methods for conduct-

ing TARA and using these as basis for deﬁning secu-

rity concepts that achieve a speciﬁed protection level

with well-deﬁned remaining risks. Structuring secu-

rity engineering as part of the development process to

encompass predeﬁned security requirements will be

crucial, also to adopt to new technologies in the Post

Quantum era. It is not the new technology that deﬁnes

the challenge, but its application and the migration to

new technologies.

Being cognisant of duties and obligations arising

from vulnerability handling, and understanding liabil-

ities and legal regulations, will play a essential role

in shaping the future of digitisation. In essence, the

CRA not only mandates compliance but also cataly-

ses a holistic transformation in the approach to cy-

bersecurity, promoting innovation, efﬁciency, and re-

silience for products that shall go to European mar-

IoTBDS 2024 - 9th International Conference on Internet of Things, Big Data and Security

250

ket, and, also this will show effect for all countries

the supply chains reaches.

5 CONCLUSION

To conclude, the description compiled here provides a

concise but complete overview of the regulatory con-

tent and context, the obligations and recommenda-

tions for action for companies and practical recom-

mendations for courses at universities, as they arise

from the CRA.

In summary, the anticipation remains that this

comprehensive legal regulation will not merely touch

but fundamentally transform every facet of the IT in-

dustry, setting forth a trajectory where security, adapt-

ability, and regulatory adherence converge for a hope-

fully more resilient digital future. Skills for risk-

based Security by Design product development will

be key and a major challenge for SMEs. Further, and

to date still open, is to quickly deﬁne the needed har-

monised European standards and certiﬁcation direc-

tives. From the operative perspective vulnerability

handling requires to establish an European wide ap-

plicable reporting infrastructure that participants can

use without too much extra efforts.

When Ursula von der Leyen as president of the EC

announced the CRA in September 2021, the draft of

which was delivered one year later, she speciﬁcally

pointed out the need to ﬁght against ransomware.

While this threat is not truly addressed by the new

legislation, the resistance of connected cyber-physical

products against IT security threats will certainly im-

prove for the European market and beyond.

ACKNOWLEDGEMENTS

My thanks go to the patient, anonymous reviewer for

the detailed comments that helped making the presen-

tation clearer and easier to understand.

REFERENCES

Harmonised Standards - European Commission. https://si

ngle-market-economy.ec.europa.eu/single-market/eu

ropean-standards/harmonised-standards en.

Common Criteria Organisation (2017). Common Method-

ology for Information Technology Security Evalua-

tion – Evaluation methodology, Version 3.1 Revi-

sion 5.

European Commission (2022). Proposal for a Regulation

of the European Parliament and of the Council on

Horizontal Cybersecurity Requirements For Products

With Digital Elements And Amending Regulation (EU)

2019/1020. European Commission. https://ec.europa.

eu/newsroom/dae/redirection/document/89543.

European Union (2019). Regulation (EU) 2019/881 of the

European Parliament and of the Council of 17 April

2019 on ENISA and on information and communi-

cations technology cybersecurity certiﬁcation and re-

pealing Regulation (EU) No 526/2013 (Cybersecurity

Act CSA). Ofﬁcial Journal of the European Union.

EU-Lex Home http://data.europa.eu/eli/reg/2019/881/

oj accessed 2024-03-10.

European Union (2022). Directive (EU) 2022/2555 of the

European Parliament and of the Council on ENISA

and measures for a high common level of cyberse-

curity across the Union (NIS-2 Directive). Ofﬁcial

Journal of the European Union. EU-Lex Home http:

//data.europa.eu/eli/reg/2022/2555/oj accessed 2024-

03-10.

General Secretariat of the Council (2023). Regulation of the

European Parliament and of the Council on horizontal

cybersecurity requirements for products with digital

elements and amending Regulation (EU) 2019/1020.

EU-Lex Home https://eur-lex.europa.eu/legal-content

/EN/TXT/PDF/?uri=CONSIL:ST 17000 2023 INIT

accessed 2024-03-10.

Milinkovich, M. (2023). Good News on the Cyber Re-

silience Act | Eclipse Foundation Staff Blogs. https:

//eclipse-foundation.blog/2023/12/19/good-news-o

n-the-cyber-resilience-act/ accessed 2024-03-10.

Sommer, F., D

urrwang, J., and Kriesten, R. (2019). Survey

and Classiﬁcation of Automotive Security Attacks. In-

formation, 10(4):148.

van Gulik, D.-W. (2024). Update on EU Software Regu-

lation: Lots of improvements & good news. https:

//news.apache.org/foundation/entry/update-on-eu-s

oftware-regulation-lots-of-improvements-good-news

accessed 2024-03-10.

Navigating the CRA: A Brief Analysis of European Cyber Resilience Act and Resulting Actions for Product Development

251