The Password Reminder You Should Delete

This is a site about setting reminders, so it is worth being straight about one you should probably delete: the quarterly prompt to change your passwords.

It is a habit inherited from workplace IT policy, it feels responsible, and the body that wrote the standard everyone was following says not to do it.

What does the standard actually say?

That periodic changes should not be required. NIST's digital identity guidance is explicit: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."

"Verifiers" means the service checking your password — the website, the app, your employer's system. So the instruction is addressed at the people who have been sending you those ninety-day nags, not at you. But the implication for your own calendar is the same: a recurring reminder to rotate passwords is enforcing a rule the standard withdrew.

And it is not replaced by nothing. The very next sentence sets out when a change is mandatory: "However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."

Read those two together and the shape of good practice appears. Change on evidence, not on schedule. A date on a calendar is not evidence of anything.

So what about the character rules?

Also discouraged. "Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets."

That is the whole apparatus of one uppercase, one number, one symbol — the thing that has produced a generation of passwords shaped like Summer2024! and has trained people to make small predictable edits.

On length, the guidance goes the other way and asks for generosity: a subscriber-chosen secret should be a minimum of "8 characters in length", and verifiers should "permit subscriber-chosen memorized secrets at least 64 characters in length".

Sixty-four characters. The standard is not asking for complexity, it is making room for a long passphrase — which is easier to remember and harder to attack than anything you would produce by satisfying a symbol requirement.

Then what should trigger a change?

Evidence, and the guidance is specific about where evidence comes from. Verifiers are to compare secrets "against a list that contains values known to be commonly-used, expected, or compromised" — including "Passwords obtained from previous breach corpuses."

That is the mechanism worth building a habit around. Not "has ninety days passed" but "has this password appeared in a breach, or is it a known-common one." Several password managers and browsers now run exactly this check against breach data and will tell you unprompted, which is a far better signal than a calendar.

Which reminders are worth setting?

Three, and the first one is a deletion:

• Delete the recurring password-rotation reminder. If you have a quarterly or annual prompt to change passwords across the board, it is enforcing a withdrawn rule and costing you the attention that the real tasks need.
• One one-off reminder: turn on two-factor authentication for your email. Email first, and not as a general tidiness measure — email is the account that can reset most of your others, so it is the one where a compromise cascades. Then work outward to banking and anything holding payment details. This is a finite task with an end, which is why it suits a one-off rather than a habit.
• One annual reminder to run a breach check and act on what it finds. Your password manager or browser can list the accounts flagged against breach data. The reminder is not "change everything" — it is "look at the list, and change the ones that appear on it." That is the calendar doing what the standard actually asks: prompting you to look for evidence rather than to act without it.

And one action with no reminder attached at all, because it cannot be scheduled: the day you learn a service you use has been breached, change that password. That is the moment the guidance treats as mandatory, and it arrives by news or by email rather than on a date. If you want a prompt for it, set it the same day you hear.

In ReminderIt you can set the two positive ones by message — "remind me every year on 1 February to run a password breach check" — and it reads the schedule back before saving.

Why a reminders company is telling you to delete a reminder

Because reminders have a cost, and it is not zero. Every recurring prompt you ignore teaches you a little more that prompts can be ignored, and that lesson transfers to the ones that matter — the medication, the deadline, the call to a parent. A quarterly nag you dismiss forty times is training.

The useful test for any recurring reminder is whether acting on it changes an outcome. Rotating a strong, unbreached password on a schedule does not. Enabling two-factor on your email does. Checking a breach list and fixing what it surfaces does.

What this page is not

Security advice for an organisation, and not a threat assessment. Workplace policy may still require rotation regardless of what the standard says, and if your employer mandates it you do not get a vote. Regulated industries have their own rules.

The passages quoted here are from NIST Special Publication 800-63B as published at pages.nist.gov/800-63-3 — the revision at that address. NIST maintains the 800-63 family and later revisions exist, so check the current publication before quoting it at anyone, including your IT department.

What the guidance does say plainly is worth carrying: change on evidence of compromise, not on a date; length over symbol soup; and check against breach lists rather than against the calendar.

Source: NIST Special Publication 800-63B, Digital Identity Guidelines — Authentication and Lifecycle Management (pages.nist.gov/800-63-3) — verifiers should not require arbitrary or periodic changes, shall force a change on evidence of compromise, should not impose composition rules, should allow a minimum of 8 and permit at least 64 characters for subscriber-chosen secrets, and should compare secrets against lists of commonly-used, expected or compromised values including previous breach corpuses.