Security

Your organization is the boundary.

InnovaEdge is a managed platform for adopting, configuring and monitoring fielded hardware, and everything you put into it — devices, telemetry, dashboards, audit history — is scoped to your organization. This page describes how that boundary is built and operated, in plain terms, without pointing at a certification we don't hold.

No SOC 2, ISO 27001 or pen-test report exists yet — posture described below, nothing claimed beyond it

01 — Four trust domains

Separated rather than shared by convenience.

A manufacturer cloud connection is an encrypted, organization-owned credential — it cannot authenticate an InnovaEdge user, define an organization, choose a storage namespace, or end a browser session. Four domains stay separate on purpose:

Control database

Users, organizations, memberships and roles — the product identity boundary itself.

MQTT transport & device identity

Broker connections and the credentials that authenticate a device onto them.

Telemetry storage

Shared or customer-owned databases holding the readings your fleet reports.

Grafana organizations

Dashboards, keyed to your organization schema, not merely to a shared broker.

02 — Identity, multi-tenant isolation & audit

Who you are, what you can see, and what got written down.

Native passwords are hashed with Argon2id (64 MiB, three passes, four lanes, a unique salt per password). Verification, reset and invite tokens are stored only as a SHA-256 digest and consumed exactly once under a row lock; verification links expire after 24 hours, self-service reset links after one hour, and invites and first-owner setup links after seven days. A password reset revokes the account's active sessions. Every native session is bound to one active organization at a time and rotates to a new session token when you switch.

Organization isolation

Every request resolves against your organization. Fleet, tables, charts and audit are scoped to it, each organization owns a stable physical telemetry namespace, and device ownership is fail-closed.

Native identity, SSO and MFA

Argon2id passwords, verified email, invitations, four roles, TOTP MFA, and OIDC single sign-on scoped to your organization so access follows the directory you already run.

Immutable audit stream

A per-organization audit event stream over the state-changing surface, plus failed authorization and failed sign-ins. Exportable as a support bundle.

Usage visibility

Broker messages, bytes, sink storage and active devices metered per organization and visible to you, so what you are billed for is something you can check rather than take on trust.

Scoped machine API keys

Long-lived keys for scripts and integrations, separate from login sessions. A key carries scopes that can only narrow the permissions of the person who issued it, is shown once and stored as a hash, so an integration credential can never quietly outrank its owner.

Enterprise SSO & passkeysPlanned

SCIM-style membership administration, enterprise SSO connectors and passkey authentication.

Private sink failure

The internal database is not a telemetry fallback. A broken private sink fails visibly instead of copying your data into control storage or an unapproved shared database.

03 — Broker isolation

A device only ever sees its own topic subtree.

Per-device identity

A production broker issues one MQTT identity per device, managed through Mosquitto dynamic security and restricted to that device's own topic subtree. Shared wildcard credentials are a demo convenience, not the production posture.

Deduplication

Broker connections are deduplicated only when endpoint, TLS identity, username and password all match. Different ACL identities on the same broker get different MQTT clients rather than being folded together.

Fail-closed ownership

A device with an unknown or conflicting identity goes to quarantine, not into an arbitrary account. Parser registries are limited to the broker and accounts assigned to that exact connection.

04 — Secret handling

Credentials are stored encrypted and shown redacted.

At rest

Broker passwords and database connection strings are encrypted before storage. The API returns only redacted connection strings and a has-password flag, never the value itself.

WLAN credentials

Sent to devices as non-retained MQTT commands and redacted from the control-plane audit trail — they pass through without being written down.

On the wire, not on the command line

Managed credential helpers receive secrets over standard input rather than as command arguments, so they never sit in a process list or a shell history.

Error reporting

Opt-in error reporting runs with frame locals forced off, so a captured stack trace cannot carry a credential-shaped variable along with it.

05 — Operations

Releases are pinned, watched, and backed up offsite.

Production runs a specific, pinned release rather than a moving branch. Promotion is preflighted and health-gated, and rolls back automatically if the gate fails. Internal and external probes — including TLS expiry — watch the platform from both sides of the network boundary.

Release rings with rollback gates

Production runs a pinned release. Promotion is preflighted, config-validated and health-gated, and rolls back automatically if the gate fails.

Whole-instance backups, pulled offsite

Control database, telemetry sink and broker security configuration are all backed up and pulled offsite, with freshness monitored — a backup nobody checks is not a backup.

Inside and outside monitoring

Service health, queue depth, pool saturation and lost rows watched from inside; public URL, TLS expiry and MQTT edge probed from outside, tagged to prove this host answered.

Ingest built for load

A bounded queue with worker threads keeps a slow sink from dropping the broker session, group commit replaces per-message fsync, and drops are counted rather than silent.

06 — Disclosure

Found something? Tell us privately, not in public.

Report a suspected credential exposure or vulnerability privately, with the affected component, reproduction conditions and any evidence that can be shared safely — never in a public or organization-visible issue that could itself leak a credential. We'll acknowledge it, assess containment, rotate anything exposed, and coordinate a fix.

Where to send it

Email[email protected]with "security" in the subject. It reaches a person, not a queue.

What we commit to

We acknowledge the report, assess containment, rotate anything exposed and coordinate a fix. There is no published response-time SLA and no bug bounty — we would rather say so than imply one we do not run.

Ask us the hard question directly.

If your evaluation checklist needs an answer that isn't on this page, ask in the demo — we'll tell you plainly what is and isn't true yet.

Request a demo