Securing connected infrastructure: a practical approach

A solar plant, a pumping station, and a greenhouse controller have something in common with a bank's servers: they are connected, so they can be attacked. The difference is the consequence. A breach of a farm's control system is not only a data problem — it can affect water, power, and crops.

That is why we treat security as part of the architecture, not a layer added at the end. These are the principles we design to.

Use a recognized framework

For industrial automation and control systems, the reference is the IEC 62443 series. Its most useful ideas are practical:

Zones and conduits. Group equipment into zones with similar security needs, and control exactly what may pass between them.
Security levels. Match the strength of protection to the realistic threat for each zone, instead of one setting for everything.
Foundational requirements such as identification and authentication, use control, system integrity, restricted data flow, and timely response to events.

Using a recognized framework also gives customers, insurers, and auditors a shared vocabulary.

Keep the control network small and quiet

Segment. Field devices and controllers sit on their own network, separate from office Wi-Fi and from the internet.
No inbound doors. Site gateways initiate an encrypted outbound connection to the platform; nobody on the internet can connect in to a pump controller.
Allow only what is needed. Each device talks only to the services it must reach.

Give every device and every person a real identity

Devices: unique credentials per gateway — ideally certificate-based with mutual TLS — so one stolen secret cannot impersonate the fleet, and a single device can be revoked without touching others. No shared default passwords.
People: named accounts, strong authentication, and least privilege. A viewer can look, an operator can act within safety policy, an administrator can configure, an auditor can read the evidence — and nobody gets more than the job needs.
Server-side enforcement. Hiding a button in the interface is not security. Permissions are checked in the backend, and each customer's data is isolated from every other's.

Hard safety must not depend on software

Cyber defenses can fail, so the last line of protection should not be code that an attacker could change. Emergency stops, pressure relief, and electrical protection should exist as independent hardware paths. Software-level interlocks add to this; they do not replace it. And as in our safety-first control principle, a remote user — however privileged — cannot instruct the system to bypass a hard safety rule.

Leave evidence

An audit trail answers the question every incident review asks: who did what, when, and why? Commands, overrides, configuration changes, and logins are recorded with identity and time. Audit records are also what lets a customer demonstrate good operation to a regulator, lender, or insurer.

Manage secrets and updates deliberately

Secrets (keys, tokens, certificates) live in a managed secret store — never in source code or on a shared drive.
Updates are signed, staged, and reversible. A site should be able to roll back to its last known good configuration, and a bad update must not be able to take every site down at once.
Dependencies are tracked and patched, because most real-world vulnerabilities arrive through third-party components.

Plan for the day something goes wrong

Backups, tested restore procedures, clear on-call responsibilities, and a documented way to isolate a single site without disturbing the rest. Because the edge keeps control running locally, isolating a site from the network is a safe response — the pumps keep their protections even when the cloud connection is cut.

Security is not a feature we add to infrastructure. It is part of what makes infrastructure trustworthy.

If you are evaluating a connected system, ask how it handles device identity, who can do what, whether safety survives a network cut, and what the audit trail records. The answers say a lot.