Where is my data stored, and what region?

Live telemetry is stored on your Pi in a local SQLite database — it never transits the cloud. Rolled-up history and configuration are stored in Firestore on Google Cloud (plus a small residual Firebase RTDB footprint for room registry and presence). The default region is us-central1; enterprise customers requiring an alternate region (eu-west, asia) can request provisioning at signup.

How is data isolated between accounts?

Firebase Security Rules enforce per-user data boundaries at the read/write layer — every Firestore document and residual RTDB path is keyed by the authenticated user's UID. There are no shared paths; a misconfigured client cannot accidentally read another tenant's data. Live telemetry is isolated physically: it lives on your own Pi.

Can I delete my data?

Yes. Account-level deletion removes your user record, device registry, telemetry rollups, parts library customisations, and Stripe customer reference. Deletion requests are processed within 30 days. Pi devices retain a local SQLite history copy until you wipe them via `/clean-device`.

Who are your subprocessors?

Google Cloud / Firebase (hosting, auth, Firestore, residual RTDB, Functions). Stripe (payments). Tailscale (VPN mesh). SendGrid (transactional email). No other vendors receive customer data.

Do you support SSO / SAML?

Today we support Google OAuth and email/password via Firebase Auth. SAML / OIDC SSO for Enterprise tier is on the roadmap; contact founders@loopstring.io if it is a buying requirement for your team.

How are security incidents handled and disclosed?

Incidents involving customer data are disclosed to affected accounts within 72 hours of confirmed impact. We monitor Firebase audit logs and Cloud Functions error rates continuously, and a status page is on the launch roadmap.

What happens if my Pi loses internet?

Edge-first by design: PID control loops, alert thresholds, schedules, recipes, and automation rules all continue to execute on the Pi during cloud outages. Sensor history buffers locally to SQLite and replays on reconnect. Your processes do not stop because Firebase has a bad day.

Do you have a vulnerability disclosure policy?

Yes — email security findings to security@loopstring.io. We acknowledge within 2 business days and we publish fixes in the changelog at /changelog. Coordinated disclosure preferred; please do not publicly post unfixed issues.

Why doesn't LoopString use MQTT for operator→Pi commands?

MQTT retained-message semantics conflict with command idempotency. Standard MQTT brokers persist the last message published with retain=true on each topic and replay it to any subscriber that connects later. A retained "on" command on an actuator topic would re-energize that actuator every time the Pi reboots — even when the operator has long since commanded "off." LoopString instead delivers commands as authenticated HTTPS POSTs to the Pi's /api endpoint over the Tailscale tunnel: every command carries fresh authenticated context, the Pi-side bounds gate runs on each delivery, and nothing is replayed on reconnect. Mosquitto on the Pi runs as a Pi-internal subflow bus only, bound to localhost.

Enterprise-grade security for your automation

Your process data, device credentials, and control systems are protected end-to-end — from the Pi on your floor to the cloud dashboard in your browser.

Start Free Contact Us

Authentication & Access Control

Firebase Authentication with email/password and Google OAuth. Role-based access control (owner, editor, viewer) with per-device permissions and team invites.

Data Encryption

All data is encrypted in transit via TLS and WireGuard. Live telemetry stays on your Pi in the on-device SQLite store; cloud data (device registry, rolled-up history, settings) is encrypted at rest in Firestore. Per-user data isolation enforced by Firebase Security Rules — no shared data paths.

Network Security

Pi devices connect to the cloud via Tailscale VPN mesh tunnels — no open ports, no exposed SSH. Device management traffic never touches the public internet.

Compliance

Data stored on Google Cloud infrastructure with SOC 2 compliance. Stripe handles all payment processing — LoopString never stores card data.

Zero-trust device access with Tailscale

Each Raspberry Pi connects to your Tailscale network automatically during provisioning. Management traffic — flow deployments, OTA updates, remote shell — routes through the encrypted WireGuard tunnel, never over the open internet.

No open inbound ports on Pi devices
Tailscale online status visible in the dashboard
Remote access provisioned with per-device scoped keys
Edge-first transport: WebSocket + SQLite over Tailscale, never RTDB-on-the-public-internet

How data flows, end-to-end

1. Sensor → PiSensors connect to the Raspberry Pi over I²C, SPI, GPIO, OneWire, or UART. Node-RED ingests readings locally; the Pi enforces PID setpoints and alert thresholds in real time, with no cloud dependency.
2. Pi → Tailscale tunnelThe Pi joins your Tailscale network at provisioning time. Outbound-only WireGuard tunnel — no inbound ports, no port forwarding, no public IP. Management traffic (deploys, OTA, remote shell) only flows over this tunnel.
3. Edge → your browserLive telemetry never transits the cloud. It stays in the on-Pi SQLite store and streams to your browser over an authenticated WebSocket through the Tailscale tunnel. Only rolled-up history lands in Firestore, under per-user document paths enforced by Firebase Security Rules.
4. Browser ↔ FirebaseThe React dashboard authenticates with Firebase Auth (email/password or Google OAuth). It reads only the rooms, devices, and rollups owned by the signed-in user — no client can read another tenant's data.

Purdue Reference Model mapping

Where every LoopString component sits in the standard ISA-95 / IEC 62443 control hierarchy. The load-bearing safety gate is the Pi-side command-path RBAC at L1 — every cloud-issued actuator command is enforced against per-actuator bounds (maxOnTimeMs, maxDutyCycle, faultBehavior) before it can touch the L0 hardware. For the full cross-level conduit with auth checkpoints, see the diagram below.

Level	Layer	LoopString components	RBAC / enforcement
L0	Physical process	Sensors (temp, RH, CO₂, flow, current, distance, color, vibration), actuators (relays, valves, dose pumps, heaters, fans, motors, linear actuators).	Physical-access trust boundary. Manual override docs (per actuator class) document the 30-second technician procedure for when cloud is unreachable.
L1	Local control	Node-RED on the Pi: PID loops, hysteresis controllers, scheduled automation, anomaly detection, per-channel actuator command handlers.	Pi command-path RBAC checkpoint — the load-bearing safety gate. Per-channel bounds enforcement (maxOnTimeMs / maxDutyCycle / faultBehavior) runs here on every cloud-issued command.
L2	Supervisory control (HMI/SCADA)	Edge-WS HTTP API on the Pi + React dashboard. Operator actions: acknowledge alerts, change setpoints, toggle actuators, view rooms.	Firebase Auth (per-user identity) + role-based UI gating (owner / editor / viewer / public share).
L3	MES / Site operations	Recipe execution, schedule orchestration, compliance reporting (HACCP / FDA / USDA exports), duty-cycle statistics, alert escalation chains.	Per-device team-membership ACL; recipe owner permissions; compliance-report signer attribution.
DMZ	IT/OT boundary	Tailscale mesh (WireGuard tunnel). Cross-level conduit for cloud↔Pi traffic — no open inbound ports on the Pi.	WireGuard per-device identity key issued at provisioning. Tunnel termination is the cross-level firewall.
L4	Site IT (residual Firebase RTDB)	Residual coordination state only — room registry, viewer presence, per-device meta (online status, flow-drift hash, ownerUid). Commands and telemetry do not transit RTDB; they flow browser ↔ Pi over the Tailscale tunnel.	Firebase Security Rules — `auth.token.deviceId == $deviceId` writers; `meta.ownerUid == auth.uid` readers.
L5	Enterprise (Firestore + Cloud Functions)	Parts library, device registry, alert configs, audit trail, Stripe billing, OTA queue, Firebase Auth identity provider.	Firestore Security Rules per collection; Cloud Function service-account auth via Firebase Admin SDK.

Cross-level conduit with auth checkpoints

Every command that crosses a level boundary passes a named auth checkpoint. The most important is the Pi command-path safety gate at L1 — even if everything upstream is compromised, an out-of-bounds command (over duty cycle, over time, malformed) is rejected and audit-logged before the relay state changes.

Operator-issued commands flow browser → L1 (Pi /api endpoint) as authenticated HTTPS POSTs over the Tailscale tunnel — they don't transit the cloud at all. The dashboard at L2 is the HMI/SCADA view; the safety enforcement is the Pi-side gate at L1. This is by design — defense-in-depth lives at the lowest authoritative level, not in a chain of upstream relays.

Cloud-issued actuator commands traverse the safety gate at L1 (highlighted)

Auth checkpoints, edge by edge

L0 → L1 (sensor wire): No auth — physical-access trust boundary. Manual override is the defense-in-depth.
L1 → L2 (Pi-internal): localhost only between Node-RED subflows; no cross-host auth needed.
L2 ↔ DMZ (Tailscale boundary): WireGuard per-device identity key issued at provisioning.
DMZ → L4 (Firebase tunnel termination): mTLS via Firebase SDK.
Browser → L1 (operator command landing on Pi): Load-bearing safety gate. Authenticated POST /api/commands over the Tailscale tunnel + Pi-side bounds enforcement (rejects out-of-bounds, audit-logs, falls back to faultBehavior on disconnect).
L4 ↔ L5 (residual RTDB ↔ Firestore): Firebase Security Rules + Cloud Function service-account auth (Firebase Admin SDK).
L5 → operator browser: Firebase Auth + per-user data isolation via Security Rules.

Roles at a glance

Owner: Manage devices, billing, and team membership. Deploy flows, change setpoints, view all data.
Editor: Deploy flows, change setpoints, acknowledge alerts. Cannot manage billing or invite teammates.
Viewer: Read-only dashboard and analytics. Perfect for inspectors, auditors, and stakeholders.
Public share link: Single-dashboard, read-only, expiring URLs — share live status with a customer without giving them an account.

Role-based access control for teams

Invite team members with owner, editor, or viewer roles, scoped per device. Owners control device settings and billing. Editors deploy flows and adjust setpoints. Viewers have read-only access to dashboards and analytics — perfect for inspectors, auditors, or external stakeholders. For one-off sharing without an account, use a public dashboard share link.

Every role change, deploy, setpoint update, and acknowledgement is captured in the per-device activity log — meets the recording requirements for HACCP, FDA, USDA inspection. For compliance regimes requiring an independent tamper-evident audit store, see Audit trail — current limits and roadmap below.

Audit trail — current limits and roadmap

LoopString writes audit entries for every actuator command (bounds enforcement, rejections), role change, flow deploy, setpoint change, alert acknowledgement, and recipe execution. These land in Firestore under users/{uid}/devices/{deviceId}/activityLog,alertEvents, and complianceReports.

Honest current limit

The audit log currently lives in the same Firebase trust domain as the controlled system. A determined cloud-side attacker with project-admin credentials could rewrite history. For regulated industries that require an independent tamper-evident audit store (HACCP recall-evidence, 21 CFR Part 11, certain SOC 2 controls), this is a known gap.

Roadmap: independent audit store — write-only mirror to Google Cloud Storage or BigQuery hosted in a separate billing project with separate project-admin keys — is planned. Email security@loopstring.io if your compliance regime needs this before public rollout.

Trust & Compliance

Google Cloud / SOC 2

Firestore (and the residual Firebase RTDB footprint) runs on Google Cloud infrastructure, which maintains SOC 2 Type II compliance and independent security audits.

PCI DSS (via Stripe)

All payment processing is handled by Stripe, a PCI DSS Level 1 certified provider. LoopString never stores, processes, or transmits cardholder data.

Per-User Data Isolation

Firebase Security Rules enforce strict per-user data boundaries. No user can access another user's devices, sensor data, or configurations.

Security FAQ

Where is my data stored, and what region?: Live telemetry is stored on your Pi in a local SQLite database — it never transits the cloud. Rolled-up history and configuration are stored in Firestore on Google Cloud (plus a small residual Firebase RTDB footprint for room registry and presence). The default region is us-central1; enterprise customers requiring an alternate region (eu-west, asia) can request provisioning at signup.
How is data isolated between accounts?: Firebase Security Rules enforce per-user data boundaries at the read/write layer — every Firestore document and residual RTDB path is keyed by the authenticated user's UID. There are no shared paths; a misconfigured client cannot accidentally read another tenant's data. Live telemetry is isolated physically: it lives on your own Pi.
Can I delete my data?: Yes. Account-level deletion removes your user record, device registry, telemetry rollups, parts library customisations, and Stripe customer reference. Deletion requests are processed within 30 days. Pi devices retain a local SQLite history copy until you wipe them via `/clean-device`.
Who are your subprocessors?: Google Cloud / Firebase (hosting, auth, Firestore, residual RTDB, Functions). Stripe (payments). Tailscale (VPN mesh). SendGrid (transactional email). No other vendors receive customer data.
Do you support SSO / SAML?: Today we support Google OAuth and email/password via Firebase Auth. SAML / OIDC SSO for Enterprise tier is on the roadmap; contact founders@loopstring.io if it is a buying requirement for your team.
How are security incidents handled and disclosed?: Incidents involving customer data are disclosed to affected accounts within 72 hours of confirmed impact. We monitor Firebase audit logs and Cloud Functions error rates continuously, and a status page is on the launch roadmap.
What happens if my Pi loses internet?: Edge-first by design: PID control loops, alert thresholds, schedules, recipes, and automation rules all continue to execute on the Pi during cloud outages. Sensor history buffers locally to SQLite and replays on reconnect. Your processes do not stop because Firebase has a bad day.
Do you have a vulnerability disclosure policy?: Yes — email security findings to security@loopstring.io. We acknowledge within 2 business days and we publish fixes in the changelog at /changelog. Coordinated disclosure preferred; please do not publicly post unfixed issues.
Why doesn't LoopString use MQTT for operator→Pi commands?: MQTT retained-message semantics conflict with command idempotency. Standard MQTT brokers persist the last message published with retain=true on each topic and replay it to any subscriber that connects later. A retained "on" command on an actuator topic would re-energize that actuator every time the Pi reboots — even when the operator has long since commanded "off." LoopString instead delivers commands as authenticated HTTPS POSTs to the Pi's /api endpoint over the Tailscale tunnel: every command carries fresh authenticated context, the Pi-side bounds gate runs on each delivery, and nothing is replayed on reconnect. Mosquitto on the Pi runs as a Pi-internal subflow bus only, bound to localhost.

Security you can trust at any scale

Start with a single device and scale to a fleet — the same security model applies throughout.

Get Started Free Email security@loopstring.io