How eSIMLab protects your business and your customers.

eSIMLab holds two kinds of data: your business's account and settings, and the personal data of your customers that is needed to sell and deliver an eSIM. Below is how both are protected, section by section, including what we do not yet do.

Infrastructure

Development and production environments are separated, and production access is limited to named administrators. Every storefront is served over HTTPS, with certificates issued and renewed automatically for each connected domain.

The hosting provider and region are not named on this page yet. They will be named in the subprocessor list, which is not published yet.

Data handling

You remain the controller of your customer data; eSIMLab processes it on your instructions. For a traveller that is typically a name, an email address and order records. Our processing terms are set out in the Data Processing Agreement.

Three subprocessors are named today because the platform cannot run without them: Stripe for card payments, eSIM Access as the provider you connect, and Cloudflare for your domain's certificate. Hosting, email delivery and backup storage are subprocessors too, and are named when the list is published.

Encryption

Traffic between browsers, our platform and provider APIs is encrypted in transit with TLS. Data at rest is encrypted at the storage layer by our hosting provider.

The credentials you paste into the workspace, such as your Stripe secret key and your eSIM Access secret, get a second layer: they are encrypted with AES-256-GCM before they are stored, using a key kept outside the database. A copy of the database alone is not enough to use them, and the screen never shows them back to you.

Account security

Passwords are stored as argon2id hashes, a memory-hard algorithm that makes a leaked table expensive to attack. Sign-in attempts are rate limited, and repeated attempts are throttled rather than silently retried.

There is no two-factor authentication yet. It is not offered, not partially built and not hidden behind a setting: a password and the rate limiting above are what stand in front of a workspace today.

Access control

Each member of your workspace holds a role: owner, admin, marketing, sales or support. A role limits which screens a person can open and what they can change. A dashboard screen that has not been given a rule is refused to everyone below admin, so a forgotten screen fails closed.

Sign-ins and changes made in the dashboard are recorded: who acted, on which screen, and whether it was allowed. What was typed is not recorded, so the trail itself does not collect personal data. Internal access to production data is limited to staff who need it for support, and is granted case by case.

Backups and monitoring

Databases are backed up and the backups are stored away from the platform that made them. A restore drill loads the newest backup into a scratch database and checks it, because a backup nobody has restored is a file, not a backup. The schedule and retention period are operational settings we do not publish yet.

Availability and error rates are monitored continuously, and the public status page reflects real monitoring data.

Incident handling

If an incident affects your data or your storefront, we email the account owner with what happened, what was affected and what we are doing about it. We do not wait for the investigation to finish before the first message, and we do not publish a notification deadline we have not committed to in a contract.

Payment boundaries

Card details are entered on Stripe's hosted checkout, not on a page we serve. eSIMLab does not receive or store card numbers, and customer payments settle to your own Stripe account, not ours.

Report a vulnerability

Send your finding through the contact form, say that it is a security report, and include enough detail to reproduce it. We will confirm receipt, keep you updated and will not pursue action against good-faith research.

Open the contact form