Separate routing identity from authenticated authority
A station identifier tells a charging platform which logical device a session claims to represent. The platform also needs evidence that the connecting endpoint is entitled to use that identity. Otherwise, routing and command association can become authority granted on the strength of a claim.
The Monta advisory provides a concrete reason to inspect that boundary. It does not establish that every deployed charging station has been compromised, nor does it demonstrate a grid event or a physical vehicle consequence. The engineering task is to determine whether the actual endpoint rejects an unauthorised claim to station identity.
Inspect the configured station profile, platform endpoint and credential binding. Encryption protects a communication channel, while client authentication addresses who can use it. A successful encrypted connection is not, by itself, the acceptance evidence for station impersonation resistance.
Give migration an operational acceptance record
Start with an inventory that connects station model, firmware, configured profile and support ownership. Confirm whether each unit can use the required authentication method and trust configuration. Do not assume that protocol compatibility establishes support for every security option on an installed legacy unit.
Use a representative controlled subset to validate provisioning, connection, required charging operations and recovery before changing the wider fleet. Define who can approve the rollout and what observations will stop it. Agree the supported recovery procedure with the platform and station suppliers, including how to regain authorised access if a credential or configuration change fails.
An unsupported station needs a bounded exception rather than a silent return to weaker access. Identify its exposure, permitted service, temporary restrictions and replacement or upgrade plan. A rollout deadline adds value only when someone owns the remaining exceptions and can explain why the service continues.
Test rejection, replacement and session ownership
Acceptance should include a negative test using an authorised test identity in a controlled environment: present a station identifier without its corresponding valid credential and confirm rejection. Also verify successful connection by the legitimate station. Retain the endpoint configuration, test conditions and observed result, rather than a generic statement that authentication is enabled.
Credential replacement and revocation need the same operational discipline. Determine who provisions the credential, how it is protected, how the platform invalidates it and how the legitimate station recovers. The recovery path should preserve accountability rather than granting broad emergency access.
CISA also reports vendor measures for throttling abusive connection patterns and handling duplicate connections. Treat those statements as inputs to validation. Test which session remains authoritative, what the operator can observe and how it restores the expected station after a conflict. No production flooding or impersonation exercise is required by this recommendation.
Make the operating record survive failure
Monitor the evidence available at the platform boundary: rejected authentication, unexpected session changes, repeated reconnects and credential lifecycle events. Establish a baseline for normal maintenance and intermittent connectivity so an alert supports an investigation rather than merely counting retries.
The Open Charge Alliance's OCPP 1.6 security material covers secure connection setup, security events and firmware updates. Use the current relevant protocol material with the supplier implementation evidence; a certification or feature claim cannot substitute for checking the deployed endpoint.
The useful completion record joins each station to its enforced profile, negative and positive test results, credential owner and recovery procedure. It lets operations maintain the security decision after replacement, outage or a supplier change. The objective is an enforceable identity boundary that charging service can sustain.
Sources & further reading
Continue this decision.
Move from this analysis into a curated route across related incidents, evidence and operating constraints.