Commission Implementing Regulation (EU) 2024/482 of 31 January 2024 laying 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)

• (a) EN 419241-2:2019 – Trustworthy Systems Supporting Server Signing – Part 2: Protection Profile for QSCD for Server Signing (v0.16), ANSSI-CC-PP-2018/02-M01;

• (b) EN 419221-5:2018 – Protection profiles for Trust Service Provider Cryptographic modules – Part 5: Cryptographic Module for Trust Services (v0.15), ANSSI-CC-PP-2016/05-M01.

• 2.Protection profiles that have been adopted as state-of-the-art documents:

• [BLANK].

ANNEX III

Recommended protection profiles

Protection profiles used in certification of ICT products including products in the technical domains:

• 1. Smartcards and similar devices:
• (a) passport:
• (1) PP Machine Readable Travel Document with ‘ICAO Application’ Basic Access Control (v1.10), BSI-CC-PP-0055-2009;
• (2) PP Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE_PP) (v1), BSI-CC-PP-0068-V2-2011-MA-01;
• (3) PP Machine Readable Travel Document with ‘ICAO Application’ Extended Access Control with PACE (v1.3), BSI-CC-PP-0056-V2-2012-MA-02;
• (b) Secure Signature Creation Devices (SSCD):
• (1) EN 419211-2:2013 – Protection profiles for secure signature creation device – Part 2: Device with key generation (v1.03), BSI-CC-PP-0059-2009-MA-02;
• (2) EN 419211-3:2013 – Protection profiles for secure signature creation device – Part 3: Device with key import (v1.0.2), BSI-CC-PP-0075-2012-MA-01;
• (3) 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 (v1.0.1), BSI-CC-PP-0071-2012-MA-01;
• (4) 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 (v1.0.1), BSI-CC-PP-0072-2012-MA-01;
• (5) 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 (v1.0.4), BSI-CC-PP-0076-2013-MA-01;
• (c) tachograph: Digital Tachograph – Tachograph Card (TC PP) (v1.0), BSI-CC-PP-0091-2017;
• (d) secure IC, Java Card platform and eUICC:
• (1) Universal SIM Java Card Platform Protection Profile Basic and SCWS Configurations (v2.0.2), ANSSI-CC-PP-2010/04 (Basic), ANSSI-CC-PP-2010/05 (Basic and SCWS);
• (2) Security IC Platform PP with Augmentation Packages (v1.0), BSI-CC-PP-0084-2014;
• (3) Embedded UICC (eUICC) for Machine-to-Machine Devices (v1.1), BSI-CC-PP-0089-2015;
• (4) Cryptographic Service Provider – CSP (v0.9.8), BSI-CC-PP-0104-2019;
• (5) Cryptographic Service Provider – Time Stamp Service and Audit (PPC-CSP-TS-Au) Version 0.9.5, BSI-CC-PP-0107-2019;
• (6) Configuration Cryptographic Service Provider – Time Stamp Service, Audit and Clustering (PPC-CSP-TS-Au-Cl) Version 0.9.4, BSI-CC-PP-0108-2019;
• (7) Java Card System – Closed Configuration (v3.1), BSI-CC-PP-0101-V2-2020;
• (8) Secure Element Protection Profile – GPC_SPE_174 (v1.0), CCN-CC-PP-5-2021;
• (9) Secure Sub-System in System-on-Chip (3S in SoC) Protection Profile (v1.8), BSI-CC-PP-0117-V2-2023;
• (10) Java Card System – Open Configuration (v3.2), BSI-CC-PP-0099-V3-2024;
• (11) Embedded UICC for Consumer Devices Protection Profile (v2.1), BSI-CC-PP-0100-V2-2025;
• (e) Trusted Platform Module: Protection Profile PC Client Specific Trusted Platform Module Specification Family 2.0; Level 0; Revision 1.59 (v1.3), ANSSI-CC-PP-2021/02.

• 1. Hardware Devices with Security Boxes:
• (a) points of (payment) interaction and payment terminals (POI):
• (1) Point of Interaction ‘POI-CHIP-ONLY’ (v4.0), ANSSI-CC-PP-2015/01;
• (2) Point of Interaction ‘POI-CHIP-ONLY and Open Protocol Package’ (v4.0), ANSSI-CC-PP-2015/02;
• (3) Point of Interaction ‘POI-COMPREHENSIVE’ (v4.0), ANSSI-CC-PP-2015/03;
• (4) Point of Interaction ‘POI-COMPREHENSIVE and Open Protocol Package’ (v4.0), ANSSI-CC-PP-2015/04;
• (5) Point of Interaction ‘POI-PED-ONLY’ (v4.0), ANSSI-CC-PP-2015/05;
• (6) Point of Interaction ‘POI-PED-ONLY and Open Protocol Package’ (v4.0), ANSSI-CC-PP-2015/06;
• (b) Hardware Security Module:
• (1) Cryptographic Module for CSP Signing Operations with Backup – PP CMCSOB 14167-2 (v0.35), ANSSI-CC-PP-2015/08;
• (2) Cryptographic Module for CSP Key Generation Services – PP CMCKG 14167-3 (v0.20), ANSSI-CC-PP-2015/09;
• (3) Cryptographic Module for CSP Signing Operations without Backup – PP CMCSO 14167-4 (v0.32), ANSSI-CC-PP-2015/10;
• (c) tachograph:
• (1) Digital Tachograph – Motion Sensor (MS PP) (v1.0), BSI-CC-PP-0093-2017;
• (2) Digital Tachograph – Vehicle Unit (VU PP) (v1.15), BSI-CC-PP-0094-V2-2021;
• (3) Digital Tachograph – External GNSS Facility (EGF PP) (v1.10), BSI-CC-PP-0092-V2-2021.

• 1. Others: Trusted Execution Environment Protection Profile – GPD_SPE_021 (v1.3), ANSSI-CC-PP-2014/01-M02.

ANNEX IV

Assurance continuity and certificate review

IV.1   Assurance continuity: scope

• 1.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.

• 2.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

• 1.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.

• 2.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.

• 3.The ITSEF shall describe the changes and detail the results of the re-assessment with an update of the previous evaluation technical report.

• 4.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 or Article 19. If the re-assessment process is successful, Article 13 paragraph 2 points (a) or (c) applies in the case of the certification of a product and Article 19 paragraph 2 point (a) or (c) applies in the case of the certification of a protection profile. If the re-assessment process is not successful, Article 13 paragraph 2 point (b) or (d) applies in the case of the certification of a product and Article 19 paragraph 2 point (b) or (d) applies in the case of the certification of a protection profile.

• 5.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 – Maintenance and re-evaluation

• 1.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.

• 2.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.

• 3.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.

• 4.Following the examination, the certification body determines the scale of a change as minor or major in correspondence to its impact on the assurance expressed in the EUCC certificate.

• 5.Where the changes have been confirmed by the certification body to be minor, no new certificate shall be issued for the modified ICT product in accordance with Article 13 paragraph 2 point (a) or Article 19 paragraph 2 point (a) and a maintenance report to the initial certification report shall be established.

• 5.a.In case of any changes to the assurance measures in the development environment, including the addition of assurance requirements from the CC ALC_FLR family (Flaw remediation), the certification body may request the ITSEF to perform a subset evaluation of the affected assurance measures. The ITSEF shall issue a partial evaluation technical report, based on which the certification body confirms the changes to be either minor or major. Where the changes have been confirmed by the certification body to be minor, Annex IV.3 point 5 shall apply. Where the changes have been confirmed by to the certification body to be major, Annex IV.3 point 7 shall apply.

• 6.The maintenance report referred to in point 5 shall be provided to ENISA for publication on its cybersecurity certification website.

• 7.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.

• 8.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.

• 9.The new certificate and certification report shall be provided to ENISA for publication.

IV.4   Patch management

• 1.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.

• 2.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.

• 3.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.

• 4.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.

• 5.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.

• 6.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 V

CONTENT OF A CERTIFICATION REPORT

V.1   Certification report

• 1.Based on the evaluation technical reports provided by the ITSEF, the certification body establishes a certification report to be published together with the corresponding EUCC certificate and security target.

• 2.The certification report is the source of detailed and practical information about the ICT product and about the ICT product’s secure deployment. It shall therefore include all publicly available and sharable information of relevance to users and interested parties. Publicly available and sharable information may be referenced by the certification report.

• 3.The certification report shall contain at least the following information:

• (a) executive summary;

• (b) identification of the ICT product;

• (c) contact information related to the evaluation of the ICT product;

• (d) security policies;

• (e) assumptions and clarification of scope;

• (f) architectural information;

• (g) supplementary cybersecurity information, if applicable;

• (h) ICT product evaluation summary and evaluated configuration;

• (i) results of the evaluation and information regarding the certificate;

• (j) comments and recommendations if applicable;

• (k) annexes, if applicable;

• (l) reference to the security target of the ICT product submitted to certification;

• (m) when available, the mark or label associated to the scheme;

• (n) glossary, if applicable;

• (o) bibliography.

• 4.The executive summary referred to in paragraph 3, point (a) shall be a brief summary of the entire certification report. It shall provide a clear and concise overview of the evaluation results and shall include the following information:

• (a) name of the evaluated ICT product;

• (b) name of the ITSEF which performed the evaluation;

• (c) completion date of evaluation;

• (d) date of issuance of the certificate;

• (e) where applicable, date of issuance of the initial certificate;

• (f) validity period;

• (g) unique identification of the certificate as described in Article 11;

• (h) brief description of the certification report results, including:
• (i) the version and if applicable release of the Common Criteria applied to the evaluation;
• (ii) the Common Criteria assurance package or list of security assurance components, the AVA_VAN level applied during the evaluation and the corresponding assurance level as set out in Article 52 of Regulation (EU) 2019/881 to which the EUCC certificate refers to;
• (iii) where applicable, the Protection Profile(s) to which the ICT product is claiming compliance to;
• (iv) reference to the security policy of the evaluated ICT product;
• (v) disclaimer(s), if applicable.

• 5.The identification referred to in paragraph 3, point (b) shall clearly identify the evaluated ICT product, including the following information:

• (a) the unique identification of the evaluated ICT product;

• (b) enumeration of the ICT product’s components that are part of the evaluation with version number of each component;

• (c) reference to additional requirements to the operational environment of the certified ICT product.

• 6.The contact information referred to in paragraph 3, point (c) shall include at least the following information:

• (a) name of the developer;

• (b) name and contact information of the holder of the EUCC certificate;

• (c) name of the certification body that issued the certificate;

• (d) responsible national cybersecurity certification authority;

• (e) name of the ITSEF which performed the evaluation, and, where applicable, the list of subcontractors.

• 7.The security policy referred to in paragraph 3, point (d), shall contain the description of the ICT product’s security policy as a collection of security services and the policies or rules that the evaluated ICT product shall enforce or comply with. It shall also include the following information:

• (a) a description of the vulnerability management and vulnerability disclosure procedures of the certificate holder, to be completed solely with information that can be made publicly available;

• (b) the assurance continuity policy of the holder of the certificate, including, where applicable, the description of the certificate holder’s lifecycle management or production processes in accordance with Section IV.1 of Annex IV;

• (c) where applicable, the presence of patch management procedure and the outcome of its assessment in accordance with Section IV.4 of Annex IV.

• 8.The assumptions and clarification of scope referred to in paragraph 3, point (e), shall contain information regarding the circumstances and objectives related to the intended use of the product as referred to in Article 7(1), point (c) and 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;

• (c) description of any threats to the ICT product that are not countered by the evaluated security functions of the product according to the intended use, if deemed relevant for a potential ICT product user.

• The information referred to in the first subparagraph shall be as clear and understandable as possible to enable potential users of the certified ICT product to make informed decisions about the risks associated with its use.

• 9.The architectural information referred to in paragraph 3, point (f), shall include a high-level description of the ICT product and its main components, based on the deliverables defined in the Common Criteria assurance family: Development – TOE Design (ADV_TDS).

• 10.The supplementary cybersecurity information referred to in paragraph 3, point (g) shall include the link to the website of the holder of the EUCC certificate referred to in Article 55 of Regulation (EU) 2019/881.

• 11.The ICT product evaluation and configuration referred to in paragraph 3, point (h), shall describe both the developer and evaluator testing effort, outlining the testing approach, configuration and depth. It shall include at least the following information:

• (a) an identification of the used assurance components from the standards referred in Article 3;

• (b) the version of the state-of-the-art documents and further security evaluation criteria used in the evaluation;

• (c) the settings and configuration of the TOE used for the testing and vulnerability analysis;

• (d) any protection profile that has been used, including the following information: the protection profile name, version, date and certificate.

• 12.The results of the evaluation and information regarding the certificate referred to in paragraph 3, point (i) shall include information on the attained assurance level as referred to in Article 4 of this Regulation and Article 52 of Regulation (EU) 2019/881.

• 13.The comments and recommendations referred to in paragraph 3, point (j), are used to impart additional information about the evaluation results. Those comments and recommendations may take the form of shortcomings of the ICT product discovered during the evaluation or mentions of features which are particularly useful.

• 14.The Annexes referred to in paragraph 3, point (k), are used to outline any additional information that may be useful to the audience of the report but does not logically fit within the prescribed sections of the report, including in cases of a complete description of security policy.

• 15.The security target referred to in paragraph 3, point (l), shall reference the evaluated security target. The evaluated security target shall be provided with the certification report for the purposes of publication on the website referred to in Article 50(1) of Regulation (EU) 2019/881. Where sanitisation of the evaluated security target is necessary prior to publication, it shall be done in accordance with point V.2 of Annex V to this Regulation.

• 16.The marks or labels associated to the EUCC scheme referred to in paragraph 3, point (m), shall be inserted in the certification report in accordance with the rules and procedures laid down in Article 11.

• 17.The Glossary referred to in paragraph 3, point (n), is used to increase the readability of the report by providing definitions of acronyms or terms of which the meanings may not be readily apparent.

• 18.The bibliography referred to in paragraph 3, point (o), 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;

• (b) the evaluation technical report;

• (c) the evaluation technical report for composite evaluation, where applicable;

• (d) technical reference documentation;

• (e) developer security guidance;

• (f) developer configuration list.

• 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

• 1.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.

• 2.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.

• 3.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.

• 4.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 VI

SCOPE AND TEAM COMPOSITION FOR PEER ASSESSMENTS

VI.1   Scope of the peer assessment

• 1.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.

• 2.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

• 1.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.

• 2.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.

• 3.For a Type 2 peer assessment the team members shall be selected from certification bodies being authorised for the concerned technical domain.

• 4.Each member of the assessment team shall have at least two years of experience of carrying out certification activities in a certification body;

• 5.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

• 6.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.

• 7.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 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 VIII

Assurance package declaration

• 1.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.

• 2.The assurance level confirmed in an EUCC certificate may be complemented by the evaluation assurance level as specified in Article 3 of this Regulation.

• 3.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 IX

Mark and label

• 1.The form of mark and label:

• Image omitted; see official source

• 2.If the mark and label are reduced or enlarged, the proportions given in point 1 shall be respected.

• 3.Where physically present, the mark and label shall be at least 5 mm high.

[^E0001]: Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (OJ L 139, 26.5.2016, p. 1, ELI: http://data.europa.eu/eli/reg_impl/2016/799/oj).

[^E0002]: Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (OJ L 257, 28.8.2014, p. 73, ELI: http://data.europa.eu/eli/reg/2014/910/oj).

[^E0003]: Commission Implementing Decision (EU) 2016/650 of 25 April 2016 laying down standards for the security assessment of qualified signature and seal creation devices pursuant to Articles 30(3) and 39(2) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market (OJ L 109, 26.4.2016, p. 40, ELI: http://data.europa.eu/eli/dec_impl/2016/650/oj).

[^E0004]: 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).