Password Policy vs. Help Desk Load
A company with 800 employees introduced a password policy: minimum 12 characters, at least one uppercase, one lowercase, one digit, and one symbol; change every 60 days; no reuse of the last 10 passwords. Within three months the help desk reports 40 password-reset tickets per day, up from 5. An audit finds that many users now write passwords on sticky notes and that several use patterns like Company2024! with a single digit changed each cycle. The security team wants to tighten the policy further to 45-day changes. The help desk manager wants to relax it to 180 days with no complexity rules.
1. Evaluate both proposals using the observed evidence, not just policy theory.
Read the worked answer
Both proposals optimize one metric and ignore the other.
- Tightening to 45 days increases forced-change frequency, which the evidence shows drives predictable mutations (
Company2024!→Company2025!) and sticky notes. That reduces effective entropy and raises help desk load further. It treats the symptom (weak passwords) by adding friction. - Relaxing to 180 days with no complexity lowers help desk load but abandons length and uniqueness, which are the properties that actually resist guessing and credential stuffing.
The evidence points to a third option: keep or increase length, drop forced periodic rotation, add breach/common-password screening, and enable MFA. The sticky notes and pattern reuse are the real failure signals.
2. Design a revised policy and state the metric you would watch to know it is working.
Read the worked answer
Revised policy:
- Minimum length 14, no mandatory character-class mixing (length over complexity).
- Block passwords found in known breach lists and company-name variants at set time.
- Change only on evidence of compromise, not on a calendar.
- Require MFA for remote and privileged access.
- Allow a password manager.
Metric to watch: reset tickets per day should fall toward the original 5, and breach-screening rejections at set time should show users are choosing screened-out passwords. A secondary check: sample audit for written-down passwords. If resets fall but users still write passwords down, the policy is being bypassed, not followed.
3. The security team argues that dropping forced rotation violates good practice. How do you respond with the data available?
Read the worked answer
Acknowledge the concern, then reframe it. Forced rotation is defended as limiting the window in which a stolen password is useful. But the observed behavior shows the rotation is producing weaker passwords (predictable mutations) and exposure (sticky notes), which enlarges the attack surface rather than shrinking it.
The defensible position: rotation without compromise detection trades a theoretical benefit for a measured harm. The measured harm here is 35 extra tickets/day and visible password disclosure. If the organization still wants rotation, pair it with MFA so a stolen password alone is insufficient - that addresses the underlying risk the rotation rule was meant to cover, without the mutation behavior.