NIST moves its identity guidelines to revision 4 and formally recognises passkeys

Three authenticator assurance levels

SP 800-63B sets the technical requirements for three authenticator assurance levels. The useful idea behind them is that not every system needs the highest one: the level should follow from the damage an impersonation of that system's users would actually do.

Passkeys are now in the normative text

NIST published interim guidance for syncable authenticators in April 2024, and revision 4 folds it into SP 800-63B as normative requirements, with a supplement, SP 800-63Bsup1, covering passkeys specifically. For an organisation weighing up moving part of its estate away from passwords, this is the official reference to cite in front of an auditor.

• A passkey is bound to the service's domain, which makes it far harder to phish than a password or a one-time code sent by message.
• Syncing across devices is what makes them practical, but it moves risk onto the account holding the sync, which then has to be protected accordingly.
• Plan the recovery path for a lost device before rolling passkeys out to a large group of users.

What the guidance says about passwords

NIST's position differs sharply from the password policy many organisations still run. The part that surprises people is the advice to stop forcing periodic password changes without cause, and to stop imposing character composition rules, because both push users towards passwords that are easier, not harder, to guess.

• Favour length over complexity, and allow long passphrases.
• Screen new passwords against lists of previously breached ones, instead of enforcing a format.
• Force a change when there is evidence of exposure, not because a timer expired.

Where to start

Most organisations do not need to change everything at once. Starting with privileged accounts and externally reachable systems usually removes the most risk for the effort involved; the password policy can then be revised to match the new guidance.