Security

What this page covers

This page describes how Esimbit is built and what that means for the data it handles. It is written to answer the questions a security review actually asks, in the order it usually asks them.

Esimbit is operated by LOKUM TECH LLC, 8 The Green, Suite A Dover, DE 19901.

Esimbit is three front ends over one API: the marketing site and the reseller panel on esimbit.com, a white-label storefront for each reseller on its own hostname, and a staff-only backoffice. They share an API and share nothing else.

Everything here is a description of the system, not a warranty. Contractual commitments live in the Terms of Service and, for personal data a reseller entrusts to us, in the Data Processing Addendum. Where this page says a figure has not been set, it has not been set — read it as a gap, not as a range.

The product is available in English, Turkish and Arabic. This document is published in English only, and the English text is the one that applies.

Who secures what

Esimbit is a bring-your-own-keys platform. A reseller connects their own eSIM provider accounts and their own payment gateway, and we call those providers on their instruction. That split decides who is responsible for what, so it is worth stating before anything else.

For a storefront sale the reseller is the seller and the merchant of record. We are the software, and the processor acting on their instructions.

Accounts and passwords

Passwords are hashed before storage. We do not keep them in readable form, we cannot recover one, and no support process exists that would let staff read or repeat a password back to you. The same is true of storefront customer accounts.

A password reset revokes every token already issued to that account. Completing a reset therefore signs the account out of every device it was signed in on, including any device an attacker was using, and the new password has to be used to sign back in.

Email verification and other one-time codes are sent by email and are single-use. Password fields are set with confirmation, so a typo becomes an error rather than a lockout.

Sessions and tokens

Signing in issues a bearer token. Every API call carries it in an Authorization header; there is no ambient session that a cross-site request could ride on.

• The reseller panel keeps its token in a cookie set to expire after 30 days, or when you sign out.
• A storefront customer token is kept per store, under a key that names the store, and is cleared on sign-out.
• Signing out discards the token on the device.

The lifetime enforced by the server, independent of what the browser is willing to keep, is 30 days.

Separation between resellers

Every record belongs to a tenant, and the tenant is resolved from the authenticated token rather than from anything the caller sends. A request cannot ask for another reseller’s data by changing an identifier, because the identifier is not what decides the answer.

Storefront customer accounts are per reseller. A shopper who creates an account at one store has an account at that store only — the same email address at another store is a different, unconnected account, and a token issued by one store is useless at another.

In production each storefront is served on its own hostname, so the browser itself keeps one store’s cookies and stored data away from the next. Where stores share a host instead — a development or staging shape — the browser does not partition them, and the separation is the application’s: every stored value is keyed to the store it belongs to.

Provider and gateway credentials

The keys a reseller connects are the most sensitive thing on the platform, and they are handled as write-only. They are encrypted by the application before storage, verified against the provider when they are saved, and never returned in full. The panel is sent only the last four characters of a stored key, as a hint for telling two connections apart; the key itself is never in an API response, in the panel, or in staff tooling.

Because the key itself never comes back, there is no "edit key" flow. Replacing a key deletes the old connection and creates a new one, which the panel says out loud rather than hiding.

Keys are scoped by the provider, not by us. Issue the narrowest credential the provider offers, and revoke it on their side if you disconnect — that is the only revocation that is certain.

Card data

No card number reaches our servers, and no card field is ever rendered on a page we serve.

A storefront checkout creates an order and then sends the shopper, by full-page redirect, to the reseller’s own gateway on the gateway’s hosted page. We hand the gateway an amount and a reference. The shopper types their card details into the gateway’s page, on the gateway’s domain, and returns to the store afterwards. We learn whether the payment succeeded, not what was used to pay.

This is a redirect, not an embedded frame or a script. There is no payment SDK in the storefront page, so a compromise of the storefront could not read a card field that does not exist there.

Esimbit’s own subscription billing works the same way: resellers pay on Stripe’s hosted page, and we store the resulting plan and billing state, not a card.

What runs in the browser

There is no third-party script on any page we serve. No analytics, no tag manager, no advertising pixel, no session replay, no in-page error reporter, no social widget, no chat bubble. Fonts and flag icons are served from our own hosts. Traffic reaches those pages through a proxy and web application firewall, named in the sub-processor table below.

The practical consequence is that the front end has almost no supply-chain surface: there is no vendor script that could be swapped out to read a page, because there is no vendor script.

One exception, and it is the reseller’s to control. A store’s branding may point at a logo hosted somewhere we do not run. When it does, the shopper’s browser fetches that image from that host, and that host sees the request. It is an image, not a script, and it cannot read the page.

• All traffic is served over HTTPS.
• The reseller panel is rendered in the browser rather than on the server, and is excluded from search engine indexing.
• The marketing site and the storefronts render on the server, and what they render there is public catalogue and store data — never another party’s order, account or credentials.

Access control

A reseller’s team members hold one of three roles — owner, admin or support — and each role carries an explicit set of capabilities: managing pricing, connections, stores, team, billing, refunds, resending a delivery email, retrying fulfilment, transferring ownership.

The API enforces those capabilities. The panel is told what the signed-in person may do so it can disable a control and say why, but disabling a button is a courtesy — the refusal that matters happens on the server, and a crafted request meets it just the same.

Connections are the sharpest case. The support role cannot open the connections screen at all, so it sees neither a stored key — nobody sees that — nor the four-character hint beside it, because even the hint says something about the reseller’s provider account. Owners and admins can.

Esimbit staff are a separate realm. Platform staff hold no role inside a reseller’s team; their access comes from the backoffice, which is staff-only and separate from both public front ends. The policy governing which staff may reach production data, on what approval, and how that access is logged and reviewed is Production data is reachable only by the engineers who need it to run the service. Access is granted individually, reviewed every quarter, and logged..

Ownership can be transferred and members can be removed, but only by someone who already holds the capability. If the owner account is lost, recovery is a support matter, not a self-service one.

Hosting and data at rest

Production runs at AWS, in Frankfurt, Germany (eu-central-1).

Two different claims about encryption at rest are worth keeping apart. The application encrypts the reseller’s provider and gateway credentials itself, before they are written, and that is true wherever the database happens to live. Whether the underlying storage and its snapshots are also encrypted by the platform they run on is a hosting configuration, and the answer is recorded above by naming the provider and region — we do not restate it here as a guarantee the software cannot make.

This page makes no claim about penetration testing, independent audit, uptime, or recovery objectives. None has been committed to. If a review needs those, ask at [email protected] and expect an honest answer rather than a number invented for the form.

Backups and logs

Backups are an infrastructure decision, not an application one — the software defines no backup behaviour of its own. The schedule, where copies are held, how long they are kept and whether restores are tested is The production database is backed up daily, encrypted, held in the same region as the database, kept for 30 days, and a restore is tested at least once a year..

Server and access logs are kept for 365 days. Logs exist to run and debug the service. They are not used to profile visitors, and there is no analytics pipeline for them to feed.

Deleting data from the live system does not by itself remove it from a backup. Deletion requests are honoured in the live system first, and in backups as those backups age out — see the Privacy Policy for how that is handled.

Where data goes

A shopper’s purchase involves a small number of other companies. Some we contract with; some the reseller does. Which of the two a company is decides who answers for it, so they are listed apart rather than in one column.

Recipients the reseller chooses (not our sub-processors — see the Data Processing Addendum):

The reseller holds those two accounts and agreed those two contracts. We call the APIs on their instruction, with the keys they connected. The Data Processing Addendum states that these are not our sub-processors, and this page does not quietly make them ours.

Our sub-processors:

Annex 2 of the Data Processing Addendum is the authoritative list of the sub-processors we engage for a reseller’s shopper data, and the addendum governs how a change to it is notified. Read this table as the same list in plainer words; where the two differ, the annex is the one under contract.

One recipient is ours alone: Esimbit’s subscription billing runs through Stripe, which sees a reseller’s billing details and nothing from any shopper. There we are the controller of our own customer records rather than a processor for a reseller, which is why Stripe is in the Privacy Policy and not in Annex 2.

Changes to the software

All application code is held in version control, and production runs a build from it — there is no editing of running code. The front ends are written against a versioned API contract, so a change to the API that would break a client is visible as a contract change rather than as a surprise in production.

Review and approval before a change reaches production is governed by Every change is reviewed by a second engineer and has to pass the automated test suite before it can be deployed. Deployment is limited to the engineers who hold production access..

Dependencies are pinned by a lockfile, so a build installs the versions that were tested rather than whatever is newest at the time.

Reporting a vulnerability

Send it to [email protected]. Include what you found, how to reproduce it, and what you think it lets someone do. If it involves an account or a store, say which — it is much faster than us guessing.

We will acknowledge a report within 2 working days and tell you what we intend to do about it. We will not take legal action over a report made in good faith that stays within the limits below.

• Test only against accounts and stores you control.
• Do not access, modify or keep anyone else’s data — if you reach it by accident, stop and tell us what you saw.
• No denial of service, no spam, no social engineering of staff, resellers or shoppers.
• Give us a reasonable chance to fix the issue before you publish it.

There is no bug bounty. We do not pay for reports, and we would rather say so than let anyone spend a weekend expecting otherwise.

If something goes wrong

If we confirm a breach affecting personal data a reseller entrusted to us, we tell that reseller. They are the controller for their shoppers’ data and the clock that matters is theirs, so a late notice from us costs them their own deadline.

The notification window we commit to is set out in the Data Processing Addendum, along with what the notice must contain and who reports a breach onward to a regulator. That is the contract, and this page does not restate it — two copies of a deadline drift apart, and only one of them is signed.

Notices go to the account contact by email. Keep that address current and reachable; it is the only channel we have. Questions about a notice go to [email protected].

Certifications

Esimbit claims no independent security certification. There is no SOC 2 report, no ISO 27001 certificate, and no completed third-party audit behind this page.

What is written here is a description of how the system is built, which you are welcome to test against the product itself. Where a control is a policy rather than code, this page marks it as unset instead of implying it exists.

If you see a certification claimed for this platform anywhere else, this page is the correct one. Please report it to us.