Designed around the realities of OT environments.
Otector places a controlled access layer between users and OT, deployed and driven from your side. Here is how it fits together, and the principles behind it.
Three components, connected from the inside out.
Every layer connects outbound over TLS. Nothing on the outside opens a connection into the OT network.
Multi-client workspace for external service providers, OEMs and system integrators. It does not receive direct network access into any client OT environment.
Your security and management layer for assets, access, approvals, policies, credentials, sessions, recordings, files and audit data.
Lightweight on-site component. It initiates outbound connections and brokers sessions locally to authorised OT assets using native protocols.
Connections towards the OT environment are initiated through the client-controlled architecture. The Site Agent establishes the connection locally. Explore the OT VPN alternative →See controlled native-tool access →
What the design holds to.
Client-controlled deployment
The Client Portal runs in your enterprise network or your own private cloud, driven by your teams.
Outbound Site Agent connectivity
The Site Agent initiates the connection outward. The OT environment does not need to accept an inbound connection.
No direct provider-to-OT connection
The Service Provider Portal has no direct network path into a client's OT environment.
Credentials remain client-side
Asset credentials stay under client control and are used at the site, not handed to external users.
Default-deny provider access
Service providers reach only what a client has explicitly granted, and nothing more.
Granular permissions
Access is scoped to specific assets and connection profiles, not to whole network segments.
Enterprise identity integration
Users authenticate through your identity provider, with roles mapped to your groups.
Step-up authentication
Higher-risk actions, such as a service-provider launch, can require a stronger factor first.
Recorded & auditable
Session recording, secure file controls and a central audit trail provide the evidence.
Where each part lives.
- The Client Portal may be deployed in the client's enterprise network or private cloud.
- The Site Agent is deployed close to the OT environment.
- The Client Portal does not require direct connectivity to individual OT targets.
- The Site Agent establishes the connection to the asset locally.
Designed with industrial security principles and architectures in mind.
Otector is built for the constraints of OT environments. We are happy to walk your security and architecture teams through the details.
Where architecture becomes assurance.
The architecture and security principles above do more than reduce remote-access risk. They create enforceable controls and attributable evidence that support the requirements organisations face under NIS2 and IEC 62443. Explore NIS2 remote access controls →
Turn remote-access obligations into enforceable controls.
NIS2 raises expectations around access control, strong authentication, supply-chain security and incident accountability. Otector helps operationalise those requirements where they are often hardest to control: third-party and remote access into OT environments.
How Otector helps- One governed path for employees, vendors and service providers.
- Enterprise identity and step-up authentication for sensitive connections.
- Asset-scoped access without unnecessary standing permissions.
- Attributable session records to support investigation, assurance and reporting.
Apply industrial security principles to remote access.
IEC 62443 addresses security across service providers, industrial systems, products and components. Otector applies those principles to one of the most sensitive control points in OT: who is allowed in, what they can reach and what happens during the connection.
Supports your security modelSupports governed access for OEMs, integrators and other external service providers.
Supports identification and authentication, use control, restricted data flow and event response.
Otector is being developed using secure product-development lifecycle principles.
Otector components are being designed around relevant industrial component security requirements.
The security platform should not become the security gap.
Otector sits on a sensitive path into OT environments. That is why the platform is being engineered around secure development, strong identity, client-controlled credentials, outbound connectivity and hardened components. Security is not added around Otector. It is built into the architecture.
From principle to enforceable control.
Otector turns remote-access requirements into controls that can be consistently applied across sites, assets and third parties.
Otector supplies remote-access controls and session evidence that support these frameworks. It does not make an organisation compliant on its own. Formal product conformance claims will only be made following the relevant assessment or certification processes. See how Otector creates remote access evidence →
Bring your security and architecture teams.
A technical walkthrough of the deployment model, the connection flow and the controls, mapped to your environment.