Autonomous Pentesting for energy utilities
Customer portals, charge-point backends and feed-in APIs change with every release. Autonomous Pentesting tests at the same pace: results in 24 hours, with proof for every vulnerability and a retest.
Customer portals · Charge points · § 14a EnWG · NIS2
Autonome Pentests für Energieversorger: Security at the pace of your releases
Our paper for security leads at German energy utilities and Stadtwerke, written in German. How utilities test their portals and APIs at a risk-based cadence, close vulnerabilities faster, and evidence it to supervisors and management.
- Five attack chains in utility portals and how to test them
- Tiering and cadence for a whole portfolio, with a worked example
- Seven requirements for any vendor, and three acceptance tests you run yourself
- Evidence under the German BSIG, EnWG and KRITIS umbrella act, and the first 30 days
Direct downloads, no form. The workbook contains formulas only, no macros. Legal status 8 November 2026; not legal advice.
Where it gets serious for utilities
The request is technically valid and not allowed: session, token and format are correct, but the object does not belong to the caller. Authorisation flaws like these appear anew with every release and touch money, customer data and trust directly.
Meter readings and instalments
Customer B reads or changes customer A's meter reading or monthly instalment, because the contract ID is printed on every bill and the ownership check is missing.
Account takeover via contract linking
When customer number and meter number are the only proof of ownership, the linking endpoint becomes an oracle that unlocks contact details, bank details and password reset.
Charge-point backends
Predictable IDs, displaced connections and implausible meter values in the backend that accepts charge points. Tested in a test tenant, with test charge points or a simulator.
Prosumer, PV and direct-marketer APIs
Tenant separation, role confusion between installer and operator, and value-relevant fields such as capacity and commissioning date.
Controllable devices under § 14a EnWG
Non-existent or duplicate device registrations and deregistering someone else's device: tested against the authorisation model of the portal and API layer, never by sending control commands into a live grid.
The common pattern
A scanner does not know which record belongs to which user. These flaws are found by tests that play several identities against each other and judge the response on its business meaning.
Security at the pace of your releases
The number that matters is the exposure window: how long an exploitable vulnerability stays open and undetected. With an annual pentest that is six months on average; with a test after every release it is a few days plus your fix time.
Results the next day
Your customer portal ships a release, and 24 hours later you have a pentest result for exactly that version, with reproducible proof for every vulnerability.
Authenticated, in several roles
Test customers and staff accounts are played against each other. That surfaces the authorisation flaws scanners miss, because a scanner does not know which record belongs to whom.
Retest after the fix
The retest repeats exactly the proven request and confirms the hole is closed. Remediation is measured, not assumed.
Limits you set
For every address you decide whether vulnerabilities are only confirmed or also exploited, and you can stop a running test yourself at any time.
Evidence for supervisors and management
German law prescribes no fixed test cadence: you set it yourself and justify it from your risk analysis. Pentest reports with retests provide concrete technical evidence for the applications tested. Our reading of the statutory text as of 8 November 2026, not legal advice.
BSIG after NIS2 transposition
Since 6 December 2025, § 30 BSIG requires appropriate, proportionate and effective measures and their documentation, explicitly including vulnerability management and procedures to assess effectiveness. Management implements and oversees them (§ 38 BSIG).
EnWG §§ 5c to 5e
Grid and plant operators fall under §§ 5c to 5e EnWG; § 5d requires documentation towards the Federal Network Agency. A utility with grid, retail and charging infrastructure can sit under different regimes per activity.
Cadence, depth, evidence
A programme is three written decisions: cadence from the rate of change, depth from the impact, evidence from vulnerability, proof, deadline and retest.
From the blog (in German)
Valid request, wrong sender: five attack chains in utility portals that scanners miss, and the one test method that covers all five.
Frequently asked questions
Attackers often reach OT through IT: portals, remote-maintenance access, web interfaces and APIs that pass data or commands on to control systems. Those are the paths SQUR tests: customer portals and apps, charge-point backends, interfaces for feed-in producers and direct marketers, portals for controllable consumer devices, and the web interfaces of OT components, preferably in a test environment. In the first call we agree with your OT security team which systems belong in the test.
For every address you decide whether vulnerabilities are only confirmed or also exploited, and you can stop a running test yourself at any time. Write tests touch only your test objects. We show you how scope enforcement, stopping and logging work in a technical review.
An owner for the application, the operator's approval, a test environment with an allow-list and a verified stop path, and two test customers plus one staff account with test contracts. In our experience this takes a few days.
No. The paper, the checklist and the workbook are direct downloads, with no form and no email address. All three are in German.
Start with one application
Typically the customer portal or its API. We set up the first run with you in a short call.