NI003 - EUCC licensing evidence

Scheme document | 04-10-2024

📄 Document information

1. Introduction

1.1 Purpose

The goal of this document is to provide information on what accreditation, and where applicable what authorisation evidence needs to be provided to the NCCA during the licensing process.

The target audience for this instruction is personnel from the Conformity Assessment Bodies (CAB), namely the CAB managers.

1.2 Scope

This document addresses the contents of the accreditation and authorisation evidence as specified in NP001 - Licensing process. It is based on the EUCC Scheme Guidance on the authorisation of CBs and ITSEFs as published by ENISA.

1.3 Involved roles

Roles identified in the EUCC licensing evidence instruction:

Role name	Responsible entity	Description of responsibility
CAB manager	CAB	Person at the CAB that is in charge of obtaining a licensing status under the Dutch NCCA.

2. EUCC licensing evidence

Accreditation evidence shall always be provided for licensing requests. Authorisation evidence is only necessary if the requested licensing scope includes the assurance level ‘high’.

2.1    Accreditation evidence

Necessary accreditation evidence that shall be provided to start the licensing process includes at least:

1. The formal statement of accreditation issued by the NAB;
2. The accreditation report issued by the NAB;
3. For ITSEFs the Dutch CB under which the evaluation activities will be performed;
   For CBs the ITSEFs to which evaluation activities will be outsourced.

The requested accreditation evidence shall clearly indicate the accreditation scope, which shall be in alignment with the requirements specified in the relevant State-of-the-art document.

If the accreditation has not been completed yet, the CAB shall provide the accreditation request and a statement of the NAB that they are in the process of handling the application, or are in process of accreditation. The formal decision on licensing request can only take place after the delivery of the necessary accreditation evidence specified above.

2.2    Authorisation evidence

Authorisation under EUCC serves the specific purpose to allow attesting that CAB has the technical competences for their conformity assessment activities where the ICT product or protection profile is to be certified under assurance level ‘high’ and has put in place appropriate technical and operational measures to effectively protect confidential and sensitive information for that assurance level.

EUCC provides under Article 21 the overview of the requirements related to the authorisation of Certification Bodies (CBs). The requirements for Information Technology Security Evaluation Facilities (ITSEFs) are defined under Article 22 EUCC. This NCCA instruction is based on the ‘EUCC guidelines authorisation of CABSs v0.7’, and serves to further provide instructions on how compliance with these authorisation requirements shall be demonstrated.

Necessary authorisation evidence that shall be provided to start the licensing process includes at least:

1. Documentation consisting of the CABs organisation structure for the purpose of having the correct context necessary for effective monitoring and supervision of the additional and specific requirements that are subject to authorisation. This documentation shall entail at least a description of those elements that fall under the scope of authorisation:
   • The ICT product categories and protection profiles for which the authorisation is requested (scope of authorisation);
   • The strategic organisational plans related to the scope of authorisation;
   • The top management and its responsibilities,
   • The resources, and the competence management system the key critical roles and financing of the roles;
   • The departments performing the day-to-day business and their responsibilities;
   • 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);
   • The roles/functions that have the responsibility for the technical competence management and their succession planning;
   • 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;
   • The compliance management, including the procedures for handling of correction of non-conformities and non-compliances;
   • 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 organisational 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;
   • Any subcontracting or hiring of external staff by the ITSEF for its activities are to be described and related contractual responsibilities need to be provided and include the overall responsibility of the ITSEF. The ITSEF sees to it that externals meet the authorisation requirements of the ITSEF for the subcontracted or hired services;
   • 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 spend on maintenance of staff competences including learning and development, the resources spend on the cybersecurity including the technical and organisational measures related to information protection and cybersecurity training of staff;
2. The documentation demonstrating the CABs competence management system that includes:
   • For ITSEFs, the required technical competences for the testing and related evaluation activities performed by the ITSEF in accordance with Article 22 EUCC and specified under Annex A (A mapping should be provided in how the staff members meet the required technical competences. The business resume/CV or an overview providing equivalent information should reflect the obtained technical certification competences of the staff /hired personnel based upon their latest appraisal. A possible example template of this mapping is provided in Annex C);
   • For CBs, the required technical competences for the CB activities performed in accordance with Article 21 EUCC and specified under Annex B (A mapping should be provided in how the staff members meet the required technical competences. The business resume/CV or an overview providing equivalent information should reflect the obtained technical certification competences of the staff /hired personnel based upon their latest appraisal. A possible example template of this mapping is provided in Annex C);
   • The required competences for the technical and organisational measures (TOMs) related activities performed by the CAB to effectively protect confidential and sensitive information specifically addressing the risks related to their activities performed under assurance level ‘high’ in accordance with Annex D.
3. The documentation demonstrating the compliance with the TOMs defined by the CAB in accordance with Annex D;
4. In the case of an initial application or scope extension, information regarding a pilot assessment performed by the CAB in accordance with the EUCC requirements. A short introduction of the pilot projects context and scope shall be attached. This pilot assessment shall meet the following requirements:
   • The product assessed falls within the scope, and if applicable the technical domain of ICT-products for which authorisation is requested;
   • The product is assessed at the assurance level (substantial/high and its associated  AVA_VAN level) for which authorisation is requested;
   • The product is assessed in accordance with OP002 – EUCC processes and the EUCC requirements defined in the Implementing Regulation. A product assessed under a national scheme that is recognised under the SOG-IS MRA may also be applicable;
   • The product assessment results, i.e. the Evaluation Technical Report (ETR) or Certification Report (CR), shall not be older than 6 months from the time of application.
   • For each technical domain requested for licensing, a pilot assessment shall be performed.
5. For CBs that use the services of third parties, information demonstrating the third parties technical competences and expertise specified for each of the certification activities that are performed by the third party within the defined scope of authorisation. This implies that:
   • An overview of the technical competences that are used by means of subcontracting should be provided. The CB should see to it that the third party meets the authorisation requirements applicable to the CB for the subcontracted services;
   • The overview of the TOMs and the related technical competences to implement and maintain the TOMs should be provided, including the legal overall responsibility for its compliance.
6. For CBs, documentation demonstrating that it conducts its activities in cooperation with authorised ITSEF(s) by providing a proof of the subcontracting contract addressing:
   • The exchange of information and the conditions that apply;
   • The aspects/fields of cooperation;
   • The right of the CB to request information and visit the ITSEF for the purpose of the certification decision;
   • 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;
   • The collaboration with the ITSEF in the assurance continuity procedure described under Annex IV of EUCC.

Annex A. The ITSEF technical competences

The ITSEF should provide the documentation demonstrating that the ITSEF ensures that it has all the necessary technical competences and is able to maintain the up-to-date technical competences in at least the following areas:

1. The ability, knowledge & skills to design, to use up-to-date threat intelligence and is able to analyse the risks and perform and assess the related risk assessments, understand and is able to translate this information to up-to-date evaluation methodologies appropriate for the scope of authorisation;
2. The ability, knowledge & skills to design, to detect, analyse and perform testing/evaluation methodologies developed for assurance level ‘high’ that are taking into account a risk-based approach, related to the scope of their foreseen application to authorisation, and which are used for testing the resilience against state-of-the-art cyberattacks performed by skilled attackers with significant skills and resources. This implies the ability, knowledge and skills to apply a comprehensive and well-structured set of procedures and flaw hypothesis methodology (whereby specifications and development and guidance evidence are analysed and then potential vulnerabilities in the TOE are hypothesized, or speculated), as required by ISO/IEC 18045 for the evaluation of different types of products or technologies and the use of the applicable guidance to support the evaluators;
3. The ability, knowledge & skills to translate of these types of cyberattacks into the different evaluation methodologies in terms of design & re-design, selection, operation and evaluation and optimisation of the applied methodologies, as there is not a unique way to perform an attack and it may be possible to spot the same vulnerability using source code analysis, fuzz testing and manually devise this, or other testing methodologies;
4. The ability, knowledge & skills to design/develop, perform and evaluate attack potential calculations using the applicable table provided by ISO/IEC 18045 (for AVA_VAN level 3 this requires the ToE to be resistant to ‘Enhanced-Basic’ attacks); for the applicable Technical Domain of Hardware devices with security boxes we refer to the SoA: “Application of Attack Potential to hardware devices with security boxes” of Annex I (1) (b) (3) EUCC; for the applicable technical Domain of Smartcards and similar devices we refer to the SoA: “Application of Attack Potential to Smart cards” of Annex I (1) (a) (7) EUCC;
5. The ability, knowledge & skills to have a thorough understanding of the capabilities and limitations of available tools selected, justified and used under assurance level ‘high’ (automated vs the manual use requiring more time and expertise; and the understanding and expertise to use development tools, analysis and attack tools (e.g. source code analysis and coverage tools, test benches for invasive and semi invasive techniques, side channel analysis, perturbation, tools for physical tempering, etc.) and IT systems necessary for the evaluation activities under assurance level ‘high’, the ability to where necessary to be able to find ‘work arounds’ for adequately testing the ICT product that allow to analyse and determine the level of resistance of the ICT product or protection profile;
6. The ability, knowledge & skills to describe the evaluation activities and the findings in a technical sound, consistent and verifiable, logical and structured order, despite the complexity of the evaluation activities under assurance level ‘high’ they should be easy to follow for outsiders of the evaluation;
7. The ability, skills and knowledge of cryptographic algorithms, protocols, and relevant expertise in cryptographic evaluations, and capability to check for the presence of well-known vulnerabilities in cryptographic protocols;
8. The ability, skills and knowledge of each technology type or in the area of work of the evaluator, knowledge of the product type in scope of the authorisation, including:
   • typical feature set, use cases, and operational environment;
   • architectural concepts, design and implementation methods and relevant implementation languages and tools;
   • associated development and production processes;
   • known vulnerabilities;
   • CAPEC™ applicable attack patterns;
   • Relevant attack methods already used in Common Criteria evaluations, especially based on the EUCC technical domains that may be relevant for the product type.
9. The ability, skills and knowledge to select, justify and apply the proper source code analysis techniques, to select justify and use in the laboratory environment or where necessary, the production environment, the different types of penetration testing (Black-box, Grey-box and Chrystal-box or White-box), selection, justification and use of penetration testing tools and debugging tools;
10. The ability, skills and knowledge to select, justify and use open source tools (e.g. gdb, ollydbg, wireshark, nmap, metasploit framework, scapy, etc), tools for adaptation of opensource software developed by the evaluator (e.g. IDA Pro, Cryptosense Analyzer, a commercial fuzzer, etc.) and AI based tools for software testing allowing to identify attack paths or to exploit vulnerabilities and hardware attack tools (e.g. portable oscilloscopes, logic analyzers, USB microscopes, special screwdrivers, soldering/desoldering/rework stations, memory programmers, low-end glitching stations);
11. The ability, skills and knowledge to perform enhanced-basic and more complex reverse engineering;
12. The ability, skills and knowledge to monitor the ICT product evaluations or protection profile evaluations, where applicable for the technical domains;
13. The ability, knowledge & skills to technically support the CB in the vulnerability handling procedure by analysing the impact assessments, to perform upon the request of the CB technical evaluation checks to verify the remediating measures that need to cover the vulnerability;
14. 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 as well.

Annex B. The CB technical competences

The CB should provide the documentation demonstrating that the CB ensures that it has all the specific technical competences for certification activities should focus amongst others on the ability to review, assess and validate amongst others, but not limited to:

• The work of the ITSEF performed under assurance level ‘high’ for the authorisation scope, including the analysis, and review of the Evaluation Technical Report,
• The drafting the certification report (including the sanitization of a security target in accordance with Annex V, section V.2 EUCC),
• 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,
• The task to make certification decisions related to issuance of certificates, suspensions, restrictions and withdrawal in accordance with the procedures, and to monitor the conditions for issuance of an EUCC certificate;
• Handle the procedures related to: vulnerability handling and patch management; handle the assurance continuity; the compliance monitoring and complaints;

Annex C. The competence overview (informative)

In this annex, a recommended template is provided for the conformity assessment body to provide to the NCCA for assessment of the required competences related to authorisation.

The conformity assessment body should have and provide an overview of the competence management system for all staff (internal and external).

Key critical functions within the conformity assessment body (CB or ITSEF) are functions that are key to perform the conformity assessment activity, without the function, the activity cannot be performed by the conformity assessment body. For the key critical functions, the conformity assessment body should have a policy in place that ensures continuity of the conformity assessment activity. The policy should include the following aspects:

• The strategy and long-term continuity of the key critical functions (describing the relation to business plan and KPI’s of the conformity assessment body);
• The identification of the key critical functions and required competences;
• The fulfilment of the key critical functions (% internal, % external staff);
• The succession planning related to key critical functions (taking into account where applicable external staff and related dependencies);
• The learning & development policy and planning (taking into account where applicable external staff and related dependencies).

Recommended competency overview template:

Department & conformity assessment activity description	Related job description	Staff member (pseudonymization) and indication internal or external	Required competence	Scored competence

General competence management elements recommended for assurance level ‘high’ context are:

• The elements of competence, competency levels and the measurement of the elements of competence are drawn from ISO/IEC 19896-1 and if they differ, they should be commensurate with the objectives and equivalence should be demonstrated;
• The knowledge, skills, experience and education, and the requirements from ISO/IEC 19896, and if they differ, they should be commensurate with the objectives and equivalence should be demonstrated. Where ISO/IEC 19896 misses requirements for a certain function within the CAB, analogous or equivalent requirements should be used instead;
• The CAB should define and handle its own set of requirements based upon the authorisation scope according to the type of products they evaluate/certify, and their underlying technologies.

Annex D. The technical & organisational measures (TOMS)

The ITSEF and the CB operating under assurance level ‘high’ will assess ICT products used in high risk or critical areas for which there is a need to minimize the risk. The ITSEF will determine the level of resistance to state-of-the-art cyberattacks carried out by actors with significant skills and resources which is verified by the CB. The information they collect, generate in the overall conformity assessment activities and store is confidential and sensitive information on the ICT products.

For this reason, it is of great importance that the CB and ITSEF take the appropriate Technical and Organisational Measures (TOMs) to minimize the risk of attacks and cyber incidents. Policies, procedures and processes need to be in place to detect, respond to, recover from these attacks or incidents and take measures that prevent these attacks or incidents from re-occurring.

Following factors should play a role in defining the appropriate TOMs for CBs and ITSEFs:

• The ITSEF subcontracted to the CB and working under its responsibility also should follow TOMs in accordance with Article 22 (1) (c) EUCC. Given the context of the relation and operation between the ITSEF and the CB this implies that the ITSEF should operate commensurable TOMs as the CB. The CB is only able to perform its activities upon the data provided by the ITSEF which means that they operate in the same environment.
• Article 51 CSA provides clear guidelines for TOMs that should be applied in European cybersecurity certification schemes for the lifecycle of certification and the retention period to achieve these objectives. They should cover the schemes related to certification of ICT products, ICT services and ICT processes, and should apply to the conformity assessment bodies.
• The ITSEF and CAB should operate a process for selection of TOMs that includes referring to established standards and tested/certified products where possible, and for regularly testing of the TOMs, where possible (e.g., checking for physical alarms, checking staff awareness or performing a penetration testing on the firewall).

The TOMs should meet the following requirements:

• They should be defined upon a risk assessment that should be performed by the CB and ITSEF and cover the degree of the entities’ exposure to risks;
• They take the organizational context into account, i.e., TOMs possibly provided by a larger entity which the CB and ITSEF is part of;
• They should take into account the likelihood of occurrence of incidents and their severity, including their societal and economic impact;
• They should have an all-hazard approach that aims to protect their network and information systems and physical environment from incidents;
• They should be regularly audited/evaluated including an improvement cycle.

In principle, the CB and ITSEF should have the following policies and procedures in place that are implemented, trained and maintained and which should apply to the entire CB and ITSEF, including where applicable all subsidiaries and establishments in the EU:

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:
   • for the reporting of incidents to the CSIRT the reporting by the CB and ITSEF as entities the procedure in analogy to Article 23 NIS2 should apply;
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:
   • the vulnerabilities specific to each direct supplier and service provider
   • 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:
   • Non-CB and non-ITSEF personnel with temporary access to assets of the CB and ITSEF (e.g.: visitors, external functions or companies) ensuring that their access is limited as much as possible and supervised;
   • Overall access policy to assets of the CB and ITSEF for CB and ITSEF personnel, based on the need-to-know and need-to-be principles and including an authentication policy consisting of multi-factor authentication. Additionally, the CB and ITSEF 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);
   • 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;
   • Basic cyber hygiene practices and cybersecurity training;
   • A policy related to work ethics with special attention for:
     • Fraud prevention;
     • Prevention of inside intruder incidents leading to leaking of information by: espionage, or deliberate publication of confidential information;
     • Neglect of duty to meet cybersecurity requirements;
     • 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 CB and ITSEF to limit the attack surface, e.g.: dedicated networks for CB and ITSEF activities; Trustworthy software installation and maintenance (upgrade) procedures including measures to limit access of 3rd parties on CB and ITSEF assets during installation/upgrade;
10. Safe and secure destruction policy of media;
11. Where artificial intelligence (AI) is used for conformity assessment activities, the ITSEF and CAB TOMs to handle AI specific risks, e.g., accuracy or robustness;
12. For the Specific TOMs that apply for the ITSEF and the developer during evaluation of ICT products, the SotA related to ‘Minimum Site Security Requirements, version 1.1’ as annexed to EUCC under annex I (a) (2) should apply.