Security Architecture

Energy Quotient deployments are designed for environments where data sovereignty, network isolation, and auditability are non-negotiable. This page describes the security architecture across the platform stack.

Network Security

Zero-Trust Mesh Networking

All device-to-device communication uses a certificate-based, zero-trust mesh network built on Nebula (Apache 2.0, proven at scale). Every gateway, sensor node, and administrative device is authenticated by a CA-signed certificate that cryptographically defines its identity and network permissions.

Key properties:

  • Mutual authentication on every connection — no implicit trust based on network location
  • Certificate-based identity — each device has a unique certificate with embedded group memberships and an IP assigned from a private overlay range (100.64.0.0/16)
  • No open inbound ports — gateways initiate outbound UDP connections with NAT traversal; no listening ports exposed to the public internet
  • Cryptographic client isolation — certificate groups enforce network segmentation so one customer’s devices cannot reach another’s
  • Geographically redundant lighthouses — distributed peer discovery with no single point of failure
  • Open-source and auditable — no proprietary VPN components; full source available for review

Firewall

Each gateway runs UFW (Uncomplicated Firewall) with a default-deny incoming policy. Only explicitly allowed traffic is permitted:

PortProtocolServiceAllowed From
22TCPSSHSensor subnet (192.168.10.0/24), VPN overlay (100.64.0.0/16)
80TCPEQ SightConfigurable (default: LAN)

SSH is not accessible from the public internet or the facility LAN unless a site administrator explicitly adds a firewall rule for their subnet. See SSH Access for details.

Intrusion Detection

fail2ban monitors authentication logs and automatically blocks IP addresses after repeated failed login attempts. VPN and sensor subnets are whitelisted since they are already authenticated at the certificate layer.

Physical Isolation

EQ Wave sensors connect to the gateway through plastic optical fiber (100Base-FX), providing complete electrical isolation between monitored power systems and the data network. There is no conductive path between the sensor’s measurement circuits and the gateway or facility LAN.

This two-stage isolation architecture means:

  • Electrical faults on the monitored system cannot propagate to the network
  • The sensor network is physically air-gapped from the facility LAN
  • No routing exists between the sensor subnet (192.168.10.0/24) and the LAN interface

Authentication and Access Control

User Account Model

Each gateway provisions three user accounts with distinct privilege levels:

AccountRoleSSH AccessSudoPurpose
eqadminVendorKey-only (no password)FullRemote support and system maintenance
adminCustomerPasswordScopedSite administration, service management, user management
demoDisplayNone (local console only)NoneKiosk display and local demonstration

SSH Hardening

  • Key-only authentication for vendor accounts (password authentication disabled)
  • AllowUsers directive restricts which accounts can log in via SSH
  • Root login disabled — no direct root SSH access
  • Per-device authorization — vendor SSH keys are baked into the provisioning manifest; no shared credentials across sites

Scoped Sudo

The customer admin account has scoped sudo access limited to:

  • EQ service management (systemctl for EQ services)
  • Firewall rule management (ufw)
  • User and group management
  • Network configuration (nmcli)

Full system-level sudo is reserved for the vendor account.

Data Sovereignty

Local-First Architecture

All waveform data is recorded and stored locally on the gateway by default. No data leaves the site unless explicitly configured:

  • CPOW waveform data is written to local storage (NVMe or microSD depending on platform)
  • Analytics and event detection execute on the gateway — no cloud round-trips required
  • Data export is an explicit action via REST API, Parquet file transfer, or configured rsync
  • Remote support access traverses the encrypted Nebula overlay and can be disabled

Air-Gap Capability

The platform operates with no cloud dependencies. For environments that require it:

  • Gateways function fully without internet connectivity
  • Sensor data collection, storage, and local visualization continue offline
  • Nebula overlay and remote support can be disabled entirely
  • All software updates can be applied via local media

Audit Trail

Three independent audit layers provide traceability:

  1. Certificate identity — which device connected, verified by CA-signed certificate
  2. Authentication logs — who logged in, tracked by SSH and system authentication
  3. Application logs — what was done, recorded by EQ Coherence and system services

All logs are stored locally and accessible to the site administrator.

Supply Chain

  • Nebula (networking): Apache 2.0, open-source, maintained by the Defined Networking team (originally developed at Slack)
  • EQ Coherence (data collection): Rust-based server with deterministic builds
  • EQ Sight (visualization): TypeScript/React frontend served locally
  • SBOM publication and formal supply chain attestation are on the 2026 roadmap

Standards Alignment

The platform’s security architecture draws on principles from these standards and frameworks. Formal certification is on our roadmap; today these reflect design choices, not compliance claims.

  • NIST SP 800-82 — Guide to OT Security (network segmentation, access control, monitoring)
  • IEC 62351 — Power systems communication security (authentication, access control)
  • NERC CIP — Critical infrastructure protection concepts (electronic security perimeters, access management)
  • Zero Trust Architecture (NIST SP 800-207) — No implicit trust; verify every connection

Contact

For security questions, vulnerability reports, or to request documentation for your compliance review, contact [email protected].



© 2026 EQ Systems Inc. • [email protected] • (415) 562–5251 • Updated March 2026