The surprising details behind your MFA enforcement status

Some questions only need a yes or no answer. If you call a restaurant and ask, "Could I make a reservation for 2 PM?" Some reasonable responses would be "Yes," "No," or "We only have outside seating available. Is that okay?"

You'd likely be surprised to hear: "Yes, but a party of odd numbers should reserve a seat at the front of the restaurant, while a party of even numbers should reserve one in the back. Also, please wear white clothes and use your left foot to enter the restaurant; otherwise, you'll be rejected."

The surprise here would be twofold: First, you didn't expect such a long answer, and second, it … doesn't seem like those conditions should exist in the first place.

It turns out that multi-factor authentication (MFA) enforcement acts similarly. While you'd expect the question, "Is this account protected by MFA?" to have a simple yes/no answer, the reality is often much more complicated than that. Often, some scenarios will enforce MFA for app access, while different scenarios will allow access without MFA — sometimes intentionally, but often not so.

The problem with fragmentation

One of the major features to look for in a solution like Okta Identity Security Posture Management is the ability to track all authentication scenarios that lead to every account in your SaaS apps and understand the protection status that each one entails.

This is an easy task when allowing only a single identity provider to authenticate an application. But it becomes much more complex when you add in varying authentication policies, migrations from previous identity solutions, hub-and-spoke models, and different SaaS apps applying different rules for direct sign-ins and MFA enforcement. All of these result in multiple sign-in scenarios, making it more challenging to track — and protect — them all.

In this blog post, we’ll dig deeper into many of those sources of fragmentation, and explore their potential impact.

Authentication policies

Authentication policies, often referred to as Conditional Access Policies, are used to enforce factor requirements when users sign in to apps or perform certain actions.

There are many reasons to allow different types of factors (or even allow sign in without MFA):

• Different platforms allow for using various factors (and, as a result, some platforms may be accessible only to certain applications)
• Differentiating company-owned devices and BYOD
• Exemption for service accounts and non-human identities
• Not requiring MFA while accessing non-sensitive resources to reduce MFA fatigue

Naturally, those differences in requirements have to be considered when displaying an account’s enforcement status.

Accidental gaps in policy configuration

Different identity providers will allow you to configure authentication policies in different ways.

While Okta uses a priority-based model for setting up authentication policies, other providers will configure “global” policies with the “most severe” action taking effect.

While both methods sound equivalent on the surface, the second method makes carving out exceptions from all policies much harder, often resulting in security gaps.
 

While this example is simplistic and unlikely when configuring only a few policies, it is worth remembering:

• Big organizations often have dozens of policies in place, making it likely to miss such cases (we frequently encounter those gaps in practice when analyzing Conditional Access Policies set up in other I dentity providers).
• While it’s unlikely someone will be using uncommon platforms while signing in, platform conditions are evaluated using the User Agent, which is easily and commonly spoofed during credential-stuffing campaigns.

Alternative login methods

While the driving force behind single sign-on (SSO) is that access to all applications can be managed from a single location, there are often multiple ways to access a given account in a certain application. Let’s review some of these cases.

Direct login

Often, accounts that can access an application via SSO can also log in directly to the application (either using a username-password combination or using access keys).

While often a deliberate choice (for example, to allow emergency administrator access or during application setup), it can sometimes happen unintentionally. In some services, password access might need to be disabled per user, even if SSO is set up. In other services, administrator accounts can always be logged into directly without an option to turn it off.

The key thing to understand is that each application behaves differently, and there is no universal behavior to rely upon. If MFA is configured for an account, some applications will still prompt for it even if the user signs in through SSO, while some will only prompt for MFA if the user has signed in directly. Other services might even allow configuring which of the two behaviors will occur.

Multiple SSO providers

In many cases, certain accounts in an application can be accessed using multiple identity providers. Such cases could occur due to:

• Different subsidiaries or departments using different identity providers, with potential for overlaps in between
• Leftovers from prior identity solutions, where a migration has enabled the new identity provider but never disabled the old one
• Testing configurations used for specific accounts or before enrolling the entire organization

Sometimes, those multiple providers are known and accounted for; other times, these settings are hidden away and easy to miss.

Factor strength

So far, everything we’ve discussed has treated “MFA/No-MFA” as a binary question, but reality is more complicated than that.

With SMS messages susceptible to takeover and phishing attacks rampant, your organization may prefer to enforce only phishing-resistant factors, or even ditch traditional MFA altogether in favor of going passwordless.

Such an endeavor requires sifting through those different authentication scenarios, as it involves understanding the authentication strength in each one.

In this blog post, we uncovered the complexities behind MFA enforcement. Factors such as authentication policies, multiple SSO providers, and differences in application behaviors make it anything but a simple yes/no status.

To navigate the challenges this complexity presents, we recommend adopting a comprehensive strategy for maintaining your organization’s authentication standard and regularly verifying that all accounts are properly protected. Okta Identity Security Posture Management helps you gain visibility into unexpected authentication flows, assuring a consistent standard for authentication across your organization.

Have questions about this blog post? Reach out to us at [email protected].

Explore more insightful Engineering Blogs from Okta to expand your knowledge.

Ready to join our passionate team of exceptional engineers? Visit our career page.

Unlock the potential of modern and sophisticated identity management for your organization. Contact Sales for more information.

This blog and any recommendations within are not legal, privacy, security, compliance, or business advice. This blog intended for general informational purposes only and may not reflect the most current security, privacy, and legal developments nor all relevant issues. You are responsible for obtaining legal, security, privacy, compliance, or business advice from your own lawyer or other professional advisor and should not rely on the recommendations herein. Okta is not liable to you for any loss or damages that may result from your implementation of any recommendations in these materials. Okta makes no representations, warranties, or other assurances regarding the content of these materials.