The Security Stakes in Electric Utility OT
Electric utility operational technology networks are, by design, among the most isolated and carefully controlled computing environments in existence. The reasons are obvious: a successful intrusion into a utility's OT network does not result in stolen customer records. It results in the potential to cause physical damage to grid infrastructure, trigger outages affecting millions of people, or in extreme cases, contribute to cascading failures with national security implications.
This is the security environment that HOP Sensors must operate within — or, more precisely, alongside. The question every utility security team asks when they evaluate a third-party platform that touches their OT data is: what is the attack surface you are introducing, and how do you manage it?
This document answers that question in full.
Our Threat Model
We model threats across three categories that are relevant to a cloud-connected SCADA observability platform.
| Threat Category | Specific Threats Modeled | Primary Mitigations |
|---|---|---|
| OT Network Intrusion via Edge Component | Compromised edge connector used as pivot into OT network; malicious firmware update injected through update channel; edge component used to issue control commands to field devices | Read-only protocol bindings; outbound-only network connections; signed update packages with TPM attestation; no inbound listeners on edge process |
| Data Interception in Transit | Telemetry stream intercepted in transit between OT environment and cloud; man-in-the-middle attack on TLS channel; replay attacks using captured telemetry frames | TLS 1.3 with certificate pinning; mutual TLS authentication; per-session nonces in telemetry frames; transport layer monitored for anomalous patterns |
| Cloud Platform Compromise | Unauthorized access to stored telemetry data; lateral movement from compromised cloud tenant; insider threat accessing sensitive utility operational data | Per-utility data isolation at storage layer; role-based access control with least-privilege enforcement; comprehensive audit logging; SOC 2 Type II controls |
| Supply Chain Attacks | Compromised third-party dependency in edge or cloud software; malicious package introduced through CI/CD pipeline | Software bill of materials (SBOM) maintained for all components; dependency integrity verified via hash pinning; edge binary signed and TPM-verified on deployment |
The Edge Component Security Model
The edge connector — the process that runs within or adjacent to the utility's OT environment — is the highest-consequence component in our security architecture. Everything about its design is oriented around one principle: it should be impossible for a compromised edge connector to cause harm to the OT environment it observes.
Read-Only Protocol Bindings
The edge connector connects to SCADA devices using read-only protocol operations. For Modbus, it issues FC03 (Read Holding Registers) and FC04 (Read Input Registers) only — write function codes are not implemented in the codebase. For DNP3, it operates as a master in read-only mode, with no outstation control capability compiled in. This is not a configuration option — it is a hard architectural constraint. A compromised edge connector cannot issue commands to field devices because the code to do so does not exist in the binary.
Outbound-Only Network Architecture
The edge connector maintains no inbound network listeners. It makes outbound connections only — to a fixed set of cloud endpoints, identified by certificate fingerprint rather than hostname. There is no management interface, no SSH listener, no API endpoint on the edge process. An attacker who compromises the network segment where the edge connector runs cannot reach it over the network; they would require local access to the host itself.
Mutual TLS Authentication
Every connection from the edge connector to the cloud ingestion service uses mutual TLS — both sides present certificates, and both sides verify the other's certificate against a pinned CA. Edge certificates are provisioned per-deployment, per-utility, and rotated on a 90-day cycle. A certificate compromise affects a single edge deployment and cannot be used to impersonate other utilities or access other tenants' data.
Unidirectional Gateway Compatibility
For utilities operating hardware data diodes or unidirectional security gateways on the IT/OT boundary, we support a split deployment model: the edge connector runs entirely within the OT network and writes to a local buffer. A separate forwarder process, running in the IT network on the other side of the gateway, reads from that buffer and handles the cloud connection. The OT-facing component never makes external network connections in this configuration.
Cloud-Side Data Isolation
In the cloud, each utility's data is isolated at the storage layer — not just at the application layer. Telemetry data is written to per-tenant namespaces in the time-series store, with access controls enforced at the storage level rather than relying solely on application-layer authentication. A bug in the application layer that bypasses authentication checks cannot expose one tenant's data to another, because the storage-level isolation prevents cross-tenant reads.
Role-based access control within each utility tenant follows a least-privilege model. Operator accounts can read telemetry and acknowledge alerts. Administrator accounts can manage alert routing and user access. No account type has write access to historical telemetry — the audit trail is append-only and cannot be modified after the fact, including by platform administrators.
Compliance Posture
HOP Sensors is being built toward SOC 2 Type II certification, with controls organized around the Trust Services Criteria for security, availability, and confidentiality. For utility customers with NERC CIP obligations, we provide documentation to support the vendor management and electronic access control requirements relevant to third-party software that interfaces with BES Cyber Systems.
We are not NERC CIP certified — that designation applies to utilities and bulk electric system operators, not to software vendors. What we provide is a platform architecture and documentation package that is designed to survive the security review of a utility's compliance and security teams, including the specific questions that NERC CIP auditors ask about third-party system access.
What We Ask of Your Security Team
We expect and welcome rigorous security review. Every utility we work with will have a security team with their own requirements, their own review process, and their own risk tolerance. We treat that review as a collaboration, not an obstacle.
What we ask is the opportunity to walk your security engineers through the architecture in detail — not just this document, but the actual code, the network diagrams, the certificate management procedures, and the incident response plan. We believe that transparency is the right security posture for a vendor operating in critical infrastructure, and we are prepared to provide the level of documentation and access that serious security reviews require.
If you are a utility security engineer evaluating HOP Sensors, reach out directly. We will set up a technical session with our security architecture team, not a sales call.