prEN 40000-1-2

SLOVENSKI STANDARD
01-december-2025
Zahteve za kibernetsko varnost za izdelke z digitalnimi elementi - 1-2 del: Načela
kibernetske odpornosti
Cybersecurity requirements for products with digital elements - Part 1-2: Principles for
cyber resilience
Cybersicherheitsanforderungen für Produkte mit digitalen Elementen - Grundsätze für
die Cyberresilienz
Ta slovenski standard je istoveten z: prEN 40000-1-2
ICS:
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2025
ICS 35.030
English version
Cybersecurity requirements for products with digital
elements - Part 1-2: Principles for cyber resilience
Anforderungen an die Cybersicherheit von Produkten
mit digitalen Bestandteilen - Grundsätze für die
Cyberesilienz
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/CLC/JTC 13.
If this draft becomes a European Standard, CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal
Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any
alteration.
This draft European Standard was established by CEN and CENELEC in three official versions (English, French, German). A
version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language
and notified to the CEN-CENELEC Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.Recipients of this draft are invited to submit, with their comments, notification
of any relevant patent rights of which they are aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

Contents Page
European foreword . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Introduction . 6
5 Cybersecurity principles . 7
5.1 General . 7
5.2 Risk-based approach to cybersecurity . 7
5.2.1 Principle . 7
5.2.2 Guidance . 7
5.3 Security by design . 8
5.3.1 Principle . 8
5.3.2 Guidance . 8
5.4 Secure by default . 9
5.4.1 Principle . 9
5.4.2 Guidance . 9
5.5 Transparency . 9
5.5.1 Principle . 9
5.5.2 Guidance . 9
6 Risk management elements . 10
6.1 General . 10
6.2 Product context . 12
6.2.1 General . 12
6.2.2 Input . 13
6.2.3 Requirement . 14
6.2.4 Output . 14
6.2.5 Assessment criteria . 14
6.3 Risk acceptance criteria and risk management methodology . 14
6.3.1 General . 14
6.3.2 Input . 16
6.3.3 Requirement . 16
6.3.4 Output . 16
6.3.5 Assessment criteria . 16
6.4 Risk assessment . 17
6.4.1 General . 17
6.4.2 Asset and cybersecurity objective identification . 17
6.4.3 Threat identification . 18
6.4.4 Risk estimation . 19
6.4.5 Risk evaluation . 20
6.5 Risk treatment . 21
6.5.1 General . 21
6.5.2 Input . 22
6.5.3 Requirement . 22
6.5.4 Output . 22
6.5.5 Assessment criteria . 22
6.6 Risk communication . 23
6.6.1 General . 23
6.6.2 Input . 23
6.6.3 Requirement . 23
6.6.4 Output . 24
6.6.5 Assessment criteria . 24
6.7 Risk monitoring and review . 24
6.7.1 General . 24
6.7.2 Input . 24
6.7.3 Requirement . 24
6.7.4 Output . 25
6.7.5 Assessment criteria . 25
7 Cybersecurity activities . 25
7.1 General . 25
7.2 Product cybersecurity planning . 26
7.2.1 General . 26
7.2.2 Input . 26
7.2.3 Requirement . 26
7.2.4 Output . 26
7.2.5 Assessment criteria . 26
7.3 Product cybersecurity requirements . 26
7.3.1 General . 26
7.3.2 Input . 27
7.3.3 Requirement . 27
7.3.4 Output . 28
7.3.5 Assessment criteria . 28
7.4 Cybersecurity architecture and design . 28
7.4.1 General . 28
7.4.2 Input . 28
7.4.3 Requirement . 28
7.4.4 Output . 29
7.4.5 Assessment criteria . 29
7.5 Secure implementation . 29
7.5.1 General . 29
7.5.2 Input . 30
7.5.3 Requirement . 30
7.5.4 Output . 30
7.5.5 Assessment criteria . 30
7.6 Cybersecurity verification and validation . 31
7.6.1 General . 31
7.6.2 Input . 32
7.6.3 Requirement . 32
7.6.4 Output . 33
7.6.5 Assessment criteria . 33
7.7 Secure production and distribution . 33
7.7.1 General . 33
7.7.2 Digital production . 34
7.7.3 Manufacturing . 35
7.8 Cybersecurity issue management . 36
7.8.1 General . 36
7.8.2 Input . 36
7.8.3 Requirement . 36
7.8.4 Output . 37
7.8.5 Assessment criteria . 37
7.9 Product monitoring . 37
7.9.1 General . 37
7.9.2 Input . 37
7.9.3 Requirement . 37
7.9.4 Output . 38
7.9.5 Assessment criteria . 38
7.10 Planning for secure decommissioning . 38
7.10.1 General . 38
7.10.2 Input . 38
7.10.3 Requirement . 38
7.10.4 Output . 39
7.10.5 Assessment criteria . 39
7.11 Third-party component cybersecurity management . 39
7.11.1 General . 39
7.11.2 Input . 40
7.11.3 Requirement . 40
7.11.4 Output . 41
7.11.5 Assessment criteria . 41
Annex A (informative) Coherence with vertical standards . 42
A.1 Coherence elements . 42
Annex B (informative) Example of a Cybersecurity Supplier Agreement (CSSA) . 43
B.1 General . 43
B.2 CSSA example . 44
Annex C (informative) Relationship between this European Standard and the essential
cybersecurity requirements of Regulation (EU) 2024/2847 . 48
C.1 General . 48
C.2 Reference to essential requirements . 48
C.3 Mapping to essential requirements . 48
C.4 Normative or informative . 51
C.5 Assessment criteria . 52
Annex D (informative) Accessible and inclusive cybersecurity . 53
D.1 Scope . 53
D.2 Legal reasoning . 53
D.3 The user . 53
D.4 Nature of the required interaction . 54
D.5 Consequences of the interaction method on the user’s cybersecurity . 54
D.6 Recommended solution to ensure maximum cybersecurity to the potential users . 54
D.7 Communication with the user . 55
Bibliography . 56
European foreword
This document (prEN 40000-1-2:2025) has been prepared by Technical Committee CEN/CLC/JTC 13
"Cybersecurity and Data Protection", the secretariat of which is held by DIN.
This document is currently submitted to the CEN Enquiry.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
1 Scope
This document specifies general cybersecurity principles and general risk management activities for
all products with digital elements, hereafter also referred to as 'products'. This document covers every
stage of the product lifecycle to ensure and maintain an appropriate level of cybersecurity based on the
risks.
This document also provides generic elements to support the development of coherent product-
cätegory-specific standards (vertical standards).
This document:
— establishes generic cybersecurity principles applicable to all stages of the product lifecycle;
— specifies requirements for risk assessment and treatment of cybersecurity risks;
— specifies requirements on activities that can be applied to ensure an appropriate level of
cybersecurity at every phase of the product lifecycle;
— provides elements and considerations for product category specific standards in order to facilitate
a harmonized approach.
This document does not provide vertical product category specific activities and elements.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
prEN 40000-1-1, Cybersecurity requirements for products with digital elements — Vocabulary
JT013090:2026, Cybersecurity requirements for products with digital elements – Vulnerability Handling
3 Terms and definitions
For the purposes of this document, the terms and definitions given in Regulation (EU) 2024/2847,
prEN 40000-1-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at http://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
4 Introduction
The purpose of this document is to provide generic principles for cybersecurity and to specify activities
for manufacturers covering all stages of the product lifecycle in order to ensure and maintain an
appropriate level of cybersecurity based on the risks. It also supports the development of vertical
standards, ensuring consistency and appropriateness.
This document is part of a set of standards that have the following structure:
— Horizontal standards for cybersecurity requirements relating to the properties of products with
digital elements, including:
— A standard for generic cybersecurity activities, providing basic concepts, definitions,
principles for design and general aspects applicable to the product;
— A standard specifying generic cybersecurity requirements, presented as a catalogue of
controls that may be applied to the product;
— A standard for vulnerability handling requirements for the product; and,
— A standard containing the common vocabulary used.
— Vertical standards for cybersecurity requirements relating to the properties of products with
digital elements covering product category specific requirements and requirements on
vulnerability handling.
Clause 5 lays out the generic principles for product cybersecurity that, when applied, will lead to an
appropriate level of product cybersecurity over all stages of the product lifecycle.
Clause 6 provides a generic framework for managing product cybersecurity risks and lays out the
requirements for appropriate cybersecurity risk management elements. It prescribes relevant elements
of appropriate risk management approaches, which can be used throughout the product lifecycle and
repeated when necessary.
Clause 7 details requirements for generic activities during the product lifecycle, including activities
related to management of cybersecurity risks. These activities are process-agnostic and can be applied
across different development methodologies. They can be performed concurrently or in varying order,
depending on the development approach.
Annex A details instructions for vertical standards that desire coherence with the framework
established by this document.
Annex B gives an example of a Cybersecurity Supplier Agreement (CSSA) between the manufacturer
and third-party providers (suppliers) of components or services.
Annex C specifies the relationship between this document and the essential requirements of CRA Annex
I Part I (1) and (2) [1]. It also identifies the normative and informative parts of the standard.
Annex D contains information to support manufacturers in developing products that are both secure
and accessible to the users.
5 Cybersecurity principles
5.1 General
This clause provides an informative overview on cybersecurity principles. It established the foundation
for risk management elements and activities detailed in this document to ensure an appropriate level
of cybersecurity throughout all stages of the product lifecycle.
5.2 Risk-based approach to cybersecurity
5.2.1 Principle
A risk-based cybersecurity approach for products ensures that cybersecurity measures are based on
identified risks and are proportionate to the identified risks, considering magnitude of loss or disruption
and the likelihood of occurrence. This approach facilitates informed decision-making regarding risk
treatment, ultimately aiming to reduce product cybersecurity risks across the product lifecycle through
targeted and appropriate actions.
5.2.2 Guidance
A risk-based approach ensures that measures are based on identified risks, are proportionate to the
level of risk, and are fit for purpose considering the intended use and reasonably foreseeable use. Risk
is a combination of impact (magnitude of loss or disruption caused by an incident) and the likelihood
of occurrence of said incident. The risk based approach includes implementing cybersecurity controls
and other measures (e.g. constraints for the operational environment) that target either the impact or
likelihood, either reducing the likelihood of a potential incident, reducing the impact of a potential
incident, or both.
A risk-based approach includes:
— establishing the product context;
— risk assessment (risk identificätion; risk analysis, including threat modelling; and risk evaluation);
— risk treatment;
— risk monitoring and review;
— risk communication and consultation;
— risk recording.
Following the application of appropriate risk treatments, any residual risk needs to be determined to
be acceptable based on risk acceptance criteria established by the manufacturer, taking into account:
— generally acknowledged state of the art;
— applicable standards and;
— the product's intended and reasonably foreseeable use.
The established context and residual risks are to be clearly communicated if required. Communication
is to be traceable, accessible, and appropriate to the stakeholder's role.
5.3 Security by design
5.3.1 Principle
The principle of security by design for cybersecurity means that a product is designed, developed, and
produced in a way that integrates cybersecurity measures from the concept phase throughout the entire
product lifecycle. Security by design ensures that cybersecurity is treated as a fundamental aspect of
the design in all its parts, and it emphasizes that it should not be regarded as an element to be added later.
5.3.2 Guidance
The security by design principle aims to create more resilient products and systems that are better
equipped to withstand cyberattacks.
Key elements of the security by design principle include but are not limited to:
— Least privilege: Ensuring that entities have only the minimum access necessary to perform their
functions, where access can be defined in different ways, e.g. levels, roles, permissions, or
capabilities.
— Attack surface minimization: Ensuring that there are as few attack vectors and entry points as
possible by which an attacker can attack. For example, this can be achieved by reducing
unnecessary interfaces, or by using constant-length API parameters to reduce the likelihood of
buffer overflows.
— Defence in depth: Implementing multiple layers of cybersecurity controls to protect against a
range of threats at different layers. For example, implementing exploit mitigation techniques like
non-executable pages, stack canaries, address space layout randomization, pointer authentication,
and capability-based addressing.
— Secure coding practices: Systematically avoid or detect common causes for defects and
weaknesses. For example, by using a specific programming language or using tools detecting
programming issues and deviations from best practices. Memory-safe programming languages are
one type of programming language that avoids memory-safety related vulnerabilities.
— Do not rely on security by obscurity: Cybersecurity does not solely rely on the secrecy of design
details or implementation information, but instead relies on established cybersecurity measures.
— User-centric design: Considering products in the context of their use, and designing products that
keep users safe and secure even when user actions could lead to adverse outcomes.
— Lifecycle management: Implementing cybersecurity measures throughout the product lifecycle,
from initial design and development to deployment, operation, end of support, until the product
is permanently decommissioned and no longer used.
5.4 Secure by default
5.4.1 Principle
The principle of secure by default for cybersecurity means that the default behaviour of the product is
secure for its intended purpose, reasonably foreseeable use, and intended operational environment.
This involves ensuring that the product is securely configured upon installation or deployment and that
available cybersecurity updates are installed without undue delay to maintain a secure by default state.
5.4.2 Guidance
The goal of secure by default is to reduce the likelihood of vulnerabilities introduced through
deployment or misconfigurätion by the user. This is done by minimizing the attack surface of a product,
ensuring that secure configurätions are the default, and informing the users about the default secure
state. This may still include mechanisms to opt out, either by choice or through agreement between the
manufacturer and business owner in relation to a tailor-made product. The product may also contain
an option to postpone updates. In either case, proper information related to the risks needs to be
provided as well as a method to reset to the secure by default state of the product.
Secure by default also entails the deactivation of unnecessary interfaces, minimising the attack surface
as far as practicable considering the intended purpose and reasonably foreseeable use during setup and
configurätion.
The secure by design approach helps to protect users, especially those who do not have the technical
knowledge to implement cybersecurity measures on their own, and it aims to reduce the likelihood of
human error that can lead to cybersecurity threats. To protect users, it is important to ensure that secure
configurätions do not interfere with accessibility settings and vice versa.
5.5 Transparency
5.5.1 Principle
The principle of transparency refers to communicating and making available the necessary
cybersecurity information to relevant stakeholders to help achieve and maintain the cybersecurity of
the products.
5.5.2 Guidance
Transparency relates to sharing information, including adequate and appropriate communication
towards the relevant stakeholder in an accessible and useable format. Appropriate transparency is not
just about sharing information about the risks, but also considers the needs of relevant stakeholders,
including accessibility requirements. This addresses aspects such as risks related to incorrect or
incomplete interpretation of shared information.
Transparency includes amongst others, methods of relaying information related to:
— assets;
— threats;
— risks;
— system architecture and design; and,
— exploitable vulnerabilities and incidents.
This can occur at various stages of the supply chain. Effective and transparent communication is critical
for informing and involving stakeholders in risk treatment. Appropriate transparency is necessary for
informed decision-making related to ensuring and maintaining cybersecurity.
6 Risk management elements
6.1 General
The management of risks applies to all phases of the product lifecycle, including design, development,
production and maintenance to ensure an appropriate level of cybersecurity.
This clause describes generic elements to manage risks that can be applied systematically and at any
point in the product lifecycle of the product. Changes in circumstances throughout the product lifecycle
may trigger repetition of some elements of the risk management activities, as appropriate.
Management of risks includes the following:
— establishing the product context according to 6.2;
— establishing the risk acceptance criteria according to 6.3;
— performing an assessment of the risks according to 6.4;
— performing appropriate treatment of the risks according to 6.5;
— communicating the residual risks according to 6.6;
— reviewing management of the risks according to 6.7.
Figure 1 contains a visual display of the interplay between the risk management elements.
Figure 1 — Risk management elements overview
6.2 Product context
6.2.1 General
6.2.1.1 Context purpose
Establishing the product context determines the starting point for the assessment and treatment of
risks. This is an iterative task as changes to the product during development can cause the product
context to change.
6.2.1.2 Product intended purpose and reasonable foreseeable use
The intended purpose and reasonably foreseeable use (IPRFU) of the product is essential to establish
the scope and context for identifying risks.
NOTE 1 Additional information on IPRFU can be found in section 2.8 of the ‘Blue Guide’ on the implementation
of EU product rules 2022 (2022/C 247/01) [2].
NOTE 2 In IPRFU, health and safety of the user and accessibility of the product by the user is considered.
EXAMPLE A smart door lock.
Intended purpose: to controls physical access to residential and office premises via a smartphone application and
digital key management.
Reasonably foreseeable use:
— Users can share access credentials informally;
— Tenants can connect the lock to third-party home automation systems;
— The lock can be used in a different environment, exposing it to harsher environmental factors than was
intended.
6.2.1.3 Product functions
The product’s functions are those specified by the manufacturer and provided when the product is used
according to its IPRFU.
NOTE The Remote Data Processing Solutions (RDPS) interfaces and dependencies are part of the product
functions.
EXAMPLE 1 The functions of a product that are remotely executed or are needed to access the remote features
of the product.
EXAMPLE 2 The functions of an internet gateway include forwarding network träffic from private networks to
the internet and vice versa.
EXAMPLE 3 The functions of a network camera include recording optical signals and making those recordings
available via a network.
EXAMPLE 4 Functions that are provided by the product when it is used according to its IPRFU can include
features which ensure the defined security objectives, e.g. certain cybersecurity functions that protect the product,
and the health and safety of the user.
EXAMPLE 5 The ability to configure a product is also a function in the product's IPRFU.
6.2.1.4 Product operational environment
The product’s operational environment refers to the external conditions under which it is used within
its IPRFU.
NOTE 1 For any RDPS, the operational environment typically contains information on connectivity, expected
availability, data handled, and any constraints (including third-party platforms).
NOTE 2 The product’s operational environment significäntly influences the likelihood and potential impact of
cybersecurity incidents caused by related vulnerabilities. It can also include existing measures that mitigate certain
risks. As such, the product’s operational environment plays an important role in the identificätion, assessment,
and appropriate treatment of risks throughout the product lifecycle.
NOTE 3 A description of a product’s operational environment can amongst others include:
— the networks where the product is intended and reasonably foreseen to be used, including the networks’
cybersecurity relevant properties;
— the system into which the product is intended, or can reasonably be foreseen, to be integrated, together with
other hardware and software components, including the relevant cybersecurity-relevant properties of this
system;
— the physical surrounding of the product, where it is intended and reasonably foreseen to be operated in,
including its cybersecurity relevant properties.
NOTE 4 Understanding the environment of an RDPS is essential, including where it operates, its network
connections, who its users are, expected uptime, the data it manages, and any limitations.
6.2.1.5 Product architecture overview
The product architecture overview includes at least the key components of the product as well as the
product interfaces and dependencies. It is a high-level overview of the components of a product and its
RDPS.
NOTE 1 Where the product contains RDPS the product architecture overview describes this relation on where
RDPS plays a role in delivering any stated product function. This overview also describes whether the RDPS is
developed by the manufacturer or provided under the manufacturer’s responsibility, and who operates it;
NOTE 2 A system can contain several components/elements. The physical components/elements of the system
can be placed in different locations, interfacing with a local network and have an RDPS component.
6.2.1.6 Product user description
The product's end user, also referred to in this document as user, is any natural or legal person intended
to install/operate/handle/use. This can include the use of a product as a component in another product.
The description outlines the user’s reasonably foreseeable level of experience, knowledge and ability
to securely install/operate/maintain/decommission the product.
This includes considering if the product is to be used by vulnerable groups of users, for example those
with (temporary or long term) disabilities and/or impairments. Annex D contains more information on
accessible cybersecurity.
NOTE 1 The product user des
...