Air Gapped MFA
You set up air gapped mfa by pairing local servers with offline hardware keys. Users check in with time-based tokens or physical keys that need no internet. Most teams run a local identity server inside the closed network to check logins. They link this server to internal databases, servers, and admin consoles. Still, once a user logs in, broad role permissions often grant full system control. How air gapped mfa works in closed networks Closed networks block all outside internet traffic to pr
Gapped MFA: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up air gapped mfa by pairing local servers with offline hardware keys. Users check in with time-based tokens or physical keys that need no internet. Most teams run a local identity server inside the closed network to check logins. They link this server to internal databases, servers, and admin consoles. Still, once a user logs in, broad role permissions often grant full system control.
How air gapped mfa works in closed networks
Closed networks block all outside internet traffic to protect sensitive data and core systems. Because of this, standard cloud push alerts and text messages cannot reach the user. Teams must rely on login methods that work without an outside network link.
One common approach uses time-based one-time codes generated on a dedicated hardware token. Both the local server and the token share a secret seed and a clock. When the user types the code, the local server runs a math check. If the clocks match, the user gets into the system.
Another strong method uses physical security keys that plug into a local USB port. These keys use public and private key pairs to sign a login challenge. The local identity server holds the public key and checks the signature right away. No network call ever leaves the building during this step.
Admins also must manage the lifecycle of these tokens inside the closed room. They enroll two keys per person so a lost key does not block work. They also keep local time servers running so token clocks never drift out of sync.
Why offline login checks leave live sessions exposed
Offline second factors do a great job of proving who is at the keyboard. They stop stolen passwords from working if an attacker gets into the local room. For compliance audits, this proves that every login used two separate factors.
Still, air gapped mfa stops working the second the login check finishes. It decides who can open a session, not what happens inside that session. Once an engineer connects to a production database, they hold an active, trusted shell.
Gapped MFA: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
In many closed setups, teams share broad admin roles to get work done fast. A user who passes the login check might have rights to drop tables. They might also run a wide query that pulls thousands of customer card numbers. Native offline tokens cannot read SQL commands or block a dangerous script in flight.
Audit logs on local servers also struggle to link commands back to one person. If three admins share one local database account, the offline token only protects the host. The database log still shows the shared role name instead of the real user. Teams need a way to inspect every single query and mask sensitive fields like emails.
Managing day-to-day token operations
Running hardware tokens in a dark site takes steady hands-on work from the security team. You must keep a locked cabinet of spare keys ready for new hires. When someone leaves the team, an admin must revoke their local key right away.
Clock drift is the most common reason offline number tokens fail to work. Local servers must sync with an internal radio or GPS clock source every day. If the server clock slips by two minutes, valid codes will start to fail. Physical USB keys avoid this clock problem because they use a direct challenge response.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can smartphone authenticator apps work in a closed network?
Yes, time-based code apps work offline after you scan the initial setup code. Still, many secure sites ban phones, so teams use dedicated hardware tokens instead.
How do you fix clock drift on offline hardware tokens?
Admins run an internal time server linked to a GPS antenna to keep servers accurate. Many local identity servers also have a tool to resync a drifting token.
Does offline MFA protect against insider mistakes in a database?
No, offline MFA only checks the user at the start of the login session. You need query-level controls and data masking to stop bad commands or data leaks.