Ranked password policies per group

Identity → Password policy carries a second card below the organisation-wide rules: named, prioritised policies scoped to one or more groups. Write a policy for Finance that demands a longer minimum length and a shorter lockout window than everyone else, leave the group ignored by every existing policy on the default rules described in Password policy and lockout, and this is the screen that does it.

Build the policies now if you want them ready — the shape, the priorities and the group assignments will carry over unchanged once the resolver is wired into the password-set paths. Just do not treat a saved policy here as a control you can point to today.

How a person's policy is chosen

Each ranked policy names one or more groups and a priority (lower number is considered first). When the resolver runs — for whichever caller eventually wires it in — it walks the ACTIVE policies in priority order and returns the settings of the first one whose group list overlaps the person's group membership. Nobody matched by any ranked policy falls back to the organisation-wide document on the same screen, exactly as if this section did not exist.

• Membership is OR, not AND. A policy naming Finance and Contractors applies to anyone in either group, not only people in both.
• First match wins. If someone belongs to two groups that each have their own ranked policy, the one with the lower priority number governs; the other is not merged in.
• Inactive policies are skipped, the same way an inactive sign-on-policy rule is skipped rather than deleted — see Sign-on policies and the decision trace for the equivalent behaviour on that engine.

What one policy carries

The same fields as the organisation-wide policy, scoped per policy rather than per organisation:

Managing policies

The table lists every ranked policy with its priority, name, group summary and minimum length, and offers edit and delete actions per row. A new policy starts one priority step above the current highest, so an admin adding a fourth policy does not have to know the existing numbering to avoid a collision — though priorities must still be unique within the organisation, and the API refuses a duplicate.

Deleting a policy is immediate — the confirmation names the consequence plainly: "People in its groups will fall back to the organization's default password policy above." There is no soft-delete or undo; recreate the policy if you deleted it by mistake.

The endpoints and permission

GET/POST  .../password-policies              organizations:read / organizations:write
PUT       .../password-policies/{id}          organizations:write
DELETE    .../password-policies/{id}          organizations:delete

This reuses the same organizations permission family as the org-wide password policy screen and the recovery and sign-on-policy documents, rather than a narrower password-specific permission — deliberately, per the same reasoning those screens use: a policy that decides how strong a password must be is exactly as sensitive as the organisation-level document it can override for a subset of people, so it gets the same gate rather than a looser one.

What to do with this today

1. If you need a genuinely stronger password requirement for a sensitive group right now, this screen will not deliver it — there is no enforcement path yet. Compensate with a step-up requirement or a phishing-resistant factor for that group in Sign-on policies and the decision trace instead, which is enforced today.
2. If you want to be ready the moment the resolver is wired in, build the policies now — the group scoping and priorities will not need to be redone.
3. Do not use a Finance-only ranked policy as evidence in a compliance answer that Finance passwords meet a stricter bar. Until the wiring lands, every account in the organisation is governed by the same fixed rules described in Password policy and lockout, regardless of what any policy document says.