The standard says the asset owner controls access. Make it true.
IEC 62443 puts identification, authentication, use control, and auditable events at the core of industrial cybersecurity, and expects service-provider access to happen on the asset owner’s terms. Monofor enforces those controls on the access path itself: individual identities, approval-gated vendor sessions, full recording, all deployable air-gapped next to the plant.
Where IEC 62443 meets identity
IEC 62443 is the international standard family for securing industrial automation and control systems (IACS). Part 3-3 defines system security requirements (SRs) organized under foundational requirements such as identification and authentication control (FR1) and use control (FR2), graded by security levels; part 2-4 defines what asset owners should expect from the security programs of their service providers, including how remote access is consented to and controlled. Regulators lean on it too: for operators in NIS2 scope with OT estates, 62443 is the de facto answer to "how" for the directive’s technical measures.
A large share of the SRs auditors actually test are identity questions: are people individually identified and authenticated, are shared accounts gone, is remote access from untrusted networks restricted and terminable, is every privileged action attributable in an audit trail? Those are enforced by the access platform, not written in a policy binder. And because control networks are segmented or fully air-gapped by design, the platform enforcing them has to run inside the plant’s own zones, without a cloud dependency.
SRs to controls, mapped.
The IEC 62443-3-3 system requirements and 62443-2-4 program expectations with an identity dimension, and the Monofor capability that enforces each one.
Every human user and software process is uniquely identified and authenticated.
Every operator, engineer, and vendor connects with an individual, verified identity; shared "maintenance" accounts disappear because target credentials stay in the vault and are injected by the platform. External users enroll passwordless via magic link.
Vendor Privileged AccessAuthenticators are protected, managed, and strong enough for the security level.
Target-system credentials live in an encrypted vault with rotation, and are never disclosed to the user; human authentication happens at the identity layer with MFA including phishing-resistant FIDO2 passkeys, independent of what the PLC-era target supports.
Monopam VaultAccess from outside the control zone is explicitly restricted, monitored, and controlled.
Remote sessions terminate at the Monopam gateway in the industrial DMZ; nothing tunnels into the control zone. Per-vendor network allow-lists (IP/CIDR) gate both sign-in and connection start, and unreadable client addresses fail closed.
Monopam GatewayUsers get the permissions their role needs on the assets in scope, nothing more.
Access is granted per resource, not per network; vendor organizations scope who may reach what, and just-in-time approval puts a human decision in front of a connection when you require it.
Just-in-time accessRemote sessions can be terminated on demand and end automatically with the authorization.
Live sessions are visible and terminable with one click; expiry, inactivity rules, deactivation, and access-review rejections cut running sessions automatically the moment the authorization ends.
Vendor Privileged AccessSecurity-relevant events are recorded, protected, and accessible for analysis.
Every privileged session is recorded (video plus keystrokes for interactive types, statement-level audit for database sessions), tied to an individual identity, and the full lifecycle trail (invite, approval, connection, expiry, review) exports to your SIEM.
Session recordingService-provider access requires asset-owner consent and remains under asset-owner control.
Vendor invitations pass your approval flow before an account exists, every connection can require a per-session approval, the sponsor is notified on connect, and the approval trail names who consented to what, when.
Vendor Privileged AccessDünya genelinde kurumsal şirketlerin tercihi
güvence altındaki kimlik
kurumsal entegrasyon
ülke
Common questions
- Does deploying Monofor make us IEC 62443 compliant?
- No product does. 62443 also covers network zoning (zones and conduits), system hardening, patch management, and organizational processes. Monofor enforces the identification, use-control, and audit requirements on the access path, which is a large share of what assessments test, and produces the per-session evidence assessors ask for.
- Does this work in an air-gapped or fully segmented plant?
- Yes. Monofor deploys self-hosted inside your own zones, typically with the gateway in the industrial DMZ, with no SaaS or outbound cloud dependency on the access path. That is a deliberate design target: OT-focused remote-access tools that relay sessions through a vendor cloud cannot serve an air-gapped site.
- How does IEC 62443 relate to NIS2?
- NIS2 tells essential and important entities what outcomes they must achieve; for operators with OT estates, IEC 62443 is the widely accepted answer to how, and national authorities reference it in guidance. The same Monofor controls serve both: MFA, supplier access management, and auditable evidence map to NIS2 Article 21 as well; see our NIS2 page for that mapping.
- We only need vendor remote access, not a full PAM program. Where do we start?
- Start exactly there: model each supplier as a vendor organization, route their sessions through the gateway, and let expiry and access reviews govern the lifecycle. The 62443-relevant evidence (individual identities, asset-owner approvals, recordings) is produced from day one, and the same platform extends to internal privileged access when you are ready.
Kimlikleri doğru şekilde
yönetmeye hazır mısınız?
Beş dakikadan kısa sürede tam donanımlı bir deneme ortamı kurun. Kredi kartı yok, satış engeli yok.