---
title: "Does the Applicant enforce a strong password policy (complexity, periodic rotation, and account lockout after repeated failed attempts)?"
url: https://insuranceposture.com/questions/access-control/applicant-enforce-strong-password-policy
category: "Access control and privilege"
canonical_key: q_pwd_003
evidence_state: partial
updated: 2026-08-24
---

# Does the Applicant enforce a strong password policy (complexity, periodic rotation, and account lockout after repeated failed attempts)?

URL: https://insuranceposture.com/questions/access-control/applicant-enforce-strong-password-policy
Section: Access control and privilege
Evidence state: Partly verifiable from your tenant

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 |

**Answer yes, then explain**

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.

## If this answer turns out to be wrong

Privileged access answers are read alongside the multi-factor block, and an inaccuracy here is usually argued the same way: that an accurate answer would have changed the terms. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [how materiality is decided](https://insuranceposture.com/glossary/materiality). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary).

## 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

- [What secondary factor method is used for MFA (SMS / Authenticator / Hardware key / Biometric)?](https://insuranceposture.com/questions/multi-factor-authentication/secondary-factor-method-mfa)
- [Are master/privileged passwords used to access client systems and IT infrastructure unique and not reused?](https://insuranceposture.com/questions/access-control/master-privileged-passwords-access-client-systems-infrastructure-unique-not)
- [Is multi-factor authentication enforced on all email access?](https://insuranceposture.com/questions/multi-factor-authentication/multi-factor-authentication-enforced-email-access)
- [Are all accounts associated with legitimate processes or current users (no orphaned/stale)?](https://insuranceposture.com/questions/access-control/accounts-associated-legitimate-processes-current-users)

---

Insurance Posture by SecValley. https://insuranceposture.com
The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished.
SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact.
Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.