I've been hearing in the office for quite a while that some people did not have MFA set up and did not need to use it on a day-to-day basis.
This is not news you wish to hear because MFA is all about security - passwords on their own are not really valid. But while that was the tagline, no investigation was done as to why this was the case.
Let's dig into this a little bit deeper and see what the actual cause of this no MFA is.
The Investigation
Many of these users indeed do use applications. To get visibility of what was going on, I relied on federated applications using primarily SAML.
When a user logged into a SAML application, it tells you what authentication methods were used. From the audit logs, users were indeed being successfully signed in with single factor authentication.
The company has a requirement for all connections going through Conditional Access to have MFA registered and active. However, there are caveats to this particular process, depending on how you have your network and Azure set up.
Conditional Access will only require the policies to be used if, for the majority, you are coming from a network that is included in the policies and you are actually logging in as your user so Conditional Access can assess the conditions and the flow of relevant Conditional Access policies to your session.
We had a policy that required everyone to register for MFA, which if you did not have it, upon login would interrupt your login with the typical banner "we need to secure your account."
However, for these users, this did not happen. They had zero authentication methods setup. But the question is why would that be?
The Trusted Network Problem
This is down to how you have set up Conditional Access and the named locations. If you have set up a named location and took the option for trusted network, then that means additional controls are no longer required because it's trusted. This also includes any MFA authentication policies assigned to your user.
However, if you are logging in from outside the network, these policies would still apply. So how is it many users did not have MFA enabled whatsoever?
Well this is because users were never accessing the network externally. They were using devices on the network that went through a portal that did not support MFA authentication and accepted a username and password. So in that scenario, they could log into a platform without MFA.
If they try to access a federated application, that would attempt to authenticate. Because they were on a trusted named location, it would still only require single factor authentication due to that trusted network, meaning the user in this scenario would get away with never having an MFA method applied and would not need it.
This also applied to any administrative accounts and service accounts that will not access from outside the company. This means if you have service accounts and administrative accounts that are only used inside the network and never connect from outside the network, you will also have a strong likelihood of not requiring MFA for those accounts.
The Evidence in the Logs
If we looked at a user's sign-in logs, you can see from the network being used they were logging into the portal that does not require MFA, and then they were going straight to federated applications that, due to the trusted named locations as I said earlier, also did not require MFA.
If you also looked at the user authentication report and filtered for SSPR capable and set to "no," this indicates they do not have MFA set up. The requirement for SSPR is to have at least one MFA authentication method set up. This doesn't include SMS as a form of MFA since that's considered weak authentication.
These users showing as SSPR "not capable" literally cannot reset their own passwords because they have no alternative authentication methods configured. They're completely dependent on IT for password resets because the system has never forced them to configure any form of MFA.
The Proxy Server Compound Effect
We also have a proxy server that authenticates you via a SAML token. Once you've authenticated, the token lifetime is set to essentially forever, so you never need to re-authenticate. When you connect to the Internet or an application, the proxy will respond on your behalf with the token you acquired the first time you received the token.
I've previously written about this specific issue in detail in "Authenticate Once, Access Forever: The Hidden Risk of Infinite Token Lifetimes", where I explored how certain proxy configurations create perpetual authentication states.
If you go to the homepage, you're on the Internet. If you interrupt the login process during the homepage loading, it will prompt you for authentication. But then because you're on a trusted network, the system will not ask you for MFA, meaning you are essentially excluded from MFA if you're going through this proxy server.
This means along with the named locations being trusted and the proxy also having infinite authentication with your token, this is the perfect storm to never be asked for MFA if you don't login outside the company and you're always using the proxy solution.
The Complete Picture
When you combine all these elements:
- Trusted named locations that bypass MFA requirements
- A proxy server with indefinite SAML token lifetime
- Legacy applications that only support basic authentication
- Users who never work outside the corporate network
You get a scenario where users that work from office locations can, by policy never need to configure MFA. They're not circumventing security - they're following the exact authentication flow we've configured.
Looking at sign-in logs tells the complete story: users authenticate through a login portal that does not support MFA, then when they do try to use web based applications they obtain a token from the proxy server, then that token persists. From the logs, you can see them accessing the non-MFA-capable portal, then moving to federated applications, all while remaining on the trusted network with single-factor authentication throughout.
Service and Administrative Account Risks
The pattern I've described doesn't just affect regular users. Administrative accounts and service accounts that only operate within the corporate network fall into the exact same gap.
If these accounts never authenticate from external networks, they never trigger the MFA registration requirement. They can operate with elevated privileges indefinitely without any MFA protection, simply because they're always used from "trusted" locations.
Service accounts present a particular challenge as many use legacy authentication protocols that cannot support modern authentication methods anyway. But administrative accounts - accounts with significant privileges - operating without MFA simply because they're on the trusted network represents a significant security risk.
Conclusion
This means in hindsight, saying the phrase "lots of users don't have MFA" is technically inaccurate. The more correct terminology is "users are not configured to use MFA due to our policies."
The users aren't doing anything wrong. They're following the authentication flow exactly as we've configured it. The gap exists because of how we've set up trusted networks in Conditional Access, combined with a proxy server that maintains perpetual authentication tokens.
If these users ever tried to work from outside the corporate network, they would immediately be prompted to set up MFA. But because they never do, and because they're always on the trusted network with the proxy handling their authentication, they can work indefinitely without ever configuring any MFA methods.
Moving Forward
If you're investigating similar issues in your environment, here are the key points to examine:
- Review your Conditional Access policies for trusted named locations
- Review your internal access methods to ensure they support MFA and not bypass MFA
- Check SSPR capability reports - users showing "not capable" have zero MFA methods configured
- Examine your proxy or SSO solutions for token lifetime configurations
- Identify which legacy applications are forcing you to maintain these authentication bypasses
- Determine which service and administrative accounts are affected
- Consider whether the convenience of trusted networks is worth the security trade-off
Understanding this distinction - between "users won't set up MFA" and "our architecture doesn't require them to" - is crucial for addressing the actual security gap rather than blaming user behavior for what is fundamentally an architectural decision.
This isn't a user compliance issue - it's a policy design problem that we created through our trust model and vendor recommendations prioritizing ease of use over security.