Most charging operations start with one shared administrator login. It is the fastest way to get a first site live, and it works until the day someone changes a tariff at the wrong station, a maintenance contractor is still able to stop live sessions six months after the contract ended, or a customer disputes a charge and nobody can say who adjusted it. None of those are hypothetical - they are the three incidents that make operators go looking for proper access control, usually after the fact. This post is about setting it up before.
Access control is an operational problem, not an IT formality
It is tempting to treat roles and permissions as a compliance checkbox handled once during onboarding. In a charging business they are closer to an operations design decision, because the console is not a reporting tool - it issues commands that affect physical equipment and real money. A single operator console can stop a session a customer is paying for, unlock a cable, push a firmware update to a fleet of chargers, change the price every driver sees, and trigger a payout to a site host. Those are five very different consequences, and very few people in an organization should be able to do all five.
The four roles almost every charging operation needs
| Role | Typically needs | Typically should not have |
|---|---|---|
| Operations | Network health, faults and alerts, remote reset/unlock, maintenance tickets, charger configuration | Tariff changes, payouts, refunds, customer payment data |
| Support | Customer lookup, session history, receipts, the ability to see what a driver saw | Pricing changes, bulk charger commands, settlement records |
| Finance | Tariffs, invoices, collections, reconciliation, site-host revenue share and payout records | Remote charger control, firmware management |
| Administrator | User and role management, integration credentials, platform-level configuration | Nothing structurally - which is exactly why the count of administrators should be small and reviewed |
The point of the right-hand column is not distrust. It is blast radius. A support agent who cannot accidentally change a tariff is a support agent who can work faster, because fewer of their actions are consequential. Least privilege makes routine work less nerve-racking, not more restricted.
Where standard roles stop working
Real organizations have responsibilities that do not fit four tiers. A regional manager who owns pricing for their region but not nationally. A field maintenance contractor who needs remote reset on a specific set of chargers and nothing else. An analyst who should see every session and change nothing. A site host who wants visibility into their own location's performance without access to the rest of the network.
Two mechanisms cover these, and a platform should offer both. Custom roles let you define a permission set that matches an actual job rather than forcing the job into a preset tier. Scoping limits a role to part of the network - a region, a zone, a set of stations - so the same “operations” role can be granted narrowly to a contractor and broadly to the internal team. This is where a clean site hierarchy earns its keep: organizing infrastructure by region, zone, station and connector is primarily an administrative convenience until you need to delegate authority along those lines, at which point it becomes the backbone of your permission model.
The audit trail is the part people regret skipping
Permissions decide what can happen. The audit trail is how you find out what did. The useful standard is logging at the request level - every administrative and operational action recorded with four facts:
- Who - the specific user or API credential, never a shared account.
- What - the action and the object it affected, with enough detail to reconstruct the change.
- When - a reliable timestamp, which matters more than it sounds when correlating a console action with a session the customer is disputing.
- The result - whether it succeeded or failed. Failed attempts are often the more interesting record: repeated failures against a permission boundary is a signal, not noise.
Two properties turn a log into something usable. It has to be filterable, because the question is never “show me everything” - it is “show me every tariff change at this station in March.” And it has to be exportable, because the people who eventually ask for it are auditors, finance and occasionally lawyers, none of whom are going to log into your operator console.
Four practices that prevent the usual incidents
- No shared logins, ever. A shared administrator account makes the audit trail worthless the moment anything needs investigating - every entry says “admin,” which answers nothing. This is the single highest-value change most small operations can make.
- Named credentials for integrations too. A machine account is a user. Give each integration its own scoped credential so an automated action is attributable to a specific system, and so revoking one does not break the others - the same discipline covered in API, webhooks and event streams.
- Offboard through the identity provider. If console access is federated through corporate identity, disabling someone's account removes their charging access automatically. A standalone platform login is the one everybody forgets - see enterprise SSO for charging platforms.
- Review access on a schedule. Quarterly is enough for most operations. Permissions drift upward over time - people get added to roles for a one-off task and are never removed - and the only reliable correction is a periodic look at who can do what.
Multi-brand and partner operations raise the stakes
Everything above assumes one organization. The moment a platform runs several brands, franchisees or partner operators, access control stops being about convenience and becomes the mechanism that keeps tenants separate: one partner's staff must not see another partner's sessions, customers or revenue, even though both run on the same platform. That isolation is a property of the architecture, not of how carefully roles are assigned - it is the core of what a multi-tenant CSMS provides, and it is worth testing explicitly during evaluation rather than assuming.
What to ask a vendor
- Can we create custom roles, or are we limited to the preset tiers?
- Can a role be scoped to a region, a site or a set of chargers rather than the whole network?
- Is every administrative action logged at the request level, including failed attempts and API calls?
- Can audit records be filtered and exported, and how long are they retained?
- Can we see the permission matrix during evaluation - the actual list of what each role can do?
CarChargeOS ships role-based access for operations, support, finance and administrators, custom roles for responsibilities those tiers do not cover, and request-level audit history that is filterable and exportable on demand - see the operations and security sections on the platform page.
Frequently asked questions
Our team is five people. Is this worth setting up?
The role separation matters less at that size; the audit trail matters just as much. Named individual logins cost nothing to set up on day one and are painful to retrofit after a year of shared-account history. Start there, and add role separation when the team grows past the point where everyone knows what everyone else did.
How long should audit records be kept?
Long enough to cover your dispute and financial reporting cycles, which in practice means at least as long as a customer can contest a transaction and as long as your finance team may need to re-examine a reconciliation period. Confirm the platform's retention period rather than assuming it is indefinite, and export anything you need to hold longer.
Should site hosts get console access?
Often yes, but narrowly - a scoped, read-only view of their own location's sessions and revenue share is usually what they actually want, and it removes a recurring reporting burden from your team. The requirement is that the scoping is enforced by the platform, not by agreeing not to look. Giving a host visibility into their own numbers also tends to make the hosting relationship easier at renewal.