Vector adds EV charging security tests

Vector has expanded its CANoe Test Package EV with a new set of security tests for charging communication, extending the tool beyond conformance and interoperability work into automated vulnerability-focused validation. The package is aimed at development teams working on EVs, charge points, and associated communication stacks where authentication, certificate handling, and encrypted sessions are now part of the normal engineering workload.

The new functions include V2G communication fuzzing, monitoring of the system under test, TLS protocol tests, TLS fuzzing, and user-defined security checks through standard interfaces. Supported specifications include ISO 15118-2, ISO 15118-20, TLS 1.2, and TLS 1.3. Vector is also linking the update to automated workflows, allowing security-related validation to sit alongside existing protocol and interoperability testing inside the same environment.

Charging communication has become markedly more complex as Plug & Charge, bidirectional power flows, smart energy management, and certificate-based interactions become more widely deployed. In that environment, a compliant implementation is no longer enough on its own. Protocol handling, session establishment, certificate exchange, and encrypted transport all introduce failure modes that can affect charging availability, field reliability, and software maintenance over the life of the product.

The CANoe Test Package EV already supports conformance and interoperability testing for charging standards including CCS, NACS, GB/T, and CHAdeMO. By adding dedicated security validation, Vector is aligning its test environment more closely with the way charging systems are now built and maintained. Development teams are being asked to support new regional requirements, higher software update frequency, and more sophisticated charging scenarios without adding prolonged manual security work at the end of the programme.

That is changing the shape of validation. EV charging was once dominated by physical connection handling and standards compliance. It now sits much closer to the software-defined model seen in other connected infrastructure, where a protocol stack also acts as a security boundary. Weaknesses in message handling, certificate workflows, or encrypted session management are not obscure corner cases. They can alter how reliably and securely a vehicle or charger behaves in day-to-day operation.

Tool chains are adjusting accordingly. Validation is becoming less compartmentalised between protocol teams, embedded software groups, and cybersecurity specialists, particularly where release cycles are faster and test automation is already embedded in CI/CD processes. That does not remove the need for deeper specialist analysis, but it does raise the baseline for what should be tested continuously as code evolves.

The market pressure behind that change is straightforward enough. Charging infrastructure is now a connected estate of power electronics, controllers, certificates, back-end links, and updateable software. Every added layer of functionality expands the need for disciplined testing across both standards compliance and security behaviour. Developers that can combine those tasks in a repeatable workflow are likely to spend less time discovering avoidable weaknesses late in integration or certification.

Vector’s update reflects that shift. Charging communication is no longer being treated as a narrow standards interface. It is being handled as an exposed, software-defined subsystem whose behaviour needs to be tested under stress as well as under nominal operating conditions.