ISO 17574:2026

• Abstract:

  This document specifies electronic fee collection (EFC) requirements for the preparation and evaluation of security requirements specifications, referred to as protection profiles (PP) in the ISO/IEC 15408 series and in ISO/IEC TR 15446.

• Status: Published
• Publication Date: 06-Sep-2026
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 6060 - International Standard published
• Start Date: 07-Sep-2026
• Due Date: 31-Oct-2026
• Completion Date: 07-Sep-2026

• Consolidates: EN ISO 17574:2026 - Electronic fee collection - Requirements for security protection profiles (ISO 17574:2026)
• Effective Date: 12-Feb-2026
• Consolidates: ISO/TS 22317:2021 - Security and resilience — Business continuity management systems — Guidelines for business impact analysis
• Effective Date: 18-Nov-2023
• Revises: ISO/TS 17574:2017 - Electronic fee collection — Guidelines for security protection profiles
• Effective Date: 04-Nov-2023

Overview

ISO 17574:2026 - Electronic Fee Collection (EFC): Requirements for Security Protection Profiles establishes standardized requirements for the preparation and evaluation of security requirements specifications-referred to as protection profiles (PP)-within electronic fee collection systems. Developed by the International Organization for Standardization (ISO), this standard aligns closely with ISO/IEC 15408 (the Common Criteria series), ensuring internationally recognized security specifications for EFC equipment and interfaces. By guiding operators and suppliers through robust security architecture and PP preparation processes, ISO 17574:2026 supports the integrity, protection, and trustworthiness of tolling systems worldwide.

Key Topics

• Protection Profiles (PP): The standard outlines steps for creating PPs for EFC subsystems (e.g., on-board equipment or OBE), detailing how to specify the security requirements systematically.
• Security Architecture: It defines an EFC-specific security architecture, clarifying the roles of operators, system developers, auditors, and legal stakeholders in designing, evaluating, and maintaining secure toll collection environments.
• Evaluation Process: ISO 17574:2026 provides a structured process to analyze threats, define security objectives, and establish both functional and assurance-based requirements based on Common Criteria.
• Stakeholder Roles: It clarifies the relationship between toll operators, equipment suppliers, independent evaluators, and authorities, detailing how PPs and Security Targets (STs) are prepared and validated.
• Registration and Reference: The document supports the international registration and sharing of PPs, allowing operators and countries to reference established profiles to streamline EFC system development.
• Alignment with Common Criteria: Conformance with the ISO/IEC 15408 series ensures that EFC security measures meet leading global standards for IT security.

Applications

ISO 17574:2026 is highly applicable for:

• Toll Road Operators: Provides a framework for operators to develop, register, and maintain security requirements tailored to their EFC systems and operational context.
• EFC System Suppliers: Enables manufacturers and system integrators (e.g., OBE or roadside unit developers) to align product security features with operator-defined protection profiles, ensuring product acceptance and compliance.
• Security Evaluators: Supplies guidelines for independent assessment bodies to evaluate the conformity of EFC products and systems, supporting transparent, uniform validation of security claims.
• Government and Regulatory Authorities: Assists regulatory bodies in harmonizing requirements and audits for national or cross-border EFC implementations, increasing public and stakeholder trust.
• International Projects: Facilitates interoperability and mutual recognition of EFC security requirements across borders thanks to alignment with Common Criteria and ISO/IEC standards.

Practical value includes:

• Reducing risk of fraud, data breaches, or system manipulation within tolling environments.
• Streamlining procurement and integration of secure EFC equipment.
• Facilitating international collaboration and system interoperability by providing referenceable, registered security profiles.
• Supporting ongoing maintenance of secure, auditable EFC operations.

Related Standards

Implementing ISO 17574:2026 typically involves or references the following standards:

• ISO/IEC 15408 Series (Common Criteria):
  • Part 1 to Part 5: Provides the foundation for specifying, implementing, and evaluating IT security requirements.
• ISO/IEC TR 15446: Offers guidance on the use of ISO/IEC 15408 for developing security requirements.
• ISO 17573-2: Defines vocabulary and system architecture for EFC, ensuring a shared base of terms and structural understanding.
• Other Relevant Security Standards: As referenced in Annex C of ISO 17574:2026, additional sector-specific or technology-specific standards may apply, especially for DSRC or integrated circuit solutions.

Summary:
ISO 17574:2026 delivers a comprehensive, internationally harmonized approach to defining, preparing, and evaluating security requirements for electronic fee collection systems. By linking EFC security architecture to recognized IT security standards, it enables secure, trustworthy, and interoperable tolling environments worldwide.

International
Standard
ISO 17574
First edition
Electronic fee collection —
2026-09
Requirements for security
protection profiles
Perception de télépéage — Exigences relatives aux profils de
protection de sécurité
Reference number
© ISO 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 EFC security architecture and protection profile processes . 2
5.1 General .2
5.2 EFC security architecture . .3
5.3 Protection profile preparatory steps .3
5.4 Relationship between actors .4
6 Outline of protection profile (PP) . 6
6.1 Structure .6
6.2 Context .6
Annex A (informative) Procedure to prepare the protection profile . 8
Annex B (informative) Example of threat analysis evaluation method .40
Annex C (informative) Relevant security standards in the context of the EFC .46
Bibliography . 47

iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 278,
Intelligent Transport Systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
This first edition cancels and replaces the third edition (ISO/TS 17574:2017), which has been technically
revised.
The main changes are as follows:
— Clause 3 has been updated and ISO 17573-2 has been made the primary source for terms and definitions;
— requirements have been updated to reflect the latest edition of the ISO/IEC 15408 series.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iv
Introduction
Electronic fee collection (EFC) systems are subject to several ways of fraud both by users and operators but
also from people outside the system. These security threats are countered with various types of security
measures linked to specified security requirements.
It is recommended that EFC operators prepare their own EFC protection profile (PP) according to this
document, as security requirements should be described from the operator's point of view.
A protection profile (PP) refers to a set of safety requirements for a category of products or systems that
meet specific needs. A typical example is a PP for on-board equipment (OBE) to be used in an EFC system.
However, the requirements in this document are superseded if a PP already exists for the subsystem in
question.
The target of evaluation (TOE) for EFC is limited to EFC specific roles and interfaces as shown in Figure 1.
Figure 1 shows the relationships and interactions among the entities related to the TOE of the EFC. As shown
in this figure, entities are overall management of the toll charging environment, EFC service provider, toll
charger and user of the service. Since the existing financial security standards and criteria are applicable to
other external roles and interfaces, they are assumed to be outside the scope of TOE for EFC.
Figure 1 — Scope of TOE for EFC
The security evaluation is performed by assessing the security-related properties of roles, entities and
interfaces defined in security targets (STs), as opposed to assessing complete processes which often are
distributed over more entities and interfaces than those covered by the TOE of this document.
NOTE Assessing security issues for complete processes is a complementary approach, which can be beneficial to
apply when evaluating the security of a system.
It should be noted that the requirements provided in this document are intended to be read in conjunction
with the ISO/IEC 15408 series. Annex A provides an example of how to prepare the security requirements for
EFC equipment, in this case, a dedicated short-range communication (DSRC)-based OBE with an integrated
circuit(s) card (ICC) containing data needed for the EFC. The example refers to a Japanese national EFC
system and should only be regarded as an example.
After an PP for EFC is prepared, it can be internationally registered by the organization that prepared the
PP for EFC so that other operators or countries that want to develop their EFC system security services can
refer to an already registered PP for EFC.
This document on security service framework and PP for EFC is based on the ISO/IEC 15408 series. The
ISO/IEC 15408 series includes a set of requirements for the security functions and assurance of IT-relevant
products and systems. Operators, organizations or authorities defining their own PP for EFC can use these

v
requirements. The different PPs for EFC defined by operators, organizations or authorities will be similar
to the different PPs registered by several financial institutions, e.g. for payment instruments like IC cards
(ICCs).
The products and systems that were developed in accordance with the ISO/IEC 15408 series can be publicly
assured by the authentication of the government or designated private evaluation agencies.

vi
International Standard ISO 17574:2026(en)
Electronic fee collection — Requirements for security
protection profiles
1 Scope
This document specifies electronic fee collection (EFC) requirements for the preparation and evaluation of
security requirements specifications, referred to as protection profiles (PP) in the ISO/IEC 15408 series and
in ISO/IEC TR 15446.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 15408-1:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 1: Introduction and general model
ISO/IEC 15408-2:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 2: Security functional components
ISO/IEC 15408-3:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 3: Security assurance components
ISO/IEC 15408-4:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 4: Framework for the specification of evaluation methods and activities
ISO/IEC 15408-5:2022, Information security, cybersecurity and privacy protection — Evaluation criteria for IT
security — Part 5: Pre-defined packages of security requirements
ISO 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17573-2 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

4 Abbreviated terms
CC common criteria
CCRA common criteria recognition arrangement
CN cellular networks
DSRC dedicated short-range communication
EAL evaluation assurance level
EFC electronic fee collection
GNSS global navigation satellite systems
HMI human-machine interface
ICC integrated circuit(s) card
IT information technology
OBE on-board equipment
PP protection profile
RSE roadside equipment
SAM secure application module
SFP security function policy
SFR security functional requirement
ST security target
TOE target of evaluation
TSF target of evaluation security functions
5 EFC security architecture and protection profile processes
5.1 General
This clause gives an overview of the context and use of this document in terms of the EFC security
architecture and protection profile processes.
This document is intended to be read in conjunction with the ISO/IEC 15408 series and ISO/IEC TR 15446.
Although a reader unfamiliar with the standards can read the first part of the document to have an overview
on how to prepare a PP for EFC equipment, the annexes, in particular Annexes A.4 and A.5, require the reader
to be familiar with the ISO/IEC 15408 series. This document uses an OBE with an integrated circuit(s) card
(ICC) as an example to describe both the structure of the PP, as well as the proposed content.
In Annex A, the procedure for preparing PP for EFC is illustrated, which is described by using an OBE as an
example of EFC equipment. The communication link (between the OBE and the RSE) is based on DSRC.
Annex B gives an example of how a threat analysis can be done, while Annex C provides an overview of
the relevant security standards in the context of the EFC, which provides the background of EFC roles and
interfaces.
5.2 EFC security architecture
Figure 2 illustrates the position of this document within the broader context of the EFC security architecture,
highlighting the relationships between related domains and information dependencies. The shaded boxes
are the aspects mostly related to the preparation of PPs for EFC systems.
Regarding the security design framework, there are five domains. Functionality of these domains are
described as below.
— Operator domain defines the data protection requirement of the TOE as PP.
— System domain develops the ST based on the requirement. For development of the ST, threat and risk
assessment are done with balancing the cost and effect of the security measures.
— Legal domain defines the relevant regulations and standards.
— Application domain defines the requirement and constraints of the TOE.
— Audit domain conducts the audit and evaluation of validities of design of implementation for data
protection measures. As the feedback of the audit and evaluation, reasons are reported to System domain
and Operator domain.
Key
action
information
Figure 2 — Overall view of security design framework
5.3 Protection profile preparatory steps
The main purpose of a PP is to analyse the security environment of a subject and then to specify the
requirements for each of the threats identified by the security environment analysis. The subject studied is
called the target of evaluation (TOE). In this document, an OBE with an ICC is used as an example of the TOE.
The preparatory work of PP for EFC consists of the steps shown in Table 1, according to the contents
described in Clause 6.
For the first step, a general outline of TOE is prepared as overview. As the second step, features, interface
of TOE and its use case are defined and in the third step, security environment and its security policies are
defined. As the fourth step, security objectives are defined. Based on this preparation, the security functional
requirements and the assurance requirements are defined based on the requirements in ISO/IEC 15408. As
the 6th step, rationale of the defined functional and assurance requirements are checked.
Table 1 — Process of preparing a protection profile for EFC equipment
Step Description prepared by Toll service Contents
provider
1 Overview Overview of the description
2 Descriptions of the TOE An entity, an interface and necessity, security problems to be
addressed
3 Descriptions of the security environ- Threat analysis and security policies must be described concretely
ment
4 Security objectives How and what extends the security needs are to be met
5 Security functional and assurance The security functional requirements explain what must be done
requirements using requirements by the TOE and the environment of the TOE to meet the security
objectives. The assurance requirements explain the degree of con-
for the security functions provided in
fidence expected in the security functions of the TOE
ISO/IEC 15408.
6 Rationale Security Objectives and Security Requirements should be checked.
A PP may be registered publicly by the entity preparing the PP to make it known and available to other
parties that can use the same PP for their own EFC systems.
5.4 Relationship between actors
A security target (ST) represents a set of security requirements and specifications to be used as the basis
for evaluation of an identified TOE. While the PP can be looked upon as the EFC toll service provider’s
requirements, the ST can be looked upon as the relevant equipment’s supplier documentation for the
compliance of TOE with the PP (e.g. an OBE as the TOE).
Figure 3 shows a simplified picture and example of the relationships among toll service provider, the EFC
equipment supplier and an evaluator. The toll service provider prepares the PP and provides it to OBE
supplier to specify the security target to design and manufacturing the OBE. The PP is registered to National
Register for the future use for development of a new OBE. The OBE supplier prepares the ST and submits this
to the evaluator. The evaluator confirms the ST with the PP. After the evaluation, the OBE supplier designs
and manufactures the OBE.
[4]
NOTE The Common Criteria Recognition Arrangement includes provision for an international registrar.

Figure 3 — Relationships among operators, suppliers and evaluators
The ST is similar to the PP, except that it contains additional implementation-specific information detailing
how the security requirements are realized in a particular product or system. Hence, the ST includes the
following parts not present in a PP:
— a TOE summary specification that presents the TOE-specific security functions and assurance measures;
— an optional PP part that explains PPs with which the ST is claimed to be conformant (if any);
— a justification containing additional evidence establishing that the TOE summary specifications ensure
satisfaction of the implementation-independent requirements and that claims about PP conformance are
satisfied;
— actual security functions of EFC products will be designed based on this ST (see example in Figure 4).
The PP is prepared by referring to ISO/IEC 15408 or the PP database. A new PP is registered in the PP
database. The ST of the OBE is prepared referring to the PP stored in the database.

Figure 4 — Example of design based on a PP
6 Outline of protection profile (PP)
6.1 Structure
The content of a PP for a part or interface of an EFC system shall be in accordance with ISO/IEC 15408-1:2022,
Clause 10. An example is provided in Annex B.
a) Top page for title
b) Overview
c) Target of Evaluation
d) Conformance
e) Security Environment
f) Security Objectives
g) Security Requirements
h) Rationale
6.2 Context
Guidelines for preparing PP are as follows:
a) Overview (see A.1)
b) Target of evaluation (TOE, see A.2)

The scope of the TOE shall be specified.
c) Conformance
The conformance claims of PPs shall be specified.
d) Security environment (see A.3)
Development, operation and control methods of the TOE are described to clarify the working and operation
requirements. Regarding these requirements, IT assets, for which the TOE must be protected, and the
security threats to which the TOE is exposed, shall be specified.
e) Security objectives (see A.4)
Security policies for threats to the TOE are determined. The policies are divided into technical, operational
and control policy.
Security objectives should be consistent with the operational aim or product purpose of the TOE.
Operational and control policies are defined as personnel and physical objectives applicable to the status, in
which the TOE is used or operated. The operational and control policy include control and operational rules
for operators.
f) Security requirements (see A.5)
In accordance with the security objectives specified in A.4, specific security requirements for security
threats stated in A.3 are specified. The security requirements consist of functional requirements and
assurance requirements for security quality.
Functional requirements are provided, selecting necessary requirements from ISO/IEC 15408-2 and
determining parameters, which shall be in accordance with ISO/IEC 15408-2:2022, Clause 6 to Clause 18.
Regarding assurance requirements, assurance requirements specified in ISO/IEC 15408-3 are adopted
by determining evaluation levels for assurance requirements, which shall be in accordance with
ISO/IEC 15408-3:2022, Clause 5 to Clause 15.
The evaluation method and activities are included in the security requirements, which shall be in accordance
with ISO/IEC 15408-4:2022, Clauses 5 and 6.
The evaluation assurance levels are included in the security requirements, which shall be in accordance
with ISO/IEC 15408-5:2022, Clause 4.
g) Rationale of justification and effectiveness (see A.6)
The content of PP is checked when necessary and covers security requirements for the TOE. The checked
items are as follows:
— all security environments needed are covered;
— security objectives should completely meet the security environments;
— security requirements should implement security objectives.

Annex A
(informative)
Procedure to prepare the protection profile
A.1 Overview
A.1.1 General
A general outline of the protection profile (PP) is described in this annex.
This annex provides an example of how to prepare the security requirements for EFC relevant equipment, in
this case, an OBE with an ICC containing data needed for EFC.
A.1.2 Identification information
Identification information for the document with example is as follows:
a) document title
EXAMPLE 1 document title: OBE Security protection profile
b) version or release number
EXAMPLE 2 reference or version number: 1.0
c) preparation date
EXAMPLE 3 preparation date: 2002-10-20
d) name of the person responsible for preparing the PP document
EXAMPLE 4 prepared by: ABC Association
A.1.3 Target of evaluation (TOE) description
TOE in the prepared PP contains the following:
a) product
EXAMPLE 1 product: EFC OBE
b) version or release number
EXAMPLE 2 version or release number: 1.0
c) developer
EXAMPLE 3 developer: ABC Co., Ltd
A.1.4 In accordance with ISO/IEC 15408 (all parts)
The prepared PP according to ISO/IEC 15408 (all parts) and the edition of ISO/IEC 15408 are stated explicitly.
The PP shall be prepared according to the ISO/IEC 15408 series and its relation to the ISO/IEC 15408
series shall be stated in the PP. The statement of conformance includes conformance to each part of the
ISO/IEC 15408 series and state the relevant edition used.

An example of conformance statement according to ISO/IEC 15408 (all parts) is shown as follows:
EXAMPLE
— ISO/IEC 15408-1:2022(Edition 4)
— ISO/IEC 15408-2:2022 (Edition 4)
— ISO/IEC 15408-3:2022 (Edition 4)
— ISO/IEC 15408-4:2022 (Edition 1)
— ISO/IEC 15408-5:2022 (Edition 1)
A.1.5 Outline of TOE
A.1.5.1 Type of TOE
For users of security PP a type of TOE described in PP is described explicitly to help them determine the
application.
EXAMPLE
Type of TOE: EFC OBE
A.1.5.2 TOE functional outline
For users of security PP, a type of device described in PP is described explicitly to help them determine the
application. Examples are as follows:
EXAMPLE
TOE functional outline of an OBE
a) EFC function:
1) mutual authentication with ICC;
2) transcription (caching) of ICC data to OBE;
3) encryption of radio communication with RSE;
4) assurance of message integrity;
5) mutual authentication with RSE;
6) storage of secured information (encryption key) used in OBE during EFC transaction.
b) Set-up function:
1) authentication of set-up card;
2) caching of vehicle information from ICC to OBE.
c) HMI function:
1) report of EFC billing results to users;
2) guidance of EFC lane.
A.1.5.3 Evaluation Assurance Level (EAL)
Evaluation Assurance Levels for objectives are selected. Each EAL defines a package consisting of assurance
components and determines the degree of assurance requirements on security systems. The justification for
the selected EAL is stated.
EXAMPLE
EAL is 5 for the EFC OBE
OBE functions as equipment for e-Commerce in EFC transactions. The security systems of OBE are vulnerable to an
attack under the control of individual users. Therefore, a high assurance level (EAL) is needed for OBE.
A.2 Target of evaluation (TOE)
A.2.1 TOE objectives and methodology
A.2.1.1 TOE use objectives
The following example indicates objectives for TOE use and the type of environment in which it is used.
EXAMPLE EFC members (users) use the EFC system at tollgates by inserting the ICC with EFC member contract
information for settlement. Vehicle information such as an automobile inspection certification is stored in OBE
beforehand. For storing vehicle information, a personalization card for initialization is used. The OBE (TOE), which
reads/writes data to ICCs for set-ups/settlements and transmits/receives data to roadside equipment for toll collection
transactions, protects the interface and internal data from external threats.
A.2.1.2 TOE use methodology
The preparation and procedures of the TOE use methodologies are described as below.
a) User preparation; steps to be taken by user before use of TOE. An example is “User’s preparation: Users
request an operator to install an OBE and set up vehicle information such as automobile inspection
certification to OBE. In addition, users receive the ICC with EFC member contract information.”.
b) Operator’s preparation; necessary hardware/software and control systems are described when
operator operates TOE. An example is “Operator preparations: Operators issue set-up information in
response to user’s requests.”.
c) Operational procedures; procedures for operation and maintenance are described. An example is
“Operation procedures: When a user is passing through tollgates, the toll is billed to the ICCs for
settlement with EFC member contract information, which is inserted in the installed OBE with vehicle
information. When a legitimate ICC for settlement is inserted in the OBE with correct vehicle information,
the toll fee is calculated in the communication zone of RSE at tollgates. For a change or update of EFC
member contract information, such as vehicle information, set-up cards and ICC are updated (re-issued/
re-registered).”.
d) Use procedures; procedures for users are described. An example is “Use procedures: A user uses the
ICCs with EFC member contract information at tollgates within the EFC system according to the EFC
member contract or OBE manuals.”.
e) Limitations of use: limitations of use such as time zones and geographical zones are described. An
example for “Limitations of use is: In general, OBE is available at any time of day, as long as EFC lanes are
open at tollgates.”.
A.2.2 TOE functions
A.2.2.1 Functions provided by TOE
The following example shows the functions for data transactions provided by the TOE which require
protection.
EXAMPLE
a) EFC transactions:
1) EFC communication control function;
2) non-secure data record function;
3) HMI input/output control function;
4) ICC insert status detect function;
5) OBE self-check function.
b) Security module:
1) data storage or protection function;
2) user access control function;
3) authentication function (DSRC, ICC);
4) encryption/decryption function;
5) ICC interface function;
6) EFC transaction interface function;
7) personalization card read function.
A.2.2.2 Functions not provided by TOE
When the TOE function is a part of the functions of an entire system, the scope of the TOE in the whole
system is shown in Figure A.1 which shows an example where the OBE is the scope of the TOE. For reference,
Figure A.2 is showing the overall security policy scope.
Figure A.1 — Example where the TOE is shown in its context

Figure A.2 — Overall security policy scope
A.2.2.3 Missing functions
When functions, which usually should be provided by the TOE in subclause A.2.2, are not included in the
TOE, the function contents and reasoning for exclusion should be described.
A.2.3 TOE structure
A.2.3.1 Hardware structure
The structure with related hardware units on TOE operation is described. The scope of TOE in the structure
should be shown as in the example given in Figure A.3. Also, the overall EFC system model of the EFC Security
Framework should be shown as in Figure A.4.
Figure A.3 — Example of TOE hardware structure

Figure A.4 — EFC system model of the EFC Security Framework
A.2.3.2 Software structure
The software structure of the TOE should be stated. The distribution of functions should be described,
especially when the operation of the TOE depends on the operating system (OS) and data control programs.
A.2.3.3 Rationale
It should be verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.3 Conformance
A.3.1 Conformance claim and conformance statement of TOE
A.3.1.1 General
Regarding conformance related to the PP, two kinds of relationships are defined. One is the relationship
between the PP and the based common criteria (CC), the other relationship is between the ST and the PP.
Regarding these relationships, both conformance claim and conformance statement are to be described.

A.3.1.2 Conformance claim
Conformance claim is related to the relationship between the PP and the based CC.
a) Edition of the relevant parts of the CC is defined.
If all security functional requirements (SFRs) are based only upon functional requirement in ISO/IEC 15408-2
and ISO/IEC 15408-3, “conformant” should be selected otherwise “extended” should be selected.
EXAMPLE 1 Conforms with ISO/IEC 15408
b) Conformance to the CC Part2 is defined.
EXAMPLE 2 CC part2 conformant and extended
c) Conformance to the CC Part3 is defined.
EXAMPLE 3 CC part3 conformant and extended
d) Conformance claim rationale
Reason and logical basis of the choice of conformance claim is to be described.
A.3.1.3 Conformance statements
The conformance statement describes the way other PPs or STs shall conform to the PP. The conformance
statement shall be one of the three types of conformance:
— demonstrable,
— strict,
— exact.
EXAMPLE Conformance manner is “Strict”.
A.4 Security environment
A.4.1 General
Security requirements to determine security objectives for the TOE operation are provided.
A.4.2 Operational environments
A.4.2.1 General
The methodology of the use of the TOE such as the operational procedures, operational time, operational
sites, operational overview, use sites and limits and requirements are described.
A.4.2.2 Operational procedures
Regarding the operational procedures of the TOE, the operation of an integrated EFC system including the
related vehicles and ICC for payment are described.
A.4.2.3 Operational time
The operational time of the TOE is described.
EXAMPLE The operational time is any time that OBE equipped vehicles use roads tolled via EFC system

A.4.2.4 Operational sites
Operational sites of the TOE are described.
A.4.2.5 Operational overview
The procedures from the purchase (obtain) to the disposal of the TOE by users are described including
installation of the TOE, set-up of the TOE and operation at toll roads.
EXAMPLE 1 Users purchase EFC OBE at OBE dealers (car dealers, car shops). An OBE is installed in a vehicle. In
addition, the on-board information needed for the EFC operation such as vehicle information is stored as on-board
information.
EXAMPLE 2 After an EFC member contract is established, users get an ICC, which is issued by credit card companies.
EXAMPLE 3 Users will be able to use the EFC system by inserting an ICC in an OBE installed in a vehicle.
EXAMPLE 4 Users use toll roads with the ICC inserted in an OBE in an OBE equipped vehicle and pass through the
tollgates without stopping.
EXAMPLE 5 Users can voluntarily dispose of unnecessary OBE.
A.4.2.6 Use sites
Sites, where users can use TOE, are described.
EXAMPLE Toll roads, along which EFC RSE are installed.
A.4.2.7 Limits and requirements
Limits and requirements in use such as available numbers of TOE are described.
EXAMPLE 1 The number of OBE installed per vehicle is limited to one.
EXAMPLE 2 OBE is fixed (built-in) in a vehicle.
EXAMPLE 3 OBE can be used any time of day as long as EFC lanes are open for operation.
A.4.3 Physical control
A.4.3.1 General
Physical control related to the operation of the TOE is described.
A.4.3.2 Installation sites and control
Installation sites and physical control of the TOE are described.
EXAMPLE 1 OBE is fixed (built-in) in a vehicle.
A.4.3.3 User unit
For use of the TOE, the physical control requirements of ICC for payments, which users possess, are described.
EXAMPLE 2 Users are responsible for their ICC.

A.4.4 Personnel requirements
The personnel requirements for the responsibility and confidence of the TOE operations are described. In
addition, the requirements for potential uses, motivations, methods and expertise of attacks are provided.
a) TOE-related agents
The following items regarding the manufacturers, operators and users of TOE are stated.
1) Type
2) Role
3) Authorization
4) Reliance
5) Risk of illicit use
6) Expertise
7) Trail
EXAMPLE 1
Personnel requirements:
Type: Manufacturer of OBE.
Role: Manufacturing and shipping based on standard specification of EFC OBE.
Authorization: None.
Reliance: No responsibility for security control.
Risk of illicit use: There are risks of illicit use since the responsibility for security control is absent.
Expertise: No need of expertise for security.
Trail: Negative list check is implemented while OBE equipped vehicle are passing through
tollgates.
b) Attackers
The following items are described for illicit user requirements against which countermeasures are
taken by the TOE.
1) Type
2) Purpose of illicit use
3) Motivation
4) Means
5) Expertise
EXAMPLE 2 Attackers:
— Type: Illicit third party among EFC users.
— Purpose of illicit use: OBE data forgery, manipulation, obtaining of personal information. Forgery and illicit
modification of OBE medium.
— Motivation: To reduce toll fees or avoid toll fee claims by illicit use of information. Sale of forged OBE.

— Means: Forgery of vehicle information on OBE. Forgery of interface data between OBE and ICC to counterfeit
someone’s card. Forgery of EFC OBE by analysing OBE internally.
— Expertise: Comprehend the internal transaction by analysing EFC OBE internally.
A.4.5 Connectivity and operational environments
The environment for TOE connectivity and operation is provided. Only the structure, which is provided in
this subclause, shall be TOE.
a) Connectivity; Transactions for RSE at tollgates and ICC needed for the operation of the TOE are
described. An example is:
EXAMPLE Connectivity:
— OBE exchanges information via radio communication (5,8 GHz) with RSE at tollgates.
— OBE reads ICC data (card number, EFC member contract information) before the vehicle passes through a
tollgate. When a vehicle passes through a tollgate, OBE sends applicable ICC internal data to RSE to transmit
billing and transaction record data.
b) Operational requirements; Hardware and software requirements (central processing unit,
implementation speed, required memory, input and output devices) needed for operation of the TOE are
described.
A.4.6 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.5 Security threats
A.5.1 Determination of target resources for protection
A.5.1.1 Selection of target resources for protection
Target resources for protection, to be protected by the TOE, are determined. Resources, which negatively
impact services of the TOE by falsification, alteration and loss, are targeted for protection. Regarding
determined individual targeted resources for protection, the lifecycle such as generation, transaction,
storage and disposal are clearly described. If there are indirect resources for a TOE transaction, the indirect
resources are determined as well.
An example of selection of target resources for protection is shown as follows:
EXAMPLE Selection of target resources for protection:
a) Target protection resources to be protected by the TOE:
— EFC member contract information: ICC internal data (i.e. ICC number);
— vehicle information: OBE internal data such as vehicle classification codes;
— tollgate information: exit/enter information, barrier information and transaction record information;
— information stated above, transmitted by radio communication through OBE between roadside units at tollgates
and ICC;
— toll information: storage in ICC such as billing information.
b) Target resources for protection such as lifecycle:

— OBE installation in a vehicle;
— transcription of vehicle information into OBE;
— OBE operation at toll roads;
— OBE disposal.
A.5.1.2 Evaluation of target resources for protection
The values of determined target resources for protection are evaluated. The evaluation is divided into three
levels as follows:
Level 1: security problems are having an impact on the entire system for the TOE, e.g. the system might
be malfunctioning or down.
Level 2: security problems drastically compromise the value of the system for the TOE, e.g. the social
responsibility for the systems is impaired; however, restoration of systems is attainable.
Level 3: security problems hinder the operation of the TOE, e.g. operation of the system is temporarily
interrupted, resulting in serious impact on the users.
EXAMPLE Evaluation of target resources for protection:
Level 1: None (no target resource for protection, which impacts systems such as destroying EFC systems);
Level 2: EFC member contract information;
Level 3: Vehicle information, tollgate information, toll information.
A.5.2 Identification of security threats
Potential threats are identified by the level of determined target resources for protection. Concrete analysis
of target resources for protection is implemented in terms of who (what), where, when, how (counterfeiting,
tapping, destruction), means (available resources, interface, expertise), threats (falsification, exposure,
service interruption) and reasons.
a) Who (what); who (what) generates threats is stated.
b) Target resource: target resource for threats (billing data, personal information) is stated.
c) Contents of threats: major threats are as follows:
1) lack of confidentiality;
2) lack of protection;
3) lack of availability;
4) lack of responsibility;
5) lack of integrity;
6) lack of reliability.
d) Means: means generating attacks are stated.
e) Methodology: methodology of attacks is stated.
f) Motivation: motivation of attacks is stated.
g) Opportunity: opportunity of attacks is stated.
h) Weak points: security weaknesses are stated.

The threat analysis shall be conducted at each stage of TOE’s lifecycle, shown in Figure A.5.
Figure A.5 — TOE’s lifecycle
Threat analysis for lifecycle of target data for protection at stage 3 of the TOE (i.e. “OBE in operation”) is
shown in Table A.1.
Table A.1 — Threat analysis for OBE at stage 3(OBE in operation) — Example
Informa- Threat
tion for
Who Where When Methodology, means Threats Why
protection
EFC
member Forge ICC or inter-
Forgery and altering of Avoid toll
contract OBE While inserting ICC face data to falsify
ICC internal data fee claim
informa- someone’s card
tion
Vehicle Forgery and
Anytime/while Forgery of vehicle Reduce
informa- OBE manipulation of OBE
Illicit
passing tollgates codes of OBE toll fee
tion internal data
third
party
Tollgate Obtain
Eavesdropping
Tapping of radio
informa- personal
of radio
communication data
tion informa-
communication
Communication via
tion
OBE Communication data
DSRC (billing)
Replay the
Toll fee
manipulation
Reduce or
eavesdropped
informa-
avoid toll
Replay attack
data
tion
fee
A.5.3 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.6 Security policy of operational entity
A.6.1 General
Security items for operational entities for the TOE are provided in accordance with the rules and policies.
The document names describing concrete rules are described.
A.6.2 Identification of security policies of operational entities
Security policies of operational entities are described in this s
...

Norme
internationale
ISO 17574
Première édition
Perception de télépéage —
2026-09
Exigences relatives aux profils de
protection de sécurité
Electronic fee collection — Requirements for security protection
profiles
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2026
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d'application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Abréviations . 2
5 Processus relatifs à l'architecture de sécurité et au profil de protection d'un EFC . 2
5.1 Généralités .2
5.2 Architecture de sécurité d'un EFC .3
5.3 Étapes préparatoires du profil de protection .3
5.4 Relation entre les acteurs .4
6 Présentation du profil de protection (PP) . 6
6.1 Structure .6
6.2 Contexte .6
Annexe A (informative) Procédure de préparation du profil de protection . 8
Annexe B (informative) Exemple de méthode d'évaluation pour l'analyse des menaces .45
Annexe C (informative) Normes de sécurité pertinentes dans le contexte de l'EFC .51
Bibliographie .52

iii
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux
de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général
confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a
été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir
www.iso.org/directives).
L'ISO attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation
d'un ou de plusieurs brevets. L'ISO ne prend pas position quant à la preuve, à la validité et à l'applicabilité de
tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l'ISO n'avait pas
reçu notification qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois,
il y a lieu d'avertir les responsables de la mise en application du présent document que des informations
plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à l'adresse
www.iso.org/brevets. L'ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits de
brevets.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l'intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de
l'ISO aux principes de l'Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 204, Systèmes de transport intelligents, en
collaboration avec le comité technique CEN/TC 278, Systèmes de transport intelligents du Comité européen
de normalisation (CEN) conformément à l'Accord de coopération technique entre l'ISO et le CEN (Accord de
Vienne).
Cette première édition annule et remplace la troisième édition (ISO/TS 17574:2017), qui a fait l'objet d'une
révision technique.
Les principales modifications sont les suivantes:
— l'Article 3 a été mis à jour et l'ISO 17573-2 constitue la source principale pour les termes et définitions;
— les exigences ont été mises à jour pour refléter la dernière édition de la série ISO/IEC 15408.
Il convient que l'utilisateur adresse tout retour d'information ou toute question concernant le présent
document à l'organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l'adresse www.iso.org/members.html.

iv
Introduction
Les systèmes de perception de télépéage (EFC) sont exposés à plusieurs formes de fraude, tant par les
utilisateurs que par les exploitants, mais également par des personnes extérieures au système. Ces menaces
de sécurité sont traitées à l'aide de différents types de mesures de sécurité, corrélées aux exigences de
sécurité spécifiées.
Il est recommandé que les exploitants de systèmes EFC établissent leur propre profil de protection (PP) EFC
conformément au présent document, car il convient de décrire les exigences de sécurité du point de vue de
l'exploitant.
Un profil de protection (PP) désigne un ensemble d'exigences de sécurité pour une catégorie de produits
ou de systèmes qui répondent à des besoins spécifiques. Un exemple type est un PP pour les équipements
embarqués (OBE) destinés à être utilisés dans un système EFC. Cependant, les exigences du présent
document sont ignorées s'il existe déjà un PP pour le sous-système considéré.
La cible d'évaluation (TOE) d'un EFC est limitée aux rôles et interfaces spécifiques à l'EFC, comme cela est
représenté à la Figure 1. La Figure 1 montre les relations et les interactions entre les entités liées à la TOE
de l'EFC. Comme le montre cette figure, les entités sont la gestion générale de l'environnement de perception
du péage, le fournisseur de service EFC, le percepteur de péage et l'utilisateur du service. Étant donné qu'ils
s'appliquent à d'autres rôles et interfaces externes, les normes et les critères de sécurité financière existants
ne relèvent pas du domaine d'application de la TOE pour les systèmes EFC.
Figure 1 — Domaine d'application de la TOE pour les systèmes EFC
L'évaluation de la sécurité est effectuée en évaluant les propriétés relatives à la sécurité des rôles, des entités
et des interfaces définies dans les cibles de sécurité (ST), plutôt qu'en évaluant des processus complets qui
sont souvent répartis sur un plus grand nombre d'entités et d'interfaces que celles qui sont couvertes par la
TOE du présent document.
NOTE L'évaluation des problèmes de sécurité pour les processus complets est une approche complémentaire qui
peut être utile pour l'évaluation de la sécurité d'un système.
Il convient de noter que les exigences fournies dans le présent document sont destinées à être lues
conjointement avec la série ISO/IEC 15408 (toutes les parties). L'Annexe A explique comment préparer
les exigences de sécurité pour les équipements EFC, en prenant l'exemple d'un équipement embarqué de
communications dédiées à courte portée (DSRC) équipé d'une ou plusieurs carte(s) à circuit(s) intégré(s)
(ICC) contenant les données nécessaires pour l'EFC. L'exemple se rapporte à un système EFC national
japonais, et il convient de le considérer uniquement comme un exemple.

v
Après la phase de préparation, le PP d'un EFC peut être enregistré à l'échelle internationale par l'organisme
qui l'a préparé, afin que d'autres exploitants ou pays qui souhaitent développer des services de sécurité pour
leur système EFC puissent se référer à un PP d'un EFC déjà enregistré.
Le présent document relatif au cadre de service de sécurité et aux PP d'EFC est fondé sur la série
ISO/IEC 15408. La série ISO/IEC 15408 contient un ensemble d'exigences relatives aux fonctions de sécurité
et à l'assurance des produits et systèmes pertinents pour les technologies de l'information. Les exploitants,
les organismes ou les autorités qui définissent leur propre PP d'EFC peuvent s'appuyer sur ces exigences. Les
différents PP d'EFC définis par les exploitants, les organismes ou les autorités sont similaires aux différents
PP enregistrés par plusieurs institutions financières, par exemple pour les instruments de paiement tels que
les cartes à circuits intégrés (ICC).
Les produits et systèmes qui ont été développés conformément à la série ISO/IEC 15408 peuvent être assurés
publiquement par l'authentification d'organismes d'évaluation publics ou privés désignés.

vi
Norme internationale ISO 17574:2026(fr)
Perception de télépéage — Exigences relatives aux profils de
protection de sécurité
1 Domaine d'application
Le présent document spécifie les exigences relatives à la perception électronique du péage (EFC) pour la
préparation et l'évaluation des spécifications relatives aux exigences de sécurité, appelées «profils de
protection» (PP) dans la série ISO/IEC 15408 et dans l'ISO/IEC TR 15446.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l'édition citée s'applique. Pour
les références non datées, la dernière édition du document de référence s'applique (y compris les éventuels
amendements).
ISO/IEC 15408-1, Technologies de l’information — Techniques de sécurité — Critères d’évaluation pour la
sécurité TI — Partie 1: Introduction et modèle général
ISO/IEC 15408-2:2022, Sécurité de l'information, cybersécurité et protection de la vie privée — Critères
d'évaluation pour la sécurité des technologies de l'information — Partie 2: Composants fonctionnels de sécurité
ISO/IEC 15408-3:2022, Sécurité de l'information, cybersécurité et protection de la vie privée — Critères
d'évaluation pour la sécurité des technologies de l'information — Partie 3: Composants d'assurance de sécurité
ISO/IEC 15408-4:2022, Sécurité de l'information, cybersécurité et protection de la vie privée — Critères
d'évaluation pour la sécurité des technologies de l'information — Partie 4: Cadre prévu pour la spécification des
méthodes d'évaluation et des activités connexes
ISO/IEC 15408-5:2022, Sécurité de l'information, cybersécurité et protection de la vie privée — Critères
d'évaluation pour la sécurité des technologies de l'information — Partie 5: Paquets prédéfinis d'exigences de
sécurité
ISO 17573-2, Perception de télépéage — Architecture de systèmes pour le péage lié aux véhicules — Partie 2:
Vocabulaire
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l'ISO 17573-2 s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— IEC Electropedia: disponible à l'adresse https:// www .electropedia .org/
— ISO Online browsing platform: disponible à l'adresse https:// www .iso .org/ obp

4 Abréviations
CC critères communs
CCRA accord de reconnaissance des critères communs [common criteria recognition arrangement]
CN réseaux cellulaires [cellular networks]
DSRC communications dédiées à courte portée [dedicated short-range communication]
EAL niveau d'assurance d'évaluation [evaluation assurance level]
EFC perception de télépéage [electronic fee collection]
GNSS système mondial de navigation par satellite [global navigation satellite system]
IHM interface homme-machine
ICC carte à circuit(s) intégré(s) [integrated circuit(s) card]
TI technologies de l'information
OBE équipement embarqué [on-board equipment]
PP profil de protection
RSE équipement en bord de route [roadside equipment]
SAM module d'application sécurisé [secure application module]
SFP politique de fonction de sécurité [security function policy]
SFR exigence fonctionnelle de sécurité [security functional requirement]
ST cible de sécurité [security target]
TOE cible d'évaluation [target of evaluation]
TSF fonction de sécurité de la cible d'évaluation [target of evaluation security function]
5 Processus relatifs à l'architecture de sécurité et au profil de protection d'un EFC
5.1 Généralités
Le présent article donne une vue d'ensemble du contexte et de l'utilisation du présent document en ce qui
concerne les processus relatifs à l'architecture de sécurité et au profil de protection d'un EFC.
Le présent document est destiné à être lu conjointement avec la série ISO/IEC 15408 et l'ISO/IEC TR 15446.
Un lecteur qui n'est pas familier de ces normes peut lire la première partie du présent document pour obtenir
une vue d'ensemble de la manière d'établir un PP pour des équipements EFC. Cependant, les annexes, et
en particulier les Articles A.4 et A.5, exigent du lecteur qu'il soit familiarisé avec la série ISO/IEC 15408.
Le présent document utilise l'exemple d'un équipement embarqué équipé d'une carte à circuit(s) intégré(s)
(ICC) pour décrire à la fois la structure du PP et le contenu proposé.
L'Annexe A fournit la procédure pour la préparation du PP d'un EFC en utilisant un équipement embarqué
comme exemple d'équipements EFC. La liaison de communication (entre l'équipement embarqué et
l'équipement en bord de route) est fondée sur une DSRC.
L'Annexe B donne un exemple de la manière dont peut être réalisée une analyse des menaces, tandis que
l'Annexe C donne une vue d'ensemble des normes de sécurité pertinentes dans le contexte de l'EFC, qui
établit le contexte des rôles et des interfaces de l'EFC.

5.2 Architecture de sécurité d'un EFC
La Figure 2 montre comment le présent document se positionne dans la vue globale de l'architecture de
sécurité d'un EFC, en mettant en évidence les relations entre les domaines associés et les dépendances en
matière d'informations. Les zones ombrées représentent les aspects principalement liés à la préparation des
PP pour les systèmes EFC.
Dans le cadre de conception de sécurité, cinq domaines sont identifiés. Les fonctions de ces domaines sont
décrites ci-dessous.
— Le domaine exploitants définit l'exigence de protection des données de la TOE sous la forme d'un PP.
— Le domaine système développe la ST par rapport à cette exigence. Pour l'élaboration de la ST, l'évaluation
des menaces et des risques est réalisée en rapprochant le coût et l'effet des mesures de sécurité.
— Le domaine juridique définit les réglementations et normes applicables.
— Le domaine d'application définit les exigences et contraintes de la TOE.
— Le domaine audit procède à des audits pour évaluer la validité de la conception pour la mise en œuvre
des mesures de protection des données. Les retours d'information, ainsi que les motifs, sont tracés et
attribués aux domaines appropriés (domaine système et domaine exploitants).
Légende
action
informations
Figure 2 — Vue d'ensemble du cadre de conception de sécurité
5.3 Étapes préparatoires du profil de protection
L'objectif principal d'un PP est d'analyser l'environnement de sécurité d'un sujet, puis de spécifier les
exigences pour traiter chacune des menaces identifiées par l'analyse de l'environnement de sécurité. Le sujet
étudié est appelé «cible d'évaluation» (TOE). Dans le présent document, un équipement embarqué doté d'une
ICC est utilisé comme exemple de TOE.
Le travail de préparation d'un PP d'EFC comprend les étapes indiquées dans le Tableau 1, selon le contenu
décrit à l'Article 6.
Pour la première étape, une présentation générale de la TOE est effectuée sous la forme d'une vue
d'ensemble. Les caractéristiques, l'interface et le cas d'utilisation de la TOE sont définis au cours de la
deuxième étape, tandis que l'environnement de sécurité et ses politiques de sécurité sont définis durant la
troisième étape. Les objectifs de sécurité sont définis pendant la quatrième étape. À partir de ce travail, les
exigences fonctionnelles de sécurité et les exigences d'assurance sont définies par rapport aux exigences de
l'ISO/IEC 15408. À la sixième étape, la justification des exigences fonctionnelles et d'assurance définies est
alors vérifiée.
Tableau 1 — Processus de préparation d'un profil de protection pour les équipements EFC
Étape Description préparée par le fournis- Contenu
seur de service de péage
1 Vue d'ensemble Vue d'ensemble de la description
2 Descriptions de la TOE Une entité, une interface et une nécessité, problèmes de sécurité à
traiter
3 Descriptions de l'environnement de L'analyse des menaces et les politiques de sécurité doivent être
sécurité décrites en termes concrets
4 Objectifs de sécurité Objectifs et moyens mis en œuvre pour répondre aux besoins en
matière de sécurité
5 Exigences fonctionnelles de sécurité et Les exigences fonctionnelles de sécurité précisent les choses à faire
exigences d'assurance, définies à partir par la TOE et l'environnement de la TOE pour atteindre les objectifs de
des exigences pour les fonctions de sécurité. Les exigences d'assurance expliquent le degré de confiance
sécurité fournies dans l'ISO/IEC 15408 attendu dans les fonctions de sécurité de la TOE
6 Fondement logique Il convient de vérifier les objectifs de sécurité et les exigences de
sécurité.
Un PP peut être enregistré publiquement par l'entité qui prépare le PP afin de le faire connaître et de le
mettre à la disposition d'autres parties qui peuvent utiliser le même PP pour leurs propres systèmes EFC.
5.4 Relation entre les acteurs
Une cible de sécurité (ST) représente un ensemble d'exigences et de spécifications de sécurité destinées
à être utilisées pour l'évaluation d'une TOE identifiée. Alors que le PP peut être considéré comme le reflet
des exigences du fournisseur de service de péage EFC, la ST peut être considérée comme la documentation
fournisseur de l'équipement approprié pour documenter la conformité de la TOE vis-à-vis du PP (par
exemple, l'équipement embarqué est une TOE).
La Figure 3 représente une image simplifiée et un exemple des relations entre le fournisseur de service de
péage, le fournisseur d'équipements EFC et un évaluateur. Le fournisseur de service de péage prépare le PP et
le fournit au fournisseur d'équipements embarqués afin de spécifier l'objectif de sécurité pour la conception
et la fabrication de l'équipement embarqué. Le PP est enregistré au bureau d'enregistrement national pour
utilisation ultérieure dans le cadre du développement d'un nouvel équipement embarqué. Le fournisseur
d'équipements embarqués prépare la ST et la soumet à l'évaluateur. L'évaluateur confirme la conformité de
la ST au PP. Après l'évaluation, le fournisseur d'équipements embarqués conçoit et fabrique les équipements
embarqués.
[4]
NOTE L'Accord de reconnaissance des critères communs inclut une disposition pour un bureau d'enregistrement
international.
Figure 3 — Relations entre exploitants, fournisseurs et évaluateurs
La ST est similaire au PP, à ceci près qu'elle contient des informations spécifiques à la mise en œuvre qui
précisent la manière dont les exigences de sécurité sont réalisées dans un produit ou un système donné. Par
conséquent, la ST comprend les parties suivantes qui ne sont pas présentes dans un PP:
— une spécification récapitulative de la TOE qui présente les fonctions de sécurité et les mesures d'assurance
spécifiques à la TOE;
— une partie PP facultative qui explique les PP auxquels la ST revendique la conformité (le cas échéant);
— une justification contenant des éléments de preuve supplémentaires attestant que les spécifications
récapitulatives de la TOE permettent de satisfaire aux exigences indépendantes de la mise en œuvre et
garantissent le respect des revendications de conformité du PP;
— les fonctions de sécurité réelles des produits EFC sont conçues à partir de cette ST (voir l'exemple à la
Figure 4). Le PP est préparé en se référant à l'ISO/IEC 15408 ou à la base de données PP. Un nouveau PP
est enregistré dans la base de données PP. La ST de l'équipement embarqué est préparée en se référant
au PP stocké dans la base de données.

Figure 4 — Exemple de conception fondée sur un PP
6 Présentation du profil de protection (PP)
6.1 Structure
Le contenu d'un PP d'une partie ou d'une interface d'un système EFC est représenté à la Figure 6, qui doit
être conforme à l'ISO/IEC 15408-1:2022, Article 10. L'exemple est fourni à l'Annexe B.
a) Haut de la page pour le titre
b) Vue d'ensemble
c) Cible d'évaluation
d) Conformité
e) Environnement de sécurité
f) Objectifs de sécurité
g) Exigences de sécurité
h) Fondement logique
6.2 Contexte
Les lignes directrices pour la préparation du PP sont les suivantes.
a) Vue d'ensemble (voir l'Article A.1)
b) Cible d'évaluation (voir l'Article A.2)

Le domaine d'application de la TOE doit être spécifié.
c) Conformité
Les revendications de conformité des PP doivent être spécifiées.
d) Environnement de sécurité (voir l'Article A.3)
Les méthodes d'élaboration, d'exploitation et de contrôle de la TOE sont décrites pour clarifier les
exigences de fonctionnement et d'exploitation. En ce qui concerne ces exigences, les actifs de technologie de
l'information qui nécessitent une protection de la TOE doivent être spécifiés, de même que les menaces de
sécurité auxquelles est exposée la TOE.
e) Objectifs de sécurité (voir l'Article A.4)
Les politiques de sécurité relatives aux menaces auxquelles est exposée la TOE sont déterminées. Les
politiques sont classées en politiques techniques, d'exploitation et de contrôle.
Il convient que les objectifs de sécurité soient cohérents avec l'objectif opérationnel ou la finalité du produit
de la TOE.
Les politiques d'exploitation et de contrôle se rapportent au personnel et aux objectifs physiques applicables
à l'état dans lequel la TOE est utilisée ou exploitée. La politique d'exploitation et de contrôle comprend des
règles de contrôle et d'exploitation pour les exploitants.
f) Exigences de sécurité (voir l'Article A.5)
Conformément aux objectifs de sécurité spécifiés à l'Article A.4, des exigences de sécurité concrètes sont
spécifiées pour les menaces de sécurité énoncées à l'Article A.3. Les exigences de sécurité comprennent les
exigences fonctionnelles et les exigences d'assurance relatives à la qualité de la sécurité.
Les exigences fonctionnelles sont spécifiées, en choisissant les exigences nécessaires parmi
celles de l'ISO/IEC 15408-2 et en déterminant les paramètres, lesquels doivent être conformes à
l'ISO/IEC 15408-2:2022, Articles 6 à 18.
En ce qui concerne les exigences d'assurance, les exigences d'assurance spécifiées dans l'ISO/IEC 15408-3
sont adoptées en déterminant les niveaux d'évaluation des exigences d'assurance, lesquels doivent être
conformes à l'ISO/IEC 15408-3:2022, Articles 5 à 15.
La méthode et les activités d'évaluation sont incluses dans les exigences de sécurité qui doivent être
conformes à l'ISO/IEC 15408-4:2022, Articles 5 et 6.
Les niveaux d'assurance d'évaluation sont inclus dans les exigences de sécurité qui doivent être conformes à
l'ISO/IEC 15408-5:2022, Article 4.
g) Fondement logique de la justification et de l'efficacité (voir l'Article A.6)
Le contenu du PP est vérifié lorsque cela est nécessaire et couvre les exigences de sécurité de la TOE. Les
points suivants sont vérifiés:
— tous les environnements de sécurité nécessaires sont couverts;
— il convient que les objectifs de sécurité couvrent entièrement les environnements de sécurité;
— il convient que les exigences de sécurité mettent en œuvre les objectifs de sécurité.

Annexe A
(informative)
Procédure de préparation du profil de protection
A.1 Vue d'ensemble
A.1.1 Généralités
La présente annexe fournit une présentation générale du profil de protection (PP).
La présente annexe explique comment préparer les exigences de sécurité pour des équipements EFC, en
prenant l'exemple d'un équipement embarqué équipé d'une ICC contenant les données nécessaires pour
l'EFC.
A.1.2 Informations d'identification
Les informations d'identification du document sont fournies ci-dessous, avec des exemples:
a) titre du document
EXEMPLE 1 titre du document: Profil de protection de sécurité de l'équipement embarqué
b) numéro de version ou de publication
EXEMPLE 2 numéro de référence ou de version: 1.0
c) date d'élaboration
EXEMPLE 3 date d'élaboration: 2002-10-20
d) nom de la personne responsable de la préparation du document PP
EXEMPLE 4 préparé par: Association ABC
A.1.3 Description de la cible d'évaluation (TOE)
La TOE dans le PP préparé est fournie comme suit, par exemple:
a) produit
EXEMPLE 1 produit: Équipement embarqué d'un système EFC
b) numéro de version ou de publication
EXEMPLE 2 numéro de version ou de publication: 1.0
c) développeur
EXEMPLE 3 développeur: ABC Co., Ltd
A.1.4 Conformément à l'ISO/IEC 15408 (toutes les parties)
Le PP préparé conformément à l'ISO/IEC 15408 (toutes les parties) et l'édition de l'ISO/IEC 15408 sont
indiqués explicitement.
Le PP doit être préparé conformément à la série ISO/IEC 15408, et sa relation avec la série ISO/IEC 15408
doit être indiquée dans le PP. La déclaration de conformité inclut la conformité à chaque partie de la série
ISO/IEC 15408 et indique l'édition correspondante utilisée.
Des exemples de déclarations de conformité conformes à l'ISO/IEC 15408 (toutes les parties) sont fournis
ci-dessous:
EXEMPLE
— ISO/IEC 15408-1:2022 (Édition 4)
— ISO/IEC 15408-2:2022 (Édition 4)
— ISO/IEC 15408-3:2022 (Édition 4)
— ISO/IEC 15408-4:2022 (Édition 1)
— ISO/IEC 15408-5:2022 (Édition 1)
A.1.5 Présentation de la TOE
A.1.5.1 Type de TOE
Pour les utilisateurs d'un PP de sécurité, un type de TOE décrit dans le PP est décrit explicitement afin de les
aider à déterminer l'application.
EXEMPLE
1.4.1 Type de TOE
Type de TOE: Équipement embarqué d'un système EFC
A.1.5.2 Présentation fonctionnelle de la TOE
Pour les utilisateurs d'un PP de sécurité, un type de dispositif décrit dans le PP est décrit explicitement afin
de les aider à déterminer l'application. Des exemples sont fournis ci-dessous:
EXEMPLE
1.4.2 Présentation fonctionnelle de la TOE (équipement embarqué pour un système EFC)
La présentation fonctionnelle est la suivante.
a) Fonction de l'EFC:
1) authentification mutuelle avec l'ICC;
2) transcription (mise en cache) des données de l'ICC vers l'équipement embarqué;
3) chiffrement de la radiocommunication avec l'équipement en bord de route;
4) assurance de l'intégrité du message;
5) authentification mutuelle avec l'équipement en bord de route;
6) stockage des informations sécurisées (clé de chiffrement) utilisées dans l'équipement embarqué lors d'une
transaction EFC.
b) Fonction de configuration:
1) authentification de la carte de configuration;
2) mise en cache des informations du véhicule entre l'ICC et l'équipement embarqué.
c) Fonction de l'IHM:
1) compte rendu des résultats de la facturation EFC aux utilisateurs;

2) orientation de la voie EFC.
A.1.5.3 Niveau d'assurance d'évaluation (EAL)
Les niveaux d'assurance de l'évaluation pour les objectifs sont choisis. Chaque EAL définit un paquetage
comprenant des composants d'assurance et détermine le degré d'exigences d'assurance sur les systèmes de
sécurité. La justification de l'EAL choisi est indiquée.
EXEMPLE
1.5.3 Équipement embarqué d'un système EFC (l'EAL est de 5)
L'équipement embarqué fonctionne à la manière d'un équipement de commerce électronique dans les transactions
EFC. Les systèmes de sécurité de l'équipement embarqué sont vulnérables aux attaques sous le contrôle d'utilisateurs
individuels. Par conséquent, un niveau d'assurance élevé (EAL) est exigé pour l'équipement embarqué.
A.2 Cible d'évaluation (TOE)
A.2.1 Objectifs et méthodologie de la TOE
A.2.1.1 Objectifs d'utilisation de la TOE
L'exemple suivant indique les objectifs d'utilisation de la TOE et le type d'environnement dans lequel elle est
utilisée.
EXEMPLE Les adhérents au système EFC (utilisateurs) utilisent le système EFC aux péages en insérant l'ICC avec
les informations du contrat d'adhésion EFC pour procéder au règlement. Les informations du véhicule, telles qu'une
certification d'inspection automobile, sont stockées au préalable dans l'équipement embarqué. Pour le stockage des
informations du véhicule, une carte de personnalisation est utilisée à des fins d'initialisation. L'équipement embarqué
(la TOE), qui lit/écrit les données sur les ICC pour les configurations/règlements et transmet/reçoit les données à
l'équipement en bord de route pour les transactions de perception de péage, protège l'interface et les données internes
contre les menaces externes.
A.2.1.2 Méthode d'utilisation de la TOE
La préparation et les procédures des méthodes d'utilisation de la TOE sont décrites ci-dessous.
a) Préparation de l'utilisateur; étapes à suivre par l'utilisateur avant d'utiliser la TOE. Un exemple possible
est «Préparation de l'utilisateur: les utilisateurs demandent à un exploitant d'installer un équipement
embarqué et de configurer les informations du véhicule, telles qu'une certification d'inspection
automobile, dans l'équipement embarqué. En outre, les utilisateurs reçoivent l'ICC contenant les
informations du contrat d'adhésion EFC.»
b) Préparation de l'exploitant; le matériel/logiciel et les systèmes de commande nécessaires sont décrits
lorsque l'exploitant fait fonctionner la TOE. Un exemple possible est «Préparation de l'exploitant: les
exploitants émettent les informations de configuration en réponse aux demandes de l'utilisateur.»
c) Procédures d'exploitation; les procédures d'exploitation et de maintenance sont décrites. Un exemple
possible est «Procédures d'exploitation: lorsqu'un utilisateur franchit des péages, le péage est facturé
aux ICC à des fins de règlement au moyen des informations du contrat d'adhésion EFC, qui sont insérées
dans l'équipement embarqué installé avec les informations du véhicule. Lorsqu'une ICC de règlement
légitime est insérée dans l'équipement embarqué avec des informations de véhicule correctes, la
redevance de péage est calculée dans la zone de communication de l'équipement en bord de route au
niveau des péages. Pour une modification ou une mise à jour des informations du contrat d'adhésion EFC,
telles que les informations du véhicule, les cartes de configuration et l'ICC sont mises à jour (réémises/
réenregistrées).»
d) Procédures d'utilisation: les procédures à l'attention des utilisateurs sont décrites. Un exemple possible
est «Procédures d'utilisation: au niveau des péages, un utilisateur utilise dans le système EFC les ICC

contenant les informations du contrat d'adhésion EFC, conformément au contrat d'adhésion EFC ou aux
manuels de l'équipement embarqué.»
e) Limites d'utilisation: les limites d'utilisation, telles que les fuseaux horaires et les zones géographiques,
sont décrites. Un exemple possible est «Limites d'utilisation: en général, l'équipement embarqué est
disponible à tout moment de la journée, à condition que les voies EFC soient ouvertes aux péages.»
A.2.2 Fonctions de la TOE
A.2.2.1 Fonctions fournies par la TOE
Les éléments suivants donnent des exemples pour les fonctions relatives aux transactions de données
fournies par la TOE qui nécessitent une protection.
EXEMPLE
a) Transactions EFC:
1) fonction de commande de la communication EFC;
2) fonction d'enregistrement de données non sécurisée;
3) fonction de commande des entrées/sorties de l'IHM;
4) fonction de détection d'état d'insertion de l'ICC;
5) fonction d'autocontrôle de l'équipement embarqué.
b) Module de sécurité:
1) fonction de stockage ou de protection des données;
2) fonction de contrôle d'accès de l'utilisateur;
3) fonction d'authentification (DSRC, ICC);
4) fonction de chiffrement/déchiffrement;
5) fonction d'interface de l'ICC;
6) fonction d'interface des transactions EFC;
7) fonction de lecture de la carte de personnalisation.
A.2.2.2 Fonctions non fournies par la TOE
Lorsque la fonction TOE fait partie des fonctions d'un système entier, le domaine d'application de la TOE
dans l'ensemble du système est tel que représenté à la Figure A.1 qui montre un exemple dans lequel
l'équipement embarqué représente le domaine d'application de la TOE. À titre de référence, la Figure A.2
montre le domaine d'application global de la politique de sécurité.

Figure A.1 — Exemple de représentation de la TOE dans son contexte
Figure A.2 — Domaine d'application global de la politique de sécurité
A.2.2.3 Fonctions manquantes
Lorsque les fonctions, qu'il convient que la TOE fournisse, indiquées au A.2.2, ne sont pas incluses dans le
TOE, il convient de décrire le contenu de la fonction et la justification de son exclusion.
A.2.3 Structure de la TOE
A.2.3.1 Structure matérielle
La structure est décrite avec les unités matérielles associées au fonctionnement de la TOE. Il convient
d'indiquer le domaine d'application de la TOE dans la structure, comme dans l'exemple de la Figure A.3. Il
convient également d'indiquer le modèle de système EFC global du cadre de sécurité EFC comme cela est
représenté à la Figure A.4.
Figure A.3 — Exemple de structure matérielle de la TOE
Figure A.4 — Modèle de système EFC du cadre de sécurité EFC
A.2.3.2 Structure logicielle
Il convient d'indiquer la structure logicielle de la TOE. Il convient de décrire la répartition des fonctions, en
particulier lorsque le fonctionnement de la TOE dépend du système d'exploitation (OS) et des programmes
de contrôle des données.
A.2.3.3 Fondement logique
Il convient de vérifier que les éléments décrits sont cohérents.
a) Absence d'éléments incohérents parmi les éléments fournis.
b) Absence de sections non définies ou ambigües dans le contenu fourni dans le présent paragraphe.
A.3 Conformité
A.3.1 Revendication de conformité et déclaration de conformité de la TOE
A.3.1.1 Généralités
En ce qui concerne la conformité liée au PP, deux types de relations sont définis. La première est la relation
entre le PP et les critères communs (CC) utilisés comme base, la seconde est la relation entre la ST et le PP. La
revendication de conformité et la déclaration de conformité doivent toutes deux être décrites au regard de
ces relations.
A.3.1.2 Revendication de conformité
La revendication de conformité est liée à la relation entre le PP et les CC utilisés comme base.
a) L'édition des parties pertinentes des CC est définie.
Si toutes les exigences fonctionnelles de sécurité (SFR) sont fondées uniquement sur les exigences
fonctionnelles de l'ISO/IEC 15408-2 et de l'ISO/IEC 15408-3, il convient de choisir le terme «conforme».
Sinon, il convient de choisir le terme «élargi».
EXEMPLE 1 Conforme à l'ISO/IEC 15408
b) La conformité à la Partie 2 des CC est définie.
EXEMPLE 2 Conforme à la Partie 2 des CC et élargi
c) La conformité à la Partie 3 des CC est définie.
EXEMPLE 3 Conforme à la Partie 3 des CC et élargi
d) Fondement logique de la revendication de conformité
La raison et le fondement logique du choix de la revendication de conformité doivent être décrites.
A.3.1.3 Déclarations de conformité
La déclaration de conformité décrit la manière dont les autres PP ou ST doivent se conformer au PP. La
déclaration de conformité doit correspondre à l'un des trois types de conformité suivants:
— démontrable;
— strict;
— exact.
EXEMPLE Le mode de conformité est «Strict».

A.4 Environnement de sécurité
A.4.1 Généralités
Les exigences de sécurité qui s'appliquent pour déterminer les objectifs de sécurité du fonctionnement de la
TOE sont fournies.
A.4.2 Environnements d'exploitation
La méthodologie d'utilisation de la TOE est décrite, par exemple les procédures d'exploitation, le temps
d'exploitation, les sites d'exploitation, la vue d'ensemble de l'exploitation, les sites d'utilisation, ainsi que les
limites et exigences.
A.4.2.1 Procédures d'exploitation
En ce qui concerne les procédures d'exploitation de la TOE, le fonctionnement d'un système EFC intégré est
décrit, y compris les véhicules associés et l'ICC utilisée pour le paiement.
A.4.2.2 Temps d'exploitation
Le temps d'exploitation de la TOE est décrit.
EXEMPLE Le temps d'exploitation correspond à tout moment où les véhicules équipés OBE empruntent des routes
à péage via le système EFC
A.4.2.3 Sites d'exploitation
Les sites d'exploitation de la TOE sont décrits.
A.4.2.4 Vue d'ensemble de l'exploitation
Les procédures allant de l'achat (obtention) jusqu'à la cession de la TOE par les utilisateurs sont décrites,
notamment l'installation de la TOE, la configuration de la TOE et l'exploitation sur les routes à péage.
EXEMPLE 1 Les utilisateurs achètent un équipement embarqué EFC auprès de revendeurs d'équipements
embarqués (concessionnaires automobiles, garages). Un équipement embarqué est installé dans un véhicule. En outre,
les informations embarquées nécessaires au fonctionnement du système EFC, telles que les informations relatives aux
véhicules, sont stockées sous forme d'informations embarquées.
EXEMPLE 2 Après l'établissement d'un contrat d'adhésion EFC, les utilisateurs obtiennent une ICC qui est délivrée
par des sociétés de cartes de crédit.
EXEMPLE 3 Les utilisateurs seront en mesure d'utiliser le système EFC en insérant une ICC dans un équipement
embarqué installé dans un véhicule.
EXEMPLE 4 Les utilisateurs empruntent des routes à péage avec l'ICC insérée dans l'équipement embarqué dans un
véhicule équipé OBE et franchissent les péages sans s'arrêter.
EXEMPLE 5 Les utilisateurs peuvent volontairement choisir de se séparer d'un équipement embarqué inutile.
A.4.2.5 Sites d'utilisation
Les sites où les utilisateurs peuvent utiliser la TOE sont décrits.
EXEMPLE Routes à péage le long desquelles l'équipement EFC en bord de route est installé.
A.4.2.6 Limites et exigences
Les limites et les exigences d'utilisation, telles que les nombres de TOE disponibles, sont décrites.
EXEMPLE 1 Le nombre d'équipements embarqués installés par véhicule est limité à un.

EXEMPLE 2 L'équipement embarqué est fixé (intégré) dans un véhicule.
EXEMPLE 3 L'équipement embarqué peut être utilisé à tout moment de la journée aussi longtemps que les voies EFC
sont ouvertes à l'exploitation.
A.4.3 Contrôle physique
Le contrôle physique associé au fonctionnement de la TOE est décrit.
A.4.3.1 Sites d'installation et contrôle
Les sites d'installation et le contrôle physique de la TOE sont décrits.
EXEMPLE L'équipement embarqué est fixé (intégré) dans un véhicule.
A.4.3.2 Unité utilisateur
Pour l'utilisation de la TOE, les exigences de contrôle physique sont décrites pour l'ICC utilisée à des fins de
paiement et que les utilisateurs possèdent.
EXEMPLE Les utilisateurs sont responsables de leur ICC.
A.4.4 Exigences relatives au personnel
Les exigences relatives au personnel sont décrites en ce qui concerne la responsabilité du fonctionnement de
la TOE et la confiance dans ce fonctionnement. En outre, les exigences relatives aux utilisations potentielles,
aux motivations, aux méthodes et à l'expertise des attaques sont établies.
a) Agents liés à la TOE
Les aspects suivants concernant les fabricants, les exploitants et les utilisateurs de la TOE sont indiqués.
1) Type
2) Rôle
3) Autorisation
4) Dépendance
5) Risque d'utilisation illicite
6) Expertise
7) Piste
EXEMPLE 1
Exigences relatives au personnel:
Type: Fabricant d'équipement embarq
...