NIST IR 8587 Final: Token Lifetimes, Key Rotation and CI/CD Rules

On 15 September 2026, NIST published the final version of NIST IR 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse," written with CISA. It gives federal agencies and the cloud service providers they use concrete targets for token lifetimes, signing key rotation, audience checks and token handling in CI/CD. NIST says it responds to tasking in Executive Order 14306 and builds on the IA-13 control added to SP 800-53 in Release 5.1.1.

What's affected

The report covers identity and access systems that rely on digitally signed assertions and tokens using asymmetric cryptography: SSO, federation, API access and workload access. Systems built on symmetric schemes, stateful sessions or API keys are mentioned where relevant but are out of scope for its controls. It also says organizations should apply the guidance when AI agents use signed tokens to reach systems, data, tools or APIs.

NIST's announcement points to the incident behind this work: attackers forged tokens using a single stolen commercial signing key and used them to get into agency email, reportedly taking more than 60,000 emails from one agency.

Be precise about force. Section 1.2 says conformance "remains voluntary for CSPs and federal agencies unless otherwise determined through policy, including OMB policies, or other binding agreements (e.g., contracts, grants)." The MUST and SHOULD language below defines what it takes to claim conformance with the guidelines. It becomes a hard requirement for you only if a policy or contract makes it one.

The key recommendations:

• Token lifetimes. Access and identity tokens MUST have defined, short lifetimes, and expired tokens MUST be rejected. NIST recommends they SHOULD be valid for no more than one hour, and CSPs SHOULD make the lifetime configurable.
• Refresh tokens. For interactive human sessions, refresh token lifetime SHOULD NOT exceed the reauthentication time frames in SP 800-63B-4. For APIs and workloads, they SHOULD be as short as possible, with compromise detection and device registration.
• Signing keys. Organizations MUST document approved cryptoperiods and SHOULD automate rotation. Signing keys for high-impact systems SHOULD have a maximum active signing period of 90 days. For moderate and low impact systems, longer periods MAY be fine but SHOULD be under one year.
• Symmetric signing of assertions and tokens is generally not recommended.
• Audience. All tokens and assertions MUST carry explicit audience fields, and access control MUST reject tokens with a missing or wrong audience. Such rejections SHOULD raise a security alert.
• Revocation. If an IdP provides revocation status, connected relying parties MUST reject revoked tokens and end related sessions. CSPs and agencies SHOULD implement session revocation signals from the OpenID Shared Signals Framework.
• Pipelines. Tokens MUST be kept out of system logs, CI/CD pipelines and build or deployment artifacts. Pipelines MUST pull secrets only from secret management systems and inject them at runtime. Any exposure should be handled as a security incident.
• Workloads. Workload identities MUST use tightly scoped, short-lived tokens and SHOULD use sender-constrained tokens such as mTLS or DPoP where feasible.
• Monitoring. Token usage data MUST be provided in a format a SIEM can consume.

Does this apply to you?

You are directly in the audience if any of these is true:

1. You are a CSP selling to US federal agencies, or plan to.
2. You are a federal agency running your own IdP, authorization server or federated SSO.
3. A contract, grant or agency policy you are under references IR 8587 or IA-13.

You are indirectly affected if you build software that issues or consumes signed tokens and sell to customers who will now ask about these numbers. NIST's Ryan Galluzzo put it plainly: "Anyone who is using tokens as part of their access management infrastructure can look to this for insights."

A quick self-check on one real token:

export TOKEN='paste-a-test-access-token-here'
python3 - <<'EOF'
import base64, json, os
p = os.environ["TOKEN"].split(".")[1]
p += "=" * (-len(p) % 4)
c = json.loads(base64.urlsafe_b64decode(p))
print("lifetime_seconds:", c.get("exp", 0) - c.get("iat", 0))
print("audience:", c.get("aud"))
print("signing alg in header is in part 0, check it is not HS256")
EOF

Then look at your published signing keys and how long each has been active:

JWKS=$(curl -s https://idp.example.com/.well-known/openid-configuration | jq -r .jwks_uri)
curl -s "$JWKS" | jq '.keys[] | {kid, kty, alg, use}'

What to do now

1. This week: measure actual lifetimes for access, ID and refresh tokens in production. Anything over one hour for access or ID tokens needs a documented reason.
2. By 31 October 2026: write down the approved cryptoperiod for every token signing key and the date each current key started signing. Flag high-impact system keys older than 90 days.
3. By 30 November 2026: search CI logs and build artifacts for tokens. Fix any pipeline that echoes secrets or writes them to caches or artifacts, and treat each hit as an incident, as the report advises.
4. By 31 December 2026: confirm every resource server rejects tokens with a missing or wrong aud, and that the rejection is logged and alerted on.
5. Q1 2027: plan sender-constrained tokens (mTLS or DPoP) for service-to-service calls, and short-lived workload identities in place of long-lived static credentials.
6. If you sell to agencies: prepare a one-page answer covering lifetimes, rotation, revocation and logging. The report says CSPs MUST document and present the availability of these capabilities to consumers.

Why it matters

Most token compromises are not cryptographic breaks. They are keys that lived too long, tokens accepted by services they were never meant for, and secrets printed into build logs. IR 8587 puts numbers on each of those failure modes, which gives security teams something specific to measure.

The CI/CD section deserves attention beyond federal work. Build logs and artifacts are read by many people and systems and kept for a long time. A token that lands there is effectively published.

Try it yourself

Pick one CI pipeline and search its last 20 run logs for strings that look like JWTs or bearer tokens:

gh run list --limit 20 --json databaseId -q '.[].databaseId' | while read id; do
  gh run view "$id" --log 2>/dev/null | grep -nE 'eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}' && echo "run $id"
done

Then see how automated secret detection fits into the same pipeline.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST IR 8587 (final), Protecting Tokens and Assertions from Forgery, Theft, and Misuse
• NIST IR 8587 PDF
• NIST news: NIST Finalizes Guidelines on Protecting Online Identity and Access Tokens From Misuse