Scheme document28-09-2026

NI003 - EUCC admission evidence v2.0

1. Introduction

1.1 Purpose

The goal of this document is to provide information on the evidence that needs to be provided by an applicant to the NCCA during the EUCC admission process, depending on the requested scope.

The target audience for this instruction is personnel from the Conformity Assessment Bodies (CAB), namely the CAB managers. Conformity Assessment Bodies is an umbrella term used for both Certification Bodies (CBs) and IT Security Evaluation Facilities (ITSEFs). Where requirements are applicable to both in the same manner, the umbrella term CAB is used. Where this is not the case, the terms CB and ITSEF are used.

The EUCC IR distinguishes between two key concepts to determine whether a CAB is able to perform evaluation or certification activities: expertise and technical competences. Which of these concepts applies depends on the requested scope, as specified in the relevant chapters of this instruction.

  • Expertise is defined by the NCCA as the knowledge level and overall capability of an organisation to perform specific tasks effectively. Expertise operates at the organisational level and reflects how the CAB ensures that it maintains relevant, state-of-the-art knowledge and abilities to carry out its certification or evaluation activities. This includes, for example, staying informed about the latest attack methods and threat landscapes, actively participating in relevant working groups, and maintaining awareness of evolving standards and interpretation guidance.

  • Technical competences are defined by the NCCA as the qualifications, knowledge, skills and experience tracked and maintained at individual level for the performance of specific technical tasks. Technical competences operate at the individual level and are managed through the CAB's competence management system, ensuring that each person involved in certification or evaluation activities possesses and maintains the specific qualifications required for their role.

The distinction between these two concepts is therefore as follows: expertise concerns the collective, organisational capability to stay current and operate effectively within a given domain, whereas technical competences concern the verifiable, individual-level qualifications and skills required to perform assigned technical tasks.

1.2 Scope

This document specifies the contents of the admission evidence that needs to be provided to the NCCA for EUCC admission applications during the admission process described in NP001. It is based on the requirements set out in Articles 21 and 22 of the EUCC Implementing Regulation, and the EUCC Scheme Guidance on the authorisation of CBs and ITSEFs as published by ENISA.

2. Admission scope and applicable evidence

The first step for an applicant is to determine the admission scope to request, as the applicable evidence depends on this scope. The admission scope comprises the assurance level (substantial or high) and optionally CCRA recognition. If assurance level 'high' is claimed, authorisation becomes applicable and the NCCA will perform an authorisation assessment in line with EUCC IR Articles 21 and 22. In that case, the applicant shall explicitly identify the scope components and corresponding AVA_VAN levels that are requested as part of the scope. The scope tables below provide an overview of the available scope attributes and which corresponding chapters of this document are applicable for the required evidence for CBs and ITSEFs.

2.1 Scope attributes and applicable evidence for CBs

Admission scope
Assurance levelSubstantialChapter 3
Substantial & High

Chapter 3

Chapter 4.1, 4.2, 4.3 and 4.5

Additional componentsCertification activities resulting in CCRA-recognised certificates.Chapter 5.1

If assurance level ‘high’ is claimed as part of the admission scope, authorisation is applicable for which the following components can be claimed;

Authorisation scope
Scope components

  • Certification of generic software and network products up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]

  • Certification of smartcards and similar devices up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]

  • Certification of hardware devices with security boxes up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]

  • Certification of protection profiles

  • For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5], please indicate this in the application.

Chapter 4.3.2

2.3 Scope attributes and applicable evidence for ITSEFs

Admission scope
Assurance levelSubstantialChapter 3
Substantial & High

Chapter 3

Chapter 4.1, 4.2, 4.4 and 4.5

Additional componentsEvaluation activities resulting in CCRA-recognised certificates.Chapter 5.2

If assurance level ‘high’ is claimed as part of the admission scope, authorisation is applicable for which the following components can be claimed;

Authorisation scope
Scope components

  • Evaluation of generic software and network products up to and including AVA_VAN.3

  • Evaluation of smartcards and similar devices up to and including AVA_VAN.3

  • Evaluation of hardware devices with security boxes up to and including AVA_VAN.3

  • Evaluation of protection profiles

  • For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including AVA_VAN.3, please indicate this in the application.

Chapter 4.4.1

  • Evaluation of generic software and network products up to and including [AVA_VAN.4 OR AVA_VAN.5]

  • Evaluation of smartcards and similar devices up to and including [AVA_VAN.4 OR AVA_VAN.5]

  • Evaluation of hardware devices with security boxes up to and including [AVA_VAN.4 OR AVA_VAN.5]

  • For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including [AVA_VAN.4 OR AVA_VAN.5], please indicate this in the application.

Chapter 4.4.2


3. General admission evidence

3.1 Business register extract

The CAB shall provide a business register extract to enable the NCCA to validate the context of the application. The extract shall be issued by the official business register of the country or region in which the CAB is established. The extract shall reflect the current registration status of the CAB.

3.2 Accreditation evidence

The CAB shall provide the following accreditation evidence to enable the NCCA to validate the CABs accreditation status and scope:

  1. The formal statement of accreditation issued by the relevant National Accreditation Body;

  2. The accreditation scope;

  3. The final accreditation report issued by the relevant National Accreditation Body or the report on which the formal statement of accreditation is based.

4. Authorisation evidence

Authorisation under EUCC provides the basis for the NCCA to permit a CAB to operate at assurance level 'high' with a specific scope.

This chapter describes the authorisation evidence that a CB or ITSEF shall provide to demonstrate compliance with the authorisation requirements from the corresponding EUCC IR Article 21 or 22. Where the requirements from EUCC IR Articles 21 and 22 are identical for both CBs and ITSEFs, they have been generalised and the term CAB is used. This chapter is also based on the 'EUCC guidelines authorisation of CABs v0.7'.

4.1 General authorisation evidence

The CAB shall provide documentation consisting of the CAB’s organisational structure to provide the NCCA with the context necessary for the effective monitoring and supervision of the additional and specific requirements subject to authorisation. This documentation shall entail, at a minimum, a description of the following elements:

  1. The ICT product categories and protection profiles for which the authorisation is requested (scope of authorisation);

  2. The strategic organisational plans related to the scope of authorisation;

  3. The top management and its responsibilities,

  4. The resources, the competence management system, the key critical roles, and the financing of these roles;

  5. The departments performing the day-to-day business and their responsibilities;

  6. The technical management providing an overview of the technical conformity assessment (certification/evaluation) operations (this includes the related IT & OT responsibilities and systems used & their architecture and the related dependencies on third party service providers);

  7. The roles/functions that have the responsibility for the technical competence management and their succession planning;

  8. The quality management, ensuring that all policies, procedures and measures are in place & retained according to retention policies and are regularly evaluated and audited, and subject to a PDCA cycle;

  9. The compliance management, including the procedures for handling of correction of non-conformities and non-compliances;

  10. The cybersecurity management of the CAB that has a position in the top management with the cybersecurity responsibility and authority to define and implement the required policies and procedures and technical and operational measures (TOMs) for effective information protection of sensitive and confidential information as well as to securely exchange this type of information with their external parties;

  11. Any subcontracting or hiring of external staff by the CAB for its activities is to be described and related contractual responsibilities need to be provided and include the overall responsibility of the CAB. The CAB shall see to it that externals meet the authorisation requirements of the CAB for the subcontracted or hired services;

  12. The financial information related to the CAB organisation, providing information on the financial resources for the elements that are subject to the scope of authorisation, including an overview of the financial dependencies and foreseen financial risks, the resources spent on maintenance of staff competences including learning and development, the resources spent on the cybersecurity including the technical and operational measures related to information protection and cybersecurity training of staff;

4.2 Information protection evidence

CABs operating at assurance level ‘high’ perform conformity assessment activities for ICT products intended for use in high-risk or critical environments. The associated evaluation activities may involve highly sensitive information, including information relating to the ICT product, intellectual property, business secrets, commercially sensitive information, and information concerning the evaluation or certification process itself.

Such information may be of significant interest to highly skilled threat actors with substantial resources. The sensitivity of the information processed by the CAB, together with the relevant threat level and potential impact of a compromise, shall therefore be taken into account when determining the appropriate technical and operational measures (TOMs).

The EUCC Implementing Regulation (IR) sets out requirements in this regard, including requirements for the CAB to have the necessary competences and to implement appropriate technical and operational measures to effectively protect confidential and sensitive information at assurance level ‘high’

4.2.1 Information protection competences

Legal refSource text
EUCC IR article 21 (1)(c)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… …it has the requisite competences… …to effectively protect confidential and sensitive information for assurance level ‘high’
EUCC IR article 22 (1)(c)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… …it has the requisite competences… …to effectively protect confidential and sensitive information for assurance level ’high’

The CAB shall provide documented evidence demonstrating that it has the requisite competences to effectively protect confidential and sensitive information at assurance level ‘high’, in accordance with Annex 3.

4.2.2 Information protection implementation

Legal refSource text
EUCC IR article 21 (1)(c)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… …it has… …put in place appropriate technical and operational measures to effectively protect confidential and sensitive information for assurance level ’high’
EUCC IR article 22 (1)(c)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… …it has… …put in place appropriate technical and operational measures to effectively protect confidential and sensitive information for assurance level ’high’

The CAB shall provide documented evidence demonstrating that appropriate technical and operational measures have been put in place to effectively protect confidential and sensitive information at assurance level ‘high’, in accordance with Annex 3.

4.3 Specific authorisation requirements for CBs

4.3.1 Subcontracting to ITSEF

Legal refSource text
EUCC IR article 21 (1)(a)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… … it conducts its certification activities in cooperation with an ITSEF authorised in accordance with Article 22;

The CB shall provide documentation demonstrating that it conducts its activities in cooperation with authorised ITSEF(s) by providing a proof of the subcontracting contract addressing:

  1. The exchange of information and the conditions that apply;

  2. The aspects/fields of cooperation;

  3. The right of the CB to request information and visit the ITSEF for the purpose of the certification decision;

  4. The elements of cooperation on behalf of compliance activities of the certified product (e.g., activities related to Article 26 EUCC for which it reaches out for support of the ITSEF; the request by the CB to the ITSEF for the support in a sampling procedure; or support in the vulnerability handling procedure;

  5. The collaboration with the ITSEF in the assurance continuity procedure described under Annex IV of EUCC.

4.3.2 Certification activities up to and including AVA_VAN.3/4/5

Claimable scope elements
Certification of generic software and network products up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]
Certification of smartcards and similar devices up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]
Certification of hardware devices with security boxes up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5]
Certification of Protection Profiles
For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including [AVA_VAN.3 OR AVA_VAN.4 OR AVA_VAN.5], please indicate this in the application.
Legal refSource text
EUCC IR article 21 (1)(a)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… … it has the expertise and competences required for the certification decision at assurance level ‘high’;

4.3.2.1 Pilot projects

At least one pilot certification project is required at AVA_VAN.3. The applicant may choose the scope element to which this pilot certification project relates.

Where the applicant seeks admission for one or more scope elements at AVA_VAN.4 or AVA_VAN.5, no separate pilot certification project is required for the AVA_VAN.3 scope elements. Instead, the pilot certification project(s) shall cover the requested AVA_VAN.4/5 scope elements.

Where multiple AVA_VAN.4/5 scope elements are requested, at least one pilot certification project shall be provided for each requested scope element at the respective AVA_VAN level.

The requirements for pilot certification projects apply only to initial admission requests and scope extension requests. No pilot certification project is required for other types of requests.

The CB shall provide the following for each applicable pilot project, in line with Annex 4:

  1. A short introduction of the pilot project's context and scope.

  2. A pilot plan, if applicable.

4.3.2.2 AVA_VAN.3/4/5 certification expertise

The CB shall provide evidence of its expertise required for the certification decision in the requested AVA_VAN.3/4/5 scope elements, covering the expertise areas listed in Annex 1.

4.3.2.3 AVA_VAN.3/4/5 certification technical competences

The CB shall provide evidence of its technical required for the certification decision in the requested AVA_VAN.3/4/5 scope elements, covering the technical competences listed in Annex 2.2.

4.3.3 Outsourcing certification activities

Where the CB outsources certification activities to third parties, the CB shall provide the NCCA with both of the following information:

  1. all information demonstrating the expertise and technical competences of those third parties for the certification activities performed by those third parties within the requested scope; and

  2. an overview of the TOMs applicable to the certification activities performed by those third parties within the requested scope, including the related technical competences required to implement and maintain those TOMs.

4.4 Specific authorisation requirements for ITSEFs

4.4.1 Evaluation activities up to and including AVA_VAN.3

Claimable scope elements
Evaluation of generic software and network products up to and including AVA_VAN.3
Evaluation of smartcards and similar devices up to and including AVA_VAN.3
Evaluation of hardware devices with security boxes up to and including AVA_VAN.3
Evaluation of Protection Profiles
For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including AVA_VAN.3, please indicate this in the application.
Legal refSource text
EUCC IR article 22 (1)(b)(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… … it 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;

4.4.1.1 Pilot projects

At least one pilot evaluation project is required at AVA_VAN.3. The applicant may choose the scope element to which this pilot evaluation project relates.

Where the applicant seeks admission for one or more scope elements at AVA_VAN.4 or AVA_VAN.5, no separate pilot evaluation project is required for the AVA_VAN.3 scope elements. Instead, the pilot evaluation project(s) shall cover the requested AVA_VAN.4/5 scope elements.

The requirements for pilot certification projects apply only to initial admission requests and scope extension requests. No pilot certification project is required for other types of requests.

The ITSEF shall provide the following for each applicable pilot project, in line with Annex 4:

  1. A short introduction of the pilot project's context and scope.

  2. A pilot plan, if applicable.

4.4.1.2 AVA_VAN.3 evaluation expertise

The ITSEF shall provide evidence of its expertise for the requested AVA_VAN.3 scope elements, covering the expertise areas listed in Annex 1.

4.4.2 Evaluation activities up to and including AVA_VAN.4/5

Claimable scope elements
Evaluation of generic software and network products up to and including [AVA_VAN.4 OR AVA_VAN.5]
Evaluation of smartcards and similar devices up to and including [AVA_VAN.4 OR AVA_VAN.5]
Evaluation of hardware devices with security boxes up to and including [AVA_VAN.4 OR AVA_VAN.5]
For any new or upcoming technical domains and/or State-of-the-art Protection Profiles not listed above but envisioned to be included in the requested scope at up to and including [AVA_VAN.4 OR AVA_VAN.5], please indicate this in the application.
Legal refSource text
EUCC IR article 22 (1)(b)(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… … for the technical domains and protection profiles, which are part of the ICT process for those ICT products, it has… …the 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;
EUCC IR article 22 (1)(b)(2)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… … for the technical domains and protection profiles, which are part of the ICT process for those ICT products, it has… …the technical competences as specified in the state-of-the-art documents listed in Annex I.

4.4.2.1 Pilot projects

If an AVA_VAN.4 or AVA_VAN.5 scope element is requested, at least one pilot evaluation project is required at the corresponding AVA_VAN level.

Where multiple AVA_VAN.4/5 scope elements are requested, at least one pilot evaluation project shall be provided for each requested scope element at the respective AVA_VAN level.

The requirements for pilot evaluation projects apply only to initial admission requests and scope extension requests. No pilot evaluation project is required for other types of requests.

The ITSEF shall provide the following for each applicable pilot project, in line with Annex 4:

  1. A short introduction of the pilot project's context and scope.

  2. A pilot plan, if applicable.

4.4.2.2 AVA_VAN.4/5 evaluation expertise

The ITSEF shall provide evidence of its expertise in the requested AVA_VAN.4/5 domains, covering the expertise areas listed in Annex 1.

4.4.2.3 AVA_VAN.4/5 evaluation technical competences

The ITSEF shall provide evidence of its technical competences in the requested AVA_VAN.4/5 domains, covering the technical competences listed in Annex 2.1.

4.4.3 Outsourcing evaluation activities

Where the ITSEF outsources evaluation activities to third parties, the ITSEF shall provide the NCCA with both of the following information:

  1. all information demonstrating the expertise and, if applicable, technical competences of those third parties for the evaluation activities performed by those third parties within the requested scope; and

  2. an overview of the TOMs applicable to the evaluation activities performed by those third parties within the requested scope, including the related technical competences required to implement and maintain those TOMs.

4.5 Assurance reports

Legal refSource text

EUCC IR article 21 (2) and;

EUCC IR article 22 (3)

… In its assessment, the national cybersecurity certification authority may reuse any appropriate evidence from prior authorisation or similar activities granted pursuant to: (a) this Regulation; (b) another European cybersecurity certification scheme adopted pursuant to Article 49 of Regulation (EU) 2019/881; (c) a national scheme referred to in Article 49 of this Regulation.

The applicant may provide reports from previous assessments that provide assurance regarding the fulfilment of requirements relevant to the EUCC authorisation, including:

  1. Authorisation reports issued by another National Cybersecurity Certification Authority (NCCA); and

  2. Accreditation reports issued by a National Accreditation Body (NAB), where the accreditation assessment covered requirements that are also relevant to the EUCC authorisation assessment.

The NCCA may take such reports into account as supporting assurance when conducting the EUCC authorisation assessment. Where appropriate, the NCCA may rely on the assurance provided by the report without repeating the assessment activities underlying its findings.

Where such reliance provides sufficient assurance for the purposes of the EUCC authorisation, the NCCA may reduce the scope of its audit or conduct the remaining assessment activities remotely. The NCCA may also determine that no further audit is necessary, provided that the assurance report(s) provide sufficient information for the NCCA to understand the CAB’s capabilities and performance and thereby enable the NCCA to effectively perform its supervision of certification projects.

5. CCRA evidence

The contents of this chapter are based on the ‘EUCC/CCRA co-existence’ document, and serves to further provide instructions on how compliance with these CCRA requirements shall be demonstrated.

The CCRA uses the term licensing for the act of granting Certification Bodies and ITSEFs permission to perform CCRA-recognised certification and evaluation activities.

In the EUCC context, the NCCA uses the term admission instead. This reflects the nature of the relationship between the NCCA and the CAB: admission is not based on a bilateral agreement between the NCCA and the CAB, but on a one-way decision by the NCCA granting the CAB permission to perform the relevant activities, subject to specific conditions and ongoing oversight.

Accordingly, to reflect this relationship more accurately, the term ‘CCRA admission’ is used throughout this chapter.

5.1 CCRA CB admission

Claimable scope elements
Certification activities resulting in CCRA-recognised certificates.

5.1.1 Conditions and obligations for CCRA CB admission

A CB admitted to perform certification activities resulting in CCRA-recognised certificates shall:

  • enable the NCCA to perform the required per-certificate oversight by following the NP002 certification process for all EUCC certification projects for which CCRA recognition is sought, regardless of the assurance level claimed, including submitting the assessment plan for NCCA approval and submitting the proposed certificate and certification report for NCCA approval;

  • not issue a certificate bearing CCRA recognition without the NCCA's prior approval;

  • where the NCCA withdraws its approval, cease to represent the certificate as CCRA-recognised and take appropriate action to ensure that the certificate no longer benefits from or represents CCRA recognition; and

  • cooperate with the CCRA Voluntary Periodic Assessment (VPA), including by providing the necessary personnel, resources and documentation and cooperating with the VPA team as required.

5.1.2 CCRA CB admission evidence

The CB shall provide documentation enabling the NCCA to:

  • Take a concrete look at the CB’s working methods to validate that;

    • that the CB has implemented controls to remain up-to-date on new CCRA publications; and

    • that the implemented security measures and, where available, the associated security policy to understand the context of the measures used are sufficient to protect the confidential information processed in CCRA projects.

  • Take a concrete look at the CB’s CC-procedures to validate that;

    • that the evaluation and/or certification procedures to be used for CCRA projects are aligned with the Dutch EUCC processes.

  • Take a concrete look at the CB’s technical competency to validate that;

    • that the CB’s competence management system and competence matrix are consistent, sufficiently detailed, and demonstrate that the CB possesses the competences necessary to perform CCRA projects.

5.2 CCRA ITSEF admission

Claimable scope elements
Evaluation activities resulting in CCRA-recognised certificates.

The ITSEF shall provide documentation enabling the NCCA to:

  • Take a concrete look at the ITSEFs working methods to validate that;

    • the ITSEF has implemented controls to remain up-to-date on new CCRA publications; and

    • the implemented security measures and, where available, the associated security policy to understand the context of the measures used are sufficient to protect the confidential information processed in CCRA projects.

  • Take a concrete look at the ITSEFs CC-procedures to validate that;

    • the evaluation procedures to be used for CCRA projects are aligned with the Dutch EUCC processes.

  • Take a concrete look at the ITSEFs technical competency to validate that;

    • the ITSEFs competence management system and competence matrix are consistent, sufficiently detailed, and demonstrate that the ITSEF possesses the competences necessary to perform CCRA projects.

A.1 EUCC authorisation expertise areas

For ITSEFs: The ITSEF should provide evidence demonstrating the ITSEF's expertise to:

For CBs: The CB should provide evidence demonstrating the CB's expertise to review the ITSEF's capability to:

  1. Analyse threats and risks using up-to-date threat intelligence, and translate the results into evaluation methodologies;

  2. Design and perform risk-based evaluation methodologies, including structured procedures and flaw hypothesis methodology as required by ISO/IEC 18045, to test resilience against state-of-the-art cyberattacks by skilled attackers with significant resources;

  3. Translate cyberattack techniques into appropriate evaluation methodologies, recognising that the same vulnerability may be identified through multiple testing methods;

  4. Perform and evaluate attack potential calculations using the table provided by ISO/IEC 18045, and where applicable apply the state-of-the-art document specified in Annex I EUCC for the relevant technical domain;

  5. Understand the capabilities and limitations of evaluation tools, including development, analysis and attack tools, and find workarounds where necessary to determine the level of resistance of the ICT product or protection profile;

  6. Describe evaluation activities and findings in a technically sound, consistent, verifiable, logical and structured manner that remains accessible to non-evaluators;

  7. Demonstrate expertise in cryptographic algorithms, protocols, and evaluations, including the ability to identify well-known vulnerabilities in cryptographic implementations;

  8. Apply technology-specific knowledge of the product type in scope, including its architecture, features, development processes, implementation methods, known vulnerabilities, and relevant attack patterns;

  9. Select, justify and apply source code analysis techniques, penetration testing approaches (Black-box, Grey-box, White-box), and associated debugging tools;

  10. Select, justify and use appropriate evaluation tools, including open source, commercial, AI-based, and hardware attack tools;

  11. Perform enhanced-basic and complex reverse engineering;

  12. Monitor ICT product or protection profile evaluations where applicable for the technical domains, including tracking evolving interpretations and guidance that may impact ongoing evaluations;

  13. Process the Evaluation Technical Report in accordance with Article 10(4) EUCC, including the ability to write clear, correct English;

  14. Develop procedures for the administrative handling, maintenance and retention of documentation in accordance with quality management requirements;

  15. Technically support the CB in vulnerability handling by analysing impact assessments and performing evaluation checks to verify remediation measures.

A.2 EUCC technical competence areas

A.2.1 ITSEF technical competences

The ITSEF should provide evidence demonstrating that it possesses and is able to maintain technical competences in at least the following areas:

  1. Where the scope of authorisation is related to a specific technical domain or a specific protection profile describing specific evaluation methods, the specific technical competences indicated in the applicable state-of the-art document listed under Annex I Commission Implementing Regulation (EU) 2024/482 should be demonstrated.

A2.2 CB Technical competences

The CB should provide evidence demonstrating that it possesses and is able to maintain technical competences in at least the following areas:

  1. The ability to review, assess and validate the work of the ITSEF performed under assurance level 'high' for the authorisation scope, including the analysis and review of the Evaluation Technical Report;

  1. The drafting of the certification report (including the sanitization of a security target in accordance with Annex V, section V.2 EUCC);

  1. The task to analyse, process and document the findings and to provide technical and procedural recommendations related to the evaluation activities performed by the ITSEF;

  1. The task to make certification decisions related to the issuance, suspension, restriction and withdrawal of certificates in accordance with the procedures, and to monitor the conditions for issuance of an EUCC certificate;

  1. The handling of procedures related to vulnerability handling and patch management, assurance continuity, compliance monitoring and complaints.

A.3 The technical & organisational measures (TOMs)

The CAB should implement appropriate TOMs. The appropriateness of the TOMs should be determined taking into account the following principles:

  1. They should be defined based on a risk assessment performed by the CAB that takes into account the degree of the entity’s exposure to relevant risks.

  2. They should take the organisational context into account, including TOMs and security measures provided by a larger entity of which the CAB forms part;

  3. They should take into account the likelihood of occurrence of incidents and their potential severity, including their societal and economic impact;

  4. They should follow an all-hazards approach aimed at protecting the network and information systems and physical environment of the CAB against relevant threats and incidents;

  5. They should be regularly reviewed for their overall appropriateness and effectiveness, with the results informing a continuous improvement cycle.

The following factors should also be considered by a CAB when defining and assessing the appropriateness of its TOMs:

  1. CABs should ensure that appropriate arrangements are in place to protect information exchanged between the CB and the ITSEF and any systems or assets shared between them. The CB is responsible for ensuring that such arrangements are sufficiently secure. Where these arrangements are not fully in place, the CB and ITSEF should work together to ensure that the necessary arrangements are established.

  2. CABs should ensure that their TOMs adequately support the applicable security objectives set out in Article 51 CSA, taking into account the nature and sensitivity of the activities performed and information processed within their scope of operation.

  3. CABs should have a process for determining and regularly testing the effectiveness of their TOMs, including, where appropriate, consideration of established standards and tested or certified products and technologies. Testing may include, as appropriate, checks of physical alarms, assessments of staff security awareness, or penetration testing of relevant security controls.

To implement these principles, the CAB should establish, implement, maintain and periodically review appropriate TOMs addressing the following domains:

  1. Risk assessment and risk analysis;

  2. Business continuity, such as backup management and disaster recovery, and crisis management;

  3. Incident handling including reporting to the NCCA and CSIRT which should follow:

    1. For the reporting of incidents to the CSIRT, the CAB should follow a procedure analogous to that set out in Article 23 of NIS2;

  4. Supply chain security, including security-related aspects concerning the relationships and transfers of data between each entity and of its direct suppliers or service providers taking into account the following:

    1. the vulnerabilities specific to each direct supplier and service provider

    2. the overall quality of their services and cybersecurity practices of their suppliers and service providers, including their secure development and lifecycle procedures.

  5. Security in network and information systems including their acquisition, development and maintenance, including vulnerability handling and a coordinated vulnerability disclosure policy. It is advisable to review international standards like the ISO/IEC 2700x series or national standards for suitable content. These systems should be appropriately documented;

  6. Cryptography policy and effective encryption mechanisms including the appropriate use of encryption to store sensitive data at rest (e.g.: hard disk encryption) and in transit (i.e. outside the control of the CAB, e.g. for e-mail, voice/video or physical media transported outside the CAB). Choice and strength of algorithms should be based on risk situation and the state of cryptography (e.g.: length of keys, use of quantum-safe algorithms).

  7. Human resources security, commensurate to the estimated attackers for tangible evaluation and certification assets. This focuses on preventive measures and should include reactive measures in case of incidents as well, which is entailing amongst others:

    1. Non-CAB personnel with temporary access to assets of the CAB (e.g.: visitors, external functions or companies) ensuring that their access is limited as much as possible and supervised;

    2. Overall access policy to assets of the CAB for CAB personnel, based on the need-to-know and need-to-be principles and including an authentication policy consisting of multi-factor authentication. Additionally, the CAB should operate a policy for secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. This implies logical access rules commensurate to the risk of the individual devices (i.e.: network context, attack surface) using multi-factor authentication where technically possible and requiring sufficient strong mechanisms (e.g.: length of passwords);

    3. A staff integrity screening policy for those persons that have access upon the need-to know-and need-to-be principles to confidential and sensitive information obliging to perform an integrity screening on a regular basis;

    4. Basic cyber hygiene practices and cybersecurity training;

    5. A policy related to work ethics with special attention for:

      1. Fraud prevention;

      2. Prevention of inside intruder incidents leading to leaking of information by: espionage, or deliberate publication of confidential information;

      3. Neglect of duty to meet cybersecurity requirements;

      4. Encouragement of reporting personal security incidents and use of these cases for cybersecurity awareness (training) programs;

  8. Physical security;

  9. Asset management including reduced network connectivity for devices used in the context of the CAB to limit the attack surface, e.g.: dedicated networks for CAB activities; Trustworthy software installation and maintenance (upgrade) procedures including measures to limit access of 3rd parties on CAB assets during installation/upgrade;

  10. Safe and secure destruction policy of media;

  11. Where artificial intelligence (AI) is used for conformity assessment activities, the CAB TOMs to handle AI specific risks, e.g., accuracy or robustness;

For the assessment of the appropriateness of the measures implemented by an ITSEF for the domains set out in points 1–11, the NCCA uses the Minimum Site Security Requirements (MSSR) as a reference framework.

A.4 Requirements for pilot project(s)

A pilot project should meet the following requirements to facilitate assessment by the NCCA:

  1. The product being assessed should fall within the scope and, where applicable, the technical domain of ICT products for which authorisation is requested.

  1. The product should be assessed at the assurance level for which authorisation is requested, including the associated AVA_VAN level where applicable (e.g. AVA_VAN.4 or AVA_VAN.5).

  1. The product should be assessed in accordance with one of the following:

    1. In the Netherlands, in accordance with OP002 -- EUCC processes, with a pilot evaluation and/or certification plan prepared for the assessment;

    2. Under the EUCC implementation of another EU Member State; or

    3. Under a national scheme recognised under the SOG-IS MRA, provided that the assessment demonstrates compliance with the applicable EUCC requirements.

  2. The assessment results, as documented in the Evaluation Technical Report (ETR) or Certification Report (CR), should preferably not be more than six months old at the time of application. Older assessment results may be accepted subject to approval by the NCCA.

  3. For each technical domain, State-of-the-art Protection Profile or other scope component requested for admission at AVA_VAN.4/5, a pilot assessment should be performed.

When submitting a pilot project, a short introduction of the pilot projects context and scope should be attached.

If option 3a is applicable, a pilot evaluation and/or certification plan should be drafted.

Depending on the context, an ITSEF can draft a pilot evaluation plan, a CB can draft a pilot certification plan, or, when both the ITSEF and the CB are in need of a pilot project, they can collaborate to draft a pilot evaluation and certification plan.

In general, the pilot evaluation and/or certification plan should contain, as applicable, the following:

TOE descriptionThe ICT product or Protection Profile must be clearly defined with a TOE description. The TOE description should demonstrate understanding of the architecture, security functionality, and anticipated technical challenges, including how these will be addressed.
(draft) Security TargetThe developer has drafted a ST that describes the TOE in sufficient detail to enable the evaluation to be performed. The logical and physical boundaries of the TOE must be clearly defined. The Security Problem Definition and Security Objectives must be complete and coherent.
Evaluation MethodologyMethods, depth of analysis, and testing strategy should be clearly described and justified.
Tools and TechniquesTools, test environments, location of testing activities and analysis techniques should be specified and appropriate to the technology under evaluation
Team CompositionEvaluation and/or certification team members and roles should be identified. Selection should reflect (past) relevant competence and experience.
Re-use of EvidenceAny re-use of evidence from previous evaluations and/or certifications should be stated and justified.
IndependenceThe independence of the evaluation team from the developer should be confirmed, including disclosure of consultancy or other relationships.
Developer Risk AcceptanceThe customer must formally acknowledge the pilot nature of the activity and that the pilot evaluation and/or certification itself does not automatically constitute certification under the EUCC.