Is there any additional protections on top of Security Defaults we should have in place to protect from persistent overseas login attempts

Question

We're a small not-for-profit using Microsoft 365 with Security Defaults enabled, so all our users have MFA configured. However, we're seeing a consistent volume of failed login attempts from international IPs—none successful, but still concerning.

Example entries in the sign-in logs include error codes 50053 and 50126, originating from countries such as Vietnam, Ecuador, and Iraq.

As a not-for-profit, we unfortunately don't have the budget for a security expert and have limited in-house security expertise, which is why Security Defaults seemed like the best fit. From what I’ve read, tactics like location blocking, IP restrictions, or high-risk sign-in policies appear to require either turning off Security Defaults to implement Conditional Access (which feels risky given our expertise) or upgrading beyond our current Entra ID Premium P1 licensing.

Are there any additional steps we can take—without turning off Security Defaults—to further protect our accounts or reduce the volume of these login attempts? Or are these kinds of attempts simply part of the landscape we have to live with these days?

We’d really appreciate any insights or suggestions from the community.

Answer 1

Hello Bevan Calliess,

The AADSTS50126 error is triggered when a user enters an incorrect password during sign-in.

The AADSTS50053 error occurs when a user repeatedly enters an incorrect password, often originating from countries such as Vietnam, Ecuador, and Iraq, as you described. Due to multiple failed sign-in attempts, the account is flagged as risky, and the user is subsequently blocked.

You can find more information about this error here: Microsoft Entra authentication and authorization error codes.

For more details, please refer to the document on Protect user accounts from attacks with Microsoft Entra smart lockout

Using Conditional Access policies instead of Security Defaults provides more flexibility in securing user sign-ins from unmanaged devices or unfamiliar locations.

Security Defaults only enforce MFA at the time of application sign-ins and offer limited control. In contrast, Conditional Access policies provide more advanced options to secure your tenant—such as blocking sign-ins from specific locations using location-based policies.

Security Defaults, Per-user MFA, and Conditional Access policies each offer different levels of security. You can choose the most suitable option based on your organization’s security requirements.

1. Security Defaults enforce MFA at sign-in for all users but offer limited customization. They do not require Premium P1 or P2 licenses, but you cannot exclude specific users or tailor conditions.
2. Per-user MFA allows you to enable MFA on a per-user basis. However, it does not support exclusions based on applications or conditions.
3. Conditional Access policies provide granular control and allow targeting specific users, apps, device platforms, and sign-in conditions. This is the most flexible and secure option for managing access. Requires Premium P1 License at least.

For more information, please refer to the following resources on:

Blocking sign-ins based on location

Configuring risk-based policies

device-based Conditional Access policy

Answer 2

Well, the reality is that cloud services are opened to such attacks by definition, as access is available from anywhere, at any time. Conditional access and similar features can indeed help, but they act after the initial authentication, so they cannot block credential compromise. In that sense, seeing error codes 50053 and 50126 in your logs is not unusual or unexpected.

The best line of defense is to switch to passwordless, if possible. Other than that, make sure your users have a strong password configured AND an additional MFA factor, such as Microsoft Authenticator. By leveraging CA (or per-user MFA) you can optionally enforce MFA to be used at every login and a plethora of other conditions/controls, but at the end of the day the only real solution to such "brute force" attempts is to move away from using passwords... which is not fully possible in M365, currently.