IEC 62443 For EV Charging
💡 IEC 62443 For EV Charging: Key Highlights
- “62443 certified” is never one claim. Five different parts certify five different actors — the supplier’s process (-4-1), the component (-4-2), the assembled system (-3-3), the operator’s risk assessment (-3-2) and the service provider’s programme (-2-4).
- A Security Level is a seven-element vector, not a number. IEC assigns one SL per foundational requirement, so “SL 3” written into an RFP without the vector specifies nothing.
- Two parts have no vendor to hide behind. -3-2 (zones and conduits) and -2-1 (asset-owner programme) bind the operator, and no supplier certificate discharges them.
- India has made this contractual. The CEA (Cyber Security in Power Sector) Regulations, 2026 — notified 31 July 2026, in force 1 April 2027 — impose signed patches, an SBOM, pre-supply hardening and vulnerability disclosure on vendors. That is 62443-4-1 restated as law.
- Most public charging lands at SL 2. Moving a charger zone to SL 3 means hardware-backed keys and a fleet-wide certificate lifecycle — a procurement decision, not a retrofit.
Ask three charger suppliers whether their product is secure and all three say yes. Ask which part of IEC 62443 they certified against, who issued the certificate and at what Security Level, and the answers separate fast. IEC 62443 is the international standard series for the cybersecurity of industrial automation and control systems — operational technology — and a charging network is OT in every way that matters to a Charge Point Operator.
This post is about the standard itself: which of its parts binds whom, how they map onto a real charging stack, and how to use the series as a purchasing instrument instead of a badge. It is deliberately not three other things. API-layer practice — authentication, audit logging, DPDP obligations — is covered in our guide to security and compliance for EV charging APIs. Protocol-level security profiles belong to the OCPP 2.1 vs OCPP 2.0.1 upgrade guide. The EU’s legal duty on recharging point operators is NIS2, which gets its own article.
Why A Charging Network Is OT, Not IT
India’s Central Electricity Authority defines operational technology as “programmable hardware or system that detects or causes changes through the direct monitoring or control of physical devices, processes, and events.” A 60 kW DC charger closes contactors on a three-phase supply on instruction from a cloud back-end. It is a physical actuator taking remote commands, which is the textbook definition.
Three IT assumptions break at that point. First, patching: you cannot reboot a charger on the second Tuesday of the month, and a failed firmware update on an unattended forecourt is a truck roll, not a support ticket. Second, physical access: chargers sit in car parks, on highways and outside petrol pumps, where an attacker can spend an hour with the enclosure unobserved. Third, priority order: IT reaches for confidentiality first, but IEC 62443 makes Resource Availability a foundational requirement in its own right (FR7), ranked alongside confidentiality rather than beneath it. For a CPO earning per kWh, that is the correct ordering.
The framing changes by segment. A pure CPO is securing revenue and a grid connection. A fuel retailer is bolting chargers onto a forecourt that already has an OT estate, safety systems and an audit regime. An enterprise or fleet operator is putting industrial actuators inside the corporate network, where depot chargers become the softest route to everything else. Same standard, three different risk conversations.
How IEC 62443 Divides Responsibility Across Your Charging Stack
The series is written for four distinct roles — asset owners, product suppliers, system integrators and service providers — and each role gets its own part. That structure is the single most useful thing in the standard and the single most abused thing in vendor marketing, because “we are 62443 compliant” is a sentence with five possible meanings. The table below is the map. Read a claim against it before you read the rest of the datasheet.
| Part of IEC 62443 | Who it actually binds | What it governs in a charging stack | How a claim is verified |
|---|---|---|---|
| -4-1 : 2018Secure product development lifecycle requirements | The supplier’s process | How the charger firmware or the back-office platform was built: security requirements, secure design and implementation, verification testing, defect management, security update management and a documented end-of-life policy. It says nothing about any one product. | ISASecure SDLA certificate — issued to a development organisation, not to a product. Certified organisations are listed on a public register. |
| -4-2 : 2019Technical security requirements for IACS components | One component | The technical capability of a single box — the charge point, a site gateway or controller, an embedded meter — expressed as a component capability security level (SL-C) across the seven foundational requirements. | ISASecure CSA (or ICSA for IIoT components). SDLA certification of the developer is a prerequisite. Certified components are publicly listed by product and version. |
| -3-3 : 2013System security requirements and security levels | The assembled system | Chargers plus gateway plus back-office plus the networks that join them, assessed as one control system. This is where the seven foundational requirements become system requirements and where SL 1–4 are defined. | ISASecure SSA — issued against a specific system configuration, never a SKU. A component certificate does not roll up into one. |
| -3-2 : 2020Security risk assessment for system design | You, the operator | Defining the system under consideration, partitioning it into zones and conduits, assessing risk per zone and setting a target security level (SL-T) for each. The output is a design document, not a device setting. | No product certificate exists. This is a deliverable you own and an auditor reads. |
| -2-4 : 2015Security program requirements for IACS service providers | Your integrator and O&M partner | How the people who install, commission and remotely maintain your estate handle staging, credentials, remote access and patching — the actors with standing access to every site you own. | Assessed against the service provider’s programme, including via the ACSSA scheme; frequently handled as a customer audit clause instead. |
| -2-1 : 2024Security program requirements for IACS asset owners | You, again | Your own security programme across the estate: policy, roles, competence, change control, incident response. The part a supplier cannot sell you. | Audited, not product-certified. |
Part titles and publication years per the IEC webstore and the ISA/IEC 62443 series listing; certification schemes per ISASecure.
A -4-1 certificate tells you nothing about the product quoted
SDLA certifies a development organisation’s documented process and a sample of artefacts. A supplier can hold a valid SDLA certificate and still quote a charger model built before that process existed, or a firmware line it white-labels from a third party. The follow-up is always the same: which product, which version, and was it developed inside the certified process scope?
A component certificate does not certify your system
-4-2 gives a component a capability security level. Whether that capability is switched on, correctly configured and coherent with everything around it is a -3-3 and -3-2 question. An SL-C 3 charger deployed with default credentials on a flat site network delivers SL 0 in practice, and no certificate on the wall changes that.
The India overlay: CEA’s 2026 vendor rules read like -4-1 in regulation
The Central Electricity Authority (Cyber Security in Power Sector) Regulations, 2026 were notified on 31 July 2026 and come into force on 1 April 2027. They bind entities owning or operating OT infrastructure connected to the interconnected power system — distribution and transmission licensees, load despatch centres, generators and storage above 50 MW. A standalone CPO is not on that list. But regulation 2(2) states that the vendor shall comply with regulations 11 and 12, and a CPO running chargers for a DISCOM, or a platform touching a licensee’s OT estate, is exactly that vendor.
Regulation 11 requires the vendor to supply digitally signed or authenticated patches for the contract period or the system’s useful life, whichever is later; a bill of materials per CERT-In guidance; hardware and software hardened before supply; disclosed end-of-support dates including for third-party components; and a formal vulnerability-reporting process feeding CSIRT-Power. Read that against the -4-1 row above: security update management, secure configuration guidance, end-of-life policy and defect management, restated as Indian law with a commencement date. Regulation 5(24) then requires covered entities to hold an ISO/IEC 27001 certificate or a “Technical Criteria Certificate” — a certificate from a designated body accredited for conformance to cyber security standards specified by the Central Government, which is precisely the shape an IEC 62443 conformance certificate takes.
Zones And Conduits On A Real Charging Topology
Part -3-2 asks one structural thing of you before you buy anything: draw the system under consideration, cut it into zones — assets sharing a security requirement — and name the conduits carrying traffic between them. A workable first partition has four zones. The charge point zone is the EVSE at one site, in an untrusted physical environment with mixed vendors and firmware vintages. The site infrastructure zone holds the gateway or site controller, the energy meter and the load-management controller, usually behind a lock. The back-office zone is where sessions, tariffs, remote start/stop and firmware campaigns live — in practice, a charging management platform like YoCharge and whatever else has an account on it. The commercial zone carries payment acquiring, roaming and eMSP interfaces.
Then the conduits, and this is where most diagrams are incomplete. Charge point to back-office over OCPP is the one everybody draws — the conduit OCPP-compliant charging software lives on, and the one OCPP’s security profiles address. Site controller to charge point is a second; back-office to payment service provider a third, back-office to roaming hub a fourth. The one routinely left off is the supplier maintenance conduit: the OEM’s own remote path into firmware and diagnostics. It crosses the same trust boundary as everything else, it is usually the highest-privilege path you own, and it belongs on the drawing with a named owner.
Done honestly, the exercise produces one uncomfortable finding. The sharpest trust boundary is rarely between the charger and the internet — it is between the charger and its own back-end. A charge point that executes any well-formed instruction from its management system inherits that system’s compromise across the whole fleet at once. Separate zones exist precisely so those two are not assigned the same target security level merely because they talk constantly.
Security Levels As A Procurement Decision
IEC 62443’s four security levels describe the attacker, not the technology. SL 1 protects against casual or coincidental violation. SL 2 against intentional violation using simple means, low resources, generic skills and low motivation. SL 3 against sophisticated means, moderate resources, IACS-specific skills and moderate motivation. SL 4 against sophisticated means, extended resources, IACS-specific skills and high motivation. Levels correlate countermeasures with adversary strength — they are a risk statement, not a product tier.
A security level is not a single number. IEC expresses it as a vector of seven elements — one per foundational requirement — so a zone can legitimately be SL 3 for identification and authentication control and SL 1 for data confidentiality. Writing “must be SL 3” into a tender without the vector does not specify a system; it specifies a price.
Where does public charging actually land? Most networks specify the charge point zone at SL 2 and the back office at SL 2 to SL 3, and the reason is cost rather than complacency. Taking a charge point zone from SL 2 to SL 3 generally means per-device unique credentials with hardware-backed key storage, mutual authentication on every conduit rather than one, and integrity protection that survives a hostile local network. That pushes you to secure-element hardware in the charger and a real certificate lifecycle — issuance, rotation, revocation — across every unit in the fleet. None of it retrofits cleanly onto a deployed estate, which is why it is a specification decision taken at procurement or not taken at all.
SL 3 earns its cost in four situations: depot and fleet charging where an outage stops a commercial operation, chargers installed inside an enterprise network, sites contracted to deliver grid services, and anything sitting within a licensee’s OT estate — the case Indian regulation is now moving toward. Public kerbside and highway charging generally does not clear that bar, and specifying it anyway prices you out of the tender.
Where IEC 62443 Sits Next To ISO 27001, OCPP And NIS2
ISO 27001 certifies a management system, not a control system. It asks whether your organisation runs security properly; it does not ask whether a charge point enforces use control. India’s CEA regulations accepting either ISO 27001 or a Technical Criteria Certificate for critical systems is the clearest official signal that the two are complements rather than substitutes.
OCPP Security Profile 3 — mutual TLS with client-side certificates — is one control on one conduit. In 62443 terms it is evidence toward the identification/authentication and confidentiality requirements on the charge point-to-back-office link: necessary, nowhere near sufficient for a zone-level SL claim. NIS2 is a legal duty on EU recharging point operators rather than a technical specification; ENISA’s technical implementation guidance is where its controls get named, and 62443 is one recognised way to evidence them. That is a separate post.
Five Questions To Put To A Platform Vendor
Every question below has a checkable answer. A supplier that cannot give you one is telling you something useful.
-4-1, -4-2 or -3-3 are three different claims. Ask for the certificate number and the accredited certification body, then check it against the scheme’s public register yourself.
Component certificates name a product and a version, not a product line. Confirm the certified version is the one being quoted, and what happens to the certificate at the next firmware release.
Ask for the capability level per foundational requirement. A vector with SL 1 against restricted data flow tells you more than a marketing “SL 2” ever will.
Including the supplier’s own remote-maintenance path. A vendor that has never drawn one has never had this conversation with an operator who audits.
In writing, per product, covering third-party components. Under CEA’s 2026 regulations an Indian vendor will owe exactly this to a licensee customer from 1 April 2027 anyway.
None of this requires you to become a standards body. It requires you to treat IEC 62443 as what it is — a division of responsibility, written down, with public registers attached — and to make your suppliers say which side of each line they are standing on. The operators who do that before signing spend the next decade patching software. The ones who do not spend it replacing hardware.
Frequently Asked Questions
Sources: ISA — ISA/IEC 62443 Series of Standards | IEC 62443-4-1:2018 | IEC 62443-4-2:2019 | IEC 62443-3-3:2013 | IEC 62443-3-2:2020 | IEC 62443-2-4:2015 | IEC SyC Smart Energy — IEC 62443 | ISASecure Certification Schemes | ISASecure Certified Components Register | CEA (Cyber Security in Power Sector) Regulations, 2026 | ENISA — NIS2 Technical Implementation Guidance
Answering a security questionnaire?
See how a charging platform built for audited networks handles it
Zone-aware architecture, signed firmware campaigns, per-charger credentials and the audit trail an enterprise or licensee customer will ask you for. Walk through it with our team against your own topology.
Get a Demo