Multi-factor authentication (MFA) is the gold standard for protecting vulnerable user credentials such as passwords against unwanted use. When a user logs into an account, they must present a second factor in the form of a one-time code, a physical token, or hit ” Approve” on an enrolled smartphone’s push notification.

Any type of MFA will hugely boost security, but almost every MFA solution assumes the user has an online connection to the server they are authenticating to. In other words, they can't ensure offline MFA.

Today, remote working complicates this assumption. When employees work from home or in the field, their laptops may be offline state for extended periods. If your admins can only prompt for MFA for remote work when users are online, this makes protecting offline access a non-starter.

Some organizations abandon MFA altogether and fall back instead on Windows account passwords (with or without low-level drive encryption) to protect laptops. This creates a risk of data compromise, though, in case the laptop gets lost or stolen. And while Windows password security might look ok, there is still a significant risk that attackers could bypass them using either a password-cracking tool or some form of social engineering.

From a security management and compliance point of view, the inability to enforce MFA when users are offline is not ideal. Organizations invest in MFA to increase security, especially the security of remote and privileged workers. But in situations where online MFA isn’t possible, they have to tolerate a security gap when workers are offline. Laptops are secure when the user authenticates via an MFA server, but not otherwise.

Some organizations simply take the risk, assuming MFA on other types of connections is “enough.”

But when MFA becomes conditional, this looks weak from a compliance point of view. Best practice for MFA is always to implement it consistently. When a remote worker logs into Windows in an offline state, they should always get a prompt to present a second factor if that is the required policy for their role.

Of course, several compliance standards and industry-specific regulations also require organizations to demonstrate MFA across all connection types. This is especially common in government and defense sectors. For many of these organizations and contractors, offline MFA is a non-negotiable.

Standing back, the issue of offline MFA is part of the wider problem of how to secure remote working in general. Employees connect through different channels at different times, while at other times not at all. The admin’s challenge is to manage all of this complexity through one set of policies without turning security and MFA into a barrier or confusing chore for the user. 

UserLock works offline (without internet) out of the box. So it's designed to help admins solve this exact problem. UserLock allows MFA to be implemented regardless of whether the machine has access to the Internet. This is done thanks to the micro agent on the laptop that communicates to the UserLock service via Windows protocols.

An additional feature of UserLock MFA is the ability to cope with an intermediate state between online and offline. Here, the remote user has Internet access but is not connected to the company’s domain through a secure channel such as a VPN. If a VPN is the configured session type, this would normally mean that the MFA agent on the laptop can’t connect to the UserLock server to enforce and monitor MFA policies.

UserLock’s solution to this is the UserLock Anywhere web app. This is a separate piece of software (included in UserLock subscriptions) installed on an IIS server which the agent installed on the laptop can connect to via a standard Internet connection. Once a secure IIS connection is established, this acts as an intermediary between the remote user and the UserLock server to allow MFA policies to be enforced.

This VPN-less, or off-domain MFA allows you to further secure remote access.

Enrolled users setting up MFA for the first time (done while inside the network*) enter their Windows password, then they get a prompt to configure authentication.

This asks them to choose an MFA method from the options configured by the UserLock admin, which can be one or more of the following types: TOTP via an authenticator app, push notifications via the UserLock Push app, and HOTP tokens such from YubiKey Series 5 and FIPS Series, or Token2 T2F2 ALU and Programmable Tokens (when choosing tokens, the first MFA authentication must happen using a local network session).

For example, choosing TOTP via an authenticator app requires the user to download a supported app from their mobile device’s app store (e.g., Google or Microsoft Authenticator). The user then scans the QR Code provided on the UserLock configuration screen, which generates and enters a one-time authentication code.

If allowed, the user can also choose to enable a second authentication method as well as print MFA recovery codes for emergency use. In addition, optionally, the admin can allow the user to skip MFA configuration for a given number of days after which they will be forced to choose a method.

Once UserLock MFA has been configured, the user will be prompted at each login to enter the required MFA. Importantly, this MFA authentication process remains the same regardless of whether they are offline or online.  

* Remote users who have been enrolled but have not authenticated at least once while inside the network will be denied access.

Admins can configure UserLock MFA to take account of the possibility of offline access or by connection type. 

As of UserLock 12.1, admins can choose how often they want UserLock to re-prompt for MFA, which can be after a given amount of time (minutes, hours, days), for every logon, once per day, or for a given amount of time after connecting from a new IP address.

Admins can independently configure these MFA settings depending on connection type (workstation, server, IIS server, VPN, or SaaS).

The UserLock admin dashboard reports MFA events in real-time or over a chosen time window, noting things like successful or failed MFA requests by users, or whether a user requested help.

In addition, UserLock also allows admins to apply contextual access restrictions, for example by IP address (IP range, department, device, country), time of day, or session type.

When Dobbs Peterbilt’s senior employees travel, the risk that a laptop containing sensitive data will be stolen or lost becomes a tangible security risk. The obvious way to mitigate this is to back Windows credentials with an MFA prompt. However, when a laptop is offline, that no longer works because the laptop has no way to connect to the authentication server.

This was the problem that confronted U.S. transportation company Dobbs Peterbilt. Since the company was using MFA for connected employees, it was logical from an auditing and consistency point of view to do the same for offline employee access too.

After testing other MFA solutions, Dobbs Peterbilt chose UserLock as the only solution that was both affordable and demonstrated effective MFA when laptops were offline. As a side benefit, UserLock could also be used to accommodate MFA on multiple connection types such as VPN, RDP, and IIS.

The benefit for employees is simplicity. They continue using the same MFA method they use when working inside the home network. It doesn’t matter whether they are online or offline.