Cybersecurity Certification Requirements for Distributed Energy Resources: A Survey of SunSpec Alliance Standards

Abstract

This survey paper explores the cybersecurity certification requirements defined by the SunSpec Alliance for Distributed Energy Resource (DER) devices, focusing on aspects such as software updates, device communications, authentication mechanisms, device security, logging, and test procedures. The SunSpec cybersecurity standards mandate support for remote and automated software updates, secure communication protocols, stringent authentication practices, and robust logging mechanisms to ensure operational integrity. Furthermore, the paper discusses the implementation of the SAE J3072 standard using the IEEE 2030.5 protocol, emphasizing the secure interactions between electric vehicle supply equipment (EVSE) and plug-in electric vehicles (PEVs) for functionalities like vehicle-to-grid (V2G) capabilities. This research also examines the SunSpec Modbus standard, which enhances the interoperability among DER system components, facilitating compliance with grid interconnection standards. This paper also analyzes the existing SunSpec Device Information Models, which standardize data exchange formats for DER systems across communication interfaces. Finally, this paper concludes with a detailed discussion of the energy storage cybersecurity specification and the blockchain cybersecurity requirements as proposed by SunSpec Alliance.

1. Introduction

The shift towards digitization and decentralization in the electric power grid is an important step in order to achieve both economic and environmental sustainability [1]. Distributed Energy Resources (DERs), such as rooftop solar panels, battery storage systems, and electric vehicles, are increasingly integrated into modern power grids, and they provide significant benefits to power and utility companies by reducing operational costs while also giving greater control to the users and the energy aggregators over their energy production and consumption [2]. However, as DERs become more interconnected and interoperable, several cybersecurity concerns arise, especially due to their remote management and control. Additionally, the reliance on communication networks and the wide variety of DER configurations significantly expand the potential attack surface.

In this paper, a detailed survey is presented based on the SunSpec Alliance’s proposed best practices related to DER devices’ cybersecurity standards. The analysis focuses on the SunSpec Cybersecurity Certification requirements and their main categorization. Then, a detailed analysis is provided on the SunSpec requirements for the test procedure by identifying the main test cases and analyzing the SAE J3072 system architecture. Then, the SunSpec Modbus functionalities are presented, where the SunSpec Modbus is an open communication standard specifically designed to facilitate interoperability among the DER system components. Additionally, the SunSpec Device Information Models are presented in order to standardize the device data exchange. Moreover, the SunSpec energy storage cybersecurity specifications are discussed along with the SunSpec blockchain cybersecurity requirements. Finally, a detailed gap analysis is performed to identify the main gaps of the SunSpec Alliance cybersecurity standards, and solutions are proposed to address these gaps.

1.1. Related Work

DERs play a critical role in the operation of modern smart grid systems [3]. Recently, substantial research work has been focused on the cybersecurity challenges related to DER devices. A Bayesian deep learning approach is introduced in [4] to enhance intrusion detection in smart grids consisting of DERs and address the data imbalance and measurement noise challenges in order to improve the cybersecurity levels of the overall system. A new security and resilience framework for smart inverters is analyzed in [5] to address the emerging cyber threats and bridge the gap between cybersecurity and power electronics communities. A useful open-source dataset for the cybersecurity analysis of battery energy storage systems (BESSs) is provided in [6] to facilitate the risk evaluation and the development of monitoring algorithms for the DER system. A monolithic cybersecurity architecture for power electronics systems is proposed in [7] by integrating semantic principles into signal reconstruction in order to enhance the resilience against data attacks and to improve system performance through a unified, scalable approach validated via real-world and simulated networks. A hybrid multi-model co-simulation infrastructure that integrates software and hardware simulators to effectively test and evaluate DER scenarios is presented in [8] in order to address the challenges related to interoperability, cybersecurity, and data management.

The authors in [9] focus their study on designing a resilient distributed algorithm utilizing homomorphic encryption and an event-triggered mechanism to protect privacy and ensure the convergence of microgrid energy management systems despite potential data intrusions and attacks. Focusing on the resilience against cyberattacks, the authors in [10] introduce a distributionally robust recovery resource allocation method using a tri-level defender–attacker–defender model, and they ultimately optimize the recovery processes. A comprehensive review of the vulnerabilities, cyberattack defense strategies, and research tools for inverter-based power systems with Distributed Energy Resources is summarized in [11]. An active defense approach that enhances the detection of false data injection (FDI) attacks in DER-based microgrids is proposed in [12] by adopting a dynamic system reconfiguration and using Distributed Energy Resources. A thorough review of the current practices, challenges, and future trends in the cyberphysical security of grid-connected battery energy storage systems (BESSs) is provided in [13]. A real-time cybersecurity testbed framework is developed in [14] to evaluate the undetectable false data injection attacks on utility-scale Distributed Energy Resources and state estimators.

A new propulsion energy model for fixed-wing unmanned aerial vehicles (UAVs) is proposed in [15] to jointly optimize the 3D flight trajectories and data collection schedules for secure and energy-efficient data collection under eavesdropping attacks. A non-orthogonal multiple-access (NOMA)-assisted secure offloading scheme for vehicular edge computing (VEC) networks is designed in [16] by utilizing physical layer security (PLS) and an asynchronous advantage actor–critic (A3C) algorithm to minimize energy consumption while ensuring offloading security and low computation delay in the presence of malicious eavesdroppers. Also, a deep recurrent reinforcement learning (DRRL)-based energy-efficient cooperative secure transmission scheme for mmWave vehicular networks is presented in [17], aiming at optimizing beam allocation, cooperative node selection, and transmit power to enhance the performance of secrecy while minimizing energy consumption. The security and functional safety challenges of artificial intelligence (AI) in embedded automotive systems are analyzed in [18] and the authors provide recommendations on how machine learning can address these challenges, along with an overview of contemporary engineering practices and the role of AI edge processing. The authors in [19] critically evaluate seven major cybersecurity frameworks and introduce novel risk management-based evaluation criteria. Also, the authors provide a unified mapping approach to streamline compliance across multiple standards. In [20], the authors compare the NIST Cybersecurity Framework (CSF) v2.0 with a new European Union standard to assess their suitability and identify gaps to achieve a comprehensive cybersecurity coverage in the defense sector, particularly in the space domain. A comprehensive cyber risk management plan for the ICT unit of the ABC organization is presented in [21], identifying 105 risks and providing 86 control recommendations.

1.2. Contributions and Outline

This paper provides a comprehensive survey of the cybersecurity certification standards established by the SunSpec Alliance for Distributed Energy Resource (DER) systems. The key contributions of this survey paper are as follows:

• We analyze the SunSpec cybersecurity standards, focusing on critical aspects such as secure communication, robust authentication processes, automated software updates, and comprehensive logging protocols to ensure the safety and reliability of DER devices.
• We emphasize the importance of remote and automated software update mechanisms and encrypted communication channels for maintaining the security of DER systems. Our survey highlights the adoption of SAE J3072 in conjunction with the IEEE 2030.5 protocol, and its role in securing communication between electric vehicle supply equipment (EVSE) and plug-in electric vehicles (PEVs), particularly in vehicle-to-grid (V2G) operations.
• We present in detail the SunSpec Modbus standard, which aims at enhancing the interoperability between various DER components and supports compliance with grid integration requirements.
• We evaluate the SunSpec Device Information Models, which offer standardize data structures that facilitate seamless communication across the DER systems. Finally, we provide an in-depth analysis of the SunSpec Alliance’s energy storage cybersecurity framework and its proposed blockchain-based security standards.

The remainder of this paper is organized as follows. Section 2 analyzes the SunSpec Cybersecurity Certification requirements and Section 3 discusses the SunSpec Requirements for the test procedure. Section 4 provides a thorough gap analysis and proposes a path to address these gaps. Finally, Section 5 concludes the paper.

2. SunSpec Cybersecurity Certification Requirements

SunSpec Cybersecurity Certification identified and organized cybersecurity requirements (Figure 1 in the following main categories [22,23]:

• Software Updates/Product Support: The Distributed Energy Resource (DER) devices must (i) support updating mutable security and operational software components, including the operating system, boot loader, applications, libraries, etc.; (ii) provide a mechanism for users to read the current software version; (iii) support remote updates by communicating with a remote server at least once per day to download and install software updates; (iv) support automated updates to streamline the update process; (v) verify the authenticity and integrity of software updates before installing them; and (vi) meet the same security requirements as remote updates in the event that the DER devices support local updates.
• Device Communications: The DER devices must (i) implement secure communication protocols (TLS 1.2 or higher, IPSec version 2 or higher, or SSH-2) for all communications accessing the public internet and (ii) reject deprecated security technologies identified by the NSA and IETF to prevent vulnerabilities.
• Authentication: Regarding the authentication of the DER devices, the SunSpec Alliance (i) requires each user to have unique security credentials for access levels or accounts; (ii) mandates secure authentication mechanisms for all electronic access, locally or remotely; (iii) requires automatic logout after a period of inactivity; (iv) allows authorized users to set session timeout periods; (v) enforces strong password requirements or provides a strength meter; (vi) requires users to create new passwords if defaults are shared or displayed; (vii) implements account lockouts after consecutive failed login attempts; (viii) prevents storage or display of unencrypted passwords; and (ix) supports at least one admin account without brute force prevention.
• Device Security: Regarding the device security, the SunSpec Alliance (i) removes or disables unnecessary interfaces and ports before device transfer and (ii) supports a “factory reset” option for end-of-life or repurposing.
• Logging: The logging requirements include secure storage, timestamps, resolution, accuracy, configuration, security events, remote logs, incident reporting, power setting logs, power cycle logs, and panel logs.

3. SunSpec Requirements for Test Procedure

The required equipment and software to perform tests in accordance with the SunSpec Cybersecurity Certification requirements are as follows [24]: (i) IUT (Interface Under Test) (one or two devices, depending on type of local software update support and whether running older software images); (ii) endpoints (devices to exercise communication capabilities, with documentation for modifying security settings); (iii) remote log and incident server (receive and store log files and incident reports from the DER); (iv) remote software update server (sends software updates to the DER); (v) software images (current, unauthenticated, modified, and old images provided by the manufacturer); (vi) documentation (completed and signed ICS document, product manual, IXIT, and functional specifications); (vii) network monitoring tools (traffic monitor, Wi-Fi, Bluetooth, and Ethernet scanners); and (viii) secrets (keys, passwords, tokens for authenticating communications).

The superset test cases that should be validated, along with their purpose, are listed as follows in Figure 2 and Figure 3.

3.1. SunSpec Requirements SAE J3072 Implementation Using the IEEE 2030.5 Protocol [25]

This section focuses on the requirements for the implementation of the Society of Automotive Engineers (SAE) J3072 standard [26] using the IEEE 2030.5 protocol. The goal is to support the electric vehicle supply equipment (EVSE) and plug-in electric vehicle (PEV) manufacturers, and/or operators, and/or system integrators to establish the necessary grid support inverter systems within PEVs connected to electric power systems (EPSs) through conductively coupled electric vehicle supply equipment (EVSE). SAE J3072 specifies the necessary technical and performance criteria to ensure safe and effective interaction between the vehicle’s inverter system and the power grid in order to enable several functionalities, e.g., vehicle-to-grid (V2G) capabilities, as presented in Figure 4 [27].

• SAE J3072 System Architecture Overview:
  • System Concept: SAE J3072 defines how the PEVs connect to the EPSs via the EVSE using onboard inverter systems. The communication between the PEVs and the EVSE is managed using the IEEE 2030.5 protocol, which ensures the safe and authorized power discharge from vehicles to the grid.
  • Security Considerations: The primary security focus is on the communication between PEVs and EVSE, specifically preventing man-in-the-middle (MITM) attacks. Both the PEV and EVSE must use IEEE 2030.5-compliant certificates and secure HTTPS connections to mitigate these risks. However, due to the point-to-point nature of the physical connection and additional protocols, the likelihood of successful MITM attacks is considered low.
  • Communication Architecture: The PEV and EVSE communicate over a physical power line communication (PLC) link, utilizing TCP/IP protocols for secure data transfer. Each connection is unique to ensure proper authentication and data integrity.
  • Operations and Compliance: Upon connection, the PEV identifies and authenticates the EVSE, discovers necessary resources, and exchanges information to receive discharge authorization. This authorization is periodically monitored and managed to ensure that the PEV operates within defined limits. If unauthorized activity is detected, the EVSE can revoke discharge permissions and, if necessary, disconnect the PEV.
  • Periodic Operations: PEVs continuously send operational data to the EVSE, including metrology and status information, ensuring compliance with site-specific limits and discharge authorizations. The communication frequency and data requirements are dynamically managed by the EVSE.
  • Exception Handling: PEVs operate in a default mode unless explicitly authorized to discharge by the EVSE. Authorization can be withdrawn due to communication failures or other exceptions, prompting the PEV to cease discharging within a specified timeframe. Both PEVs and EVSE must be capable of handling such scenarios to maintain system integrity.

The main security protocols identified by SunSpec Alliance in order to implement the SAE J3072 using the IEEE 2030.5 protocol are summarize as follows.

• TLS Encryption: Mutual TLS encryption is mandatory during initial communications to establish a secure connection. Both devices exchange IEEE 2030.5-compliant certificates to authenticate each other.
• Device Certificates: PEV certificates must encode make and model details using Object IDs (OIDs). This information enables the verification of the PEV’s authenticity and suitability for connection.
• IPv6 Usage: All communications utilize IPv6, with specific address blocks and stateless address autoconfiguration for the secure and unique identification of devices on the network.
• Restricted Bridging/Routing: Initially, the EVSE restricts any bridging or routing of PEV communications to prevent unauthorized network access. Bridging may only be enabled after successful PEV authorization.
• Service Discovery: Multicast DNS (mDNS) is employed for discovering services on the network, ensuring that devices can locate necessary resources securely without reliance on external DNS servers.

These requirements ensure the secure and authenticated interactions between the EVSE and the PEVs, aiming at securing the data exchange and operational integrity of the electric vehicle charging systems. It is noted that if communication is lost between the PEV and the EVSE, the PEV sends a heartbeat message every second, and the EVSE monitors for these signals. A failure to receive ten consecutive heartbeats prompts the EVSE to stop the PEV from discharging. Therefore, the reception of three consecutive heartbeats restores the connection. Additionally, the EVSE has a gatekeeper function to cut off power if unauthorized or out-of-limit discharging occurs, and can revoke discharge authorization, which the PEV must comply with within three seconds. The SAE J3072 standard also covers coordinated charging/discharging and sleep/wake functions to ensure secure and efficient operations.

The IEEE 2030.5 messages (i) facilitate communication between the PEVs and the EVSE and (ii) ensure secure interactions, i.e., service discovery and resource retrieval. The following cybersecurity requirements need to be considered throughout the communication between the PEVs and the EVSE:

• Service Discovery: The PEVs and EVSE use mDNS and DNS-SD for service discovery, and they also establish a secure TLS connection before retrieving the DeviceCapability resources.
• Resource Discovery: The PEVs have access to a wide range of resources, e.g., DeviceCapability, Time, EndDeviceList, and DERList, in order to ensure secure data exchange.
• PEV Retrieves Site Limits: The PEVs retrieve site limits from the EVSE in order to guarantee their compatibility and secure communication.
• PEV Sends Info to EVSE: The PEVs send information, e.g., Device Information, Power Status, DER Capability, and DER Settings, to the EVSE in order to guarantee secure data transmission.
• PEV Retrieves Management Information: The PEVs retrieve information, e.g., Function Set Assignments, Time, DER Program List, Default DER Control, and DER Control List, in order to guarantee the secure management and operation.
• DERControl Responses: The EVs send responses to the DERControl commands in order to indicate the status of the control action. These responses are immediately sent upon receiving the control command.
• Mirror Usage Point Setup: The EVs post mirror usage point data, including meter readings such as active power, reactive power, voltage, and frequency. These readings are posted periodically and their update rate is determined by the meter usage point configuration.
• Subscriptions and Notifications: The EVs subscribe to receive notifications about changes in control commands or system configurations. The charging infrastructure sends notifications to EVs when such changes occur.
• Periodic Retrieval of Information: The EVs periodically query the charging infrastructure for updates on control commands, meter readings, and system configurations. This allows the EVs to stay synchronized with the charging infrastructure and respond to the changes in a timely and synchronized manner.
• Sends Periodic Information: The periodic information sent by the PEVs includes updates on the DERStatus, PowerStatus, DERAvailability, Meter Readings (i.e., Active Power, Reactive Power, Voltage, and Frequency), which serve as the heartbeat messages for the detection of the loss of communication. Additionally, the PEVs interact with the new DERControl and adjust the Active Power limits for the site, and also coordinate the charging and discharging processes through the DERControl responses.

3.2. SunSpec Modbus

The SunSpec Modbus is an open communication standard specifically designed to facilitate interoperability among DER system components. Developed by SunSpec Alliance, this protocol leverages the widely adopted Modbus framework, which has been a cornerstone in industrial electronic communications since the 1980s. SunSpec Modbus defines standardized parameters and settings for the monitoring and control of DER systems, such as solar inverters, PV modules, meters, and energy storage devices. By providing a common language for these components, SunSpec Modbus ensures seamless integration, reduces implementation costs, and supports compliance with updated grid interconnection standards, such as the IEEE 1547-2018 [28].

• IEEE 1547-2018 Standard
  • Revision: April 2018 by the IEEE.
  • Requirement: Communication interface for DER systems.
  • Interfaces: SunSpec Modbus or other standard interfaces.
  • Adoption: Mandatory for all DERs in state and local jurisdictions once adopted.
• SunSpec Modbus Interface

  ⋄

  Purpose:

  −

  Defines parameters and settings for DER monitoring and control.

  −

  Enhances interoperability.

  −

  Facilitates voltage regulation, power factor setting, and power export limiting.

  ⋄

  Development:

  −

  Based on Modbus protocol (1980s).

  −

  Created by SunSpec Alliance (2009).

  −

  Extended to cover solar inverters and other DERs.

  ⋄

  Adoption:

  −

  Integrated into ~80% of DER devices.

  −

  Simple to add SunSpec Modbus support for IEEE 1547 compliance.

Table 1. Benefits and descriptions of integration.

Benefit	Description
Simple Integration	Short step for manufacturers familiar with Modbus to comply with IEEE 1547-2018
Cost-Effective	Low cost due to existing network interfaces in most DER devices
Easy Compliance	Provides royalty-free specs, reference software, and development tools

summarizes the benefits of the SunSpec Modbus interface.

• SunSpec Modbus and DER Systems

The main applications of the SunSpec Modbus in DER systems are focused on monitoring, control, operations, maintenance, and custom applications. The main components that are utilized along with their interface are summarized in

Table 2. Components and their SunSpec Modbus interfaces.

Component	Interface
Inverter	SunSpec Modbus
PV Module	SunSpec Modbus
Meter	SunSpec Modbus
Tracker	SunSpec Modbus
Storage	SunSpec Modbus
Gateway	SunSpec Modbus

[29].

The IEEE 1547-2018 standard mandates DER systems to have a standard communication interface, such as SunSpec Modbus, to ensure interoperability, ease of integration, and cost-effective compliance.

⋄

Communication and Interoperability:

−

Protocol: Leverages Modbus protocol for DER devices.

−

Communication: Between loggers, servers, and DER devices.

−

Information Model: Defines data points and functionality.

Table 3. Communication and interoperability standards.

Standard	Interface
IEEE 1547-2018	Establishes the communication requirements for DER systems.
IEEE 2030.5	Specifies internet communication protocols used in DER systems.
IEEE 1815	Defines protocols for utility network communication.

lists standards related to communication and interoperability for DER systems and identifies specific standards and their corresponding interfaces.

⋄

SunSpec Information Models

−

Device Information Models: Define data points and functionality.

−

Encoding: Uses JSON and CSV formats.

Table 4. SunSpec information models.

Model	Description
Common Model	Provides basic identification details about the physical device, such as manufacturer, model, and serial number. This model is always included in a SunSpec-compliant device.
Standard Models	Specify common data points implemented by devices within a given category. These models ensure that devices within the same category share a common set of data points for interoperability.
Vendor Models	Defined by individual device vendors, these models include data points unique to the vendor’s specific implementation. Although they must adhere to certain rules, they do not follow the SunSpec Standard Model review process. Each Vendor Model requires an identifier assigned by SunSpec.

summarizes the types of SunSpec information models and their purposes.

⋄

Certification and Conformance

−

Process: Vendors declare implementations in a Protocol Implementation Conformance Statement (PICS).

−

Conformance: Verified against SunSpec standards.

3.3. SunSpec Device Information Models to Standardize Device Data Exchange

SunSpec Device Information Models provide a standardized approach for specifying and structuring device data for exchange across communication interfaces. These models facilitate the standardization of device datasets, which can be represented using the Modbus or the JSON encoded messages. The key aspects of the SunSpec Device Information Models are summarized in

Table 5. Key aspects and descriptions of SunSpec devices’ information models.

Key Aspects of SunSpec Device Information Models	Description
Standardization	The models ensure a consistent method for defining and using device data.
Communication Interfaces	They support data exchange via Modbus and JSON, making them versatile for different applications.
Model Structure	The models consist of various elements such as models, points, point groups, symbols, and comments to represent device data comprehensively.

as follows [30].

To define the SunSpec Device Information Models, the following elements are adopted (

Table 6. Key elements and their descriptions in SunSpec devices’ information models.

Element	Description
Model	Logical grouping of data points with a unique model ID.
Point	Defines a device data point with a value.
Point Group	Groups multiple points or other point groups.
Symbol	Name–value pair representing constant values for points.
Comment	Annotations for documenting elements.

).

The Device Information Model definitions represent collections of device data points, which can be standardized for interface usage. These models use definition elements to structure and describe device data, as summarized in Table 6. The attributes associated with each element type are summarized in

Table 7. Description of attributes in the model hierarchy. R and O indicate the required and optional attributes, respectively.

Attribute	Description	Model	Point Group	Point	Symbol
ID	Element name, unique within the group	R	R	R	R
Points	Array of point definitions		R
Groups	Array of point group definitions		O
Value	Constant value associated with the element				R
Type	Element type		R	R
Count	Occurrence count of the element		O	O
Size	Element size, mandatory for strings			O
Scale Factor	Scale factor point for the element			O
Units	Units associated with the element			O
Access	Read or read/write access			O
Mandatory	Indicates if element is mandatory			O
Label	Short label for the element	R	R	O	O
Description	Element description	O	O	O	O
Symbols	Name–value pair for enumerated values		O	O	O

. Device Information Models standardize data points for device communication interfaces. Models can be encoded in JSON or CSV for ease of use and implementation. Models can be mapped into a Modbus address space, creating a Modbus map that corresponds to the device’s supported data points (i.e., Modbus usage). Models can be represented as JSON objects, facilitating data exchange via RESTful web services or other JSON-based interfaces (i.e., JSON usage). By using standardized Device Information Models, the devices can efficiently exchange data in a consistent and interoperable manner across different communication protocols.

Furthermore, the SunSpec Device Information Model Specification defines a structured approach for modeling and encoding device information, primarily aimed at energy-related devices. The specification defines various types of data representation within the model, ranging from numeric to floating point to other types of data representation, as summarized in

Table 8. Description of various data types.

Numeric Types	Floating Point Types	Other Types
int16, int32, int64: Signed integers of 16, 32, and 64 bits, respectively.	float32: 32-bit floating-point number.	string: UTF-8 encoded string.
uint16, uint32, uint64: Unsigned integers of 16, 32, and 64 bits, respectively.	float64: 64-bit floating-point number.	sunssf: Scale factor for applying multipliers or dividers.
raw16: 16-bit raw value.		pad: 16-bit pad used for alignment.
acc16, acc32, acc64: Unsigned accumulators of 16, 32, and 64 bits, respectively.		ipaddr: Unsigned 32-bit IPv4 address.
bitfield16, bitfield32, bitfield64: Bitfields of 16, 32, and 64 bits, respectively.		ipv6addr: 16-byte IPv6 address.
enum16, enum32: Enumerations of 16 and 32 bits, respectively.		eui48: 48-bit MAC address.

, each with specific attributes that govern their behavior and encoding.

Each element in the model can have several attributes that define its characteristics: (i) Count: Specifies the number of occurrences of the element. (ii) Size: Maximum length of the element in 16-bit words. (iii) Scale Factor (sf): Applies a signed scale factor to numeric values. (iv) Units: Specifies the units associated with the element. (v) Access: Specifies if the element is read-only, i.e., R, or read/write, i.e, RW. (vi) Mandatory: Specifies whether the element is mandatory, i.e., M, or optional, i.e., O. (vii) Label: Short label associated with the element. And (viii) Description: Provides a brief description of the element. The primary encoding format for defining SunSpec Device Information Models is JSON, providing a structured and human-readable representation. CSV encoding is also supported for convenience, allowing models to be created and inspected using spreadsheet applications. Finally, for integration with the Modbus, SunSpec models are mapped into Modbus registers, specifying address locations, supported function codes (Read Holding Registers, Write Multiple Registers), and error handling procedures.

3.4. SunSpec DER Information Model Specification

The SunSpec DER Information Model Specification outlines a detailed and thorough framework for defining data exchange standards between DERs and different interfacing systems. The specification defines standard SunSpec Device Information Models for DERs, enabling reliable information exchange between DERs and control systems. It supports various DER management functions through specific models like DER AC Measurement, Capacity, Frequency Droop, and more. The DER information models as introduced by SunSpec are summarized in

Table 9. Curve Management Points.

Symbol	Description	Access
Ena	Enables or disables the function.	Read/Write
AdptCrvReq	Selects a new curve setting.	Read/Write
AdptCrvRslt	Result of the AdptCrvReq operation.	Read-Only
NPt	Number of possible curve points.	Read-Only
NCrv	Number of curve instances.	Read-Only
ActPt	Number of active points in the curve.	Read/Write

[31].

Several important management points related to curves within the SunSpec DER Information Model Specification have been identified for managing and adjusting curve settings in DERs, as summarized in

Table 10. Description of Model Names.

Model Name	Description
DER AC Measurement	Measurement data, status, and alarm information.
DER Capacity	Capacity-related information.
DER Enter Service	Enter service-related data.
DER AC Controls	AC control settings and parameters.
DER Volt-Var	Voltage–var control settings and parameters.
DER Volt-Watt	Voltage–watt control settings and parameters.
DER Trip LV	Low-voltage trip settings and parameters.
DER Trip HV	High-voltage trip settings and parameters.
DER Trip LF	Low-frequency trip settings and parameters.
DER Trip HF	High-frequency trip settings and parameters.
DER Frequency Droop	Frequency droop settings and parameters.
DER Watt-Var	Watt–var control settings and parameters.
DER Storage Capacity	Storage capacity-related information.
DER DC Measurement	DC measurement data and parameters.

.

SunSpec has also defined the behavior of DERs related to voltage trip and momentary cessation within specified regions. Three main types of voltage trip have been identified: immediate trip, i.e., where the DER must trip immediately upon entering the region, momentary cessation, i.e., where the DER ceases energizing but does not trip, and conditional behavior, i.e., where the DER may or may not trip based on specific conditions. This hierarchical structure and categorization (

Table 11. Voltage trip/momentary cessation points.

Region	DER Behavior	Precedence Hierarchy
Trip	DER trips when region is entered.	1 (highest)
May Trip	DER may continue operating or trip.	3
Momentary Cessation	DER ceases energizing but does not trip.	2

) help to clarify which behavior takes precedence when multiple conditions are active at the same time, ensuring consistent and reliable DER operation in varying grid conditions.

Moreover, focusing on the DER Capacity information model, this model provides a structured approach to manage ratings and settings for DERs and includes read-only ratings and configurable settings that override default values for operational parameters. Based on the DER Capacity information model, different DER capacity points are characterized by RW access, i.e., indicating whether the point is read/write (RW), read-only (-), or write-only (-); they can be mandatory for the model (M) or optional (-), and static (S) or dynamic (-) in nature, as summarized in

Table 12. DER capacity points.

Group/Point Name	Label	Data Type	RW Access	Mandatory (M)	Static (S)
DERCapacity	DER Capacity group ID	uint16	-	M	S
L	DER Capacity Model Length	uint16	-	M	S
WMaxRtg	Active Power Max Rating	uint16	-	-	S
WOvrExtRtg	Active Power (Over-Excited) Rating	uint16	-	-	S
WUndExtRtg	Active Power (Under-Excited) Rating	uint16	-	-	S
VAMaxRtg	Apparent Power Max Rating	uint16	-	-	S
VarMaxInjRtg	Reactive Power Injected Rating	uint16	-	-	S
WChaRteMaxRtg	Charge Rate Max Rating	uint16	-	-	S
VNomRtg	AC Voltage Nominal Rating	uint16	-	-	S
AMaxRtg	AC Current Max Rating	uint16	-	-	S

. A similar approach is followed for the DER capacity settings, as presented in

Table 13. DER capacity settings.

Group/Point Name	Label	Data Type	RW Access	Mandatory (M)	Static (S)
WMax	Active Power Max Setting	uint16	RW	-	-
WOvrExtPF	Specified Over-Excited PF	uint16	RW	-	-
WMaxUndExt	Active Power (Under-Excited) Setting	uint16	RW	-	-
VAMax	Apparent Power Max Setting	uint16	RW	-	-
VarMaxInj	Reactive Power Injected Setting	uint16	RW	-	-
VNom	Nominal AC Voltage Setting	uint16	RW	-	-
AMax	AC Current Max Setting	uint16	RW	-	-

(please note that the most representative and important DER capacity points and capacity settings are summarized in Table 12 and Table 13, respectively).

3.5. SunSpec Energy Storage Cybersecurity Specifications

The SunSpec Alliance Interoperability Specification outlines detailed data models (please also refer to the previous section) and Modbus register mappings tailored for standalone energy storage systems (ESSs). Initially focused on lithium-ion and redox flow batteries, SunSpec accommodates diverse storage technologies, such as advanced lead-acid and vanadium redox flow batteries. The SunSpec ESS models’ specification aligns closely with cybersecurity standards and protocols to ensure robust communication interfaces across devices. The models are designed to integrate seamlessly with IEC 61850-7-420 [32], maintaining consistency in naming conventions, units, and behaviors, while some concepts in this specification currently lack direct equivalents in IEC 61850-7-420. An overview of the SunSpec ESS models is provided in

Table 14. Overview of SunSpec energy storage system models.

Model #	Name	Summary	Availability
802	Battery Base Model	Key monitoring and control points of all batteries	TEST
803	Lithium-ion Battery Bank	Monitoring and control of lithium-ion battery banks	TEST
804	Lithium-ion Battery String	Monitoring and control of lithium-ion battery strings	TEST
805	Lithium-ion Battery Module	Monitoring and control of lithium-ion battery modules	TEST
806	Flow Battery Bank	Monitoring and control of flow battery banks	N/A
807	Flow Battery String	Monitoring and control of flow battery strings	TEST
808	Flow Battery Module	Monitoring and control of flow battery modules	N/A
809	Flow Battery Stack	Monitoring and control of flow battery stacks	N/A

[33].

SunSpec ESS models’ specification introduces support for flow batteries, addresses feedback from industry stakeholders, and enhances the robustness and comprehensiveness of the models, making them suitable for deployment in production systems. In commercial and industrial setups, lithium-ion battery strings are used to provide backup power and peak power-limiting capabilities. These are structured into strings composed of modules, each monitored through specific models. Manufacturers must manage the Modbus register limits (i.e., avoid exceeding the 65,535 register limit) when implementing multiple models. Flow batteries, unlike lithium ion, typically operate as a single string and provide significant energy capacity. The Battery Base Model and Flow Battery String Model are core components for communication. The foundational model provides essential information like nameplate values, state of charge management, depth of discharge, and health metrics that are applicable across different battery technologies. Focusing on the battery type and alarm information, the SunSpec ESS models outline the following descriptive standards regarding each aspect of the ESS (either hardware or software or operation-oriented aspect) for communicating with and managing the battery systems (

Table 15. Battery aspects.

Aspect	Description
Battery Type Enumeration (Typ)	Enumerates the type of battery connected, aiding Modbus masters in identification.
Battery Alarms and Warnings (Evt1)	Bitfield for managing alarms and warnings; includes standard and custom alarm capabilities.
Alarm Reset (AlmRst)	Resets latched alarms upon receiving a value of 1; updates Evt1 to reflect alarm reset status.
External Battery Measurements	Registers: V (External Battery Voltage), A (Total DC Current), W (Total Power).
Max/Min Cell Voltage (CellVMax/CellVMin)	Provides maximum and minimum voltages across all cells; essential for monitoring cell performance.
Optional Location Data	Registers: CellVMaxStr, CellVMaxMod, CellVMinStr, CellVMinMod; specify location of extreme voltages.
Dynamic Limits	Registers: AChaMax (Max Charge Current), ADisChaMax (Max Discharge Current), VMax (Max Voltage), VMin (Min Voltage).
Operational Boundaries	Communicates maximum and minimum operational limits for current and voltage; ensures safe operations.
Battery States (State)	Enumerates operational states (Disconnected, Initializing, Connected, Fault).
State Transitions	Managed via SetOp commands; reflect state changes such as connect/disconnect operations.
Inverter State (SetInvState)	Indicates current state of connected inverter to coordinate battery operations.
Temperature Monitoring	Registers: ModTmpMax (Max Module Temperature), ModTmpMin (Min Module Temperature).
Location-Specific Data	Registers: ModTmpMaxStr, ModTmpMaxMod, ModTmpMinStr, ModTmpMinMod; provide temperature location.
String-Level Metrics	Registers: StrVMax, StrVMin (Voltage); StrAMax, StrAMin (Current); StrSoC, StrSoH (State/Health).
Operational Details	String state (StrSt), fault reasons (StrDisRsn), and health metrics at string level.

).

3.6. SunSpec Blockchain Cybersecurity Requirements

The SunSpec Blockchain Work Group proposes a blockchain-based key registry for DER devices to enhance cybersecurity by providing accessible and integrity-protected information about cryptographic keys. This set of cybersecurity standards addresses the current shortcomings in security practices for DERs and ensures their robust protection against cyber threats [34].

A permissioned blockchain architecture is proposed using Byzantine Fault-Tolerant (BFT) consensus, with governance structures designed to mitigate security risks, including nation-state threats and coercion. The main components of this architecture include a high-level data model and an API for managing and querying key security information. The main actors involved in the DER service security based on this standard are summarized in

Table 16. Main actors involved in DER device security with different colors.

Actor	Description
Manufacturer	Responsible for device manufacturing and key registration on the blockchain.
Authorized Assessor	Independent evaluator of key creation and provisioning processes, auditing device security.
Key Generator	Entity creating and provisioning cryptographic keys into DER devices.
Certificate Authority	Issues digital certificates based on blockchain information to validate DER device identities.
Governing Body	Oversees the blockchain governance, establishing rules and security protocols.
DER Client	Equipment in the DER space using registered keys for secure communications.
DER Server	Web server endpoint managing communications with DER Clients based on key security levels.

, while different use case scenarios where this standard can find applications are presented in

Table 17. Main use case scenarios.

Use Case Description	Key Features
Manufacturer registers private/public key pairs on blockchain for DER devices.	Secure key creation and provisioning processes.
Authorized Assessor audits and stores evaluation reports on blockchain.	Independent verification of device security measures.
Certificate Authority validates device identities using blockchain information for TLS sessions.	Issuance of digital certificates based on verified device keys.
DER Server makes trust decisions based on blockchain data regarding device security properties.	Secure communication with DER Clients based on certified key security levels.

.

The proposed standard organizes and secures the key management practices across the energy grid. The primary use case involves the secure management of private/public key pairs for Distributed Energy Resource (DER) devices, facilitated by blockchain technology. The main interactions that take place include the following:

• Authorized Assessor Audit:

  −

  An authorized Assessor conducts security audits on key generation, key storage within DER Clients, and key exposure in the manufacturing supply chain.

  −

  Audit results are stored on the blockchain for transparency and integrity.

• Key Generation and Provisioning:

  −

  The Key Generator creates and provides private/public key pairs into DER Clients, ensuring adherence to audited processes.

  −

  Keys can be provisioned during manufacturing or installation, with mechanisms to securely store and control access to the private key.

• Manufacturer Responsibilities:

  −

  Manufacturers produce DER Clients, ensuring compliance with audited processes for key handling and provisioning.

  −

  Manufacturers register each device’s key on the blockchain, linking it to audited processes and device information.

• Certificate Authority (CA) Issuance:

  −

  CAs issue certificates based on blockchain-verified information, ensuring secure mapping between public keys and device attributes.

  −

  Certificates are essential for secure TLS sessions between DER Clients and DER Servers, facilitating mutual authentication.

• DER Server Validation:

  −

  DER Servers validate DER Client certificates during TLS handshakes using blockchain data, ensuring that the trustworthiness of private key management meets minimum security requirements.

The proposed cybersecurity standard also integrates traditional Certificate Authority (CA) mechanisms with blockchain for enhanced security and lifecycle management of DER Clients. To realize the latter, the following main points need to be ensured:

Certificate Creation and Validation:

• A CA issues X.509 certificates containing DER Client public keys and policy parameters.
• Certificates are used for authentication during communication with DER Servers.

Blockchain Integration:

• DER Servers query the blockchain using extracted key identifiers from certificates.
• Blockchain provides additional cybersecurity information beyond traditional mechanisms like OCSP and CRL.

Key Lifecycle Tracking:

• Lifecycle stages include manufacturing, distribution, installation, and decommissioning.
• Blockchain records ownership transfers, end-of-life events, and key revocations.

Supply Chain Security:

• Involves multiple actors (manufacturers, distributors, installers) ensuring secure key provisioning and ownership transfer.
• Different scenarios (component integration, service provision) affect blockchain recording requirements.

4. Gap Analysis on SunSpec Alliance Standards

In this section, based on the detailed survey performed on the SunSpec Alliance Standards, a thorough gap analysis is performed following the National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF). The NIST CSF was initiated by the Department of Energy (DOE) in the United States of America and the Electric Power Research Institute (EPRI) to improve organizational cybersecurity risk management strategies. In our gap analysis, we adopted the 2.0 version of the NIST CSF [35] to analyze the gaps in the SunSpec cybersecurity standards, given that it provides a structured approach for businesses, government agencies, and other entities to address cybersecurity risks. This version of the NIST CSF offers a broad framework of key cybersecurity goals that organizations of any size, sector, or level of maturity can use to assess, prioritize, and enhance their cybersecurity strategies.

The NIST CSF’s core gap analysis is organized into three main components, i.e., Functions, Categories, and Subcategories, with each Category representing a subset of the overarching Functions, and the Subcategories represent a breakdown of the Categories. The NIST CSF’s core structure is presented in Figure 5. A summary of the gap analysis is provided below.

4.1. Gap Analysis

The SunSpec Cybersecurity Certification program mainly covers the secure communication among the different DER devices, authentication, software updates, and continuous monitoring of the DER devices. Specifically, SunSpec requires the use of protocols like TLS and IPSec in order to protect the data in transit; it mandates secure methods in order to manage authentication credentials and ensure that only authorized access is possible. Moreover, SunSpec addresses the need for regular software updates and provides guidelines in order to prevent unauthorized software installations. Additionally, SunSpec includes aspects of continuous monitoring and secure communication among the DER devices. On the other hand, topics related to organizational relevant cyber security requirements are not covered by SunSpec. Specifically, SunSpec does not cover organizational security measures, cybersecurity training of personnel, data security specifically in terms of data-in-transit and data-in-use, platform security and infrastructure, and the incident management. Specifically, SunSpec does not cover identity management and access control policies beyond the ones described at the DER device level as well as broader organizational security practices. SunSpec does not provide requirements for training programs for personnel and for data backup for recovery from data loss or corruption. Additionally, SunSpec does not discuss configuration management practices, technology infrastructure resilience, hardware maintenance and life cycle management of the hardware. The device-level cyber security standards provided by SunSpec cover all the critical aspects related to the communication, authentication, authorization, software updates, and monitoring of the devices, which is one of the main goals of this project. Organizational-related cyber security standards can be addressed, if needed, by other standards listed in this survey analysis. Thus, from the performed analysis, it is concluded that SunSpec covers all the most critical aspects of the device-level security, which becomes critical for securing the electric vehicles’ infrastructure both of the front-end and at the back-end.

Table 18. Gap analysis summary for SunSpec cybersecurity standards.

	SunSpec
Organizational Context (GV.OC)	Insufficiently Addressed: The SunSpec documentation provides an overview of interoperability processes and standards for Distributed Energy Resource (DER) systems, including the SunSpec Alliance’s specification process, information models, and conformance and certification requirements. However, it falls short in addressing critical aspects such as the organizational mission, stakeholder expectations, and legal, regulatory, and contractual requirements related to cybersecurity risk management decisions. Additionally, the documentation lacks the identification of specific internal or external stakeholders and does not adequately cover the cybersecurity-related expectations of DERs beyond what is discussed in the specifications. It also fails to address the communication of organizational objectives and services, as the focus remains primarily on the technical cybersecurity requirements for the devices.
Risk Management Strategy (GV.RM)	Insufficiently Addressed: The SunSpec framework insufficiently addresses organizational-level risk management strategies, priorities, constraints, risk tolerance, and objectives. Its focus is primarily on technical specifications and requirements for device cybersecurity, such as software updates, secure communications, and authentication mechanisms. Overall, it lacks comprehensive organizational recommendations or a broader perspective on risk management strategies.
Roles, Responsibilities, and Authorities (GV.RR)	Insufficiently Addressed: The coverage of accountability and responsibility in the SunSpec framework is insufficiently addressed in several key areas. SunSpec emphasizes the device-level certification and specifies the manufacturer requirements to ensure device security and integrity; however, it only indirectly fosters organizational accountability. The framework partially outlines the responsibilities regarding the software updates, communication security, and authentication but lacks a comprehensive discussion on cybersecurity roles beyond these device-specific mandates. Additionally, SunSpec addresses the resource allocation for compliance with cybersecurity standards; however, it does not consider the broader implications of resource management for the overall cybersecurity efforts. Furthermore, there is no mention of human resource practices.
Policy (GV.PO)	Addressed
Oversight (GV.OV)	Insufficiently Addressed: SunSpec does not address organizational-level risk management strategy review and adjustment. It primarily focuses on the technical requirements for device cybersecurity.
Cybersecurity Supply Chain Risk Management (GV.SC)	Not Addressed: SunSpec does not explicitly address roles and responsibilities beyond the device manufacturer and certifying bodies. It focuses solely on the device-level cybersecurity requirements.
Asset Management (ID.AM)	Insufficiently Addressed: The SunSpec certification focuses on individual device-type testing rather than comprehensive organizational hardware inventories. It ensures devices are certified individually but does not mandate comprehensive organizational inventory management.
Risk Assessment (ID.RA)	Not Addressed: SunSpec focuses on type testing for individual devices, not organizational vulnerabilities.
Improvement (ID.IM)	Insufficiently Addressed: The SunSpec certification focuses primarily on device-specific cybersecurity requirements and type testing. Evaluations for organizational improvements, such as cybersecurity risk assessments across all functions, are not within the scope.
Identity Management, Authentication, and Access Control (PR.AA)	Insufficiently Addressed: SunSpec specifies requirements for managing authentication credentials securely (e.g., DER/AUTH/REQ-01, DER/AUTH/REQ-06). However, it focuses more on device-specific credentials rather than the organizational management of identities across all authorized entities.
Awareness and Training (PR.AT)	Not Addressed: The SunSpec Cybersecurity Certification document primarily focuses on device-level cybersecurity requirements for DER devices. It does not address organizational training and awareness programs for personnel, which are outside the scope of device certification.
Data Security (PR.DS)	Insufficiently Addressed:SunSpec does not explicitly specify requirements for protecting data-at-rest explicitly. It primarily focuses on device-level security and software updates.
Platform Security (PR.PS)	Insufficiently Addressed: SunSpec does not explicitly discuss configuration management practices.
Technology Infrastructure Resilience (PR.IR)	Insufficiently Addressed: The SunSpec documentation does not address protection from environmental threats such as physical damage, natural disasters, or other non-cyber-related environmental risks. The scope is limited to cybersecurity requirements for devices.
Continuous Monitoring (DE.CM)	Insufficiently Addressed: SunSpec focuses on device type testing rather than network monitoring. It ensures that devices communicate securely but does not specify the continuous monitoring of networks themselves.
Adverse Event Analysis (DE.AE)	Not Addressed
Incident Management (RS.MA)	Not Addressed
Incident Analysis (RS.AN)	Insufficiently Addressed: The SunSpec documentation primarily focuses on device-level cybersecurity requirements, such as secure software updates, secure communications, and authentication mechanisms. SunSpec emphasizes the importance of security measures and incident prevention (like software update integrity and secure communications); it does not explicitly detail procedures for incident analysis and root cause determination.
Incident Response Reporting and Communication (RS.CO)	Not Addressed
Incident Mitigation (RS.MI)	Not Addressed
Incident Recovery Plan Execution (RC.RP)	Not Addressed
Incident Recovery Communication (RC.CO)	Not Addressed

summarizes the main findings of the gap analysis based on the NIST CSF for the SunSpec cybersecurity standards.

4.2. Addressing Gaps in SunSpec Standards

Based on the performed analysis of the existing SunSpec cybersecurity standards and the discussion regarding the identified gaps, we conclude with the outcome that it is important to extend the focus of cybersecurity standards beyond device-level security and incorporate organizational-level cybersecurity measures, as identified by the NIST CSF. Based on the above discussion, it is evident that the SunSpec cybersecurity standards mainly emphasize on securing communication among the Distributed Energy Resource devices, the authentication processes, and the software updates. However, we identified that the SunSpec cybersecurity standards lack coverage in areas such as organizational security policies, personnel training, and incident management protocols. One solution to address this gap is to introduce an additional framework that supplements the SunSpec cybersecurity standards by establishing clear guidelines for organizational practices and include policies for cybersecurity awareness training, data management, and recovery procedures in order to ensure that the organizations not only secure the DER devices but also build a robust security culture across all personnel and systems. Another way to address the organizational policies is the extension of the SunSpec cybersecurity standards in order to include broader security management practices, for example, identity and access control management at an organizational level.

Based on the performed gap analysis, we concluded that the SunSpec cybersecurity standards cover authentication between the devices; however, the standards do not specify how the organizations should manage the overall lifecycle of their identities, for example, the employee credentials and the multifactor authentication. One solution to address this gap is the extension of the SunSpec cybersecurity standards or complementing them with existing or new standards in order for the organizations to implement a centralized identity management system, which will ensure secure access across all the devices and personnel regardless of their role. This solution will mitigate the risks that are associated with the unauthorized access, as well as the insider threats and the danger of identity misuse. Based on the performed gap analysis, we also concluded that the SunSpec cybersecurity standards do not include the concept of platform security, especially when this is related to the data-in-use or the data-in-transit. Therefore, a way to strengthen the data security is to integrate additional protocols into the existing SunSpec cybersecurity standards and provide explicit guidance in terms of how the data will be secured at all the stages of their life cycle. This solution can include data segmentation techniques that minimize the exposure of sensitive information complementary to existing encryption methods. Also, another solution could be the adoption of standards that cover incident management and data backup procedures to complement the SunSpec cybersecurity standards in order to ensure that the organizations can swiftly respond to data breaches or system failures and ultimately minimize their downtime but also prevent data corruption or loss. With regard to addressing the hardware life cycle management, which is absent in the SunSpec cybersecurity standards, a solution could be the periodic hardware audits and the establishment of maintenance protocols. Specifically, the organizations can adopt a continuous monitoring approach for the hardware and document-specific procedures in order to manage the replacement, upgrade, or the commissioning of the devices. By incorporating such an approach within the existing SunSpec cybersecurity standards, the hardware vulnerabilities can quickly be identified and resolved, and thus the risk of exploitation due to outdated or compromised equipment will be reduced. Additionally, by adopting the lifecycle management protocols, the resilience of the overall system will be improved in addition to securing the DER devices.

Concluding this analysis, the goal of this survey is to guide the application of the corresponding techniques to highlight the relationship between the identified gaps in the SunSpec Alliance Standards and the relevant frameworks for addressing these gaps. The gap analysis that is performed above has identified the critical areas where the SunSpec standards fall short, particularly in organizational cybersecurity measures, such as training protocols, incident management, and comprehensive identity and access management. By utilizing the NIST Cybersecurity Framework (CSF), the organizations can effectively apply its core functions, i.e., identify, protect, detect, respond, and recover, to these gaps. This structured approach provides a roadmap for organizations to enhance their cybersecurity strategies, and to ensure that both device-level security and broader organizational practices are integrated into their operations. Furthermore, the implementation of additional standards alongside the SunSpec cybersecurity standards can further strengthen an organization’s cybersecurity posture. For instance, adopting protocols for incident response and data management can fill the gaps identified in the SunSpec analysis. By providing explicit guidance on how organizations can implement and manage these protocols, this survey emphasizes the importance of a holistic approach to cybersecurity that not only secures DERs but also fosters a robust security culture across all personnel and systems.

5. Conclusions

In this paper, a detailed survey is presented in relation to the cybersecurity certification requirements as they have been identified by SunSpec Alliance for Distributed Energy Resource devices. The survey is mainly focused on the software updates, the device communications, the authentication mechanisms, the device security, logging, and test procedures as they have been identified by the SunSpec Alliance. The provided discussion also focuses on the remote and automated software updates, the authentication practices, the secure communication protocols, and the logging mechanisms that are adopted based on the SunSpec cybersecurity standards in order to ensure the operational integrity of both DER devices and the overall system. Focusing on the vehicle-to-grid capabilities, the survey analyzes the secure interactions between the electric vehicle supply equipment and the plug-in electric vehicles as they are derived from the implementation of the SAE J3072 standard that utilizes the IEEE 2030.5 protocol. Additionally, their SunSpec Modbus standard is discussed, aiming at enhancing the interoperability among the DER system components and facilitating its compliance with the grid interconnection standards. Moreover, the survey covers existing SunSpec Device Information Models in order to standardize the data exchange formats for the DER systems across different communication interfaces. Finally, a detailed gap analysis is presented in order to identify the gaps that exist within the SunSpec cybersecurity standards, and we introduce potential paths that can be followed in order to address these gaps.