EN 17640:2022+A1:2026

• Abstract:

  This document describes a cybersecurity evaluation methodology that can be implemented using pre-defined time and workload resources, for ICT products. It is intended to be applicable for all three assurance levels defined in the CSA (i.e. basic, substantial and high).; The methodology comprises different evaluation blocks including assessment activities that comply with the evaluation requirements of the CSA for the mentioned three assurance levels. Where appropriate, it can be applied both to third-party evaluation and self-assessment.

• Status: Published
• Publication Date: 30-Jun-2026
• ICS: 35.030 - IT Security
• Technical Committee: CEN/CLC/TC 13 - Cybersecurity and Data Protection
• Drafting Committee: CEN/CLC/JTC 13/WG 3 - Security evaluation and assessment
• Current Stage: 6060 - Definitive text made available (DAV) - Publishing
• Start Date: 01-Jul-2026
• Completion Date: 01-Jul-2026
• Ref Project: SIST EN 17640:2023+A1:2026 - Fixed-time cybersecurity evaluation methodology for ICT products

• Merged From: EN 17640:2022/prA1 - Fixed-time cybersecurity evaluation methodology for ICT products
• Effective Date: 22-Apr-2026
• Merged From: EN 17640:2022 - Fixed-time cybersecurity evaluation methodology for ICT products
• Effective Date: 22-Apr-2026

SLOVENSKI STANDARD
01-september-2026
Metodologija ocenjevanja kibernetske varnosti za izdelke IKT za določeno obdobje
(vključuje dopolnilo A1)
Fixed-time cybersecurity evaluation methodology for ICT products
Zeitlich festgelegte Cybersicherheitsevaluationsmethodologie für IKT-Produkte
Méthode d'évaluation de la cybersécurité pour produits TIC
Ta slovenski standard je istoveten z: EN 17640:2022+A1:2026
ICS:
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 17640:2022+A1

NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2026
ICS 35.030
Supersedes EN 17640:2022
English version
Fixed-time cybersecurity evaluation methodology for ICT
products
Méthode d'évaluation de la cybersécurité pour Zeitlich festgelegte
produits TIC Cybersicherheitsevaluationsmethodologie für IKT-
Produkte
This European Standard was approved by CEN on 15 August 2022 and includes Amendment 1 approved by CEN on 22 April
2026.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2026 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 17640:2022+A1:2026 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Conformance . 11
5 General concepts . 13
5.1 Usage of this methodology . 13
5.2 Knowledge of the TOE . 13
5.3 Development process evaluation . 13
5.4 Attack Potential . 14
5.5 Knowledge building . 14
5.6 !Composition . 14
6 Evaluation tasks . 15
6.1 Completeness check . 15
6.1.1 Aim . 15
6.1.2 Evaluation method . 15
6.1.3 Evaluator competence . 15
6.1.4 Evaluator work units . 15
6.2 FIT Protection Profile Evaluation . 16
6.2.1 Aim . 16
6.2.2 Evaluation method . 16
6.2.3 Evaluator competence . 16
6.2.4 Evaluator work units . 16
6.3 Review of security functionalities . 17
6.3.1 Aim . 17
6.3.2 Evaluation method . 17
6.3.3 Evaluator competence . 17
6.3.4 Evaluator work units . 17
6.4 FIT Security Target Evaluation . 18
6.4.1 Aim . 18
6.4.2 Evaluation method . 18
6.4.3 Evaluator competence . 18
6.4.4 Evaluator work units . 18
6.5 Development documentation . 19
6.5.1 Aim . 19
6.5.2 Evaluation method . 19
6.5.3 Evaluator competence . 19
6.5.4 Work units . 19
6.6 Evaluation of TOE Installation . 20
6.6.1 Aim . 20
6.6.2 Evaluation method . 20
6.6.3 Evaluator competence . 20
6.6.4 Evaluator work units . 20
6.7 Conformance testing . 21
6.7.1 Aim . 21
6.7.2 Evaluation method . 21
6.7.3 Evaluator competence . 21
6.7.4 Evaluator work units . 21
6.8 Vulnerability review . 22
6.8.1 Aim . 22
6.8.2 Evaluation method . 23
6.8.3 Evaluator competence . 23
6.8.4 Evaluator work units . 23
6.9 Vulnerability testing . 24
6.9.1 Aim . 24
6.9.2 Evaluation method . 24
6.9.3 Evaluator competence . 24
6.9.4 Evaluator work units . 24
6.10 Penetration testing . 26
6.10.1 Aim . 26
6.10.2 Evaluation method . 26
6.10.3 Evaluator competence . 27
6.10.4 Evaluator work units . 27
6.11 Basic crypto analysis . 28
6.11.1 Aim . 28
6.11.2 Evaluation method . 28
6.11.3 Evaluator competence . 28
6.11.4 Evaluator work units . 28
6.12 Extended crypto analysis . 29
6.12.1 Aim . 29
6.12.2 Evaluation method . 29
6.12.3 Evaluator competence . 30
6.12.4 Evaluator work units . 30
6.13 !Composition TOE Evaluation . 31
6.13.1 Aim . 31
6.13.2 Evaluation method . 32
6.13.3 Evaluator qualification . 32
6.13.4 Evaluator work units . 32
Annex A (informative) Example for a structure of a FIT Security Target (FIT ST) . 35
Annex B (normative) The concept of a FIT Protection Profile (FIT PP) . 37
Annex C (informative) Acceptance Criteria . 38
Annex D (informative) Guidance for integrating the methodology into a scheme . 45
Annex E (informative) Parameters of the methodology and the evaluation tasks . 50
Annex F (normative) Calculating the Attack Potential . 52
Annex G (normative) Reporting the results of an evaluation . 57
Annex H (informative) Clarification of ‘composition of assurance’ developed in
EN ISO/IEC 15408-1:2023 in support of ‘composition’ introduced in
Bibliography . 61

European foreword
This document (EN 17640:2022+A1:2026) has been prepared by the Joint Technical Committee CEN-
CENELEC/ JTC 13 “Cybersecurity and Data Protection”, the secretariat of which is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by January 2027, and conflicting national standards shall
be withdrawn at the latest by January 2027.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN-CENELEC shall not be held responsible for identifying any or all such patent rights.
This document includes Amendment 1 approved by CEN on 22 April 2026.
The start and finish of text introduced or altered by amendment is indicated in the text by tags !".
This document supersedes EN 17640:2022.
Any feedback and questions on this document should be directed to the users’ national standards
body/national committee. A complete listing of these bodies can be found on the CEN and CENELEC
websites.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the United
Kingdom.
Introduction
The foundation for a sound product certification is a reliable, transparent and repeatable evaluation
methodology. Several product or scheme dependent evaluation methodologies exist. The Cybersecurity
Act (CSA) [1] will cause new schemes to be created which in turn require (new) methodologies to
evaluate the cybersecurity functionalities of products. These new methodologies are required to describe
evaluation tasks defined in the CSA. This methodology also adds a concept, independent of the
requirements of the CSA, namely the evaluation in a fixed time. Existing cybersecurity evaluation
methodologies (e.g. EN ISO/IEC 15408 in combination with EN ISO/IEC 18045) are not explicitly
designed to be used in a fixed time.
Scheme developers are encouraged to implement the evaluation methodology in their schemes. This can
be done for general purpose schemes or in dedicated (vertical domain) schemes, by selecting aspects for
self-assessment at CSA assurance level “basic” or third-party assessments. The self-assessment may be
performed at CSA assurance level “basic”, the third-party evaluations at CSA assurance level “basic”,
“substantial” or “high”. And the evaluation criteria and methodology might be subject to extra tailoring,
depending on the requirements of the individual scheme. This cybersecurity evaluation methodology
caters for all of these needs. This methodology has been designed so that it can (and needs to be) adapted
to the requirements of each scheme.
Scheme developers are encouraged to implement the evaluation methodology for the intended use of
the scheme, applicable for general purpose or in dedicated (vertical) domains, by selecting those aspects
needed for self-assessment at CSA assurance level “basic” or third-party evaluation at any CSA assurance
level required by the scheme.
This document provides the minimal set of evaluation activities defined in the CSA to achieve the desired
CSA assurance level as well as optional tasks, which might be required by the scheme. Selection of the
various optional tasks is accompanied by guidelines so scheme developers can estimate the impact of
their choices. Further adaption to the risk situation in the scheme can be achieved by choosing the
different evaluation tasks defined in the methodology or using the parameters of the evaluation tasks, e.g.
the number of days for performing certain tasks.
If scheme developers choose tasks that are not defined in this evaluation methodology, it will be the
responsibility of the scheme developer to define a set of companion requirements or re-use another
applicable evaluation methodology.
Nonetheless, it is expected that individual schemes will instantiate the general requirements laid out in
this evaluation methodology and provide extensive guidance for manufacturers (and all other parties)
about the concrete requirements to be fulfilled within the scheme.
Evaluators, testers and certifiers can use this methodology to conduct the assessment, testing or
evaluation of the products and to perform the actual evaluation/certification according to the
requirements set up by a given scheme. It also contains requirements for the level of skills and knowledge
of the evaluators and thus will also be used by accreditation bodies or National Cybersecurity
Certification Authorities during accreditation or authorization, where appropriate, and monitoring of
conformity assessment bodies.
Manufacturers and developers will find the generic type of evidence required by each evaluation task
listed in the evaluation methodology to prepare for the assessment or evaluation. The evidence and
evaluation tasks are independent from the fact of whether the evaluation is done by the
manufacturer/developer (i.e. 1st party) or by someone else (2nd/3rd party).
Users of certified products (regulators, user associations, governments, companies, consumers,
etc.) may also use this document to inform themselves about the assurance drawn from certain
certificates using this evaluation methodology. Again, it is expected that scheme developers provide
additional information, tailored to the domain of the scheme, about the assurance obtained by
evaluations / assessments under this methodology.
Furthermore, this methodology is intended to enable scheme developers to create schemes which
attempt to reduce the burden on the manufacturer as much as possible (implying additional burden on
the evaluation lab and the certification body).
NOTE In this document the term “Conformity Assessment body” (CAB) is used for CABs doing the evaluation.
Other possible roles for CABs are not considered in this document.
It should be noted that this document cannot be used “stand alone”. Each domain (scheme) needs to
provide domain specific cybersecurity requirements (“technical specifications”) for the objects to be
evaluated / certified. This methodology is intended to be used in conjunction with those technical
specifications containing such cybersecurity requirements. The relationship of the methodology
provided in this document to the activities in product conformity assessment is shown in Figure 1.

Figure 1 — Relationship of this document to the activities in product conformity assessment
1 Scope
This document describes a cybersecurity evaluation methodology that can be implemented using pre-
defined time and workload resources, for ICT products. It is intended to be applicable for all three
assurance levels defined in the CSA (i.e. basic, substantial and high).
The methodology comprises different evaluation blocks including assessment activities that comply with
the evaluation requirements of the CSA for the mentioned three assurance levels. Where appropriate, it
can be applied both to third-party evaluation and self-assessment.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
• IEC Electropedia: available at https://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
evaluator
individual that performs an evaluation
Note 1 to entry: Under accreditation the term “tester” is used for this individual.
3.2
auditor
individual that performs an audit
3.3
certifying function
people or group of people responsible for deciding upon certification
Note 1 to entry: Depending on the scheme the certifying function may use evidence beyond the ETR (3.13) as a basis
for the certification decision.
3.4
scheme developer
person or organization responsible for a conformity assessment scheme
Note 1 to entry: For schemes developed under the umbrella of the CSA the so-called “ad hoc group” helps the scheme
developer.
Note 2 to entry: This definition is based on and aligned with the definition of “scheme owner” in EN ISO/IEC 17000.
3.5
confirm
declare that something has been reviewed in detail with an independent
determination of sufficiency
[SOURCE: ISO/IEC 18045:2022, definition 3.2 with NOTE removed]
3.6
verify
rigorously review in detail with an independent determination of sufficiency
Note 1 to entry: Also see “confirm”. This term has more rigorous connotations. The term “verify” is used in the
context of evaluator actions where an independent effort is required of the evaluator.
[SOURCE: ISO/IEC 18045:2022, definition 3.22]
3.7
determine
affirm a particular conclusion based on independent analysis with the objective of
reaching a particular conclusion
Note 1 to entry: The usage of this term implies a truly independent analysis, usually in the absence of any previous
analysis having been performed. Compare with the terms “confirm” or “verify” which imply that an analysis has
already been performed which needs to be reviewed.
[SOURCE: ISO/IEC 18045:2022, definition 3.5]
3.8
ICT product
product with information and/or communication technology
Note 1 to entry: ICT covers any product that will store, retrieve, handle, transmit, or receive digital information
electronically in a digital form (e.g., personal computers, smartphones, digital television, email systems, robots).
3.9
Target of Evaluation
TOE
product (or parts thereof, if product is not fully evaluated) with a clear boundary, which is subject to the
evaluation
3.10
FIT Security Target
FIT ST
documented information describing the security properties and the operational environment of the TOE
(3.9)
Note 1 to entry: The FIT ST may have different content, structure and size depending on the CSA assurance level.
3.11
FIT Protection Profile
FIT PP
implementation-independent statement of security needs for a TOE (3.9) type
[SOURCE: ISO/IEC 15408-1:2022, definition 3.68]
3.12
Secure User Guide
SUG
documented information describing the steps necessary to set up the TOE (3.9) into the intended secure
state (3.16)
3.13
Evaluation Technical Report
ETR
documented information describing the results of the evaluation
3.14
scheme-specific checklist
list of items defining the required level of detail and granularity of the documentation, specified by the
scheme
3.15
knowledge
facts, information, truths, principles or understanding acquired through experience or education
Note 1 to entry: An example of knowledge is the ability to describe the various parts of an information assurance
standard.
Note 2 to entry: This concept is different from the concept “Knowledge of the TOE”.
[SOURCE: ISO/IEC TS 17027:2014, 2.56, modified — Note 1 to entry has been added from
ISO/IEC 19896-1:2018, Note 2 to entry is new]
3.16
secure state
state in which all data related to the TOE (3.9) security functionality are correct, and security functionality
remains in place
3.17
self-assessment
conformance assessment activity that is performed by the person or organization that provides the TOE
(3.9) or that is the object of conformity assessment
[SOURCE: EN ISO/IEC 17000:2020, definition 4.3 with Notes and Examples removed]
3.18
evaluation task parameter
parameter required to be set when using this document to define how the evaluation task shall be
executed by the evaluator (3.1)
!3.19
component
entity (3.20) which provides resources and services in a product
[SOURCE: EN ISO/IEC 15408-1:2023, 3.18 modified, is omitted]
3.20
entity
identifiable item that is described by a set or collection of properties
Note 1 to entry: Entities include subjects, users (including external IT products), objects, information, sessions
and/or resources
[SOURCE: EN ISO/IEC 15408-1:2023, 3.36]
3.21
composite product
product comprised of two or more components (3.19) which one already evaluated component (3.19) and
another component (3.19)
Note 1 to entry: The component (3.19) which has already been evaluated provides resources and services to another
component(s) (3.19), and these components (3.19) are called ‘base component’ and ‘dependent component’,
respectively.
Note 2 to entry: Already evaluated base component is called ‘base TOE’.
Note 3 to entry: A dependent component can rely on one or more base components.
Note 4 to entry: A dependent component potentially consists of one or more dependent sub-components. For
simplification, they are considered as ‘one dependent component’.
[SOURCE: EN ISO/IEC 15408-1:2023, 3.24 with references to layer removed and Notes to entries added.]
3.22
composite target of evaluation
composite TOE
part of a composite product (3.21) being subject to composite TOE evaluation
Note 1 to entry: A composite TOE can contain parts that are independent from the base component or base TOE
respectively. For simplification, such parts are considered as belonging to the dependent component.
Note 2 to entry: The composite TOE evaluation can be applied as many times as necessary to a multi-component
product, in an incremental approach.
3.23
evaluation technical report for composite TOE evaluation
ETR for composite TOE evaluation
documentation intended to be used within the composite TOE (3.22) evaluation and derived by the base
component evaluator from the full evaluation technical report (ETR) (3.13) for the evaluated component
Note 1 to entry: The ETR for composite TOE evaluation is used for the evaluation of a composite product with such
base component when using the composite evaluation approach.
Note 2 to entry: The ETR for composite TOE evaluation related to a base component is set up to provide sufficient
information for a composite evaluation of a composite product that integrates such already evaluated component.
It enables the composite product evaluator and the respective composite product evaluation authority to
understand the attack paths and the tests that have been considered and performed for the base component and
the effectiveness of the countermeasures implemented by the base component.
[SOURCE: EN ISO/IEC 15408-1:2023, 3.44, adapted.]"
4 Conformance
The following Table 1 provides a reference on how the evaluation tasks should be chosen for a certain
scheme for the different CSA assurance levels:
Table 1 — Evaluation tasks vs. CSA assurance level conformance claim
CSA assurance level conformance claim
Evaluation tasks Reference Basic Substantial High
Completeness
6.1 Required Required Required
check
Review of security
6.3 Required
functionalities
FIT Security
6.4 Required Required
Target Evaluation
Development
6.5 Required Required Required
1)
documentation
Evaluation of TOE
6.6 Recommended Required Required
Installation
Conformance
6.7 Recommended Required Required
Testing
Vulnerability Required (or done
6.8 Recommended
review with 6.9)
Vulnerability
6.9 Recommended
testing
Penetration
6.10  Required
testing
Basic crypto
2)
6.11 Recommended Recommended
analysis
Extended crypto
6.12  Required
analysis
1) The scheme specific checklist may be empty for a particular scheme and then this evaluation tasks
would not apply.
2) If crypto functionality is at the core of the product, then it is sensible for scheme developers to
include it, e.g. defining appropriate product classes.
NOTE 1 FIT Protection Profile Evaluation is a dedicated process and not part of the evaluation of a TOE. While
the FIT PP specifies for which CSA assurance level it is applicable, the evaluation of a FIT PP is agnostic to this.
To implement the methodology for a certain scheme, the following steps shall be performed:
1. The scheme developer needs to perform a (domain) risk assessment, reviewing the domain under
consideration.
2. The scheme developer shall assign the Attack Potential (cf. Clause 5.4 and Annex F) to each CSA
assurance level used in the scheme
3. For each CSA assurance level the scheme developer shall select those evaluation tasks required for
this level, these are marked grey in Table 1.
4. For each task chosen, the scheme developers shall review the parameters for this evaluation task and
set them suitably based on the risk assessment and the determined attack potential. For the
evaluation task “development documentation” this includes setting up a scheme specific checklist
(which maybe empty).
5. For each CSA assurance level the scheme developer shall review those evaluation tasks
recommended for this level if inclusion is sensible, these task contain the word “Recommended” in
Table 1.
6. For each CSA assurance level the scheme developer shall review if those evaluation tasks are
sufficient for the scheme based on the determined Attack Potential. If not, the scheme developer shall
select additional evaluation tasks (e.g. from the same CSA assurance level), tasks from a higher CSA
assurance level or additional tasks not defined in this methodology. These may replace tasks already
chosen.
7. For each new or updated task chosen the scheme developers shall review the parameters for this
task and set them suitably based on the risk assessment and the attack potential.
If the scheme developers want to include development process evaluation/assessment, there is an
additional task for the scheme: The scheme developer needs to decide about validity of process
evaluation/assessment results for future product evaluations. This means that the development related
tasks may be performed once, and the output of these tasks is subsequently used in several product
evaluations (e.g. as a precondition). Optionally the auditors may define a list of artefacts which are to be
provided in each subsequent product evaluation, to show that the audited processes are still operational.
If schemes intend to include this development process evaluation/assessment re-use mechanism, they
shall ensure that reuse is limited to cases where the development process is the same in all evaluations
or assessments, i.e. the site(s), the knowledge of the people and the actual processes are identical or
equivalent. To achieve this, the initial evaluation or assessment may be made more broadly (i.e. cover a
larger scope of the development). Additionally, the scheme shall limit the maximum period of time during
which the results are to be acceptable.
EXAMPLE A usual maximal age of these results is two years. This means, if the evaluation / assessment occurs
more than two years after the results of the development process evaluation have been produced, the development
process needs to be re-assessed/re-evaluated. If an existing SDL (Software Development Lifecyle) certificate is used,
its validity is another possibility for the validity of this evidence.
For some evaluation tasks the scheme may require additional inputs from the developer, e.g. an
architectural overview. This additional input should be limited as much as possible, especially if this
documentation is typically only prepared for the assessment or evaluation, i.e. not readily available for
the TOE anyhow.
NOTE 2 Requiring design information might preclude some products from assessment or certification, as this
information might not be available due to the fact that some third-party components, including hardware, might be
proprietary without the possibility to obtain this design information. This is in general not applicable if white box
testing is performed (if this is an option in the scheme). Further composition of certified parts is an option to
mitigate this problem.
An example of the integration of this methodology in a scheme is given in Annex D.
!The concept of composite evaluation is not explicitly contained in the CSA and hence not explicitly
mentioned in any assurance level. Moreover, composite evaluation is not applicable in every TOE. If
scheme developers intend to implement composite TOE evaluation, they need to specify conditions and
requirements on the certificates concerning base components that can be used as evidence in the
composite TOE evaluation."
5 General concepts
5.1 Usage of this methodology
Clause 5 describes elements of an evaluation methodology for fixed-time security certification and self-
assessment.
To instantiate a specific evaluation methodology based on this generic methodology, the required
evaluation tasks are selected depending on the intended CSA assurance level according to the CSA.
Depending on the domain, certain evaluation tasks are required, while others are optional (see Clause 4).
For sample-based evaluation tasks, the scheme needs to devise the sample size and sampling strategy as
well as the absolute or relative weight, i.e. the number of person days or the percentage of overall
evaluation time. Additional constraints on sampling might be provided, e.g. on the limits of sampling
depending on the CSA assurance level.
To use this methodology, it is not necessary to require all evaluation tasks described in Clause 6 for every
CSA assurance level. For example, a scheme designed for CSA assurance level “substantial” might require
a “Basic crypto analysis” evaluation task or might omit it and possibly integrate the necessary parts into
the “Conformance testing” task instead.
NOTE This document and the resulting scheme do not define the exact structure of the documents used or
produced by the evaluation, e.g. the FIT ST or the ETR. These are scheme dependent.
5.2 Knowledge of the TOE
The scheme will require different sets of information or information with different levels of detail. This
depends on the one hand on the assurance required, on the other hand additional information might
speed up certain evaluation tasks.
In general, the developer shall provide a FIT Security Target and a Secure User Guide. The latter may not
be needed, if the TOE goes into the secure state as defined in the FIT ST automatically, i.e. no further
guidance is necessary.
The scheme may require additional information for certain activities. This is indicated in the respective
evaluation tasks where applicable.
The evaluator shall have access to information (like standards, protocol specifications) regarding the
technology implemented in the TOE, where this information is publicly available.
NOTE Publicly available does not imply that it is available free of charge.
5.3 Development process evaluation
This methodology is concerned with ICT product evaluation, and a scheme might limit its evaluation tasks
to pure ICT product related activities. However, experience in ICT product certification has shown that it
is sensible and valuable to evaluate the development process as well. This concerns both the initial
development (e.g. regarding security during design and construction of the product, including site
security) as well as aspects beyond delivery of the product, e.g. vulnerability and update management
processes. To improve usage of audit results in future product evaluations, the auditor may define a set
of artefacts (e.g. meeting reports, listing of configuration management systems, filled in checklists) which
will then be requested in every subsequent product evaluation to verify that the processes audited have
been adhered to in this instance.
Generic standards for development process evaluations should be reused where possible, applicable or
available.
5.4 Attack Potential
To determine the necessary evaluation tasks and their parameters it is necessary to define the expected
threat agent, characterized with a specific strength, also called Attack Potential. The vulnerability analysis
task of the evaluator may include penetration testing assuming the Attack Potential of the threat agent.
The following levels of Attack Potential are assumed in this document, the categorization is based on [2]
and [5].
— Basic
— Enhanced Basic
— Moderate
— High
NOTE 1 Attack Potential Moderate and High are unlikely to be addressable in a fixed-time evaluation scheme:
systematic availability of detailed documentation will probably be necessary to allow evaluators to be on par with
high level threat agents.
The CSA [1] defines three assurance levels: basic, substantial and high. Each level has an implicitly defined
attack scenario assigned. Scheme developers are advised to review the definitions in the CSA to align the
CSA assurance levels (as applicable to their domain) with the attack potential used in this methodology.
NOTE 2 The terms used in the context of attack potential are used as defined in this document and deviate from
the meaning of similar terms used in the CSA.
In the end evaluators will assess whether a threat agent possessing a given Attack Potential is able to
bypass or break the security functionality of the TOE.
The calculation of the attack potential is given in Annex F.
5.5 Knowledge building
Ensuring that each evaluation task produces the expected results requires certain knowledge and
competence by the evaluators. This knowledge is briefly described for each evaluation task and needs to
be refined when setting up the scheme.
To ensure that an overall evaluation produces the expected results, the competent evaluators need to
work as a good team. In particular the evaluators who work on the document parts of the evaluation need
to very closely collaborate with the evaluators performing the actual testing; ideally, they are the same
(set of) persons, especially if the total time span of the evaluation is low.
5.6 !Composition
Often a product consists of several components, developed by different parties. Sometimes some of these
components are evaluated or certified independently of the entire TOE they will be integrated in. In this
specific case the evaluation of the certified component can be replaced by certain evaluation tasks listed
in Clause 6.13.
rd
NOTE Other means of gaining assurance in 3 party components are not considered composition in this
document.
To enable efficient evaluations and avoid double evaluation work, composition typically requires certain
inputs to be provided. These inputs are divided into two groups. The names and further requirements on
theses inputs are scheme dependent. The inputs include the following:
• Developer guidelines with
— sufficient requirements for integration and use, ensuring that all the related claimed security
features are indeed active;
— a description wit
...