Cybersecurity glossary

What is the Not Before Claim (nbf)?

Learn what the JWT not-before claim (nbf) is, when tokens become valid, how nbf works with exp and iat, and how to validate early-use attempts safely with clock skew.

Identity and accessUpdated July 23, 2026
Also known asnbf claimJWT not-beforeToken not-before time

Definition

The not-before claim (nbf) is a registered JWT claim containing a NumericDate before which the token must not be accepted for processing, allowing issuers to delay validity until a scheduled time or to align token usability with a defined window.

Why not-before matters

Token lifetime is a window, not only a deadline. The not-before claim (nbf) defines the start of that window so verifiers reject early presentation.

Most APIs focus on exp, but ignoring nbf when it is present creates avoidable edge cases—especially with pre-issued tokens or skewed clocks.

What nbf is for

Delayed activation

Allows issuers to mint tokens that become usable only after a start time.

Windowed validity

Pairs with exp to define a complete acceptable time range.

Early-use rejection

Stops clients or attackers from presenting tokens before policy allows.

Clock hygiene signal

Unexpected nbf failures can reveal NTP problems across services.

Enforcing the validity window

1

Verify signature and issuer

Establish a trusted claim set before evaluating times.

2

Read nbf when present

Parse the NumericDate start bound from the payload.

3

Compare to verifier now

Reject if current time is before nbf (minus tiny allowed skew).

4

Validate exp and optional iat

Ensure the token is also not expired and freshly issued as required.

5

Reject impossible windows

Fail tokens where nbf is after exp or otherwise nonsensical.

6

Proceed to authorization

Only in-window tokens reach audience and permission checks.

Time-claim relationships

ClaimRole in the windowIf ignored
nbfWindow startEarly tokens accepted
expWindow endExpired tokens accepted
iatIssuance markerNo age/freshness signal

nbf hardening checklist

  • Enforce nbf whenever the claim is present in authentication tokens.
  • Keep skew leeway small and clocks synchronized.
  • Ensure issuers never mint nbf values after exp.
  • Include early-presentation test cases in API auth suites.
  • Treat persistent nbf failures as a possible clock or issuer bug.
  • Document whether your access tokens use nbf or rely on iat/exp only.
  • Do not allow clients to adjust nbf locally.
  • Combine with short exp for tight overall validity windows.

The practical takeaway

The not-before claim (nbf) is the start gate of JWT validity. When issuers include it, verifiers must honor it.

Validate nbf with exp and iat so tokens are accepted only inside a coherent, policy-defined time window.

Related security terms

Frequently asked questions

What is the nbf claim in simple terms?

nbf is the earliest time a token is allowed to work. If someone presents it too early, the API should reject it.

How is nbf different from iat?

iat is when the token was minted. nbf is when it becomes usable. They are often equal, but nbf can be later for delayed activation.

Do all JWTs include nbf?

No. Many access tokens omit it and rely on iat/exp. When present, verifiers must enforce it.

What format does nbf use?

A NumericDate in seconds since the Unix epoch, consistent with exp and iat.

Should verifiers allow clock skew for nbf?

A small leeway can absorb minor clock drift. Large leeway effectively weakens not-before protection.

When is delayed nbf useful?

Scheduled credential activation, pre-issued batch tokens, or aligning access with a maintenance/start window.

What if nbf is after exp?

The token can never be valid. Issuers should prevent this; verifiers should reject nonsensical windows.

References

Explore authoritative guidance and frameworks related to not before claim (nbf).

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary