Air-gapped MFA under §30 BSIG: how a German public body authenticates without the cloud

Some environments are built to have no way out. No outbound path to the internet, no cloud callback, no dependency a network operator cannot see and control. For the teams who run them, that isolation is the security control, and anything added inside has to respect it rather than quietly punch a hole through it.

This is the situation a German public-sector body faced, in scope of the country’s NIS2 regime, operating a network-segmented environment where a sensitive set of business applications sits behind an air gap. The organisation was migrating from a SafeNet hardware-token deployment that had grown heavy to operate, for a user base of close to a thousand people. The requirement was simple to state and hard to satisfy: strong authentication on the isolated environment, with nothing added that would depend on a service outside the perimeter.

Why cloud-delivered MFA cannot run where there is no way out

Most multi-factor authentication today is delivered from a vendor’s cloud. The agent installed on the customer side has to reach an external endpoint to validate a factor, route a push notification, or simply check that its licence is still valid. Inside a segment with no outbound connection, those cloud-dependent authentication flows cannot complete.

That narrows the field to software that runs entirely on the organisation’s own servers, licensing included. OpenOTP, the RCDevs authentication server, and WebADM, the central console that runs and pilots the services of the suite, were installed on the organisation’s own Linux servers inside the isolated segment. Licence activation and renewal were performed offline, so the authentication service never had to call out to validate itself. Because there is no outbound path, push notifications and any cloud-routed method are off the table by design here: the second factor has to be something that validates locally, on hardware the organisation already controls.

What §30 BSIG asks for, and where multi-factor authentication sits in it

Germany transposed NIS2 late. The NIS2 Implementation Act took effect on 6 December 2025, revising the Federal Cybersecurity Act (BSIG), more than a year after the EU transposition deadline in October 2024, and with no transition period: the obligations applied from the day the law entered into force.

§30(2) BSIG sets out ten categories of minimum risk-management measures that entities in scope must put in place, appropriate and proportionate to their risk. Multi-factor or continuous authentication appears in the tenth category, and access control is included in the ninth. The other eight cover risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and development, reviewing whether the measures actually work, staff training, and cryptography.

Read against the statute, the place of MFA is clear. It is a required measure under §30 BSIG, and it is one category among ten. Strong authentication supports an entity’s obligations under the regime; it does not, on its own, discharge them. For a body already operating an isolated environment, the useful question is therefore narrower: can a strong second factor be added to that environment without introducing the outbound dependency the isolation exists to prevent.

Replacing an MFA product without discarding the existing hardware tokens

The organisation already had close to a thousand hardware OATH tokens in the field, issued under SafeNet. A common assumption when changing vendor is that the token fleet goes in the bin along with the old server, and that the project is really a re-equipment exercise dressed up as a migration.

It does not have to be. OpenOTP works with standard OATH hardware tokens, so the devices already in service were re-enrolled and kept, and nothing had to be bought or replaced beyond the natural attrition of dead units or added headcount. For a fleet of that size, in an environment where every device has to be handled and enrolled inside the isolated network, that is the difference between a controlled change of authentication server and a full hardware roll-out.

Keeping identities in the organisation’s own directories

The environment ran several Active Directory domains. Rather than copy those accounts into a separate directory of our own, WebADM connected to each domain through an LDAP mount point: the accounts were read in place and never replicated into a third-party store. Active Directory stays the source of truth, and at login OpenOTP validates the password against the organisation’s own AD before applying the second factor.

For a body that treats its directory as sensitive in its own right, this is not a detail. The identities never leave the perimeter the organisation controls, and there is no shadow copy of the user base sitting in a vendor’s system to be secured, audited, or requested separately. The authentication layer reads the directory; it does not take custody of it.

This extends to the vendor as well. OpenOTP is developed and published in Europe by RCDevs. In this deployment, the identities and authentication data remained within infrastructure controlled by the organisation, with no dependency on a non-European SaaS identity platform.

What this deployment did and did not cover

It is worth being precise about scope, because in a regulated setting the boundaries matter as much as the result. Within that scope, the deployment delivered locally validated MFA, retained the existing OATH token fleet, kept Active Directory as the identity authority, and removed any dependency on an external authentication or licensing service. It did not:

• on its own, make the organisation compliant with §30 BSIG, which spans nine further categories of measures beyond authentication;
• introduce phishing-resistant authentication, since the existing OATH one-time-password tokens were retained rather than replaced with FIDO2 devices;
• copy Active Directory identities into any third-party directory;
• rely on cloud-routed push, which an isolated segment cannot support.

After the isolated deployment

Once the air-gapped deployment was in production, the same authentication platform was extended to remote access on other, non-isolated network segments, over RADIUS, without exposing an identity provider to those segments. The core did not change. Only its reach did, from an environment designed to have no way out to segments that need controlled ways in.

---

Further reading

Regulatory sources:

• §30 BSIG, official consolidated text (risk-management measures)
• BSI, obligations for NIS2-regulated entities (the regulator’s own presentation of the measures)

RCDevs:

• Offline MFA and critical-infrastructure IAM for air-gapped environments
• NIS2 compliance with OpenOTP
• Cloud IAM and MFA products compared with an on-premise solution

---