NIST SP 800-63B-4 and the minutes after login: what the standard now says about session monitoring

NIST Special Publication 800-63 is the US government's digital identity guideline, and much of the private sector uses it as a reference point even when it doesn't have to. Volume B covers authentication: how someone proves they control an account. The fourth revision, SP 800-63B-4, was finalised in 2025.

Most commentary on the revision focused on passwords and phishing-resistant authenticators. This post is about a quieter part that has become more relevant since: what the standard says about the session after authentication, and in particular session monitoring.

Why this section matters now

In October 2026, large US banks reported AI agents operating inside customer accounts, according to Axios. In each case the agent had signed in with the customer's real credentials. Authentication worked exactly as designed. The problem started after it.

At the same time, the broader traffic picture has shifted. Thales's 2026 Bad Bot Report found that 53% of internet traffic in its dataset was automated, and that 46% of account-takeover attacks targeted financial services. A standard that only governs the login moment leaves the rest of the session to each organisation's judgement. 800-63B-4 says something about that rest.

What the session chapter says

Sessions have limits

The guideline requires a definite reauthentication timeout for every session, scaled by assurance level. At AAL2, the level that requires two authentication factors, the overall timeout should be no more than 24 hours. Reauthentication restores confidence that the subscriber is still the one in control, at intervals.

Session monitoring is a recognised risk-reduction measure

The newer part is section 5.3. It defines session monitoring, also called continuous authentication, as “the ongoing evaluation of session characteristics to detect possible fraud during a session.” A relying party (the website or app) may perform it, alone or with its identity provider, as a risk-reduction measure. The guideline says indicators of potential fraud may be used at all assurance levels.

It says what to do on detection

When monitoring finds possible fraud, the relying party “SHOULD act in conjunction with the CSP, IdP, or verifier to reauthenticate, terminate the session” or notify support staff. In other words, the response NIST describes is a step-up or an end to the session, not silent logging.

It comes with a privacy warning

NIST lists several kinds of characteristics that might be evaluated, and immediately adds: “Most of these characteristics have privacy implications.” Collecting, storing and processing them must be covered by the privacy risk assessment described in section 7 of the same volume.

How to read it

Three points are easy to miss.

1. It is permissive, not mandatory. Session monitoring is something a relying party “may” do. The standard recognises it; it does not require it.
2. It frames the session, not the login, as where fraud happens. The definition is about detecting fraud “during a session”. That is a quiet acknowledgement that a correct login is not the end of the risk.
3. Privacy is a condition, not a footnote. The way a session is monitored matters as much as whether it is. A control that learns a great deal about who someone is to decide whether they are present fails the spirit of section 7.

What it implies for agents in valid sessions

800-63B-4 was not written with consumer AI agents in mind, but its structure fits the problem well. An agent that signs in with a customer's password produces a perfectly authenticated session. If anything is to tell the difference between the customer and their agent, it has to happen after login, during the session: exactly the space section 5.3 describes.

The standard's prescribed responses also map neatly. Reauthentication with a phishing-resistant authenticator, such as a passkey, is a step an agent holding a password cannot easily complete. Ping Identity's chief executive made the same point to USA TODAY in October: “Passkeys and biometrics ensure that the human is the one authenticating.”

What the standard leaves open is when to ask. Reauthenticating on every action would make online banking unusable. Never reauthenticating leaves every action to whoever, or whatever, holds the session. The practical answer is to check at the moments that matter, such as withdrawals, payee changes and credential resets, and to step up only when the evidence for a person being in control is weak.

Where HEIP fits

HEIP is built around the shape 800-63B-4 describes, with the privacy condition taken seriously. It looks at how a page is being used, not who is using it: no keystroke content, no form values, no names, emails, faces or voices, and no cross-site fingerprint. At a sensitive action, the platform's server asks HEIP whether a person is at the controls, and gets ALLOW, STEP_UP or DENY, with reasons. STEP_UP is the standard's “reauthenticate”, asked only when it is needed.