diff --git a/EntraID-SmartLockout.md b/EntraID-SmartLockout.md
index 19ae7c7..ffc62b3 100644
--- a/EntraID-SmartLockout.md
+++ b/EntraID-SmartLockout.md
@@ -38,9 +38,14 @@ Great question! Let's consider two scenarios:
- Both attacker and legitimate user are locked out. During the lockout, user cannot successfully authenticate to all services relying on Entra ID (e.g., Microsoft 365, Azure Resource Manager, 3rd party integrated SaaS apps).
Because affected user's lockout status is not replicated to on-premises Active Directory, they can still successfully authenticate to all on-prem workloads relying on AD.
+**What about passwordless users? Are their account susceptible to brute force attempts and malicious lockouts?**
+Unfortunately yes, as currently you can't create an user object without specyfing its password, below creation attempt via _New-MGBetaUser_ proves that.
+
+
+
>[!NOTE]
>If you are using pass-through-authentication or ADFS (you really need that PHS project going!), above scenarios become a bit more complex as they involve real-time password verification on-premises. To avoid unnecessary account lockout, you should set lockout threshold in Entra ID to be lower that on-premises domain.
>[!TIP]
>Microsoft Entra ID also protects against attacks by analyzing more signals during each authentication attempt. Assessed data includes source IP reputation and associated malicious activity.
->If the sign-in is coming from an suspicious IP, regardless if credentials are correct, Entra returns [AADSTS50053](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes#aadsts-error-codes) error code.
+>If the sign-in is coming from an suspicious IP, regardless if credentials are correct, Entra returns [AADSTS50053](https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes#aadsts-error-codes) error code.