oSIST prEN 40000-1-3:2026

SLOVENSKI STANDARD
01-februar-2026
Zahteve za kibernetsko varnost za izdelke z digitalnimi elementi - 1-3 del:
Obravnavanje ranljivosti
Cybersecurity requirements for products with digital elements - Part 1-3: Vulnerability
Handling
Cybersicherheitsanforderungen für Produkte mit digitalen Bestandteilen - Umgang mit
Schwachstellen
Ta slovenski standard je istoveten z: prEN 40000-1-3
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
December 2025
ICS 35.030
English version
Cybersecurity requirements for products with digital
elements - Part 1-3: Vulnerability Handling
Cybersicherheitsanforderungen für Produkte mit
digitalen Bestandteilen - Umgang mit Schwachstellen
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.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2025 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. prEN 40000-1-3:2025 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 General . 8
4.1 Structure of this document . 8
4.2 Relationships with other international standards . 8
5 Vulnerability handling . 9
5.1 General . 9
5.2 [APP] Applicability . 9
5.2.1 General . 10
5.2.2 [APP-1] Requirement enhancement applicability . 10
5.3 [PRE] Preparation . 10
5.3.1 General . 10
5.3.2 [PRE-1] Policy on vulnerability handling . 10
5.3.3 [PRE-2] Policy on coordinated vulnerability disclosure . 12
5.3.4 [PRE-3] Operational security . 14
5.3.5 [PRE-4] On-going communication . 15
5.3.6 [PRE-5] Secure communication . 16
5.3.7 [PRE-6] Product identification . 17
5.3.8 [PRE-7] Identification of software components . 18
5.3.9 [PRE-8] Identification of hardware components . 20
5.3.10 [PRE-9] Planning regular test and reviews . 21
5.3.11 [PRE-10] Mechanisms for distribution . 22
5.4 [RCP] Receipt . 22
5.4.1 General . 22
5.4.2 [RCP-1] Capability to receive reports . 23
5.4.3 [RCP-2] Monitoring . 24
5.4.4 [RCP-3] Potentially impacted software components . 25
5.4.5 [RCP-4] Potentially impacted hardware components . 25
5.4.6 [RCP-5] Coordinator involvement . 26
5.4.7 [RCP-6] Performing regular tests . 26
5.4.8 [RCP-7] Performing regular reviews . 27
5.5 [VRF] Verification . 28
5.5.1 General . 28
5.5.2 [VRF-1] Initial assessment and verification . 28
5.5.3 [VRF-2] Vulnerability risk assessment . 29
5.6 [RMD] Remediation . 30
5.6.1 General . 30
5.6.2 [RMD-1] Remediation decision . 30
5.6.3 [RMD-2] Remediation development . 30
5.6.4 [RMD-3] Remediation test . 31
5.7 [RLS] Release . 32
5.7.1 General . 32
5.7.2 [RLS-1] Security update release . 32
5.7.3 [RLS-2] Release information . 33
5.8 [PRA] Post-release . 35
5.8.1 General . 35
5.8.2 [PRA-1] Post-release actions . 35
Annex ZA (informative) Relationship between this European Standard and the essential
cybersecurity requirements of Regulation (EU) 2024/2847 of the European
Parliament and of the Council of 23 October 2024 on horizontal cybersecurity
requirements for products with digital elements and amending Regulations (EU)
No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber
Resilience Act) aimed to be covered . 36
Bibliography . 37
European foreword
This document (prEN 40000-1-3:2026) 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-CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Introduction
Vulnerabilities are likely to emerge over time during the life cycle of a product with digital elements
(hereinafter referred to as "product"), including its software and hardware components, despite
adherence to cybersecurity principles defined in prEN 40000-1-2 [1].
It is important to prepare for those events by developing an effective strategy for the management of
vulnerabilities during the product life cycle, including regular monitoring, testing, risk assessment,
prioritization, remediation, and verification, as well as communication, which are all essential activities
to discover and fix new vulnerabilities and maintain cybersecurity coverage.
This vulnerability handling document refines the activities that are part of international standards such
as EN ISO/IEC 30111:2020 [2], EN ISO/IEC 29147:2020 [3] and ISO/IEC TR 5895:2022 [4]. It elevates,
where appropriate, recommendations to mandatory requirements to ensure conformity with the Cyber
Resilience Act (CRA) obligations. It integrates essential elements such as Software Bill of Materials
(SBOM), regular testing and review activities, secure update mechanisms, and explicit requirements to
support effective Coordinated Vulnerability Disclosure (CVD) and vulnerability-handling processes.
The rigor with which vulnerability handling activities are expected to be executed are expected to adhere
to a risk-based approach, determined by the potential societal impact of a product's security failure.
For example, the regular test and other monitoring activities are expected to be executed more
frequently for products with higher criticality, and having a more detailed SBOM can improve the
detection of vulnerabilities in components used by the product. The horizontal standards for the Cyber
Resilience Act cannot be too prescriptive and thus require appropriate product risk-based criteria to
be documented in the risk assessment and the cybersecurity plan for the product.
Identifying a product that can cause high-risk impact, which can be found across all categories covered
by the Cyber Resilience Act, is integral to the regulatory risk assessment that needs to be conducted by
the manufacturer. To support a risk-based approach, this document defines requirement enhancements.
Figure 1 illustrates an example of the vulnerability life cycle model, where the period between
vulnerability discovery and the application of security updates prolongs the window of opportunity for
threat actors to exploit the vulnerability and to conduct a cybersecurity attack.
a
Derived from ENISA — STATE OF VULNERABILITIES 2018/2019 — Analysis of Events in the life of
Vulnerabilities ( December 2019 / Page 9 / Figure 2: Vulnerability life cycle )
Figure 1 — Vulnerability life cycle
The vulnerability handling activities defined in this document are organized into the following distinct
phases:
— Preparation: Establishing policies, processes, and capabilities for vulnerability intake and
disclosure.
— Receipt: Receiving and monitoring vulnerability reports from internal and external sources.
— Verification: Assessing the validity, applicability, and severity of reported vulnerabilities.
— Remediation: Planning, developing, and testing fixes or mitigations.
— Release: Distributing security updates and publishing advisories.
— Post-Release: Monitoring effectiveness and applying lessons learned.
Manufacturers implementing this document will be equipped to demonstrate due diligence in
vulnerability handling, maintain product security over time, and support transparency and trust across
the digital ecosystem.
1 Scope
This document specifies the requirements and activities that focus on the process aspects of
vulnerability handling applicable to manufacturers of products with digital elements (hereinafter
referred to as "product").
The document is intended to support compliance with the Cyber Resilience Act (CRA) Regulation (EU)
2024/2847, particularly the essential requirements outlined in Annex I, Part II.
This document, with the appropriate requirement enhancements, is applicable across all product
categories. Implementing these requirements enables a manufacturer to ensure security is maintained
throughout the product life cycle.
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
prEN 40000-1-2:2025, Cybersecurity requirements for products with digital elements - Part 1-2: Principles
for cyber resilience
3 Terms and definitions
For the purposes of this document, the terms and definitions given in 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/
3.1
test
activity in which a system or component is executed under specified conditions, the results are observed
or recorded, and an evaluation is made of some aspect of the system or component
Note 1 to entry: A test is carried out to measure or classify a characteristic or a property of an item by applying to
the item a set of environmental and operating conditions and/or requirements.
[SOURCE: ISO/IEC/IEEE 29119-2:2021 [5], 3.21]
3.2
review
activity undertaken to determine the suitability, adequacy and effectiveness of the subject matter to
achieve established objectives
[SOURCE: ISO 31073:2022 [6], 3.3.41]
3.3
coordination
set of activities including identifying and engaging stakeholders, mediating, communicating, and other
planning in support of vulnerability disclosure
Note 1 to entry: The term “coordinated vulnerability disclosure” is used to denote a disclosure process that includes
coordination.
[SOURCE: EN ISO/IEC 29147:2020 [3], 3.3]
3.4
upstream
handling, processes and movements of goods that occur before the organization in the supply chain
takes custody of the goods
[SOURCE: ISO 28001:2007 [7], 3.27]
3.5
downstream
handling, processes and movements of goods when they no longer are in the custody of the organization
in the supply chain
[SOURCE: ISO 28001:2007 [7], 3.10]
4 General
4.1 Structure of this document
Requirements in this document are assigned unique identifiers consisting of a three letter abbreviation
for clause and for the requirement a two-letter abbreviation (“RQ” for a requirement, “RC” for a
recommendation, and “PM” for a permission, all numbered independently, each starting at 01), followed
by a number, separated by a hyphen.
This document supports the risk-based approach by providing requirement enhancements that are
listed into the document with the acronym RE.
EXAMPLE 5.X.X [XXX-1] Title of the Section
....
5.X.X.X Requirement
....
[XXX-X-RQ-XX] Description of a requirement
[XXX-X-RQ-XX-RE] Description of a requirement enhancement
[XXX-X-RC-XX] Description of a recommendation
[XXX-X-PM-XX] Description of a permission
4.2 Relationships with other international standards
This document uses as building blocks the following standards and technical reports:
— EN ISO/IEC 29147:2020 [3] - Vulnerability disclosure - provides guidelines for manufacturers on
how to process and remediate potential vulnerability reports reported by internal or external
individuals or organizations. The major focus is on receiving reports about potential vulnerabilities
and when distributing vulnerability remediation information to affected users.
— EN ISO/IEC 30111:2020 [2] - Vulnerability handling processes - provides guidelines on how to
investigate, process and resolve potential vulnerability reports.
To enhance the multi-party essence of the CVD and to capture the complexity of the supply chain and
multiple stakeholder involved in the coordinated vulnerability disclosure process this document has
been augmented with ISO/IEC TR 5895:2022 [4].
— ISO/IEC TR 5895:2022 [4] - Multi-party coordinated vulnerability disclosure and handling -
clarifies and increases the application and implementation of EN ISO/IEC 30111:2020 [2] and
ISO/IEC 29147:2018 [8] in multi-party coordinated vulnerability disclosure (MPCVD) settings.
NOTE EN ISO/IEC 30111:2020 [2] and EN ISO/IEC 29147:2020 [3] use the term “vendor” where CRA uses
“manufacturer”.
The relationships between the referenced standards are shown in Figure 2, which highlights the
components that were introduced or substantially modified to align with the Cyber Resilience Act
essential requirements.
a
Derived from ISO/IEC TR 5895:2022 [4] — Figure 2: The relationship between ISO/IEC 29147 and
ISO/IEC 30111 with respect to MPCVD
Figure 2 — Relationships between referred standards and this document
5 Vulnerability handling
5.1 General
This clause defines the key activities and requirements for vulnerability disclosure and handling,
providing manufacturers with a structured foundation for designing and implementing their own
processes. These processes enable manufacturers to manage communication among stakeholders,
proactively discover and collect vulnerability information and reports, and diagnose and remediate
vulnerabilities before they become public, thereby preventing malicious actors from exploiting them.
5.2 [APP] Applicability
5.2.1 General
The rigor applied to vulnerability handling activities follows a risk-based approach aligned with the
product's risks.
5.2.2 [APP-1] Requirement enhancement applicability
5.2.2.1 General
Manufacturers are normally responsible for conducting a risk assessment to assess the risks associated
with the use of the product to determine the appropriate rigor for vulnerability handling.
Dependent upon the risks, there is an expectation to implement the relevant requirement enhancements
in one or more of the following identified activities:
— [PRE-5-RQ-01-RE] Secure communication
— [PRE-7-RQ-03-RE] SBOM completeness
— [PRE-7-RQ-07-RE] SBOM software component hash
— [RLS-2-RQ-03-RE] Machine-readable advisories
NOTE EDITORIAL NOTE: CEN-CENELEC JTC13/WG9 invites feedback from the national organizations on the
approach for requirement enhancements to better support the risk based approach.
5.2.2.2 Input
— Product context (prEN 40000-1-2 [1], 6.2)
— Risk assessment (prEN 40000-1-2 [1], 6.4)
5.2.2.3 Requirement
[APP-1-RQ-01] The applicability of the requirement enhancements shall be determined based on the
product risks.
NOTE Requirement Enhancement: Requirements marked with “RE” indicate risk-based enhancements that
apply where the regulatory risk assessment determines that additional rigor is necessary.
5.2.2.4 Output
— Statement of applicability
5.2.2.5 Assessment criteria
— Evaluation of the applicability criteria based on the product context and risk assessment
5.3 [PRE] Preparation
5.3.1 General
The preparation phase lays the foundation for establishing appropriate vulnerability handling and
disclosure processes and policies to support the subsequent phases, providing a structured,
methodological approach to identify, verify, and address vulnerabilities, including communication. This
phase also includes requirements such as identifying software and hardware components, focusing on
creating the Software Bill of Materials (SBOM), and establishing a coordinated vulnerability disclosure
and vulnerability handling policy.
5.3.2 [PRE-1] Policy on vulnerability handling
5.3.2.1 General
A manufacturer establishes and maintains an internal vulnerability handling policy to clearly define
their approach for investigating and remediating security vulnerabilities. An additional important
aspect covered is the testing strategy that should be defined to support effective and regular tests and
reviews of its products. This policy forms a core part of the manufacturer’s overall vulnerability handling
process and is compatible with the external coordinated vulnerability disclosure policy as per 5.3.3.
The intended audience for the vulnerability handling policy is the internal staff.
5.3.2.2 Input
— Coordinated Vulnerability Disclosure policy
— 5.3.10
— Software bill of materials
5.3.2.3 Requirement
[PRE-1-RQ-01] A policy on vulnerability handling shall be created, put in place and adhered to.
NOTE 1 For additional guidance on the vulnerability handling policy, refer to EN ISO/IEC 30111:2020 [2], 6.3.
[PRE-1-RC-01] An organizational framework should be created to support the activities defined in the
vulnerability handling process as per [PRE-1-RQ-01].
NOTE 2 For additional guidance on organizational framework, refer to EN ISO/IEC 30111:2020 [2], 6.4.
[PRE-1-RQ-02] The vulnerability handling policy shall include:
— basic guidance, principles, and responsibilities for handling potential vulnerabilities in products
— measures to prevent premature disclosure of information about potential vulnerabilities before
they are fixed
— a target schedule for remediation development
NOTE 3 The target schedule serves as a guide for completing the activities of remediation development, as
described in 5.6.
NOTE 4 The target schedule depends on different aspects such as the complexity of the remediation to be
developed, and the potential risk of the vulnerability, as assessed in 5.5.2. Additional variables include the
complexity of the interactions with the supply chain and entities involved in the investigation and remediation
activities.
— strategies related to the regular test (3.1) and review (3.2) activities, as defined in 5.3.10.
[PRE-1-RC-02] A policy on vulnerability handling should include:
— the full process description that is aligned with the expectations of this document
— the roles and responsibilities that will be assigned to handle the potential vulnerabilities in the
product
NOTE 5 For additional guidance on role and responsibilities including definition of usual activities refer to EN
ISO/IEC 30111:2020 [2]:
— 6.5 Vendor CSIRT or PSIRT
— 6.6 Responsibilities of the product business division
— 6.7 Responsibilities of customer support and public relations
— 6.8 Legal consultation
— measures to prevent premature disclosure of information about potential vulnerabilities before
they are fixed, as defined in 5.3.6
— activities and criteria to define a target schedule for the remediation of the vulnerability, which
depends on the embargo period, established and inflüenced by the complexity of the case by case
situation with impacted upstream stakeholders, and on the criticality of the vulnerability and the
product itself
— where known and appropriate, it is important to list the downstream stakeholders that are using
the product under scope
NOTE 6 Appropriateness depends on privacy and confidentiality agreements with downstream
stakeholders.
— the mapping of upstream stakeholders to support the component identification required by 5.3.8
and 5.3.9
NOTE 7 For additional guidance on roles and responsibilities in a multi-party configüration that includes
definition of usual activities, refer to ISO/IEC TR 5895:2022 [4], Clause 8.
[PRE-1-RQ-03] The effectiveness of the vulnerability handling process shall be monitored.
NOTE 8 For additional guidance on ways to monitor the effectiveness of the vulnerability handling process,
refer to EN ISO/IEC 30111:2020 [2], 7.2.
[PRE-1-RQ-04] For a timely resolution of the issues, a mapping of upstream interdependencies,
including open source, is required to support the coordination and notification activities when a
vulnerability is discovered.
[PRE-1-RQ-05] A policy on vulnerability handling shall support all the activities that are defined in the
vulnerability disclosure policy, as described in 5.3.3.
5.3.2.4 Output
— Policy on vulnerability handling
— List of the upstream stakeholders
— Data collection on target with the schedule remediation activities
5.3.2.5 Assessment criteria
— Policy on vulnerability handling that covers the activities defined within this document
— Existence of a list of upstream stakeholders linked to the components integrated into the product
with a completeness check using the SBOM
— Policy on vulnerability handling that includes:
— appropriate alignment with the coordinated vulnerability disclosure
— demonstrated organizational capabilities, roles and responsibilities to deal timely and in a
systematic way in the event of a vulnerability
— Appropriate testing and review policies defined including regularity and timeline of those activities
as aligned with 5.3.10
— Evidence of process monitoring for vulnerability handling effectiveness
5.3.3 [PRE-2] Policy on coordinated vulnerability disclosure
5.3.3.1 General
The purpose of the coordinated vulnerability disclosure policy is to communicate the manufacturer's
intentions, responsibilities, and expectations regarding vulnerability disclosure. A coordinated
vulnerability disclosure policy encompasses both two-party coordination (e.g. between the reporter
and the manufacturer) and multi-party disclosure involving multiple stakeholders. To support this, the
manufacturer develops and publishes an external coordinated vulnerability disclosure policy and
ensures the related internal activities are in place to effectively coordinate the disclosure of
vulnerabilities.
In addition, to prevent attackers from gaining early access to sensitive information, reporters typically
notify manufacturers privately, and refrain from public disclosure until a fix is available after an agreed-
upon embargo period has passed. The receipt, verification, and remediation development stages are
generally conducted within this embargo period, ensuring that vulnerabilities are addressed securely
and responsibly by all the parties involved in the process.
5.3.3.2 Input
— Vulnerability handling policy
5.3.3.3 Requirement
[PRE-2-RQ-01] A policy on coordinated vulnerability disclosure (CVD) shall be created, published in
an accessible format and adhered to.
NOTE 1 Accessibility requirements and advice can be found in EN 301 549 v3.2.1 [9].
[PRE-2-RQ-02] A coordinated vulnerability disclosure policy shall include one or more contact
mechanisms.
NOTE 2 Contact information can be available for both reporting vulnerabilities and for requesting additional
information about the coordinated vulnerability program.
For additional guidance on policy elements refer to EN ISO/IEC 29147:2020 [3], 9.2.2.
A list of possible contact mechanisms includes, but is not limited to:
— e-mail address;
— phone number;
— web form;
— contact information for customer service.
[PRE-2-RC-01] The contact mechanisms should provide accessibility via more than one sensory
channel.
EXAMPLE The purpose of providing more than one sensory channel is to address situations in which a potential
user with a writing impediment can still, for example, call a phone number to ask for and provide information.
NOTE 3 Accessibility requirements and advice can be found in EN 301 549 v3.2.1 [9].
[PRE-2-RQ-03] Setting expectations for on-going communication shall be stated in this policy.
NOTE 4 The reference for this requirement is 5.3.5.
[PRE-2-RC-02] A vulnerability disclosure policy should include following elements:
— vulnerability report contents;
— secure communication options as detailed in 5.3.6;
— scope;
— publication;
— recognition.
NOTE 5 For additional guidance on recommended policy elements refer to EN ISO/IEC 29147:2020 [3], 9.3.
[PRE-2-RC-03] A disclosure strategy should be in place to ensure that the information on vulnerability
is not disclosed before it is addressed.
NOTE 6 For additional guidance on the embargo period refer to EN ISO/IEC 29147:2020 [3], 5.6.8.
For additional guidance on the disclosure strategy refer to ISO/IEC TR 5895:2022 [4], 7.3.2.
NOTE 7 Vulnerability disclosure requires flexibility; there is no one-size-fits-all approach. Reports, timelines,
and responses can be tailored to each case and agreed upon by all stakeholders.
NOTE 8 Different embargo periods (vulnerability-by-vulnerability) can be negotiable between manufacturers
and reporters, or a coordinator if involved.
5.3.3.4 Output
— Policy on coordinated vulnerability disclosure
5.3.3.5 Assessment criteria
— Evidence of the policy on coordinated vulnerability disclosure that is published and followed, and
aligned with the internal vulnerability handling policy to support its implementation
— Evidence of the policy on coordinated vulnerability disclosure that include agreements or
definition of parameters necessary to estimate the embargo period during the receipt phase
— Evidence that the contact mechanisms have been published in an accessible format and consider
more than one sensory channel
5.3.4 [PRE-3] Operational security
5.3.4.1 General
Information related to vulnerabilities is generally sensitive information, as vulnerabilities can be used
by malicious actors. All external communication, as well as the manufacturers' internal processes, need
to take operational security into account. The confidentiality controls can be lifted after remediation
and advisory information has been published. Depending on the organization and its products,
confidentiality controls can be as simple as marking information with TLP (Traffic Light Protocol) or
be supported by technical controls like access control.
5.3.4.2 Input
— Policy on vulnerability handling
— Policy on coordinated vulnerability disclosure
5.3.4.3 Requirement
[PRE-3-RC-01] Operational security should be provided throughout the activities of receiving (5.4.2)
and communicating about (5.3.5) vulnerability information or reports.
NOTE 1 For additional guidance related to this requirement, refer to EN ISO/IEC 29147:2020 [3], 6.7.
NOTE 2 Operational security can be implemented in a way that maintains accessibility for submitting
vulnerability reports, including the availability of an anonymous reporting mechanism.
[PRE-3-RQ-01] Limiting access to non-public vulnerability information on a need-to-know basis shall
be considered.
NOTE 3 For additional guidance related to this requirement, refer to EN ISO/IEC 30111:2020 [2], 7.3.
5.3.4.4 Output
— Documented security measures applied during vulnerability handling
— Documented security measures applied during coordinated vulnerability disclosure
— Evidence of the implementation of the capability to receive the reports
5.3.4.5 Assessment Criteria
— Evidence of documented security measures
5.3.5 [PRE-4] On-going communication
5.3.5.1 General
The purpose of this phase is to maintain regular communication channels during the vulnerability
handling activities with relevant stakeholders, such as users, coordinators, reporters, manufacturers,
open-source stewards, maintainers of non-commercial open-source projects and other stakeholders,
where required. Communication can be aligned with the product’s life cycle and occur in parallel with
all vulnerability handling phases, rather than following a strict sequence.
5.3.5.2 Input
— policy on coordinated vulnerability disclosure
Depending on the phase of vulnerability handling, not all of these may be required or available:
— Vulnerability report from internal or external source, see section 5.4.3
— Verified vulnerability report including an initial assessment of the vulnerability and its severity,
as required per 5.5.2
— Results of the risk assessment, as required per 5.5.3
— Remediation plan, as required per 5.6.2
— Remediation and/or fix, as required per 5.6.3
— Timeline
5.3.5.3 Requirement
[PRE-4-RQ-01] Communication with reporters and other stakeholders shall be established and
maintained.
NOTE 1 For additional guidance on communication with reporters and other stakeholder, refer to EN ISO/IEC
29147:2020 [3], 6.5.
[PRE-4-RQ-02] Communication with users shall implement accessible modes of communication.
NOTE 2 For additional guidance on accessible communication methods refer to prEN 40000-1-2 [1], 6.6.
5.3.5.4 Output
— Record of the communication with users and other relevant stakeholders
5.3.5.5 Assessment criteria
— Presence in the CVD policy on commitments related to on-going communications
— Presence of accessible modes of communication
— If reports have been submitted, evidence exists that communication with stakeholders has been
performed
5.3.6 [PRE-5] Secure communication
5.3.6.1 General
The purpose of this subclause is to define secure communication mechanisms. Since vulnerability
information can be exploited to attack affected systems, it is essential that such sensitive information,
especially when not publicly disclosed, is communicated confidentially.
5.3.6.2 Input
— Reporting mechanism, as required per 5.4.2.
5.3.6.3 Requirement
[PRE-5-RC-01] Secure communication mechanisms should be provided throughout the activities of
receiving and communicating vulnerability information or reports.
[PRE-5-RQ-01-RE] Secure communication mechanisms shall be provided and communicated to
support 5.4.2can.
NOTE 1 Initial contact (reporter-controlled). Because initial contact can arrive via any channel (e.g. email, social
media, phone), the organization accepts the report, registers it, and offers to continue over one of the secure
options when sensitive details (exploits, customer data, keys, configüration data) are required.
NOTE 2 Providing a means of secure communication is essential, but is not enforced if the reporter is unwilling
or unable to support it.
[PRE-5-RC-02] Secure communication methods should support confidentiality and message integrity.
EXAMPLE
— web-based forms or applications using TLS (HTTPS)
— e-mail encryption and signing using S/MIME or OpenPGP
NOTE 3 For additional guidance on secure communication, refer to EN ISO/IEC 29147:2020 [3], 5.8.
[PRE-5-RC-03] Stakeholders should have a way to report vulnerabilities anonymously.
[PRE-5-RC-04] Methods of secure communication should not disrupt the accessibility of external
communication.
5.3.6.4 Output
— Documentation on the secure communication mechanism used
— Evidence of secure communication
5.3.6.5 Assessment criteria
— Presence in the CVD policy on commitments related to mechanisms of secure communication
— If reports have been submitted, evidence exists that secure communication with stakeholders has
been performed
5.3.7 [PRE-6] Product identification
5.3.7.1 General
This subclause describes the activities of recording relevant information to enable the product to be
identifiable, for different purposes such as vulnerability handling, software bill of material generation
and verification, and vulnerability information sharing and reporting.
5.3.7.2 Input
— Rules on naming and versioning conventions
5.3.7.3 Requirement
[PRE-6-RQ-01] A product shall be identifiable by providing at least the following information:
— manufacturer name;
— product name;
— (for hardware): any hardware product identifier, if applicable;
— (for software): any software product identifier, if applicable.
[PRE-6-RQ-02] If the product consists of both hardware and software, information for product
identification, as per [PRE-6-RQ-01], shall be provided separately.
NOTE A taxonomy of methods for identifying the product is documented in prEN IEC 61360-7:2025 [10]. The
resource can be found online with reference 0112/2///61360_7#AAS005#001 at the following web address
https://cdd.iec.ch/cdd/iec61360-7/iec61360-7.nsf/classes/0112-2---61360_7%23AAS005
EXAMPLE Information for product identification can be provided using one or more of the following:
(for hardware)
— part number
— serial number
— batch number
— firmware version
— production date
(for software)
— software version
— release version
— build number
— software Hash Identifier (SWHID)
— release date
5.3.7.4 Output
— Record of information for product identification
5.3.7.5 Assessment criteria
— Evidence of product identification
5.3.8 [PRE-7] Identification of software components
5.3.8.1 General
This subclause describes the activities of identifying the software components that make up the product.
The purpose of this identification is to enable effective vulnerability handling by ensuring that all
components are known, traceable, and can be assessed for potential cybersecurity risks.
5.3.8.2 Input
— Binary artefacts
— Configüration files
— Source code
— Cybersecurity architecture and design documents (prEN 40000-1-2 [1], 7.4)
— 5.3.7
— Risk assessment (prEN 40000-1-2 [1], 6.4)
5.3.8.3 Requirement
[PRE-7-RQ-01] All software components contained in the product shall be identified and documented.
[PRE-7-RQ-02] For each component identified in [PRE-7-RQ-01], the following information shall be
included:
— Software producer
NOTE 1 For open-source software, which is supported by an open-source steward, this is the name of the
stewarding organization.
— Component name
— Component version
[PRE-7-RQ-03] An SBOM shall be drawn up, including at least the top-level dependencies that are
contained in the product, as identified in [PRE-7-RQ-01].
NOTE 2 For additional guidance on top-level dependencies, refer to BSI TR-03183-2 [11], 8.3.1.
[PRE-7-RQ-03-RE] All the software components identified in [PRE-7-RQ-01] shall be drawn up in the
SBOM to detect transitive dependencies when technically feasible.
NOTE 3 It might not always be possible to obtain the necessary information from suppliers to generate an
SBOM that includes all transitive dependencies.
NOTE 4 For additional guidance on the depth and extent of the SBOM refer to ISO/IEC 27036-3:2023 [12],
B.3.1.3.
NOTE 5 A more granular SBOM can better support the ability to faster and more efficiently detect vulnerabilities
in the components that are part of the product.
[PRE-7-RQ-04] The SBOM shall be assembled in a structured, machine-readable format.
NOTE 6 The SBOM includes the relationship of the identified software components. This includes the software
components on which this software component is directly dependent, or which this software component contains.
NOTE 7 Some of the widely used machine-readable formats by software ecosystem stakeholders to generate
and consume SBOMs are, for example:
— Software Package Data eXchange (SPDX) (ISO/IEC 5962:2021 [13])
— CycloneDX
[PRE-7-RQ-05] If the software component is updated with a new build or release, a new SBOM shall
be created to reflect the new version of the software.
NOTE 8 This includes software builds to integrate an updated component or dependency.
[PRE-7-RC-01] When new details about the identified components are detected or the need to correct
an error in the existing SBOM is discovered, a revised SBOM should be issued.
[PRE-7-RQ-06] Metadata for the SBOM shall include:
— SBOM Author
NOTE 9 The name of the entity that creates the SBOM data for a component.
— Version
— Timestamp
NOTE 10 Timestamp is used to record the date and time of the SBOM creation and modification by the Author.
For additional guidance on the timestamp format, refer to ISO 8601-1:2019 [14] (e.g. 2024-05-23T13:51:37Z).
[PRE-7-RQ-07] For
...