How to set up two-factor authentication without the cloud

Two-factor authentication without the cloud works perfectly well if an organization is prepared to own the verification servers, key material, time sources, and recovery procedure. For administrators, I would not build it around codes from a phone. The primary method should use a hardware cryptographic key or smart card, with TOTP reserved for compatibility and a planned fallback.

The main mistake starts when a company buys a box of keys before documenting its entry points. Interactive domain sign-in, VPN, SSH, RDP, the hypervisor console, and network equipment panels use different protocols. One token may hold several credential types, but that does not make them one system. First decide where the second factor will be verified, what happens when the domain connection fails, and who can restore access without turning a recovery password into a permanent bypass.

What a local authentication system looks like

A local system does not need the internet, but it does need its own trusted verifier. In a minimal design, the account remains in the directory while a separate component checks proof of hardware-key possession or a shared TOTP secret. VPN gateways and other remote entry points call that component through RADIUS, LDAP, Kerberos, or a local PAM module. Logs, configuration backups, and time sources also stay inside the organization.

It helps to separate the system into four roles. The directory owns identities and groups. A verification node accepts the second factor. The access point enforces the decision and does not allow a spare route. The enrollment process binds a particular authenticator to a particular administrator. If one server performs all four roles, its failure blocks access, while its compromise gives an attacker both accounts and secrets.

A critical environment needs at least two verification nodes in separate failure zones. They must receive the same policies and current device-revocation records, but they do not need internet access. Backing up a TOTP database or certificate authority only helps when the protected encryption keys and a tested recovery procedure are included. A database copy without its key is useless, while a database and key in the same archive are far too convenient for a thief.

Before choosing a product, draw up a table of entry points. For each row, record the protocol, current identity source, MFA method, behavior without the network, log location, and owner of emergency access. The table quickly exposes that a web panel supports TOTP, SSH understands FIDO keys, and an old console accepts only a password. That final row determines the actual protection of the administrative environment.

A hardware key can mean three different things

Choose a hardware key for local infrastructure by protocol, not connector or case shape. Vendors often group FIDO2/U2F, a PIV-compatible smart card, and a hardware OATH-TOTP generator under the same label. These modes solve different problems and leave different records on the server.

Keep the differences in a short reference:

• FIDO2/U2F stores a private key for a specific service, and the service verifies a signature and challenge. This mode fits web sign-in, SSH, and PAM.
• PIV or a smart card stores a private key and certificate checked by PKI, Kerberos, or TLS. This mode fits domain sign-in, RDP, and VPN.
• OATH-TOTP stores a shared secret and time counter, while a local TOTP server compares the code. This mode is needed for older VPNs and applications.

FIDO2 provides strong phishing protection when the protocol binds the response to the verifier's name. NIST SP 800-63B explicitly distinguishes that cryptographic binding from manual entry of a one-time code. An attacker can solicit a valid TOTP and immediately relay it to the real VPN, while a FIDO signature for a fake address will not work at the genuine address.

PIV uses certificates and fits Active Directory, RDP, and TLS client authentication well. That compatibility comes with a complete PKI: certificate templates, trusted roots, revocation-list publication, renewal, token inventory, and protection of the certificate authority key. If nobody owns CRL and domain-controller certificate expiry, smart cards will stop admitting administrators at the least convenient moment.

A hardware TOTP token is better than an app on a personal phone for possession and inventory, but its protocol still uses a shared secret. The server that verifies a code needs the same seed. A leak of that database allows attackers to clone generators without stealing physical devices. A hardware case does not turn TOTP into a public-key design.

During procurement, check the required modes on the exact OS and client versions, the ability to set a PIN, attempt limits, the reset procedure, a unique serial number for inventory, and a way to update firmware inside an isolated network. Do not buy a mixed fleet without a reason. Two identical-looking keys with different applets create more support errors than they save in purchasing.

TOTP works offline but moves risk to the server

TOTP is easy to deploy locally because the algorithm needs only a shared secret and synchronized time. RFC 6238 defines the value as HOTP over a time counter and recommends a 30-second step. The standard requires a unique secret for every generator and recommends accepting at most one adjacent step for transmission delay. Do not expand the window to several minutes for convenience. Every extra step extends the period in which a stolen code remains useful.

Verification nodes should receive time from at least two internal sources, and those sources need a controlled upstream reference. Monitor synchronization failures as well as current offset. After a virtual machine is restored from a snapshot, its clock may jump backward, turning an ordinary infrastructure fault into a sign-in outage for the entire on-call shift.

Do not store seeds in clear text in the directory, a configuration repository, or a support ticket. The verification server needs a reversible form of the secret, so ordinary hashing is not enough. Encrypt the database with a separate master key, restrict the service account, and keep the data backup apart from the master-key backup. A directory administrator should not automatically gain the ability to export every TOTP secret.

Enrollment through a QR code also transfers the secret itself, not a harmless picture. Perform enrollment at a managed workstation after an in-person identity check or an equally strict alternative. Do not send the QR code by email or leave it in a ticketing system. After enrollment, ask the administrator for two consecutive codes, destroy the temporary secret carrier, and record the token identifier rather than the seed.

TOTP has a sensible role in equipment that does not understand certificates or FIDO, an emergency VPN client, and a migration period. Do not present it as equivalent to a hardware signature. NIST considers OTP resistant to replay of an already used value but not resistant to phishing because the user manually gives the code to a verifier. That distinction changes the protection, not merely the terminology.

Domain sign-in needs PKI, not only a key

In Active Directory, a dependable local path for interactive sign-in uses a smart card or PIV mode with a certificate. The domain controller maps the certificate to an account and validates the trust chain. Do not treat an ordinary FIDO2 key as a direct smart-card replacement for classic domain sign-in. Without a supported credential provider and a separate design, Windows will not accept it simply because someone inserted the key into a USB port.

Microsoft's smart-card sign-in documentation requires the issuing certificate authority to appear in the NTAuth store and domain controllers to have suitable certificates. The client and controller must trust the root. The user certificate needs correct account mapping and key usage, and revocation information must be available. A bad UPN, chain, or CRL often appears to the operator as an unhelpful message that the credentials could not be verified.

Revocation checking deserves its own test. If a CRL publication point cannot be reached or the list has expired, sign-in may fail even with a working key and correct PIN. Place CRLs inside every required network zone, set a validity period that leaves enough time to restore the certificate authority, and alert operators well before Next Update. Do not disable revocation checks for availability. A lost certificate would then keep working until it expires.

Use the built-in command on a test workstation to inspect the card and chain:

certutil.exe -scinfo

In the output, look for the detected reader, key container, sign-in certificate, chain to a trusted root, and revocation-check result. The utility seeing the device does not prove that domain sign-in is ready. Run the check from every zone and under an account that matches the real administrative profile.

Enable the "smart card is required for interactive logon" policy in stages. First issue two registered tokens to each administrator, test workstation and RDP sign-in, and then enforce the requirement for a pilot group. Do not begin with built-in or service accounts. Their purpose and technical constraints need separate analysis.

A laptop disconnected from the domain creates a separate case. Microsoft describes offline sign-in as a check of cached credentials, not a new online certificate validation by a domain controller. Test the cache policy, certificate lifetime, CRL access before disconnection, and post-revocation behavior on your Windows build. Nobody can promise immediate key revocation on a machine that receives no new data.

On Linux the second factor must survive an encrypted home

Linux can verify a hardware FIDO/U2F key locally through PAM, but the mapping file cannot hide somewhere the system reaches only after the user's sign-in. The pam_u2f manual specifically warns that placing the mapping file in an encrypted home directory makes sign-in impossible when the directory opens after authentication. For system sign-in, keep mappings in a protected file that root can read before mounting the home directory.

A minimal PAM line can look like this:

auth required pam_u2f.so authfile=/etc/security/u2f_mappings cue

The word required matters. A second-factor error must fail the whole stack even if the next module accepts the password. Module order varies by distribution and entry method, however. Keep a root console open, validate pam_u2f syntax, file permissions, and two keys for a test user, and only then apply the change to SSH, sudo, or a display manager.

For SSH, native security-key support in OpenSSH is usually simpler. Create the key at the administrator's workstation and send only the public part to the server:

ssh-keygen -t ed25519-sk -O verify-required -C "admin@infrastructure"

The expected interaction asks the administrator to insert the device, touch it, and perform user verification with a PIN when supported. The verify-required option makes the server require the local user-verification flag, rather than a physical touch alone. Before a broad rollout, confirm that the client and server OpenSSH versions support the selected key type, and retain a separate console-only emergency route.

Do not add one public key to several people's accounts. The SSH log will prove only that someone used a shared key, not which operator did it. Every administrator needs an individual account and two personal tokens. Log privilege elevation through sudo separately so the sign-in and the administrative action do not merge into one vague record.

Close remote access at the first entry point

Verify the second factor at the VPN gateway, bastion, or RD Gateway before administrative traffic reaches the internal network. If the VPN accepts a password and only one server's web panel asks for MFA, a stolen account can already scan internal addresses and attack protocols that do not require the second factor.

A common cloud-free VPN design has two local RADIUS nodes, a directory, and the selected MFA module. The gateway sends a RADIUS request, the verification node checks administrative-group membership and the second factor, then returns an approval with the smallest required access profile. Configure separate RADIUS secrets for every client, restrict request sources with the firewall, and protect the gateway's management protocol separately from the user VPN.

Not every VPN protocol carries two fields conveniently. Some clients join the password and TOTP into one string, others support a separate challenge, while a hardware signature needs a different exchange entirely. Test the exact client, including the mobile fallback, before choosing a verification server. A checkbox saying "RADIUS supported" does not explain how the user enters the second factor or whether the gateway can distinguish a bad password from a bad code.

For RDP, the smart card can stay with the administrator. Remote Desktop Services redirects calls from the remote session to the local reader. Microsoft documentation lists separate requirements for KDC certificates, trusted roots, and the UPN when signing in across domains. Test direct RDP, gateway access, and reconnection to an existing session as separate cases. Blocking the clipboard does not replace controls on credential-device redirection.

For SSH, use the hardware key at the bastion and disable password sign-in for the administrative group after the pilot. I would not make agent forwarding the default. A remote node can ask the local agent to sign requests for as long as the connection remains active. Prefer the next hop with a short-lived SSH certificate or a separate key whose policy limits its destination.

Logs need to connect the request at the external gateway, the MFA decision, the domain account, and the target session. Synchronize the clocks of all four sources. A record saying "code accepted" without a token name and request identifier contributes little to an investigation, while a shared emergency account hides the person at the exact moment when risk is highest.

Recovery access must not become a quiet bypass

A practical fallback starts with a second personal hardware key, enrolled at the same time as the first and stored separately. That is simpler and safer than urgently disabling MFA at night. An on-call team's spare key may stay in a controlled room with an issue log, but it should still be bound to one person rather than a shared account.

A second recovery level is needed when the entire MFA system fails. Create one or more emergency accounts that are unused in routine work, have long random passwords, and do not depend on the same verification node. Split password retrieval between two responsible people or use a protected vault with dual control. Every retrieval must immediately raise an alert over an independent channel.

One-time recovery codes make sense only when the system stores strong hashes, accepts each code once, and records its use. A printed list beside the server turns possession of paper into full administrative access. For infrastructure, I prefer a second key and a formal emergency account because they are easier to inventory, revoke, and test during exercises.

The fallback must not repeat the same failure cause. Two TOTP applications do not help when the verification database is damaged. Two smart-card certificates do not help when the CRL has expired. An emergency password in a cloud vault does not help an isolated site. For each method, record dependencies on the directory, PKI, DNS, time, network, storage, and specific people.

Test emergency access on a schedule, but do not turn the test into routine administration. After every use, change the password, close temporary firewall rules, revoke issued sessions, and examine the cause. If an emergency account is used every week, it is not a fallback. It is a poorly observed primary route.

Speed of revocation matters when a device is lost

A lost key does not mean instant account compromise if a PIN protects the device and an outsider does not know the password. The support team should not speculate about the finder's intentions, though. It needs to remove the key's association with the user quickly, revoke the certificate when PKI is involved, and check whether anyone used the device after the reported loss time.

A workable procedure has five actions:

1. Verify the reporter's identity through a prearranged procedure that does not use the lost device.
2. Record the time, serial number or credential ID, accounts, and presumed location of loss.
3. Disable the specific authenticator in every verification system, revoke its certificate, and publish a new CRL.
4. End the owner's active VPN, web, SSH, and RDP sessions, then review events since the last known legitimate use.
5. Issue a new primary key through normal enrollment and return the backup key to reserve after testing it.

Do not automatically disable the whole account if that would leave a site without its only on-call administrator. Base that decision on evidence of password theft, suspicious sessions, and the availability of another operator. If someone demonstrably used the lost key, disabling the account, changing related secrets, and investigating the incident become mandatory.

For FIDO, delete the registered credential ID or public key. For PIV, revoke the certificate by serial number and deliver a current CRL to every verification node. For TOTP, remove the seed and change the password if an attacker may have solicited the code alongside it. Crossing the device number out of an inventory spreadsheet is not enough.

An exercise should begin with "the on-call engineer lost the primary key and is away from the office" and end with confirmed access through the backup plus full revocation of the missing device. Measure the time to find waits on a single approver, an inaccessible safe, or a CRL that can only be published manually from a powered-off server.

The pilot should break the design before production

A good pilot tests failures as well as successful sign-in. Select several administrators with different workstations and include every access type: local console, VPN, SSH, RDP, privilege elevation, hypervisor management, and network equipment. At each point, try the primary key, backup key, wrong PIN, locked token, expired certificate, and unavailable verification node.

Stop one RADIUS node, disrupt time synchronization on a test server, make the CRL unavailable, and disconnect a workstation from the domain. Document the expected behavior before the test. If the team decides during the outage whether it should allow a password when MFA fails, the design is not ready.

Check observability. For one attempt, an operator should find the user name, device identifier, access point, result of each factor, and failure reason. The log must not contain a TOTP seed, PIN, recovery code, or full RADIUS password. Give log access to incident investigators, and separate policy-changing rights from event-viewing rights.

After the pilot, document issuance, replacement, revocation, certificate renewal, and employee exit. State who may enroll a new factor and what identity evidence they require. The ability to add a key after a single password sign-in defeats the entire design, especially for a broadly privileged administrator.

Deploy in groups and retain a tested recovery console that user networks cannot reach. GSE can select a local server platform and integration design for this environment, taking the existing infrastructure and support requirements into account. The organization's risk owner still has to decide which recovery route is acceptable.

Choose from protocols and the failure model

If the infrastructure mainly uses current SSH and web interfaces, I would choose FIDO2 keys with PINs and personal accounts. PIV or smart cards with a properly maintained PKI make more sense for classic Windows domain sign-in and RDP. TOTP works as a compatibility layer for systems that do not understand cryptographic keys, but its seed database needs protection comparable to an administrative password vault.

Do not demand one literal method everywhere. Demand the same result: two independent factors at the first administrative entry point, a personal attribution for every action, rapid revocation, and a tested fallback. Protocols under that rule can differ. Otherwise, one old device will force weaker protection across the whole environment.

When comparing products, ask for offline documentation, supported protocol and version lists, the backup export format, protection of master keys, an audit trail of administrative changes, and behavior when a licensing or update server is unavailable. The phrase "on premises" guarantees nothing by itself. A product may check its license through the internet, download dependencies during recovery, or keep part of its configuration at the vendor.

Run the final acceptance test with the external connection physically unplugged. Enroll a test key, sign in through every administrative point, revoke the device, restore a verification node from backup, and apply the emergency procedure. If any step needs unplanned outside access or an unknown password, the system is not yet autonomous.

Make the uncomfortable decision before procurement: when MFA fails, will the organization prefer denied access or a password bypass? For an administrative environment, a separate and tightly controlled fallback is safer than allowing every gateway to fall back to passwords. Otherwise, the first outage teaches the team to bypass the protection it has just deployed.