When your software interacts with DER hardware through vendor APIs, it accumulates credentials: OAuth access tokens and refresh tokens for cloud-connected devices, API keys for monitoring platforms, client certificates for OCPP and IEEE 2030.5 connections. How you handle those credentials is not a detail you can defer to a later sprint. The security architecture you choose shapes the risk profile of your application for its entire lifetime.
This piece covers the threat model for energy API credentials, the architectural patterns for managing them securely, and the specific considerations that are different for DER applications compared to typical web services.
Why energy credentials are higher-risk than typical API keys
Not all API credentials carry the same risk. A compromised API key for a social media analytics service is an embarrassment and a billing headache. A compromised credential for a DER control API is a different category of problem.
DER APIs give software the ability to change the physical state of grid-connected hardware: curtail a solar array's output, command a battery to discharge, change an EV charger's maximum current, push a thermostat setpoint. A credential that grants write access to these capabilities, in an adversary's hands, is an operational control over physical energy infrastructure. That threat profile demands a security model that treats credentials as critical infrastructure, not application configuration.
The energy sector context compounds the risk. DER deployments in demand response programs are increasingly coordinated at scale — virtual power plants aggregating hundreds of megawatts across thousands of devices. Credentials that grant control over a large VPP fleet are a meaningful attack surface, not just for financial fraud but for grid reliability.
The credential types you are managing
A typical DER software platform accumulates several distinct credential types, each with different characteristics:
| Type | Examples | Expiry | Risk on compromise |
|---|---|---|---|
| Long-lived API keys | SolarEdge, Enphase production keys | Typically no expiry | Persistent monitoring access |
| OAuth access tokens | Enphase OAuth, Tesla Fleet API | Hours to days | Limited window, auto-rotates |
| OAuth refresh tokens | Same vendors as above | Months to indefinite | Can regenerate access tokens continuously |
| Client certificates | OCPP TLS, IEEE 2030.5 | Typically 1-3 years | Protocol-level impersonation |
| Device credentials | OCPP charger passwords, Modbus keys | No expiry until rotated | Direct device control |
Refresh tokens deserve particular attention. An access token that expires in one hour is relatively low risk if compromised — the window for misuse is limited. A refresh token that can generate new access tokens indefinitely is a persistent backdoor unless the compromised refresh token is explicitly revoked at the vendor level.
The vault architecture
A credential vault is the architectural pattern for managing API credentials securely. The core principle: application code should never hold vendor credentials directly. Instead, credentials are stored in a dedicated vault service, and application code holds only an identifier that it uses to request the credential from the vault at the moment it is needed.
The minimal vault implementation has four components:
- Encrypted storage — Credentials at rest are encrypted using a key that is not stored alongside the data. AES-256 is standard. The encryption key itself should be managed by a hardware security module (HSM) or a managed KMS service (AWS KMS, Google Cloud KMS, HashiCorp Vault).
- Access control — Each application component gets access to only the credentials it needs. A component that reads solar telemetry should not have access to the EV charger control credentials.
- Audit logging — Every credential access is logged: which component requested it, at what time, for which device. This log is the forensic trail if a compromise occurs.
- Token rotation — The vault handles OAuth token refresh automatically. Application code never needs to see the refresh token; it requests an access token from the vault, and the vault refreshes it if needed before returning it.
The application code boundary
The most important security boundary in this architecture is the one between application code and the vault. Application code should receive credentials only in memory, only at the moment of use, and should never write them to logs, error messages, or persistent state.
This sounds obvious, but in our experience it is violated frequently in development environments. A developer adds a debug log statement that prints the full request context, including authorization headers. That log statement makes it into a staging environment, then accidentally into production. Credentials that should be invisible to logging infrastructure are now in a log aggregation service.
Log scrubbing — automatically redacting strings that match credential patterns from log output — is a useful defense-in-depth measure. But it is not a substitute for never writing credentials to logs in the first place.
Treat any code path that accepts a credential as a credential sink. Review those paths explicitly in security review. Credentials that are correctly managed 99% of the time and leak 1% of the time offer weak security guarantees.
Revocation and incident response
A credential vault is only part of the security picture. The other part is having a clear process for revocation when a compromise occurs — or when a team member with credential access leaves the organization.
For each vendor API your application uses, you should have a documented revocation procedure: how to invalidate the current credential, how to generate a new one, and how to update the vault without downtime. For OAuth 2.0 vendors, this means the ability to revoke the refresh token at the vendor level. For API key vendors, it means the ability to generate a new key and update the vault atomically.
Mean time to revoke is a useful metric. If you cannot revoke all credentials for a specific vendor and update your application within one hour of detecting a compromise, your incident response capability is too slow for the risk profile of DER control software. Measure it before you need it.
The energy software sector is building the infrastructure that will manage hundreds of gigawatts of flexible grid resources. The credential security model you implement now will be load-bearing infrastructure for years. Build it with that permanence in mind.
