Security Overview

The Connectitude IIoT Platform™ and Connectitude IIoT Edge Gateway connect equipment — whether that's production lines on a factory floor, machines out in the field, or skids and packaged systems built by an OEM — to the cloud tools used to monitor, analyze, and improve their performance. Whether you're a manufacturer connecting your own plant, or a machine builder connecting equipment you design and ship to customers, that connection spans a local network and the public internet, so security has to be built into every layer in between — not assumed.

This page describes, at a high level, how we approach that. It's written for anyone evaluating Connectitude as part of your security or IT review, regardless of whether you're a plant operator, a machine builder or OEM, or a systems integrator — engineers, IT and OT teams, and compliance stakeholders alike. It intentionally stays at the level of what we do and why, rather than the specific technical mechanisms involved. If your team needs implementation-level detail as part of a formal security review, see Request the full security documentation below.

Our approach: defense in depth

No single control carries the full weight of keeping the platform secure. Device identity, software integrity, network encryption, and access control are each independent layers, so that no single point of failure can compromise the whole system. A few principles run through everything below:

• Nothing is trusted by default. A new device, a new software update, and a new user account each have to prove themselves before they're allowed to do anything.
• Everything is encrypted in transit. Every connection between a gateway, our cloud platform, and your browser is encrypted — there is no unencrypted path anywhere in the system.
• A human is always in the loop for new devices. A gateway can't start exchanging real production data on its own; a system administrator has to explicitly approve it first.
• Access follows your organization's structure. What a person can see and do in the portal is scoped to their role and their part of your organization, not the entire account.

Securing the Edge Gateway

The Edge Gateway is deployed physically wherever the equipment it connects lives — on your plant floor, inside a machine builder's cabinet, or out at a remote installation — so its security has to hold up without a security team standing next to it.

A protected, unclonable device identity. Each gateway is given a unique cryptographic identity that is generated and stored in protected hardware. That identity cannot be extracted, copied, or moved to another device — it is used to make sure the cloud platform is always talking to the genuine, physical gateway it expects, and nothing else.

A minimal, purpose-built operating system. Rather than running a general-purpose operating system with a broad set of pre-installed software, the gateway runs a lean, purpose-built system containing only what it needs to do its job. Fewer components means fewer things that can go wrong, and it lets us track and manage every piece of software on the device with precision.

Verified software, always. Every piece of software that runs on a gateway — from its very first setup to every update afterward — is checked before it's trusted to run. Operating system updates are cryptographically signed, and application updates are locked to the specific device they were prepared for, so software can't be tampered with in transit or run on a gateway it wasn't intended for.

Safe, self-healing updates. Software and security updates are delivered as complete, verified packages. An update is only switched into use after it has been fully validated, and if an update ever fails to start up correctly, the gateway automatically falls back to its last known-good state on its own — no site visit required. This lets us roll out security fixes quickly and safely across every deployed gateway.

Separate networks for OT and IT. Each gateway keeps your production network and its internet connection on physically separate network interfaces, with tightly locked-down rules governing what can pass between them. Your plant floor is never directly exposed to the internet, and the internet-facing side is never given a direct path back into your process network. If your IT team needs the specific domains and ports to allow, see Firewall settings.

Bringing a new gateway online

Connecting a new gateway is deliberately not an automatic, silent process:

1. The device generates its own protected identity the first time it starts up.
2. It requests access from the cloud, proving its identity as it does so.
3. It's created in a disabled state — it exists in the system, but cannot send or receive any data yet.
4. A system administrator on your side has to explicitly enable the device in the portal before it can go live.

That last step is a deliberate checkpoint: even if a device were somehow tampered with or misrepresented, it cannot start exchanging data without a person deciding to let it.

Data in transit

All communication — between a gateway and the cloud, and between the cloud and your browser — travels over industry-standard encrypted connections. Gateways are also designed to add an extra layer of checking that they're talking to a genuine Connectitude endpoint before exchanging any data, helping guard against an attacker attempting to intercept or impersonate that connection, even on a network your organization doesn't fully control.

Cloud platform and access control

The Connectitude cloud platform uses enterprise-grade identity and access management to control who can log in and what they can do. Access is role-based and follows your organization's own structure — whether that's a line operator, plant manager, and multi-site administrator at a manufacturer, or a machine builder's service team and their end customers each needing visibility into only the machines that are theirs. Every API the platform relies on is authenticated; there is no path into your data that doesn't go through this same access control.

Keeping the platform secure over time

Security isn't a one-time property of a device or a release — it's maintained continuously. Because updates are delivered safely and remotely, we can respond to newly discovered issues quickly and roll fixes out across the installed base without requiring a site visit. We also track emerging regulatory requirements relevant to connected industrial products, including the EU Cyber Resilience Act, and are aligning our processes accordingly as those requirements come into force.

Built for regulated manufacturing — and for machine builders who serve it

Connectitude is built for food and beverage manufacturing, where production data increasingly doubles as quality and compliance evidence. The controls described above — protected device identity, verified software, and access governed by role — are what make it possible to treat the data flowing from your plant floor into your OEE, quality, and planning modules as trustworthy, which matters directly if you run a HACCP-based food safety program or are preparing for a BRC or similar audit.

If you're a machine builder or OEM shipping equipment into these same regulated environments, that same foundation carries over to your customers: the devices you connect through Connectitude inherit the same protected identity, verified software, and audited access, so you can stand behind the security of the machines you build without having to engineer and maintain that trust yourself.

Request the full security documentation

This page is intentionally high-level. If your organization is running a formal security review or vendor risk assessment and needs implementation-level detail — architecture diagrams, network and firewall requirements, and our approach to specific frameworks — reach out to your Connectitude account team and we'll provide our detailed security whitepaper.