Security & privacy
You trust us with your charging data, and soon with your payout. This page explains in plain language what we keep, where it lives and who can see it. No technical background needed.
Last updated: July 2026
Prefer the mechanisms? Jump to the technical section →
The short version
Only you see your data
Every account can reach its own data and nothing else. That isn't a filter in the app — it's a lock in the database itself.
Stored encrypted
The key we use to collect your charge sessions is stored encrypted. What's needed to unlock it lives somewhere else, so a copy of the database on its own is useless.
We don't know your password
Your password goes straight to our login service and never passes through our own servers. Sign in with Google and you don't even have a password with us.
Everything is traceable
Connections, registrations and checks all land in a log that can only be added to. Nothing can be quietly changed or deleted.
What data we hold
We ask for what we need to register and pay out your EREs. Nothing more.
What we store
- Your name and email address, for your account and our messages.
- Your address and the EAN code of your grid connection — both are required for registration with the NEa.
- The brand and model of your charger, and which charger sits at which address.
- Your charge sessions: start and end time, and the number of kWh.
- Later, once we start paying out: your bank account number. It gets the same encrypted treatment as your charger connection.
What we don't do
- We don't track your car: no trips, no locations, no licence plates.
- We see nothing of the rest of your household's electricity use — only what goes through your charger.
- We don't operate your charger. We only read sessions — we never start or stop charging or change settings.
- We don't sell your data, don't trade it and don't build advertising profiles from it.
Where your data lives
Your account and charging data sit with processors in the European Union, encrypted in transit and encrypted at rest. Our suppliers work under a data processing agreement and only get what they need to do their job.
We use cookies to measure website visits — those are separate from your account. What we measure and how to switch it off is in our Privacy statement.
How your charger connection is secured
Every charger brand does it differently. Per brand we always pick the route where we need to know as little about you as possible.
Consent at the manufacturer
With most brands you click 'allow' inside the manufacturer's own environment. Your login details never pass through us: we only receive a key, and either side can revoke it.
Sign in once, or paste a key
With some brands you sign in once, or create a key in your own account and paste it with us. After that we only keep that key, encrypted — we don't store your password.
The exceptions, and we say so
A couple of brands offer no route other than your login details (yet). Then we store them encrypted, say so in plain language on the connect page before you type anything, and delete them the moment you disconnect. We want those exceptions gone: we're asking those manufacturers for a proper connection.
Who can access your data
- You, in your portal — that's the complete picture.
- A small part of our team, only when needed: when you ask for support, or when a connection breaks. Never your password, never a key in readable form.
- The NEa and the auditor who checks our registrations, for exactly what they need to be able to check.
- Nobody else. No data trading, no reselling, no ad networks.
Why we record so much
An ERE certificate is only worth something if someone can verify those kWh were really charged. So we keep your charger's answer exactly as it reached us, and record every check and every change. Awkward for anyone who'd want to cheat — and good for you, because it's your evidence if questions ever come up.
You stay in control
- Your portal shows all your sessions and registrations.
- You can disconnect at any time. We wipe that connection's keys; your earlier sessions stay as evidence.
- Moving house or handing over your charger is done in the portal. Sessions are attributed from the correct date, never retroactively to the wrong person.
- Want to see your data, have it corrected, or close your account? One email is enough.
- A registration contract legally runs for at least one calendar year — with us too. After that it's cancellable yearly.
Staying safe together
- We will never ask for your password, a code or a key by email or phone. If you get such a message: don't reply, but do forward it to us.
- Links in our messages always point to revvolt.nl. Not sure? Type the site into your browser yourself.
- Use a unique password you don't use anywhere else — a password manager does the work for you.
For the technically inclined
Want more than "we encrypt everything"? Here are the mechanisms themselves — at the level where you can judge them, not at the level where they become a manual.
Open a topic to read it.
Access control in the database
- Row-level security is on for every table holding customer data. Policies bind to the user id from the verified session token, not to anything the client sends along. An API key runs through those exact same policies.
- Columns holding key material additionally have their privileges revoked for the customer role. A mistake in a single policy still yields no keys — two locks, not one.
- The role that may bypass RLS exists server-side only, behind our own API, and never reaches browser code. No direct database connection from the client.
Encryption
- In transit: TLS with modern cipher suites, HSTS on our domains, no mixed content.
- At rest: disk encryption at the hosting provider, plus encrypted backups that never leave the EU.
- On top of that we encrypt charger-connection key material at the application layer with AES-256-GCM (authenticated encryption, a unique nonce per value). The ciphertext carries a version prefix, so we can rotate the key or the algorithm without downtime and without a big-bang migration.
- The encryption key lives in the runtime environment — not in the database, not in the repository, not in a backup. A database dump without that key yields no usable token. The trade-off, stated plainly: lose the key and everyone has to reconnect. That's the intended direction of failure.
Authentication & sessions
- Sign-in and sign-up go straight from the browser to our managed auth provider. Your password never passes through our own API routes, server code or tables. Storage is a bcrypt hash with a per-user salt, in a schema our application role cannot read.
- Sessions are short-lived JWTs in httpOnly, secure cookies; refresh happens in middleware. Authorization always hangs off the user id inside the token.
- Google sign-in runs over OIDC. Those users have no password with us at all — nothing to leak.
- The auth endpoints are rate-limited at the provider, so repeated failed attempts don't run unbounded.
Charger connections
- Where the manufacturer supports it: OAuth 2.0 authorization code flow, with a CSRF `state` in a short-lived httpOnly cookie, fixed redirect URIs and server-side token exchange.
- We request the narrowest scope that yields charge sessions. No permission to start or stop charging or change settings — so we can't misuse it either if something goes wrong on our side.
- Tokens are refreshed outside your flow. When that stops working we mark the connection expired and ask you to reconnect, rather than hammering the manufacturer's API. That's also what their fair-use policy asks of us.
- Brands without OAuth: a key or personal access token you create yourself, or — when there genuinely is no other route — login details. Always application-encrypted, always disclosed on the connect page above the input field, always deleted on disconnect. Which measure applies to which brand is stated on that connect page itself.
Ingestion & evidence
- The manufacturer's response goes into append-only storage unchanged. The normalized session is derived from it, so every calculation can be re-run from source.
- Sessions are upserted on the manufacturer's session identifier, so a repeated, overlapping or backfilled sync can't produce duplicate kWh.
- Where the manufacturer supplies signed meter data (OCMF), we keep that signed blob as-is — a signature is worthless the moment you rewrite what it covers.
- Attribution is date-bound: a session belongs to whoever owned the charger at that session's start time. A later connection can't claim earlier sessions, and on a handover only sessions from the agreed date move across.
- Every verification step and status change is an append-only audit row. Those tables carry no UPDATE or DELETE privileges — not for us either.
The ERE calculation
- ERE = kWh × renewable fraction × fossil reference × 3.6 / 1000. No secret sauce: it's the formula from the regulation, and it's unit-tested.
- The parameters live in database configuration per calendar year, not in code. The same source feeds the calculator on this site, your portal and the registration — one truth, so no gap between what we quote and what we file.
What isn't there yet
- MFA with TOTP. The storage side is ready at our auth provider; the screens around it are a short job we want done before payout details live in accounts.
- A check against known breached passwords at sign-up and password change.
- The payout side doesn't exist yet. Bank details will get the same application-layer encryption as key material, with tighter access — built together with payouts, not after them.
- A published subprocessor list and data processing agreement for anyone who wants to review them. On request for now.
What we deliberately don't publish
No infrastructure diagrams, version numbers, names of tables, endpoints or keys, and no exhaustive mapping of which measure sits with which supplier. None of that changes the guarantee for you; for an attacker it's the difference between searching and knowing.
Found something?
If you think you've spotted a weak spot, we'd rather hear it from you than from someone else. Email us what you saw and how to reproduce it. We take it seriously, take no action against anyone who reports responsibly and without causing damage, and are happy to credit you as a thank-you. One ask: don't try anything that could reach other customers' data, and give us the chance to fix it before you publish.
Our contact details for reports are also machine-readable at /.well-known/security.txt.
Questions about this page or about your own data? Email us at support@revvolt.nl