ISO 15118-20:2022/Amd 1:2026

• Status: Published
• Publication Date: 12-Jul-2026
• ICS: 43.120 - Electric road vehicles
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/JWG 1 - Joint ISO/TC 22/SC 31 - IEC/TC 69 WG: Vehicle to grid communication interface (V2G CI)
• Current Stage: 6060 - International Standard published
• Start Date: 13-Jul-2026
• Due Date: 02-Oct-2026
• Completion Date: 13-Jul-2026

• Consolidates: EN ISO 15118-20:2022/FprA1 - 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/FDAM 1:2026)
• Effective Date: 12-Feb-2026
• Consolidates: ISO 24411:2022 - Space systems — Micro-vibration testing
• Effective Date: 14-Oct-2023
• Amends: ISO 15118-20:2022 - Road vehicles — Vehicle to grid communication interface — Part 20: 2nd generation network layer and application layer requirements
• Effective Date: 28-Oct-2023

Overview

ISO 15118-20:2022/Amd 1:2026 is an amendment to the ISO 15118 series, specifically addressing the vehicle to grid (V2G) communication interface for road vehicles. This amendment introduces new services and enhances security concepts for 2nd generation network and application layers. Key inclusions are the AC Distributed Energy Resource (DER) service, the Megawatt Charging System (MCS) service, and upgraded security requirements, supporting the evolution of electric vehicle (EV) charging infrastructure.

ISO 15118-20:2022/Amd 1:2026 is an internationally recognized standard developed by ISO, with participation from IEC and CEN, ensuring global applicability and interoperability within electric mobility ecosystems.

Key Topics

• AC DER Service: Adds support for distributed energy resources integrated with alternating current (AC) charging, allowing EVs to interact with the grid, either by consuming or supplying energy.
• MCS Service: Facilitates high-power, rapid charging capabilities through Megawatt Charging Systems, addressing the growing demand for fast charging, especially for heavy-duty vehicles and commercial fleets.
• Improved Security Concepts: Enhances certificate management, authentication, and cryptographic requirements to strengthen communication security between EVs and charging infrastructure.
• Requirement Numbering Structure: Establishes a systematic and traceable method for documenting and referencing technical requirements and provisions.
• Expanded Terminology and Definitions: Includes updated terms such as "charge enable state," "megawatt charging system," "frequency droop curve," and different levels of charging to clarify new capabilities.

Applications

ISO 15118-20:2022/Amd 1:2026 offers practical value by supporting the expanding role of electric vehicles as dynamic grid components. Applications include:

• Bidirectional Charging (V2G, V2X): Enables EVs to supply stored energy back to the grid (vehicle-to-grid), participate as distributed energy resources, and assist with grid stability during peak periods.
• Public and Commercial EV Charging: Supports AC charging stations and megawatt-level charging for varied user needs - from private passenger vehicles to fleet and heavy-duty operations.
• Cybersecurity Compliance: Adopts stricter security practices for certificate life cycle management, encryption, and online certificate status protocols (OCSP), helping implementers meet regulatory and industry best-practice expectations.
• Cross-platform Interoperability: Facilitates consistent integration across different manufacturers and service providers, ensuring seamless EV charging experiences globally.
• Future-proofing Infrastructure: With support for high-power charging and DER capabilities, charging stations and vehicles are ready for the next generation of e-mobility services.

Related Standards

To ensure full compliance and interoperability, organizations adopting ISO 15118-20:2022/Amd 1:2026 should also reference:

• ISO 15118-10:2025 - Physical and data link layer requirements for single-pair Ethernet in V2G communications.
• IEC 61851-23-3:2025 - DC electric vehicle supply equipment for megawatt charging systems.
• ISO 15118-3, ISO 15118-8, ISO 15118-2 - Related parts within the ISO 15118 family, covering other layers and requirements in the EV charging ecosystem.
• IETF RFC 5280, RFC 6960, RFC 8446 - Internet standards for digital certificates, online certificate status protocols, and TLS communications, relevant for security implementations.
• NIST FIPS PUB 202 - Cryptography standards applied within the improved security concept.

By aligning with these related standards, implementers support the creation of robust, secure, and interoperable EV charging solutions suitable for smart grid and energy transition initiatives.

---

Keywords: ISO 15118-20, V2G, electric vehicle charging, AC DER, MCS, megawatt charging, EV cybersecurity, charging station interoperability, distributed energy resource, vehicle to grid protocol, electric mobility standards.

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: [phone]
Email: [e-mail]
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 policy session can include for example
the command TPM2_PolicySecret whose authorization is ensured by proving knowledge of the authValue of an entity.
Choosing the storage key as the entity allows the SA to compute the policy, as it requires knowledge of the name of the
key whose public part is present in the OEM provisioning certificate extension.

Renumber all notes starting from the original NOTE 7.

7.9.2.5.3.1
Replace the requirement [V2G20-2511] with:
[V2G20-3433] The EVCC’s TPM 2.0 shall contain a storage key pair. The storage key pair in the EVCC’s
TPM shall use the storage key profile from Table 19 for the default ECC algorithm (elliptic
curve P-521/secp521, see [V2G20-2674]) or the storage key profile from Table 19 for the
alternative ECC algorithm (Curve448, see [V2G20-2319]).

Replace Table 19 with the following new table:

ISO 15118-20:2022/Amd.1:2026(en)
Table 19 — TPM key profiles for (elliptic curve) EC P-521/secp521r1 and Curve448 (public area)
Parameter Content for secp521r1
Storage key OEM provisioning key Contract key
type TPM2_ALG_ECC TPM2_ALG_ECC TPM2_ALG_ECC
nameAlg TPM2_ALG_SHA512 TPM2_ALG_SHA512 TPM2_ALG_SHA512
fixedTPM = 1 fixedTPM = 1 fixedTPM = 0
stClear = 0 stClear = 0 stClear = 0
fixedParent = 1 fixedParent = 1 fixedParent = 0
sensitiveDataOrigin = 1 sensitiveDataOrigin = 1 sensitiveDataOrigin = 1
userWithAuth = 1 userWithAuth = 0 (1 if no userWithAuth = 0 (1 if no
policy) policy)
adminWithPolicy = 0
objectAttributes adminWithPolicy = 1 (0 if no adminWithPolicy = 1 (0 if no
noDA = 0
policy) policy)
encryptedDuplication = 0
noDA = 0 noDA = 0
restricted = 1
encryptedDuplication = 0 encryptedDuplication = 0
decrypt = 1
restricted = 0 restricted = 0
sign = 0
decrypt = 0 decrypt = 0
sign = 1 sign = 1
authPolicy
size 0 64 (0 if no policy) 64 (0 if no policy)
buffer NULL OEM chosen policy digest OEM chosen policy digest
parameters
symmetric.algorithm TPM2_ALG_AES TPM2_ALG_NULL TPM2_ALG_NULL
symmetric.keyBits 256 NULL NULL
symmetric.mode TPM2_ALG_CFB NULL NULL
symmetric.details NULL NULL NULL
scheme.scheme TPM2_ALG_NULL TPM2_ALG_NULL TPM2_ALG_NULL
scheme.details NULL NULL NULL
curveID TPM2_ECC_NIST_P521 TPM2_ECC_NIST_P521 TPM2_ECC_NIST_P521
kdf.scheme TPM2_ALG_NULL TPM2_ALG_NULL TPM2_ALG_NULL
kdf.details NULL NULL NULL
unique
x.size 0 0 66
x.buffer NULL NULL x-coordinate of the public key
y.size 0 0 66
y.buffer NULL NULL y-coordinate of the public key
Parameter Content for Curve448
Storage key OEM provisioning key Contract key
type TPM_ALG_ECC TPM_ALG_ECC TPM_ALG_ECC
nameAlg TPM_ALG_SHA512 TPM_ALG_SHA512 TPM_ALG_SHA512

ISO 15118-20:2022/Amd.1:2026(en)
TTabablele 1 199 ((ccoonnttiinnueuedd))
objectAttributes fixedTPM = 1 fixedTPM = 1 fixedTPM = 0
stClear = 0 stClear = 0 stClear = 0
fixedParent = 1 fixedParent = 1 fixedParent = 0
sensitiveDataOrigin = 1 sensitiveDataOrigin = 1 sensitiveDataOrigin = 1
userWithAuth = 1 userWithAuth = 0 (1 if no userWithAuth = 0 (1 if no
policy) policy)
adminWithPolicy = 0
adminWithPolicy = 1 (0 if no adminWithPolicy = 1 (0 if no
noDA = 0
policy) policy)
encryptedDuplication = 0
noDA = 0 noDA = 0
restricted = 1
encryptedDuplication = 0 encryptedDuplication = 0
decrypt = 1
restricted = 0 restricted = 0
sign = 0
decrypt = 0 decrypt = 0
sign = 1 sign = 1
authPolicy
size 0 64 (0 if no policy) 64 (0 if no policy)
buffer NULL OEM chosen policy digest OEM chosen policy digest
parameters
symmetric.algorithm TPM_ALG_AES TPM_ALG_NULL TPM_ALG_NULL
symmetric.keyBits 256 NULL NULL
symmetric.mode TPM_ALG_CFB NULL NULL
symmetric.details NULL NULL NULL
scheme.scheme TPM_ALG_NULL TPM_ALG_EDDSA TPM_ALG_EDDSA
scheme.details NULL NULL NULL
curveID TPM_ECC_CURVE_448 TPM_ECC_CURVE_448 TPM_ECC_CURVE_448
kdf.scheme TPM_ALG_NULL TPM_ALG_NULL TPM_ALG_NULL
kdf.details NULL NULL NULL
unique
x.size 0 0 57
x.buffer NULL NULL Public key compressed format
y.size 0 0 0
y.buffer NULL NULL NULL
Replace NOTE 4 with the following notes:
NOTE 4 Table 19 contains the TPM Key Profiles for the default ECC algorithm (elliptic curve P-521/secp521) as
defined by [V2G20-2321] and the TPM Key Profiles for the alternative ECC algorithm (Curve448) according to [V2G20-
2319]. Further ECC algorithms supported by TPM 2.0 are specified in TCG algorithm registry.
NOTE 5 Table 19 contains the TPM key profiles (TPMT_PUBLIC structure) used as input to the key creation
commands for the storage key and the OEM provisioning key and the import command for the contract key.
NOTE 6 The OEM provisioning key based on the curve TPM_ECC_CURVE_448 is not defined as a general-purpose
key because it is not possible to sign with Ed448 scheme and exchange a secret with X448 scheme using the same key.
NOTE 7 The public part of a signing key based on the curve TPM_ECC_CURVE_448 is represented in the compressed
format as detailed in IETF RFC 8032.
7.9.2.5.3.2
Replace the requirement [V2G20-2512] and NOTE 8 with:

ISO 15118-20:2022/Amd.1:2026(en)
[V2G20-3396] The OEM provisioning key pair shall be generated using the provisioning key profile from
Table 19 for the default ECC algorithm (elliptic curve P-521/secp521, see [V2G20-2674])
or using the provisioning key profile from Table 19 for the alternative ECC algorithm
(Curve448, see [V2G20-2319]).
NOTE 8 The policy digest is part of the TPM key profile (see "authPolicy") and is created using the "nameAlg"
algorithm of the key. In case of the default or the alternative ECC algorithm as defined by [V2G20-2674] and [V2G20-
2319], the EVCC's TPM policy digest uses SHA-512 and is 64 byte long (see Table 19).
7.9.2.5.3.3
Replace the requirement [V2G20-2518] and NOTE 2 with:
[V2G20-3397] In order to enable a direct import of the encrypted contract certificate private key into
the EVCC’s TPM, the contract certificate private key shall be encrypted with the TPM
storage key of the EVCC's TPM from the OEM provisioning certificate extension (in con-
trast to [V2G20-2529] and [V2G20-3013]). This encryption shall comply with ISO/IEC
11889-1:2015, 23.3.2 and only use the outer duplication wrapper. This encryption shall
use the values from Table 19 for the default ECC algorithm (elliptic curve P-521/secp521,
see [V2G20-2674]) or shall use the values from Table 19 for the alternative ECC algorithm
(Curve448, see [V2G20-2319]), whereby the contract certificate public key is inserted
into the buffers of the contract key profile’s "unique" field. If a policy digest is provided
in the OEM provisioning certificate of this EVCC, the value of the policy digest shall be
included in the encryption of the contract certificate private key via the "authPolicy"
field of the contract key profile.
NOTE 2 The values from Table 19
...