NEBLI
Request an invitation
Nebli Environment

Security and data

How Nebli Environment keeps your sensor data and your people's data, how long it keeps readings, what it records about use, and the limits it has today.

Who this is for: the city's or the organisation's IT or security reviewer, the programme lead, and anyone answering questions about where the data lives.

Where it runs

Where Nebli hosts the platform, it runs at env.nebli.ai in Nebli's own AWS account in one US region, on the same managed cluster as Nebli's other products but in its own namespace, with its own database. Sensors and gateways connect to mqtt.env.nebli.ai (port 8883), http.env.nebli.ai and talq.env.nebli.ai.

Your organisation's data stays yours

  • Every read and write is scoped to one organisation. Every table carries the organisation, and every query must name one; a query without one is refused. An id from another organisation answers exactly as a missing one.
  • Every credential resolves to one organisation before any data is touched: an adapter credential, an API key, a person's session.
  • A sensor credential writes only for its own nodes. A reading for another node is refused and counted, never written under that node. Over MQTT a sensor can publish only under its own topic prefix and can never subscribe.
  • Readings that look wrong are kept as suspect. Unknown channels and impossible values are stored as suspect for diagnosis, and never open an alert, feed an index or become a node's current value.

Protection in transit and at rest

  • In transit: every connection from outside uses TLS; plain HTTP is only redirected to HTTPS. MQTT is served on 8883 only; a plain connection is refused. Browsers are told to use HTTPS only.
  • At rest: the database and the file store use the cloud's encryption at rest. Secrets live in a secret store, never in the database or in images.
  • Credentials: adapter secrets and API keys are shown once and stored only as a keyed hash (HMAC), so a copy of the database alone yields no usable secret. Every credential can be revoked on its own, and a revoked one is refused on its next request; open MQTT connections are closed within seconds.
  • Logs never hold a credential, and a credential never travels in an address.

Signing in

There are no passwords. A person signs in with a short code sent to their email. The code works once, expires, is bound to the browser that asked for it, and is spent after a few wrong tries. Asking for a code looks the same for an unknown address. Sessions are kept on the server, and signing out ends that session on the server, so no copy of its cookie keeps working (People and access).

Exports

Exports are kept in a private store under keys that include your organisation. They go only to the person who asked, after the person, the organisation and their right to export are checked again, and they are deleted after seven days. There is never a public link to an export (Exports and the read-only API).

Calls to your systems

Nebli Environment calls addresses you give it: a HikCentral receiver, and a TALQ gateway. It treats them as untrusted: HTTPS only, no IP addresses, no private or internal network unless your installation lists it, no redirects, time and size limits, and only the status code and a short cleaned excerpt of the answer kept. The HikCentral event line carries ids and numbers only, never a name anyone typed (Sending alerts to your console).

How long data is kept

Readings, alerts and deliveries are kept for the period your plan sets, and then deleted. Settings › Retention shows the periods, which are not editable there, and the last purge with what it removed. The period is never shorter than three months, and the database itself enforces that floor. Open alerts and the readings that opened them are never purged.

What Nebli records about use

Where Nebli hosts the platform, it records how signed-in people use the screens: a small set of events and a replay of the session.

  • People are identified by an opaque id only, never by name or email.
  • Events carry only ids, fixed values, counts and yes-or-no; a name, an email or any typed text is refused.
  • The replay never shows a secret: credentials and API keys shown once, delivery-target credentials and the sign-in code are kept out of it, and links are reduced to their page. Nothing is recorded on the sign-in pages, and signing out stops the recording.
  • A platform that Nebli does not host records nothing and contacts no analytics service.

Personal data

Environmental readings carry no person. The personal data in Nebli Environment is people's emails, names and languages, and the audit rows that name them.

Limits you should know

  • On a partner's or customer's own cluster, whoever administers that cluster can read sensor secrets as they arrive, read delivery-target secrets in their own secret store, and change readings and audit rows in the database they run. Nebli Environment makes no claim against that administrator today.
  • Rate limits per network address are coarse. Sensors often share mobile carrier addresses, so the limit that decides is the one per credential.

Compliance

Nebli Environment has not been audited or certified against a security framework such as SOC 2 or ISO 27001.

Next