Cyber Resilience Act Requirements Standards Mapping-KJNA31892ENN

ISSN 1831-9424
Cyber Resilience Act Requirements

Standards Mapping
Joint Research Centre & ENISA Joint Analysis
EUR 31892 EN
Legal Notice
The scientific output expressed does not imply a policy position of the European Commission. Neither the European
Commission nor any person acting on behalf of the Commission is responsible for the use that might be made of this
publication. For information on the methodology and quality underlying the data used in this publication for which the
source is neither Eurostat nor other Commission services, users should contact the referenced source. The designations
employed and the presentation of material on the maps do not imply the expression of any opinion whatsoever on the
part of the European Union concerning the legal status of any country, territory, city or area or of its authorities, or
concerning the delimitation of its frontiers or boundaries.
JRC137340
EUR 31892 EN
PDF ISBN 978-92-68-14180-9 ISSN 1831-9424 doi:10.2760/905934 KJ-NA-31-892-EN-N
Luxembourg: Publications Office of the European Union, 2024
© European Union, 2024
The reuse policy of the European Commission documents is implemented by the Commission Decision 2011/833/EU of
12 December 2011 on the reuse of Commission documents (OJ L 330, 14.12.2011, p. 39). Unless otherwise noted, the
reuse of this document is authorised under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence
(https://creativecommons.org/licenses/by/4.0/). This means that reuse is allowed provided appropriate credit is given and
any changes are indicated.
For any use or reproduction of photos or other material that is not owned by the European Union permission must be
sought directly from the copyright holders.
How to cite this report: Hernandez Ramos, J.L., Karopoulos, G., Nai Fovino, I., Spigolon, R., Sportiello L., Steri, G., Gorniak,
S., Magnabosco, P., Atoui, R., Crippa Martinez, C., Cyber Resilence Act Requirements Standards Mapping, Publication Office
of the European Union, 2024, https://data.europa.eu/doi/10.2760/905934, JRC137340.
About JRC
The Joint Research Centre is the European Commission’s science and knowledge service. The JRC is a Directorate-General
of the European Commission under the responsibility of the Commissioner for Innovation, Research, Culture, Education
and Youth. Our researchers provide EU and national authorities with solid facts and independent support to help tackle
the big challenges facing our societies today. Our headquarters are in Brussels and we have research sites in five Member
States: Geel (Belgium), Ispra (Italy), Karlsruhe (Germany), Petten (the Netherlands) and Seville (Spain). Our work is largely
funded by the EU’s budget for Research and Innovation. We create, manage and make sense of knowledge, delivering the
best scientific evidence and innovative tools for the policies that matter to citizens, businesses and governments. For more
information, visit https://ec.europa.eu/jrc.
About ENISA
The European Union Agency for Cybersecurity, ENISA, is the Union’s agency dedicated to achieving a high common level of
cybersecurity across Europe. Established in 2004 and strengthened by the EU Cybersecurity Act, the European Union
Agency for Cybersecurity contributes to EU cyber policy, enhances the trustworthiness of ICT products, services and
processes with cybersecurity certification schemes, cooperates with Member States and EU bodies, and helps Europe
prepare for the cyber challenges of tomorrow. Through knowledge sharing, capacity building and awareness raising, the
Agency works together with its key stakeholders to strengthen trust in the connected economy, to boost resilience of the
Union’s infrastructure, and, ultimately, to keep Europe’s society and citizens digitally secure. For more information, visit
www.enisa.europa.eu .
Contact information
For contacting the authors, please use https://ec.europa.eu/jrc/en/contact/form or [email protected]
Authors
JRC ENISA
Hernandez Ramos, J. Gorniak, S.
Karopoulos, G. Magnabosco, P.
Nai Fovino, I.
Spigolon R. Atoui, R.
Sportiello L. Crippa Martinez, C.
Steri, G.
Acknowledgements
The authors would like to thank colleagues of DG CNECT.H2 for their review of this report.
Contents
Abstract .......................................................................................................................... 1
1 Introduction............................................................................................................. 2
2 Methodology ............................................................................................................ 3
3 Requirements-Standards mapping and analysis ................................................ 5
3.1 Security requirements relating to the properties of products with digital elements ........... 5
3.1.1 (1) Products with digital elements shall be designed, developed and produced in
such a way that they ensure an appropriate level of cybersecurity based on the risks;............. 5
3.1.2 (2) Products with digital elements shall be delivered without any known exploitable
vulnerabilities;.............................................................................................................................................. 7
3.1.3 (3) On the basis of the risk assessment referred to in Article 10(2) and where
applicable, products with digital elements shall: ................................................................................. 9
(a) be delivered with a secure by default configuration, including the possibility to reset the
product to its original state; ...................................................................................................................... 9
3.1.4 (3b) ensure protection from unauthorised access by appropriate control
mechanisms, including but not limited to authentication, identity or access management
systems; ...................................................................................................................................................... 11
3.1.5 (3c) protect the confidentiality of stored, transmitted or otherwise processed data,
personal or other, such as by encrypting relevant data at rest or in transit by state of the art
mechanisms; .............................................................................................................................................. 15
3.1.6 (3d) protect the integrity of stored, transmitted or otherwise processed data,
personal or other, commands, programs and configuration against any manipulation or
modification not authorised by the user, as well as report on corruptions; ............................... 17
3.1.7 (3e) process only data, personal or other, that are adequate, relevant and limited to
what is necessary in relation to the intended use of the product (‘minimisation of data’); ...... 20
3.1.8 (3f) protect the availability of essential functions, including the resilience against
and mitigation of denial of service attacks; ......................................................................................... 22
3.1.9 (3g) minimise their own negative impact on the availability of services provided by
other devices or networks; ..................................................................................................................... 24
3.1.10 (3h) be designed, developed and produced to limit attack surfaces, including
external interfaces; ................................................................................................................................... 26
3.1.11 (3i) be designed, developed and produced to reduce the impact of an incident
using appropriate exploitation mitigation mechanisms and techniques; .................................... 28
3.1.12 (3j) provide security related information by recording and/or monitoring relevant
internal activity, including the access to or modification of data, services or functions; .......... 32
3.1.13 (3k) ensure that vulnerabilities can be addressed through security updates,
including, where applicable, through automatic updates and the notification of available
updates to users. ...................................................................................................................................... 34
3.2 Vulnerability handling requirements ............................................................................................ 36
3.2.1 Manufacturers of the products with digital elements shall: (1) identify and
document vulnerabilities and components contained in the product, including by drawing up
a software bill of materials in a commonly used and machine-readable format covering at the
very least the top-level dependencies of the product; ..................................................................... 36
3.2.2 (2) in relation to the risks posed to the products with digital elements, address and
remediate vulnerabilities without delay, including by providing security updates; ................... 37
i
3.2.3 (3) apply effective and regular tests and reviews of the security of the product with
digital elements; ........................................................................................................................................ 39
3.2.4 (4) once a security update has been made available, publically disclose information
about fixed vulnerabilities, including a description of the vulnerabilities, information allowing
users to identify the product with digital elements affected, the impacs of the vulnerabilities,
their severity and information helping users to remediate the vulnerabilities; .......................... 41
3.2.5 (5) put in place and enforce a policy on coordinated vulnerability disclosure; .......... 43
3.2.6 (6) take measures to facilitate the sharing of information about potential
vulnerabilities in their product with digital elements as well as in third party components
contained in that product, including by providing a contact address for the reporting of the
vulnerabilities discovered in the product with digital elements; .................................................... 45
3.2.7 (7) provide for mechanisms to securely distribute updates for products with digital
elements to ensure that exploitable vulnerabilities are fixed or mitigated in a timely manner;
46
3.2.8 (8) ensure that, where security patches or updates are available to address
identified security issues, they are disseminated without delay and free of charge,
accompanied by advisory messages providing users with the relevant information, including
on potential action to be taken. ............................................................................................................. 48
4 Summary of the identified standards and overall remarks ............................ 51

5 Conclusion ............................................................................................................. 55
References ................................................................................................................... 56
List of abbreviations and definitions ....................................................................... 58
List of figures ............................................................................................................... 60
Annexes ........................................................................................................................ 62
Annex 1. High level pre-screening of standardisation activities with potential relevance for the
CRA requirements ......................................................................................................................................... 62
ii
Abstract
The increasing number of cyberattacks affecting digital products, coupled with widespread
vulnerabilities and insufficient timely security updates, creates heavy financial burdens on society.
In response, the European Commission has drafted the Cyber Resilience Act (CRA), a new proposal
for regulation to define the legislative framework of essential cybersecurity requirements that
manufacturers must meet when placing any product with digital elements on the internal market.
To facilitate adoption of the CRA provisions, these requirements need to be translated into the
form of harmonised standards, with which manufacturers can comply. In support of the
standardisation effort, this study attempt to identify the most relevant existing cybersecurity
standards for each CRA requirement, analyses the coverage already offered on the intended scope
of the requirement and highlights possible gaps to be addressed.
1
1 Introduction
On 15 September 2022, the European Commission published the proposal for the Cyber Resilience
Act (CRA) [1], a proposal for a first ever EU-wide legislation of its kind, aimed at introducing
mandatory cybersecurity requirements for products with digital elements throughout their
lifecycle.
The CRA proposal covers all products with digital elements put on the market which can be
connected to a device or a network, including their building blocks (i.e., hardware and software)
and encompassing also solutions provided in a Software as a Service (SaaS) fashion if they qualify
as remote data processing solutions, as defined by Article 3(2) of the CRA proposal.
The CRA proposal provides two sets of essential requirements:
— Product cybersecurity requirements in Annex I, Section 1 of the CRA proposal
— Vulnerability handling process requirements in Annex I, Section 2 of the CRA proposal
These requirements should be the subject of a standardisation process by the European
Standardisation Organizations (ESOs) to express them in the form of specifications in harmonised
standards.
The general principle is that for the products on the market, a self-assessment of compliance with
the requirements specified in Annex I will be sufficient. For certain categories of more critical
products, the application of harmonised standards will be required. For even more critical
products, a third-party assessment will be mandatory.
This report details the available standardisation outputs on the cybersecurity of products
(hardware and software products, including hardware and software components of more complex
products) carried out mainly by ESOs and international Standards Development Organizations
(SDOs). Specifically, the study aim at presenting a mapping of the existing cybersecurity standards
against the essential requirements listed in Annex I of the CRA proposal, along with a gap analysis
between the mapped standards and the requirements. In view of the development of harmonised
standards, this analysis offers a possible overview about the current coverage of the requirements
by existing specifications, highlighting possible lacks that may be compensated by further
standardisation work.
Upon request of DG CNECT, this study has been developed jointly by the Joint Research Centre
(JRC) and the European Union Agency for Cybersecurity (ENISA). This was also in line with the
expectations of the proposal of regulation, in which it is stated that synergies on standardisation
aspects should be considered between the Commission and ENISA.
In Section 2, the methodology adopted to carry out this study is summarised. Section 3 is devoted
to the presentation of the mapping between requirements and standards, giving an analysis of the
coverage offered by the standards and possible gaps. In Section 4, a summary of all identified
standards and their respective mapping is offered along with some overall remarks, while Section
5 is for conclusions.
2
2 Methodology
The development of the present study has been articulated in several stages summarised here
below.
Identification of the standardisation organisations
The first step consisted in the identification of the entities that are considered relevant for
standards in the specific area and that are recognised by the industry and scientific communities,
giving precedence to European and international standardisation organisations. Specifically, the
following ones have been taken into account:
— CEN
— CENELEC
— ETSI
— ISO
— IEC
— ITU
Identification of the committees and related standardisation activities
For each of the organisations listed above, the respective committees working on cybersecurity
standards have been identified. For each one of the identified committees the list of
standardisation activities, including ongoing activities, with potential relevance for the mapping
have been identified, drafting a list of respective standards.
High level analysis of the standardisation activities
The standards identified above have been analysed based on freely available information to
confirm their relevance to the specific topic. For those considered relevant a tentative mapping to
the cybersecurity requirements expressed in Annex I of the CRA Regulation has been proposed,
while the others have been discarded. Some statistics pertaining to this activity are summarised in
Annex I of the present document, so as to give an order of magnitude of its extent. This high-level
overview represented a preparatory ground for the insightful analysis of the next stage.
Mapping and analysis of requirements against standards
Once we listed all standards that might be relevant in a first quantitative analysis, the analysis took
a bottom-up approach. For each CRA requirement the most relevant standards were selected
based on an expert analysis, allowing to identify both the currently offered coverage and the
potential gaps to be addressed at later standardisation stages. The requirements mapping and
analysis process is presented in Figure 1, and the overall output of this stage is presented in Section
3.
Identification
Identification
of key security Listing of most
Requirement Coverage Potential gap of the life-
goals and relevant
Selection rationale identified cycle stage(s)
potential sub- standards
concerned
requirements
Figure 1 Overall requirements mapping and analysis process
3
The CRA cybersecurity essential requirements are presented in a list, and each of them is
expressed in the form of generic text. To enhance the identification and evaluation of the standards
possibly covering aspects captured by the CRA requirements it has been deemed useful to analyse
them and highlight some core concepts. Specifically, for each essential requirement a set of sample
sub-requirements and keywords have been identified. Such elements have served mainly as guide
to identify the CRA-relevant standards, but there are not intended to represent a comprehensive
list of sub-requirements, as a specific break-down of a requirement may depend on specificities of
products and applications. To be noted that when an identified standard was available both in the
form of international standard and European standard, we have referenced it according to the
latter.
In addition to the requirements-standards mapping, since the security requirements may apply to
different stages of the products life-cycle, the study have been enriched with an information
pointing out the possible relevance of a requirement with specific product life-cycle stages. This
may be helpful under a manufacturer point of view to better navigate through the requirements
and standards depending on at what stage a product is. The following high-level generic life-cycle
that applies to all diversity of products has been taken as reference.
Design
Implementation
Validation
Commissionning
Surveillance |
Maintenance
End of Life
Figure 2 Generic product life-cycle
4
3 Requirements-Standards mapping and analysis
Here below each CRA requirement is mapped against relevant standards. For each standard is
discussed the level of coverage offered for the requirement and possible gaps to be considered.
For each requirement all the analysis are summarized in an overall consideration. The two sub-
sections below reflect the two groups of requirements expressed in the CRA Annex I.
3.1 Security requirements relating to the properties of products with digital

elements
3.1.1 (1) Products with digital elements shall be designed, developed and
produced in such a way that they ensure an appropriate level of
cybersecurity based on the risks;
Sample Sub-requirements:
— A cybersecurity risk analysis should be conducted and monitored during the complete lifecycle
of the product
— Cybersecurity should be taken into account in every step of the product creation (e.g. secure
coding, security by design principles, etc.)
Keywords: risk, risk analysis, remediation strategy, secure coding
Standard Standard title Rationale Gap Life-Cycle

ID
EN Information ISO 27002 includes While there are Implementation

ISO/IEC security, controls related to indications for
Validation
27002: cybersecurity secure coding and software
2022 and privacy information security development like Commissioning
protection — in supplier the secure coding Surveillance
Information agreements part, analogous
security (demanding that the indications for a Maintenance
controls suppliers ensure its secure hardware
products/component design are missing
s have the required in this standard,
level of security, and although a more
communicate all generic “Secure
information system architecture
regarding external and engineering
software and principles” could in
components used) principle make up
for it in all those
cases where
hardware is
acquired and
incorporated but
not designed.
5
EN Information Although not specific This standard is Design
ISO/IEC security, to product security, generic and not
27005: cybersecurity this standard specific to product
2022 and privacy specifies how development
protection — information security
Guidance on risks should be
managing managed. A proper
information risk analysis is indeed
security risks of paramount
importance to
understand which is
the “appropriate level
of cybersecurity
based on the risks”
EN IEC Security for Although specific only This standard Design

62443-3- industrial to Industrial applies only to
Implementation
2:2020 automation Automation and Industrial
and control Control Systems Automation and Validation
systems – (IACS), this standard Control System and
covers in detail a does not cover
Part 3-2:
Security Risk cybersecurity
Security risk
Assessment process principles like
assessment for
focused on a system security by design
system design
design, including the
re-evaluation phase
after proper
countermeasures
have been
implemented,
determining the
presence of residual
and tolerable risks
EN IEC Security for Although specific only This standard Design

62443-4- industrial to Industrial applies only to
Implementation
1:2018 automation Automation and Industrial
and control Control Systems Automation and Validation
systems – (IACS), this standard Control System and
prescribes security does not cover the
Part 4-1:
principles (i.e. concept of risk
Secure product
security by design) to assessment
development
be included during
lifecycle
the various phases of
requirements
a product
development.
ETSI EN CYBER; Cyber Promotes secure Detailed guidelines Design

303 645 Security for development and on risk analysis and
Maintenance
Consumer maintenance secure practices are
6
V2.1.1 Internet of practices, implies the not provided, but
(2020-06) Things: need for risk analysis sometimes
Baseline by setting a references to
Requirements framework for secure relevant documents
design, emphasizes are provided.
secure development
practices and data
protection
Overall The various components of this requirement are covered within major
coverage cybersecurity standards. Within these three selected standards, the gaps may be
and summarised as follow:
possible
— The hardware design part is less covered when compared to the software
gaps
counterpart
— A risk analysis process specifically targeted to system design is presented only
for IACS, while the more general ISO 27005 standard is not specific to system
or product design
Table 1: Mapping of security requirement No. 1
3.1.2 (2) Products with digital elements shall be delivered without any known
exploitable vulnerabilities;
— A vulnerability assessment should be performed against the digital elements of a product
— Known exploitable vulnerabilities shall be fixed before the release of the product
Keywords: exploitable vulnerability, vulnerability assessment
Standard Standard Rationale Gap Life-Cycle

ID
ISO/IEC Information Describes the minimum Covers only Validation

18045: security, actions to be performed for vulnerability
2022 cybersecurity a generic IT security discovery and
and privacy evaluation. It includes a not fixing
protection — dedicated section on vulnerabilities.
Evaluation vulnerability assessment. Cites only one
criteria for IT This section describes the discovery
security — main elements that should technique
Methodology be present in a vulnerability (penetration
for IT security assessment with specific testing).
evaluation steps and activities to be
followed (such as
penetration testing).
(note: this is
the standard
used for the (note: it is intended to be
Common used in conjunction with the
Evaluation
7
Methodology Common Criteria - ISO/IEC
(CEM)) 15408 series)
ITU-T Security Covers vulnerability Covers Validation

X.1214 assessment detection of ICT network (software-based)
Surveillance
(03/2018) techniques in elements; both known and ICT network
telecommunic unknown (zero-day) elements. Maintenance
ation/informa vulnerabilities; covers Vulnerability
tion and different techniques: detection only,
communicatio scanning, fuzzing, code not fixing. There
n technology review, binary analysis, is no detailed
networks penetration testing, plus step-by-step
some other supplementary procedure but
techniques an example
model that
could be
followed; the
standard
contains mainly
a list of
techniques that
could be used,
providing
general
descriptions of
these
techniques
EN IEC Security for Although specific only to This standard Validation

62443-4- industial Industrial Automation and applies only to
Surveillance
1:2018 automation Control Systems (IACS), this Industrial
and control standard contains several Automation and Maintenance
systems – provisions related to Control System
security testing, like
Part 4-1:
vulnerability testing and
Secure
penetration testing.
product
Moreover, it describes what
development
this tests should cover, who
lifecycle
should perform them, and
requirements
how to manage identified
cybersecurity issues
ETSI EN CYBER; Cyber Provision 5.2-3 of the The standard Validation

303 645 Security for standard refers to secure lacks explicit
V2.1.1 Consumer development lifecycle provisions
(2020-06) Internet of including vulnerability regarding
Things: management. conducting a
Baseline Manufacturers should vulnerability
Requirements continually monitor for assessment.
identifying and rectifying There is no
security vulnerabilities explicit
8
within products and services requirement to
they sell, produce, have fix each known
produced and services they exploitable
operate during the defined vulnerability
support period. before the
release of the
product
Overall The first two standards (ISO/IEC 18045:2022 and ITU-T X.1214) contain a step-by-
coverage step methodology for vulnerability assessment; collectively they cover the pre-
and and post-delivery phases of the product life cycle. They cover both known and
possible unknown (zero-day) vulnerabilities with a number of different, complementary
gaps techniques. The IEC 62443-4-1 standard prescribes several security tests on the
product, although referring only IACS, and the ETSI EN 303 645 standard poses a
requirement for IoT manufacturers not referring explicitly to the initial delivery
and without further implementation detail.
With the exception of the IEC 62443-4-1 standard, but which refers only to IACS,
the main identified gap is that the mentioned standards cover only vulnerability
detection and not the patching of the discovered vulnerabilities, so in general not
covering the whole requirement: ISO/IEC 18045 (which is the standard used for
the Common Evaluation Methodology (CEM) that is used in conjunction with the
Common Criteria - ISO/IEC 15408 series) describes a vulnerability assessment
methodology in validation phase and with only one technique, ITU-T X.1214 covers
more techniques in validation and maintenance phases but without a specific
methodology and focusing on ICT network elements, and ETSI EN 303 645
describes only the necessity to deliver products without vulnerabilities.
Table 2: Mapping of security requirement No. 2
3.1.3 (3) On the basis of the risk assessment referred to in Article 10(2) and where
applicable, products with digital elements shall:
(a) be delivered with a secure by default configuration, including the

possibility to reset the product to its original state;
— In case default configurations foresee an initial/default credential, the same should use a
complex and randomly chosen password, different for each product
— In case default configurations cover cybersecurity items, they should adopt a reasonable level
of security for each item
— The default configuration should be placed in a non-erasable memory
— A function to reset the product configuration to the default one should be implemented
Keywords: default configuration, randomised password, unique password, non-erasable memory,
ROM, reset, security by default
9
ID
EN Information This standard It mainly Implementation

ISO/IEC security, provides a set of provides general
Validation
27002: cybersecurity and generic controls for guidelines
2022 privacy protection information security covering several
— Information risk treatment. It different aspects,
security controls includes so it does not
implementation specifically target
guidance for the this requirement.
controls based on
recognised best
practices. Among the
technological
controls there is
configuration
management, which
addresses security
configuration of
hardware, software,
services and
networks.
ETSI EN CYBER; Cyber This standard defines The provisions Design

303 645 Security for cybersecurity are expressed at
Implementation
V2.1.1 Consumer Internet provisions for high-level
(2020-06) of Things: Baseline consumer IoT without details
Requirements devices. Among for a reasonable
those there are security level in
recommendations on the default
the use of default configuration
passwords on the and target
devices, secure specifically
storage of sensitive consumer IoT
parameters and the devices.
management of the
credentials (e.g.,
password
generation, user
authentication and
change of default
values)
ISO/IEC Information This standard defines The standard is Design

18031: technology — the conceptual dedicated to the
Implementation
2011 Security techniques model of non- definition of
— Random bit deterministic and models for
generation deterministic random bit
random bit generation, thus
generators for not specifically
10
cryptographic targeting
purposes. It specifies configuration
their security management
requirements and aspects.
covers application of
random bit strings
for random PIN and
password
generation. It can be
employed to address
aspects of
randomised
passwords and keys
for secure product
configuration.
Overall Aspects related to random password and key generation in general are well
coverage covered by ISO/IEC 18031:2011 for what concerns specific conceptual models.
and Those related to product configuration/credentials management (ISO/IEC
possible 27002:2022 and ETSI EN 303 645) are addressed at a high level, with references to
gaps NIST publications for details. More detailed implementation aspects relying for
example on the specific use of non-erasable memories for configuration
management seem not to be covered.
Table 3: Mapping of security requirement No. 3a
3.1.4 (3b) ensure protection from unauthorised access by appropriate control

mechanisms, including but not limited to authentication, identity or access
management systems;
— In accordance with the nature of the product and to the relevant risks identified in the risk
analysis, an appropriate system to provide authentication and authorisation should be
implemented.
— The access to personal/protected data and to administration/configuration functions should
be granted only to authenticated and authorised users
— In accordance with the nature of the product and to the relevant risks identified in the risk
analysis, physical unauthorized access should be forbidden
Keywords: authentication, authorisation, identity & access management, IAM, physical access
control, logical access control, anti-tampering
11
ID
ISO/IEC Information technology The General part Covers only Design

9798 — Security techniques of the ISO/IEC authentication.
Implementation
— Entity authentication 9798 standard
Parts 1 to
— specifies a model
6
for entity
Part 1:2010 General
authentication,
Part 2:2019 together with
Mechanisms using general
authenticated requirements
encryption and constraints
Part 3:2019 for the relevant
Mechanisms using mechanisms. It
digital signature covers a variety
techniques of authentication
protocols,
Part 4:1999 including one-to-
Mechanisms using a one and through
cryptographic check a third-party
function authentication.
Part 5:2009 Details for
Mechanisms using specific
zero-knowledge mechanisms are
techniques provided in the
other Parts of
Part 6:2010 this standard.
Mechanisms using
manual data transfer
ISO/IEC IT Security and Privacy This series of Covers only Design

24760 — A framework for standards identity
Implementation
identity management specifies a management
Parts 1 to
framework for systems; does Validation
3 Part 1:2019
issuing, not cover
Terminology and
administering, access
concepts
and managing management.
Part 2:2015 Reference identity data and
architecture and applies to any
requirements information
Part 3:2016 Practice system.
Part 1 defines
terms and core
concepts of
identity and
identity
management.
Part 2 provides
guidelines and
12
requirements for
the
implementation
of an identity
management
framework.
Part 3 provides
guidance for
ensuring that an
identity
management
system conforms
to Parts 1 and 2.
ISO/IEC Information technology This standard Covers access Design

29146: — Security techniques defines a management
2016 — A framework for framework for only; does not
access management access cover identity
management, management
building on top which is a pre-
of an identity requisite for
management this framework.
system (not
covered in this
standard). It
describes the
process to access
ICT resources in
a secure and
accountable way.
ITU-T Security guidelines for This standard It is of generic Design

X.1253 identity management provides nature and
(09/2011) systems guidelines for the does not apply
secure and to specific
privacy- identity
preserving management
deployment and systems; as
operation of such, high-level
identity descriptions of
management the techniques
systems. are provided.
ITU-T Information technology Provides a It is generic and Design

X.812 – Open Systems general overview does not
(11/1995) Interconnection – of access control, describe
Security frameworks policies and specific access
for open systems: mechanisms. It control
Access control can be used by mechanisms or
framework standards steps to be
describing performed to
13
specific access provide access
control control
mechanisms and services.
services.
ETSI EN CYBER; Cyber Security Provisions 5.1, The standard Design

303 645 for Consumer Internet 5.5: require emphasizes
Implementation
V2.1.1 of Things: Baseline authentication, authentication
(2020-06) Requirements unique and
passwords, and cryptography,
cryptographic but lacks
measures. specifics on
access
management
systems.
EN IEC Security for industial This standard, This standard Design

62443-4- automation and control related to IACS applies only to
Implementation
2:2019 systems – components, Industrial
includes Automation
Part 4-2: Technical
requirements and Control
security requirements
that cover the System
for IACS components
various aspects
of user
authentication
(all provisions
included in
Foundational
Requirement 1 –
Identification and
authentication
control) and
authorisation
(Component
requirement 2-1:
Authorisation
enforcement)
Overall The standards above cover the following areas: authentication, identity & access
coverage management, and access control. The aspects related with these areas are well
and covered by the above standards. It should be noted that the above standards are
possible mainly of generic nature and in most cases do not cover specific mechanisms and
gaps services.
Table 4: Mapping of security requirement No. 3b
14
3.1.5 (3c) protect the confidentiality of stored, transmitted or otherwise
processed data, personal or other, such as by encrypting relevant data at rest
or in transit by state of the art mechanisms;
— Data stored in a product’s internal memory should be encrypted at rest using current non-
deprecated technology
— Transmission protocols used to send/receive data should support encrypted communications
and enable them by default
— The product should implement symmetric or asymmetric encryption schemes (including PKIs)
to ensure that confidentiality of exchanged data is protected
Keywords: symmetric/asymmetric encryption, encryption at rest and in motion/transit, PKI,
certificates, sensitive assets confidentiality, data confidentiality

ID
ITU-T Security This standard Does not cover Design

X.805 architecture for describes a protection of
(10/2003) systems providing generic data at rest; very
end-to-end architecture for generic, covers
communications end-to-end the basic
communication principles that
security that is should be
independent of followed by
the network security
technology or mechanisms
protocol stack without
layer. describing
specific
mechanisms.
ISO/IEC Information This series of These standards Design

18033 security — standards do not describe
Implementation
Encryption describes key
Parts 1 to
algorithms — encryption management;
7
algorithms for only an overview
Part 1:2021 General
data is given in Part 1
Part 2:2006 confidentiality with relevant
Asymmetric ciphers both for stored references. Some
Part 3:2010 Block and transmitted algorithms are
ciphers data. It covers deprecated
symmetric and
Part 4:2011 Stream asymmetric
ciphers ciphers but also
Part 5:2015 Identity- non-conventional
based ciphers algorithms such as
homomorphic and
15
Part 6:2019 identity-based
Homomorphic ciphers.
encryption
Part 7:2022
Tweakable block
ciphers
ITU-T Information This standard It is very generic, Design

X.814 technology – Open defines the basic covers the basic
(11/1995) Systems concepts related principles of
Interconnection – to confidentiality, confidentiality
Security discussing also without
frameworks for types of describing
open systems: confidentiality specific protocol
Confidentiality services, exchanges
framework mechanisms,
threats and
attacks.
ETSI EN CYBER; Cyber Provisions 5.5.1, The standard Design

303 645 Security for 5.5.6, 5.5.7 focus lacks specific
Implementation
V2.1.1 Consumer Internet on secure coverage for
(2020-06) of Things: Baseline communication protecting all
Requirements and confidentiality data types, in
using particular at rest,
cryptography. and does not
Provisions 5.8.1, fully address
5.8.2 ensure particular
cryptographic encryption
protection of schemes.
personal data.
Provisions 5.4.1,
5.4.4 require
secure storage
and uniqueness of
security
parameters.
EN IEC Security for This standard, This standard Design

62443-4- industial related to IACS applies only to
Implementation
2:2019 automation and components, Industrial
control systems – includes a Automation and
confidentiality Control System.
Part 4-2: Technical
requirement for Moreover, the
security
both data at rest confidentiality
requirements for
and in transit requirement is
IACS components
(Component quite generic and
Requirement 4.1: does not provide
Information technical details
Confidentiality)
16
Overall The above standards cover the basic concepts and principles behind data
coverage confidentiality, both at-rest and in-transit. They also cover symmetric and
and asymmetric encryption algorithms, as well as homomorphic and identity-based
possible ciphers. The aspects related with these areas are well covered by the above
gaps standards. It should be noted here that the above standards are a mix of generic
standards independent from network technology or network stack layer and more
specific standards describing encryption algorithms.
Table 5: Mapping of security requirement No. 3c
3.1.6 (3d) protect the integrity of stored, transmitted or otherwise processed

data, personal or other, commands, programs and configuration against any
manipulation or modification not authorised by the user, as well as report
on corruptions;
— Integrity of data, programs and configurations stored in the product’s internal memory should
be ensured using current non-deprecated technology, e.g. hashing
— Transmission protocols used to send/receive data should support ways to ensure it is possible
to spot data alteration during the transmission (e.g. MACs)
— The product should implement symmetric or asymmetric encryption schemes (including PKIs)
to ensure that the integrity of exchanged data is protected
— A product should perform self-test to verify integrity of relevant code/information (e.g.
firmware)
Keywords: integrity, hashing, checksum, data corruption, PKI, certificates, self-test
Standard ID Standard Rationale Gap Life-Cycle
ISO/IEC 9796 Information Covers digital Does not cover Design

technology — signatures where digital
Parts 2 and Implementation
Security techniques part or the entire signatures with
3
— Digital signature message can be appendix; also,
schemes giving recovered from does not cover
message recovery the signature. It techniques for
describes key
Part 2:2010 Integer
deterministic and management
factorization based
randomized and random
mechanisms
mechanisms, number
Part 3:2006 specifying also the generation.
Discrete logarithm key production
based mechanisms method.
ISO/IEC 9797 Information These standards Does not cover Design

technology — cover several MAC key
Parts 1 to 3 Implementation
Security techniques algorithms based management of
— Message on block ciphers, block cipher
dedicated or mechanisms.
universal hash
17
Authentication functions. Part 1
Codes (MACs) covers 6 MAC
algorithms based
Part 1:2011
on block ciphers,
Mechanisms using
generic enough to
a block cipher
be applied to any
Part 2:2021 security
Mechanisms using architecture,
a dedicated hash- process or
function application.
Part 3:2011
Mechanisms using
a universal hash-
function
ISO/IEC Information Covers digital Does not cover Design

14888 technology — signatures where digital
Implementation
Security techniques the entire signatures with
Parts 1 to 3
— Digital message is stored message
signatures with and/or recovery; also,
appendix transmitted does not cover
together with the techniques for
Part 1:2008
signature. It key and
General
describes several certificate
Part 2:2008 Integer mechanisms, management,
factorization based including identity- and random
mechanisms based, and number
Part 3:2018 certificate-based generation.
Discrete logarithm schemes.
based mechanisms
ITU-T X.815 Information This standard It is of generic Design

(11/1995) technology – Open defines the basic nature; covers
Systems concepts related the basic
Interconnection – to integrity, also principles of
Security discussing types of integrity
frameworks for integrity services, without
open systems: policies, describing
Integrity framework mechanisms, specific
threats and mechanisms
attacks.
ETSI EN 303 CYBER; Cyber The standard While the Design

645 V2.1.1 Security for emphasizes standard
Implementation
(2020-06) Consumer Internet secure storage covers many
of Things: Baseline (5.4), and software aspects of data
Requirements integrity (5.7). integrity, it
18
These directly does not
align with the explicitly detail
requirement's information
focus on ensuring integrity.
integrity using
non-deprecated
technology like
hashing and
cryptographic
schemes
EN IEC Security for This standard, This standard Design

62443-4- industrial related to IACS applies only to
Implementation
2:2019 automation and components, Industrial
control systems – includes specific Automation
integrity and Control
Part 4-2: Technical
requirements that System.
security
cover software, Moreover, the
requirements for
updates, integrity
IACS components
configuration, requirements
communications, although quite
audit logs, etc. specific, do not
seem to have a
general
applicability in
all situation
(e.g. there is
not an integrity
requirement
prescribing all
memory to
have integrity
protection
feature, but
this might be
due to the
specific nature
of IACS)
Overall The above standards cover basic concepts and principles for providing integrity
coverage services. They also describe specific mechanisms for integrity based on digital
and possible signatures and MACs. The aspects related with these areas are well covered by
gaps the above standards. It should be noted here that the above standards are a mix
of generic (related to integrity concepts) and more specific standards (related to
integrity mechanisms).
Table 6: Mapping of security requirement No. 3d
19
3.1.7 (3e) process only data, personal or other, that are adequate, relevant and
limited to what is necessary in relation to the intended use of the product
(‘minimisation of data’);
— In general, refer to GDPR best practices, such as:
o it should not be asked to the user the provision of data that is not strictly necessary to
the execution of the task or service requested
o data no longer needed should be deleted without delay
Keywords: privacy, GDPR, data minimisation, personal data, data retention

ID
ISO/IEC Security This standard is an This standard, Design

27701: techniques — extension to ISO being an extension
Implementation
2019 Extension to 27001 and 27002 of the ISO/IEC
ISO/IEC 27001 and regarding privacy 27001 and 27002 Validation
ISO/IEC 27002 for information standards, refers Commissioning
privacy management. It to organisations
information includes rather than Surveillance
management — requirements and products. Maintenance
Requirements and controls for this Nevertheless, it
guidelines specific topic and could be argued End of Life
mapping with that an
relevant standards organisation
and legislation, like implementing the
the GDPR. controls included
in this standard
will do the same
for its products
ISO/IEC Information This standard No specific Design

29100: technology — provides a high- requirements or
Implementation
2011 Security level framework for controls are
techniques — the protection of PII present in this Validation
Privacy framework within ICT systems. document Commissioning
Although it is quite
high-level and does Surveillance
not include Maintenance
concrete
requirements and End of Life
controls, it contains
explanatory
sections on key
privacy concepts,
including data
minimisation
20
ETSI TS CYBER; This Technical The documents Design
103 485 Mechanisms for Specification does not list
Implementation
V1.1.1 privacy assurance document specific
(2020-08) and verification describes requirements or Validation
mechanism to controls Commissioning
enable assurance
of privacy, using Surveillance
references to Maintenance
Common Criteria
documents and to End of Life
the GDPR
ETSI EN CYBER; Cyber The standard While the standard Design

303 645 Security for addresses data outlines broad
Implementation
V2.1.1 Consumer protection and measures for data
(2020-06) Internet of Things: minimization, with security and
Baseline provisions ensuring processing, it lacks
Requirements secure data specific guidance
handling, for data
transparent minimization
processing, and practices such as
adhering to the the deletion of
principles of only unnecessary data
processing and prevention of
necessary data forced
(e.g., Sections 5.8 registrations. It
and 6). The would also benefit
standard from better
emphasizes secure reference to some
and responsible explicit GDPR-
data management, specific best
aligning with GDPR practices to be
principles, thereby more effective.
addressing the
requirement to a
considerable
extent.
Overall This privacy requirements is very well covered especially in the ISO/IEC 27701
coverage standard, that proposes a mapping between various standards and legislation,
and including the GDPR. The concept of data minimisation is well covered.
possible
gaps
Table 7: Mapping of security requirement No. 3e
21
3.1.8 (3f) protect the availability of essential functions, including the resilience
against and mitigation of denial of service attacks;
— The product should be hardened against attacks, like for instance distributed denial of service
attacks, by implementing, among other things, the following measures if appropriate:
o reverse proxies network segmentation
o load balancing
o rate limiting
o redundancy and high availability solutions
o backup sites
o disaster recovery plans
o minimize offered services
Keywords: availability, resiliency, secure outages, backup, denial of service, DoS, DDoS, protocol-
based attacks, connection limit

ID
EN Information This standard provides a The guidance Implementation

ISO/IEC security, set of generic controls for developing
Validation
27002: cybersecurity and for information security availability of
2022 privacy protection risk treatment. It essential
— Information includes implementation functions is
security controls guidance for the provided at a
controls based on high level
recognised best (e.g., for DoS
practices. Among the protection).
organisational controls
there is information
transfer, which
mentions denial of
service protection for
electronic messaging
and availability of
services and information
ISO/IEC Information This standard describes The focus is Design

22237- technology — the principles for specifically for
Implementation
1:2021 Data centre availability, reliability data centre
facilities and and resilience of data facilities and
infrastructures — centres, seen as key infrastructure
Part 1: General element for housing and s. Although
concepts supporting IT data this would
processing, storage and cover services
transport. Availability is and
also considered as a applications
provisioned
22
dimension for data from a data
centres classification. centre, it does
not refer to
the design of
generic user
products.
ITU-T Security This standard defines a Specific for Design

X.805 architecture for network security end-to-end
Implementation
(10/2003) systems providing architecture for network
end-to-end providing end-to-end security, it
communications network security. The does not
architecture is cover general
applicable to different aspects of
types of networks and systems or
considers several products
security dimensions design.
(including availability)
and security planes
(management, control,
end-user). The
availability dimension
explicitly mentions
protection against active
attacks such as Denial of
Service (DoS).
ETSI EN CYBER; Cyber This standard gathers The provisions Design

303 645 Security for cybersecurity provisions are expressed
Implementation
V2.1.1 Consumer for consumer IoT at high-level
(2020-06) Internet of devices. It contains and target
Things: Baseline provisions on systems specifically
Requirements resilience to outages, consumer IoT
including mitigations devices.
against Distributed
Denial of Service (DDoS)
attacks. More specifically
about some provisions:
5.5 Communicate
securely: Emphasizes
best practice
cryptography and secure
authentication.
5.6 Minimize exposed
attack surfaces: Focuses
on disabling unused
interfaces and secure
development.
5.9 Make systems
resilient to outages:
23
Addresses resilience in
case of data networks
and power outages.
EN IEC Security for This standard, related to This standard Design

62443-4- industial IACS components, applies only to
Implementation
2:2019 automation and includes specific Industrial
control systems – requirements focused Automation
on maintaining a and Control
Part 4-2:
baseline of operational System.
Technical security
functionalities also in
requirements for
cases of denial of service
IACS components
attacks (see Component
Requirement 7.1: Denial
of service protection).
Moreover, it presents a
requirement that
prescribes a resource
usage limitation
capability to prevent
resource exhaustion
(Component
Requirement 7.2:
Resource management).
Overall General availability aspects are covered by ISO/IEC 22237-1:2021 for what concerns
coverage the design of data centre facilities and infrastructures, that could be applicable to
and some digital products and services but do not cover all the landscape. Broader
possible scope is provided by ISO/IEC 27002:2022 and ETSI EN 303 645 even if at a high level
gaps and, for the latter, focusing on IoT consumer devices. ITU-T X.805 (10/2003) covers
the requirement for end-to-end network security. EN IEC 62443-4-2 covers the
requirement for IACS. A possible gap could be the more detailed guidance on
implementation of availability principles for generic user products.
Table 8: Mapping of security requirement No. 3f
3.1.9 (3g) minimise their own negative impact on the availability of services
provided by other devices or networks;
— The product should limit outgoing network connections to what is strictly needed
— The product should implement measures such as timeouts and exception handling to avoid
generating multiple requests to a busy/not responsive service
Keywords: network saturation, minimization, connection limits, timeouts, exception handling
24
ID
ETSI EN CYBER; Cyber The standard includes While the standard Design
303 645 Security for requirements on encompasses
Implementation
V2.1.1 Consumer system resilience, security, data
(2020-06) Internet of limiting unnecessary protection, and
Things: exposure, and orderly resilience, it
Baseline network connections, doesn't specifically
Requirements which align with focus on
minimizing negative minimizing
impacts on other interference with
services. other services as
in the given
Relevant Provisions:
requirement.
5.6 Minimize exposed Provisions related
attack surfaces to network
5.9 Make systems saturation,
resilient to outages connection limits,
and exception
5.13 Validate input handling are not
data fully addressed in
the standard,
indicating
potential gaps in
coverage.
Moreover, the
provisions are
expressed at high-
level and target
specifically
consumer IoT
devices.
ITU-T Requirements In section 9.5 “Specific Although specific, Design

Y.4810 for data requirements for data these
Implementation
(11/2021) security of transfer to and from requirements,
heterogeneous heterogeneous IoT related only to IoT
Internet of devices” the following devices, limit their
things devices two requirements coverage to data
could be seen as transfer and radio
partially covering this interference. In
topic: the document
there are not
it is required to limit
other elements
the function of data
that could be
transfer to and from an
mapped to this
IoT device – the
element
process of a specific
type of data transfer is
required to be initiated
25
only with explicit
permission of end
users
it is required to have
the anti-interference
ability between the IoT
device and network
equipment.
Overall Requirement 3(g) of the CRA proposal is covered only in documents related to IoT
coverage devices, although they can be considered quite generic. However, even in these
and documents the coverage is limited to a minimal number of high-level provisions.
possible
gaps
Table 9: Mapping of security requirement No. 3g
3.1.10 (3h) be designed, developed and produced to limit attack surfaces, including
external interfaces;
— The product’s hardware design should limit all the connections and interfaces that are not
strictly required for performing the various tasks the product is expected to do
— If required by a risk assessment, a physical product should include tamper-resistant features
— The product/service should have all not essential network ports closed as a default
configuration
— Software present in digital product should be designed to avoid having unnecessary entry
points (e.g. API) open and available for external unauthorised callers
Keywords: hardware hardening, tamper-resistance, system hardening, software hardening,
interfaces, security by design
Standard ID Standard title Rationale Gap Life-Cycle
ISO/IEC TS Information This technical This document Design

19249:2017 technology — specification document is rather
Security describes some descriptive and
techniques — security design does not
Catalogue of principles that would include a
architectural help developing a concrete
and design secure product. In the “requirements”
principles for list it is included the list
secure attack surface
products, minimisation principle,
systems and at the core of this
applications requirement. The
description is followed
by a concrete example
26
of the application of
the principle.
ISO/IEC Information This standard lists a This document Design

15408- security, series of security does not list
Implementation
2:2022 cybersecurity functional concrete
and privacy components, that, in “requirements” Validation
protection — the Common Criteria
Evaluation jargon are defined as
criteria for IT the basis for security
security — Part functional
2: Security requirements.
functional
In particular, the
components
“Limited capabilities
and availability” section
defines requirements
to limit the capabilities
(i.e. a function should
provide only the
capabilities necessary
for its genuine
purpose) and
availability (i.e. the use
of a specific function
should be restricted
when not
needed/required) of
functions.
This is useful to
enforce design
principles such as least
privilege and attack
surface minimization
EN IEC Security for Although this standard In this standard Design

62443-4- industrial is specific for Industrial it is not present
Implementation
2:2019 automation Automation Control a requirement
and control Systems, it lists several dedicated to an Validation
systems - Part requirements related attack surface
4-2: Technical to physical hardening, minimisation
security like “Physical tamper principle.
requirements resistance and Moreover, this
for IACS detection” and “use of document
components physical diagnostic and targets
test interfaces” exclusively
Industrial
Automation
Control
Systems
27
ETSI EN 303 CYBER; Cyber The requirement This standard is Design
645 V2.1.1 Security for closely aligns with specific to IoT
Implementation
(2020-06) Consumer Section 5.6 of this consumer
Internet of standard, which devices and
Things: emphasizes minimizing does not
Baseline exposed attack automatically
Requirements surfaces through apply to other
disabling unused categories of
interfaces, not products, for
unnecessarily exposing which other
physical interfaces, and and maybe
following secure more specific
development provisions may
processes. be needed.
Overall This requirement is well covered from a theoretical point of view in the analysed
coverage documents, that well describe what are the security design principles that would
and allow to minimise the attack surface of a product with digital elements.
possible Nevertheless, we found a lack of concrete requirements and practical controls
gaps that, implemented, would indeed ensure an attack surface minimisation.
Standard EN IEC 62443-4-2:2019 is a partial exception to this as it included
concrete requirements although limited to industrial automation and control
systems.
Table 10: Mapping of security requirement No. 3h
3.1.11 (3i) be designed, developed and produced to reduce the impact of an incident
using appropriate exploitation mitigation mechanisms and techniques;
— The product should be designed in a way that gaining unauthorised access to a function or
data does not automatically lead to a complete access to all product’s functions and data
(defence in depth principles)
— Sensitive data stored in a product’s internal memory should be encrypted at rest
— The product should not store data that is not relevant or necessary to perform its tasks (data
minimisation)
Keywords: defence in depth, encryption-at-rest, data minimisation, security by design, hardening,
risk assessment, secure architecture, sandboxing, secure environment

ID
ISO/IEC Information Provides a It does not cover Design

27001: security, systematic specific technical
2022 cybersecurity approach for measures for
and privacy managing defence in depth,
protection — information encryption at rest,
Information security risks. or sandboxing.
28
security
management
systems —
Requirements
ISO/IEC Information Offers best High-level Design

27002: security, practices for guidelines, might
Implementation
2022 cybersecurity selecting and lack specific details
and privacy implementing on secure software
protection — security controls. design and
Information hardening.
security
controls
ISO/IEC Information Focuses on secure The standard Design

27034- technology — development promotes security
Implementation
1:2011 Security practices for in all software
techniques — software development
Application applications. phases, implicitly
security — Part supporting defence-
1: Overview and in-depth, but
concepts doesn't detail
hardening and
sandboxing. While
not specifying
controls like
encryption at rest, it
encourages risk
assessments and
appropriate control
implementation.
Data minimisation
isn't explicitly
addressed, but
could be
implemented if
identified as a risk.
EN Information Provides security This standard Design

ISO/IEC security, evaluation criteria primarily focused
Implementation
15408- cybersecurity for IT products and on evaluation
3:2022 and privacy systems. criteria, not specific
protection — mitigation
Evaluation mechanisms or
criteria for IT techniques which
security — Part could be enforced
3: Security through security
assurance functional
components requirements
defined in ISO/IEC
15408-2:2022.
29
However, it could be
used to provide
assurance in the
product thus
reducing the impact
of an incident using
appropriate (=
assessed by the lab)
exploitation
mitigation
mechanisms and
techniques.
EN Information Specifies the This standard Validation

ISO/IEC security, methodology for focuses on
18045: cybersecurity evaluating the methodology for IT
2022 and privacy security properties security evaluation,
protection — of IT products and not specific
Evaluation systems. mitigation
criteria for IT mechanisms. But it
security — supports the
Methodology ISO/IEC 15408-
for IT security 3:2022 coverage
evaluation statement above
while providing
evaluation methods
considering for
instance attack
potential calculation
to assess the
mitigation
mechanisms and
techniques for
robustness.
ETSI EN CYBER; Cyber The requirement Data Minimization: Design

303 645 Security for aligns with the Lacking explicit
Implementation
V2.1.1 Consumer standard principles coverage in
(2020-06) Internet of emphasizing secure provisions,
Things: Baseline design, encryption, constituting a gap.
Requirements minimizing data,
Secure architecture,
and resilience.
sandboxing, secure
More specifically:
environment: not
Defence in Depth explicitly defined,
Principles: leading to potential
provisions 5.6, 5.9, gaps.
and 5.6-9 cover this
principle but may
need more specific
layering details.
30
Encryption-at-Rest:
provisions 5.4-1,
5.4-2, 5.3-7, and
5.5-1 partly address
this requirement.
Other Relevant
Provisions:
Ensuring software
integrity (5.7)
Encrypted
communication
(5.5)
Hardening by
disabling unused
interfaces and
minimizing code
(5.6-1, 5.6-6)
Secure
management
processes and best
practice
cryptography (5.5-8,
5.3-7)
IEC 62443- Security for Provides guidelines Relevant to Design

3-2:2020 industrial for security risk Industrial products.
automation and assessment and While it doesn't
control systems secure system explicitly mention
- Part 3-2: design, addressing encryption at rest or
Security risk defence in depth data minimisation, it
assessment for through network covers security by
system design segmentation design, risk
strategies. It implies assessment, and
hardening through secure architecture.
identification of However, specific
vulnerabilities and sandboxing or
countermeasures. secure environment
requirements aren't
detailed.
Overall The standards provide a solid foundation in secure system design, secure product
coverage development, risk assessment, security evaluation, and security controls.
and However, some aspects of defence in depth, sandboxing, and certain mitigation
possible techniques might not be explicitly covered by the selected standards.
gaps
Table 11: Mapping of security requirement No. 3i
31
3.1.12 (3j) provide security related information by recording and/or monitoring
relevant internal activity, including the access to or modification of data,
services or functions;
— A product should contain a log of cybersecurity related events
— Access or modification of data, services or functions should be logged
— Such log should be accessible to the privileged user
— Logs should be protected from unauthorised modification or corruption
Keywords: logging, event monitoring, non-repudiation, intrusion detection, tamper-detection

ID
EN ISO/IEC Information This standard provides a Guidance in Implementation

27002: security, set of generic controls this standard is
Validation
2022 cybersecurity for information security generally
and privacy risk treatment. It provided at a
protection — includes implementation high level, even
Information guidance for the controls though for this
security based on recognised requirement
controls best practices. Among few examples
those there is logging facilitate the
and monitoring identification of
activities, which use cases and
embraces logging of main actions to
events and protection of put in place.
log information. It
includes example of
events to log and of
unauthorised changes.
ISO/IEC Information Standard specific for More general Design

13888- security — non-repudiation aspects not
Implementation
1:2020 Non- mechanisms using related to non-
repudiation — cryptographic repudiation are Validation
Part 1: General techniques, it targets not in the
generation of evidence scope of this
concerning relevant standard.
events. It can be applied
to recording and
monitoring of activities
as specified in the
requirement with
particular focus on non-
repudiation.
32
ETSI EN CYBER; Cyber Relevant Provisions: The Design
303 645 Security for requirement
5.9-2, 5.9-3 (Resilience): Implementation
V2.1.1 Consumer related to
focus on resilience and
(2020-06) Internet of recording Validation
restoration after
Things: and/or Surveillance
outages. They imply the
Baseline monitoring
need to monitor system Maintenance
Requirements relevant
behaviour, possibly
internal activity,
including unauthorized
including the
access attempts or
access to or
modifications, although
modification of
this is not explicit.
data, services,
5.10-1 (Examine system or functions, is
telemetry data): calls for not explicitly
examining telemetry addressed.
data, including the While there are
monitoring of system some aspects
usage and behaviour. It related to
aligns with the focus on telemetry data
recording and and input
monitoring internal validation,
activities, such as specific
unauthorized access or guidelines or
modifications. mandates for
5.11-1 to 5.11-4 (Easy logging
deletion of user data): cybersecurity-
allow users to control related events,
and erase their data. and ensuring
They indirectly imply that logs are
tracking of data access accessible to
and modification privileged users
while being
5.13-1 (Validate input protected from
data): requires data unauthorized
input validation to modification or
ensure its integrity and corruption, are
authenticity. It implies a not expressly
monitoring mechanism detailed in the
and may indirectly relate standard.
to logging and event
monitoring
IEC 62443- Security for This standard is related Relevant only Design
4-2:2019 industrial to IACS. Within the listed to IACS.
Implementation
automation requirements there are
and control also provisions about
systems - Part event auditing
4-2: Technical (Component
security Requirement 2.8:
requirements Auditable events),
timestamping of audit
33
for IACS records (Component
components Requirement 2.11:
Timestamps) and non-
repudiation (Component
Requirement 2.12: Non-
repudiation)
Overall Monitoring aspects with specific focus on non-repudiation are covered in ISO/IEC
coverage 13888-1:2020. ISO/IEC 27002:2022 gives a more general overview and high-level
and provisions. ETSI EN 303 645 V2.1.1 touches upon telemetry data, data validation
possible and integrity. EN 62443-4-2 covers the requirement for IACS.
gaps
Table 12: Mapping of security requirement No. 3j
3.1.13 (3k) ensure that vulnerabilities can be addressed through security updates,
including, where applicable, through automatic updates and the notification
of available updates to users.
— The company distributing a product or service should provide timely security updates for the
software components of the product/service for a reasonable amount of time.
— A function to automatically check the presence of updates and install them, or notify the user
of their presence, should be implemented, and where applicable this should be the default
initial configuration.
— A product should provide a secure mechanism to install/implement updates
— The company distributing a product should notify the user on the availability of updates
Keywords: Indicator of Compromise, patching, software updates, automatic updates, user
notification, secure update functionality

ID
EN Information security, Covers general Lacks specific Design

ISO/IEC cybersecurity and principles for guidance on
Validation
27002: privacy protection — information automatic
2022 Information security security updates and user
controls management, notifications
including patch
management
ISO/IEC Information technology Focuses on Lacks guidance Design

30111: — Security techniques vulnerability on secure
2019 — Vulnerability handling handling processes mechanisms for
processes but not specifically installing/implem
on the mechanisms enting updates
for delivering and
installing updates
34
ETSI EN CYBER; Cyber Security Addresses security Lacks detailed Design
303 645 for Consumer Internet updates, automatic guidance on
V2.1.1 of Things: Baseline updates, and user secure
(2020-06) Requirements notifications for mechanisms for
consumer IoT installing/implem
devices enting updates
IEC 62443- Industrial Addresses patch Limited to Design

2-1:2010 communication management and industrial
networks - Network and updates in the automation and
system security - Part 2- context of control system
1: Establishing an industrial environments. It
industrial automation automation and does not cover
and control system control systems automatic
security program updates and user
notifications in
detail
IEC 62443- Security for industrial Provides guidance Limited to Design

4-2:2019 automation and control on patch industrial
systems - Part 4-2: management and automation and
Technical security security updates control system
requirements for IACS for IACS components – It
components components does not cover
user notifications
Overall The identified standards focus on different aspects of vulnerability management,

coverage patching, and updates. However, some standards mention the need for secure
and updates, but they do not provide detailed guidance on the secure mechanisms for
possible installing/implementing updates. Also, they do not explicitly cover the requirement of
gaps notifying users about the availability of updates.
Table 13: Mapping of security requirement No. 3k
35
3.2 Vulnerability handling requirements
3.2.1 Manufacturers of the products with digital elements shall:

(1) identify and document vulnerabilities and components contained in the
product, including by drawing up a software bill of materials in a commonly
used and machine-readable format covering at the very least the top-level
dependencies of the product;
— A monitoring of the cybersecurity status of the overall supply chain for the acquisition of the
necessary components incorporated in the product should be put in place.
— All libraries and external components used in the software part of a product, including their
version number should be listed in a Software Bill of Material (SBOM) available to the user
— Such Software bill of materials (SBOM) should be compliant to the relevant standards (e.g.,
ISO/IEC 5921:2021 also known as SPDX [2] or CycloneDX [4] standard)
Keywords: software bill of materials, SPDX, CycloneDX, supply chain security, machine-readable,
versioning, software dependencies, composability

ID
ISO/IEC Cybersecurity This standard covers While it is Design

27036 — Supplier information security for relevant to the
Surveillance
relationships — supplier relationships. It overall supply
Parts 1 to
Part 1:2021 provides guidance on chain, it doesn't Maintenance
3
Overview and managing information specifically
concepts security risks associated address the
with suppliers and third- creation,
Cybersecurity
party developers. This can management, or
— Supplier
be relevant to SBOM in the exchange of
relationships —
context of the software Software Bill of
Part 2:2022
supply chain. Materials
Requirements
(SBOM).
Cybersecurity
— Supplier
relationships —
Part 3:
Guidelines for
hardware,
software, and
services supply
chain security
Overall To address the gaps in ISO/IEC 27036 related to Software Bill of Materials (SBOM),
coverage it's recommended to consider the following standards and initiatives:
and
— SPDX: A Linux Foundation standard for sharing software components, licenses,
possible
copyrights, and security data, providing a consistent SBOM format [2].
gaps
36
— NTIA's Software Component Transparency Initiative: A U.S. initiative working
on standardizing SBOM formats and best practices for software component
transparency [3].
— CycloneDX: An SBOM specification designed for application security and supply
chain component analysis, offering a lightweight format for describing
software components and metadata [4].
— ECSO Supply Chain management and Product Certification Composition [5]
— IIoTSBOM is an initiative from LSEC, Flanders Make and KU Leuven COSIC from
Belgium to improve cybersecurity for devices. Inspired and with the support of
the US CISA (Cyber Security and Infrastructure Security Agency) [6]
Combining these standards and initiatives with ISO/IEC 27036 can help create a
comprehensive approach to managing SBOMs, addressing information security
risks in supplier relationships, and improving software supply chain transparency.
Table 14: Mapping of vulnerability handling requirement No. 1
3.2.2 (2) in relation to the risks posed to the products with digital elements,
address and remediate vulnerabilities without delay, including by providing
security updates;
— In case vulnerabilities are found they should be classified in accordance with standard severity
metrics (e.g. CVSS)
— vulnerabilities that can be directly fixed by the company should be fixed without delay, in
accordance to their severity and the posed risks
— In case a vulnerability is found in a software component of a product (including libraries and
third party components), an update should be prepared and distributed as soon as possible
— The company developing a product or service should be subscribed to updates coming from
CERTs and cybersecurity organisations and analyse them in order to spot vulnerabilities in their
products
— The company developing a product or service should remain updated on the release of new
versions of the libraries or third party software components included in their products/services
and update the relative software whenever such new version includes a security update
Keywords: security updates, CVSS, updates release, vulnerability management, secure policy

ID
ISO/IEC Information This international This standard Surveillance

27001: security, standard provides a provides a high-level
Maintenance
2022 cybersecurity and framework for framework for
privacy protection establishing, information security
— Information implementing, management. It
security maintaining, and doesn't explicitly
management continually improving cover vulnerability
an information classification, patch
37
systems — security management, or
Requirements management system handling security
(ISMS). It outlines the updates for libraries
requirements for and third-party
managing risks components.
related to
information security,
including addressing
and remediating
vulnerabilities in
digital products.
ISO/IEC Information This standard While it offers Surveillance

27002: security, provides best guidelines for
Maintenance
2022 cybersecurity and practices and information security
privacy protection guidelines for controls, it is not
— Information implementing sufficient in providing
security controls information security detailed guidance on
controls in vulnerability
organizations. It classification, specific
covers various patch management
aspects of procedures, or
vulnerability addressing
management, vulnerabilities in
including risk third-party
assessment, components.
vulnerability
classification, and
remediation.
EN Information This standard This standard focuses Surveillance

ISO/IEC technology — specifies the process on the process for
Maintenance
30111: Security for vulnerability vulnerability handling
2020 techniques — handling in software in software products
Vulnerability products. It provides but does not
handling guidance on how specifically address
processes organizations can subscribing to
identify, analyse, and updates from CERTs
remediate and cybersecurity
vulnerabilities in their organizations or
software products, maintaining updates
including distributing for third-party
security updates. components and
libraries.
EN Information This standard defines This standard focuses Surveillance

ISO/IEC technology — the process for on vulnerability
Maintenance
29147: Security vulnerability disclosure and does
2020 techniques — disclosure, focusing not cover aspects like
on how organizations vulnerability
can receive and classification,
38
Vulnerability process vulnerability remediation, and
disclosure reports from external patch management in
sources, such as a comprehensive
CERTs and manner.
cybersecurity
organizations.
EN IEC Security for This standard is This standard is for Surveillance

62443-4-1 industrial related to IACS. It IACS only. Moreover,
Maintenance
2018 automation and contains although it requires
control systems – requirements security patches, it
covering security does not cover
Part 4-1: Secure
updates and in aspects like
product
particular timely vulnerability
development
delivery of security classification,
lifecycle
patches (SUM-1 remediation and
requirements
“Security update patch management in
qualification” and a comprehensive
SUM-5 “Timely manner.
delivery of security
patches”)
Overall While each standard provides valuable information and guidance, there is no single
coverage standard that comprehensively addresses all aspects of vulnerability management,
and including classification, remediation, patch management, handling updates from
possible CERTs and cybersecurity organizations, and maintaining updates for third-party
gaps components and libraries.
To cover this gap, these standards could be combined to address the specific
security needs aligned with sectoral requirements, and the regulatory landscape. By
leveraging the strengths of each standard, a more comprehensive vulnerability
management process addressing and remediating vulnerabilities in products with
digital elements could be needed to fully cover this requirement.
3.2.3 (3) apply effective and regular tests and reviews of the security of the
product with digital elements;
— Periodic vulnerability assessment should be executed, especially towards those components
that present the highest risk
— When developing or maintaining software components, automatic tests should be executed
whenever a new commit/build/version is prepared, if possible using Continuous
Integration/Continuous Deployment (CI/CD) techniques
— A risk assessment should be re-evaluated whenever there is a significant change in one of the
dimensions analysed (new threats, new vulnerabilities, etc.) or a new product release.
Keywords: vulnerability assessment, continuous integration/continuous deployment, risk
assessment, security testing procedures, testing
39
ID
ISO/IEC Information This international This standard Surveillance

27001: security, standard provides a provides a high-
Maintenance
2022 cybersecurity and framework for level framework
privacy protection establishing, for information
— Information implementing, security
security maintaining, and management. It
management continually improving does not explicitly
systems — an information security cover detailed
Requirements management system security testing
(ISMS). It outlines the procedures,
requirements for continuous
managing risks related integration/contin
to information security, uous deployment
including performing (CI/CD), or specific
regular security tests testing
and reviews. methodologies.
ISO/IEC Information This standard provides While it offers Surveillance

27002: security, best practices and guidelines for
Maintenance
2022 cybersecurity and guidelines for information
privacy protection implementing security controls, it
— Information information security is not sufficient in
security controls controls in providing detailed
organizations. It covers guidance on
various aspects of specific security
security testing and testing
vulnerability procedures, CI/CD
management, including techniques, or the
risk assessment and frequency and
periodic reviews. scope of testing.
ISO/IEC TS Information This standard focuses This standard Surveillance

27034-5- technology — on application security focuses on
Maintenance
1:2018 Application and provides application
security — Part 5- guidelines for security but might
1: Protocols and embedding security not cover all
application into the software aspects of security
security controls development lifecycle, testing, especially
data structure, including regular for non-software
XML schemas security testing and products,
reviews of applications. hardware
components, or
infrastructure
elements.
40
ISO/IEC Information This standard provides This standard Surveillance
27005: security, guidelines for provides
Maintenance
2022 cybersecurity and information security guidelines for
privacy protection risk management, information
— Guidance on which includes risk security risk
managing assessment, risk management, but
information treatment, and regular it does not cover
security risks monitoring and review specific security
of risks associated with testing
digital products. methodologies or
CI/CD techniques.
Overall While each standard provides valuable information and guidance, there is no single
coverage standard that comprehensively addresses all aspects of security “effective” testing
and and reviews for products with digital elements, including specific testing
possible methodologies, CI/CD techniques, and the frequency and scope of testing.
gaps
To cover this gap, it could be considered the implementation of a combination of

these standards and guidelines, tailoring the approach to the specific needs,
industry, and regulatory landscape. By leveraging the strengths of each standard, it
may be developed a more comprehensive security testing process during the
development phase (e.g. DevSecOps) that addresses the requirement of applying
effective and regular tests and reviews of the security of products with digital
elements.
3.2.4 (4) once a security update has been made available, publically disclose
information about fixed vulnerabilities, including a description of the
vulnerabilities, information allowing users to identify the product with
digital elements affected, the impacts of the vulnerabilities, their severity
and information helping users to remediate the vulnerabilities;
— New CVE indicators should be publicly released and disseminated as soon as the relative
security update has been released or implemented
Keywords: Common Vulnerabilities and Exposures (CVE), vulnerability disclosure, vulnerability
analysis

ID
EN Information This standard provides This standard Surveillance

ISO/IEC technology — guidelines for provides
Maintenance
29147: Security vulnerability disclosure, guidelines for
2020 techniques — including vulnerability
Vulnerability recommendations on disclosure but
disclosure how to disclose does not offer
41
vulnerability specific guidance
information, such as the on the timeline
nature of the for public
vulnerabilities, affected disclosure or the
products, impacts, exact format for
severity, and sharing
remediation vulnerability
information. information.
EN Information This standard focuses While it focuses Surveillance

ISO/IEC technology — on the process of on the process of
Maintenance
30111: Security vulnerability handling in vulnerability
2020 techniques — software products, handling in
Vulnerability including the steps software
handling processes necessary to investigate, products, it does
resolve, and publicly not provide
disclose vulnerability detailed guidance
information. on the public
disclosure of
vulnerability
information for
non-software
products or
hardware
components.
ETSI EN CYBER; Cyber This European standard Even if the Surveillance

303 645 Security for is dedicated to standard remains
Maintenance
V2.1.1 Consumer Internet consumer internet of quite generic it is
(2020-06) of Things: Baseline things. Chapter 5.2 is dedicated to
Requirements dedicated to a means to internet of things
manage reports of (IoT). It provides
vulnerabilities. It refers overview of
to EN ISO/IEC 29147 vulnerability
document. disclosure policy
content, timeline
is a general one
and not more
precise than EN
ISO/IEC 29147.
EN IEC Security for This standard is related This standard is Surveillance

62443-4-1 industrial to IACS. Requirement for IACS only.
Maintenance
2018 automation and DM-5 “Disclosing
control systems – security-related issues”
prescribes the
Part 4-1: Secure
disclosure of
product
information related to
development
the fixed vulnerability in
lifecycle
a timely matter.
requirements
42
Overall While these standards and initiatives contribute to the process of vulnerability
coverage disclosure, they do not comprehensively address all aspects of public disclosure,
and such as specific disclosure timelines or the exact format for sharing vulnerability
possible information across different industries or product types.
gaps
these standards and initiatives, tailoring the approach to the specific needs,
industry, and regulatory landscape. Additionally, it may be possible to rely on
vulnerability disclosure policies and procedures that align with industry best
practices (including for instance: CVE [7], NIST National Vulnerability Database (NVD)
[8], FIRST Vulnerability Reporting and Data eXchange (VRDX) SIG [9]). As part of a
holistic approach, engaging with and incorporating feedback from various
stakeholders, such as customers, researchers, and security experts, should be an
ongoing, integral part of the vulnerability management process. By leveraging the
strengths of each standard and initiative, it may be possible to create a
comprehensive and effective vulnerability disclosure process that meets the
requirement and its sub-requirements.
3.2.5 (5) put in place and enforce a policy on coordinated vulnerability disclosure;
— The company should adopt and enforce the CVD policy
Keywords: CVD policy

ID
EN Information This standard provides This standard Design

ISO/IEC technology — guidelines for offers guidelines
Surveillance
29147: Security vulnerability disclosure, for vulnerability
2020 techniques — which includes disclosure but Maintenance
Vulnerability recommendations for does not provide
disclosure organizations to develop detailed guidance
and implement a CVD on the
policy. It offers guidance implementation of
on the disclosure a CVD policy, such
process, roles and as specific
responsibilities, and how processes or
to communicate requirements for
vulnerability different
information. industries.
EN Information This standard focuses on This standard is Design

ISO/IEC technology — the process of dedicated to
Surveillance
30111: Security vulnerability handling in vulnerability
2020 techniques — software products. It handling Maintenance
Vulnerability complements ISO/IEC processes,
29147 by providing including
43
handling guidance on coordinated
processes investigating, resolving, vulnerability
and disclosing disclosure (CVD).
vulnerabilities in a However, it
coordinated manner. doesn't specify the
enforcement of a
particular national
or EU CVD policy.
ETSI EN CYBER; Cyber This European standard Even if the Surveillance

303 645 Security for is dedicated to standard remains
Maintenance
V2.1.1 Consumer consumer internet of quite generic it is
(2020-06) Internet of Things: things. Chapter 5.2 is dedicated to
Baseline dedicated to a means to internet of things
Requirements manage reports of (IoT). It provides
vulnerabilities. It refers some details
to EN ISO/IEC 29147 related to
document vulnerability
disclosure, and
highlights the
successful use of
CVD in some
software
industries but
without details on
how to apply it in
the IoT domain.
There is also a
reference to the
Common
Vulnerability
Reporting
Framework (CVRF)
but without
details.
Overall While the mentioned standards and initiatives contribute to the development and
coverage implementation of a CVD policy, they do not comprehensively address all aspects of
and enforcing such a policy or provide specific guidance tailored to different industries
possible and product types.
gaps
these standards, initiatives, and national / EU CVD policies. Additionally, it may be
possible to rely on CVD policies and procedures that align with industry best
practices (e.g. NIST SP 800-61 Revision 2 [10], FIRST VRDX SIG [9]). By leveraging the
strengths of each standard and initiative, it may be possible to create a
comprehensive and effective CVD policy that meets the requirement.
44
3.2.6 (6) take measures to facilitate the sharing of information about potential
vulnerabilities in their product with digital elements as well as in third party
components contained in that product, including by providing a contact
address for the reporting of the vulnerabilities discovered in the product
with digital elements;
— The company distributing a product/service should have a contact point specifically advertised
to collect information related to vulnerabilities found in their products/services. If the company
has one, this contact point should be the company’s PSIRT
— The company distributing a product/service should inform any relevant authority (e.g. national
CERT/CSIRT) about how they can be reached in a timely manner for reasons related to the
handling of vulnerabilities
Keywords: PSIRT, discovered vulnerabilities

ID
EN Information This standard provides This standard Design

ISO/IEC technology — guidelines for provides guidelines
29147: Security vulnerability disclosure, for vulnerability
2020 techniques — including disclosure but does
Vulnerability recommendations on not specifically
disclosure how organizations can address the sharing
establish and maintain of information
communication channels about potential
for reporting vulnerabilities in
vulnerabilities. It covers third-party
the roles and components.
responsibilities of
organizations and the
process for
communicating
vulnerability
information.
EN Information This standard focuses on Focused on Design

ISO/IEC technology — the process of vulnerability
30111: Security vulnerability handling in handling in software
2020 techniques — software products, which products, it does not
Vulnerability can be extended to comprehensively
handling cover digital elements cover the aspects of
processes and third-party sharing information
components. It about potential
complements ISO/IEC vulnerabilities in
29147 by providing third-party
guidance on components and
investigating, resolving, other digital
elements.
45
and disclosing
vulnerabilities.
Overall The mentioned standards and initiatives contribute to various aspects of the
coverage requirement but do not comprehensively address sharing information about
and potential vulnerabilities in third-party components and other digital elements.
possible
gaps
these standards, initiatives, and collaborate with national CERTs/CSIRTs and ENISA.
It may be possible to also follow the CSIRTs Network forum and [11] latest ENISA
activities on that topic under the EU Cybersecurity Act umbrella.
The CSIRTs Network is composed of CSIRTs appointed by EU Member States and
CERT- EU ('CSIRTs Network members'). It is worth noting that ENISA actively
supports cooperation between CSIRTs, provides the secretariat and supports
incident coordination upon request.
Additionally, it may be possible to rely on policies and procedures that align with
industry best practices (e.g., NIST SP 800-61 Revision 2 [10], FIRST PSIRT Services
Framework [12]). By leveraging the strengths of each standard and initiative, it may
be possible to create a comprehensive and effective process for sharing information
about potential vulnerabilities and handling discovered vulnerabilities in their
products with digital elements and third-party component.
3.2.7 (7) provide for mechanisms to securely distribute updates for products with
digital elements to ensure that exploitable vulnerabilities are fixed or
mitigated in a timely manner;
— Security updates should be digitally signed using a Code Signing Certificate to ensure the
identity of the issuer
— Hashes of the updates should be made publicly available with instructions on how to verify
them
Keywords: code signing certificate, hashing, secure software update distribution, digital
signatures, official distribution channel, hash publication
Standard Standard title Rationale Gap Life-

ID Cycle
ISO/IEC Information This standard provides Although it provides Design

27002: security, guidelines for guidelines for secure
2022 cybersecurity and information security software distribution, it
privacy protection controls, including does not explicitly
— Information secure software address the
security controls distribution and update requirement of
management. It covers publishing hashes of
aspects such as updates and providing
securing development
environments,
46
cryptographic controls, instructions for
and securing verification.
distribution channels.
IEC 62443- Security for This standard focuses While IEC 62443-4-1 Design
4-1:2018 industrial on defining process addresses security
automation and requirements for the aspects throughout the
control systems - secure development of product development
Part 4-1: Secure products used in lifecycle, including
product industrial automation aspects related to
development and control systems. It secure software
lifecycle covers security updates and patch
requirements requirements management, there are
throughout the product potential gaps when it
development lifecycle, comes to covering the
including design, analysed requirement
implementation, of securely distributing
testing, and updates for products
maintenance. While the with digital elements.
standard is primarily
Industry specificity: IEC
targeted at the
62443-4-1 is tailored to
development of secure
Industrial Automation
products, it also
and Control Systems
addresses aspects
(IACS). Although the
related to secure
standard's principles
software updates and
can be applied to other
patch management,
industries, it does not
which are important for
fully cover the unique
securely distributing
needs and challenges of
updates.
other sectors.
Explicit mention of
hashes and verification:
The standard does not
explicitly address the
publication of update
hashes and the
provision of
instructions for
verifying them.
Organizations may
need to develop
additional guidelines or
policies to ensure that
hashes are published
and that users receive
clear instructions for
verifying the
authenticity and
47
integrity of software
updates.
Code signing certificate:
While the standard
covers secure software
development practices,
it does not explicitly
mention the
requirement of using
code signing certificates
to sign security
updates, which ensures
the identity of the issuer
and the integrity of the
update.
Overall The mentioned standards contribute to various aspects of the requirement but
coverage does not comprehensively address the publication of update hashes and the
and provision of instructions for their verification.
possible
gaps
these standards, tailored to the specific needs and industry best practices (e.g.,
NIST SP 800-53 [13], NIST SP 800-63B [14], OWASP SSDLC [15]). It may be possible
to take a closer look into the Patch Management mechanism suggest in the EUCC
[16]. The latter provides a framework for securely distributing updates for products
with digital elements, ensuring that exploitable vulnerabilities are fixed or mitigated
in a timely manner. By leveraging the strengths of each standard and considering
input from various sources, it may be possible to create a comprehensive and
effective process for securely distributing updates and mitigating exploitable
vulnerabilities in a timely manner.
3.2.8 (8) ensure that, where security patches or updates are available to address
identified security issues, they are disseminated without delay and free of
charge, accompanied by advisory messages providing users with the relevant
information, including on potential action to be taken.
— Users should be made aware of the existence of security updates either via automatic
distribution, popup, newsletter, etc.
— This notice should contain information about the fixed issues and instructions on how to apply
the update
— Security updates should be released free of charge
Keywords: Security update notice
48
ID
EN Information This standard provides While the standard Surveillance

ISO/IEC technology — guidelines for the covers
Maintenance
30111: Security design and vulnerability
2020 techniques — implementation of handling
Vulnerability vulnerability handling processes, it does
handling processes processes, including not explicitly
the discovery, address the
reporting, and requirement of
remediation of providing security
vulnerabilities. It can updates free of
help organizations charge or specific
develop processes to methods for
ensure timely notifying users.
dissemination of
security patches,
updates, and
advisories
ISO/IEC Information This standard provides This standard Surveillance

27002: security, best practice provides best
Maintenance
2022 cybersecurity and recommendations on practice
privacy protection information security recommendations
— Information management for but does not
security controls organizations. Section provide explicit
12.6, "Technical guidance on
Vulnerability providing updates
Management," covers free of charge or
aspects related to specific
vulnerability notification
management, methods for users.
including the timely
application of security
patches and updates.
EN IEC Security for This standard is related This standard is Surveillance

62443-4-1 industrial to IACS. Requirements for IACS only.
Maintenance
2018 automation and DM-5: “Disclosing Moreover, it does
control systems – security-related issues” not make explicit
and SUM-5 “Timely that the security
Part 4-1: Secure
delivery of security update should be
product
patches” cover the free of charge
development
requirement with the
lifecycle
notable exception of
requirements
the gratuitousness if
the security update
49
Overall The existing standards and guidelines generally provide guidance on vulnerability
coverage management, patch management, and the dissemination of security updates.
and However, they do not explicitly address certain aspects of the requirement, such
possible as providing updates free of charge or specifying methods for user notification.
gaps
To cover the overall gap, it could be possible to define policies that mandate
providing updates free of charge and establishing specific methods for notifying
users about available security updates.
50
4 Summary of the identified standards and overall remarks
Here the overall list of identified standards is summarised with the respective mapping, grouping
them according to the two groups of CRA essential requirements.
Security requirements relating to the

properties of products with digital
elements
Standard 1 2 3 3 3 3 3 3 3 3 3 3 3
a b c d e f g h i j k
EN ISO/IEC 27002:2022 x x x x x x
EN ISO/IEC 27005:2022 x
EN IEC 62443-3-2:2020 x x
EN IEC 62443-4-1:2018 x x
ISO/IEC 18045:2022 x x
ITU-T X.1214 (03/2018) x
ETSI EN 303 645 V2.1.1 (2020-06) x x x x x x x x x x x x x
ISO/IEC 18031:2011 x
ISO/IEC 9798, Parts 1 to 6 x
ISO/IEC 29146:2016 x
ITU-T X.1253 (09/2011) x
ITU-T X.812 (11/1995) x
EN IEC 62443-4-2:2019 x x x x x x x
ITU-T X.805 (10/2003) x x
ITU-T X.814 (11/1995) x
ISO/IEC 9796, Parts 2 and 3 x
51
ITU-T X.815 (11/1995) x
ISO/IEC 27701:2019 x
ISO/IEC 29100:2011 x
ETSI TS 103 485 V1.1.1 (2020-08) x
ISO/IEC 22237-1:2021 x
ITU-T Y.4810 (11/2021) x
ISO/IEC TS 19249:2017 x
ISO/IEC 15408-2:2022 x
ISO/IEC 27001:2022 x
ISO/IEC 27034-1:2011 x
EN ISO/IEC 15408-3:2022 x
ISO/IEC 13888-1:2020 x
ISO/IEC 30111:2019 x
IEC 62443-2-1:2010 x
Table 22: Overall list of the identified standards with their respective mapping towards the security
requirements
Vulnerability handling
requirements
Standard 1 2 3 4 5 6 7 8
ISO/IEC 27001:2022 x x
ISO/IEC 27002:2022 x x x x
EN ISO/IEC 30111:2020 x x x x x
EN ISO/IEC 29147:2020 x x x x
IEC 62443-4-1:2018 x x x x
ISO/IEC TS 27034-5-1:2018 x
52
ISO/IEC 27005:2022 x
ETSI EN 303 645 V2.1.1 (2020-06) x x
Table 23: Overall list of the identified standards with their respective mapping towards the vulnerability
handling requirements
Some overall remarks stem from the detailed analysis of the previous section and from the two
above summary tables, and are summarized here below:
— Overall, the existing standards cover at least partially all CRA requirements. This provides a
strong basis to build on taking into consideration the identified gaps. Nevertheless, we did not
find a single standard that can, alone, satisfy all requirements listed in the two lists present in
Annex I of the CRA;
— In general, “horizontal” standards - i.e., not targeting a specific use case or a market sector -
emerged as the most relevant to cover the purposes of the different requirements. The only
exception to this is represented by some standards of the EN IEC 62443 family (related to
industrial control systems) and the Internet of Things (IoT), although in our opinion standards
targeting the IoT domain can be seen mostly as horizontal standards, since nowadays most
digital devices can be associated to the IoT scenario;
— Although some of the selected standards are not directly related to product
design/development (e.g., EN ISO/IEC 27002 related to recommended controls for initiating,
implementing or maintaining information security management systems), they might
nevertheless be relevant for the CRA, as their implementation by an organisation will be
reflected also in the products produced by that organisation;
— Regarding the product-related security requirements of the first list of CRA Annex I, the
standard ETSI EN 303 645 has been indicated to us as one of the most relevant, and for this
reason we have made a specific attempt to map it on all the requirements, which result
somehow all covered by the standard even if with some gaps. To be also noted that the
standard is specifically devoted to IoT systems, so, even if many digital products nowadays
present different features analogous to those of the IoT environment, an automatic
applicability of this standard to all categories of products cannot to be taken for granted (see
also the comment below about the requirement 3g). Another relevant standard in terms of
coverage of the requirements is EN ISO/IEC 27002 (information security controls), covering 6
out of 13 requirements. Also the EN IEC 62443 family offers a quite good coverage, but it is
specifically devoted to industrial control systems.
— For the vulnerability handling requirements, the second list of the annex, EN ISO/IEC 30111
(vulnerability handling process) is the most relevant one, covering 5 out of 8 requirements, with
also EN ISO/IEC 29147 (vulnerability disclosure) covering 4 of the same requirements. All these
standards are “horizontal” in terms of their application;
— In some cases, such as requirement 3(b) (ensure protection from unauthorised access by
appropriate control mechanisms, including but not limited to authentication, identity or access
management systems), the selected standards are quite generic whereas there exist several
other standards covering specific use cases in more detail. The selection of more generic
standards allows more flexibility and wider coverage of current and future use cases. On the
other hand, specific and sectoral standards might be able to satisfy more closely the peculiar
constraints and requirements of specific niches;
53
— In other cases, e.g., 3(f) (protect the availability of essential functions, including the resilience
against and mitigation of denial of service attacks), the focus of the identified documents is more
on infrastructural elements rather than user products or services. Even though these
infrastructures are the core for provisioning of services and for some device functionalities,
more specific standard provisions would be needed. Those are present for IoT devices, but still
at a high level;
— While requirement 3(g), which focuses on minimizing negative impacts on the availability of
services provided by other devices or networks, is specifically addressed by standards related to
the IoT domain, it raises questions about the broader applicability of these standards. In the
context of the highly interconnected nature of devices in the IoT domain, these standards have
clear relevance. However, for other domains, the specific applicability of IoT-focused
cybersecurity standards may need further evaluation. While interconnectedness is also a
characteristic of several domains nowadays, the specific requirements, regulations, and risks
might vary, necessitating a tailored approach or additional measures to ensure that
cybersecurity needs are adequately addressed.
54
5 Conclusion
Products with digital elements are evermore present in our lives. The increasing number of
cyberattacks affecting them triggers negative impacts on many different aspects of our society. As
a response the European Commission has proposed the Cyber Resilience Act, a new legislative
framework prescribing a set of cybersecurity requirements that manufacturers have to implement
in their products with digital elements.
The defined requirements should be translated into harmonised European standards which would
become the reference cybersecurity specifications to be followed by manufacturers. In view of this
standardisation activity, this report identifies the most relevant already existing cybersecurity
standards mapping them to the different requirements, describing both the level of offered
coverage and the gaps to be possibly considered in further standardisation efforts.
According to our analysis for each of the defined requirements there is already at least one
document that can be considered as an initial reference offering some coverage. However, to the
best of our knowledge, there is not a single standard capable of covering all the requirements
expressed in the proposed legislative act, even if some of the standards do partially cover all of the
requirements. The analysis offers re-assurance that a good international cybersecurity
standardisation base is already in place for serving the scope of the Cyber Resilience Act
requirements, but harmonisation is needed to ensure a homogeneous horizontal coverage, and
some gaps, as highlighted in this report, need still to be addressed.
55
References
[1] 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, COM/2022/454. https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX%3A52022PC0454
[2] SPDX: A Linux Foundation standard for sharing software components, licenses, copyrights,
and security data, providing a consistent SBOM format - SPDX Specification 2.2.
https://spdx.github.io/spdx-spec/
[3] NTIA's Software Component Transparency Initiative - a U.S. initiative working on standardizing
SBOM formats and best practices for software component transparency.
https://www.ntia.gov/SBOM
[4] CycloneDX: An SBOM specification designed for application security and supply chain
component analysis, offering a lightweight format for describing software components and
metadata - CycloneDX Specification. https://cyclonedx.org/capabilities
[5] ECSO Supply Chain management and Product Certification Composition. https://ecs-
org.eu/activities/standardisation-certification-and-supply-chain-management/
[6] IIoTSBOM is an initiative from LSEC, Flanders Make and KU Leuven COSIC from Belgium to
improve cybersecurity for devices. Inspired and with the support of the US CISA
(CyberSecurity and Infrastructure Security Agency). https://www.iiotsbom.com/
[7] The Common Vulnerabilities and Exposures (CVE) system provides a reference-method for
publicly known information-security vulnerabilities and exposures. https://cve.mitre.org/
[8] The National Vulnerability Database (NVD) is the U.S. government repository of standards-
based vulnerability management data, enabling automation of vulnerability management,
security measurement, and compliance. https://www.nist.gov/itl/products-and-
services/national-vulnerability-database-nvd
[9] The Vulnerability Reporting and Data eXchange Special Interest Group (VRDX SIG) of the
Forum of Incident Response and Security Teams (FIRST) focuses on improving vulnerability
management processes and standards. https://www.first.org/global/sigs/vrdx
[10]NIST SP 800-61 Revision 2 - Computer Security Incident Handling Guide.
https://www.researchgate.net/publication/320851514_NIST_Special_Publication_800-
61_Revision_2_Computer_Security_Incident_Handling_Guide
[11]The CSIRT (Computer Security Incident Response Team) Network is a collaborative platform
where members can cooperate, exchange information, and build trust. The network's
members, composed of CSIRTs appointed by EU Member States and CERT-EU ('CSIRTs
Network members'), work together to improve the handling of cross-border incidents and
discuss how to respond in a coordinated manner to specific incidents.
https://www.enisa.europa.eu/topics/incident-response/csirts-in-europe/csirts-network
[12]The PSIRT (Product Security Incident Response Team) Services Framework is a document
developed by the FIRST (Forum of Incident Response and Security Teams) community,
detailing potential services that CSIRTs (Computer Security Incident Response Teams) and
PSIRTs may provide. https://www.first.org/resources/guides/first-psirt-services-framework-
v1.0.pdf
[13]NIST SP 800-53: This standard provides a catalog of security and privacy controls for all U.S.
federal information systems except those related to national security. It aims to protect
individuals' privacy and organizational operations from a diverse set of threats.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf
[14]NIST SP 800-63B: This is a guideline for digital identity services. It offers technical
requirements for each of three levels of assurance in the areas of identity proofing,
56
authentication, and federation.
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
[15]OWASP SSDLC: The Open Web Application Security Project (OWASP) Secure Software
Development Life Cycle Project is a guide to security in the software development life cycle. It
provides a core framework for integrating security concepts and best practices into a software
development process. https://owasp.org/www-project-secure-software-development-
lifecycle/
[16]The patch management approach outlined in the EU Common Criteria is for certified ICT
products and aims to ensure the security of the products through proper vulnerability
handling and patch deployment. The process allows for different patch levels based on the
severity and urgency of vulnerabilities, and it involves the collaboration of various
stakeholders in the certification process. Annex 15:
https://www.enisa.europa.eu/publications/cybersecurity-certification-eucc-candidate-
scheme-v1-1.1
57
List of abbreviations and definitions
API Application Programming Interface
CERT Computer Emergency Response Team
CD Continuous Deployment – A Software engineering approach that involves

regularly delivering software features using automated deployment processes.
CI Continuous Integration – A Software engineering approach that consists in

automatically integrating code changes from various contributors into a unified
software repository, where automated tests and builds are performed.
CISA Cybersecurity and Infrastructure Security Agency - A U.S. government agency

responsible for cybersecurity and critical infrastructure protection
CRA Cyber Resilience Act
CSIRT Computer Security Incident Response Team
CVD Coordinated Vulnerability Disclosure - A process of reporting and addressing

vulnerabilities in a collaborative manner
DoS Denial of Service
DDoS Distributed Denial of Service
ECSO European Cyber Security Organisation - An organization that aims to develop a

cybersecurity ecosystem in Europe
ENISA European Union Agency for Cybersecurity
ESO European Standardisation Organization
FIRST Forum of Incident Response and Security Teams - A global organization

focused on incident response and security coordination
GDPR General Data Protection Regulation
IACS Industrial Automation and Control Systems
IIoTSBOM Industrial Internet of Things Software Bill of Materials - An initiative to improve

cybersecurity for devices
IoT Internet of Things
ISMS Information Security Management System
JRC Joint Research Centre
58
LSEC Leaders in Security - A European information security cluster
NIST National Institute of Standards and Technology - A U.S. government agency

that develops standards and guidelines
NTIA National Telecommunications and Information Administration - A U.S.

government agency
PII Personal Identifiable Information
PKI Public Key Infrastructure
PSIRT Product Security Incident Response Team - A team responsible for handling
security incidents and vulnerabilities in products
ROM Read Only Memory
SaaS Software as a Service
SBOM Software Bill of Materials - A document that lists the components used in a
software product
SDO Standards Developing Organisation
SP Special Publication - A series of publications by NIST covering various

technology and security topics
SPDX Software Package Data Exchange - A Linux Foundation standard for sharing
software component information
VRDX SIG Vulnerability Reporting and Data eXchange Special Interest Group - A group
within FIRST focused on vulnerability reporting and data exchange
XML eXtensible Markup Language
59
List of figures
Figure 1 Overall requirements mapping and analysis process .............................................................. 3
Figure 2 Generic product life-cycle ............................................................................................................. 4
60
List of Tables
Table 1: Mapping of security requirement No. 1 ..............................................................................................................................7
Table 2: Mapping of security requirement No. 2 ..............................................................................................................................9
Table 3: Mapping of security requirement No. 3a ....................................................................................................................... 11
Table 4: Mapping of security requirement No. 3b ....................................................................................................................... 14
Table 5: Mapping of security requirement No. 3c ........................................................................................................................ 17
Table 6: Mapping of security requirement No. 3d ....................................................................................................................... 19
Table 7: Mapping of security requirement No. 3e ....................................................................................................................... 21
Table 8: Mapping of security requirement No. 3f......................................................................................................................... 24
Table 9: Mapping of security requirement No. 3g ....................................................................................................................... 26
Table 10: Mapping of security requirement No. 3h .................................................................................................................... 28
Table 11: Mapping of security requirement No. 3i ...................................................................................................................... 31
Table 12: Mapping of security requirement No. 3j ...................................................................................................................... 34
Table 13: Mapping of security requirement No. 3k .................................................................................................................... 35
Table 14: Mapping of vulnerability handling requirement No. 1.................................................................................... 37
Table 15: Mapping of vulnerability handling requirement No. 2 .................................................................................... 39
Table 22: Overall list of the identified standards with their respective mapping towards the
security requirements ........................................................................................................................................................................................... 52
Table 23: Overall list of the identified standards with their respective mapping towards the
vulnerability handling requirements ........................................................................................................................................................ 53
61
Annexes
Annex 1. High level pre-screening of standardisation activities with potential relevance for
the CRA requirements
As preparatory activity of the present study, with the aim to offer a robust mapping of the CRA
requirements against the relevant cybersecurity standardisation activities offered by European
and international standardisation body, several outputs produced by their committees have been
surveyed. This pre-analysis has represented the ground on which to build the detailed mapping of
standards against the CRA requirements.
In the screening activity already published standards have been obviously considered, but ongoing
standardisation efforts, technical specifications, technical reports and guidelines have been also
taken into consideration. The analysis of each of them has been based solely on freely available
information, like overviews, summaries, abstracts, tables of content and where possible the full
text. For each identified document a tentative coarse mapping against the CRA requirements has
been sketched, so as to measure the potential relevance of each of them in the actual mapping.
In the table below we summarise the number of committees and documents we went through for
the pre-screening of the present study, so as to give an insight about the amplitude of the analysis.
Committees/Working Surveyed
groups Standards/Documents
International SDOs (ISO, IEC, ITU) 37 ~ 950
European SDOs (CEN, CENELEC, 25 ~ 270

ETSI)
Table 1 Number of committees/working groups and standards/documents considered in the analysis.
62
GETTING IN TOUCH WITH THE EU
In person
All over the European Union there are hundreds of Europe Direct centres. You can find the address of the centre nearest you online
(european-union.europa.eu/contact-eu/meet-us_en).
On the phone or in writing
Europe Direct is a service that answers your questions about the European Union. You can contact this service:
by freephone: 00 800 6 7 8 9 10 11 (certain operators may charge for these calls),
at the following standard number: +32 22999696,
via the following form: european-union.europa.eu/contact-eu/write-us_en.
FINDING INFORMATION ABOUT THE EU

Online
Information about the European Union in all the official languages of the EU is available on the Europa website (european-
union.europa.eu).
EU publications
You can view or order EU publications at op.europa.eu/en/publications. Multiple copies of free publications can be obtained by
contacting Europe Direct or your local documentation centre (european-union.europa.eu/contact-eu/meet-us_en).
EU law and related documents
For access to legal information from the EU, including all EU law since 1951 in all the official language versions, go to EUR-Lex (eur-
lex.europa.eu).
Open data from the EU
The portal data.europa.eu provides access to open datasets from the EU institutions, bodies and agencies. These can be downloaded
and reused for free, for both commercial and non-commercial purposes. The portal also provides access to a wealth of datasets
from European countries.
The portal data.europa.eu provides access to open datasets from the EU institutions, bodies and agencies. These can be downloaded
and reused for free, for both commercial and non-commercial purposes. The portal also provides access to a wealth of datasets
from European countries.

Cyber Resilience Act Requirements Standards Mapping-KJNA31892ENN

Uploaded by

Copyright:

Available Formats

Cyber Resilience Act Requirements Standards Mapping-KJNA31892ENN

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cyber Resilience Act Requirements Standards Mapping-KJNA31892ENN

Uploaded by

Copyright:

Available Formats

ISSN 1831-9424

Cyber Resilience Act Requirements

Joint Research Centre & ENISA Joint Analysis

© European Union, 2024

For contacting the authors, please use https://ec.europa.eu/jrc/en/contact/form or [email protected]

4 Summary of the identified standards and overall remarks ............................ 51

Figure 1 Overall requirements mapping and analysis process

Figure 2 Generic product life-cycle

3.1 Security requirements relating to the properties of products with digital

Standard Standard title Rationale Gap Life-Cycle

EN Information ISO 27002 includes While there are Implementation

EN IEC Security for Although specific only This standard Design

EN IEC Security for Although specific only This standard Design

ETSI EN CYBER; Cyber Promotes secure Detailed guidelines Design

Table 1: Mapping of security requirement No. 1

Standard Standard Rationale Gap Life-Cycle

ISO/IEC Information Describes the minimum Covers only Validation

ITU-T Security Covers vulnerability Covers Validation

EN IEC Security for Although specific only to This standard Validation

ETSI EN CYBER; Cyber Provision 5.2-3 of the The standard Validation

Table 2: Mapping of security requirement No. 2

(a) be delivered with a secure by default configuration, including the

EN Information This standard It mainly Implementation

ETSI EN CYBER; Cyber This standard defines The provisions Design

ISO/IEC Information This standard defines The standard is Design

Table 3: Mapping of security requirement No. 3a

3.1.4 (3b) ensure protection from unauthorised access by appropriate control

ISO/IEC Information technology The General part Covers only Design

ISO/IEC IT Security and Privacy This series of Covers only Design

ISO/IEC Information technology This standard Covers access Design

ITU-T Security guidelines for This standard It is of generic Design

ITU-T Information technology Provides a It is generic and Design

ETSI EN CYBER; Cyber Security Provisions 5.1, The standard Design

EN IEC Security for industial This standard, This standard Design

Table 4: Mapping of security requirement No. 3b

Standard Standard Rationale Gap Life-Cycle

ITU-T Security This standard Does not cover Design

ISO/IEC Information This series of These standards Design

ITU-T Information This standard It is very generic, Design

ETSI EN CYBER; Cyber Provisions 5.5.1, The standard Design

EN IEC Security for This standard, This standard Design

Table 5: Mapping of security requirement No. 3c

3.1.6 (3d) protect the integrity of stored, transmitted or otherwise processed

Standard ID Standard Rationale Gap Life-Cycle

ISO/IEC 9796 Information Covers digital Does not cover Design

ISO/IEC 9797 Information These standards Does not cover Design

ISO/IEC Information Covers digital Does not cover Design

ITU-T X.815 Information This standard It is of generic Design

ETSI EN 303 CYBER; Cyber The standard While the Design

EN IEC Security for This standard, This standard Design

Table 6: Mapping of security requirement No. 3d

Standard Standard title Rationale Gap Life-Cycle

ISO/IEC Security This standard is an This standard, Design

ISO/IEC Information This standard No specific Design

ETSI EN CYBER; Cyber The standard While the standard Design

Table 7: Mapping of security requirement No. 3e

Standard Standard title Rationale Gap Life-Cycle

EN Information This standard provides a The guidance Implementation

ISO/IEC Information This standard describes The focus is Design

ITU-T Security This standard defines a Specific for Design