Cloud access needs a revocation test

A successful login does not create permanent trust. Modern cloud systems commonly issue signed tokens that identify a user or service, define what it may access and remain valid for a limited period. NIST IR 8587, finalised on 15 September 2026, sets out implementation guidance for protecting those tokens across single sign-on, federation and application programming interfaces.

For systems claiming conformance, the report says a token or assertion should identify its issuer, subject, intended audience, issue time, validity window and unique identifier. Its lifecycle should include generation, issuance, refresh, revocation, time restriction and audience restriction. The report also notes that immediate global revocation is not always possible in stateless systems; short-lived access tokens, controlled refresh and reauthentication can narrow the period in which compromised access remains useful.

The audit trail matters as much as the expiry setting. NIST recommends tamper-resistant records of events such as issuance, refresh, acceptance, rejection and revocation, while excluding the token itself and personal data contained inside it. It also separates provider responsibilities, including core identity services and infrastructure logging, from customer responsibilities such as policy configuration, application access and enabling logs that may not be on by default.

Dunes Bureau interpretation: a cloud buyer can convert that guidance into an acceptance test. Simulate a compromised account, revoke its access and measure how long connected applications and APIs continue to accept it; then confirm that the event can be reconstructed without exposing the credential in logs. The report’s formal scope is federal cloud environments, so this is an operational inference for commercial buyers, not evidence of a measured reduction in breaches or cost.