Does the Applicant enforce a strong password policy (complexity, periodic rotation, and account lockout after repeated failed attempts)?
This question is often worded against guidance that current standards have moved away from. Answer the intent, then explain the design, because periodic rotation is no longer best practice.
What the carrier is actually asking
The carrier typically asks about three things together: complexity, periodic rotation, and lockout after repeated failed attempts. Two of those are still sound. Forced periodic rotation has been withdrawn from major guidance because it drives predictable, incrementing passwords, and Microsoft's own recommendation is to disable expiration where multi-factor and password protection are in place.
Why it is underwritten
Password spraying and credential stuffing are automated, high-volume, and cheap. Lockout and banned-password enforcement blunt them directly. Carriers ask the question in its traditional form because forms change slowly, but underwriters increasingly accept a modern design when it is explained rather than asserted.
Where the answer lives in Microsoft 365, Entra ID, and Azure
The enforcement points are visible in the tenant, which lets you answer this with configuration rather than with a policy document.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Entra ID | Password protection: custom banned password list and lockout threshold | Organisation-specific terms banned, lockout threshold and duration set rather than left at defaults you never chose |
| Entra ID | Smart lockout configuration | Enabled, so repeated failures from an attacker do not require locking out the legitimate user |
| Microsoft 365 | Password expiration policy | Expiration disabled deliberately where multi-factor and banned-password protection are in place, and documented as a decision |
| Entra ID | Self-service password reset with two verification methods | Enabled with two methods, so the reset path is not itself a takeover route |
| Entra ID | Accounts with password-only authentication | The residual population that a password policy alone has to protect, which should be near zero |
A defensible response is: complexity and banned-password enforcement in place, lockout configured, expiration deliberately disabled in line with current guidance because multi-factor is enforced universally. That is a stronger position than a yes that quietly means passwords expire every sixty days and users increment a digit.
What a defensible yes requires
- Lockout threshold and duration are set deliberately and smart lockout is enabled.
- A custom banned password list covers your organisation name, products, and local terms.
- The rotation decision is deliberate and defensible, whichever way it goes.
- Self-service password reset requires two verification methods.
- Password-only accounts are eliminated, because policy strength matters most exactly where a second factor is missing.
How this answer goes wrong
Two opposite errors. The first is answering yes on a tenant that has never had its lockout or banned-password settings touched, so the answer describes Microsoft defaults rather than a policy. The second is a policy so aggressive that it produces its own weakness: sixty-day expiration with complexity rules that push users to a predictable pattern, and enough friction that they write it down.
Frequently asked
Should passwords expire?
Current guidance from NIST and Microsoft says no, where multi-factor and banned-password protection are in place, because forced rotation degrades password quality. Say that explicitly if the form asks, rather than silently answering no.
Is lockout risky?
Traditional lockout can be used to deny service. Smart lockout mitigates it by distinguishing familiar sign-in patterns from attack traffic, which is why it is worth confirming it is on.
What about on-premises Active Directory?
Password protection can extend to Active Directory with a proxy agent, and it is worth deploying, because the on-premises half is otherwise governed by a domain policy the cloud cannot see.
Does a passwordless design change the answer?
It strengthens it considerably. Answer the question, then note that a defined population authenticates without a password at all, which removes the attack this control exists to blunt.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture