Commission Implementing Regulation (EU) 2024/482of 31 January 2024laying down rules for the application of Regulation (EU) 2019/881 of the European Parliament and of the Council as regards the adoption of the European Common Criteria-based cybersecurity certification scheme (EUCC)(Text with EEA relevance)
32024R0482
European Union
§ Article 12
Article 12 of Directive (EU) 2022/2555 of the European Parliament and of the Council
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).
or other online repositories referred to in Article 55(1), point (d) of Regulation (EU) 2019/881.
CHAPTER VII
RETENTION, DISCLOSURE AND PROTECTION OF INFORMATION
Article 40
Retention of records by certification bodies and the ITSEF
- 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.
- 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.
Article 41
Information made available by the holder of a certificate
- 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.
- 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:
(a) records of the information provided to the certification body and to the ITSEF during the certification process;
(b) specimen of the certified ICT product.
- 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.
- 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.
Article 42
Information to be made available by ENISA
- ENISA shall publish the following information on the website referred to in Article 50(1) of Regulation (EU) 2019/881:
(a) all EUCC certificates;
(b) the information on the status of an EUCC certificate, notably whether it is in force, suspended, withdrawn, or expired;
(c) certification reports corresponding to each EUCC certificate;
(d) a list of accredited conformity assessment bodies;
(e) a list of authorised conformity assessment bodies;
(f) the state-of-the-art documents listed in Annex I
(g) the opinions of the European Cybersecurity Certification Group referred to in Article 62(4), point (c), of Regulation (EU) 2019/881;
(h) peer assessment reports issued in accordance with Article 47.
- The information referred to in paragraph 1 shall be made available at least in English.
- 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).
- 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.
Article 43
Protection of information
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.
CHAPTER VIII
MUTUAL RECOGNITION AGREEMENTS WITH THIRD COUNTRIES
Article 44
Conditions
- 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.
- The mutual recognition agreement shall cover the applicable assurance levels for certified ICT products and, where applicable, protection profiles.
- Mutual recognition agreements referred to in paragraph 1, may only be concluded with third countries that meet the following conditions:
(a) have an authority that:
(1) is a public body, independent of the entities it supervises and monitors in terms of organisational and legal structure, financial funding and decision making;
(2) has appropriate monitoring and supervising powers to carry out investigations and is empowered to take appropriate corrective measures to ensure compliance;
(3) has an effective, proportionate and dissuasive penalty system to ensure compliance;
(4) agrees 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
(b) have an independent accreditation body performing accreditations using equivalent standards to those referred to in Regulation (EC) No 765/2008;
(c) commit 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;
(d) have the capacity to report previously undetected vulnerabilities and an established, adequate vulnerability management and disclosure procedure in place;
(e) have established procedures that enable it to effectively lodge and handle complaints and provide effective legal remedy for the complainant;
(f) establishing 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.
- 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:
(a) the 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;
(b) the 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.
CHAPTER IX
PEER ASSESSMENT OF CERTIFICATION BODIES
Article 45
Peer assessment procedure
- 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.
- 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.
- 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:
(a) the results are not older than 5 years;
(b) the 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;
(c) the peer assessment report referred to in Article 47 specifies which results were reused with or without further assessment.
- Where a peer assessment covers a technical domain, the concerned ITSEF shall also be assessed.
- 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.
- The peer assessment shall be carried out by a peer assessment team set up in accordance with Annex VI.
Article 46
Peer assessment phases
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Article 47
Peer assessment report
- The peer assessment team shall provide the peer-assessed certification body with a draft of the peer assessment report.
- 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.
- 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.
- 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.
- The European Cybersecurity Certification Group shall adopt an opinion on the peer assessment report:
(a) where 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;
(b) where 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.
- Prior to the publication of the opinion, all sensitive, personal or proprietary information shall be removed from the published documents.
CHAPTER X
MAINTENANCE OF THE SCHEME
Article 48
Maintenance of the EUCC
- 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.
- The European Cybersecurity Certification Group may adopt an opinion to endorse state-of-the-art documents.
- State-of-the-art documents which have been endorsed by the European Cybersecurity Certification Group shall be published by ENISA.
CHAPTER XI
FINAL PROVISIONS
Article 49
National schemes covered by the EUCC
- 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.
- 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.
- 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.
Article 50
Entry into force
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.
It shall apply from 27 February 2025.
Chapter IV and Annex V shall apply from the date of entry into force of this Regulation.
This Regulation shall be binding in its entirety and directly applicable in all Member States.
Done at Brussels, 31 January 2024.
For the Commission
The President
Ursula von der Leyen
Annex
ANNEX I
Technical domains and state-of-the-art documents
- Technical domains at AVA_VAN level 4 or 5:
(a) documents 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]:
(1) Minimum ITSEF requirements for security evaluations of smart cards and similar devices, initially approved by ECCG on 20 October 2023;
(2) Minimum Site Security Requirements, initially approved by ECCG on 20 October 2023;
(3) Application of Common Criteria to integrated circuits, initially approved by ECCG on 20 October 2023;
(4) Security Architecture requirements (ADV_ARC) for smart cards and similar devices, initially approved by ECCG on 20 October 2023;
(5) Certification of open smart card products, initially approved by ECCG on 20 October 2023;
(6) Composite product evaluation for smart cards and similar devices, initially approved by ECCG on 20 October 2023;
(7) Application of Attack Potential to Smartcards, initially approved by ECCG on 20 October 2023;
(b) documents 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]:
(1) Minimum ITSEF requirements for security evaluations of hardware devices with security boxes, initially approved by ECCG on 20 October 2023;
(2) Minimum Site Security Requirements, initially approved by ECCG on 20 October 2023;
(3) Application of Attack Potential to hardware devices with security boxes, initially approved by ECCG on 20 October 2023.
- State-of-the-art documents in their respective version in force on [date of entry into force]:
(a) document related to the harmonised accreditation of conformity assessment bodies: Accreditation of ITSEFs for the EUCC, initially approved by ECCG on 20 October 2023.
Annex
ANNEX II
Protection profiles certified at AVA_VAN level 4 or 5
- For the category of remote qualified signature and seal creation devices:
(1) EN 419241-2:2019 – Trustworthy Systems Supporting Server Signing - Part 2: Protection Profile for QSCD for Server Signing ;
(2) EN 419221-5:2018 - Protection profiles for Trust Service Provider Cryptographic modules - Part 5: Cryptographic Module for Trust Services
- Protection profiles that have been adopted as state-of-the-art documents:
[BLANK]
Annex
ANNEX III
Recommended protection profiles (illustrating technical domains from Annex I)
Protection profiles used in certification of ICT products falling under the below stated ICT product category:
(a) for the category of machine readable travel documents:
(1) PP Machine Readable Travel Document using Standard Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011-MA-01;
(2) PP for a Machine Readable Travel Document with ICAO Application Extended Access Control, BSI-CC-PP-0056-2009;
(3) PP for a Machine Readable Travel Document with ICAO Application Extended Access Control with PACE, BSI-CC-PP-0056-V2-2012-MA-02;
(4) PP for a Machine Readable Travel Document with ICAO Application Basic Access Control, BSI-CC-PP-0055-2009;
(b) for the category of secure signature creation devices:
(1) EN 419211-1:2014 - Protection profiles for secure signature creation device - Part 1: Overview
(2) EN 419211-2:2013 - Protection profiles for secure signature creation device - Part 2: Device with key generation;
(3) EN 419211-3:2013 - Protection profiles for secure signature creation device - Part 3: Device with key import;
(4) EN 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
(5) EN 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;
(6) EN 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;
(c) for the category of digital tachographs:
(1) Digital Tachograph - Tachograph Card, as referred in Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) 165/2014 (Annex 1C);
(2) Digital Tachograph - Vehicle unit as referred in Annex IB of Commission Regulation (EC) No. 1360/2002 intended to be installed in road transport vehicles;
(3) Digital 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;
(4) Digital 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;
(d) for the category of secure integrated circuits, smart cards and related devices:
(1) Security IC Platform PP, BSI-CC-PP-0084-2014;
(2) Java Card System - Open Configuration, V3.0.5 BSI-CC-PP-0099-2017;
(3) Java Card System - Closed Configuration, BSI-CC-PP-0101-2017;
(4) PP for a PC Client Specific Trusted Platform Module Family 2.0 Level 0 Revision 1.16, ANSSI-CC-PP-2015/07;
(5) Universal SIM card, PU-2009-RT-79, ANSSI-CC-PP-2010/04;
(6) Embedded UICC (eUICC) for Machine-to-Machine Devices, BSI-CC-PP-0089-2015;
(e) for the category of points of (payment) interaction and payment terminals:
(1) Point of Interaction POI-CHIP-ONLY, ANSSI-CC-PP-2015/01;
(2) Point of Interaction POI-CHIP-ONLY and Open Protocol Package, ANSSI-CC-PP-2015/02;
(3) Point of Interaction POI-COMPREHENSIVE, ANSSI-CC-PP-2015/03;
(4) Point of Interaction POI-COMPREHENSIVE and Open Protocol Package, ANSSI-CC-PP-2015/04;
(5) Point of Interaction POI-PED-ONLY, ANSSI-CC-PP-2015/05;
(6) Point of Interaction POI-PED-ONLY and Open Protocol Package, ANSSI-CC-PP-2015/06;
(f) for the category of hardware devices with security boxes:
(1) Cryptographic Module for CSP Signing Operations with Backup - PP CMCSOB, PP HSM CMCSOB 14167-2, ANSSI-CC-PP-2015/08;
(2) Cryptographic Module for CSP key generation services - PP CMCKG, PP HSM CMCKG 14167-3, ANSSI-CC-PP-2015/09;
(3) Cryptographic Module for CSP Signing Operations without Backup - PP CMCSO, PP HSM CMCKG 14167-4, ANSSI-CC-PP-2015/10.
Annex
ANNEX IV
Assurance continuity and certificate review
IV.1
Assurance continuity: scope
- The following requirements for assurance continuity apply to the maintenance activities related to the following:
(a) a re-assessment if an unchanged certified ICT product still meets its security requirements;
(b) an evaluation of the impacts of changes to a certified ICT product on its certification;
(c) if included in the certification, the application of patches in accordance with an assessed patch management process;
(d) if included, the review of the certificate holder’s lifecycle management or production processes.
- The holder of an EUCC certificate may request the review of the certificate in the following cases:
(a) the EUCC certificate is due to expire within nine months;
(b) there has been a change either in the certified ICT product or in another factor which could impact its security functionality;
(c) the 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.
IV.2
Re-assessment
- Where 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.
- The 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.
- The ITSEF shall describe the changes and detail the results of the re-assessment with an update of the previous evaluation technical report.
- The 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.
- The re-assessment report and updated certificate shall be provided to the national cybersecurity certification authority and ENISA for publication on its cybersecurity certification website.
IV.3
Changes to a certified ICT product
- Where 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.
- The impact analysis report shall provide the following elements:
(a) an introduction containing necessary information to identify the impact analysis report and the target of evaluation subject to changes;
(b) a description of the changes to the product;
(c) the identification of affected developer evidence;
(d) a description of the developer evidence modifications;
(e) the findings and the conclusions on the impact on assurance for each change.
- The 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.
- Following the examination, the certification body determines the scale of a change as minor or major in correspondence to its impact.
- Where 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:
(a) the maintenance report shall be included as a subset of the impact analysis report, containing following sections:
(1) introduction;
(2) description of changes;
(3) affected developer evidence;
(b) the validity date of the new certificate shall not exceed the date of the initial certificate.
- The new certificate including the maintenance report shall be provided to ENISA for publication on its cybersecurity certification website.
- Where 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.
- After 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.
- The new certificate and certification report shall be provided to ENISA for publication.
IV.4
Patch management
- A 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.
- The 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:
(a) the functionalities affected by the patch reside outside the target of evaluation of the certified ICT product;
(b) the patch relates to a predetermined minor change to the certified ICT product;
(c) the patch relates to a confirmed vulnerability with critical effects on the security of the certified ICT product.
- If 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.
- The patch management procedure for an ICT product will be composed of the following elements:
(a) the process for the development and release of the patch for the ICT product;
(b) the technical mechanism and functions for the adoption of the patch into the ICT product;
(c) a set of evaluation activities related to the effectiveness and performance of the technical mechanism.
- During the certification of the ICT product:
(a) the applicant for certification of the ICT product shall provide the description of the patch management procedure;
(b) the ITSEF shall verify the following elements:
(1) the developer implemented the patch mechanisms into the ICT product in accordance to the patch management procedure that was submitted to certification;
(2) the 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;
(3) the technical patch mechanism performs in accordance with the provisions of this section and the applicant’s claims;
(c) the certification body shall include in the certification report the outcome of the assessed patch management procedure.
- The 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:
(a) in the case referred to in point 2(a), report the patch concerned to the certification body that shall not change the corresponding EUCC certificate;
(b) in 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;
(c) in 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.
Annex
ANNEX V
CONTENT OF A CERTIFICATION REPORT
V.1
Certification report
- On 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.
- The 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.
- The certification report shall at least contain the following sections:
(a) executive summary;
(b) identification of the ICT product or the ICT product category for protection profiles;
(c) security services;
(d) assumptions and clarification of scope;
(e) architectural information;
(f) supplementary cybersecurity information, if applicable;
(g) ICT product testing, if it was performed;
(h) where applicable, an identification of the certificate holder’s lifecycle management processes and production facilities;
(i) results of the evaluation and information regarding the certificate;
(j) summary of the security target of the ICT product submitted to certification;
(k) when available, the mark or label associated to the scheme;
(l) bibliography.
- The 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:
(a) name of the evaluated ICT product, enumeration of the product’s components that are part of the evaluation and the ICT product version;
(b) name of the ITSEF that performed the evaluation and, where applicable, the list of subcontractors;
(c) completion date of evaluation;
(d) reference to the evaluation technical report established by the ITSEF;
(e) brief description of the certification report results, including:
(1) the version and if applicable release of the Common Criteria applied to the evaluation;
(2) the 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;
(3) the security functionality of the evaluated ICT product;
(4) a summary of threats and organisational security policies addressed by the evaluated ICT product;
(5) special configuration requirements;
(6) assumptions about the operating environment;
(7) where applicable, the presence of an approved patch management procedure in accordance with Section IV.4 of Annex IV;
(8) disclaimer(s).
- The evaluated ICT product shall be clearly identified, including the following information:
(a) the name of the evaluated ICT product;
(b) an enumeration of the ICT product’s components that are part of the evaluation;
(c) the version number of the ICT product’s components;
(d) identification of additional requirements to the operating environment of the certified ICT product;
(e) name and contact information of the holder of the EUCC certificate;
(f) where applicable, the patch management procedure included into the certificate;
(g) link 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.
- The 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.
- The 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:
(a) the vulnerability handling policy of the holder of the certificate;
(b) the assurance continuity policy of the holder of the certificate.
- Where applicable, the policy may include the conditions related to the use of a patch management procedure during the validity of the certificate.
- The 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:
(a) assumptions 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;
(b) assumptions on the environment for the compliant operation of the ICT product;
- The 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.
- The 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.
- A 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.
- The ICT product testing section shall include the following information:
(a) the name and point of contact of the authority or body that issued the certificate including the responsible national cybersecurity certification authority;
(b) the name of the ITSEF which performed the evaluation, when different from the certification body;
(c) an identification of the used assurance components from the standards referred by Article 3;
(d) the version of the state-of-the-art document and further security evaluation criteria used in the evaluation;
(e) the complete and precise settings and configuration of the ICT product during the evaluation, including operational notes and observations if available;
(f) any protection profile that has been used, including the following information:
(1) the author of the protection profile;
(2) the name and identifier of the protection profile;
(3) the identifier of the protection profile’s certificate;
(4) the name and contact details of the certification body and of the ITSEF involved in the evaluation of the protection profile;
(5) the assurance package(s) required for a product conforming to the protection profile.
- The results of the evaluation and information regarding the certificate section shall include the following information:
(a) confirmation of the attained assurance level as referred to in Article 4 of this Regulation and Article 52 in Regulation (EU) 2019/881;
(b) assurance requirements from the standards referred by Article 3 that the ICT product or protection profile actually meets, including the AVA_VAN level;
(c) detailed description of the assurance requirements, as well as the details of how the product meets each of them;
(d) date of issuance and period of validity of the certificate;
(e) unique identifier of the certificate.
- The 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.
- The security target may be sanitised in accordance with Section VI.2.
- The mark or label associated to the EUCC may be inserted the certification report in accordance with the rules and procedures laid down Article 11
- The bibliography section shall include references to all documents used in the compilation of the certification report. That information shall include at least the following:
(a) the security evaluation criteria, state-of-the-art documents and further relevant specifications used and their version;
(b) the evaluation technical report;
(c) the evaluation technical report for composite evaluation, where applicable;
(d) technical reference documentation;
(e) developer documentation used in the evaluation effort.
- In 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.
V.2
Sanitization of a security target for publication
- The 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.
- The 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.
- The content of the sanitised security target shall conform to the following minimum requirements:
(a) its introduction shall not be sanitised as it includes no proprietary information in general;
(b) the sanitised security target has to have a unique identifier that is distinct from its complete original version;
(c) the 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;
(d) the 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;
(e) the 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;
(f) all 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;
(g) the target of evaluation summary specification shall include all target of evaluation security functions but additional proprietary information may be sanitised;
(h) references to protection profiles applied to the target of evaluation shall be included;
(i) the rationale may be sanitised to remove proprietary information.
- Even 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.
Annex
ANNEX VI
SCOPE AND TEAM COMPOSITION FOR PEER ASSESSMENTS
VI.1
Scope of the peer assessment
- The following types of peer assessments are covered:
(a) Type 1: when a certification body performs certification activities at the AVA_VAN.3 level;
(b) Type 2: when a certification body performs certification activities related to a technical domain listed as state-of-the-art documents in Annex I;
(c) Type 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.
- The 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:
(a) the 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;
(b) for a Type 2 peer assessment, the certification body shall submit at least one product per technical domain and per concerned ITSEF;
(c) for a Type 3 peer assessment, at least one candidate product shall be evaluated in accordance with an applicable and relevant protection profiles.
VI.2
Peer assessment team
- The 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.
- In 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.
- For a Type 2 peer assessment the team members shall be selected from certification bodies being authorised for the concerned technical domain.
- Each member of the assessment team shall have at least two years of experience of carrying out certification activities in a certification body;
- For 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
- The 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.
- The 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.
Annex
ANNEX VII
Content of an EUCC Certificate
An EUCC certificate shall at least contain:
(a) a unique identifier established by the certification body issuing the certificate;
(b) information related to the certified ICT product or protection profile and the holder of the certificate, including:
(1) name of the ICT product or protection profile and, where applicable, of the target of evaluation;
(2) type of ICT product or protection profile and, where applicable, of the target of evaluation;
(3) version of the ICT product or protection profile;
(4) name, address and contact information of the holder of the certificate;
(5) link to the website of the holder of the certificate containing the supplementary cybersecurity information referred to in Article 55 of Regulation (EU) 2019/881;
(c) information related to the evaluation and certification of the ICT product or protection profile, including:
(1) name, address and contact information of the certification body that issued the certificate;
(2) where different from the certification body, name of the ITSEF which performed the evaluation;
(3) name of the responsible national cybersecurity certification authority;
(4) a reference to this Regulation;
(5) a reference to the certification report associated with the certificate referred to in Annex V;
(6) the applicable assurance level in accordance with Article 4;
(7) a reference to the version of the standards used for the evaluation, referred to in Article 3;
(8) identification 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;
(9) where applicable, reference to one or more protection profiles with which the ICT product or protection profile complies;
(10) date of issuance;
(11) period of validity of the certificate;
(d) the mark and label associated with the certificate in accordance with Article 11.
Annex
ANNEX VIII
Assurance package declaration
- Contrary to the definitions in the Common Criteria, an augmentation:
(a) shall not be denoted by the abbreviation +;
(b) shall be detailed by a list of all concerned components;
(c) shall be outlined in detail in the certification report.
- The assurance level confirmed in an EUCC certificate may be complemented by the evaluation assurance level as specified in Article 3 of this Regulation.
- If the assurance level confirmed in an EUCC certificate does not refer to an augmentation, the EUCC certificate shall indicate one of the following packages:
(a) the specific assurance package;
(b) the assurance package conformant to a protection profile in case of referencing a protection profile without an evaluation assurance level.
Annex
ANNEX IX
Mark and label
- The form of mark and label:
- If the mark and label are reduced or enlarged, the proportions given in the drawing above shall be respected.
- Where physically present, the mark and label shall be at least 5 mm high.
Metadata
- Type
- Forordning
- År
- 2024
- Ikrafttrædelsesdato
- 1. januar 1970