16. Security¶

Security is fundamental to the GEISA specification, so much so that it is included in the name itself: Grid Edge Interoperability and Security Alliance. This specification was developed with prevailing security and privacy design principles in mind, such as NIST 800-53, CCPA and NERC CIP standards, and enables implementers to incorporate security controls appropriate to their operational contexts and needs.

Security in GEISA exists to enable trusted interoperability across independently developed hardware, software, and operational domains without requiring a single vendor-controlled platform. It is designed to allow applications from different vendors to co-exist, to allow utilities to trust in portable secure workloads and/or edge applications, and allows for interoperability without shared implementations, while allowing the Utility or Operator to dictate their specific policies and standards.

GEISA is intended to support multi-vendor application ecosystems across heterogeneous hardware platforms, and is designed to support deployment across utilities and operators with differing regulatory obligations, risk tolerances, and operational practices. Accordingly, the specification separates capability definition from policy enforcement.

The Common Operating Environment (COE) provides mechanisms that enable security, privacy, and operational policies to be configured by the deploying utility or operator. GEISA does not mandate uniform policy settings, nor should implementations hard-code assumptions about allowable access, connectivity, or application behavior.

The COE is not a single software component or runtime environment. It is the logical collection of execution environments, system services, control interfaces, policy enforcement mechanisms, and lifecycle management functions defined by GEISA that together provide a governed platform for applications at the grid edge.

The COE may include one or more execution environments (e.g. native Linux or virtual runtimes), but is defined by the security, isolation, authorization, and operational controls it enforces rather than by any specific implementation technology.

This approach ensures that:

Utilities and operators retain authority over what functionality is enabled.
Policy decisions may be adapted to local regulatory or operational needs as required.
Interoperability across vendors (hardware and software as applicable) is maintained without constraining governance.

Implementations shall expose the configuration and control interfaces necessary for operator-defined policy to govern behavior within the COE.

The following are the minimum criteria needed for success of the GEISA specification and for the implementor.

Clear expectations must be illustrated outlining what responsibilities fall to the GEISA team vs the entities or individuals implementing the specification. This will be referred to as the “Shared Responsibility Model”.
The specification must enable implementers to comply with applicable standards, frameworks, certifications, or regulatory requirements.

16.1. Responsibilities¶

16.1.1. Shared Responsibility Model¶

GEISA cannot feasibly account for every implementer’s operational context, architecture, governance model, policy requirement, or business process. Accordingly, responsibilities are divided between GEISA and those entities implementing or operating solutions based on the specification.

The GEISA specification is architected according to established security design principles; however, as a specification it defines required capabilities and interfaces rather than prescribing specific implementations. It provides the mechanisms and flexibility needed for implementers and operators to apply their own policies, controls, and technology choices appropriate to their environment.

GEISA is therefore not responsible for the final design, implementation, or operation of security controls within a specific implementation or deployment. The specification is not tailored to implementation-specific requirements and does not mandate particular components, libraries, or platforms. It is intentionally implementation-agnostic so that conformant solutions may adapt to evolving technologies, regulatory landscapes, and operational priorities while maintaining interoperability.

GEISA also recognizes that Implementers and Operators adopting the specification may have varying definitions of data classification and policy statements surrounding those classifications. The specification is designed to allow for the application of policy and controls appropriate to a variety of needs and requirements. As such, it and does not mandate specific classifications or associated controls. Instead, GEISA makes capabilities available to Implementers and Operators such that they may apply their own classifications and controls as needed to meet their requirements.

16.1.2. GEISA Responsibilities¶

Making available to an implementer a baseline specification for a Common Operating Environment(COE) with levers needed to provide the implementer the ability to meet their applicable security and privacy requirements.
Identifying the minimum system requirements in order to run the GEISA specification and testing against those system requirements to prove out a reference implementation in support of implementers.
Implementing processes to ensure that contributions to the GEISA specification are properly vetted and carried out by individuals free of malicious intent.
Defining and maintaining a baseline Threat Model to identify risks, and where deemed appropriate, aligning system design to either mitigate those risks or allow for mitigation of those risks by an implementer using mechanisms available within the COE.

16.1.3. Implementer Responsibilities¶

You as the implementer are best suited and equipped to understand the architecture and environment that you are implementing within, the parties involved, additional/specific policy requirements and risk appetites, etc. and, as such, the following responsibilities have been identified:

Responsible for:

Identifying the applicable laws, regulations, required security and privacy controls or other security and privacy-oriented requirements that individual specific entities must satisfy, assessing the GEISA specification for suitability to meet those requirements, and then implementing those requirements.
Identifying the underlying hardware, choosing a compatible operating system they wish to use and at their discretion any additional software or system services deemed necessary beyond what is defined in the GEISA specification.
Once implemented, keeping the operating system and any other software current with updates as they are released to fix published bugs, defects, vulnerabilities, etc.
Defining their own shared responsibility model with any third parties that they may allow to access or provide components to the architecture they implement inclusive of the GEISA specification. This may include but is not limited to first or third-party application developers, system operators, etc.
Defining and maintaining a threat model, which may take into account the GEISA baseline threat model, and identifying applicable risks as well as any appropriate action(s) required in order to mitigate those risks.
Ensuring achievement of any/all implementation-specific control requirements spanning any/all relevant Security and Privacy domains.
The GEISA specification may assist the implementer with achieving certain baseline implementation requirements but it is not responsible for the final design, implementation and/or operation of controls defined by the implementer nor is the GEISA specification required to meet implementation-specific requirements.

The following threat model establishes the risk framework used to derive the security capability expectations defined by this specification.

16.2. Threat Model¶

The GEISA threat model identifies the assets requiring protection, the trust boundaries across which the GEISA Common Operating Environment (COE) operates, and representative threat scenarios that conformant implementations should be designed to mitigate. It is not exhaustive and is intended to be a living framework that evolves alongside the threat landscape. It provides implementers with a baseline set of threats to consider when evaluating their specific implementations.

Implementers SHOULD extend this model to reflect their operational context, inclusive of, but not limited to, their deployment, regulatory, and operational environments and identify additional threats applicable to their specific circumstances.

Unlike traditional IT systems, compromise of grid-edge devices and resources may create direct reliability impacts to the electrical grid or to individual service locations. Therefore, prioritizing a defense-in-depth approach is essential. Additionally, the potential for physical access to grid-edge devices creates a need for robust physical security controls and/or tamper resistance.

The GEISA specification is designed to enable implementers to meet these needs through the design of the COE and the control levers it provides to enforce deployment-specific security policy.

16.2.1. Software Provenance and Deployment Authorization¶

GEISA deployments rely on verifiable software provenance and explicit operator authorization. Trust decisions may involve multiple independent signing or credential authorities, including application providers, utilities/operators, and, where implemented, device or platform providers.

The following roles are referenced in this section:

Application Publisher: the entity responsible for producing, signing, and asserting provenance of an application or workload artifact.
Device/Platform Provider: the entity responsible for the hardware or platform on which the COE executes, when such identity is represented.

Note

Review whether the PKI governance language below reflects current consensus regarding operator authority and interoperability. In particular, hw impact and compute needed for the more frequent validation checks.

GEISA does not mandate a specific PKI hierarchy; however, cryptographic identity, signing, and validation are REQUIRED capabilities.

Implementations shall be capable of interoperating with operator-selected utility, vendor, or industry PKI systems. Conformant implementations shall not require exclusive use of a proprietary trust infrastructure controlled solely by the implementer.

The utility or operator retains final authority over trust anchors, certificate hierarchies, and approval of credential authorities.

Conformant implementations shall support operator-selected trust anchors and credential authorities and shall not constrain the operator to a single implementer-controlled trust infrastructure.

Support for operator-selected trust configurations shall be provided in a manner that preserves the verification and enforcement capabilities described herein.

Conformant implementations must provide mechanisms enabling:

Validation of application provenance (e.g., verification that an application artifact corresponds to the bits produced by an identified vendor or publisher).
Validation of operator authorization prior to deployment or activation (e.g., the utility/operator explicitly approves whether a given application is permitted in a target environment, device class, or operational mode).
Verification of authenticity and authorization in both:
- application lifecycle workflows (e.g., package intake, cataloging, approval, deployment orchestration), and
- on-device enforcement prior to install, activation, or execution within the COE.
Support for both centralized deployment orchestration and authorized local provisioning workflows (e.g., field tool installation by authorized personnel).

Device or platform identity mechanisms (e.g., hardware vendor certificates or attestation) may be used to strengthen trust in the executing environment. GEISA does not mandate such mechanisms; however, if implemented they must integrate with the above validation and enforcement model.

Validation performed by centralized or upstream lifecycle management systems shall not be considered sufficient on its own. The COE must enforce verification of software authenticity and authorization locally on the device prior to installation, activation, or execution. This ensures that software running within the COE is trustworthy even in the event of compromised upstream systems or supply chain attacks that may attempt to introduce unauthorized or malicious software.

The COE is the final technical enforcement point on the device itself. Operational authority remains with the utility/operator (or delegated operational systems) that define policy and authorization; the COE ensures those decisions are enforced locally and cannot be bypassed by external systems. External lifecycle or orchestration systems may request deployment actions, but shall not be able to bypass local verification, authorization, or policy enforcement.

16.2.2. Lifecycle Trust Enforcement¶

Trust within GEISA is not established at a single point in time. It is evaluated and enforced across multiple lifecycle transitions, including application ingest, approval, deployment, installation, activation, and execution.

Conformant implementations must ensure that trust assertions made by one system or phase are independently verified at the point where enforcement occurs. Trust shall not be implicitly inherited across lifecycle boundaries without validation.

This includes, but is not limited to:

Verification of application integrity and publisher identity when software is introduced into lifecycle management systems.
Confirmation of operator authorization prior to deployment to a device or environment.
Independent validation performed by the COE prior to installation and at activation (including restarts of applications and/or workloads).

Note

Need to discuss execution/runtime or periodic validations.
Continued enforcement of policy, identity, and behavioral constraints during runtime operation.
Runtime enforcement of operator-defined behavioral constraints, including the ability to detect, limit, or terminate workloads that violate policy or exceed authorized resource or communication profiles.
Revocation of trust relationships when software is no longer authorized for execution within the COE (e.g. due to compromise, policy change, or end of life).

This model ensures that compromise of any single lifecycle component does not result in implicit trust of software or actions elsewhere in the system and helps to mitigate risks resulting in systemic compromise.

16.2.3. Trust Revocation and Credential Lifecycle¶

Note

definitely needs review:

GEISA defines mechanisms (revocation, update, policy change), but the operator or implementer is responsible for monitoring, initiating, and governing these actions. GEISA-compliant implementations and deployments must support the ability to modify or withdraw previously established trust relationships throughout the operational lifecycle of a device or application.

Conformant implementations shall provide mechanisms enabling:

Revocation or invalidation of application, publisher, operator, or device credentials when trust can no longer be assured.
Enforcement of operator-directed actions to disable, restrict, or remove software that is no longer authorized for execution within the COE.
Update and rotation of trust anchors, certificates, and associated cryptographic material without requiring replacement of deployed devices.
Local enforcement of revocation or policy changes even in environments with limited or intermittent connectivity to centralized management systems.

These capabilities ensure that trust established during provisioning or deployment can be continuously evaluated and adjusted in response to evolving security conditions, operational decisions, or cryptographic requirements.

16.2.4. Assets Requiring Protection¶

The GEISA specification is designed to protect the following asset classes:

Integrity of grid-impacting control functions (e.g., service disconnect, DER coordination, or other local controls)
Authenticity and integrity of telemetry, metrology, and status data
Device identity and associated cryptographic credentials
Availability of edge execution environments necessary for safe grid operation
Application and Application Publisher identity as represented by associated credentials
Isolation between workloads executing within the COE
Application and device monitoring, behavioral logging, and alerting capabilities
Customer data subject to privacy and/or regulatory protection
Trust relationships with utility/operator systems
Software and firmware integrity across the device lifecycle

16.2.5. Trust Boundaries and External Interfaces¶

The GEISA Execution Environment operates across multiple security trust boundaries. A trust boundary exists wherever administrative control, execution privilege, or assurance level changes.

GEISA defines these boundaries to enable secure interoperability among heterogeneous vendor solutions while preserving the operator’s ability to enforce deployment-specific policy. The GEISA Common Operating Environment (COE) acts as the on-device enforcement point through which operators may permit, restrict, or condition interactions between applications, networks, and connected systems.

These enforcement functions exist regardless of whether applications execute locally, participate in hybrid edge/cloud workflows, or are installed through centralized lifecycle management systems.

All interactions crossing these boundaries shall be treated as untrusted unless explicitly authenticated, authorized, and governed by operator-defined policy. The boundaries listed below represent the primary attack surfaces considered by this model. They are not exhaustive. Implementers shall evaluate their deployment to determine whether additional boundaries are present.

Note that examples are illustrative and do not define required sensor types or configurations.

Boundary	Description	Examples
Field Devices	Physically accessible deployment environment where attackers may gain hardware access. This includes attempts to tamper with the device, extract sensitive material, or conduct side-channel to observe, influence, or bypass normal system protections.	Enclosure access, debug ports
Local Provisioning / Maintenance	Interfaces used during installation or maintenance that may introduce temporary elevated trust.	Field tools, Bluetooth, serial
Sensors	Data originating from instrumentation whose acquisition and integrity are governed by the COE device itself.	Metrology, temperature, accelerometer, GNSS, other directly-attached sensors
Customer Networks	Communications over networks not managed by the utility/operator and therefore not inherently trusted.	Home/Business Wi-Fi, HAN, LAN, Thread
Workload (e.g. Applications)	Separation between the COE platform and hosted workloads enabling operator control over resource and network access. This boundary exists even when all code is local due to multi-tenancy, privilege separation, and differing lifecycles.	GEISA COE APIs, resource allocation, storage, permission models
External Device / Control	Interfaces to autonomous systems not governed by GEISA lifecycle or assurance controls. Includes third-party devices or subsystems that may have grid or local impact if compromised.	Inverters, Matter devices, thermostats, gateways, controllable loads, local data sources
Operational Integration	Exchange of operational data with upstream systems, including utility or non-utility infrastructure outside the COE trust domain.	AMI backhaul, DERMS, analytics platforms, monitoring systems, hybrid edge/cloud applications
Lifecycle Management	Authority to deploy, configure, approve, restrict, update, or revoke software and policy governing the COE.	Application deployment, update orchestration, policy/config distribution

Utility-operated networks and systems are considered external to the COE trust domain and are therefore modeled within the Operational Integration or Lifecycle Management boundaries depending on function.

Devices communicating via customer-managed ecosystems (e.g., Wi-Fi, Thread, Matter, or similar technologies) are not considered part of the Sensor Boundary, even when providing measurement data. Such devices operate with independent identity, firmware, and lifecycle control and are therefore treated as External Devices whose communications traverse the Customer Network Boundary.

16.2.6. Threat Actors Considered¶

The GEISA threat model considers a range of potential threat actors with varying levels of access, capability, and intent. These actors may operate independently or in coordination and may target individual devices, aggregated infrastructure, or upstream systems.

The following categories are considered within scope:

Threat Actor	Description
Supply Chain Adversary	Actor seeking to introduce malicious components, firmware, or updates during manufacturing or distribution stages.
Field-Level Physical Attacker	Actor with physical access capable of tampering, extraction, or hardware manipulation to disrupt operation, alter executable code outside authorized lifecycle processes, or obtain data from the device. This may include invasive techniques (e.g., device/chip decapsulation (“decap”), probing, or unauthorized reflashing) intended to bypass protections.
Opportunistic Local Network Attacker	Actor on a customer or shared network capable of interception, manipulation, or disruption of communications or operations.
Unauthorized Local Service Actor	Individual attempting access via provisioning or maintenance interfaces using unauthorized or stolen tools or credentials.
Remote Adversary	External attacker using network access to exploit exposed services, protocols, or integrations.
Coordinated Distributed Actor	Group or automated campaign capable of influencing behavior across many endpoints.
Compromised Upstream System	Trusted operational or management system issuing valid-looking but malicious actions after being compromised.
Compromised External Device	Third-party or customer-managed device providing malicious data or attempting lateral influence on the COE.
Malicious or Negligent Insider	Individual with authorized access who may misuse privileges, attempt escalation, alter policy, or exfiltrate information, either intentionally or unintentionally.

16.2.7. Representative Threat Scenarios¶

The following scenarios illustrate representative ways in which identified threat actors may attempt to exploit trust boundaries to impact protected assets. These examples are not exhaustive but demonstrate the types of risks implementations should be designed to address.

Implementations SHOULD address these risks using deployment-specific controls, policies, and technologies consistent with the capabilities defined by the GEISA specification.

16.2.8. Unauthorized Use of Local Service Interfaces¶

An Unauthorized Local Service Actor connects to provisioning or maintenance interfaces using stolen credentials or unauthorized tools to modify configuration, deploy software, or alter policy.

Boundaries Involved: Local Provisioning / Maintenance, Lifecycle Management
Potential Impact: Unauthorized deployment, policy manipulation, integrity loss, or unauthorized access to sensitive configuration or data.

16.2.9. Compromise of a Customer-Network Connected Device¶

A Compromised External Device (e.g., Matter or Wi-Fi system) provides falsified telemetry or malformed data intended to influence processing performed locally or by upstream systems participating in hybrid workflows.

Boundaries Involved: External Device / Control, Customer Networks
Potential Impact: Corrupted data, unintended control actions, incorrect operational conclusions, or propagation of misleading information into coordinated services.

16.2.10. Malicious or Altered Software Introduced During Update¶

A Supply Chain Adversary inserts malicious code into firmware, applications, or update packages prior to deployment.

Boundaries Involved: Lifecycle Management
Potential Impact: Persistent compromise, unauthorized control, data exposure, or loss of software and device integrity across the lifecycle.

16.2.11. Remote Exploitation of Exposed Services¶

A Remote Adversary targets reachable services or protocols to gain unauthorized access, manipulate data, or disrupt availability.

Boundaries Involved: Operational Integration
Potential Impact: Loss of availability, unauthorized command execution, unintended control actions, or compromise of data privacy.

16.2.12. Insider Abuse of Authorized Privileges¶

A Malicious or Negligent Insider misuses authorized access to escalate privileges, alter logging or policy, access sensitive data, or deploy unauthorized workloads.

Boundaries Involved: Workload Boundary, Lifecycle Management
Potential Impact: Policy bypass, unauthorized data access, compromise of data privacy, undetected system changes, or loss of operational integrity.

16.2.13. Coordinated Manipulation Across Multiple Devices¶

A Coordinated Distributed Actor attempts to influence many endpoints simultaneously to create aggregate operational impact or to collect or manipulate data at scale.

Boundaries Involved: Operational Integration
Potential Impact: Grid instability, synchronized disruption, large-scale data exposure, or propagation of misleading information into upstream systems.

The following capability expectations describe the security functions that implementations must be able to realize in order to address the risks identified in this threat model.

16.3. Interpretation of Conformance¶

The threat model is informative and provides context for required capabilities; it does not prescribe specific mitigations or implementation techniques.

GEISA conformance is evaluated based on the ability of an implementation to demonstrate the security capabilities and enforcement behaviors defined by this specification, rather than on the use of any specific technology, framework, or software component.

Conformance testing may exercise defined interfaces, workflows, and operational scenarios to validate that required security properties—such as identity verification, authorization enforcement, workload isolation, integrity protection, and policy governance—are correctly realized.

Implementations may use differing operating systems, execution environments, cryptographic libraries, or architectural approaches, provided that the required behaviors and outcomes are achieved and are externally verifiable through defined interactions.

Where minimum versions or technical baselines are referenced, they shall relate to interoperable standards, protocols, or security capabilities and shall not mandate specific vendor products, libraries, or implementation frameworks.

16.4. Security Capability Expectations¶

To address the risks identified in this threat model, conformant implementations must realize these capabilities within the COE, which serves as the enforcement layer for application behavior, resource governance, and authorized interaction with connected systems while ensuring that operators retain control of the ability to set and enforce policy, protect system integrity, and maintain trust relationships across defined trust boundaries.

The GEISA specification defines the security outcomes that must be achievable, but does not prescribe specific technologies or implementation approaches.

16.4.1. Identity and Authentication¶

Implementations shall support verifiable identity for:

Devices or platforms (e.g., meters, NICs, or other edge hardware), hereafter referred to as the Device/Platform Provider where such identity is supplied by the hardware or platform manufacturer.
Applications and associated software artifacts produced by an Application Publisher (the entity responsible for creating and signing an application or workload).
External systems interacting across trust boundaries.

These identities establish provenance, accountability, and authorization context for software deployment and operation within the COE.

Such identities may represent organizational provenance used to establish trust in software origin and authorization for deployment within the COE.

Identity mechanisms must protect associated credential material from unauthorized extraction, duplication, or misuse and support secure lifecycle management of those credentials.

16.4.2. Authorization and Policy Enforcement¶

The COE must enable operator-defined policy controlling application execution, resource access, and permitted interactions across networks and systems.

16.4.3. Integrity Protection¶

Implementations must protect software, configuration, and operational data from unauthorized modification.

16.4.4. Isolation of Workloads¶

The COE shall provide isolation sufficient to prevent privilege escalation or cross-application interference.

16.4.5. Secure Lifecycle Management¶

Implementations must support secure deployment, update, validation, and removal of software throughout the device lifecycle.

16.4.6. Protection of Data¶

Implementations shall protect sensitive data from unauthorized disclosure or manipulation when stored or transmitted across trust boundaries.

16.4.7. Auditability and Visibility¶

The COE shall enable logging and monitoring sufficient to detect unauthorized activity and support operational accountability.

16.4.8. Resilience and Availability¶

Security mechanisms shall support continued safe operation and policy enforcement under degraded connectivity conditions.

These capabilities are intended to enable interoperable yet independently governed deployments across diverse utility environments.