EV Charging Data & Firmware Risk Report 2026

Introduction

EV charging is infrastructure at scale: the IEA counts more than 7 million public charging points worldwide at the end of 2025, with nearly 1.8 million added that year, a rise of more than a third¹. Its published security record is growing too, and most of that record concerns the charger itself or the backend, the Charging Station Management System (CSMS), it talks to over the Open Charge Point Protocol (OCPP). This report looks at a layer that sits beside both: the file services that deliver firmware to chargers and collect their diagnostic logs.

Security attention in EV charging and distributed energy concentrates on two things: the charger as a device, and the CSMS that manages it. Both are hardened as if they were the whole system, while the file services beside them fall outside that frame. That blind spot holds real material. A file service stores firmware, and it collects the diagnostic bundles chargers upload, which carry authentication secrets alongside identifiers tied to vehicles and drivers: vehicle identification numbers, charging-contract IDs and RFID tags. Their files also carry download links to customer billing receipts kept in cloud storage that anyone with the link can fetch without logging in. Where such data identifies a person it is personal data under the EU GDPR, so what is overlooked here is both a security exposure and a privacy one.

OCPP carries commands, not files. To update a charger or collect its logs, the CSMS sends a command that contains a location: UpdateFirmware, and GetDiagnostics in OCPP 1.6 or GetLog in OCPP 2.0.1. The charger then opens a separate connection to a file service and downloads the firmware or uploads its log bundle. OCPP names HTTP, HTTPS, FTP, FTPS, and SFTP for this transfer, and the location it describes can carry a user name and password in the URL.

One term recurs throughout this report. A file service is a file-transfer endpoint reached over FTP(S), SFTP or HTTP(S) to upload or download files, run by one operator or vendor; one of those examined is an object-storage bucket reached over HTTPS. The study examined 204 such services directly, and the logins recovered inside them point outward to a wider set of file services run by other parties, so each figure names the population it counts: the services examined, the services a login reaches, or the services carrying a credentialed login.

A single host can run more than one file service. Where a host serves more than one file-transfer endpoint, for example an FTP(S) service alongside an SFTP one, or FTP alongside HTTP(S), each endpoint is counted as its own file service. Of the 204 file services examined, 6 (about 3%) expose more than one protocol, such as SFTP alongside FTP, where at least one of the protocols has a working login.

The specifications recommend a secure protocol or encrypted firmware for the transfer, and the secure firmware update in the OCPP 1.6 security extension and in 2.0.1 requires that updates be digitally protected. But they set no requirements for how the file service itself is secured, authenticated or audited: how its files are stored, whether each charger is given its own login rather than a shared one, whether a charger is confined to its own paths so it cannot read or write another charger's data, or whether a charger's login can overwrite the firmware it is served or list every image on the server.

The Alliance's Security Operations Guide v2, an informational document that defers to the specification, begins to address this, and several of its recommendations map onto the weaknesses this report measures: * Serve the transfer over HTTPS rather than FTPS for a smaller attack surface * Give each charger its own transfer credentials so one leak does not expose others * Keep credentials out of diagnostic logs This report goes well beyond that guidance: it measures how widespread these weaknesses are across the file services found in the field, and in doing so shows the security and maturity of the EV-charging industry as it stands today.

These weaknesses do not stay with one server. A charger, its manufacturer, its operator and its platform all touch the same file services, and the login that opens one is often written into the files of another: in a logged command, in a diagnostic bundle. So a single exposed login rarely stops where it is found: it opens the next party's service, and the next. The graph below traces that reach.

A single compromised file service rarely stays contained to one company. Its reach can extend across the EV-charging supply chain, from one operator to the vendors, platforms and hosts it shares logins with, so a weakness in this layer is a risk to the network and the wider ecosystem, not to one party alone.

What the analysis shows

One exposed file-service login rarely stays with one company. Across the 204 file services examined for this report, and the 490 servers their logins reach, five findings trace that reach:

Same set of posture issues, repeated across vendors, operators and platforms, and that is what lets a single login reach from one party to the next.

Chargers and OCPP backends get audited. The file services behind them mostly do not.

SaiFlow's search of the National Vulnerability Database, merged with the CVEs in CISA's advisories on charging products, finds 235 CVE records published from 2021 to 2 October 2026: 13 in 2021, 66 in 2025 and 117 in 2026 so far.

Wherever charging security draws scrutiny, it lands on the charger or its control channel, not on the files moving between them. Pwn2Own Automotive, the main contest for hacking charging and vehicle hardware, counted 76 unique zero-days at its January 2026 edition, up from 49 in both 2024 and 2025 (Zero Day Initiative). CISA's advisories concentrate on the OCPP backend: 15 between 22 January and 1 October 2026, each flagging a WebSocket control channel that does not properly authenticate connecting chargers (CISA ICS advisories, retrieved 4 October 2026; first ICSA-26-022-08). The file service the charger uses to pull firmware and push logs sits outside both.

That overlooked layer is where the exposure sits.

Only 3 of the 235 CVE records mention the firmware or log transfer path. Each concerns how a charging product handles the transfer: its credentials, its location or the file. One is CVE-2025-7357, a charger that stores FTP-server credentials in cleartext in its system logs. None describes a weakness of a file service itself. That is SaiFlow's reading of the published record, not a count of audits. The report gives three reasons:

• The issues here are not CVEs. Shared logins, weak passwords and over-broad directory permissions are weaknesses of a deployment, not defects in a product, so they are rarely assigned a CVE. They mark a deployment poorly suited to its use case: EV charging and distributed energy resources (DER).
• The owner changes with the deployment. Who secures the file service depends on the stack: a charge-point operator (CPO) on a managed CSMS assumes its provider covers the file services its fleet relies on; a CSMS provider owns them itself; a vendor inherits its managed CSMS's posture, or, running its own CSMS, must secure the relaying services, the file service included. Because the responsible party shifts, each can assume another holds it.
• Standards leave it between layers. OCPP's security profiles apply only to the WebSocket between the charger and the CSMS, leaving the file service component out of scope.

Because that URL carries its own credentials, a file-service login rarely stays with one service: chargers keep these URLs (user names and passwords included) in the configuration they store and the diagnostics they upload, so the files inside one service tend to hold the logins to others, and those others aren't always run by the same organization. A credential exposed in one file service can open a service owned by a different entity in the charging chain, so a CPO can inherit exposure from its CSMS provider or one of its charger vendors. A vendor that pulls diagnostics from a CPO's chargers receives whatever logins those logs carry, which can include the CPO's own backend and file-service credentials. The findings below measure how far that reach extends.

Exposure overview

This report's dataset covers 204 file services and, through the logins inside them, 490 file services; it also records 95,460 firmware builds. Eight figures summarize what it records. Each is counted on its own population.

The file services are mostly FTP: 90% (183 of 204). Charger vendors, CPOs, CSMS providers and third-party hosts run them, and one service usually does both jobs: 81% of file services with collected files (161 of 199) hold both confirmed firmware and logs. This is measured by file type, so it includes an unknown share of vendor build or staging shares (where the firmware is release packaging and the logs are build output), not only charger-facing services. That makes one login matter twice. Whoever can read the service can see the diagnostics of the chargers that upload to it. Whoever can write to it can change the file the fleet downloads next, unless the charger verifies a signature.

Key findings

Five findings follow, in the order an exposure would extend: from one file service to the others in its supply chain, from the password to the logs it protects, from the logs to the firmware, and from the file service to the host underneath. Each states what the dataset records, what it cannot show, and the control that breaks the condition.

The credentials that let an EV charger authenticate to a file service are often stored in plaintext inside the diagnostic files that service collects, open to anyone who can read them, a threat actor included. A diagnostic bundle records the file-transfer commands the charger ran, some with a login inside the command's URL, and those commands are not all the operator's: a firmware update that pointed the charger at the vendor's own server leaves a working login to that server sitting in the operator's logs. In at least one case a service's whole diagnostic-log tree was also published over an open HTTP directory index on the same host, readable with no login at all, so the service's own authentication bought nothing.

So the files on a service tend to hold logins, its own and other parties'. In our findings, 61% of file services with a credentialed login (112 of 185) store that login in their own retrievable files, counting only logins recorded with their own credentials, so reading the service returns the key to it. And 46% (85 of 185) hold a working login to another server, which can belong to someone else: a charger vendor, another operator, a platform provider or a host. One read often returns not a single login but several, to services the reader was never given.

The anonymous service above is the plainest instance of a general pattern: the files on one server name the next. The chains can be counted. From the best-connected starting point, credentialed logins lead to 22 file services in one hop, 62 in two and 108 in three, the reach of that one starting point, not a typical server's. One place such a login is recorded is the URL of a logged OCPP command.

This is a supply-chain exposure. A CPO's chargers fetch firmware from, and send logs to, file services run by its vendors, its platform provider and their hosts. The CPO does not control those file services, and a login to one of them can sit in the files of another. A second measure runs the other way: not what a server reaches, but how widely it is reached. In our findings, 44% of file services with a credentialed login (81 of 185) are themselves named in the files of two or more independent file services (close to the outward measure above, but the opposite relationship), so cleaning one party's logs does not close them. These counts are of independent file services, not of companies.

What a single login opens, the dataset shows at scale. The graph below maps how far these credentials actually reach across the study population, the links the data can confirm rather than a hypothetical worst case.

FTPSFTPFTPSHTTPS

Where company attribution is resolvable, those chains cross organizational lines.

A stored login sometimes reaches past the files into the host itself. On at least 13% of the researched file services that store their own login (14 of 112), the login opens the whole host, not just its file area: on all but one of them the login is not confined to its own folder and can read the host's operating-system files from the filesystem root, and on the remaining one the login is an administrative account outright. On those servers, whoever can read the files holds a login to the entire host.

Reach is largest where one file service serves many vendors. The report classes a file service that serves chargers from three or more vendors as a multi-vendor platform, its measure of a managed platform. The 51 file services in that class hold credentialed logins to 5.65 other servers on average, against 2.55 for the 62 single- or dual-vendor services, and 90% (46 of 51) hold at least one. So the few multi-vendor platforms are the report's high-reach nodes, and one platform's file-service posture shapes the exposure of everyone whose chargers and logins pass through it.

What a login found this way allows depends on the file service it opens: reading that party's diagnostic logs (Finding 3), writing to its firmware directory (Finding 4) or seeing its host (Finding 5). The dataset records the logins, not their use, and it cannot give a probability that a given CPO is exposed. What it shows is that a CPO depends on the file-service practice of its suppliers and its platform as much as on its own.

40% of the researched file services with a credentialed login (78 of 194) use a password that is also recorded for another file service. For 28% of these file services (54 of 194), that other service also has a credentialed login. 24% (47 of 194) accept a password classed as trivial or weak.

The command is where the login comes from. To collect logs or push firmware, the platform hands the charger a location, and over the FTP family (FTP, FTPS and SFTP) that location is a URL that can carry a user name and password in front of the host. A charger that records the command it received, then uploads that log, writes the server's opening credential into a file anyone who can read the log can retrieve. Most file-transfer commands instead name an HTTPS location, which hands the charger a short-lived upload token rather than a reusable login.

The case below is reuse at its starkest: one shared credential pair reads every tenant of a managed platform, exactly what a per-asset secret prevents.

How quickly such passwords would fall is estimated from their shape, not by cracking. A file service can carry more than one login; across the 194 file services that carry a credentialed file-transfer login, there are 269 credentialed logins in all, after setting aside one service whose 21 logins are UUID tokens issued by a custom authentication scheme (permanent user name with different UUIDs) rather than chosen passwords. By an upper-bound estimate of guessing effort, 10% of these logins (26 of 269) fall in the ranges the report labels instant or minutes to hours. Another 22% (58 of 269) fall in the range it labels days to weeks offline. Vendors that generate secrets generate long ones: 48% (130 of 269) sit in the highest range.

Many of the rest are predictable. Of the 269 credentialed logins:

A login can carry several of these signals, so the rows overlap rather than partition the 269.

Logins are typically set per fleet, not per charger: one file-service login usually covers many of a vendor's chargers rather than one device (Finding 5). In one case a single firmware-embedded key serves as the login for many of one vendor's chargers (Finding 4). The dataset also records the same password strings in the data of more than one operator, though this report gives no count for that.

Whether a file-service login also opens an interactive service such as SSH or a web console is a question the dataset answers only in part. 2% of distinct logins (18 of 1,096) are configured for two or more protocols on the same server, 10 of them credentialed. The dataset records 7 FTP logins presented against SFTP, 2 of them recorded as accepted. Wider reuse against SSH or web management was not tested.

In our findings, 80% of file services (164 of 204) hold at least one key, password or token in their diagnostic logs. Chargers upload the files their vendor's diagnostic routine collects, and those files can include the secrets the charger uses to reach its platform.

Three kinds stand out. The first is private keys: 5,356 distinct PEM private keys across 76 file services. The large majority are SSH keys, the charger devices' own host keys, and almost none come from firmware. The remainder is a mix of TLS and PKI material: charger HTTPS management-interface server keys, some a single key reused across many units, alongside client and mutual-TLS keys and CA and leaf certificates, rather than the file service's own keys. The count is dominated by a single platform that aggregates many devices' diagnostics, so the typical affected service holds only a handful.

The second is platform bearer tokens: 85,474 distinct tokens were decoded, nearly all of them (99.99%) signed with a shared-secret HMAC, almost always HS256, with a median lifetime of 30.4 days. Across all the decoded tokens, 12.5% (10,697 of 85,474) had not yet expired. Whether a platform still accepts them was not tested.

The third is OCPP authorization keys, the credential that authenticates a charger to its CSMS: 1,413 distinct keys at 74 file services.

The key rarely travels alone. In our findings, 80% of the files that carry an OCPP authorization key (8,219 of 10,282) also record the endpoint it is for, so one uploaded bundle hands a reader both the address of the charger's control channel and the credential that opens it.

Where the exposed credentials in these bundles reach, box to box and across operators, is mapped in the exposure graph in Finding 1.

Not every flagged secret is a usable credential. In our findings, of the 39 file services whose logs hold a cloud key, most carry only the public access-key identifier of a short-lived upload link: 143 distinct AWS access-key identifiers appear with no paired secret. Most of those are temporary STS keys from pre-signed upload links, upload-only and expiring (129, about 90%); of the 14 permanent IAM keys, about 6 are genuine charger-diagnostic candidates. Just 1 is a full static cloud-storage credential, an access key paired with its secret. The genuine one is a key the devices use for a proprietary file transfer outside OCPP.

That one credential is not confined to a single device. It is an embedded cloud identity shipped across many units of one vendor and model, and it surfaces in the diagnostic uploads of 7 file services across 3 containers. A threat actor who recovers it holds read and write access to that shared store, outside OCPP, and can plant or replace the files it holds.

Some uploads are handed to the charger not as a reusable login but as a short-lived presigned URL, a signed link that grants upload to a single object. These are write links: while one is valid, whoever reads it from a log can overwrite the object it points to. By design such a link lasts at most seven days, usually far less, so almost all had expired by the time they were collected. In the researched 993 presigned upload links rode in GetLog or GetDiagnostics commands and 610 in a vendor message; 27 and 48 of them respectively were still valid when they were collected.

The same logs hold identifiers linked to drivers and vehicles: we were able to find 233,559 distinct vehicle identification numbers at 32 file services, 369,762 contract identifiers (EMAIDs) at 25, and about 6 million distinct RFID identifiers in total, a count not broken out by file service. Where an identifier can be linked to a person, it is considered personal data under the GDPR (Regulation (EU) 2016/679, Article 4(1)). A readable log store is therefore a security exposure and a privacy one. SaiFlow's 2025 research on supply-chain weaknesses in chargers and CPO backends describes device logs with ID tags sent to vendor backends over plain HTTP.

OCPP link logins, stored in cleartext in charger logs. Beyond file-service credentials, the diagnostic files chargers upload carry the charger's own OCPP login, the authorization key it uses to reach its CSMS. Most sit in charger-written logs and configuration; a smaller share appear in platform-side files (a server-side application file or web-server log), where the same login is exposed from the CSMS end rather than the charger's.

Logins for the OCPP link. About 31% of file services (63 of 204) in our dataset carry a charger's OCPP authorization key in cleartext in their logs, 866 distinct keys in all. In OCPP security profiles 1 and 2, a charger logs in to its CSMS with HTTP Basic authentication when it opens the WebSocket. The user name is the charger's identity and the password is its authorization key (OCPP 2.0.1, requirements A00.FR.202 and A00.FR.204). The dataset records that login in four forms, almost all of them in charger files:

Another 363 logged Basic headers sit in other charger logs, where the dataset cannot tell an OCPP handshake from another HTTP call, and 16 appear only in web-service host files. MQTT, which some chargers use beside OCPP, shows the same pattern: 13 MQTT logins in charger logs and configuration files at 10 file services, and 2 broker addresses with an embedded login.

The diagnostic-log chart above counts these keys more broadly, 1,413 across 74 file services, every logged occurrence including management platforms; this breakdown applies the file-service scope rule used for the headline counts, with management platforms excluded and duplicates merged, which gives 866 at 63.

These keys cannot be tied to a specific charger vendor. The authorization key is almost always logged on its own, as a configuration value, rather than as the Basic header it rides in at the handshake, so no charger identity is paired with it in 93% of the files that hold one (8,020 of 8,608). Because the credential carries no device identity, a leaked key cannot be attributed to a charger's vendor or model from the file alone. The exposure is a property of how these platforms log their configuration, not of any one vendor's firmware.

In our findings, on 79% of the file services that expose firmware (120 of 152), the directory holding the firmware is writable by the charger's own file-transfer login. On 20% (30 of 152), that directory is world-writable, open to any connecting account. In either case, an actor who reaches the service with the credentials it already accepts, or with none, can write a file into the location the charger reads its firmware from.

File-layer integrity does little to change this. Across the firmware we recovered, we could positively confirm an embedded signature on fewer than 4% of images (3,445 of 95,460). Our analysis identifies signature structures, not whether a device checks them, so we report only what we could confirm rather than treat the rest as unprotected. Where the firmware directory is already writable, a signature on the existing file does not stop a different file being written in its place.

Our dataset records files and their permissions, not chargers or install-time behavior; signature verification at boot or install is not observed.

The world-writable figure is not confined to firmware directories. Across all file services in our dataset, at least 23% expose at least one world-writable directory (47 of 204); among the 126 whose directory listings captured permission bits, the measured rate is 37% (47 of 126).

So how feasible is it to replace a firmware file? On the file-service side the preconditions are common: the login that uploads logs can usually write where the firmware is served, and the file carries no signature of its own. The last step is the one the dataset cannot show. OCPP can carry the signature in the update command: SignedUpdateFirmware in the OCPP 1.6 security extension, and the signature fields of UpdateFirmware in OCPP 2.0.1. A charger that verifies that signature would reject a substituted build. The dataset records files, not chargers, so it cannot show how many chargers perform the check.

Because a firmware file is served from a fixed path, that path can be overwritten with new content, and the serving file service keeps no record of who did it or when it was read. A routine release and a tampered image are therefore indistinguishable in this data, and unattributable to any actor. What it does leave is a signal worth alerting on: the same path reissued with the same declared version but a different hash.

In our findings, on 7% of file services (13 of 182), the charger login is recorded reading the host's operating-system files, beyond its own folder. On those 13, 24% of retrievable files (1,145,093 of 4,755,643) were operating-system content, not charger data. Shell histories were retrievable on 12 file services, SSH server configuration on 6 and authorized_keys files on 3.

Where the host also runs the operator's web application, an un-confined login reaches more than OS files: it reads the application's own configuration and the backend credentials in it. In the clearest cases that is a production charging-management database, a message broker and a managed search service; more broadly, backend connection strings appear in cleartext configuration at 11% of file services (23 of 204). Counted where they appear and not tested, each opens the datastore behind the platform, not just the transfer in front of it.

Confinement holds more often than write control: on 80% of file services (145 of 182), in our dataset, the login stays inside its own tree, and 13% (24 of 182) more show operating-system-like paths without a confirmed view of the root. Staying inside the tree is not the same as seeing one charger's files. On 77% of file services (140 of 182), in the dataset, the login sees more than one top-level directory, where one per charger or site is typical, which is a proxy for one login listing more than one charger's uploads.

The route from a file login to a shell is recorded only as a precondition. 10% of file services (17 of 169) show a home directory, and 2 show both a .ssh directory and a writable directory. SSH host keys are recorded only for the 10 hosts where SFTP data was collected, so how many of these servers expose SSH at all is outside the dataset.

The last measure is how many chargers one login exposes.

Each file service is one login, and that one login can read every charger that uploads to the service, which is typically a fleet, not a single device.

File service software

Which products and versions run these services sits outside this report's dataset, which holds no service banners. Of the 185 file services, 178 presented a readable service banner; the software is overwhelmingly self-hosted FTP, and old: where a version was exposed the median release is about 11 years old, and 52% (46 of 89) are a decade or older.

Old software carries known vulnerabilities. In our dataset, of the 92 file services whose version we could identify, 42% (39) run a release with at least one publicly documented CVE, almost all medium-severity access-control or denial-of-service issues. vsFTPd carries most of that load (33 of the 39), though only 45% of vsFTPd's own versioned instances are affected (33 of 74). This is a posture signal, not a demonstrated exploit: a reported version is not a patch level, because distributions back-port fixes silently.

%count

Two cases could be worse where the configuration allows it. A ProFTPD service running mod_copy at a version at or below 1.3.5b would carry a potential unauthenticated remote-code-execution flaw (CVE-2019-12815, CVSS 9.8); the ProFTPD services we could identify did not reveal a core version, so this stays potential, not confirmed. An SFTPGo service with the optional rsync feature enabled would carry a potential command-injection flaw (CVE-2025-24366) that reads or writes files as the service account; rsync is off by default and not visible in the version string. Neither is a confirmed path, but both show how an old, loosely configured file service could move from a posture weakness to remote compromise.

What this means for CPOs

For most operators, exposure in this layer does not sit only in their own file services. Finding 1 showed that the managed CSMS platforms are the high-reach nodes, so a platform's file-service posture shapes a CPO's exposure as much as the CPO's own practice does.

Two duties can apply to the operator. The EU's NIS 2 Directive lists operators of recharging points in its energy sector, and those above its size thresholds carry risk-management and incident-reporting duties (Directive (EU) 2022/2555, Annex I and Articles 21 and 23). And where logs hold driver-linked identifiers, the operator is normally the data controller, even when a vendor's routine put the data there.

Six questions are worth putting to a CSMS platform provider and a charger vendor:

1. Is each firmware build signed, and does the charger verify the signature before installing?
2. Does each file-transfer operation (firmware download, diagnostic upload) use a unique user name, or the charger ID, with a generated credential that is rotated as soon as the operation completes, whether it succeeds or errors, after a short retry window?
3. Is the firmware origin read-only to charger accounts, and is log upload a separate, write-only path?
4. Does the diagnostic routine strip credentials, keys and tokens before packaging the bundle?
5. Is each file-service credential confined to its own directory, with chroot or a per-device prefix, and no view of the host or of other chargers' uploads?
6. How long are diagnostic bundles retained, where, and who can read them?

Conclusion

File transfer needs the same testing and security awareness as the rest of the EV charging ecosystem. The weaknesses in this report are ordinary ones: shared logins, writable directories, and logs that hold secrets. They produce few CVEs, so they are missing from the counts the industry uses to track charging security.

None of the conditions depends on a software exploit. They involve valid credentials, ordinary protocols and servers doing what they were configured to do, which is why most of the fixes are configuration. As Finding 1 showed, the 51 managed platforms, the CSMS providers that give CPOs the infrastructure to manage their fleets, are the high-reach nodes, so one file service can sit in front of many parties, and one fix can protect them all.

Three measurements cover most of the layer, and each party can take them on its own infrastructure. Firmware integrity: is each build signed, verified on the charger, and served from a directory the charger's login cannot write to? Credential hygiene: is each file-transfer credential generated per operation and rotated on completion, kept out of logs, and confined to its folder? Log content: are credentials, keys, tokens and driver-linked identifiers stripped or protected before a bundle is stored?

Recommendations

The report's six recommendations are tagged by owner: the charger vendor, the CPO, or the CSMS platform.

About SaiFlow

SaiFlow provides energy-contextual cybersecurity for distributed energy devices and sites: EV chargers, DER controllers, battery storage, solar PV systems, and the sites and platforms behind them. The SaiFlow platform discovers these assets through deep protocol inspection, gives operators full visibility, and monitors them in real time for both posture gaps and active incidents.

SaiFlow also provides secure file services to the operators, vendors and CSMS platforms that distribute firmware and collect diagnostics. For the file services they already run, SaiFlow scores their posture, turns each gap into a fix-it action item, and watches for abuse in real time. This report comes directly out of that work: studying the exposure of EV-charger file services across the ecosystem surfaced the five findings presented here.

Secure the File Services Behind Your Energy Devices.

SaiFlow secure file transfer protects firmware and diagnostics delivery for EV chargers and distributed energy resources (DER), with continuous posture scoring and real-time monitoring for security incidents. It also analyzes device diagnostic logs for deeper cyber and operational insights.

Contact Us