Security

Flowion connects real EV chargers to real organizations' fleets, so we treat authentication, authorization and data isolation as core to the product, not an afterthought. This page describes how the running system protects your chargers, your team and your drivers.

At a glance

Encryption in transit

Every connection into the platform runs over TLS — browser sessions to the console, calls to the management API, and every charger's connection to the platform. Nothing talks to Flowion in plaintext.

Authenticating operators

Signing in to the console or calling the management API requires a valid ID token from our identity provider, Google Cloud Identity Platform. You sign in with Google, with GitHub or with a link we email you: there are no Flowion passwords to guess, reuse or leak. Every request is verified against Google's published keys — signature, expiry, issuer and audience are all checked before a request is treated as authenticated.

For their own backends, operators can mint scoped API keys. A key is shown once and stored only as a hash, is scoped to a single organization or project, can carry a hard expiry, can never hold the Owner policy, and can be revoked at any time.

Authenticating chargers

Every charger authenticates with its own password carried over TLS (OCPP Security Profile 2). Each password is hashed with Argon2id before it's ever written to the database; we don't store the raw password and can't recover it, only verify it. A charger's password can be rotated at any time without physical access to the hardware.

Chargers that support it can authenticate with a TLS client certificate instead (OCPP Security Profile 3), issued by Flowion's own certificate authority.

Authorization and tenant isolation

Every management API request is authorized against real organization membership — the permission policies a person actually holds, across the organization or in a specific project (Owner, Admin or User), and what each one allows — never a client-supplied tenant identifier. A request for an organization, project or charger you don't belong to returns the same "not found" response as one that doesn't exist, so unauthorized requests can't be used to enumerate other tenants' data.

When a customer grants an installer access to its chargers, that access covers commissioning and diagnostics for the stations it names. It never reaches the customer's billing, members, driver identifiers or charging sessions, and either side can end it at any time.

Cross-origin requests to the API are restricted to known, explicitly allowed browser origins.

Driver data

The RFID cards and other identifiers a charging network accepts are personal data, and they are stored encrypted. Charging sessions refer to a driver identifier only by an opaque reference, never by its value. Revealing an identifier's value takes a permission only the Owner policy includes, and every reveal is written to an audit trail before the value is returned. A customer can erase an identifier permanently.

The one place an identifier appears as the charger sent it is the log of raw charger messages, kept for seven days so a failed exchange can be investigated, and then deleted.

Webhooks

Every webhook delivery is signed, so a receiver can check it came from Flowion before trusting it. A webhook must use https, and its address is checked on every delivery attempt: one that resolves to a private, loopback or link-local address is refused, so a webhook cannot be pointed inside anyone's network.

Infrastructure

Flowion's backend runs as Rust services on Google Kubernetes Engine in Google Cloud's Stockholm region, provisioned entirely through Terraform and deployed as Helm charts — infrastructure changes are reviewed like any other code change, not made by hand in a console. The charger-facing gateway and the management API are deployed and scaled independently, so a deploy of one doesn't interrupt the other's live charger connections.

How we build

The whole test suite — unit tests, lint, formatting and the structural checks that hold the rules above in place — runs on every change before it reaches production. The API's OpenAPI specification is generated directly from the code that serves it, so documentation can't silently drift from what's actually deployed. And every three minutes we start a real charging session on production, on chargers old and new, and check the result through the same public API our customers use.

Reporting a security issue

If you believe you've found a security vulnerability in Flowion, please email security@flowion.io with details. We take reports like this seriously and will respond as quickly as we can — please give us a reasonable chance to investigate and address an issue before disclosing it publicly.