Not every enterprise network can reach the internet. Some aren’t allowed to. Others are physically constructed to prevent it.
Defense contractors operating under ITAR requirements, energy utilities running operational technology networks under NERC CIP, government agencies managing classified systems, manufacturing facilities with OT/ICS segments deliberately isolated from corporate IT — these environments share a common constraint: cloud-based security tools either don’t function or aren’t permitted. That constraint applies directly to authentication infrastructure.
The assumption that all MFA requires cloud connectivity is widespread and incorrect. It reflects the consumer and SMB origins of most MFA products, not the architectural reality of enterprise authentication protocols. TOTP — the time-based one-time password algorithm standardized in RFC 6238 — generates codes locally on the authenticating device using a pre-shared secret and the current time. No network call required. The validation happens on whatever server holds the matching secret. If that server is on your isolated network, the entire authentication flow stays inside your perimeter.
This article covers how MFA functions in air-gapped and isolated network environments, what the architectural requirements look like, and what operational considerations security teams encounter in practice.
Why Air-Gapped Networks Still Need MFA — Insider Threats, Supply Chain, Privileged Accounts
Air-gapped networks are not inherently secure by virtue of their isolation. The threat model is different, not absent.
The most widely documented case of air-gap compromise is Stuxnet — malware that reached an isolated Iranian nuclear facility via infected USB drives, propagated through Windows zero-days, and caused physical damage to centrifuges without any network connection to its operators. The attack vector wasn’t the network. It was removable media carried by personnel with physical access. Stuxnet remains the reference case because it demonstrated that air-gap isolation eliminates external network threats while leaving insider threats, supply chain attacks, and physical access vectors fully intact.
CISA’s guidance on ICS/OT security consistently identifies insider threat and privileged account abuse as primary risks in isolated industrial environments. Credentials for engineering workstations, historian servers, and SCADA HMI interfaces are valuable targets precisely because the systems they access are critical and often have limited monitoring. A single compromised privileged account in an OT environment can have consequences that network segmentation alone cannot prevent.
NIST SP 800-82 — the Guide to OT Security — recommends multi-factor authentication for remote access to OT systems and for privileged accounts accessing critical components. The recommendation explicitly acknowledges that OT environments have constraints that IT environments don’t, and addresses authentication architecture accordingly. IEC 62443, the industrial automation and control systems security standard, similarly requires access control mechanisms commensurate with the security level of the zone being protected — which for SL-2 and above typically means MFA.
The threat surface in isolated networks is narrower but the consequences of a breach are often more severe. Authentication without a second factor on privileged accounts in these environments is a documented gap, not an acceptable risk posture.
Why Cloud MFA Cannot Work in Air-Gapped Networks
Cloud MFA is architecturally incompatible with air-gapped networks — this is a fundamental constraint, not a configuration problem.
Every major cloud MFA service validates one-time passwords by sending the user’s OTP to a cloud API, which checks it against the stored token seed and returns a pass/fail response. That API call requires outbound internet connectivity. In a true air-gapped network, that connectivity doesn’t exist. The authentication request goes nowhere. The user cannot log in.
Some environments are not fully air-gapped but operate under strict no-internet policies for specific network segments — OT networks connected to corporate IT through a demilitarized zone, classified systems on separate VLANs with firewall rules blocking external traffic, banking core systems isolated from internet-facing infrastructure. In these cases, cloud MFA might be technically reachable through a proxy, but routing authentication requests for sensitive internal systems through an internet-connected proxy creates the kind of external dependency that the network segmentation was designed to eliminate.
Sub-processor disclosure is a separate issue. GDPR Article 28 requires organizations to know and document which sub-processors handle personal data on their behalf. Cloud MFA vendors’ sub-processor lists — the infrastructure providers, CDN services, and monitoring tools underpinning their platforms — can be extensive and include non-EU entities. For classified government environments and defense contractors, the question isn’t just GDPR compliance. It’s whether authentication event data for sensitive systems should transit infrastructure operated by any third party, regardless of jurisdiction.
The practical conclusion is straightforward: organizations running air-gapped or highly isolated networks need authentication infrastructure that operates without outbound connectivity. That means on-premise deployment.
Architectural Requirements for Air-Gapped MFA
On-premise MFA for isolated networks has specific architectural constraints that don’t apply in connected environments.
Full local deployment
The authentication platform — OTP validation engine, user database, token secrets, audit logs, management console — must run entirely within the isolated network. No component can require outbound connectivity for core authentication functions. This rules out hybrid architectures where the on-premise component calls a cloud API for validation or license checks.
No external API calls
This sounds obvious but requires explicit verification during product evaluation. Some “on-premise” MFA products are proxies — they receive authentication requests locally and forward them to cloud infrastructure for processing. In an air-gapped environment, this architecture fails silently: the user enters their OTP, the proxy can’t reach the cloud API, and authentication times out. The validation engine must run locally.
Offline time synchronization
TOTP validation is time-dependent — the server validates the OTP by computing what the token should be generating at the current time. Clock drift between the authentication server and the token exceeds the tolerance window (typically ±1 time step, or 90 seconds of tolerance), validation fails. In air-gapped environments, NTP synchronization against internet time servers isn’t available. Internal NTP infrastructure — a GPS-disciplined time source or a stratum-1 server within the isolated network — is typically required for reliable long-term operation. This is a standard component in classified network designs but sometimes overlooked in OT/ICS environments that are newly adding MFA.
Hardware token provisioning
Software authenticator apps can operate offline for OTP generation, but cloud backup, synchronization, and recovery features may not be available in air-gapped environments. Hardware OATH TOTP tokens are the more reliable choice: the secret key is programmed into the token during manufacturing, the token generates codes locally using only the stored secret and the device clock, and no connectivity is required at any point during normal use. Tokens are provisioned before deployment into the isolated environment. NFC-reprogrammable models (provisioned via Android smartphone in a connected environment, then carried into the air-gapped segment) allow secret key rotation without replacing the physical device.
Manual update mechanisms
Security patches and platform updates cannot be pulled automatically in an air-gapped environment. Update procedures require manual transfer — typically via verified removable media following a defined change management process. This should be evaluated during procurement: platforms that require frequent cloud-connected updates for security patches create operational overhead that compounds over time.
Clustering without external dependencies
High availability in an air-gapped environment means clustering entirely within the isolated network. A common approach is a three-node or larger configuration with local load balancing and database replication across nodes. This design provides authentication continuity if individual nodes fail and avoids dependence on external connectivity.
Protectimus On-Premise Platform is designed to satisfy these constraints. Its on-prem MFA architecture operates without external dependencies after deployment, supports hardware token provisioning for environments where mobile devices are restricted, and clusters within isolated network boundaries.
Practical Authentication Methods for Air-Gapped Environments
Air-gapped MFA deployments typically rely on OTP-based authentication methods that can operate without network connectivity. The most common approaches are TOTP, HOTP, and OCRA, which can be delivered through either hardware tokens or software authenticators depending on operational requirements.
TOTP (Time-based One-Time Password)
defined in RFC 6238, extends the HMAC-based OTP algorithm of RFC 4226. The algorithm takes a shared secret and the current Unix time (divided by the time step, typically 30 seconds) as inputs and produces a 6–8 digit code. Both the token and the validation server compute the same code independently. No communication between them is required during authentication — only that their clocks agree within the tolerance window. TOTP is the standard for OATH-certified hardware tokens and software authenticators.
HOTP (HMAC-based One-Time Password)
defined in RFC 4226, uses a counter rather than time. Each generated OTP advances the token counter, while the server counter advances after successful validation. HOTP eliminates the clock synchronization requirement entirely — useful in environments where maintaining accurate time across an isolated network is operationally difficult. The trade-off is counter synchronization: if a token generates codes that aren’t used for validation, the counter on the token advances while the server’s counter doesn’t, requiring a resync procedure. For high-frequency authentication environments, TOTP is generally preferred. For deployments where clock management is a genuine constraint, HOTP is the alternative.
OCRA (OATH Challenge-Response Algorithm)
defined in RFC 6287, extends OTP authentication by incorporating a challenge value provided by the authentication server. During login, the user enters the displayed challenge into the token, which generates a response code based on the challenge and a shared secret. OCRA can also incorporate additional inputs such as counters or time values, making it one of the most flexible and secure OATH algorithms. The trade-off is usability: challenge-response workflows are less convenient than TOTP or HOTP, which is why OCRA is used primarily in high-security environments rather than mainstream MFA deployments.
Hardware tokens
are the gold standard for air-gapped environments. OATH-certified hardware tokens generate TOTP or HOTP codes on-device with no network connectivity, no battery-draining smartphone radio, and no dependency on a mobile operating system’s security model. For critical infrastructure and defense environments where mobile devices may be prohibited in certain areas, hardware tokens provide a second factor that functions anywhere the user can physically carry it.
Protectimus offers four hardware token models for these scenarios — Slim NFC, TWO, FLEX, and SHARK — all compliant with the OATH TOTP standard and supporting 30- and 60-second time steps. These tokens are commonly used in RADIUS-authenticated OT/ICS environments, VPN gateways, and other isolated network deployments. The SHARK model supports SHA-256-based TOTP generation rather than SHA-1, which may be important for organizations with cryptographic algorithm requirements defined by internal security policies or regulatory frameworks.
Push notifications, SMS OTP, email OTP, and chatbot delivery all require network connectivity. None are viable in a true air-gapped environment. For partially isolated environments with controlled connectivity, SMS or email OTP may be available as fallback methods for specific user populations, but the primary second factor for privileged access is typically TOTP delivered through hardware tokens.
Operational Considerations — Token Provisioning, Lost Token Recovery, Audit Logging
Deploying MFA in an isolated network introduces operational challenges that connected environments handle through cloud services.
Token provisioning
In connected environments, users self-enroll via a web portal. In air-gapped environments, provisioning requires an out-of-band process: administrators either import pre-generated token secrets supplied with hardware tokens or generate secrets internally and program them into programmable hardware tokens. The token is then delivered to the user through a controlled chain-of-custody procedure. Alternatively, a provisioning workstation within the isolated network — connected only to the authentication platform, not to external networks — can handle enrollment for software tokens on approved devices. Either way, the provisioning process requires explicit design before deployment, not improvisation afterward.
Lost token recovery
A user who loses their hardware token in a connected environment opens a support ticket and gets a temporary bypass while a replacement is ordered. In an air-gapped environment, the same scenario requires a defined procedure for temporary access that doesn’t create a permanent authentication gap. Typical approaches include administrator-issued temporary OTP bypass with a hard time limit and audit logging, or a secondary hardware token held in escrow for critical accounts. NIS2 and NIST SP 800-63B both address authenticator recovery procedures — the isolated network deployment needs a written procedure that satisfies whichever framework applies.
Audit logging
Authentication event logs in an air-gapped environment stay where they belong — on infrastructure within the isolated network. This is actually an advantage for compliance purposes: logs are under direct organizational control, cannot be accessed by third parties, and are available for forensic analysis without export dependencies. The operational requirement is ensuring log storage capacity and retention policies are defined. FedRAMP High, IL5, and ISO 27001 all specify authentication log retention requirements that on-premise deployments satisfy directly.
Regulatory compliance alignment
NERC CIP-007 requires authentication management for systems within the electronic security perimeter of bulk electric systems — hardware token-based MFA on an on-premise platform satisfies this without creating connectivity to external services. MFA is commonly used to help meet access control objectives in higher-security IEC 62443 environments. NIST SP 800-82’s recommendations for OT security explicitly address authentication in environments with connectivity constraints.
Conclusion
Air-gapped MFA is possible, production-tested, and architecturally straightforward — provided the authentication platform is selected and configured for the constraint from the start.
The core requirements are not complex: local OTP validation with no external API calls, hardware tokens for environments where mobile devices are restricted or impractical, internal NTP for clock synchronization, clustering within the isolated network for availability, and operational procedures for provisioning and recovery that account for the absence of cloud-based self-service.
What makes air-gapped MFA deployments fail is not the technology — TOTP has been an open standard since 2011 and works identically with or without internet connectivity. What causes failures is deploying a product designed for connected environments into an isolated one and discovering mid-rollout that it requires outbound connectivity for license validation, cloud backup sync, or OTP processing. Evaluation criteria for any MFA platform intended for air-gapped use should include an explicit test: disconnect all external network access and verify that authentication continues to function normally. If it doesn’t, the architecture isn’t suitable for the environment.
For security architects evaluating options, Protectimus On-Premise Platform’s deployment documentation covers the clustering and integration architecture for isolated environments in technical detail.
