Built for the Trust Boundary Between OT and IT
KŌJŌ Stack sits at the edge, between operational systems and the cloud. That position carries a responsibility: every zone, credential, and connection is designed with the assumption that it will be attacked.
Network Architecture
Four secured zones, one direction of trust
Industrial data moves across OT, an industrial DMZ, the customer network, and the KŌJŌ Stack control plane. OT never crosses the DMZ directly-a dedicated DMZ-forwarder pattern brokers every hop, and every connection is initiated from the inside out.
OT / Control Network
PLCs, sensors, and historians. No inbound connections are accepted from outside this zone-KŌJŌ Stack initiates every OT connection from the inside out.
Industrial DMZ
The KŌJŌ Stack runtime and its DMZ-forwarder sit here, brokering data between OT and the customer network without ever bridging the two directly.
Customer Network / Cloud
Structured data lands in the customer's own historian, lakehouse, or message bus-under the customer's control.
KŌJŌ Stack Control Plane
Fleet management and configuration are isolated from the live data path, so control-plane access never grants a route into the OT network.
No direct OT-to-cloud path exists. Every hop is authenticated, and the DMZ-forwarder pattern means a compromise on the customer network side can never reach directly into the control network.
Access Control
Role-based access, default-deny
Every identity is scoped to one of three roles. Access is denied by default-a user or integration only sees and does what its role explicitly grants. Programmatic access follows the same model through JWT bearer tokens, so an automation carries no more authority than the role behind it.
Admin
Full configuration authority-sources, destinations, pipelines, secrets, and user management.
Operator
Operates and monitors running pipelines and modules without configuration or user-management rights.
Viewer
Read-only visibility into data flow, health, and metrics.
Security Profiles
Hardened by default, not by opt-in
A single profile setting controls password policy, account lockout, CORS restrictions, and request rate limiting across the deployment. Secure is the install default-a fresh deployment starts hardened, not open.
Development
Relaxed defaults for local iteration-not intended for networked or production use.
Secure
DefaultThe install default. Enforces TLS, authentication on every endpoint, a minimum password policy, account lockout, explicit CORS origins, and request rate limiting.
Per-connection validation goes further. Individual ingress modules can enforce stricter TLS and credential validation- rejecting plaintext transports, skipped certificate verification, or hardcoded credentials on a given connection-independent of the system-wide profile.
Secrets & Certificates
Credentials never live in plaintext
Every password, API key, and certificate a pipeline needs is managed centrally- referenced by name in configuration, resolved only at the moment a connection is made.
Encrypted secret store
Passwords, API keys, and tokens are encrypted at rest with AES-256 and never written to configuration files in plaintext.
@secret runtime resolution
Configurations reference credentials by name; the real value is resolved only at runtime and is never logged or exposed in the UI or API.
Centralized certificate store
TLS and mTLS certificates are managed in one place, referenced by name across every protocol module and destination.
TLS/mTLS where the protocol supports it
Server and mutual TLS secure every cloud and historian destination, plus OT protocols that support it. Legacy control protocols with no native encryption-Modbus, EtherNet/IP, BACnet-are protected instead by network segmentation and the DMZ boundary.
Centrally managed rotation
Certificates and credentials are rotated in the store and referenced by name-a pipeline picks up the new material on restart, with no config edits by hand.
Industrial PKI integration
Designed to work with an existing certificate authority, so trust follows the same chain the rest of the plant already relies on.
Tamper-Evident Audit
Every change leaves a verifiable record
Logins, configuration changes, and module lifecycle events are written to a hash-chained audit trail. Each record carries a hash of the one before it, so altering or deleting a past entry breaks the chain and is immediately detectable-not just logged, but provably intact.
Auth events, config changes, and pipeline lifecycle are all captured-giving operators and reviewers a single, tamper-evident source of truth for what changed, when, and by whom.
Protocol & Workload Hardening
Isolation where the protocol can't protect itself
Per-protocol security guidance
Modbus, Siemens S7, EtherNet/IP, and BACnet were designed for isolated control networks, not open ones. KŌJŌ Stack pairs each protocol module with documented compensating controls-network segmentation, read-only connection modes, and firewall rules-so the gaps in the protocol itself don't become gaps in the deployment.
Process and workload isolation
Protocol drivers and workloads run as isolated processes with their own resources. A crash or fault in one module is contained-it cannot take down the runtime or any other module.
Standards Alignment
Designed and aligned to IEC 62443 foundational requirements
Role-based access, authentication policy, and tamper-evident audit logging were built with the IEC 62443 foundational requirements as a design reference-security by identification and authentication, use control, and system integrity.
This describes design intent and architecture-not a formal audit or third-party attestation against IEC 62443 or any other standard. How a given deployment measures against a standard depends on how it is configured and operated within its own environment.
Vulnerability Disclosure
Found a security issue? Tell us privately
We welcome responsible disclosure from researchers and operators. Reach out through our contact channel and we will follow up directly to coordinate investigation and remediation.