Cloud-Native DCS

Cybersecurity

Bring your own identity and policies

Request a demo
The security layers between the outside and the plant. A stack of security layers between the untrusted outside and the plant. From the outside, your users descend through three layers, identity with your own identity provider, network with a default-deny policy and a single HTTPS port in, and transport with mutual TLS on by default. Beside them, software releases descend through the supply chain layer, signed, scanned, and shipped with a bill of materials. Both paths end at the plant, and a footer line notes that the controls trace to IEC 62443. users releases Identity Network Transport Supply chain the plant The controls trace to IEC 62443, the international standard for industrial cybersecurity
Your users cross identity, network, and transport to reach the plant, and software releases cross the signed supply chain

Sign-on runs through your own directory

Accounts live in your identity provider, and sessions are enforced at the server

Your OpenID Connect or LDAP provider governs accounts, passwords, and multi-factor policy. There is no parallel directory of users to provision or keep in step.

Sessions lock after inactivity and on demand, and signing out invalidates the session at the server.

Sign-in happens at the plant's own identity provider, and the app's header then names the identity and the role the server resolved
Re-authentication after a lock resumes the same view, while pressing the browser's back button after sign-out lands only on the sign-in page

Every API operation checks the caller's permission

A least-privilege role table ships as standard

The role table caps what every session can do. In production, even an administrator cannot delete a compliance record.

Your administrators author one declarative policy file that sets what each role may do

The policies you bring are a file your administrators author. Each role carries a tier of permissions, and the file refines that grant action by action, allowing or denying named operations such as approving a recipe or shelving an alarm. It is versioned like any other configuration and read by the control plane at startup.

The supervisor's recipe edit is refused with the denied action named, while the engineer who signs in after him saves the same edit
The operator's own entitlement list returns exactly the tightened grant the live role table shows for her role

The record cannot be quietly changed

An admission check rejects any edit, and a signature breaks if its content changes

Electronic signatures are bound by a keyed hash to the exact content they approve, so changing that content after the fact invalidates the signature. Review and approval are held to separate people, enforced independently in two places, and the signing keys are versioned so they can be rotated without breaking past signatures.

In production, an edit is rejected at admission. A delete is refused unless it is attested. A top-to-bottom figure. At the top, two mutation attempts point down at a fail-closed admission check, drawn as an accent box scoped to production. An edit is rejected at the boundary in a muted X. A delete forks on its way down: with a valid attestation it turns and crosses the boundary into the trail as an accountable archive operation. A forged or incomplete attestation fails closed at its own X on the boundary. Inside the box, the audit trail is a stack of records that only grows, fanning in to a signed manifest seal and labeled append-only and tamper-evident. admission check in production edit rejected delete attested archive forged fails closed audit trail append-only, tamper-evident
In production, an append-only, tamper-evident audit trail behind a fail-closed admission check
Archive integrity verification checks every archived audit manifest, in the product and from the command line

An isolated network with one door

Every boundary denies all traffic by default, and one HTTPS port is the perimeter's only way in

IEC 62443, the international standard for industrial cybersecurity, asks for zones and conduits. The default-deny segmentation is that model, expressed as native network policy.

Cloud-Native DCS network security zones. Nested security zones. The outer, dashed boundary is the untrusted enterprise network and internet. Inside it, a solid boundary marks the control plane. Inside that is the edge runtime out at the equipment, and innermost is the field zone with the field bus and equipment, the remote I/O modules the field signals land in. The only opening from outside is a single HTTPS port into the control plane. The control plane and the edge cross their boundary over mutual TLS, and the edge reaches the field over Modbus TCP and OPC UA. Every other path is denied by default. Enterprise network / internet Control plane Edge runtime Field bus and equipment HTTPS 443 mTLS Modbus TCP · OPC UA Only the labeled conduits are open
Nested security zones with a single HTTPS door from outside, mutual TLS to the edge, and the field bus sealed innermost

Mutual TLS between every component

A built-in certificate authority issues short-lived certificates and renews them automatically

Mutual TLS means both ends of a connection prove their identity to each other before data moves. Telemetry from the plant floor rides the same encrypted transport.

Encryption at rest is a storage-layer control, configured on the cluster you run Cloud-Native DCS on.

A built-in CA issues each component a short-lived certificate, and every connection between them is mutually authenticated. A built-in certificate authority at the top issues a short-lived, auto-rotated certificate down to each of three components stacked below it: a gateway, a historian, and a control-operator. Each component holds a certificate. To the right, the three are fully interconnected by mutual-TLS links, each carrying a padlock, so both ends of every connection authenticate. Mutual TLS is on by default. built-in CA short-lived certs, auto-rotated gateway historian control-operator mutual TLS, on by default
A built-in certificate authority issues each component a short-lived, auto-rotated certificate for mutual TLS on every connection

A signed and scanned supply chain

The build fails on any high-severity finding, and images ship minimal and non-root

Every release is signed, inventoried, and scanned before it is published. A high-severity finding stops the release. A top-to-bottom release pipeline. A version tag triggers a release. The image is signed by its digest with cosign, published with an SPDX software bill of materials, and scanned by Trivy. If the scan finds a high-severity vulnerability, the release is not published. A clean release is the artifact that runs the plant. clean version tag Sign cosign · by digest SBOM SPDX Scan Trivy high-severity finding release not published published release signed, scanned, SBOM runs the plant
Each release is signed by digest and inventoried in a software bill of materials (SBOM), with the scan as the gate before publication

Traceable to IEC 62443

A control-by-control matrix traces each control to IEC 62443-3-3

The matrix lives in the documentation and states each control's status. Cloud-Native DCS substantially implements the controls for Security Level 2, the standard's four-tier rating of protection strength, with elements of Security Level 3.

Cloud-Native DCS controls map to all seven of IEC 62443-3-3's foundational requirements. A coverage map of the seven IEC 62443-3-3 foundational requirements, each paired with the Cloud-Native DCS controls that address it, from identification and authentication through resource availability. This is not a certification. It is a traceability posture. IEC 62443-3-3 the seven foundational requirements the Cloud-Native DCS controls that address each FR1FR2FR3 FR4FR5FR6 FR7 IdentityUse controlIntegrity ConfidentialityData flowEvent response Availability your identity provider, least-privilege roles segregation of duties, electronic signatures signed releases, immutable audit, mutual TLS encrypted in transit default-deny zones and conduits audit access, operational monitoring backup and recovery, rate limiting This is not a certification. It is a traceability posture
Every IEC 62443-3-3 foundational requirement maps to named Cloud-Native DCS controls

See the full posture

The regulatory and quality side, from 21 CFR Part 11 to GAMP 5 and validation, lives on the compliance page

The Audit Trail with an approval opened to its Event Details and its 21 CFR Part 11 Electronic Signature, the signer, the signature meaning, and the HMAC digest on screen.
Compliance posture

Audit trail, e-signatures, and change control, built into the data model

Read the traceability matrices in the engineer documentation →