Remote Maintenance in OT: The BSI Requirements under IND.3.2

Remote maintenance in OT is indispensable — and at the same time the most frequently underestimated entry point. The BSI module IND.3.2, "Remote Maintenance in the Industrial Environment," describes how to secure it: centrally controlled, strongly authenticated, supervised, and logged without gaps. For operators of plants, controllers, and control systems, the question is rarely whether, but how — and with which solution most of the requirements can be met without rebuilding the plant technology.

This article summarizes what IND.3.2 requires across four clusters, and shows which requirements a remote PAM platform like VISULOX covers directly at the technical level — and which remain the operator's organizational responsibility.

Why remote maintenance is the most critical entry point in OT

An operator's OT is typically decentralized: plants across multiple sites, components from numerous vendors, many of them not patchable or with long life cycles. The result is a multitude of remote maintenance access paths often pre-installed by the vendor, permanently open, and not even fully known to the operator. The BSI explicitly describes the management of these access paths in the industrial environment as confusing and error-prone.

A classic VPN or vendor tunnel authenticates a connection, not an action. Whoever is inside often reaches an entire network segment instead of exactly one machine; access paths persist for years; and logs show when someone connected — not what they did on the control system. In OT, this is not only about data, but about availability and physical safety. Our guide "VPN out, control in" shows how to switch remote access to identity- and session-based approvals instead.

What IND.3.2 requires the standard in four clusters

IND.3.2 begins with an organizational obligation (requirement A1: a uniform, central remote maintenance concept for the entire OT) and makes it concrete through technical and organizational requirements. These can be grouped into four clusters.

1. Architecture

‍A uniform, centrally administered solution. Critical components belong in a DMZ or behind a jump station, with no direct connection to the OT network. Only individual target systems (IP and port) are released instead of entire subnets; the connection is established in a controlled manner and approved manually and internally.

2. Secure communication

‍Only established protocols, IPsec, SSH, TLS sufficiently strong cryptographic methods in line with BSI TR-02102. The strength of the encryption parameters should be adjustable.

3. Authentication

‍An individual account per person instead of group accounts, strong authentication (2FA/MFA), secure passwords, and mechanisms for attack detection and against repeated brute-force attempts.

4. Organization & evidence

‍Risk analysis, the principle of minimization, governed processes for creating, approving, and revoking access, an inventory of all access paths, time windows, detailed logging with timestamps and alerting — plus the ability for plant personnel to supervise a session and terminate it if needed. Across all three protection-requirement levels: every session must be limited, controlled, and verifiable, and at elevated protection requirements up to full content recording.

From standard to practice: what a platform covers directly

IND.3.2 mixes technology and organization. This is exactly where a remote PAM control layer comes in: it sits as a central access point over the existing infrastructure and runs every remote access, internal as well as by vendors as a personally approved, recorded session.

This pays directly into the technical core of IND.3.2: access to exactly one approved target system instead of a network segment; MFA and connection to central identities via SAML/OAuth; just-in-time approvals with automatic expiry; the four-eyes principle with live monitoring and immediate session termination; a credential vault that never exposes plant access data; and an audit-proof session recording that is searchable down to on-screen content via OCR and keystroke search. This makes the evidence a by-product of every session. The product overview shows how controlled access works in practice.

Our whitepaper with the complete coverage matrix lists, line by line, which IND.3.2 requirement VISULOX fulfills and which remains open.

Where the standard remains with the operator

Honesty builds credibility: a tool does not fulfill a standard, it provides controls and evidence. The remote maintenance concept (A1), the risk analysis, detecting hidden vendor-side access, network segmentation, and contractual requirements for service providers remain the operator's task. A platform provides the technical foundation and the evidence for this and this exact division of labor is what an auditor expects, too.

Outlook: Grundschutz++ from 2026

The IT-Grundschutz is currently being fundamentally reformed. With Grundschutz++, the BSI is moving the compendium to a digital, machine-readable, and streamlined rule set; it has been publicly available since the end of September 2025 and takes effect from 2026. The previous edition, including IND.3.2, remains valid during a multi-year transition period. The form of the requirements changes, but the protection objectives stay the same limit access, secure identity, monitor activity, involve service providers, retain evidence. A control- and evidence-oriented platform therefore carries over through the change of standard and at the same time serves NIS-2, DORA, and KRITIS with the same logic.

IND.3.2 requires more than an encrypted connection for remote maintenance in OT: central control, strong authentication, supervision, and gap-free evidence. A remote PAM platform like VISULOX covers this technical core directly and produces the evidence as a by-product of every session — while the concept, risk analysis, and contracts remain the operator's duty. Whoever separates the two cleanly meets the standard verifiably and is also prepared for Grundschutz++. You'll find the complete coverage matrix in our whitepaper.

(This article does not constitute legal or certification advice.)