@@ -58,20 +58,18 @@ In the present document "**shall**", "**shall not**", "**should**", "**should no
The present document provides the technical cybersecurity requirements for the products in scope, following a risk-based approach in support of the Cyber Resilience Act (CRA) [\[i.1\]](#_ref_i.1). The technical cybersecurity requirements are thereby proportionate to the intended purpose, reasonably foreseeable use, deployment context, and threat exposure of the products.
[clause 4](#4-product-context) does not contain technical requirements; it describes the product context that is considered for the application of this standard.
[Clause 4](#product-context) does not contain technical requirements; it describes the product context that is considered for the application of this standard.
[clause 4](#4-product-context) also defines Use Cases (UCs) that represent the main deployment scenarios reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for identifying relevant cybersecurity risks.
[Clause 4](#product-context) also defines Use Cases (UCs) that represent the main deployment scenarios reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for identifying relevant cybersecurity risks.
[clause 5](#5-technical-requirements-for-the-products) specifies technical cybersecurity requirements for the product to mitigate the identified risks, including their applicability conditions.
[Clause 5](#technical-requirements-for-products) specifies technical cybersecurity requirements for the product to mitigate the identified risks, including their applicability conditions.
[clause 6](#6-assessment-criteria-for-compliance-with-technical-requirements) specifies the assessment criteria and compliance verification procedures with the requirements of clause 5.
[Clause 6](#assessment-criteria-for-compliance-with-technical-requirements) specifies the assessment criteria and compliance verification procedures with the requirements of clause 5.
[Annex A](#_annex.a) maps the technical requirements of the present document with the essential requirements of the CRA [\[i.1\]](#_ref_i.1) regulation.
[Annex B](#_annex.b) informs about the methodology used to assess the security risks of the products in their context.
<mark>Editor’s Note: Where the functionality of the product relies on cryptography, then Annex K shall be included and instantiated in the CRA Vertical standard to provide presumption of conformity with regards to cryptographic mechanisms embarked in the product.</mark>
[Annex K](#_annex.k) supports the definition of the cryptographic requirements and assessment criteria used by the present document.
<mark>Editor’s Note: The following annexes are optional (may or may not be included in the vertical):</mark>
@@ -85,7 +83,7 @@ Further information on guidance for the application of the present document is p
The present document specifies technical requirements and corresponding assessment criteria for Virtual Private Networks related to cybersecurity. The products with digital elements in scope, thereafter “VPNs”:
* are specified within the “technical description” of the “category of product” number “5” by the Commission Implementing Regulation (EU) 2025/2392 [\[i.2\]](#_ref_i.2) as: “Products with digital elements that establish an encrypted logical tunnel that is constructed from the system resources of a physical or virtual network.”
* are only covered within the product context described in [clause 4](#4-product-context) and the text of this clause.
* are only covered within the product context described in [clause 4](#_clause.4) and the text of this clause.
In particular, the present document specifies technical characteristics and methods of assessment for:
@@ -539,7 +537,7 @@ See [\[i.3\]](#_ref_i.3) for formal definitions of micro, small, and medium-size
***Architecture:** Client installed on various devices (mobile phones, laptops, servers). Connects endpoints with other endpoints directly. Connection management operated by manufacturer.
@@ -547,9 +545,7 @@ See [\[i.3\]](#_ref_i.3) for formal definitions of micro, small, and medium-size
::include{file=clauses/6.Assessment-Criteria.md}
<spanid="_annex.a"></span>
# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act
# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 - the Cyber Resilience Act <span id="_annex.a"></span>
The present document has been prepared in response to the Commission's standardisation request C(2025)618 [\[i.3\]](#_ref_i.3) to provide, in additions to its other uses, one voluntary means of conforming to the essential requirements of Regulation (EU) 2024/2847 [\[i.2\]](#_ref_i.2) known as the Cyber Resilience Act (CRA).
@@ -600,9 +596,7 @@ Presumption of conformity stays valid only as long as a reference to the present
Other Union legislation may be applicable to the product(s) falling within the scope of the present document.
<spanid="_annex.b"></span>
# Annex B (informative): Security analysis
# Annex B (informative): Security analysis <span id="_annex.b"></span>
(previously # Annex C (informative): Cybersecurity threat landscape, risk identification and assessment methodology)
@@ -1496,30 +1490,18 @@ _Editor's note: this table must be updated before the draft can be considered Fi
⁵ REQ-EMM-02 (MI-NUTI-1) or (REQ-EMM-03 (MI-TRAF-2) and REQ-EMM-04 (MI-TRAF-3) and REQ-EMM-05 (MI-TRAF-4)) apply
⁶ REQ-DRT-02 (MI-RSET) or REQ-DRT-03 (MI-INST) or REQ-DRT-06 (MI-DELE) apply
<spanid="_annex.g"></span>
# Annex G (informative): Guidelines on the implementation of the present document
# Annex G (informative): Guidelines on the implementation of the present document <span id="_annex.g"></span>
_This annex is optional and may be referred to from the Introduction of the document to provide more information on how to implement the standard._
<spanid="_annex.k"></span>
# Annex K (normative): Generic requirements and assessment criteria for the use of state-of-the-art cryptography
# Annex K (normative): Generic requirements and assessment criteria for the use of state-of-the-art cryptography <span id="_annex.k"></span>
::include{file=clauses/K.Cryptography.md}
<spanid="_annex.r"></span>
# Annex R (normative): Remote Data Processing Solutions
# Annex R (normative): Remote Data Processing Solutions <span id="_annex.r"></span>
::include{file=clauses/R.RDPS.md}
<spanid="_annex.s"></span>
# Annex S (normative): Secure Updates
::include{file=clauses/S.Secure-Update.md}
# History
_The following table will automatically be filled in by the ETSI Secretariat._
<mark>Editor's Note: This is the normative clause of the standard, defining the technical requirements to implement the Essential Cybersecurity Requirements of the CRA regulation.</mark>
<mark>Editor's Note: Requirements should be written with "shall" statements.</mark>
@@ -42,7 +40,7 @@
## 5.1 Introduction - Applicability of the requirements
The technical requirements of the present document apply under the product context described in [clause 4](#4-product-context), which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.
The technical requirements of the present document apply under the product context described in [clause 4](#_clause.4), which shall be in accordance with its intended use. The product shall comply with all applicable technical requirements of the present document at all times when operating in such a product context.
Not all requirements are universally applicable: The applicability of requirements may be based on use cases or specific capabilities of the product.
@@ -37,7 +37,7 @@ The product’s default configuration shall only use cryptographic mechanisms th
- a) the cryptographic mechanism is listed in [clause K.3.2](#k32-list-of-acm-extended-cryptographic-mechanisms) as an ACM-extended cryptographic mechanism for the specific product function(s), following consideration of the criteria specified in item 2.b;
- b) where the cryptographic mechanism is not listed in [clause K.3.2](#k32-list-of-acm-extended-cryptographic-mechanisms), the cryptographic mechanism meets all the following criteria:
- i) the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [1](#_ref_1);
- ii) the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognized European, international or sector-specific standards development organization, or by an industry specification organization accountable for the relevant specification, including *CEN, CENELEC, ETSI, ISO, IEC, ISO/IEC JTC 1, IETF, IEEE, ITU-T, NIST, 3GPP, O-RAN Alliance, BSI, ACN, [C2SP](http://c2sp.org), ;* or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognized national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including BSI TR-02102-1, BSI TR-02102-2, BSI TR-02102-3 and BSI TR-02102-4;
- ii) the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognized European, international or sector-specific standards development organization, or by an industry specification organization accountable for the relevant specification, including CEN, CENELEC, ETSI, ISO, IEC, ISO/IEC JTC 1, IETF, IEEE, ITU-T, NIST, 3GPP, O-RAN Alliance, BSI, ACN, [C2SP](http://c2sp.org); or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognized national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including BSI TR-02102-1, BSI TR-02102-2, BSI TR-02102-3 and BSI TR-02102-4;
- iii) the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;
- iv) the cryptographic properties of the cryptographic mechanism are known;
- v) no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;
@@ -260,9 +260,9 @@ Where the product’s default configuration uses ACM-extended cryptographic mech
### K.3.2 List of ACM-extended cryptographic mechanisms
Table K.3.2 lists the ACM-extended cryptographic mechanisms specified by the present document.
Table K.1 lists the ACM-extended cryptographic mechanisms specified by the present document.
| UMAC | Algorithm | 128 bit | MAC | Authentication, Integrity | RFC 4418 [\[11\]](#_ref_11) | |
> NOTE 1: The combination of the mechanism mentioned in Table K.3.2: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
> NOTE 1: The combination of the mechanism mentioned in Table K.1: ACM-extended cryptographic mechanisms together with the mechanisms in ACM that is appropriate for the cryptographic use-case to form a cryptographic protocol are allowed. For example ChaCha20-Poly1305, HMAC-blake2s or X25519ML-KEM768.
> NOTE 2: The use-case defined in K.3.2 marked in “Related product function(s) / use case(s), where applicable” is a non-exhaustive list and listed algorithm can be used for other appropriate use-cases as well.
@@ -320,36 +320,16 @@ Where the product’s default configuration uses interoperability-based cryptogr
### K.4.2 List of interoperability-based cryptographic mechanisms
Table K.4.2 lists the interoperability-based cryptographic mechanisms specified by the present document.
Table K.2 lists the interoperability-based cryptographic mechanisms specified by the present document.
| Interoperability-based cryptographic mechanism | Type of cryptographic mechanism | Characteristics / parameters | Related product function(s) / use case(s), where applicable | External specification(s) or external requirement(s) | Interoperability justification | Conditions or limitations, where applicable |
| \<mechanism name\> | \<Algorithm / Primitive / Scheme / Protocol / Protocol profile / Cipher suite / Mode / Construction / Parameter set / Other\> | \<key length, mode, profile, cipher suite, parameter set, version, etc.\> | \<product function, interface, protocol context, operational context, etc.\> | \<external specification, regulatory requirement, mandatory public-sector requirement, operational constraint requiring use of the mechanism, technical interoperability constraint, platform compatibility requirement, etc.\> | \<why the mechanism is needed for interoperability\> | \<constraints, permitted use, excluded use, negotiation preference, external system or requirement, compensating measures, migration expectation, warning/logging, lifecycle limitation, etc.\> |
Editor’s note for rapporteurs: Where no interoperability-based cryptographic mechanisms are specified by the vertical standard, this clause should state: “No interoperability-based cryptographic mechanisms are specified.” This editor’s note shall be removed before publication.
Editor’s note for rapporteurs: Table K.4.2 is an example template and can be adapted where needed for the relevant vertical standard.
### K.4.3 Assessment
Compliance with the requirement in [clause K.4.1](#k41-requirement) is assessed in [clause K.1.2.3](#k123-assessment-of-interoperability-based-cryptographic-mechanisms).
> NOTE: The assessment of the external specifications or external requirements themselves is outside the scope of this assessment. Their relevance is deemed confirmed by their inclusion in the present document.
# Change history
| Document history | | |
| ----- | :---- | :---- |
| V 0.0.7 | 10\. April 2026 | editHelp provision |
| V 0.0.7.1 | 22\. April 2026 | Update of agreed changes regarding resolution of comments in TF CR \#06 |
| V 0.0.7.2 | 28.April 2026 | Update of changes regarding **proposal** of solution of comments in TFCR \#07 and editorial changes |
| V 0.0.8.3 | 06 May 2026 | Kilian (BSI): Updates following the meeting \#8 Mohamad (IOTR): Editorial improvements clarifications to Annex K, including refinement of assessment wording, clarification of evidence expectations for PASS/FAIL verdicts, and minor corrections to crypto-agility assessment criteria, without changing the agreed structure or technical intent of the annex. Alessio (Qualcomm): contribution addressing some limitations of the current version of Annex K |
| V 0.0.8.4 | 12 May 2026 | Targeted consistency updates to align K.1.2 with the three CRY-SOTA routes defined in K.1.1; clarification of assessment objectives, preparation, activities, evidence and PASS/FAIL verdicts; refinement of stability, vulnerability and crypto-agility wording; integration of relevant generic assessment improvements identified from a vertical Annex K customisation; removal of actor-specific assessment wording; harmonisation of assessment structure across K.1.2.1, K.1.2.2 and K.2.2; review of EC and Google comments and integration of corresponding resolutions where agreed, including clarification that documentation review is a minimum assessment activity, refinement of the stability-period criterion, and clarification of publicly available specifications and catalogues; and editorial consistency improvements while preserving the agreed Annex K structure. |
| V 0.0.8.5 | 14 May 2026 | Restructuring of Annex K to distinguish ACM-listed, ACM-extended and interoperability-based cryptographic mechanisms; replacement of “cryptographic algorithm” by “cryptographic mechanism” where needed; clarification of terms and definitions, including cryptographic mechanism, cryptographic property and interoperability; refinement of Application Guidance for vertical standards and rapporteurs; separation between rapporteur selection criteria in K.1.1 and product assessment in K.1.2; update of K.1.2 assessment cases to focus on the product’s default cryptographic configuration; update of K.2 crypto-agility requirement and assessment; introduction of K.3 and K.4 clauses for ACM-extended and interoperability-based cryptographic mechanisms, including template tables and guidance for cases where no items are specified; and editorial clean-up to remove obsolete state-of-the-art route terminology and align references across K.1, K.2, K.3 and K.4. |
| V 0.0.8.6 | 15 May 2026 | Integration of comments received on v0.0.8.5, including terminology alignment with the ACM by replacing “cryptographic item” with “cryptographic mechanism”; replacement of “product mechanism” with “product function”; clarification of the scope of Note 4 regarding cryptographic protocols versus primitives, modes of operation, constructions, parameter sets and cipher suites; restructuring of K.1.1 into a simplified product-facing requirement; transfer of ACM-extended and interoperability-based selection criteria to K.3.1 and K.4.1; clarification of the use of national cryptographic catalogues and introduction of a placeholder for the list of recognised organisations pending validation; and corresponding updates to K.1.2, K.2, K.3 and K.4 assessment and guidance text. |
| V 0.0.8.7 | 18 May 2026 | Version prepared for EUSR endorsement. Integration of European Commission comments on v0.0.8.6, including clarification in the application guidance that applicable vertical standards may define additional or more specific requirements, assessment activities, assessment evidence or assessment criteria where needed for the relevant product category, product function, use case or risk profile; addition of use-case references where relevant, including in the guidance for completing clauses K.3.1 and K.4.1 and in the K.3.1/K.4.1 table structures; clarification that ACM-extended cryptographic mechanisms may include sector-specific cryptographic mechanisms not explicitly listed in the ACM catalogue, including sector-specific profiles, restrictions or configurations of ACM-listed mechanisms; clarification that K.3.1 provides a complementary route to the ACM and that listing an organisation in the selection criteria does not by itself make a mechanism ACM-extended; update of recognised organisation examples to include sector-specific standards development organisations and industry specification organisations such as 3GPP and O-RAN Alliance; clarification of the term “external requirement” for interoperability-based cryptographic mechanisms, including regulatory, procurement, customer, deployment, technical interoperability and platform compatibility requirements; addition of a note explaining that conditions or limitations are necessary for the secure and constrained use of interoperability-based cryptographic mechanisms; definition of “migration condition”; update of the crypto-agility requirement and assessment to refer to deprecation dates, expiry dates, migration conditions and usage limitations specified by the ACM catalogue or the applicable vertical standard; replacement of “supported use” by wording based on limiting the use of affected product functions; and corresponding consistency updates across K.1.1, K.1.2, K.2, K.3 and K.4. |
| V1.0 r1 | 20 May 2026 | Version prepared for endorsement following resolution of all comments received on Annex K v0.0.8.7. The update integrates agreed comment resolutions and consistency improvements across the whole annex, including clarification of the treatment of cryptographic protocols and their underlying primitives, modes of operation, constructions, parameter sets and cipher suites; refinement of the K.1.1 product-facing requirement; addition of the corresponding assessment case in K.1.2 for protocols not explicitly listed; restructuring of K.3 and K.4 to separate rapporteur guidance, requirements, lists and assessment references; clarification that ACM-extended and interoperability-based mechanisms are selected through the vertical-standard tables and not through manufacturer self-classification; alignment of terminology with the ECCG ACM; removal or replacement of ambiguous “may” and “should” wording where needed; clarification of default configuration, lifecycle and crypto-agility treatment; and editorial consistency updates to notes, editor’s notes, table references and cross-references. |
| V1.1 | 22 May 2026 | Version prepared for endorsement following resolution of the comments received on Annex K V1.0 r1 during the EUSR \#35 joint ETSI / CEN-CENELEC meeting. The update introduces a controlled criteria-based ACM-extended route for cryptographic mechanisms not explicitly listed in the ACM catalogue and not listed in clause K.3.2; aligns the corresponding assessment case in K.1.2.2; restructures K.3 and K.4 to distinguish rapporteur guidance, requirements, lists and assessment references; and includes editorial consistency updates to notes, editor’s notes, table references and cross-references. |
| V1.2 | 25 May 2026 | The update clarifies the ACM-extended route in clause K.1.1 item 2 by removing the reference to the criteria in item 2.b from item 2.a, confirming that mechanisms listed in clause K.3.2 are accepted through the K.3.2 route, while the criteria in item 2.b apply where the mechanism is not listed in clause K.3.2. The corresponding rapporteur guidance remains in clause K.3.0. |
