OCPP Secure Provisioning
The default position in a lot of deployed charging is a charger that will talk to any backend that answers, and a backend that accepts any charger claiming an identity. Secure provisioning is the work of giving each unit an identity it cannot lie about, and it has to happen in the factory rather than on site.
What OCPP security profiles actually protect against, where a charger's identity comes from, how keys are stored, the bootstrap problem that every scheme has to solve, and what all of this looks like as a step on a production line.
Meet security profile 3For A manufacturer or network operator specifying security for a fleet, often because a tender or a utility customer has started asking.
What is actually being protected
Three separate risks get bundled together as security, and they have different answers.
- 1
Someone reads the traffic
Session data, identifiers and commands in clear text on a network you do not control. Solved by transport encryption.
- 2
Something impersonates the charger
A device claiming to be charge point 47 and reporting sessions that never happened, or absorbing commands meant for a real unit. Solved by the charger proving its identity.
- 3
Something impersonates the backend
The more serious one. A charger that connects to whatever answers can be told to unlock, to change its configuration, or to accept firmware. Solved by the charger verifying the server rather than trusting it.
The third is the one most often left open, because a charger that trusts any server works perfectly until somebody points it at a different one.
The OCPP security profiles
OCPP 2.0.1 defines security profiles that build on each other. The numbering matters in tenders, so it is worth knowing what each one actually gives you.
Swipe to compare
| Profile | Charger proves identity by | Server verified | Traffic encrypted |
|---|---|---|---|
| 1 | Basic authentication over an unsecured connection | No | No |
| 2 | Basic authentication over TLS | Yes, via server certificate | Yes |
| 3 | Client certificate over mutual TLS | Yes, via server certificate | Yes |
Profile 1 is meaningfully worse than the other two and exists largely for constrained legacy cases. Profile 2 is the pragmatic position for most fleets. Profile 3 is what a utility or a national scheme tends to require, and it is the one that forces the provisioning question, because a client certificate has to come from somewhere.
Where identity comes from
A charger cannot generate its own trusted identity. Something has to vouch for it, and the only place where that can be done under controlled conditions is manufacture.
- A key pair is generated, ideally on the device so the private key never exists anywhere else
- A certificate is issued against that key by a certificate authority the backend will trust
- The unit's identity is recorded against its serial number in a manufacturing record
- The trust anchors the charger will use to verify servers are installed at the same time
Doing this on site instead means an engineer with a laptop and a private key in a file, which is not a controlled condition. It also does not scale, and it produces exactly the audit gap that a utility customer will ask about.
Key storage, and what a secure element buys
A private key in flash is a private key that can be extracted by anyone who obtains a unit, and units are obtainable. Whether that matters depends on what the identity controls.
- 1
Software keystore in flash
Cheapest. Adequate where the consequence of a stolen identity is limited to one charger's sessions. Not adequate where the same key material appears across a fleet.
- 2
Secure element or secure enclave
The private key is generated inside and cannot be read out. Signing happens on the chip. Adds cost per unit and removes the whole class of key extraction attacks.
- 3
Per-unit keys either way
The failure that turns one compromised unit into a compromised fleet is a shared key. Whatever the storage, keys must be unique per device.
The bootstrap problem
Every provisioning scheme has to answer one awkward question: how does a device that has no identity yet get one, over a network, without that first exchange being the weak point?
- Provision fully at manufacture, so there is no first connection without an identity. Cleanest, and it requires the factory to have access to the certificate authority
- Ship with a manufacturer certificate and exchange it for an operator certificate on first connection. Practical, and the exchange window has to be authenticated by the manufacturer certificate rather than left open
- Provision on site under supervision. Workable at small scale and it does not scale, and it leaves the audit gap mentioned above
Whichever is chosen, the window in which a unit is trusted without having proven anything must be bounded, logged and closable. A bootstrap that stays open forever is a permanent door.
What this looks like on a production line
Provisioning is a production step with a jig, a record and a failure mode, not something an engineer does at the end.
- A programming and provisioning jig that generates or injects keys and installs trust anchors
- A record linking serial number to identity, which is what makes later revocation possible
- A verification step, because a unit that leaves unprovisioned is a unit that fails at a customer site
- Controlled access to the certificate authority from the factory, which is a process and access control question rather than a technical one
- A defined path for re-provisioning a board that is repaired or replaced
Want this applied to your own site?
Meet security profile 3Technically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
Which security profile do we need?
Profile 2 is the pragmatic position for most fleets. Profile 3, with client certificates and mutual TLS, is what utilities and national schemes tend to require, and it is the one that forces the provisioning question.
Can we provision on site instead of in the factory?
At small scale, yes. It does not scale, it puts private key material in a file on an engineer's laptop, and it produces the audit gap that a utility customer will ask about.
Do we need a secure element?
It depends on what a stolen identity would let someone do. Where each unit has its own key and the consequence is limited, a software keystore may be adequate. Shared keys across a fleet are never adequate.
What is the bootstrap problem?
A device with no identity has to obtain one over a network, and that first exchange is the weak point. It is solved by provisioning fully at manufacture, or by shipping a manufacturer certificate that authenticates the exchange.
Does this apply to OCPP 1.6J?
The profiles are defined in 2.0.1, but transport security and server verification can be applied to 1.6J deployments through network and TLS design. It is less standardised and it is not nothing.
Being asked for OCPP security profile 3?
The answer starts at the production line, not at the firmware. Tell us how your units are programmed today.
Meet security profile 3