@ansvar/eu-regulations-mcp 0.1.0 → 0.2.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (156) hide show
  1. package/LICENSE +190 -21
  2. package/README.md +159 -26
  3. package/data/seed/aifmd.json +432 -0
  4. package/data/seed/applicability/ai-act.json +87 -0
  5. package/data/seed/applicability/aifmd.json +74 -0
  6. package/data/seed/applicability/cbam.json +74 -0
  7. package/data/seed/applicability/cer.json +74 -0
  8. package/data/seed/applicability/cra.json +77 -0
  9. package/data/seed/applicability/csddd.json +74 -0
  10. package/data/seed/applicability/csrd.json +74 -0
  11. package/data/seed/applicability/cyber_solidarity.json +74 -0
  12. package/data/seed/applicability/cybersecurity-act.json +69 -0
  13. package/data/seed/applicability/data-act.json +71 -0
  14. package/data/seed/applicability/dga.json +74 -0
  15. package/data/seed/applicability/dma.json +77 -0
  16. package/data/seed/applicability/dsa.json +71 -0
  17. package/data/seed/applicability/eecc.json +74 -0
  18. package/data/seed/applicability/ehds.json +74 -0
  19. package/data/seed/applicability/eidas2.json +86 -0
  20. package/data/seed/applicability/eprivacy.json +74 -0
  21. package/data/seed/applicability/eu_taxonomy.json +74 -0
  22. package/data/seed/applicability/eucc.json +74 -0
  23. package/data/seed/applicability/eudr.json +74 -0
  24. package/data/seed/applicability/gpsr.json +74 -0
  25. package/data/seed/applicability/ivdr.json +74 -0
  26. package/data/seed/applicability/led.json +74 -0
  27. package/data/seed/applicability/machinery.json +74 -0
  28. package/data/seed/applicability/mdr.json +74 -0
  29. package/data/seed/applicability/mica.json +74 -0
  30. package/data/seed/applicability/mifid2.json +74 -0
  31. package/data/seed/applicability/mifir.json +74 -0
  32. package/data/seed/applicability/pld.json +74 -0
  33. package/data/seed/applicability/psd2.json +74 -0
  34. package/data/seed/applicability/red.json +74 -0
  35. package/data/seed/applicability/sfdr.json +74 -0
  36. package/data/seed/applicability/un-r155.json +68 -0
  37. package/data/seed/applicability/un-r156.json +68 -0
  38. package/data/seed/cbam.json +397 -0
  39. package/data/seed/cer.json +233 -0
  40. package/data/seed/csddd.json +205 -0
  41. package/data/seed/csrd.json +50 -0
  42. package/data/seed/cyber_solidarity.json +252 -0
  43. package/data/seed/data-act.json +517 -0
  44. package/data/seed/dga.json +342 -0
  45. package/data/seed/dma.json +499 -0
  46. package/data/seed/dsa.json +686 -0
  47. package/data/seed/eecc.json +981 -0
  48. package/data/seed/ehds.json +638 -0
  49. package/data/seed/eidas2.json +590 -0
  50. package/data/seed/eprivacy.json +115 -0
  51. package/data/seed/eu_taxonomy.json +285 -0
  52. package/data/seed/eucc.json +386 -0
  53. package/data/seed/eudr.json +401 -0
  54. package/data/seed/gpsr.json +462 -0
  55. package/data/seed/ivdr.json +1036 -0
  56. package/data/seed/led.json +480 -0
  57. package/data/seed/machinery.json +513 -0
  58. package/data/seed/mappings/iso27001-ai-act.json +114 -0
  59. package/data/seed/mappings/iso27001-aifmd.json +50 -0
  60. package/data/seed/mappings/iso27001-cbam.json +26 -0
  61. package/data/seed/mappings/iso27001-cer.json +74 -0
  62. package/data/seed/mappings/iso27001-cra.json +130 -0
  63. package/data/seed/mappings/iso27001-csddd.json +50 -0
  64. package/data/seed/mappings/iso27001-csrd.json +26 -0
  65. package/data/seed/mappings/iso27001-cyber_solidarity.json +82 -0
  66. package/data/seed/mappings/iso27001-cybersecurity-act.json +90 -0
  67. package/data/seed/mappings/iso27001-data-act.json +66 -0
  68. package/data/seed/mappings/iso27001-dga.json +50 -0
  69. package/data/seed/mappings/iso27001-dma.json +50 -0
  70. package/data/seed/mappings/iso27001-dsa.json +58 -0
  71. package/data/seed/mappings/iso27001-eecc.json +74 -0
  72. package/data/seed/mappings/iso27001-ehds.json +90 -0
  73. package/data/seed/mappings/iso27001-eidas2.json +106 -0
  74. package/data/seed/mappings/iso27001-eprivacy.json +66 -0
  75. package/data/seed/mappings/iso27001-eu_taxonomy.json +34 -0
  76. package/data/seed/mappings/iso27001-eucc.json +66 -0
  77. package/data/seed/mappings/iso27001-eudr.json +34 -0
  78. package/data/seed/mappings/iso27001-gpsr.json +42 -0
  79. package/data/seed/mappings/iso27001-ivdr.json +66 -0
  80. package/data/seed/mappings/iso27001-led.json +74 -0
  81. package/data/seed/mappings/iso27001-machinery.json +50 -0
  82. package/data/seed/mappings/iso27001-mdr.json +82 -0
  83. package/data/seed/mappings/iso27001-mica.json +66 -0
  84. package/data/seed/mappings/iso27001-mifid2.json +66 -0
  85. package/data/seed/mappings/iso27001-mifir.json +42 -0
  86. package/data/seed/mappings/iso27001-pld.json +26 -0
  87. package/data/seed/mappings/iso27001-psd2.json +82 -0
  88. package/data/seed/mappings/iso27001-red.json +42 -0
  89. package/data/seed/mappings/iso27001-sfdr.json +50 -0
  90. package/data/seed/mappings/iso27001-un-r155.json +130 -0
  91. package/data/seed/mappings/iso27001-un-r156.json +106 -0
  92. package/data/seed/mappings/nist-csf-ai-act.json +138 -0
  93. package/data/seed/mappings/nist-csf-aifmd.json +58 -0
  94. package/data/seed/mappings/nist-csf-cbam.json +42 -0
  95. package/data/seed/mappings/nist-csf-cer.json +90 -0
  96. package/data/seed/mappings/nist-csf-cra.json +130 -0
  97. package/data/seed/mappings/nist-csf-csddd.json +50 -0
  98. package/data/seed/mappings/nist-csf-csrd.json +34 -0
  99. package/data/seed/mappings/nist-csf-cyber_solidarity.json +90 -0
  100. package/data/seed/mappings/nist-csf-cybersecurity-act.json +90 -0
  101. package/data/seed/mappings/nist-csf-data-act.json +50 -0
  102. package/data/seed/mappings/nist-csf-dga.json +58 -0
  103. package/data/seed/mappings/nist-csf-dma.json +42 -0
  104. package/data/seed/mappings/nist-csf-dora.json +210 -0
  105. package/data/seed/mappings/nist-csf-dsa.json +82 -0
  106. package/data/seed/mappings/nist-csf-eecc.json +90 -0
  107. package/data/seed/mappings/nist-csf-ehds.json +98 -0
  108. package/data/seed/mappings/nist-csf-eidas2.json +114 -0
  109. package/data/seed/mappings/nist-csf-eprivacy.json +58 -0
  110. package/data/seed/mappings/nist-csf-eu_taxonomy.json +34 -0
  111. package/data/seed/mappings/nist-csf-eucc.json +66 -0
  112. package/data/seed/mappings/nist-csf-eudr.json +58 -0
  113. package/data/seed/mappings/nist-csf-gdpr.json +178 -0
  114. package/data/seed/mappings/nist-csf-gpsr.json +58 -0
  115. package/data/seed/mappings/nist-csf-ivdr.json +66 -0
  116. package/data/seed/mappings/nist-csf-led.json +74 -0
  117. package/data/seed/mappings/nist-csf-machinery.json +58 -0
  118. package/data/seed/mappings/nist-csf-mdr.json +66 -0
  119. package/data/seed/mappings/nist-csf-mica.json +98 -0
  120. package/data/seed/mappings/nist-csf-mifid2.json +74 -0
  121. package/data/seed/mappings/nist-csf-mifir.json +50 -0
  122. package/data/seed/mappings/nist-csf-nis2.json +194 -0
  123. package/data/seed/mappings/nist-csf-pld.json +34 -0
  124. package/data/seed/mappings/nist-csf-psd2.json +98 -0
  125. package/data/seed/mappings/nist-csf-red.json +58 -0
  126. package/data/seed/mappings/nist-csf-sfdr.json +42 -0
  127. package/data/seed/mappings/nist-csf-un-r155.json +130 -0
  128. package/data/seed/mappings/nist-csf-un-r156.json +98 -0
  129. package/data/seed/mdr.json +1066 -0
  130. package/data/seed/mica.json +1003 -0
  131. package/data/seed/mifid2.json +906 -0
  132. package/data/seed/mifir.json +512 -0
  133. package/data/seed/pld.json +244 -0
  134. package/data/seed/psd2.json +827 -0
  135. package/data/seed/red.json +452 -0
  136. package/data/seed/sfdr.json +228 -0
  137. package/data/seed/un-r155.json +166 -0
  138. package/data/seed/un-r156.json +150 -0
  139. package/dist/http-server.d.ts +9 -0
  140. package/dist/http-server.d.ts.map +1 -0
  141. package/dist/http-server.js +342 -0
  142. package/dist/http-server.js.map +1 -0
  143. package/dist/index.js +4 -4
  144. package/dist/index.js.map +1 -1
  145. package/dist/tools/map.d.ts +1 -1
  146. package/dist/tools/map.d.ts.map +1 -1
  147. package/dist/tools/map.js +3 -3
  148. package/dist/tools/map.js.map +1 -1
  149. package/package.json +8 -3
  150. package/scripts/build-db.ts +20 -8
  151. package/scripts/check-updates.ts +141 -39
  152. package/scripts/ingest-eurlex.ts +9 -1
  153. package/scripts/ingest-unece.ts +368 -0
  154. package/src/http-server.ts +380 -0
  155. package/src/index.ts +4 -4
  156. package/src/tools/map.ts +4 -4
@@ -0,0 +1,386 @@
1
+ {
2
+ "id": "EUCC",
3
+ "full_name": "EU Common Criteria Cybersecurity Certification",
4
+ "celex_id": "32024R0482",
5
+ "effective_date": "2024-02-27",
6
+ "eur_lex_url": "https://eur-lex.europa.eu/eli/reg_impl/2024/482/oj",
7
+ "articles": [
8
+ {
9
+ "number": "1",
10
+ "title": "Subject matter and scope",
11
+ "text": "This Regulation sets out the European Common Criteria-based cybersecurity certification scheme (EUCC).\n\nThis Regulation applies to all information and communication technologies (‘ICT’) products, including their documentation, which are submitted for certification under the EUCC, and to all protection profiles which are submitted for certification as part of the ICT process leading to the certification of ICT products.",
12
+ "chapter": "I"
13
+ },
14
+ {
15
+ "number": "2",
16
+ "title": "Definitions",
17
+ "text": "For the purposes of this Regulation, the following definitions shall apply:\n\n(1)\n\n‘Common Criteria’ mean the Common Criteria for Information Technology Security Evaluation, as set out in ISO standard ISO/IEC 15408;\n\n(2)\n\n‘Common Evaluation Methodology’ means the Common Methodology for Information Technology Security Evaluation, as set out in ISO/IEC standard ISO/IEC 18045;\n\n(3)\n\n‘target of evaluation’ means an ICT product or part thereof, or a protection profile as part of an ICT process, which is subjected to cybersecurity evaluation to receive EUCC certification;\n\n(4)\n\n‘security target’ means a claim of implementation-dependent security requirements for a specific ICT product;\n\n(5)\n\n‘protection profile’ means an ICT process that lays down the security requirements for a specific category of ICT products, addressing implementation-independent security needs, and that may be used to assess ICT products falling into that specific category for the purpose of their certification;\n\n(6)\n\n‘evaluation technical report’ means a document produced by an ITSEF to present the findings, verdicts and justifications obtained during the evaluation of an ICT product or a protection profile in accordance with the rules and obligations set out in this Regulation;\n\n(7)\n\n‘ITSEF’ means an Information Technology Security Evaluation Facility, which is a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008 that performs evaluation tasks;\n\n(8)\n\n‘AVA_VAN level’ means an assurance vulnerability analysis level that indicates the degree of cybersecurity evaluation activities carried out to determine the level of resistance against potential exploitability of flaws or weaknesses in the target of evaluation in its operational environment as set out in the Common Criteria;\n\n(9)\n\n‘EUCC certificate’ means a cybersecurity certificate issued under the EUCC for ICT products, or for protection profiles that can be used exclusively in the ICT process of certification of ICT products;\n\n(10)\n\n‘composite product’ means an ICT product that is evaluated together with another underlying ICT product that has already received an EUCC certificate and on whose security functionality the composite ICT product depends;\n\n(11)\n\n‘national cybersecurity certification authority’ means an authority designated by a Member State pursuant to Article 58(1) of Regulation (EU) 2019/881;\n\n(12)\n\n‘certification body’ means a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008, which performs certification activities;\n\n(13)\n\n‘technical domain’ means a common technical framework related to a particular technology for the harmonised certification with a set of characteristic security requirements;\n\n(14)\n\n‘state-of-the-art document’ means a document which specifies evaluation methods, techniques and tools that apply to the certification of ICT products, or security requirements of a generic ICT product category, or any other requirements necessary for certification, in order to harmonise evaluation, in particular of technical domains or protection profiles;\n\n(15)\n\n‘market surveillance authority’ means an authority defined in Article 3(4) of Regulation (EU) 2019/1020.",
18
+ "chapter": "I"
19
+ },
20
+ {
21
+ "number": "3",
22
+ "title": "Evaluation standards",
23
+ "text": "The following standards shall apply to evaluations performed under the EUCC scheme:\n\n(a)\n\nthe Common Criteria;\n\n(b)\n\nthe Common Evaluation Methodology.",
24
+ "chapter": "I"
25
+ },
26
+ {
27
+ "number": "4",
28
+ "title": "Assurance levels",
29
+ "text": "1.   Certification bodies shall issue EUCC certificates at assurance level ‘substantial’ or ‘high’.\n\n2.   EUCC certificates at assurance level ‘substantial’ shall correspond to certificates that cover AVA_VAN level 1 or 2.\n\n3.   EUCC certificates at assurance level ‘high’ shall correspond to certificates that cover AVA_VAN level 3, 4 or 5.\n\n4.   The assurance level confirmed in a EUCC certificate shall distinguish between the conformant and augmented use of the assurance components as specified in the Common Criteria in accordance with Annex VIII.\n\n5.   Conformity assessment bodies shall apply those assurance components on which the selected AVA_VAN level depends in accordance with the standards referred to in Article 3.",
30
+ "chapter": "I"
31
+ },
32
+ {
33
+ "number": "5",
34
+ "title": "Methods for certifying ICT products",
35
+ "text": "1.   Certification of an ICT product shall be carried out against its security target:\n\n(a)\n\nas defined by the applicant; or\n\n(b)\n\nincorporating a certified protection profile as part of the ICT process, where the ICT product falls in the ICT product category covered by that protection profile.\n\n2.   Protection profiles shall be certified for the sole purpose of the certification of ICT products falling in the specific category of ICT products covered by the protection profile.",
36
+ "chapter": "I"
37
+ },
38
+ {
39
+ "number": "6",
40
+ "title": "Conformity self-assessment",
41
+ "text": "A conformity self-assessment within the meaning of Article 53 of Regulation (EU) 2019/881 shall not be permitted.\n\nCERTIFICATION OF ICT PRODUCTS\n\nSECTION I\n\nSpecific standards and requirements for evaluation",
42
+ "chapter": "II"
43
+ },
44
+ {
45
+ "number": "7",
46
+ "title": "Evaluation criteria and methods for ICT products",
47
+ "text": "1.   An ICT product submitted for certification shall, as a minimum, be evaluated in accordance with the following:\n\n(a)\n\nthe applicable elements of the standards referred to in Article 3;\n\n(b)\n\nthe security assurance requirements classes for vulnerability assessment and independent functional testing, as set out in the evaluation standards referred to in Article 3;\n\n(c)\n\nthe level of risk associated with the intended use of the ICT products concerned pursuant to Article 52 of Regulation (EU) 2019/881 and their security functions that support the security objectives set out in Article 51 of Regulation (EU) 2019/881;\n\n(d)\n\nthe applicable state-of-the-art documents listed in Annex I; and\n\n(e)\n\nthe applicable certified protection profiles listed in Annex II.\n\n2.   In exceptional and duly justified cases, a conformity assessment body may request to refrain from applying the relevant state-of-the-art document. In such cases the conformity assessment body shall inform the national cybersecurity certification authority with a duly reasoned justification for its request. The national cybersecurity certification authority shall assess the justification for an exception and, where justified, approve it. Pending the decision of the national cybersecurity certification authority, the conformity assessment body shall not issue any certificate. The national cybersecurity certification authority shall notify the approved exception, without undue delay, to the European Cybersecurity Certification Group, which may issue an opinion. The national cybersecurity certification authority shall take utmost account of the opinion of the European Cybersecurity Certification Group.\n\n3.   Certification of ICT products at AVA_VAN level 4 or 5 shall only be possible in the following scenarios:\n\n(a)\n\nwhere the ICT product is covered by any technical domain listed in Annex I, it shall be evaluated in accordance with the applicable state-of-the-art documents of those technical domains,\n\n(b)\n\nwhere the ICT product falls into a category of ICT products covered by a certified protection profile that includes AVA_VAN levels 4 or 5 and that has been listed as a state-of-the-art protection profile in Annex II, it shall be evaluated in accordance with the evaluation methodology specified for that protection profile,\n\n(c)\n\nwhere points a) and b) of this paragraph are not applicable and where the inclusion of a technical domain in Annex I or of a certified protection profile in Annex II is unlikely in the foreseeable future, and only in exceptional and duly justified cases, subject to the conditions set out in paragraph 4.\n\n4.   Where a conformity assessment body considers to be in an exceptional and duly justified case referred to in point c) of paragraph 3, it shall notify the intended certification to the national cybersecurity certification authority with a justification and a proposed evaluation methodology. The national cybersecurity certification authority shall assess the justification for an exception and, where justified, approve or amend the evaluation methodology to be applied by the conformity assessment body. Pending the decision of the national cybersecurity certification authority, the conformity assessment body shall not issue any certificate. The national cybersecurity certification authority shall report, without undue delay, the intended certification to the European Cybersecurity Certification Group, which may issue an opinion. The national cybersecurity certification authority shall take utmost account of the opinion of the European Cybersecurity Certification Group.\n\n5.   In the case of an ICT product undergoing a composite product evaluation in accordance with the relevant state-of-the-art documents, the ITSEF that carried out the evaluation of the underlying ICT product shall share the relevant information with the ITSEF performing the evaluation of the composite ICT product.\n\nSECTION II\n\nIssuance, renewal and withdrawal of EUCC certificates",
48
+ "chapter": "II"
49
+ },
50
+ {
51
+ "number": "8",
52
+ "title": "Information necessary for certification",
53
+ "text": "1.   An applicant for certification under EUCC shall provide or otherwise make available to the certification body and the ITSEF all information necessary for the certification activities.\n\n2.   The information referred to in paragraph 1 shall include all relevant evidence in accordance with the sections on ‘Developer action elements’ in the appropriate format as set out in the sections on ‘Content and presentation of evidence element’ of the Common Criteria and Common Evaluation Methodology for the selected assurance level and associated security assurance requirements. The evidence shall include, where necessary, details on the ICT product and its source code in accordance with this Regulation, subject to safeguards against unauthorised disclosure.\n\n3.   Applicants for certification may provide to the certification body and ITSEF appropriate evaluation results from prior certification pursuant to:\n\n(a)\n\nthis Regulation;\n\n(b)\n\nanother European cybersecurity certification scheme adopted pursuant to Article 49 of Regulation (EU) 2019/881;\n\n(c)\n\na national scheme referred to in Article 49 of this Regulation.\n\n4.   Where the evaluation results are pertinent to its tasks, the ITSEF may reuse the evaluation results provided that such results conform to the applicable requirements and its authenticity is confirmed.\n\n5.   Where the certification body allows the product to undergo a composite product certification, the applicant for certification shall make available to the certification body and the ITSEF all necessary elements, where applicable, in accordance with the state-of-the-art document.\n\n6.   Applicants for certification shall also provide the certification body and the ITSEF with the following information:\n\n(a)\n\nthe link to their website containing the supplementary cybersecurity information referred to in Article 55 of Regulation (EU) 2019/881;\n\n(b)\n\na description of the applicant’s vulnerability management and vulnerability disclosure procedures.\n\n7.   All relevant documentation referred to in this Article shall be retained by the certification body, the ITSEF and the applicant for a period of 5 years after the expiry of the certificate.",
54
+ "chapter": "II"
55
+ },
56
+ {
57
+ "number": "9",
58
+ "title": "Conditions for issuance of an EUCC certificate",
59
+ "text": "1.   The certification bodies shall issue an EUCC certificate where all of the following conditions are met:\n\n(a)\n\nthe category of ICT product falls within the scope of the accreditation, and where applicable of the authorisation, of the certification body and the ITSEF involved in the certification;\n\n(b)\n\nthe applicant for certification has signed a statement undertaking all commitments listed in paragraph 2;\n\n(c)\n\nthe ITSEF has concluded the evaluation without objection in accordance with the evaluation standards, criteria and methods referred to in Articles 3 and 7;\n\n(d)\n\nthe certification body has concluded the review of the evaluation results without objection;\n\n(e)\n\nthe certification body has verified that the evaluation technical reports provided by the ITSEF are consistent with the provided evidence and that the evaluation standards, criteria and methods referred to in Articles 3 and 7 have been correctly applied.\n\n2.   The applicant for certification shall undertake the following commitments:\n\n(a)\n\nto provide the certification body and the ITSEF with all the necessary complete and correct information, and to provide additional necessary information if requested;\n\n(b)\n\nnot to promote the ICT product as being certified under the EUCC before the EUCC certificate has been issued;\n\n(c)\n\nto promote the ICT product as being certified only with respect to the scope set out in the EUCC certificate;\n\n(d)\n\nto cease immediately the promotion of the ICT product as being certified in the event of the suspension, withdrawal or expiry of the EUCC certificate;\n\n(e)\n\nto ensure that the ICT products sold with reference to the EUCC certificate are strictly identical to the ICT product subject to the certification;\n\n(f)\n\nto respect the rules of use of the mark and label established for the EUCC certificate in accordance with Article 11.\n\n3.   In the case of an ICT product undergoing a composite product certification, in accordance with the relevant state-of-the-art documents, the certification body that carried out the certification of the underlying ICT product shall share the relevant information with the certification body performing the certification of the composite ICT product.",
60
+ "chapter": "II"
61
+ },
62
+ {
63
+ "number": "10",
64
+ "title": "Content and format of an EUCC certificate",
65
+ "text": "1.   An EUCC certificate shall include at least the information set out in Annex VII.\n\n2.   The scope and boundaries of the certified ICT product shall be unambiguously specified in the EUCC certificate or the certification report, indicating whether the entire ICT product has been certified or only parts thereof.\n\n3.   The certification body shall provide the applicant with the EUCC certificate at least in electronic form.\n\n4.   The certification body shall produce a certification report in accordance with Annex V for each EUCC certificate it issues. The certification report shall be based on the evaluation technical report issued by the ITSEF. The evaluation technical report and the certification report shall indicate the specific evaluation criteria and methods referred to in Article 7 used for the evaluation.\n\n5.   The certification body shall provide the national cybersecurity certification authority and ENISA with every EUCC certificate and every certification report in electronic form.",
66
+ "chapter": "II"
67
+ },
68
+ {
69
+ "number": "11",
70
+ "title": "Mark and label",
71
+ "text": "1.   The holder of a certificate may affix a mark and label to a certified ICT product. Mark and label demonstrate that the ICT product has been certified in accordance with this Regulation. Mark and label shall be affixed in accordance with this Article and with Annex IX.\n\n2.   The mark and label shall be affixed visibly, legibly and indelibly to the certified ICT product or its data plate. Where that is not possible or not warranted on account of the nature of the product, it shall be affixed to the packaging and to the accompanying documents. Where the certified ICT product is delivered in the form of software, the mark and label shall visibly, legibly and indelibly appear in its accompanying documentation or this documentation shall be made easily and directly accessible to users by means of a website.\n\n3.   The mark and label shall be set out as in Annex IX and contain:\n\n(a)\n\nthe assurance level and the AVA_VAN level of the certified ICT product;\n\n(b)\n\nthe unique identification of the certificate, consisting of:\n\n(1)\n\nthe name of the scheme;\n\n(2)\n\nthe name and the reference number of the accreditation of the certification body that has issued the certificate;\n\n(3)\n\nyear and month of issuance;\n\n(4)\n\nidentification number assigned by the certification body that has issued the certificate.\n\n4.   The mark and label shall be accompanied by a QR code with a link to a website containing at least:\n\n(a)\n\nthe information on the validity of the certificate;\n\n(b)\n\nthe necessary certification information as set out in Annexes V and VII;\n\n(c)\n\nthe information to be made publicly available by the holder of the certificate in accordance with Article 55 of Regulation (EU) 2019/881; and\n\n(d)\n\nwhere applicable, the historic information related to the specific certification or certifications of the ICT product to enable traceability.",
72
+ "chapter": "II"
73
+ },
74
+ {
75
+ "number": "12",
76
+ "title": "Period of validity of an EUCC certificate",
77
+ "text": "1.   The certification body shall set a period of validity for each EUCC certificate issued taking into account the characteristics of the certified ICT product.\n\n2.   The period of validity of the EUCC certificate shall not exceed 5 years.\n\n3.   By derogation from paragraph 2 that period may exceed 5 years, subject to the prior approval of the national cybersecurity certification authority. The national cybersecurity certification authority shall notify the European Cybersecurity Certification Group of the granted approval without undue delay.",
78
+ "chapter": "II"
79
+ },
80
+ {
81
+ "number": "13",
82
+ "title": "Review of an EUCC certificate",
83
+ "text": "1.   Upon request of the holder of the certificate or for other justified reasons, the certification body may decide to review the EUCC certificate for an ICT product. The review shall be carried out in accordance with Annex IV. The certification body shall determine the extent of the review. Where necessary for the review, the certification body shall request the ITSEF to perform a re-evaluation of the certified ICT product.\n\n2.   Following the results of the review, and where applicable of the re-evaluation, the certification body shall:\n\n(a)\n\nconfirm the EUCC certificate;\n\n(b)\n\nwithdraw the EUCC certificate in accordance with Article 14;\n\n(c)\n\nwithdraw the EUCC certificate in accordance with Article 14 and issue a new EUCC certificate with an identical scope and an extended validity period; or\n\n(d)\n\nwithdraw the EUCC certificate in accordance with Article 14 and issue a new EUCC certificate with a different scope.\n\n3.   The certification body may decide to suspend, without undue delay, the EUCC certificate in accordance with Article 30, pending remedial action by the holder of the EUCC certificate.",
84
+ "chapter": "II"
85
+ },
86
+ {
87
+ "number": "14",
88
+ "title": "Withdrawal of an EUCC certificate",
89
+ "text": "1.   Without prejudice to Article 58(8), point (e), of Regulation (EU) 2019/881, an EUCC certificate shall be withdrawn by the certification body that issued that certificate.\n\n2.   The certification body referred to in paragraph 1 shall notify the national cybersecurity certification authority of the withdrawal of the certificate. It shall also notify ENISA of such withdrawal in view of facilitating the performance of its task under Article 50 of Regulation (EU) 2019/881. The national cybersecurity certification authority shall notify other relevant market surveillance authorities.\n\n3.   The holder of an EUCC certificate may request the withdrawal of the certificate.\n\nCERTIFICATION OF PROTECTION PROFILES\n\nSECTION I\n\nSpecific standards and requirements for evaluation",
90
+ "chapter": "III"
91
+ },
92
+ {
93
+ "number": "15",
94
+ "title": "Evaluation criteria and methods",
95
+ "text": "1.   A protection profile shall be evaluated, as a minimum, in accordance with the following:\n\n(a)\n\nthe applicable elements of the standards referred to in Article 3;\n\n(b)\n\nthe level of risk associated with the intended use of the ICT products concerned pursuant to Article 52 of Regulation (EU) 2019/881 and their security functions that support the security objectives set out in Article 51 of that; and\n\n(c)\n\nthe applicable state-of-the-art documents listed in Annex I. A protection profile covered by a technical domain shall be certified against the requirements set out in that technical domain.\n\n2.   In exceptional and duly justified cases, a conformity assessment body may certify a protection profile without applying the relevant state-of-the-art documents. In such cases, it shall inform the competent national cybersecurity certification authority and provide a justification for the intended certification without application of the relevant state-of-the-art documents as well as the proposed evaluation methodology. The national cybersecurity certification authority shall assess the justification and, where justified, approve the non-application of the relevant state-of-the-art documents, and approve or amend, where appropriate, the evaluation methodology to be applied by the conformity assessment body. Pending the decision of the national cybersecurity certification authority, the conformity assessment body shall not issue any certificate for the protection profile. The national cybersecurity certification authority shall notify, without undue delay, the authorised non-application of the relevant state-of-the-art documents to the European Cybersecurity Certification Group, which may issue an opinion. The national cybersecurity certification authority shall take utmost account of the opinion of the European Cybersecurity Certification Group.\n\nSECTION II\n\nIssuing, renewing and withdrawing EUCC certificates for protection profiles",
96
+ "chapter": "III"
97
+ },
98
+ {
99
+ "number": "16",
100
+ "title": "Information necessary for certification of protection profiles",
101
+ "text": "An applicant for certification of a protection profile shall provide or otherwise make available to the certification body and the ITSEF all information necessary for the certification activities. Article 8(2), (3), (4) and (7) shall apply mutatis mutandis.",
102
+ "chapter": "III"
103
+ },
104
+ {
105
+ "number": "17",
106
+ "title": "Issuance of EUCC certificates for protection profiles",
107
+ "text": "1.   The applicant for certification shall provide the certification body and the ITSEF with all the necessary complete and correct information.\n\n2.   Articles 9 and 10 shall apply mutatis mutandis.\n\n3.   The ITSEF shall evaluate whether a protection profile is complete, consistent, technically sound and effective for the intended use and the security objectives of the ICT product’s category covered by that protection profile.\n\n4.   A protection profile shall be certified solely by:\n\n(a)\n\na national cybersecurity certification authority or another public body accredited as certification body; or\n\n(b)\n\na certification body, upon prior approval by the national cybersecurity certification authority for each individual protection profile.",
108
+ "chapter": "III"
109
+ },
110
+ {
111
+ "number": "18",
112
+ "title": "Period of validity of an EUCC certificate for protection profiles",
113
+ "text": "1.   The certification body shall set a period of validity for each EUCC certificate.\n\n2.   The period of validity may be up to the lifetime of the protection profile concerned.",
114
+ "chapter": "III"
115
+ },
116
+ {
117
+ "number": "19",
118
+ "title": "Review of an EUCC certificate for protection profiles",
119
+ "text": "1.   Upon request of the holder of the certificate or for other justified reasons, the certification body may decide to review an EUCC certificate for a protection profile. The review shall be carried out by applying the conditions set out in Article 15. The certification body shall determine the extent of the review. Where necessary for the review, the certification body shall request the ITSEF to perform a re-evaluation of the certified protection profile.\n\n2.   Following the results of the review, and where applicable of the re-evaluation, the certification body shall do one of the following:\n\n(a)\n\nconfirm the EUCC certificate;\n\n(b)\n\nwithdraw the EUCC certificate in accordance with Article 20;\n\n(c)\n\nwithdraw the EUCC certificate in accordance with Article 20 and issue a new EUCC certificate with an identical scope and an extended validity period;\n\n(d)\n\nwithdraw the EUCC certificate in accordance with Article 20 and issue a new EUCC certificate with a different scope.",
120
+ "chapter": "III"
121
+ },
122
+ {
123
+ "number": "20",
124
+ "title": "Withdrawal of an EUCC certificate for a protection profile",
125
+ "text": "1.   Without prejudice to Article 58(8), point (e) of Regulation (EU) 2019/881, an EUCC certificate for a protection profile shall be withdrawn by the certification body that issued that certificate. Article 14 shall apply mutatis mutandis.\n\n2.   A certificate for a protection profile issued in accordance with Article 17(4), point (b) shall be withdrawn by the national cybersecurity certification authority that approved that certificate.\n\nCONFORMITY ASSESSMENT BODIES",
126
+ "chapter": "IV"
127
+ },
128
+ {
129
+ "number": "21",
130
+ "title": "Additional or specific requirements for a certification body",
131
+ "text": "1.   A certification body shall be authorised by the national cybersecurity certification authority to issue EUCC certificates at assurance level ‘high’ where that body demonstrates that, in addition to meeting the requirements laid down in Article 60(1) and the Annex to Regulation (EU) 2019/881 regarding accreditation of conformity assessment bodies, the following:\n\n(a)\n\nit has the expertise and competences required for the certification decision at assurance level ‘high’;\n\n(b)\n\nit conducts its certification activities in cooperation with an ITSEF authorised in accordance with Article 22; and\n\n(c)\n\nit has the requisite competences and put in place appropriate technical and operational measures to effectively protect confidential and sensitive information for assurance level ‘high’, in addition to the requirements set out in Article 43.\n\n2.   The national cybersecurity certification authority shall assess whether a certification body fulfils all the requirements set out in paragraph 1. That assessment shall include at least structured interviews and a review of at least one pilot certification performed by the certification body in accordance with this Regulation.\n\nIn its assessment, the national cybersecurity certification authority may reuse any appropriate evidence from prior authorisation or similar activities granted pursuant to:\n\n(a)\n\nthis Regulation;\n\n(b)\n\nanother European cybersecurity certification scheme adopted pursuant to Article 49 of Regulation (EU) 2019/881;\n\n(c)\n\na national scheme referred to in Article 49 of this Regulation.\n\n3.   The national cybersecurity certification authority shall produce an authorisation report which is subject to peer review in accordance with Article 59(3), point (d), of Regulation (EU) 2019/881.\n\n4.   The national cybersecurity certification authority shall specify the ICT product categories and protection profiles to which the authorisation extends. The authorisation shall be valid for a period no longer than the validity of the accreditation. It may be renewed upon request provided that the certification body still meets the requirements set out in this Article. For the renewal of the authorisation, no pilot evaluations are required.\n\n5.   The national cybersecurity certification authority shall withdraw the authorisation of the certification body where it no longer meets the conditions set out in this Article. Upon withdrawal of the authorisation, the certification body shall cease immediately promoting itself as an authorised certification body.",
132
+ "chapter": "IV"
133
+ },
134
+ {
135
+ "number": "22",
136
+ "title": "Additional or specific requirements for an ITSEF",
137
+ "text": "1.   An ITSEF shall be authorised by the national cybersecurity certification authority to carry out the evaluation of ICT products which are subject to certification under the assurance level ‘high’, where the ITSEF demonstrates that, in addition to meeting the requirements laid down in Article 60(1) and the Annex to Regulation (EU) 2019/881 regarding accreditation of conformity assessment bodies, it complies with all of the following conditions:\n\n(a)\n\nit has the necessary expertise for performing the evaluation activities to determine the resistance to state-of-the-art cyberattacks carried out by actors with significant skills and resources;\n\n(b)\n\nfor the technical domains and protection profiles, which are part of the ICT process for those ICT products, it has:\n\n(1)\n\nthe expertise to perform the specific evaluation activities necessary to methodically determine a target of evaluation’s resistance against skilled attackers in its operational environment assuming an attack potential of ‘moderate’ or ‘high’ as set out in the standards referred to in Article 3;\n\n(2)\n\nthe technical competences as specified in the state-of-the-art documents listed in Annex I;\n\n(c)\n\nit has the requisite competences and put in place appropriate technical and operational measures to effectively protect confidential and sensitive information for assurance level ’high’ in addition to the requirements set out in Article 43.\n\n2.   The national cybersecurity certification authority shall assess whether an ITSEF fulfils all the requirements set out in paragraph 1. That assessment shall include at least structured interviews and a review of at least one pilot evaluation performed by the ITSEF in accordance with this Regulation.\n\n3.   In its assessment, the national cybersecurity certification authority may reuse any appropriate evidence from prior authorisation or similar activities granted pursuant to:\n\n(a)\n\nthis Regulation;\n\n(b)\n\nanother European cybersecurity certification scheme adopted pursuant to Article 49 of Regulation (EU) 2019/881;\n\n(c)\n\na national scheme referred to in Article 49 of this Regulation.\n\n4.   The national cybersecurity certification authority shall produce an authorisation report which is subject to peer review in accordance with Article 59(3), point (d) of Regulation (EU) 2019/881.\n\n5.   The national cybersecurity certification authority shall specify the ICT product categories and protection profiles to which the authorisation extends. The authorisation shall be valid for period no longer than the validity of the accreditation. It may be renewed upon request provided that the ITSEF still meets the requirements set out in this Article. For the renewal of the authorisation, no pilot evaluations should be required.\n\n6.   The national cybersecurity certification authority shall withdraw the authorisation of the ITSEF where it no longer meets the conditions set out in this Article. Upon withdrawal of the authorisation, the ITSEF shall stop promoting itself as being an authorised ITSEF.",
138
+ "chapter": "IV"
139
+ },
140
+ {
141
+ "number": "23",
142
+ "title": "Notification of certification bodies",
143
+ "text": "1.   The national cybersecurity certification authority shall notify the Commission of the certification bodies in its territory that are competent to certify at assurance level ‘substantial’ based on their accreditation.\n\n2.   The national cybersecurity certification authority shall notify the Commission of the certification bodies in their territory that are competent to certify at assurance level ‘high’ based on their accreditation and the authorisation decision.\n\n3.   The national cybersecurity certification authority shall provide at least the following information when notifying the Commission of the certification bodies:\n\n(a)\n\nthe assurance level or levels for which the certification body is competent to issue EUCC certificates;\n\n(b)\n\nthe following information related to accreditation:\n\n(1)\n\ndate of the accreditation;\n\n(2)\n\nname and address of the certification body;\n\n(3)\n\ncountry of registration of the certification body;\n\n(4)\n\nreference number of the accreditation;\n\n(5)\n\nscope and duration of validity of the accreditation;\n\n(6)\n\nthe address, location and link to the relevant website of the national accreditation body; and\n\n(c)\n\nthe following information related to authorisation for level ‘high’:\n\n(1)\n\ndate of the authorisation;\n\n(2)\n\nreference number of the authorisation;\n\n(3)\n\nduration of validity of the authorisation;\n\n(4)\n\nscope of the authorisation including the highest AVA_VAN level and, where applicable, the covered technical domain.\n\n4.   The national cybersecurity certification authority shall send a copy of the notification referred to in paragraphs 1 and 2 to ENISA for the publication of accurate information on the cybersecurity certification website regarding the eligibility of certification bodies.\n\n5.   The national cybersecurity certification authority shall examine without undue delay any information regarding a change in the status of the accreditation provided by the national accreditation body. Where the accreditation or authorisation have been withdrawn, the national cybersecurity certification authority shall inform the Commission thereof, and may submit to the Commission a request in accordance with Article 61(4) of Regulation (EU) 2019/881.",
144
+ "chapter": "IV"
145
+ },
146
+ {
147
+ "number": "24",
148
+ "title": "Notification of ITSEF",
149
+ "text": "The notification obligations of the national cybersecurity certification authorities set out in Article 23 shall also apply to ITSEF. The notification shall include the address of the ITSEF, the valid accreditation and, where applicable, the valid authorisation of that ITSEF.\n\nMONITORING, NON-CONFORMITY AND NON-COMPLIANCE\n\nSECTION I\n\nCompliance monitoring",
150
+ "chapter": "V"
151
+ },
152
+ {
153
+ "number": "25",
154
+ "title": "Monitoring activities by the national cybersecurity certification authority",
155
+ "text": "1.   Without prejudice to Article 58(7) of Regulation (EU) 2019/881, the national cybersecurity certification authority shall monitor the compliance of:\n\n(a)\n\nthe certification body and the ITSEF with their obligations pursuant to this Regulation and Regulation (EU) 2019/881;\n\n(b)\n\nthe holders of an EUCC certificate with their obligations pursuant to this Regulation and Regulation (EU) 2019/881;\n\n(c)\n\nthe certified ICT products with the requirements set out in the EUCC;\n\n(d)\n\nthe assurance expressed in the EUCC certificate addressing the evolving threat landscape.\n\n2.   The national cybersecurity certification authority shall perform its monitoring activities in particular on the basis of:\n\n(a)\n\ninformation coming from certification bodies, national accreditation bodies and relevant market surveillance authorities;\n\n(b)\n\ninformation resulting from its own or another authority’s audits and investigations;\n\n(c)\n\nsampling, carried out in accordance with paragraph 3;\n\n(d)\n\ncomplaints received.\n\n3.   The national cybersecurity certification authority shall, in cooperation with other market surveillance authorities, sample annually at least 4% of the EUCC certificates as determined by a risk assessment. Upon request and acting on behalf of the competent national cybersecurity certification authority, certification bodies and, if necessary, ITSEF shall assist that authority in monitoring compliance.\n\n4.   The national cybersecurity certification authority shall select the sample of certified ICT products to be checked using objective criteria, including:\n\n(a)\n\nproduct category;\n\n(b)\n\nassurance levels of products;\n\n(c)\n\nholder of a certificate;\n\n(d)\n\ncertification body and, where applicable, the subcontracted ITSEF;\n\n(e)\n\nany other information brought to the authority’s attention.\n\n5.   The national cybersecurity certification authority shall inform the holders of the EUCC certificate about the selected ICT products and the selection criteria.\n\n6.   The certification body that certified the sampled ICT product shall, upon request of the national cybersecurity certification authority, with the assistance of the respective ITSEF, conduct additional review in accordance with the procedure laid down in Section IV.2 of Annex IV and inform the national cybersecurity certification authority of the results.\n\n7.   Where the national cybersecurity certification authority has sufficient reason to believe that a certified ICT product is no longer in compliance with this Regulation or Regulation (EU) 2019/881, it may carry out investigations or make use of any other monitoring powers set out in Article 58(8) of Regulation (EU) 2019/881.\n\n8.   The national cybersecurity certification authority shall inform the certification body and ITSEF concerned about ongoing investigations regarding selected ICT products.\n\n9.   Where the national cybersecurity certification authority identifies that an ongoing investigation concerns ICT products that are certified by certification bodies established in other Member States, it shall inform thereof the national cybersecurity certification authorities of the relevant Member States in order to collaborate in the investigations, where relevant. Such national cybersecurity certification authority shall also notify the European Cybersecurity Certification Group of the cross-border investigations and the subsequent results.",
156
+ "chapter": "V"
157
+ },
158
+ {
159
+ "number": "26",
160
+ "title": "Monitoring activities by the certification body",
161
+ "text": "1.   The certification body shall monitor:\n\n(a)\n\nthe compliance of the holders of a certificate with their obligations under this Regulation and Regulation (EU) 2019/881 towards the EUCC certificate that was issued by the certification body;\n\n(b)\n\nthe compliance of the ICT products it has certified with their respective security requirements;\n\n(c)\n\nthe assurance expressed in the certified protection profiles.\n\n2.   The certification body shall undertake its monitoring activities on the basis of:\n\n(a)\n\nthe information provided on the basis of the commitments of the applicant for certification referred to in Article 9(2);\n\n(b)\n\ninformation resulting from activities of other relevant market surveillance authorities;\n\n(c)\n\ncomplaints received;\n\n(d)\n\nvulnerability information that could impact the ICT products it has certified.\n\n3.   The national cybersecurity certification authority may draw up rules for a periodical dialogue between certification bodies and holders of EUCC certificates to verify and report on compliance with the commitments made pursuant to Article 9(2), without prejudice to activities related to other relevant market surveillance authorities.",
162
+ "chapter": "V"
163
+ },
164
+ {
165
+ "number": "27",
166
+ "title": "Monitoring activities by the holder of the certificate",
167
+ "text": "1.   The holder of an EUCC certificate shall perform the following tasks to monitor the conformity of the certified ICT product with its security requirements:\n\n(a)\n\nmonitor vulnerability information regarding the certified ICT product, including known dependencies by its own means but also in consideration of:\n\n(1)\n\na publication or a submission regarding vulnerability information by a user or security researcher referred to in Article 55(1), point (c) of Regulation (EU) 2019/881;\n\n(2)\n\na submission by any other source;\n\n(b)\n\nmonitor the assurance expressed in the EUCC certificate.\n\n2.   The holder of an EUCC certificate shall work in cooperation with the certification body, the ITSEF, and, where applicable, the national cybersecurity certification authority to support their monitoring activities.\n\nSECTION II\n\nConformity and compliance",
168
+ "chapter": "V"
169
+ },
170
+ {
171
+ "number": "28",
172
+ "title": "Consequences of non-conformity of a certified ICT product or protection profile",
173
+ "text": "1.   Where a certified ICT product or protection profile does not conform with the requirements laid down in this Regulation and in Regulation (EU) 2019/881, the certification body shall inform the holder of the EUCC certificate about the identified non-conformity and request remedial actions.\n\n2.   Where an instance of non-conformity with the provisions of this Regulation might affect compliance with other relevant Union legislation, which provides for the possibility to demonstrate the presumption of conformity with the requirements of that legal act by using the EUCC certificate, the certification body shall inform the national cybersecurity certification authority without delay. The national cybersecurity certification authority shall immediately notify the market surveillance authority responsible for such other relevant Union legislation regulation about the instance of non-conformity identified.\n\n3.   Upon receipt of the information referred to in paragraph 1, the holder of the EUCC certificate shall within the time period set by the certification body, which shall not exceed 30 days, propose to the certification body the remedial action necessary to address the non-conformity.\n\n4.   The certification body may suspend, without undue delay, the EUCC certificate in accordance with Article 30 in case of emergency, or where the holder of the EUCC certificate does not duly cooperate with the certification body.\n\n5.   The certification body shall carry out a review in accordance with Articles 13 and 19, assessing whether the remedial action addresses the non-conformity.\n\n6.   Where the holder of the EUCC certificate does not propose appropriate remedial action during the period referred to in paragraph 3, the certificate shall be suspended in accordance with Article 30 or withdrawn in accordance with Articles 14 or 20.\n\n7.   This Article shall not apply to cases of vulnerabilities affecting a certified ICT product, which shall be handled in accordance with Chapter VI.",
174
+ "chapter": "V"
175
+ },
176
+ {
177
+ "number": "29",
178
+ "title": "Consequences of non-compliance by the holder of the certificate",
179
+ "text": "1.   Where the certification body finds that:\n\n(a)\n\nthe holder of the EUCC certificate or the applicant for certification is not compliant with its commitments and obligations as set out in Articles 9(2), 17(2), 27 and 41; or\n\n(b)\n\nthe holder of the EUCC certificate does not comply with Article 56(8) of Regulation (EU) 2019/881 or Chapter VI of this Regulation;\n\nit shall set a time period of not more than 30 days within which the holder of the EUCC certificate shall take remedial action.\n\n2.   Where the holder of the EUCC certificate does not propose appropriate remedial action during the time period referred to in paragraph 1, the certificate shall be suspended in accordance with Article 30 or withdrawn in accordance with Article 14 and Article 20.\n\n3.   Continued or recurring infringement by the holder of the EUCC certificate of the obligations referred to in paragraph 1 shall trigger the withdrawal of the EUCC certificate in accordance with Articles 14 or Article 20.\n\n4.   The certification body shall inform the national cybersecurity certification authority of the findings referred to in paragraph 1. Where the instance of non-compliance affects compliance with other relevant Union legislation, the national cybersecurity certification authority shall immediately notify the market surveillance authority responsible for such other relevant Union legislation about the instance of non-compliance identified.",
180
+ "chapter": "V"
181
+ },
182
+ {
183
+ "number": "30",
184
+ "title": "Suspension of the EUCC certificate",
185
+ "text": "1.   Where this Regulation refers to suspension of an EUCC certificate, the certification body shall suspend an EUCC certificate concerned for a period appropriate to the circumstances triggering suspension, that does not exceed 42 days. The suspension period shall begin on the day following the day of the decision of the certification body. The suspension shall not affect the validity of the certificate.\n\n2.   The certification body shall notify the holder of the certificate and the national cybersecurity certification authority of the suspension without undue delay and shall provide the reasons for the suspension, the requested actions to be taken and the suspension period.\n\n3.   Certification holders shall notify the purchasers of the ICT products concerned about the suspension and the reasons provided by the certification body for the suspension, except those parts of the reasons the sharing of which would constitute a security risk or which contain sensitive information. This information shall also be made publicly available by the holder of the certificate.\n\n4.   Where other relevant Union legislation provides for a presumption of conformity based on certificates issued under the provisions of this Regulation, the national cybersecurity certification authority shall inform the market surveillance authority responsible for such other relevant Union legislation about the suspension.\n\n5.   The suspension of a certificate shall be notified to ENISA in accordance with Article 42(3).\n\n6.   In duly justified cases, the national cybersecurity certification authority may authorise an extension of the period of suspension of an EUCC certificate. The total period of suspension may not exceed 1 year.",
186
+ "chapter": "V"
187
+ },
188
+ {
189
+ "number": "31",
190
+ "title": "Consequences of non-compliance by the conformity assessment body",
191
+ "text": "1.   In case of non-compliance by a certification body with its obligations, or by the relevant certification body in case of identifying non-compliance by an ITSEF, the national cybersecurity certification authority shall, without undue delay:\n\n(a)\n\nidentify, with the support of the concerned ITSEF, the potentially affected EUCC certificates;\n\n(b)\n\nwhere necessary, request evaluation activities to be performed on one or more ICT products or protection profiles by either the ITSEF which performed the evaluation, or any other accredited and, where applicable, authorised ITSEF that may be in a better technical position to support that identification;\n\n(c)\n\nanalyse the impacts of non-compliance;\n\n(d)\n\nnotify the holder of the EUCC certificate affected by non-compliance.\n\n2.   On the basis of the measures referred to in paragraph 1, the certification body shall adopt either of the following decisions with respect to each affected EUCC certificate:\n\n(a)\n\nmaintain the EUCC certificate unaltered;\n\n(b)\n\nwithdraw the EUCC certificate in accordance with Article 14 or Article 20, and, where appropriate, issue a new EUCC certificate.\n\n3.   On the basis of the measures referred to in paragraph 1, the national cybersecurity certification authority shall:\n\n(a)\n\nwhere necessary, report the non-compliance of the certification body or related ITSEF to the national accreditation body;\n\n(b)\n\nwhere applicable, assess the potential impact on the authorisation.\n\nVULNERABILITY MANAGEMENT AND DISCLOSURE",
192
+ "chapter": "VI"
193
+ },
194
+ {
195
+ "number": "32",
196
+ "title": "Scope of vulnerability management",
197
+ "text": "This Chapter applies to ICT products for which an EUCC certificate was issued.\n\nSECTION I\n\nVulnerability management",
198
+ "chapter": "VI"
199
+ },
200
+ {
201
+ "number": "33",
202
+ "title": "Vulnerability management procedures",
203
+ "text": "1.   The holder of an EUCC certificate shall establish and maintain all necessary vulnerability management procedures in accordance with the rules laid down in this Section and, where necessary, supplemented by the procedures set out in EN ISO/IEC 30111.\n\n2.   The holder of an EUCC certificate shall maintain and publish appropriate methods for receiving information on vulnerabilities related to their products from external sources, including users, certification bodies and security researchers.\n\n3.   Where a holder of an EUCC certificate detects or receives information about a potential vulnerability affecting a certified ICT product, it shall record it and carry out a vulnerability impact analysis.\n\n4.   When a potential vulnerability impacts a composite product, the holder of the EUCC certificate shall inform the holder of dependent EUCC certificates about potential vulnerability.\n\n5.   In response to a reasonable request by the certification body that issued the certificate, the holder of an EUCC certificate shall transmit all relevant information about potential vulnerabilities to that certification body.",
204
+ "chapter": "VI"
205
+ },
206
+ {
207
+ "number": "34",
208
+ "title": "Vulnerability impact analysis",
209
+ "text": "1.   Vulnerability impact analysis shall refer to the target of evaluation and the assurance statements contained in the certificate. Vulnerability impact analysis shall be carried out in a timeframe appropriate for the exploitability and criticality of the potential vulnerability of the certified ICT product.\n\n2.   Where applicable, an attack potential calculation shall be performed in accordance with the relevant methodology included in the standards referred to in Article 3 and the relevant state-of-the-art documents listed in Annex I, in order to determine the exploitability of the vulnerability. The AVA_VAN level of the EUCC certificate shall be taken into account.",
210
+ "chapter": "VI"
211
+ },
212
+ {
213
+ "number": "35",
214
+ "title": "Vulnerability impact analysis report",
215
+ "text": "1.   The holder shall produce a vulnerability impact analysis report where the impact analysis shows that the vulnerability has a likely impact on the conformity of the ICT product with its certificate.\n\n2.   The vulnerability impact analysis report shall contain an assessment of the following elements:\n\n(a)\n\nthe impact of the vulnerability on the certified ICT product;\n\n(b)\n\npossible risks associated with the proximity or availability of an attack;\n\n(c)\n\nwhether the vulnerability may be remedied;\n\n(d)\n\nwhere the vulnerability may be remedied, possible resolutions of the vulnerability.\n\n3.   The vulnerability impact analysis report shall, where applicable, contain details about the possible means of exploitation of the vulnerability. Information pertaining to possible means of exploitation of the vulnerability shall be handled in accordance with appropriate security measures to protect its confidentiality and ensure, where necessary, its limited distribution.\n\n4.   The holder of an EUCC certificate shall transmit a vulnerability impact analysis report to the certification body or the national cybersecurity certification authority in accordance with Article 56(8) of Regulation (EU) 2019/881, without undue delay.\n\n5.   Where the vulnerability impact analysis report determines that the vulnerability is not residual within the meaning of standards referred to in Article 3, and that it can be remedied, Article 36 shall apply.\n\n6.   Where the vulnerability impact analysis report determines that the vulnerability is not residual and that it cannot be remedied, the EUCC certificate shall be withdrawn in accordance with Article 14.\n\n7.   The holder of the EUCC certificate shall monitor any residual vulnerabilities to ensure that it cannot be exploited in case of the changes in the operational environment.",
216
+ "chapter": "VI"
217
+ },
218
+ {
219
+ "number": "36",
220
+ "title": "Vulnerability remediation",
221
+ "text": "The holder of an EUCC certificate shall submit a proposal for an appropriate remedial action to the certification body. Certification body shall review the certificate in accordance with Article 13. The scope of the review shall be determined by the proposed remediation of the vulnerability.\n\nSECTION II\n\nVulnerability disclosure",
222
+ "chapter": "VI"
223
+ },
224
+ {
225
+ "number": "37",
226
+ "title": "Information shared with the national cybersecurity certification authority",
227
+ "text": "1.   The information provided by the certification body to the national cybersecurity certification authority shall include all elements necessary for the national cybersecurity certification authority to understand the impact of the vulnerability, the changes to be made to the ICT product and, where available, any information from the certification body on the broader implications of the vulnerability for other certified ICT products.\n\n2.   The information provided in accordance with paragraph 1 shall not contain details of the means of exploitation of the vulnerability. This provision is without prejudice to the investigative powers of the national cybersecurity certification authority.",
228
+ "chapter": "VI"
229
+ },
230
+ {
231
+ "number": "38",
232
+ "title": "Cooperation with other national cybersecurity certification authorities",
233
+ "text": "1.   The national cybersecurity certification authority shall share the relevant information received in accordance with Article 37 with other national cybersecurity certification authorities and ENISA.\n\n2.   Other national cybersecurity certification authorities may decide to further analyse the vulnerability or, after informing the holder of the EUCC certificate, request the relevant certification bodies to assess whether the vulnerability may affect other certified ICT products.",
234
+ "chapter": "VI"
235
+ },
236
+ {
237
+ "number": "39",
238
+ "title": "Publication of the vulnerability",
239
+ "text": "Upon withdrawal of a certificate, the holder of the EUCC certificate shall disclose and register any publicly known and remediated vulnerability in the ICT product on the European vulnerability database, established in accordance with Article 12 of Directive (EU) 2022/2555 of the European Parliament and of the Council (5) or other online repositories referred to in Article 55(1), point (d) of Regulation (EU) 2019/881.\n\nRETENTION, DISCLOSURE AND PROTECTION OF INFORMATION",
240
+ "chapter": "VII"
241
+ },
242
+ {
243
+ "number": "40",
244
+ "title": "Retention of records by certification bodies and the ITSEF",
245
+ "text": "1.   The ITSEF and certification bodies shall maintain a record system, which shall contain all documents produced in connection with each evaluation and certification they perform.\n\n2.   Certification bodies and the ITSEF shall store the records in a secure manner and shall keep those records for the period necessary for the purposes of this Regulation and for at least 5 years after the withdrawal of the relevant EUCC certificate. When the certification body has issued a new EUCC certificate in accordance with Article 13(2), point (c), it shall retain the documentation of the withdrawn EUCC certificate together with and as long as for the new EUCC certificate.",
246
+ "chapter": "VII"
247
+ },
248
+ {
249
+ "number": "41",
250
+ "title": "Information made available by the holder of a certificate",
251
+ "text": "1.   The information referred to in Article 55 of Regulation (EU) 2019/881 shall be available in a language that can be easily accessible to users.\n\n2.   The holder of an EUCC certificate shall store the following securely for the period necessary for the purposes of this Regulation and for at least 5 years after the withdrawal of the relevant EUCC certificate:\n\n(a)\n\nrecords of the information provided to the certification body and to the ITSEF during the certification process;\n\n(b)\n\nspecimen of the certified ICT product.\n\n3.   When the certification body has issued a new EUCC certificate in accordance with Article 13(2), point (c), the holder shall retain the documentation of the withdrawn EUCC certificate together with and as long as for the new EUCC certificate.\n\n4.   Upon request by the certification body or the national cybersecurity certification authority, the holder of an EUCC certificate shall make available the records and copies referred to in paragraph 2.",
252
+ "chapter": "VII"
253
+ },
254
+ {
255
+ "number": "42",
256
+ "title": "Information to be made available by ENISA",
257
+ "text": "1.   ENISA shall publish the following information on the website referred to in Article 50(1) of Regulation (EU) 2019/881:\n\n(a)\n\nall EUCC certificates;\n\n(b)\n\nthe information on the status of an EUCC certificate, notably whether it is in force, suspended, withdrawn, or expired;\n\n(c)\n\ncertification reports corresponding to each EUCC certificate;\n\n(d)\n\na list of accredited conformity assessment bodies;\n\n(e)\n\na list of authorised conformity assessment bodies;\n\n(f)\n\nthe state-of-the-art documents listed in Annex I\n\n(g)\n\nthe opinions of the European Cybersecurity Certification Group referred to in Article 62(4), point (c), of Regulation (EU) 2019/881;\n\n(h)\n\npeer assessment reports issued in accordance with Article 47.\n\n2.   The information referred to in paragraph 1 shall be made available at least in English.\n\n3.   Certification bodies and, where applicable, national cybersecurity certification authorities shall inform ENISA without delay about their decisions which affect the content or the status of an EUCC certificate referred to in paragraph 1, point (b).\n\n4.   ENISA shall ensure that the information published in accordance with paragraph 1 points (a), (b) and (c), clearly identifies the versions of a certified ICT product which are covered by an EUCC certificate.",
258
+ "chapter": "VII"
259
+ },
260
+ {
261
+ "number": "43",
262
+ "title": "Protection of information",
263
+ "text": "Conformity assessment bodies, national cybersecurity certification authorities, ECCG, ENISA, the Commission and all other parties shall ensure the security and protection of business secrets and other confidential information, including trade secrets, as well as the preserving intellectual property rights, and take the necessary and appropriate technical and organisational measures.\n\nMUTUAL RECOGNITION AGREEMENTS WITH THIRD COUNTRIES",
264
+ "chapter": "VIII"
265
+ },
266
+ {
267
+ "number": "44",
268
+ "title": "Conditions",
269
+ "text": "1.   Third countries willing to certify their products in accordance with this Regulation, and who wish to have such certification recognised within the Union, shall conclude a mutual recognition agreement with the Union.\n\n2.   The mutual recognition agreement shall cover the applicable assurance levels for certified ICT products and, where applicable, protection profiles.\n\n3.   Mutual recognition agreements referred to in paragraph 1, may only be concluded with third countries that meet the following conditions:\n\n(a)\n\nhave an authority that:\n\n(1)\n\nis a public body, independent of the entities it supervises and monitors in terms of organisational and legal structure, financial funding and decision making;\n\n(2)\n\nhas appropriate monitoring and supervising powers to carry out investigations and is empowered to take appropriate corrective measures to ensure compliance;\n\n(3)\n\nhas an effective, proportionate and dissuasive penalty system to ensure compliance;\n\n(4)\n\nagrees to collaborate with the European Cybersecurity Certification Group and ENISA to exchange best practice and relevant developments in the field of cybersecurity certification and to work towards a uniform interpretation of the currently applicable evaluation criteria and methods, amongst others, by applying harmonised documentation that is equivalent to the state-of-the-art documents listed in Annex I\n\n(b)\n\nhave an independent accreditation body performing accreditations using equivalent standards to those referred to in Regulation (EC) No 765/2008;\n\n(c)\n\ncommit that the evaluation and certification processes and procedures will be carried out in a duly professional manner, taking into account compliance with the international standards referred to in this Regulation, in particular in Article 3;\n\n(d)\n\nhave the capacity to report previously undetected vulnerabilities and an established, adequate vulnerability management and disclosure procedure in place;\n\n(e)\n\nhave established procedures that enable it to effectively lodge and handle complaints and provide effective legal remedy for the complainant;\n\n(f)\n\nestablishing a mechanism for cooperation with other Union and Member States’ bodies relevant to the cybersecurity certification under this Regulation including the sharing of information about the possible non-compliance of certificates, monitoring relevant developments in the field of certification and ensuring a joint approach on certification maintenance and review.\n\n4.   In addition to the conditions set out in paragraph 3, a mutual recognition agreement referred to in paragraph 1 covering assurance level “high” may only be concluded with third countries where also the following conditions are met:\n\n(a)\n\nthe third country has an independent and public cybersecurity certification authority performing or delegating evaluation activities necessary to allow certification under assurance level ‘high’ that are equivalent to the requirements and procedures laid down for national cybersecurity authorities in this Regulation and in Regulation (EU) 2019/881;\n\n(b)\n\nthe mutual recognition agreement establishes a joint mechanism equivalent to the peer assessment for EUCC certification to enhance the exchange of practices and jointly solve issues in the area of evaluation and certification.\n\nPEER ASSESSMENT OF CERTIFICATION BODIES",
270
+ "chapter": "IX"
271
+ },
272
+ {
273
+ "number": "45",
274
+ "title": "Peer assessment procedure",
275
+ "text": "1.   A certification body issuing EUCC certificates at assurance level ‘high’ shall undergo a peer assessment on a regular basis and at least every 5 years. The different types of peer assessment are listed in Annex VI.\n\n2.   The European Cybersecurity Certification Group shall draw up and maintain a schedule of peer assessments ensuring that such periodicity is respected. Except in duly justified cases, peer assessments shall be performed on-site.\n\n3.   The peer assessment may rely on evidence gathered in the course of previous peer assessments or equivalent procedures of the peer-assessed certification body or national cybersecurity certification authority, provided that:\n\n(a)\n\nthe results are not older than 5 years;\n\n(b)\n\nthe results are accompanied by a description of the peer assessment procedures established for that scheme where they relate to a peer assessment conducted under a different certification scheme;\n\n(c)\n\nthe peer assessment report referred to in Article 47 specifies which results were reused with or without further assessment.\n\n4.   Where a peer assessment covers a technical domain, the concerned ITSEF shall also be assessed.\n\n5.   The peer-assessed certification body and, where necessary, the national cybersecurity certification authority shall ensure that all relevant information is made available to the peer assessment team.\n\n6.   The peer assessment shall be carried out by a peer assessment team set up in accordance with Annex VI.",
276
+ "chapter": "IX"
277
+ },
278
+ {
279
+ "number": "46",
280
+ "title": "Peer assessment phases",
281
+ "text": "1.   During the preparatory phase, the members of the peer assessment team shall review the certification body’s documentation, covering its policies and procedures, including the use of state-of-the-art documents.\n\n2.   During site visit phase, the peer assessment team assesses the body’s technical competence and, where applicable, the competence of an ITSEF that performed at least one ICT product evaluation covered by peer assessment.\n\n3.   The duration of the site visit phase may be extended or reduced depending on such factors as the possibility of reusing existing peer assessment evidence and results or the number of ITSEF and technical domains for which the certification body issues certificates.\n\n4.   If applicable, the peer assessment team shall determine the technical competence of each ITSEF by visiting its technical laboratory or laboratories and interviewing its evaluators as regards the technical domain and related specific attack methods.\n\n5.   In the reporting phase, the assessment team shall document their findings in a peer assessment report including a verdict and, where applicable, a list of observed non-conformities, each graded by a criticality level.\n\n6.   The peer assessment report must be first discussed with the peer-assessed certification body. Following those discussions, the peer-assessed certification body establishes a schedule of the measures to be taken to address the findings.",
282
+ "chapter": "IX"
283
+ },
284
+ {
285
+ "number": "47",
286
+ "title": "Peer assessment report",
287
+ "text": "1.   The peer assessment team shall provide the peer-assessed certification body with a draft of the peer assessment report.\n\n2.   The peer-assessed certification body shall submit to the peer assessment team comments regarding the findings and a list of commitments to address the shortcomings identified in the draft peer assessment report.\n\n3.   The peer assessment team shall submit to the European Cybersecurity Certification Group a final peer assessment report, which shall also include the comments and the commitments made by the peer-assessed certification body. The peer assessment team shall also include their position on the comments and on whether those commitments are sufficient to address the shortcomings identified.\n\n4.   Where non-conformities are identified in the peer-assessment report, the European Cybersecurity Certification Group may set an appropriate time limit for the peer-assessed certification body to address the non-conformities.\n\n5.   The European Cybersecurity Certification Group shall adopt an opinion on the peer assessment report:\n\n(a)\n\nwhere the peer-assessment report does not identify non-conformities or where non-conformities have been appropriately addressed by the peer-assessed certification body, the European Cybersecurity Certification Group may issue a positive opinion and all relevant documents shall be published on ENISA’s certification website;\n\n(b)\n\nwhere the peer-assessed certification body does not address the non-conformities appropriately within the set time limit, the European Cybersecurity Certification Group may issue a negative opinion that shall be published on ENISA’s certification website, including the peer assessment report and all relevant documents.\n\n6.   Prior to the publication of the opinion, all sensitive, personal or proprietary information shall be removed from the published documents.\n\nMAINTENANCE OF THE SCHEME",
288
+ "chapter": "X"
289
+ },
290
+ {
291
+ "number": "48",
292
+ "title": "Maintenance of the EUCC",
293
+ "text": "1.   The Commission may request the European Cybersecurity Certification Group to adopt an opinion in view of maintaining the EUCC and to undertake the necessary preparatory works.\n\n2.   The European Cybersecurity Certification Group may adopt an opinion to endorse state-of-the-art documents.\n\n3.   State-of-the-art documents which have been endorsed by the European Cybersecurity Certification Group shall be published by ENISA.\n\nFINAL PROVISIONS",
294
+ "chapter": "XI"
295
+ },
296
+ {
297
+ "number": "49",
298
+ "title": "National schemes covered by the EUCC",
299
+ "text": "1.   In accordance with Article 57(1) of Regulation (EU) 2019/881 and without prejudice to Article 57(3) of that Regulation, all national cybersecurity certification schemes and the related procedures for ICT products and ICT processes that are covered by the EUCC shall cease to produce effects from 12 months after the entry into force of this Regulation.\n\n2.   By derogation from Article 50, a certification process may be initiated under a national cybersecurity certification scheme within 12 months from the entry into force of this Regulation provided that the certification process is finalised not later than 24 months after entry into force of this Regulation.\n\n3.   Certificates issued under national cybersecurity certification schemes may be subject to review. New certificates replacing the reviewed certificates shall be issued in accordance with this Regulation.",
300
+ "chapter": "XI"
301
+ },
302
+ {
303
+ "number": "50",
304
+ "title": "Entry into force",
305
+ "text": "This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.\n\nIt shall apply from 27 February 2025.\n\nThis Regulation shall be binding in its entirety and directly applicable in all Member States.\n\nDone at Brussels, 31 January 2024.\n\nFor the Commission\n\nThe President\n\nUrsula VON DER LEYEN\n\n(1)\n\nOJ L 151, 7.6.2019, p. 15.\n\n(2)  Mutual Recognition Agreement of Information Technology Security Evaluation Certificates, version 3.0 of January 2010, available on sogis.eu, approved by Senior Officials Group Information Systems Security of the European Commission in response to point 3 of Council Recommendation 95/144/EC of 7 April 1995 on common information technology security evaluation criteria (OJ L 93, 26.4.1995, p. 27).\n\n(3)  Joint Interpretation Library: Minimum ITSEF Requirements for Security Evaluations of Smart cards and similar devices, version 2.1 of February 2020, available at sogis.eu.\n\n(4)  Regulation (EU) 2019/1020 of the European Parliament and of the Council of 20 June 2019 on market surveillance and compliance of products and amending Directive 2004/42/EC and Regulations (EC) No 765/2008 and (EU) No 305/2011 (OJ L 169, 25.6.2019, p. 1).\n\n(5)  Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) (OJ L 333, 27.12.2022, p. 80).\n\nANNEX I\n\nTechnical domains and state-of-the-art documents\n\n1.\n\nTechnical domains at AVA_VAN level 4 or 5:\n\n(a)\n\ndocuments related to the harmonised evaluation of technical domain ‘smart cards and similar devices’ and in particular the following documents in their respective version in force on [date of entry into force]:\n\n(1)\n\n‘Minimum ITSEF requirements for security evaluations of smart cards and similar devices’, initially approved by ECCG on 20 October 2023;\n\n(2)\n\n‘Minimum Site Security Requirements’, initially approved by ECCG on 20 October 2023;\n\n(3)\n\n‘Application of Common Criteria to integrated circuits’, initially approved by ECCG on 20 October 2023;\n\n(4)\n\n‘Security Architecture requirements (ADV_ARC) for smart cards and similar devices’, initially approved by ECCG on 20 October 2023;\n\n(5)\n\n‘Certification of “open” smart card products’, initially approved by ECCG on 20 October 2023;\n\n(6)\n\n‘Composite product evaluation for smart cards and similar devices’, initially approved by ECCG on 20 October 2023;\n\n(7)\n\n‘Application of Attack Potential to Smartcards’, initially approved by ECCG on 20 October 2023;\n\n(b)\n\ndocuments related to the harmonised evaluation of technical domain ‘hardware devices with security boxes’ and in particular the following documents in their respective version in force on [date of entry into force]:\n\n(1)\n\n‘Minimum ITSEF requirements for security evaluations of hardware devices with security boxes’, initially approved by ECCG on 20 October 2023;\n\n(2)\n\n‘Minimum Site Security Requirements’, initially approved by ECCG on 20 October 2023;\n\n(3)\n\n‘Application of Attack Potential to hardware devices with security boxes’, initially approved by ECCG on 20 October 2023.\n\n2.\n\nState-of-the-art documents in their respective version in force on [date of entry into force]:\n\n(a)\n\ndocument related to the harmonised accreditation of conformity assessment bodies: ‘Accreditation of ITSEFs for the EUCC’, initially approved by ECCG on 20 October 2023.\n\nANNEX II\n\nProtection profiles certified at AVA_VAN level 4 or 5\n\n1.\n\nFor the category of remote qualified signature and seal creation devices:\n\n(1)\n\nEN 419241-2:2019 – Trustworthy Systems Supporting Server Signing - Part 2: Protection Profile for QSCD for Server Signing ;\n\n(2)\n\nEN 419221-5:2018 - Protection profiles for Trust Service Provider Cryptographic modules - Part 5: Cryptographic Module for Trust Services\n\n2.\n\nProtection profiles that have been adopted as state-of-the-art documents:\n\n[BLANK]\n\nANNEX III\n\nRecommended protection profiles (illustrating technical domains from Annex I)\n\nProtection profiles used in certification of ICT products falling under the below stated ICT product category:\n\n(a)\n\nfor the category of machine readable travel documents:\n\n(1)\n\nPP Machine Readable Travel Document using Standard Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011-MA-01;\n\n(2)\n\nPP for a Machine Readable Travel Document with \"ICAO Application\" Extended Access Control, BSI-CC-PP-0056-2009;\n\n(3)\n\nPP for a Machine Readable Travel Document with \"ICAO Application\" Extended Access Control with PACE, BSI-CC-PP-0056-V2-2012-MA-02;\n\n(4)\n\nPP for a Machine Readable Travel Document with \"ICAO Application\" Basic Access Control, BSI-CC-PP-0055-2009;\n\n(b)\n\nfor the category of secure signature creation devices:\n\n(1)\n\nEN 419211-1:2014 - Protection profiles for secure signature creation device - Part 1: Overview\n\n(2)\n\nEN 419211-2:2013 - Protection profiles for secure signature creation device - Part 2: Device with key generation;\n\n(3)\n\nEN 419211-3:2013 - Protection profiles for secure signature creation device - Part 3: Device with key import;\n\n(4)\n\nEN 419211-4:2013 - Protection profiles for secure signature creation device - Part 4: Extension for device with key generation and trusted channel to certificate generation application\n\n(5)\n\nEN 419211-5:2013 - Protection profiles for secure signature creation device - Part 5: Extension for device with key generation and trusted channel to signature creation application;\n\n(6)\n\nEN 419211-6:2014 - Protection profiles for secure signature creation device - Part 6: Extension for device with key import and trusted channel to signature creation application;\n\n(c)\n\nfor the category of digital tachographs:\n\n(1)\n\nDigital Tachograph - Tachograph Card, as referred in Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) 165/2014 (Annex 1C);\n\n(2)\n\nDigital Tachograph - Vehicle unit as referred in Annex IB of Commission Regulation (EC) No. 1360/2002 intended to be installed in road transport vehicles;\n\n(3)\n\nDigital Tachograph - External GNSS Facility (EGF PP) as referred in Annex 1C of Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) 165/2014 of the European Parliament and of the Council;\n\n(4)\n\nDigital Tachograph - Motion Sensor (MS PP) as referred in Annex 1C of Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) 165/2014 of the European Parliament and of the Council;\n\n(d)\n\nfor the category of secure integrated circuits, smart cards and related devices:\n\n(1)\n\nSecurity IC Platform PP, BSI-CC-PP-0084-2014;\n\n(2)\n\nJava Card System - Open Configuration, V3.0.5 BSI-CC-PP-0099-2017;\n\n(3)\n\nJava Card System - Closed Configuration, BSI-CC-PP-0101-2017;\n\n(4)\n\nPP for a PC Client Specific Trusted Platform Module Family 2.0 Level 0 Revision 1.16, ANSSI-CC-PP-2015/07;\n\n(5)\n\nUniversal SIM card, PU-2009-RT-79, ANSSI-CC-PP-2010/04;\n\n(6)\n\nEmbedded UICC (eUICC) for Machine-to-Machine Devices, BSI-CC-PP-0089-2015;\n\n(e)\n\nfor the category of points of (payment) interaction and payment terminals:\n\n(1)\n\nPoint of Interaction \"POI-CHIP-ONLY\", ANSSI-CC-PP-2015/01;\n\n(2)\n\nPoint of Interaction \"POI-CHIP-ONLY and Open Protocol Package\", ANSSI-CC-PP-2015/02;\n\n(3)\n\nPoint of Interaction \"POI-COMPREHENSIVE\", ANSSI-CC-PP-2015/03;\n\n(4)\n\nPoint of Interaction \"POI-COMPREHENSIVE and Open Protocol Package\", ANSSI-CC-PP-2015/04;\n\n(5)\n\nPoint of Interaction \"POI-PED-ONLY\", ANSSI-CC-PP-2015/05;\n\n(6)\n\nPoint of Interaction \"POI-PED-ONLY and Open Protocol Package\", ANSSI-CC-PP-2015/06;\n\n(f)\n\nfor the category of hardware devices with security boxes:\n\n(1)\n\nCryptographic Module for CSP Signing Operations with Backup - PP CMCSOB, PP HSM CMCSOB 14167-2, ANSSI-CC-PP-2015/08;\n\n(2)\n\nCryptographic Module for CSP key generation services - PP CMCKG, PP HSM CMCKG 14167-3, ANSSI-CC-PP-2015/09;\n\n(3)\n\nCryptographic Module for CSP Signing Operations without Backup - PP CMCSO, PP HSM CMCKG 14167-4, ANSSI-CC-PP-2015/10.\n\nANNEX IV\n\nAssurance continuity and certificate review\n\nIV.1   Assurance continuity: scope\n\n1.\n\nThe following requirements for assurance continuity apply to the maintenance activities related to the following:\n\n(a)\n\na re-assessment if an unchanged certified ICT product still meets its security requirements;\n\n(b)\n\nan evaluation of the impacts of changes to a certified ICT product on its certification;\n\n(c)\n\nif included in the certification, the application of patches in accordance with an assessed patch management process;\n\n(d)\n\nif included, the review of the certificate holder’s lifecycle management or production processes.\n\n2.\n\nThe holder of an EUCC certificate may request the review of the certificate in the following cases:\n\n(a)\n\nthe EUCC certificate is due to expire within nine months;\n\n(b)\n\nthere has been a change either in the certified ICT product or in another factor which could impact its security functionality;\n\n(c)\n\nthe holder of the certificate demands that the vulnerability assessment is carried out again in order to reconfirm the EUCC certificate’s assurance associated with the ICT product’s resistance against present cyberattacks.\n\nIV.2   Re-assessment\n\n1.\n\nWhere there is a need to assess the impact of changes in the threat environment of an unchanged certified ICT product, a re-assessment request shall be submitted to the certification body.\n\n2.\n\nThe re-assessment shall be carried out by the same ITSEF that was involved in the previous evaluation by reusing all its results that still apply. The evaluation shall focus on assurance activities which are potentially impacted by the changed threat environment of the certified ICT product, in particular the relevant AVA_VAN family and in addition the assurance lifecycle (ALC) family where sufficient evidence about the maintenance of the development environment shall be collected again.\n\n3.\n\nThe ITSEF shall describe the changes and detail the results of the re-assessment with an update of the previous evaluation technical report.\n\n4.\n\nThe certification body shall review the updated evaluation technical report and establish a re-assessment report. The status of the initial certificate shall then be modified in accordance with Article 13.\n\n5.\n\nThe re-assessment report and updated certificate shall be provided to the national cybersecurity certification authority and ENISA for publication on its cybersecurity certification website.\n\nIV.3   Changes to a certified ICT product\n\n1.\n\nWhere a certified ICT product has been subject to changes, the holder of the certificate wishing to maintain the certificate shall provide to the certification body an impact analysis report.\n\n2.\n\nThe impact analysis report shall provide the following elements:\n\n(a)\n\nan introduction containing necessary information to identify the impact analysis report and the target of evaluation subject to changes;\n\n(b)\n\na description of the changes to the product;\n\n(c)\n\nthe identification of affected developer evidence;\n\n(d)\n\na description of the developer evidence modifications;\n\n(e)\n\nthe findings and the conclusions on the impact on assurance for each change.\n\n3.\n\nThe certification body shall examine the changes described in the impact analysis report in order to validate their impact upon the assurance of the certified target of evaluation, as proposed in the conclusions of the impact analysis report.\n\n4.\n\nFollowing the examination, the certification body determines the scale of a change as minor or major in correspondence to its impact.\n\n5.\n\nWhere the changes have been confirmed by the certification body to be minor, a new certificate shall be issued for the modified ICT product and a maintenance report to the initial certification report shall be established, under following conditions:\n\n(a)\n\nthe maintenance report shall be included as a subset of the impact analysis report, containing following sections:\n\n(1)\n\nintroduction;\n\n(2)\n\ndescription of changes;\n\n(3)\n\naffected developer evidence;\n\n(b)\n\nthe validity date of the new certificate shall not exceed the date of the initial certificate.\n\n6.\n\nThe new certificate including the maintenance report shall be provided to ENISA for publication on its cybersecurity certification website.\n\n7.\n\nWhere the changes have been confirmed to be major, a re-evaluation shall be carried out in the context of the previous evaluation and by reusing any results from the previous evaluation that still apply.\n\n8.\n\nAfter completion of the evaluation of the changed target of evaluation, the ITSEF shall establish a new evaluation technical report. The certification body shall review the updated evaluation technical report and, where applicable, establish a new certificate with a new certification report.\n\n9.\n\nThe new certificate and certification report shall be provided to ENISA for publication.\n\nIV.4   Patch management\n\n1.\n\nA patch management procedure provides for a structured process of updating a certified ICT product. The patch management procedure including the mechanism as implemented into the ICT product by the applicant for certification can be used after the certification of the ICT product under the responsibility of the conformity assessment body.\n\n2.\n\nThe applicant for certification may include into the certification of the ICT product a patch mechanism as part of a certified management procedure implemented into the ICT product under one of the following conditions:\n\n(a)\n\nthe functionalities affected by the patch reside outside the target of evaluation of the certified ICT product;\n\n(b)\n\nthe patch relates to a predetermined minor change to the certified ICT product;\n\n(c)\n\nthe patch relates to a confirmed vulnerability with critical effects on the security of the certified ICT product.\n\n3.\n\nIf the patch relates to a major change to the target of evaluation of the certified ICT product in relation to a previously undetected vulnerability having no critical effects to the security of the ICT product, the provisions of Article 13 apply.\n\n4.\n\nThe patch management procedure for an ICT product will be composed of the following elements:\n\n(a)\n\nthe process for the development and release of the patch for the ICT product;\n\n(b)\n\nthe technical mechanism and functions for the adoption of the patch into the ICT product;\n\n(c)\n\na set of evaluation activities related to the effectiveness and performance of the technical mechanism.\n\n5.\n\nDuring the certification of the ICT product:\n\n(a)\n\nthe applicant for certification of the ICT product shall provide the description of the patch management procedure;\n\n(b)\n\nthe ITSEF shall verify the following elements:\n\n(1)\n\nthe developer implemented the patch mechanisms into the ICT product in accordance to the patch management procedure that was submitted to certification;\n\n(2)\n\nthe target of evaluation boundaries are separated in a way that the changes made to the separated processes do not affect the security of the target of evaluation;\n\n(3)\n\nthe technical patch mechanism performs in accordance with the provisions of this section and the applicant’s claims;\n\n(c)\n\nthe certification body shall include in the certification report the outcome of the assessed patch management procedure.\n\n6.\n\nThe holder of the certificate may proceed to apply the patch produced in compliance of the certified patch management procedure to the concerned certified ICT product and shall take the following steps within 5 working days in the following cases:\n\n(a)\n\nin the case referred to in point 2(a), report the patch concerned to the certification body that shall not change the corresponding EUCC certificate;\n\n(b)\n\nin the case referred to in point 2(b), submit the patch concerned to the ITSEF for review. The ITSEF shall inform the certification body after the reception of the patch upon which the certification body takes the appropriate action on the issuance of a new version of the corresponding EUCC certificate and the update of the certification report;\n\n(c)\n\nin the case referred to in point 2(c), submit the patch concerned to the ITSEF for the necessary re-evaluation but may deploy the patch in parallel. The ITSEF shall inform the certification body after which the certification body starts the related certification activities.\n\nANNEX V\n\nCONTENT OF A CERTIFICATION REPORT\n\nV.1   Certification report\n\n1.\n\nOn the basis of the evaluation technical reports provided by the ITSEF, the certification body establishes a certification report to be published together with the corresponding EUCC certificate.\n\n2.\n\nThe certification report is the source of detailed and practical information about the ICT product or the category of ICT products and about the ICT product’s secure deployment and shall therefore include all publicly available and sharable information of relevance to users and interested parties. Publicly available and sharable information can be referenced by the certification report.\n\n3.\n\nThe certification report shall at least contain the following sections:\n\n(a)\n\nexecutive summary;\n\n(b)\n\nidentification of the ICT product or the ICT product category for protection profiles;\n\n(c)\n\nsecurity services;\n\n(d)\n\nassumptions and clarification of scope;\n\n(e)\n\narchitectural information;\n\n(f)\n\nsupplementary cybersecurity information, if applicable;\n\n(g)\n\nICT product testing, if it was performed;\n\n(h)\n\nwhere applicable, an identification of the certificate holder’s lifecycle management processes and production facilities;\n\n(i)\n\nresults of the evaluation and information regarding the certificate;\n\n(j)\n\nsummary of the security target of the ICT product submitted to certification;\n\n(k)\n\nwhen available, the mark or label associated to the scheme;\n\n(l)\n\nbibliography.\n\n4.\n\nThe executive summary shall be a brief summary of the entire certification report. The executive summary shall provide a clear and concise overview of the evaluation results and shall include the following information:\n\n(a)\n\nname of the evaluated ICT product, enumeration of the product’s components that are part of the evaluation and the ICT product version;\n\n(b)\n\nname of the ITSEF that performed the evaluation and, where applicable, the list of subcontractors;\n\n(c)\n\ncompletion date of evaluation;\n\n(d)\n\nreference to the evaluation technical report established by the ITSEF;\n\n(e)\n\nbrief description of the certification report results, including:\n\n(1)\n\nthe version and if applicable release of the Common Criteria applied to the evaluation;\n\n(2)\n\nthe Common Criteria assurance package and security assurance components including the AVA_VAN level applied during the evaluation and its corresponding assurance level as set out in Article 52 of Regulation (EU) 2019/881 to which the EUCC certificate refers to;\n\n(3)\n\nthe security functionality of the evaluated ICT product;\n\n(4)\n\na summary of threats and organisational security policies addressed by the evaluated ICT product;\n\n(5)\n\nspecial configuration requirements;\n\n(6)\n\nassumptions about the operating environment;\n\n(7)\n\nwhere applicable, the presence of an approved patch management procedure in accordance with Section IV.4 of Annex IV;\n\n(8)\n\ndisclaimer(s).\n\n5.\n\nThe evaluated ICT product shall be clearly identified, including the following information:\n\n(a)\n\nthe name of the evaluated ICT product;\n\n(b)\n\nan enumeration of the ICT product’s components that are part of the evaluation;\n\n(c)\n\nthe version number of the ICT product’s components;\n\n(d)\n\nidentification of additional requirements to the operating environment of the certified ICT product;\n\n(e)\n\nname and contact information of the holder of the EUCC certificate;\n\n(f)\n\nwhere applicable, the patch management procedure included into the certificate;\n\n(g)\n\nlink to the website of the holder of the EUCC certificate where supplementary cybersecurity information for the certified ICT product in accordance with Article 55 of Regulation (EU) 2019/881 is provided.\n\n6.\n\nThe information included in this Section shall be as accurate as possible in order to ensure a complete and accurate representation of the ICT product that can be re-used in future evaluations.\n\n7.\n\nThe security policy section shall contain the description of the ICT product's security policy and the policies or rules that the evaluated ICT product shall enforce or comply with. It shall include a reference and a description of the following policies:\n\n(a)\n\nthe vulnerability handling policy of the holder of the certificate;\n\n(b)\n\nthe assurance continuity policy of the holder of the certificate.\n\n8.\n\nWhere applicable, the policy may include the conditions related to the use of a patch management procedure during the validity of the certificate.\n\n9.\n\nThe section for the assumptions and clarification of scope shall contain exhaustive information regarding the circumstances and objectives related to the intended use of the product as referred to in Article 7(1), point (c). The information shall include the following:\n\n(a)\n\nassumptions on the ICT product’s usage and deployment in the form of minimum requirements, such as proper installation and configuration and hardware requirements being satisfied;\n\n(b)\n\nassumptions on the environment for the compliant operation of the ICT product;\n\n10.\n\nThe information listed in point 9 shall be as understandable as possible in order to let users of the certified ICT product make informed decisions about the risks associated with its use.\n\n11.\n\nThe architectural information section shall include a high-level description of the ICT product and its main components in accordance with Common Criteria’s ADV_TDS subsystems design.\n\n12.\n\nA complete listing of the ICT product supplementary cybersecurity information shall be provided in accordance with Article 55 of Regulation (EU) 2019/881. All relevant documentation shall be denoted by the version numbers.\n\n13.\n\nThe ICT product testing section shall include the following information:\n\n(a)\n\nthe name and point of contact of the authority or body that issued the certificate including the responsible national cybersecurity certification authority;\n\n(b)\n\nthe name of the ITSEF which performed the evaluation, when different from the certification body;\n\n(c)\n\nan identification of the used assurance components from the standards referred by Article 3;\n\n(d)\n\nthe version of the state-of-the-art document and further security evaluation criteria used in the evaluation;\n\n(e)\n\nthe complete and precise settings and configuration of the ICT product during the evaluation, including operational notes and observations if available;\n\n(f)\n\nany protection profile that has been used, including the following information:\n\n(1)\n\nthe author of the protection profile;\n\n(2)\n\nthe name and identifier of the protection profile;\n\n(3)\n\nthe identifier of the protection profile’s certificate;\n\n(4)\n\nthe name and contact details of the certification body and of the ITSEF involved in the evaluation of the protection profile;\n\n(5)\n\nthe assurance package(s) required for a product conforming to the protection profile.\n\n14.\n\nThe results of the evaluation and information regarding the certificate section shall include the following information:\n\n(a)\n\nconfirmation of the attained assurance level as referred to in Article 4 of this Regulation and Article 52 in Regulation (EU) 2019/881;\n\n(b)\n\nassurance requirements from the standards referred by Article 3 that the ICT product or protection profile actually meets, including the AVA_VAN level;\n\n(c)\n\ndetailed description of the assurance requirements, as well as the details of how the product meets each of them;\n\n(d)\n\ndate of issuance and period of validity of the certificate;\n\n(e)\n\nunique identifier of the certificate.\n\n15.\n\nThe security target shall be included in the certification report or referenced and summarised in the certification report and provided with the certification report association with it for the purposes of publication.\n\n16.\n\nThe security target may be sanitised in accordance with Section VI.2.\n\n17.\n\nThe mark or label associated to the EUCC may be inserted the certification report in accordance with the rules and procedures laid down Article 11\n\n18.\n\nThe bibliography section shall include references to all documents used in the compilation of the certification report. That information shall include at least the following:\n\n(a)\n\nthe security evaluation criteria, state-of-the-art documents and further relevant specifications used and their version;\n\n(b)\n\nthe evaluation technical report;\n\n(c)\n\nthe evaluation technical report for composite evaluation, where applicable;\n\n(d)\n\ntechnical reference documentation;\n\n(e)\n\ndeveloper documentation used in the evaluation effort.\n\n19.\n\nIn order to guarantee the reproducibility of the evaluation, all documentation referred to has to be uniquely identified with the proper release date, and proper version number.\n\nV.2   Sanitization of a security target for publication\n\n1.\n\nThe security target to be included in or referenced by the certification report pursuant to point 1 of Section VI.1 may be sanitised by the removal or paraphrasing of proprietary technical information.\n\n2.\n\nThe resulting sanitised security target shall be a real representation of its complete original version. This means that the sanitised security target cannot omit information which is necessary to understand the security properties of the target of evaluation and the scope of the evaluation.\n\n3.\n\nThe content of the sanitised security target shall conform to the following minimum requirements:\n\n(a)\n\nits introduction shall not be sanitised as it includes no proprietary information in general;\n\n(b)\n\nthe sanitised security target has to have a unique identifier that is distinct from its complete original version;\n\n(c)\n\nthe target of evaluation description may be reduced as it may include proprietary and detailed information about the target of evaluation design which should not be published;\n\n(d)\n\nthe target of evaluation security environment description (assumptions, threats, organisational security policies) shall not be reduced, in so far as that information is necessary to understand the scope of the evaluation;\n\n(e)\n\nthe security objectives shall not be reduced as all information is to be made public to understand the intention of the security target and target of evaluation;\n\n(f)\n\nall security requirements shall be made public. Application notes may give information on how the functional requirements of the Common Criteria as referred to in Article 3 were used to understand the security target;\n\n(g)\n\nthe target of evaluation summary specification shall include all target of evaluation security functions but additional proprietary information may be sanitised;\n\n(h)\n\nreferences to protection profiles applied to the target of evaluation shall be included;\n\n(i)\n\nthe rationale may be sanitised to remove proprietary information.\n\n4.\n\nEven if the sanitised security target is not formally evaluated in accordance with the evaluation standards referred to in Article 3, the certification body shall ensure that it complies with the complete and evaluated security target, and reference both the complete and the sanitised security target in the certification report.\n\nANNEX VI\n\nSCOPE AND TEAM COMPOSITION FOR PEER ASSESSMENTS\n\nVI.1   Scope of the peer assessment\n\n1.\n\nThe following types of peer assessments are covered:\n\n(a)\n\nType 1: when a certification body performs certification activities at the AVA_VAN.3 level;\n\n(b)\n\nType 2: when a certification body performs certification activities related to a technical domain listed as state-of-the-art documents in Annex I;\n\n(c)\n\nType 3: when a certification body performs certification activities above the AVA_VAN.3 level making use of a protection profile listed as state-of-the-art documents in Annex II or III.\n\n2.\n\nThe peer-assessed certification body shall submit the list of certified ICT products that may be candidate to the review by the peer assessment team, in accordance with the following rules:\n\n(a)\n\nthe candidate products shall cover the technical scope of the certification body authorisation, of which at least two different products evaluations at assurance level ‘high’ will be analysed through the peer assessment, and one protection profile if the certification body has issued certificate at assurance level ‘high’;\n\n(b)\n\nfor a Type 2 peer assessment, the certification body shall submit at least one product per technical domain and per concerned ITSEF;\n\n(c)\n\nfor a Type 3 peer assessment, at least one candidate product shall be evaluated in accordance with an applicable and relevant protection profiles.\n\nVI.2   Peer assessment team\n\n1.\n\nThe assessment team shall consist of at least two experts each selected from a different certification body from different Member States that issues certificates at the assurance level ‘high’. The experts should demonstrate the relevant expertise in the standards as referred in Article 3 and state-of-the-art documents that are in scope of the peer assessment.\n\n2.\n\nIn the case of a delegation of certificate issuance or prior approval of certificates as referred to in Article 56(6) of Regulation (EU) 2019/881, an expert from the national cybersecurity certification authority related to the concerned certification body shall in addition participate in the team of experts selected in accordance with paragraph 1 of this Section.\n\n3.\n\nFor a Type 2 peer assessment the team members shall be selected from certification bodies being authorised for the concerned technical domain.\n\n4.\n\nEach member of the assessment team shall have at least two years of experience of carrying out certification activities in a certification body;\n\n5.\n\nFor a Type 2 or 3 peer assessment, each member of the assessment team shall have at least two years of experience of carrying out certification activities in that relevant technical domain or protection profile and proven expertise and participation in the authorisation of an ITSEF\n\n6.\n\nThe national cybersecurity certification authority monitoring and supervising the peer-assessed certification body and at least one national cybersecurity certification authority whose certification body is not subject to the peer assessment shall participate in the peer assessment as an observer. ENISA may also participate in the peer assessment as an observer.\n\n7.\n\nThe peer-assessed certification body is presented with the composition of the peer assessment team. In justified cases, it may challenge the composition of the peer assessment team and ask for its review.\n\nANNEX VII\n\nContent of an EUCC Certificate\n\nAn EUCC certificate shall at least contain:\n\n(a)\n\na unique identifier established by the certification body issuing the certificate;\n\n(b)\n\ninformation related to the certified ICT product or protection profile and the holder of the certificate, including:\n\n(1)\n\nname of the ICT product or protection profile and, where applicable, of the target of evaluation;\n\n(2)\n\ntype of ICT product or protection profile and, where applicable, of the target of evaluation;\n\n(3)\n\nversion of the ICT product or protection profile;\n\n(4)\n\nname, address and contact information of the holder of the certificate;\n\n(5)\n\nlink to the website of the holder of the certificate containing the supplementary cybersecurity information referred to in Article 55 of Regulation (EU) 2019/881;\n\n(c)\n\ninformation related to the evaluation and certification of the ICT product or protection profile, including:\n\n(1)\n\nname, address and contact information of the certification body that issued the certificate;\n\n(2)\n\nwhere different from the certification body, name of the ITSEF which performed the evaluation;\n\n(3)\n\nname of the responsible national cybersecurity certification authority;\n\n(4)\n\na reference to this Regulation;\n\n(5)\n\na reference to the certification report associated with the certificate referred to in Annex V;\n\n(6)\n\nthe applicable assurance level in accordance with Article 4;\n\n(7)\n\na reference to the version of the standards used for the evaluation, referred to in Article 3;\n\n(8)\n\nidentification of the assurance level or package specified in the standards referred to in Article 3 and in conformity with Annex VIII, including the assurance components used and the AVA_VAN level covered;\n\n(9)\n\nwhere applicable, reference to one or more protection profiles with which the ICT product or protection profile complies;\n\n(10)\n\ndate of issuance;\n\n(11)\n\nperiod of validity of the certificate;\n\n(d)\n\nthe mark and label associated with the certificate in accordance with Article 11.\n\nANNEX VIII\n\nAssurance package declaration\n\n1.\n\nContrary to the definitions in the Common Criteria, an augmentation:\n\n(a)\n\nshall not be denoted by the abbreviation ‘+’;\n\n(b)\n\nshall be detailed by a list of all concerned components;\n\n(c)\n\nshall be outlined in detail in the certification report.\n\n2.\n\nThe assurance level confirmed in an EUCC certificate may be complemented by the evaluation assurance level as specified in Article 3 of this Regulation.\n\n3.\n\nIf the assurance level confirmed in an EUCC certificate does not refer to an augmentation, the EUCC certificate shall indicate one of the following packages:\n\n(a)\n\n“the specific assurance package”;\n\n(b)\n\n“the assurance package conformant to a protection profile” in case of referencing a protection profile without an evaluation assurance level.\n\nANNEX IX\n\nMark and label\n\n1.\n\nThe form of mark and label:\n\n2.\n\nIf the mark and label are reduced or enlarged, the proportions given in the drawing above shall be respected.\n\n3.\n\nWhere physically present, the mark and label shall be at least 5 mm high.\n\nELI: http://data.europa.eu/eli/reg_impl/2024/482/oj\n\nISSN 1977-0677 (electronic edition)\n\n////////////////////////$(document).ready(function(){generateTOC(true,'', 'Top','false');scrollToCurrentUrlAnchor();});",
306
+ "chapter": "IV"
307
+ }
308
+ ],
309
+ "definitions": [
310
+ {
311
+ "term": "common criteria",
312
+ "definition": "the Common Criteria for Information Technology Security Evaluation, as set out in ISO standard ISO/IEC 15408;",
313
+ "article": "2"
314
+ },
315
+ {
316
+ "term": "common evaluation methodology",
317
+ "definition": "the Common Methodology for Information Technology Security Evaluation, as set out in ISO/IEC standard ISO/IEC 18045;",
318
+ "article": "2"
319
+ },
320
+ {
321
+ "term": "target of evaluation",
322
+ "definition": "an ICT product or part thereof, or a protection profile as part of an ICT process, which is subjected to cybersecurity evaluation to receive EUCC certification;",
323
+ "article": "2"
324
+ },
325
+ {
326
+ "term": "security target",
327
+ "definition": "a claim of implementation-dependent security requirements for a specific ICT product;",
328
+ "article": "2"
329
+ },
330
+ {
331
+ "term": "protection profile",
332
+ "definition": "an ICT process that lays down the security requirements for a specific category of ICT products, addressing implementation-independent security needs, and that may be used to assess ICT products falling into that specific category for the purpose of their certification;",
333
+ "article": "2"
334
+ },
335
+ {
336
+ "term": "evaluation technical report",
337
+ "definition": "a document produced by an ITSEF to present the findings, verdicts and justifications obtained during the evaluation of an ICT product or a protection profile in accordance with the rules and obligations set out in this Regulation;",
338
+ "article": "2"
339
+ },
340
+ {
341
+ "term": "itsef",
342
+ "definition": "an Information Technology Security Evaluation Facility, which is a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008 that performs evaluation tasks;",
343
+ "article": "2"
344
+ },
345
+ {
346
+ "term": "ava_van level",
347
+ "definition": "an assurance vulnerability analysis level that indicates the degree of cybersecurity evaluation activities carried out to determine the level of resistance against potential exploitability of flaws or weaknesses in the target of evaluation in its operational environment as set out in the Common Criteria;",
348
+ "article": "2"
349
+ },
350
+ {
351
+ "term": "eucc certificate",
352
+ "definition": "a cybersecurity certificate issued under the EUCC for ICT products, or for protection profiles that can be used exclusively in the ICT process of certification of ICT products;",
353
+ "article": "2"
354
+ },
355
+ {
356
+ "term": "composite product",
357
+ "definition": "an ICT product that is evaluated together with another underlying ICT product that has already received an EUCC certificate and on whose security functionality the composite ICT product depends;",
358
+ "article": "2"
359
+ },
360
+ {
361
+ "term": "national cybersecurity certification authority",
362
+ "definition": "an authority designated by a Member State pursuant to Article 58(1) of Regulation (EU) 2019/881;",
363
+ "article": "2"
364
+ },
365
+ {
366
+ "term": "certification body",
367
+ "definition": "a conformity assessment body as defined in Article 2, point (13), of Regulation (EC) No 765/2008, which performs certification activities;",
368
+ "article": "2"
369
+ },
370
+ {
371
+ "term": "technical domain",
372
+ "definition": "a common technical framework related to a particular technology for the harmonised certification with a set of characteristic security requirements;",
373
+ "article": "2"
374
+ },
375
+ {
376
+ "term": "state-of-the-art document",
377
+ "definition": "a document which specifies evaluation methods, techniques and tools that apply to the certification of ICT products, or security requirements of a generic ICT product category, or any other requirements necessary for certification, in order to harmonise evaluation, in particular of technical domains or protection profiles;",
378
+ "article": "2"
379
+ },
380
+ {
381
+ "term": "market surveillance authority",
382
+ "definition": "an authority defined in Article 3(4) of Regulation (EU) 2019/1020.",
383
+ "article": "2"
384
+ }
385
+ ]
386
+ }