Security

IronFlock is designed for industrial and enterprise IoT environments where security is not optional. The system follows a zero-trust architecture with defense-in-depth across every layer — from device connectivity to data isolation.

No Open Ports on Devices

Edge devices running IronFlock do not expose any open ports. The device agent initiates all connections outbound to the WAMP message router. This means:

• No inbound firewall rules are needed on the device network.
• Devices are not discoverable or directly addressable from the internet.
• Remote access works through reverse tunnels — the device connects out, not the other way around.

This eliminates an entire class of attack vectors common in IoT deployments where devices listen on open ports (SSH, HTTP, MQTT).

Authentication

IronFlock uses OpenID Connect (OIDC) for user authentication.

Multi-Factor Authentication

All accounts support TOTP-based two-factor authentication (Time-based One-Time Password). Users can enable 2FA in their account settings using any standard authenticator app (Google Authenticator, Authy, 1Password, etc.).

API Keys

For programmatic access, users generate API keys that authenticate against the REST API. API keys are validated on every request through the backend before any operation is executed.

Device Authentication

Devices authenticate using WAMP-CRA (Challenge-Response Authentication) with per-device credentials. Each device receives a unique secret during the flashing process that is stored on the device and used for all subsequent connections.

Encrypted Transports

All communication in IronFlock is encrypted:

There is no plaintext communication path in the entire system.

Messaging Isolation

IronFlock uses WAMP (Web Application Messaging Protocol) for all real-time communication. The message router enforces strict isolation between projects:

Separate Realms

Each project-app combination gets its own messaging realm on the WAMP router. A realm is a completely isolated namespace — messages published in one realm are invisible to all other realms.

This means:

• Devices in Project A cannot see messages from Project B.
• App X installed in Project A has a different realm than App X installed in Project B.
• Even if the same app is installed in two projects, the data flows are completely separate.

Realm Authentication

Every realm connection requires authentication. Devices, backend services, and UI clients must present valid credentials to join a realm. Unauthorized clients cannot subscribe to topics or call procedures.

Database Isolation

Each project gets its own dedicated database resources in FleetDB (PostgreSQL):

• Separate tables — Each project-app combination has its own set of time-series tables. There is no shared table where data from different projects could leak.
• Separate credentials — Each data backend has unique connection credentials. Apps can only access their own project’s data.
• No cross-project queries — The database layer enforces that queries cannot span project boundaries.

This isolation is enforced at the infrastructure level, not just the application level. Even a compromised app cannot access data from another project.

Privilege System

IronFlock enforces a per-asset privilege model where every project, device, group, app, dashboard, and data backend has its own access control:

• The owner of an asset has full control and can grant permissions to other users.
• The project owner automatically has full control over all assets within that project.
• Each permission is a discrete boolean flag — there are no broad “admin” roles that grant unbounded access.
• All privilege changes are recorded in an immutable audit trail.

See Privileges for the full list of permissions per asset type.

Software Supply Chain Security

Security doesn’t stop at how the software runs — it starts with how the software is built and delivered. The IronFlock Supervisor, the only IronFlock component that runs directly on your devices, is built through a hardened, fully automated supply chain so you can trust exactly what reaches your fleet.

• Minimal attack surface — The Supervisor ships as a single, statically-linked Go binary with no external runtime dependencies and no embedded interpreter. There is no package manager, no dynamic library tree, and nothing listening for inbound connections — dramatically reducing what an attacker could target.
• Continuous vulnerability scanning — Every release is scanned for known vulnerabilities (CVEs) across our own code and all dependencies, using reachability-aware analysis that focuses on code paths the binary can actually execute. Scans also run on a weekly schedule, so vulnerabilities disclosed after a version ships still surface against already-deployed builds.
• Software Bill of Materials (SBOM) — Each release publishes a complete CycloneDX SBOM — a full inventory of every component and version that went into the binary. This gives you, and your auditors, exact transparency into what you’re running.
• Signed, verifiable builds — Every release binary carries a sigstore-signed provenance attestation cryptographically bound to its exact contents. The signature is tamper-evident and independently verifiable, so you can confirm a binary was produced by IronFlock’s pipeline and has not been altered in transit.
• Gated, automated releases — Builds, signing, and publishing happen in a controlled CI pipeline — never on an individual developer’s machine. Nothing is published unless the full automated test and security suite passes, ensuring the artifact that ships is exactly the one that was tested and attested.
• Secure over-the-air updates — OTA updates are delivered over encrypted channels and sourced only from IronFlock-published, signed builds — so devices update themselves without ever opening an inbound port or trusting an unverified artifact.

Together these controls give you a verifiable chain of custody from source code to the binary running on each device.

Compliance

IronFlock’s security architecture supports compliance with:

• IEC 62443 — Industrial automation and control systems security
• ISO 27001 — Information security management
• SOC 2 — Service organization controls for data security
• GDPR — Data stored in EU data centers (configurable), audit trail for data access
• EU Cyber Resilience Act (CRA) — Per-release SBOMs and a documented, continuous vulnerability-handling process directly address the CRA’s core obligations for products with digital elements.
• SLSA / NIST SSDF — Signed build provenance and a gated CI pipeline align with recognized supply-chain integrity and secure-software-development frameworks.

The combination of encrypted transports, authentication, per-project data isolation, granular privileges, comprehensive audit logging, and a hardened software supply chain provides the controls required by these frameworks.