BSI-CS 108: how remote maintenance should actually be built

Germany’s Federal Office for Information Security (BSI) publishes a short recommendation called Remote maintenance in industrial environments, reference BSI-CS 108. It runs to three pages. Engineers usually come across it because someone quotes it in a corporate standard or a tender, rarely because they went looking.

It deserves a full read, because three pages of concrete requirements are worth more than thirty pages of principles. What follows is what it asks for, what has aged, and what it means on a real site.

The opening statement, still the most useful sentence

The document says plainly that established solutions based on analogue or ISDN modems, and the direct Internet connection of components such as programmable logic controllers, do not comply with the state of the art.

That was written in January 2015. It is still the sentence most worth quoting, because both practices are still out there: the modem in the cabinet for the machine builder, and the PLC with a public address because “it was quicker”. A national authority stating in writing that these fall below the state of the art carries more weight in a budget meeting than any risk score.

Architecture: five requirements

One consistent solution. In larger infrastructures especially, a single remote maintenance solution should be used. Fewer attack vectors, less complexity. The document calls the alternative uncontrolled growth, which describes rather well a site with one tool per machine builder.

A DMZ. The remote maintenance component sits in a separate zone rather than directly in the production network, and remote access must not lead to firewalls being bypassed. The firewall is there to define the address ranges allowed for remote maintenance, not to be tunnelled through by the tool installed to make support easier.

Granularity. Access should be controlled per IP address and per port rather than granted per subnet. The paper suggests 1:1 connections over SSH instead of coupling entire networks with IPsec. In practice this is the requirement most often failed: a vendor VPN that drops the supplier onto the production VLAN when they came to service one machine.

Connection establishment. The important one. Remote access should, where possible, only be initiated from the company side, outbound, with no open ports for connections from outside. Where that is impossible, access is enabled temporarily, with strong authentication, an up-to-date patch level, and organisational processes that make sure it is switched off again.

Dedicated systems. The components used for remote maintenance do that and nothing else. That rules out the familiar arrangement where the jump host is also the engineering station, the file server and the licence server.

Communication and cryptography, with an honest note on age

The paper asks for established protocols only (IPsec, SSH, SSL/TLS in current versions), points to BSI’s minimum standard for TLS 1.2, and cites Heartbleed and POODLE as reasons why versions matter.

On symmetric encryption it makes an argument specific to industry: do not settle for the minimum key length, because industrial systems stay in service for a long time. A key size judged adequate today has to remain adequate for a machine still running in twenty years. The document writes this as AES with “at least 196 bits”. AES keys come in 128, 192 and 256 bits, so read it as “more than 128, in practice 256”. The figure is odd; the reasoning is sound.

Two things in this section have aged, and it is better to say so than to quote a 2015 paper as if it were current. TLS 1.3 now exists and should be preferred, and the named vulnerabilities are history rather than live threats. For key lengths, check the current edition of BSI TR-02102 rather than the figure in the paper.

Authentication, including the requirement nobody expects

One user per account. Group accounts must be avoided under all circumstances. The wording is unusually absolute for a BSI document, and it is aimed squarely at the shared “service” account every integrator asks for.

Two-factor authentication, preferred to passwords: something you know plus something you have, such as an X.509 certificate, a one-time-password generator, a smart card or a USB token. Hardware that cannot be copied, the paper notes, gives a particularly high level of security.

A password policy the system enforces technically, not one that is merely written down. The paper is explicit that password-only authentication cannot provide more than a basic level of protection.

Then comes the requirement that always surprises people, and shows the authors knew industry. Protection against brute force is necessary, but unlike in conventional IT, temporary blocking should kick in after something like 20 failed attempts rather than three, because of the specific requirements of availability and safety.

Think about what that means. A three-attempt lockout on a remote maintenance account is an availability risk: the specialist who mistypes twice at two in the morning, during an incident, is now locked out of the machine that is down. The paper accepts a weaker brute-force posture to avoid a self-inflicted outage, and compensates elsewhere, with two-factor authentication and logging.

An IT security team applying its standard baseline to production will usually not have made that trade-off. Here a national authority makes it in writing.

Organisational requirements: where the document earns its keep

The section opens with a sentence worth putting on a slide: secure maintenance access can never be ensured by technical safeguards alone. Nine requirements follow.

• A formal risk analysis of the designed solution.
• Minimalism. Only the remote access options that are absolutely necessary are implemented, and the person responsible documents why each one is needed, a “business justification”. Applied honestly, this alone removes a good share of the remote access paths on most sites, because nobody can name a current reason for them.
• Processes for releasing connections, locking accounts when people leave, emergency procedures, and regular changes of authentication data.
• An inventory of all remote access options: type of access, systems affected, authorised persons, the specifications and processes that apply. A list of paths with people attached, not a list of tools.
• A time window. Remote access is enabled only when needed, or within a defined maintenance window (the paper mentions key-operated switches), and activation and deactivation are logged. The key switch is not a quaint detail. It puts the decision physically in the hands of the person on site, the simplest and sturdiest form of consent there is.
• A functional test at regular intervals, which is how you discover that a path has drifted.
• Rules for the maintenance personnel themselves, third parties above all: the equipment they may use (no smartphones), antivirus, firewall, hardening, patch level. And these are agreed in the contract, not merely requested.
• A patch process for the remote maintenance components. The paper closes a common argument here. A PLC often cannot be patched, but a remote maintenance component usually has no direct real-time or availability impact, so updating it is generally possible within a defined process. “We cannot patch it, it is OT” does not apply to the access box.
• Logging and alerting, covered in the next section because it is the one most sites get wrong.

The logging requirement everyone gets wrong

Logging is required for connection data and failed login attempts, evaluated automatically with an alarm where necessary, plus periodic manual review. Then comes the sentence that matters most in the whole document: to ensure auditing acceptability, it is absolutely necessary that the log data is collected at the operator and not at the party performing the maintenance.

If the record of what your supplier did lives on your supplier’s platform, it is not evidence. You cannot produce it independently, you cannot rely on it in a dispute, and it can be altered by the party it describes. On many sites the only trace of vendor remote sessions is still in the vendor’s own portal.

The joint guide on securing remote access software published by CISA, NSA, FBI, MS-ISAC and the Israel National Cyber Directorate in June 2023 lands in the same place: keep direct access to log servers, and the ability to delete or alter logs, out of reach of remote management tools. Two authorities, eight years and an ocean apart, arriving at the same control.

The case for read-only, often the real requirement

Near the end, the paper offers an option that deserves more attention than it gets. Its recommendations cover maintenance that changes something or at least requires interaction. For merely passive access (reading status information, measured values, system states) it proposes something else entirely: decouple the data through a web or FTP server that the ICS network pushes to, and that cannot itself open a connection back into the ICS network.

Raise it every time a supplier asks for permanent remote access “for monitoring”. A large share of remote access on industrial sites exists so that someone can look at values. That does not need an interactive session into the cell; it needs a one-way push. Separating the two shrinks the attack surface, and it is usually an easier conversation with the supplier than refusing access outright.

What to do with it

Three uses, in order of return.

1. An audit grid. Take your existing remote access paths and score each one against the five architecture requirements and the nine organisational ones. The failures will cluster around granularity, the business justification and where the logs live.
2. Contract language. The rules for maintenance personnel and the location of the logs belong in the next support or integration contract. For entities in scope of NIS2, supply chain security is one of the required risk-management measures, so the contract is where it becomes concrete.
3. The answer when someone proposes a modem. A national authority has written that it is below the state of the art. That ends the discussion faster than a risk matrix.

References

• BSI, *Remote maintenance in industrial environments*, BSI-CS 108, version 1.00, January 2015.
• BSI, TR-02102, Cryptographic mechanisms: recommendations and key lengths, for current key-length guidance.
• CISA, NSA, FBI, MS-ISAC and INCD, *Guide to Securing Remote Access Software*, June 2023.