In less than a decade, how organizations apply multi-factor authentication (MFA) with Active Directory has rapidly evolved. What was once a specialized security technology to secure privileged accounts is now a best practice to secure all user and service accounts.

The problem is, most MFA solutions weren’t designed with implementation across all users in mind. As a result, this one-size-fits-all MFA often gets in the way of productivity for end-users and IT admins alike.

Security is important, but it can’t get in the way of business as usual. How can IT teams apply MFA so that it better balances security and productivity? The answer is to allow MFA to work in a more conditional way using granular controls. We like to call it granular MFA.

Before we dive into what granular MFA offers, let’s first step back and look at what drives the need for MFA to work in a more conditional way.

Organizations today usually implement MFA for one or more of the following reasons:

• Numerous compliance regulations mandate or highly recommend MFA, like the forthcoming PCI DSS v4.0.

• Specific requirement such as cyber insurance requirements often mandate MFA.

• MFA is a security best practice (for example, it’s part of zero trust best practices).

The driver behind MFA mandates and best practice recommendations is the way attackers now target user accounts as a primary weakness. Across almost all cyber-attacks, the login is the common point of access. For instance, with a single set of stolen or phished credentials, attackers can bypass layers of traditional endpoint and network security in ways defenders find difficult to counter. The results are all around us in a wave of high-profile cyberattacks, many of which feature authentication weaknesses as a recurring theme.

For any one of these reasons, as we mentioned above, organizations are increasingly keen to implement MFA for all users as soon as possible.

But when organizations apply MFA to all users, this magnifies any problems and productivity issues.

What’s more, the technologies for completing the second factor of authentication are diverse and come with their own pros and cons in terms of the burden on the end-user. Think of one-time codes, tokens, and push notifications, for example. IT admins may need to adjust how and when they prompt for MFA given any number of different factors, depending on which MFA method their users employ.

Another issue is that, to fulfill MFA requirements, IT admins often work within the limits of an MFA solution that defaults to prompting for MFA every time their users log in, on every connection. Further, depending on the MFA method, this often means that users are entering multiple one-time codes or presenting a hardware token repeatedly throughout the day.

The result is authentication fatigue. Inevitably, as the user experience (UX) deteriorates, frustration grows and productivity goes down.

As frustration grows, users push back against MFA, giving IT admins the exhausting task of explaining a situation they have no way of modifying without weakening security.

Now, we all know that it’s a challenge to implement and manage MFA across a range of work contexts without it becoming a barrier that adds complexity to employees’ lives. In the worst case, both sides are unhappy, and both security and productivity are compromised to some degree.

Achieving the perfect balance between security and productivity is crucial to building long-term, effective IT security infrastructures.

Of course, what that exact balance is will look different for each organization, employee and partner. So, it’s important for IT security policies like MFA to easily adapt to those different access needs and risk levels. MFA that has customized, granular contextual controls can allow IT teams to satisfy security requirements without burdening end-users with more security than is needed for a given context.

In practice, we can divide customized and granular MFA with Active Directory into two types.

• Granularity based on who to prompt for MFA, for example the user’s job role or department as indicated by the Active Directory (AD) organizational unit (OU).

• Granularity as to how or if to prompt users for MFA if one or more specific conditions apply, for example requiring MFA for users based on connection type and IP address range (internal access vs. remote access), for example.

While almost all MFA solutions allow a degree of granularity as to who to prompt for MFA, few offer the second. At least, not to the degree organizations need to minimize the burden of MFA on their teams.

In theory, using a mixture of both types of granularity should give organizations the ability to minimize disruptive MFA prompts. Unfortunately, it is not always this simple. It’s also quite hard to assess which parameters matter in advance of using an MFA solution under real-world conditions. That’s why it’s so important for admins to be able to customize granular controls in a way that’s least disruptive for their unique circumstances and user base.

Admins might want to ask for MFA more frequently in higher-risk contexts, but only once a day in lower ones. For example, employees can easily get frustrated when they’re prompted for MFA every time they step away from their workstation to make a coffee or meet with a colleague. So admins might decide that they’ll only require MFA once a day for employees who log into their office workstation, but at every connection for remote workers.

Or, admins might want to prompt for MFA when an employee who regularly works from the office logs in from home, or another new IP address.

It’s a win-win: users have an easier time authenticating and admins are still able to enforce security policies required for compliance and good practice.

MFA security doesn’t always need to conflict with usability. UserLock’s answer to this is simple: put more control in the hands of admins by increasing granularity around how, if and when to apply MFA. The greater the number of fine controls admins have at their disposal, the easier it becomes to apply distinct MFA requirements for different user contexts.

With UserLock MFA, admins can apply MFA to both internal and external workstations and servers based not only on who to prompt for MFA but also, importantly, how and under what circumstances.

In addition to configuring MFA for endpoints based on AD settings, UserLock’s granularity comes into its own in the context of MFA for remote work: for connections using Microsoft remote services such as Remote Desktop Protocol (RDP), Outlook web access for Exchange, VPN/AlwaysOn VPN, cloud app connections, and RD Web Access for IIS.

Admins can set MFA to trigger on any of these for every login, when logging in from a new IP address, for the first login only, or after an interval of n days. This can also be used to distinguish between internal and external connections in more complex ways such as external connections via an internal RDP gateway server.

With UserLock, IT admins can even choose to prompt for MFA on computers that are offline, or each time a user unlocks a device while still logged in, or for privileged users at every login. They might want to automatically ask for MFA on all remote connection types, or on users who log in without a network (LAN) connection at all.

UserLock MFA does this with easy enrollment for a range of authentication methods, including Google, Microsoft, and LastPass authenticators, or hardware tokens like YubiKey and Token2.

Single sign-on (SSO) streamlines user access to cloud apps by replacing different cloud application credentials with the user’s single authentication to the corporate network. Effectively, SSO eliminates time-consuming re-authentication. Each user spends less time accessing applications and more time working with them. When paired with MFA, administrators can balance security with productivity by specifying when to prompt users for a second factor of authentication.

UserLock also lets IT pros take granularity one step further, by pairing MFA with context-aware restrictions. Admins can choose to authorize, deny or limit a user’s access to the network, even once authenticated, based on contextual factors like location, time, and session type. These contextual restrictions further verify users’ claimed identity, and further help IT administrators to balance security and user productivity.