How to implement MFA
Implement MFA in UserLock: prepare users, apply MFA access policies, track enrollment and help users who get stuck.
A well-prepared MFA deployment protects your accounts without locking users out or flooding your help desk. This page guides you through six steps:
Check the requirements
The UserLock Desktop Agent is installed on every workstation and server you want to protect.
Agents can reach the UserLock server. See Communication and required protocols and Enforce firewall requirements.
Prepare: choose the methods to offer and plan for users who need help.
Inform: tell users when and how to enroll.
Apply: create the MFA access policy and test it on a pilot group.
Follow up: track enrollment and help users who get stuck.
Strengthen: protect privileged accounts, connections from outside and offline sign-ins, then extend MFA to other connections.
Make these choices before you create the MFA access policy:
Offer only the methods you need. Fewer choices mean fewer support requests. Users choose their method at enrollment, and switching later requires an MFA reset. See Configure your MFA methods.
Let users skip enrollment for a few days. Enable Skip configuration in the MFA policy. This avoids lockouts and gives IT time to help users who aren’t ready.
Enable the “Ask for help” button. Users can notify IT from the MFA prompts when they can’t enroll or sign in. See “Ask for help” button.
Start with a pilot group. Apply MFA first to a small group, such as IT staff, to validate your settings before you apply it to the whole organization.
Decide when users enroll. By default, users are prompted to enroll at their next workstation sign-in, even if their MFA policy requires MFA only for some connections, such as connections from outside. To prompt users only when their policy requires MFA, set Force MFA Enrollment on Workstation to No in Advanced settings.
Tell users:
Why MFA is being implemented.
When they will be asked to enroll.
How to enroll: share the enrollment guide for their method.
What to have at hand at their next sign-in: their phone with the app, their token or their security key.
Which additional method to enroll: a second security key, an authenticator app or recovery codes, depending on the methods you enable.
Where to keep their recovery codes, if you enable them: in a password manager or on a printed copy kept in a safe place, never in a screenshot.
Who to contact if enrollment fails or they lose their device.
For users who work outside the corporate network, see Enroll remote users in MFA.
In the UserLock console, go to Access Policies ▸ Add Policy.
Follow the steps in Configure an access policy until you reach the policy type selection. When you select the users the policy applies to, select your pilot group.
Select Multi-factor authentication to open the MFA policy form.
Set MFA application to Enabled.
Under Configuration mode, select Distinct setting per session type to set separate rules for Workstation and Server sessions.
Set the Connection type for each session type.
Set the Frequency.
Optionally, enable Skip configuration to make onboarding easier.
Apply the policy and test it with your pilot group.
For a description of each parameter, see the Multi-factor authentication (MFA) access policy reference.
After you apply the MFA policy, check who has enrolled and who still needs to.
Go to Environment ▸ Users and open the Audited by UserLock tab.
Select Filters.
Under Conditions, select MFA method:
To list users without an MFA method, select None.
To list users with an MFA method, select Is not, then None.
Add other filters if needed, then select Apply.
Check the MFA configuration column to see which methods each user has enrolled.
To check this list regularly, save the filtered view.
The MFA events report lists all MFA-related actions through predefined views.
Go to Reporting ▸ MFA events.
Select the time period. The default is the last 7 days.
Select a predefined view.
Add Filters if needed.
View name | Description |
|---|---|
MFA configuration skipped | The user was prompted to enroll but selected Skip (if enabled). Shows who postponed enrollment. |
MFA help requests | The user selected Ask for help while enrolling or validating MFA (if enabled). Shows who needs assistance. |
MFA cancelled | The user cancelled the MFA prompt before validation. Can point to confusion, technical issues or aborted sign-ins. |
MFA successful | The user validated MFA. Confirms adoption progress. |
MFA failed | The user failed MFA and couldn’t sign in. Helps detect authentication issues or suspicious activity. |
Some users get stuck, for example when they can’t enroll, lose their device or replace it. From any user view in the console, you can:
Temporarily disable MFA to restore access, for example if the user forgot their device. Use the shortest possible duration.
Reset MFA configuration when the user must enroll again, for example after losing or replacing a device, token or security key. The user enrolls again at the next sign-in, including any second security key.
⚠️ Important
A computer applies an MFA reset only at its next contact with the UserLock server. Until then, a lost security key can still be used to sign in offline on that computer.
If you enabled the “Ask for help” button, you’re notified by popup, by email or in the console when a user needs help. You see all requests in Activity ▸ MFA help requests, where the same actions are available.
If users struggle to enroll, share the enrollment guide for their method.
Administrator and service accounts have elevated rights and are the highest risk if compromised.
Create a dedicated MFA policy for privileged users, by group, OU or account.
Require MFA at every logon for all session types.
💡 Tip
To avoid being locked out by a policy misconfiguration, create an emergency account (for example ULadmin) with full UserLock console permissions and MFA disabled.
Network intrusions often start with stolen credentials used from outside the organization.
Create a permanent MFA policy for the Everyone group.
In Connection type, select From outside.
Set the MFA frequency:
Workstation sessions: every logon
Other sessions: once per IP address (first logon of the day)
Any sign-in from outside the network then requires MFA.
⚠️ Important
By default, if the Desktop Agent can’t contact the UserLock service, no access policy applies, including MFA.
To keep users protected when they work away from the corporate network:
Configure UserLock Anywhere so agents can reach the UserLock service over the Internet when no LAN or VPN connection is available.
If possible, let users connect to the VPN from the Windows sign-in screen, so the agent reaches the service before authentication. See Connect to VPN before logon.
When no network connection is available, require MFA offline:
Go to ⚙️ Server settings ▸ General.
Set it to Ask for MFA or Force MFA, depending on your security needs.
Users already enrolled in MFA who signed in at least once while connected to the corporate network are then prompted for MFA even offline. With a FIDO2 security key, offline sign-in works only on a computer where the user already signed in online with that key, and the user always enters the key’s PIN.
UserLock can also require MFA on other connections. Each one has its own requirements:
VPN: require MFA for VPN connections through the UserLock NPS agent.
Single Sign-On (SSO): require MFA when users sign in to SaaS and web applications through SSO.
IIS Applications: protect web applications such as Outlook Web Access or RD Web.
UAC prompts: require MFA when users perform actions that need administrator consent.
RemoteApp: require MFA when users launch or reconnect to published applications.
RD Gateway: secure Remote Desktop access through gateway servers.