Where is my data stored, and what region?

Telemetry and configuration are stored in Firebase Realtime Database and Firestore on Google Cloud. 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 RTDB path and Firestore document is keyed by the authenticated user's UID. There are no shared paths; a misconfigured client cannot accidentally read another tenant's data.

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, RTDB, Firestore, Functions, Hosting). 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 does LoopString use Firebase RTDB instead of MQTT for cloud→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 cloud has long since commanded "off." LoopString's per-command audit gate requires fresh authenticated context per command, which retained-message replay cannot supply. Firebase RTDB delivers the current value at subscribe time but every delivery is authenticated by the receiving Pi's token, and the channel function's bounds gate runs on every delivery — no stale-state replay. 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 at rest in Firebase RTDB and 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 → FirebaseTelemetry is published to Firebase RTDB over TLS using the device's scoped credentials. Historical rollups land 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 (Firebase RTDB)	Real-time command paths, per-device meta (online status, agentVersion, ownerUid), alert state, snapshot warm-start hydration.	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 cloud commands flow L4 (RTDB) → L1 (Pi firebase-on listener) via the authenticated Pi-side subscription — they don't loop through L2 sequentially. 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.
L4 → L1 (cloud command landing on Pi): Load-bearing safety gate. database.rules.json writer ACL + Pi-side bounds enforcement (rejects out-of-bounds, audit-logs, falls back to faultBehavior on disconnect).
L4 ↔ L5 (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

Firebase RTDB and Firestore run 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?: Telemetry and configuration are stored in Firebase Realtime Database and Firestore on Google Cloud. 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 RTDB path and Firestore document is keyed by the authenticated user's UID. There are no shared paths; a misconfigured client cannot accidentally read another tenant's data.
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, RTDB, Firestore, Functions, Hosting). 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 does LoopString use Firebase RTDB instead of MQTT for cloud→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 cloud has long since commanded "off." LoopString's per-command audit gate requires fresh authenticated context per command, which retained-message replay cannot supply. Firebase RTDB delivers the current value at subscribe time but every delivery is authenticated by the receiving Pi's token, and the channel function's bounds gate runs on every delivery — no stale-state replay. 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