GivEnergy enters administration, batteries expose home networks

TL;DR - A great power storage battery, but with some security fails - Facepalm worthy configuration advice from the manufacturer, now addressed for new installs - Created a backdoor on customer networks, also allowed battery to be made inoperative - The manufacturer has refused to address the issue for existing customers, leaving their home networks and batteries exposed to compromise. - The manufacturer failed to act when the enforcing agency (OPSS) contacted them to ask them to correct their breach of the UK PSTI Act that helps secure IoT - Sadly, the manufacturer collapsed and is now insolvent/in administration, leaving customers including ourselves, wondering about support and warranty - A how-to-fix for non-technical owners is here Introduction In late 2024, we found multiple vulnerabilities in GivEnergy home battery systems that could allow attackers to access customers’ home networks, disrupt battery operation, and potentially violate UK product security regulations. While GivEnergy updated installer guidance for newer deployments, older installations may still be exposed, with no clear remediation plan communicated to customers. Even before the latest news, this was already a story about weak deployment practices and poor local controls. Now it is also a story about legacy risk. GivEnergy Ltd entered administration on 9 April 2026, after filing a notice of intention to appoint administrators on 7 April 2026. That changes the context. The question is no longer just what was wrong, but who will help existing customers review and remediate systems that may still be exposed. If you’re worried you might be affected, particularly if you’ve got an older installation, we’ve outlined the fixes you can apply yourself at the end of this post. Our green journey at PTP has a twist Before we start, we are strong supporters of battery storage. They help balance the power grid, reduce costs, and cut down carbon emissions. At Pen Test Partners (PTP), we run multiple solar PV arrays at our office and use battery storage to capture excess generation rather than exporting and repurchasing power. To do this, we installed GivEnergy All In One 6.0 batteries, which have performed well from an energy and cost perspective. But, as always at PTP, we started poking at them to see how they were connected and deployed. Imagine our surprise when we found a series of vulnerabilities that were virtually identical to findings in another smart product from more than a decade ago! Poking the power bear Here’s one of our batteries, complete with a gateway to allow remote monitoring. The batteries must be installed by a trained professional. GivEnergy insist on that. Fair enough. Hopefully they teach installers to follow good cyber hygiene in their training course? Following a tip from an industry contact, Phil Smith, we noticed that earlier batteries had a Wi-Fi access point. Now, I understand why a battery would need to be a Wi-Fi client, but not also an AP. Sometimes APs on smart devices are reconfigured by clients during setup, but not with GivEnergy, it seems. Earlier batteries had the PSK set as 12345678. That’s a pretty big fail, but this wasn’t the case with ours. A quick Wi-Fi survey showed some interesting SSIDs of ours that looked a bit like this: WK12345G67 They correlated with the serial numbers on the labels on the side of our battery gateways. The PSK wasn’t default, so we either needed to crack or find the key. So we went digging for the installer manuals: https://givenergy.co.uk/wp-content/uploads/WiFi-Dongle-Guide-2024.pdf In section 8, we found this: The installer guidance recommended using the inverter serial number as the password. That is a poor choice because the serial number is also broadcast in the SSID! Talk about metaphorically leaving the key in the lock. That matters because a broadcast serial number is not just visible locally. It can also make devices easier to identify and correlate in public wireless datasets. So, using wigle.net with a query like https://wigle.net/search?ssidlike=WK123xxxx leads us to the GPS location of these batteries and their PSK. Why that matters The weak Wi-Fi setup was only the start of the problem. A quick port scan showed the gateway was exposing multiple local services, including HTTP on port 80 and Telnet on port 23. An API was accessible on 8899 and a Modbus TCP interface was also available! That matters because this was not just a poor password choice. It meant that once someone reached the device, they had direct access to local management interfaces on a product sitting inside the customer’s network. The presence of Telnet was the more serious finding. Telnet has no place being this exposed on a modern connected energy product inside a customer environment. It immediately widened the issue from predictable credentials to exposed local management. Telnet access Digging into the Telnet service showed that the Wi-Fi module was exposing a management interface of its own. A bit of investigation pointed to it being an HF-A21-SMT module from High Flying, an older module with a dated management surface and little in the way of meaningful security controls. More importantly, the command set exposed through Telnet made it possible to interrogate the device and recover useful configuration information, including the Wi-Fi PSK. Sounds familiar? It’s our Wi-Fi kettle attack from 2015 all over again! One could recover the PSK for the home network to which the battery gateway was joined! Arguably this is somewhat worse than the kettle, as the GivEnergy battery is usually connected to the home network. The Wi-Fi kettle required a de-auth attack first, this battery doesn’t. Digging further into the Telnet interface was also interesting. It required a login, but going back to the installer manual, there was no instruction for the installer to change it from the default. admin/admin got us in, unsurprisingly. So, one could have completely screwed up connectivity to the GivEnergy cloud platform. But was there more to be done? Why on earth run an access point in both AP and STA mode? Simply because the mobile app has the facility to work locally as well as via the cloud platform. The mobile device can either talk directly to the battery over Wi-Fi, or the battery can be a client on the home network and talk to the mobile app via the cloud. This causes some complexities, detailed in this handy blog post: https://butnoidea.co.uk/2024/03/05/givenergy-inverter-networking/ Unintentional backdoor into customer home networks There’s another way to recover the customers’ home Wi-Fi PSK too: And even if that isn’t present, the battery gateway contains an RJ45 port. Installation instructions recommend connecting that cable to the customer’s home router using an ethernet cable, if they are physically close. Combine the PSK issue and that cable connection and you now have a backdoor on the customer’s home network. But there’s more…. Killing the battery UI As so often happens in older and cheap IoT modules, they don’t deal well with unexpected traffic. We had the same problem when trying to brute force the PIN on our Wi-Fi kettle – the embedded web server simply fell over when making a lot of requests. The Wi-Fi module in the GivEnergy battery had similar issues – one could hit it hard with a port scan and it would simply fall over. Interestingly, it appeared to go back to factory default settings, creating an interesting attack: a port scan could prevent your battery from working. It would certainly lose useful charge/discharge configs. Taking control There are further services available, including Modbus TCP on port 502 and an API on 8099. Either of these can be used to modify the behaviour of the battery, including forcing it not to charge, rendering it useless. Various open-source projects can make this easier for you, including GivTCP (https://github.com/britkat1980/giv_tcp) and GivEnergy-modbus (https://github.com/dewet22/givenergy-modbus). API fails We didn’t go too hard into the hardware of our devices, as they’re quite expensive and we didn’t want to break them too much! However, we looked at the API to see if it was authorising all requests properly. This request was not properly authorised: GET /internal-api/inverter/data/CH12345678/2024-05-23 HTTP/2 Simply change the serial, and you get someone else’s grid power, voltage, generation, consumption, battery, export etc. We did this between our own two battery accounts but could have accessed anyone’s data if we so wanted. Does this matter? Not particularly. It’s not sensitive data, but it is a surprising omission. Rogue firmware updates Our battery is now out of support, given that GivEnergy has collapsed. We don’t particularly want to render it useless. That said, whilst the firmware appears to be signed, it may be possible to push rogue firmware to it and affect the battery management system. The PSTI Act and Regulations Unfortunately, the installer guidance falls foul of the UK Product Security and Telecommunications Infrastructure Act, world-first set legislation regulating IoT. The PSTI came into effect on 29th April 2024. GivEnergy released the ‘GivInstaller’ app that allows the PSK to be changed to a much stronger, random password. It was released in beta on 27th June 2024. However, the final version was not released until 1st July 2025. This put GivEnergy in breach of the PSTI for at least May and June 2024, but arguably for a year longer than that. The Office for Product Safety and Standards (OPSS) is the regulator responsible for enforcement. GivEnergy was likely in breach of the ‘no default passwords’ requirement of the PSTI. Whether this would apply to the PSK, we’re not certain. It would definitely apply to the embedded web server password though! Regulator enforcement action We got in contact with the UK Office for Product Safety and Standards (OPSS), which is the enforcing agency for the PSTI. They were helpful and contacted GivEnergy to ask for a response. GivEnergy acknowledged the contact from OPSS, but then failed to take action. The latest update I received from OPSS indicated that they were investigating other options for enforcement. GivEnergy collapses But then GivEnergy collapsed into administration. Given that no updates or patches or support is likely to be provided, we’ve published a quick fIx that owners can take themselves. Recommendations For owners of GivEnergy batteries, we strongly recommend changing the Wi-Fi password from ‘12345678’ or the serial number. This can be achieved by downloading the GivInstaller app from the AppStore or Play Store. It’s also possible by connecting to the embedded web server. The web server admin password is likely to be ‘admin’ also, though your installer may have changed it, if they are cyber-aware. Whilst you’re there, it’s also worth changing the embedded web server admin password – this can be found in ‘Device Management’. If you have the ability to segregate your home network, we also advise ensuring your batteries sit on a separate, isolated network subnet. Disclosure timeline Late 2024 – Initial discovery of multiple security issues affecting the GivEnergy All‑In‑One battery and gateway, including predictable Wi‑Fi credentials, exposed local services, and unauthenticated or weakly authenticated control surfaces. 24/12/2024 – Issues reported directly to GivEnergy. Support responded the same day, stating that a new installer app sets a unique 32‑character pseudo‑random Wi‑Fi password and that the issues had already been addressed for newer installations. Dec 2024 – Jan 2025 – Follow‑up questions sent to GivEnergy focusing on legacy installations, changes to installation guidance, and remediation plans for already‑deployed systems. No remediation path was provided. 29/04/2024 – UK Product Security and Telecommunications Infrastructure (PSTI) regulations came fully into force. 27/06/2024 – GivEnergy released an installer app in beta, enabling stronger Wi‑Fi credential generation. Reported uptake was limited due to reliability issues reported by installers. 01/07/2025 – Full release of the installer app. By this point, a significant number of systems had already been installed using earlier guidance. Jan 2026 – Issue raised with the Office for Product Safety and Standards (OPSS), outlining concerns that the installation guidance and lack of remediation for existing customers constituted a potential PSTI breach. Feb – Mar 2026 – OPSS contacted GivEnergy multiple times. GivEnergy acknowledged receipt of correspondence but did not provide a substantive response. 09/04/2026 – GivEnergy Ltd entered administration. No remediation plan for existing installations was received.