SIST EN ISO 15118-20:2022/A1:2026

SLOVENSKI STANDARD
01-oktober-2026
Cestna vozila - Komunikacijski vmesnik med vozilom in omrežjem - 20. del:
Zahteve za omrežno in aplikacijsko plast druge generacije - Dopolnilo A1 (ISO
15118-20:2022/Amd 1:2026)
Road vehicles - Vehicle to grid communication interface - Part 20: 2nd generation
network layer and application layer requirements - Amendment 1: AC DER service, MCS
service, and improved security concept (ISO 15118-20:2022/Amd 1:2026)
Straßenfahrzeuge - Kommunikationsschnittstelle zwischen Fahrzeug und Ladestation -
Teil 20: Anforderungen der 2. Generation an das Netzwerk- und Anwendungsprotokoll -
Ergänzung 1 (ISO 15118-20:2022/Amd 1:2026)
Véhicules routiers - Interface de communication entre véhicule et réseau électrique -
Partie 20: Exigences des couches réseau et application de 2ème génération -
Amendement 1: Titre manque (ISO 15118-20:2022/Amd 1:2026)
Ta slovenski standard je istoveten z: EN ISO 15118-20:2022/A1:2026
ICS:
35.100.05 Večslojne uporabniške Multilayer applications
rešitve
43.040.15 Avtomobilska informatika. Car informatics. On board
Vgrajeni računalniški sistemi computer systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN ISO 15118-
EUROPEAN STANDARD
20:2022/A1
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2026
ICS 43.120
English Version
Road vehicles - Vehicle to grid communication interface -
Part 20: 2nd generation network layer and application
layer requirements - Amendment 1: AC DER service, MCS
service, and improved security concept (ISO 15118-
20:2022/Amd 1:2026)
Véhicules routiers - Interface de communication entre Straßenfahrzeuge - Kommunikationsschnittstelle
véhicule et réseau électrique - Partie 20: Exigences des zwischen Fahrzeug und Ladestation - Teil 20:
couches réseau et application de 2ème génération - Anforderungen der 2. Generation an das Netzwerk-
Amendement 1: Service RED en CA, service MCS et und Anwendungsprotokoll - Ergänzung 1 (ISO 15118-
concept de sécurité amélioré (ISO 15118- 20:2022/Amd 1:2026)
20:2022/Amd 1:2026)
This amendment A1 modifies the European Standard EN ISO 15118-20:2022; it was approved by CEN on 17 May 2026.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for inclusion of
this amendment into the relevant 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
member.
This amendment exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.

CEN members are the national standards bodies 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.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN ISO 15118-20:2022/A1:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3

European foreword
This document (EN ISO 15118-20:2022/A1:2026) has been prepared by Technical Committee
ISO/TC 22 "Road vehicles" in collaboration with Technical Committee CEN/TC 301 “Road vehicles” 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 shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
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 website.
According to the CEN-CENELEC Internal Regulations, the national standards organizations 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.
Endorsement notice
The text of ISO 15118-20:2022/Amd 1:2026 has been approved by CEN as EN ISO 15118-
20:2022/A1:2026 without any modification.

International
Standard
ISO 15118-20
First edition
Road vehicles — Vehicle to grid
2022-04
communication interface —
AMENDMENT 1
Part 20:
2026-07
2nd generation network layer and
application layer requirements
AMENDMENT 1: AC DER service, MCS
service, and improved security concept
Véhicules routiers — Interface de communication entre véhicule
et réseau électrique —
Partie 20: Exigences des couches réseau et application de 2ème
génération
AMENDEMENT 1: Service RED en CA, service MCS et concept de
sécurité amélioré
Reference number
ISO 15118-20:2022/Amd.1:2026(en) © ISO 2026

ISO 15118-20:2022/Amd.1:2026(en)
© 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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
ISO 15118-20:2022/Amd.1:2026(en)
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 jointly by Technical Committee ISO/TC 22, Road vehicles, Subcommittee
SC 31, Data communication, Technical Committee IEC/TC 69, Electrical power/energy transfer systems for
electrically propelled road vehicles and industrial trucks, in collaboration with the European Committee for
Standardization (CEN) Technical Committee CEN/TC 301, Road vehicles, in accordance with the Agreement
on technical cooperation between ISO and CEN (Vienna Agreement).
A list of all parts in the ISO 15118 series can be found on the ISO website.
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.

iii
ISO 15118-20:2022/Amd.1:2026(en)
Road vehicles — Vehicle to grid communication interface —
Part 20:
2nd generation network layer and application layer
requirements
AMENDMENT 1: AC DER service, MCS service, and improved
security concept
Clause 2, Normative references
Add the following references at the end of the clause:
ISO 15118-10:2025, Road vehicles — Vehicle to grid communication interface — Part 10: Physical layer and data
link layer requirements for single-pair Ethernet
IEC 61851-23-3:2025, Electric vehicle conductive charging system - Part 23-3: DC electric vehicle supply
equipment for Megawatt charging systems

Clause 3, Terms and definitions
Add the following terms and definitions at the end of the clause:

3.72
charge enable state
CE state
state according to the charge enable function defined in IEC 61851-23-3
3.73
megawatt charging system
MCS
charging system according to IEC 61851-23-3
3.74
area EPS
area electric power system as defined in IEEE 1547
3.75
cease to energize
cessation of active power delivery under steady-state and transient conditions and limitation of reactive
power exchange
Note 1 to entry: After the cessation is over, the EV is allowed to return immediately into service without following the
enter service rules.
ISO 15118-20:2022/Amd.1:2026(en)
3.76
distributed energy resource
DER
source of electric power that is not directly connected to a bulk power system
EXAMPLE Generators and energy storage technologies capable of exporting active power to the electrical grid.
Note 1 to entry: An interconnection system or a supplemental DER device that is necessary for compliance with this
document is part of a DER.
3.77
enter service
set of parameters that defines how to start energizing or re-energizing the electric power system
Note 1 to entry: If voltage and frequency values are not within the desired range, the distributed energy resource (DER)
(3.76) will not be allowed to start injecting power to the grid/electric power system.
3.78
frequency droop curve
parameterized curve of the frequency-watt function
Note 1 to entry: The parameters include a frequency dB (dead band) and a unitless factor k which defines the rate
of power output change due to the frequency change. This operation limits active power generation or consumption
when the line frequency deviates from nominal by a specified amount.
3.79
level 1 charging
charging with a maximum power between 1 kW and 1,8 kW, via a standard 120 Vrms AC single phase outlet
Note 1 to entry: This power limit is only applicable in the United States of America.
3.80
level 2 charging
charging with a maximum power between 3 kW and 22 kW, via a dedicated AC charger
Note 1 to entry: In the United States of America the voltage supplied is typically 240 Vrms AC whereas in Europe is
230 Vrms AC.
3.81
may trip region
region of voltage or frequency within which the EV is allowed to cease to energize (3.75) and to trip (3.88)
the connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.82
momentary cessation region
region of voltage or frequency within which the EV will temporarily cease to energize (3.75) (inject power
to) an electric power system in response to a disturbance of the applicable voltages or the system frequency
Note 1 to entry: When entering this region, the EV will retain the capability of immediate restoration of the output of
operation when the applicable voltages and the system frequency return to within the defined ranges.
Note 2 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.83
must trip region
region of voltage or frequency within which the EV must cease to energize (3.75) and must trip (3.88) the
connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.

ISO 15118-20:2022/Amd.1:2026(en)
3.84
open loop response time
time to ramp up to 90 % of the new target in response to the step change of the control input signal
3.85
permit service
setting that indicates whether a distributed energy resource (DER) (3.76) is allowed to enter or remain in
service
3.86
return to service
enter service (3.77) following recovery from a trip (3.88)
3.87
ride-through
ability to withstand voltage or frequency disturbances inside defined limits and to continue operating as
specified
3.88
trip
inhibition of immediate return to service (3.86)
Note 1 to entry: Once the distributed energy resource (DER) (3.76) has permission to come back to service, it shall
follow the enter service (3.77) rules.

Clause 4, Abbreviated terms
Add the following abbreviations to the list:

CE charge enable
CL charge loop
DER distributed energy resource (in the context of AC DER)
MCS megawatt charging system
Modify the existing abbreviation DER as follows:
DER distinguished encoding rules (in the context of X.509v3 certificates)

5.2
Replace the entire subclause including its title with the following subclause:
5.2  Requirement and provision structure
This document uses the requirement structure defined here. Also, important provisions that are no
requirements (“shall”), but permissions (“may”) or recommendations (“should”) use the structure defined
here. A unique number identifies each individual requirement or provision defined in this document.
Systematic and ordered requirement (provision) structure enables readers to find the target requirement
(provision) number easily.
The following format is applied for newly added and updated requirements or provisions:

ISO 15118-20:2022/Amd.1:2026(en)
"[V2G20-"XXXX"]" "requirement/provision text", where:
— "V2G20" represents this document;
— “XXXX” represents the unique requirement or provision number consisting of four digits starting from
1 000;
— "requirement/provision text" includes the actual text of the requirement or provision.
— For purely AC DER or MCS specific requirements, an identifier is added as follows: "[V2G20-"XXXX"]
[DER]" or "[V2G20-"XXXX"] [MCS]”, respectively.
EXAMPLE 1 [V2G20-0000]  This shall/may/should be an example requirement introduced in this document.
The following format is applied for requirements taken over from ISO 15118-2 Ed.1:
[“V2G20”-"YYY"] "requirement/provision text", where:
— "V2G20" represents this document;
— “YYY” represents the unique requirement or provision number as already defined in ISO 15118-2 Ed.1;
— "requirement/provision text" is the same text as specified in ISO 15118-2 Ed.1.
EXAMPLE 2 [V2G20-000]  This shall/may/should be an example requirement originally defined in ISO 15118-2
Ed.1.
Clause 6
Replace Figure 2 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 2 — Vehicle to grid communication document overview

7.3.2
Replace Table 2 with this table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. digital signature, non-repudia-
Key usage
tion, key encipherment, …)
Further specification of key usage using OIDs, e.g.:
— server authentication (1.3.6.1.5.5.7.3.1)

— client authentication (1.3.6.1.5.5.7.3.2)
NOTE Sometimes the following values are encoded here:
— Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended key usage
— Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for server gated crypto and indicates that the
server can also use strong cryptography for the connection
with the client’s browser. This extension was used at the time
of strong crypto export control to enable financial web site to
provide appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP. Refer to IETF RFC 6960 as updated by
IETF RFC 8954 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is a root certificate or a sub-CA certificate.
Subject information Additional information about the subject

Replace NOTE 8 with:
NOTE 8 Additionally, key length of 456 bits is used with certain curves in the application of this document. If a V2G
entity can manage and utilize 521 bit keys, it can be capable of managing and utilizing 456 bit keys as well.

Add the following new paragraph below NOTE 14 to requirement [V2G20-1234]:
In this document, the size of certificate is less than or equal to 1 600 bytes. This limit considers resource
constraints in embedded systems. To reduce the size of certificates, things to consider are for example to be
cautious when adding long URLs, 4-byte characters in distinguished names, or multiple certificate policies
as these can increase the size of the certificate significantly. It can be necessary to use only one, either
CRLDistributionPoints or AuthorityInfoAccess, and not both, if including both makes the certificate larger
than 1 600 bytes.
Replace the requirement [V2G20-1004] with the following new requirements and note:
[V2G20-3000] The relying parties shall ensure that the certificates are valid exclusively within the
validity of their issuer's certificate.
NOTE 15 The CA is expected to only issue certificates that are valid exclusively within the validity of its own
certificate.
[V2G20-3001] While validating certificates, EVCC and SECC shall ensure that [V2G20-3000] is fulfilled.
Replace first bullet point in NOTE 20 (old numbering) with:
NOTE 20  […].
ISO 15118-20:2022/Amd.1:2026(en)
a) The content of the leaf certificate has not been altered after issue. This means it is possible to check and
confirm the signature up to the trust anchor level and thus the integrity of the signed content.
— […].
Renumber old NOTE 15 and following notes, starting with number 16.

7.3.2.1
Replace the requirement [V2G20-2327] and NOTE 3 with:
[V2G20-3002] The OCSP signer certificate used to sign the OCSP response for the SECC certificate sta-
tus shall be generated using a certificate chain that either uses the same V2G root CA
certificate as the trust anchor as the SECC certificate whose status is being checked or
uses one of the V2G root CA certificates, as the trust anchor, whose DN was included by
the EVCC in the “certificate_authorities” extension sent by the EVCC in the “ClientHello”
message. Refer to Figure 5 for a pictorial representation. Refer to Annex H for further
details. Refer to H.1.6 for examples of certificate structure. Refer to Annex B for details
of the certificate profile.
NOTE 3 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
SECC certificate (or the sub-CA certificate(s) in the SECC certificate chain) chains up to the same V2G root CA that
signs the SECC certificate chain that the SECC is transmitting to the EVCC for this particular TLS handshake. This is,
however, out of scope of this document.
Replace the requirements [V2G20-2330] and [V2G20-2332] with the following new requirements,
respectively:
[V2G20-3003] The OCSP signer certificate used to sign the OCSP response for the contract certificate
status shall be generated using a certificate chain that uses either the same eMSP root
CA certificate or the same V2G root CA certificate as the trust anchor of the contract
certificate whose status is being checked. Refer to Figure 6 for a pictorial representation.
Refer to Annex H for further details. Refer to H.1.6 for examples of certificate structure.
Refer to Annex B for details of the certificate profile.
[V2G20-3004] The OCSP signer certificate used to sign the OCSP response for the vehicle certificate
status shall be generated using a certificate chain that uses either the same OEM root CA
certificate or the same V2G root CA certificate as the trust anchor of the vehicle certificate
whose status is being checked. Refer to Figure 7 for a pictorial representation. Refer to
Annex H for further details. Refer to H.1.6 for examples of certificate structure. Refer to
Annex B for details of the certificate profile.
Replace NOTE 10 with:
NOTE 10 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
vehicle certificate (or the sub-CA certificate(s) in the vehicle certificate chain) chains up to the same V2G root CA that
signs the vehicle certificate chain whose status is being checked. This is, however, out of scope of this document.
Replace the requirement [V2G20-2334] and NOTE 12 with:
[V2G20-3005] The OCSP signer certificate used to sign the OCSP response for the OEM provisioning
certificate status shall be generated using a certificate chain that uses either the same
OEM root CA certificate or the same V2G root CA certificate as the trust anchor as the
OEM provisioning certificate whose status is being checked. Refer to Figure 7 for a pic-
torial representation. Refer to Annex H for further details. Refer to H.1.6 for examples of
certificate structure. Refer to Annex B for details of the certificate profile.

ISO 15118-20:2022/Amd.1:2026(en)
NOTE 12 This document does not mandate usage of a particular V2G root CA. In case multiple V2G root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
OEM provisioning certificate (or the sub-CA certificate(s) in the OEM provisioning certificate chain) chains up to the
same V2G root CA that signs the OEM provisioning certificate chain whose status is being checked. This is, however,
out of scope of this document.

7.3.4
Delete the following requirements: [V2G20-1235] and [V2G20-2646].

7.4
Add the following new requirements and note at the end of this subclause (below Figure 9):
[V2G20-3006] [MCS] In case of an MCS and MCS_BPT: If the EVCC sent the message SessionStopReq
with parameter ChargingSession equal to "Pause" it shall pause the Data-Link
(D-LINK_PAUSE.request()) after receiving the message SessionStopRes with Re-
sponseCode set to "OK" and follow the sleep and wake-up requirements defined in
ISO 15118-10:2025, 7.6.
[V2G20-3007] [MCS] In case of an MCS and MCS_BPT: If the SECC received the message SessionStopReq
with parameter ChargingSession equal to "Pause" it shall pause the Data-Link
(D-LINK_PAUSE.request()) after sending the message SessionStopRes with Re-
sponseCode set to "OK" and follow the sleep and wake-up requirements defined in
ISO 15118-10:2025, 7.6.
NOTE 3 Requirements [V2G20-1227] and [V2G20-1777] are not applicable for an MCS and MCS_BPT.

7.5
Replace second sentence of the first paragraph with:
ISO 15118-3, ISO 15118-8, and ISO 15118-10 define additional details on data link layer to be covered.
Add the following new requirement at the end of this subclause:
[V2G20-3008] [MCS] If a V2G entity communicates by 10BASE-T1S, the V2G entity shall comply with
ISO 15118-10.
7.5.1.2
Replace Figure 10 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Key
1 App layer communication protocol
2 IEEE 802.1X communication protocol
Figure 10 — IEEE 802.1X example with backend authentication for WPT
7.7.3.3
Add the following new NOTE after NOTE 8 below [V2G20-2368]:
NOTE 9 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280:2008, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
must be the same between the Issuer field and the subject field.
Replace the requirements [V2G20-2369], [V2G20-2370] with the following new requirements, respectively:
[V2G20-3373] If no V2G root CA certificate(s) and PE private root CA certificate(s) are available in the
EVCC, "certificate_authorities" extension shall not be present in the "ClientHello" message.
[V2G20-3374] While the EVCC is in CPM4PE, it shall not include "certificate_authorities" extension in
the "ClientHello" message regardless if the EVCC has any V2G root CA certificate(s) and
PE private root CA certificate(s) or not. Refer to H.2.2.3 for details of CPM4PE.

Delete the following requirement: [V2G20-2371]

Replace the requirements [V2G20-2378], [V2G20-2379] with the following new requirements, respectively:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3375] If the EVCC did not provide any indication of the available roots according to [V2G20-
3373], a public SECC shall send in the "ServerHello" message its own certificate chain
(SECC certificate chain) including any necessary cross certificates up to a root (excluding
the root certificate itself) of its own choosing.
[V2G20-3376] If the EVCC provides a list of the available roots according to [V2G20-1006], the public
SECC shall follow IETF RFC 5280:2008, 7.1, as updated by IETF RFC 6818, IETF RFC 8398
and IETF RFC 8399, to utilize the received "DistinguishedNames" (see [V2G20-1006]) to
choose an SECC certificate chain originating from one of the received "Distinguished-
Names" and provide it to the EVCC in "ServerHello" message as defined in IETF RFC 8446.

Replace the requirements [V2G20-2383], [V2G20-2384] with the following new requirements, respectively:
[V2G20-3377] If the EVCC provides a list of the available roots according to [V2G20-1006], the private
SECC shall follow IETF RFC 5280:2008, 7.1 as updated by IETF RFC 6818, IETF RFC 8398
and IETF RFC 8399, to utilize the received "DistinguishedNames" (see [V2G20-1006]) to
choose a PE certificate chain originating from one of the received "DistinguishedNames"
and provide it to the EVCC in "ServerHello" message as defined in IETF RFC 8446.
[V2G20-3378] If the EVCC did not provide any indication of the available roots according to [V2G20-
3373], a private SECC not in CPM4PE shall send in the "ServerHello" message its own
certificate chain (PE certificate chain) including any necessary cross-certificates up to a
root (excluding the root certificate itself) of its own choosing.

Replace the requirement [V2G20-2388] with:
[V2G20-3379] Since the EVCC used the "status_request" extension to request OCSP response for the
certificate chain sent by the public SECC, it shall include an OCSP response for each cer-
tificate in the certificate chain sent by the public SECC in the "Certificate" message. Refer
to IETF RFC 6960 (as updated by IETF RFC 8954) and IETF RFC 8446 for further details.

Replace the requirement [V2G20-2391] with:
[V2G20-3380] Since the EVCC used the "status_request" extension to request OCSP response for the
certificate chain sent by private SECC, if the private SECC supports PnC, it shall include
an OCSP response for each certificate in the certificate chain sent by the private SECC in
the "Certificate" message. Refer to IETF RFC 6960 (as updated by IETF RFC 8954) and
IETF RFC 8446 for further adetails.

Replace NOTE 21 below [V2G20-1008] with:
NOTE 21 As defined in IETF RFC 6960 (as updated by IETF RFC 8954), an OCSP responder can either be the sub-
CA itself, or it can be an entity which is directly signed by the corresponding sub-CA/root CA using a key pair with a
special extended key usage flag in the certificate.
Replace the requirements [V2G20-2404], [V2G20-2405] with the following new requirements, respectively:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3381] If no V2G root CA certificate and OEM root CA certificate is/are available in the public
SECC or private SECC not in CPM4PE, the "certificate_authorities" extension shall not
be present in the "CertificateRequest" message.
[V2G20-3382] A private SECC in CPM4PE shall send not include "certificate_authorities" extension in
the "CertificateRequest" message. Refer to H.2.2.3 for details of CPM4PE.

Add the following new NOTE after NOTE 29 below [V2G20-2403]:
NOTE 30 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280:2008, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
must be the same between the Issuer field and the Subject field.
Replace the requirements [V2G20-2426], [V2G20-2427], [V2G20-2428] with the following new requirements,
respectively:
[V2G20-3383] If the SECC provides a list of the available roots according to [V2G20-2401] or [V2G20-
2402], the EVCC shall follow IETF RFC 5280:2008, 7.1, as updated by IETF RFC 6818,
IETF RFC 8398 and IETF RFC 8399, to utilize the received "DistinguishedNames" (see
[V2G20-2401]) to choose a vehicle certificate chain originating from one of the received
"DistinguishedNames" and provide it to the SECC in "Certificate" message as defined in
IETF RFC 8446.
[V2G20-3384] If the public SECC did not provide any indication of the available roots according to
[V2G20-3381], the EVCC shall send a "Certificate" message containing its own certifi-
cate chain (vehicle certificate chain) including any necessary cross-certificates up to the
corresponding root (excluding the root certificate itself) of its own choosing.
[V2G20-3385] If the private SECC did not provide any indication of the available roots according to
[V2G20-3381], an EVCC not in CPM4PE shall send a "Certificate" message containing its
own certificate chain (vehicle certificate chain) including any necessary cross-certificates
up to the corresponding root (excluding the root certificate itself) of its own choosing.

Renumber all NOTEs starting from the original NOTE 9.

7.7.3.10
Add the following new requirements and note at the end of the subclause:
[V2G20-3009] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for an EVCC
using an MCS.
[V2G20-3010] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for an SECC
using an MCS.
NOTE 10 Requirements [V2G20-2054] through [V2G20-2070] are not applicable for an MCS and MCS_BPT.

7.8.3.1, Table 14
In Table 14: replace the table row with payload type value 0x8007 - 0x8100 with the following new rows:

ISO 15118-20:2022/Amd.1:2026(en)
Payload type value Payload type identifier Explanation
0x8007 - 0x8009 Not applicable Reserved for future use
EXI encoded V2G messages of this document
which are exchanged as part of the main
stream of the communication flow and are
specific to AC DER IEC. This set of messages
0x8010 AC-DER-IEC-PayloadID
is using the XSD schema with the namespace
"urn: iso: std: iso: 15118: -20: AC -DER -IEC".
Refer to Annex L for the definition of this
message set.
EXI encoded V2G messages of this document
which are exchanged as part of the main
stream of the communication flow and are
specific to AC DER SAE. This set of messages
0x8011 AC-DER-SAE-PayloadID
is using the XSD schema with the namespace
"urn: iso: std: iso: 15118: -20: AC -DER -SAE".
Refer to Annex M for the definition of this
message set.
0x8012 - 0x8100 Not applicable Reserved for future use

7.9.1.3
Add the following new requirement below requirement [V2G20-5125]:
[V2G20-3011] [DER] The XML schema with the namespace "urn:i so:s td:i so:1 5118:- 20:A C- DER- IEC" shall be
used for encoding and decoding EXI streams sent or received with AC-DER-IEC-Pay-
loadID and defined in Annex L.
[V2G20-3386] [DER] The AC-DER-IEC-PayloadID shall only be used for the AC DER IEC service.
[V2G20-3161] [DER] The XML schema with the namespace "urn:i so:s td:i so:1 5118:- 20:A C- DER- SAE" shall be
used for encoding and decoding EXI streams sent or received with AC-DER-SAE-Pay-
loadID and defined in Annex M.
[V2G20-3387] [DER] The AC-DER-SAE-PayloadID shall only be used for the AC DER SAE service.

7.9.2.4.2
Add the following requirement and note below the requirement [V2G20-2476] and renumber all NOTEs
starting from the original NOTE 2:
[V2G20-3012] NIST FIPS PUB 202 defines SHAKE256 as an extendable-output function (XOF). Hence the
output length of SHAKE256 (referred as “d” by NIST FIPS PUB 202) can be configured to
any necessary value as needed by the application. For signatures as defined by [V2G20-
2476], the output length “d” of SHAKE256 shall be 114 bytes (912 bits).
NOTE 2 IETF RFC 8032:2017, 5.2 specifies using 114 bytes (912 bits) as the output length of SHAKE256. This
requirement keeps the SHAKE256 output length consistent between the IETF RFC 8032 and this document.

7.9.2.4.3
Replace Table 17 with this table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 17 — Overview of applied XML based signatures
Verifying
XML message Protected fields Signing entity (sender) entity (re-
ceiver)
EVCC; signed with private key
associated with the contract
AuthorizationReq PnC_AReqAuthorizationMode SECC
certificate provided within PnC_
AReqAuthorizationMode
EVCC; signed with private key
associated with OEM provision secondary
CertificateInstallationReq OEMProvisioningCertificateChain
certificate (transmitted in mes- actor
sage body element)
secondary actor; signed with the
private key associated with the
CertificateInstallationRes SignedInstallationData EVCC
leaf certificate of the certificate
provisioning service
EVCC; signed with private key
associated with the contract cer-
MeteringConfirmationReq SignedMeteringData SECC
tificate (certificate is transmitted
in AuthorizationReq message)
secondary actor; signed with the
AbsolutePriceSchedule + PriceLev-
ScheduleExchangeRes private key associated with the EVCC
elSchedule
eMSP Sub-CA2 certificate
Replace NOTE 1 below the requirement [V2G20-2479] with:
NOTE 1 The key in the “value” field of “generalName” parameter of “accessLocation” field of “accessDescription
(x448PublicKey)” parameter in the extension “subjectInfoAccess” is encoded for use only in ECDH algorithm. It is not
possible to use it to verify signatures using the Ed448 algorithm.
7.9.2.5.2.1
Replace the requirement [V2G20-2492] with:
[V2G20-3388] Additional authenticated data (AAD) shall be calculated by concatenating the PCID received/
used in the CertificateInstallationReq message with capital letters and digits without
separators (18 bytes), followed by the SKI value of the contract certificate included in
the CertificateInstallationRes encoded as a hexa-decimal string with capital letters and
digits according to IETF RFC 5234 (16 bytes for method 2 and 40 bytes for method 1).

7.9.2.5.2.2.1
Replace the name of the subclause with:
Common requirements for encryption of 521-bit and 456-bit contract certificate private keys for EVCC
without TPM 2.0
Replace the requirement [V2G20-2495] with:
[V2G20-3389] When using 456-bit ephemeral public key in requirement [V2G20-2497], the sender shall
not include any extra filler/padding bytes to reach DHPublicKey size of 133 bytes.

7.9.2.5.2.2.3
Replace the name of the subclause with:

ISO 15118-20:2022/Amd.1:2026(en)
Encryption of 456 bit contract certificate private key for EVCC without TPM 2.0

Replace the requirement [V2G20-2500] and NOTE 2 with:
[V2G20-3390] The 456-bit private key corresponding to the contract certificate shall be encrypted by
the sender (the SA (eMSP)) using the same session key used to encrypt the 521-bit private
key in [V2G20-2497]. The sender shall apply the algorithm AES-GCM-256 according to
NIST Special Publication 800-38D for this encryption. The initialization vector (IV) for
this encryption shall be randomly generated before encryption and shall have a length
of 88 bits with minimum entropy as defined by the implementer(s). The AAD for this
encryption shall be calculated according to [V2G20-2492]. The encryption shall produce
the 456-bit long ciphertext (encrypted private key) and 128-bit long authentication tag
("tag" for short).
NOTE 2 No explicit padding is required here since the 456-bit private key is byte aligned.
Replace Figure 19 with this figure:
Figure 19 — 456-bit contract certificate private key encryption
Replace the text above [V2G20-2502] with the following text:
The output of AES-GCM-256 encryption will be the ciphertext and the authentication tag. The 456-bit
ciphertext is the encrypted contract certificate private key.

Replace the requirement [V2G20-2502] with:
[V2G20-3391] The IV (as defined by [V2G20-2497]) shall be transmitted in the 11 most significant
bytes of the X448_EncryptedPrivateKey field. The ciphertext (encrypted private key)
of 57 bytes shall be written after the IV in the X448_EncryptedPrivateKey field. The
tag (as defined by [V2G20-2494]) shall make up the 16 least significant bytes of the
X448_EncryptedPrivateKey field. Figure 20 provides this structure in pictorial format.
Replace Figure 20 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 20 — X448_EncryptedPrivateKey

7.9.2.5.2.3
Replace the name of the subclause with:
Common requirements for decryption of 521-bit and 456-bit contract certificate private keys for EVCC
without TPM 2.0
7.9.2.5.2.3.1
Replace the requirement [V2G20-2504] with:
[V2G20-3392] If the decryption of either the 521-bit private key or 456-bit private key or both fails, the
receiver shall reject the CertificateInstallationRes message as invalid.

7.9.2.5.2.3.3
Replace the name of the subclause with:
Decryption of 456-bit contract certificate private key for EVCC without TPM 2.0

Replace the requirement [V2G20-2508] with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3393] Upon reception of X448_EncryptedPrivateKey, the receiver (EVCC) shall decrypt the
contract certificate private key using the same session key used to decrypt the 521-bit
private key in [V2G20-2505] and applying the algorithm AES-GCM-256 according to NIST
Special Publication 800-38D. The IV shall be read from the 11 most significant bytes of
the X448_EncryptedPrivateKey field. The ciphertext (encrypted private key) shall be
read from the 57 bytes after the IV in the X448_EncryptedPrivateKey field. The AAD
for this decryption shall be calculated before decryption following [V2G20-2492]. The
authentication tag shall be read from the 16 least significant bytes of the X448_Encrypt-
edPrivateKey field.
Replace Figure 23 with this figure:
Figure 23 — 456-bit contract certificate private key decryption overview

Replace Figure 24 with this figure:
Figure 24 — 456-bit contract certificate private key decryption
Replace the requirement [V2G20-2509] and [V2G20-2510] with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3394] The EVCC shall use the 456-bit decrypted data as the 456-bit contract certificate private key.
[V2G20-3395] Upon receipt of a contract certificate, the EVCC shall verify that the 456-bit private key
received with the certificate is a valid 456-bit private key for that certificate:
— its value shall be strictly smaller than the order of the base point for x448 curve;
— multiplication of the base point with this value shall generate a key matchingthe
456-bit public key of the contract certificate.
7.9.2.5.3, Figure 25
Replace Figure 25 with this figure:
Figure 25 — Process for CertificateInstallationRes for EVCC equipped with TPM 2.0

7.9.2.5.3.3, Figure 26
Replace Figure 26 with this figure:

ISO 15118-20:2022/Amd.1:2026(en)
Figure 26 — Contract key encryption for direct import into EVCC’s TPM 2.0 (for (elliptic curve) EC
P-521/secp521r1)
Replace NOTE 5 below Figure 26 with the following note:
NOTE 5 Key encryption process and structures illustrated in Figure 26 are valid for both currently specified
(elliptic curve) ECs.
Add the following note below Figure 26:
NOTE 7 As the authValue of the contract key is part of the encrypted contract private key, it is known only to
the SA and not to a TPM's local controller in the EVCC. It is thus recommended to provision the contract key with a
policyDigest and use a policy session to authorize signing with this key. This p
...