CISA AND NIST RELEASE NEW FEDERAL CLOUD SECURITY GUIDELINES TO COMBAT TOKEN THEFT, FORGERY AND IDENTITY ABUSE

WASHINGTON — The Cybersecurity and Infrastructure Security Agency and the National Institute of Standards and Technology have released new technical guidance aimed at protecting federal cloud identity systems from the theft, forgery, replay, and misuse of authentication tokens that can give attackers access to sensitive applications, data, communications, and cloud services.

The final publication, NIST Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, provides federal agencies and cloud service providers with detailed recommendations for protecting identity tokens, access tokens, cryptographic signing keys, single sign-on systems, federation services, and application programming interfaces.

The guidance addresses a security problem that has become central to modern cloud infrastructure.

Organizations now rely heavily on identity providers and authorization servers rather than requiring users to authenticate separately every time they access an application or service.

Conformance with IR 8587 remains voluntary for federal agencies and cloud service providers unless its requirements are made binding through policy or another applicable agreement. Within the report, requirements identified as “MUST” or “MUST NOT” apply to organizations choosing to claim conformance with the guidelines.

That architecture provides speed, scalability, and centralized identity management, but it also creates a valuable target.

If an attacker steals a legitimate token, compromises a signing key, or finds a way to forge a trusted assertion, the attacker may be able to impersonate an authorized user without stealing the victim’s password or repeatedly defeating multifactor authentication.

NIST warns that compromised cryptographic keys or defective token verification can allow an attacker to gain unauthorized access and rapidly move into multiple protected resources connected to the same identity environment.

The report was developed after a series of high-profile attacks demonstrated that identity infrastructure itself can become a path into government and enterprise systems.

NIST specifically notes previous incidents where attackers forged Security Assertion Markup Language assertions after gaining access to privileged identity infrastructure. In another incident described in the report, attackers used exposed signing keys and token-validation weaknesses to access government and enterprise email systems, resulting in more than 60,000 emails being taken from a single federal agency.

Those incidents helped drive the creation of the IA-13 Identity Providers and Authorization Servers control added to NIST Special Publication 800-53.

IR 8587 expands that work by providing agencies and cloud providers with a more detailed implementation roadmap rather than stopping at a high-level security requirement.

The final report follows extensive government and private-sector collaboration.

CISA and NIST incorporated feedback from nearly 250 public comments covering token validation, secrets management, large-scale detection, and related security controls. The development process also included work through CISA’s Joint Cyber Defense Collaborative and discussions with cloud and identity technology providers.

Participants included Google, Microsoft, Amazon Web Services, IBM, Okta, Oracle, HashiCorp, the OpenID Foundation, Wiz, and other industry partners.

CISA Acting Executive Assistant Director for Cybersecurity Chris Butera described identity as the new security perimeter and said stolen or forged credentials must not be allowed to become footholds across the federal enterprise.

That concept is fundamental to the new guidance.

The traditional network perimeter has become less meaningful as government systems move into cloud, hybrid, remote-access, software-as-a-service, and multi-cloud environments.

An employee may authenticate once and then use a trusted identity token to reach numerous resources distributed across different systems.

A compromised token can therefore carry authority far beyond the device where it was originally issued.

NIST describes cloud security as a shared responsibility between the cloud service provider and the organization consuming the service.

Cloud providers commonly control underlying infrastructure, core identity services, token issuance, cryptographic signing, secrets storage, and infrastructure-level monitoring. Agencies remain responsible for properly configuring identity policies, application access, authentication, session management, application secrets, logging, and user access. Incident response, continuous monitoring, user education, and token revocation often require cooperation between both sides.

That division of responsibility is important because a secure cloud platform can still be exposed by weak customer configuration, just as strong agency policies can be undermined by weaknesses in the infrastructure issuing or validating identities.

The report calls for continuous monitoring rather than treating identity controls as systems that can be configured once and forgotten.

Federal agencies and cloud providers are expected to monitor accounts, clients, token issuers, token consumers, validation systems, access grants, entitlements, and account status continuously.

NIST notes that some real-world token compromises can only be identified through account activity and cloud-provider logs.

Session behavior is another major focus.

The report calls for monitoring token use for unusual patterns, including geolocation changes, abnormal device information, and velocity anomalies that may indicate the same identity is being used in ways inconsistent with legitimate activity.

Token activity should also be capable of feeding security platforms such as Security Information and Event Management systems and behavioral analytics tools so identity events can be correlated with other threat data.

The guidance also addresses one of the most dangerous failure points in federated identity systems: signing keys.

Identity providers digitally sign tokens so connected applications can verify that the information came from a trusted source and has not been altered.

If the private signing key is stolen, the attacker may be able to create tokens that appear authentic.

NIST recommends isolating signing keys, limiting their scope, rotating them based on risk, automating key-management processes where practical, and preventing a key intended for one environment from being trusted in another.

Signing keys should also be restricted to their designated purpose and should not be reusable outside their assigned security boundary.

The report makes clear that possession of a technically valid token should not automatically equal authorization.

Zero-trust principles require applications and authorization systems to evaluate additional context before granting access.

NIST recommends that authorization systems consider the validity, scope, source, integrity, entitlements, and circumstances surrounding a request rather than trusting the token alone. Identity governance should also support least privilege, just-in-time authorization, zero standing privilege, and separation of duties where sensitive resources are involved.

Token lifetime is another critical control.

IR 8587 recommends short validity periods so a stolen credential has a limited window of usefulness.

Access and identity tokens should have defined short lifetimes, and expired tokens must be rejected. The report recommends that access and identity tokens generally remain valid for no more than one hour, with shorter periods appropriate for higher-risk resources.

Revocation presents a more complicated challenge.

In distributed stateless architectures, instantly invalidating every token associated with a compromised identity may not always be technically possible.

NIST recommends combining short-lived access tokens with secure refresh mechanisms, reauthentication, revocation signaling, and mechanisms that allow connected systems to learn when an identity or session has been compromised.

Applications receiving revoked tokens must reject them and terminate associated sessions when the infrastructure supports that capability.

Audience restriction is also required.

A token created for one application should not become a universal credential capable of opening unrelated systems.

NIST states that tokens and assertions must identify their intended audience and that access-control systems must reject credentials with missing or incorrect audience restrictions. Token scope should be limited to the minimum authority necessary for the intended operation.

Replay attacks receive specific attention.

An attacker who obtains a legitimate token may attempt to reuse it before it expires.

IR 8587 recommends unique token identifiers, sender-constrained credentials, token rotation, conditional access controls, validation of token uniqueness, and tamper-resistant logging to make stolen credentials harder to reuse successfully.

The report also identifies risks created by software development and deployment pipelines.

Tokens or secrets that accidentally appear in debugging output, build logs, console output, cache directories, or development artifacts can remain accessible far longer than intended.

NIST states that secrets should be retrieved through approved secret-management systems, injected only when needed during runtime, and kept out of logs and build artifacts. Any discovered exposure of a token should be treated as a security incident.

Machine identities receive their own protections.

Modern cloud environments contain large numbers of automated services, workloads, APIs, containers, and machine-to-machine connections that may operate without a human user.

The report calls for these non-person identities to use tightly scoped, short-lived tokens issued through approved enterprise identity platforms. NIST also recommends sender-constrained technologies where feasible so a stolen credential cannot simply be copied to another system and replayed.

Logging requirements are equally strict.

Components handling tokens and assertions must maintain tamper-resistant event logs, but the actual tokens and personal information contained inside them must not be written into those logs.

Instead, defenders can record information such as token type, issuer, scope, intended audience, associated user or workload identifiers, and timestamped security events without storing the sensitive credential itself.

The report also reaches into the rapidly developing field of artificial intelligence.

NIST states that agentic AI systems are beginning to rely on signed tokens and assertions when accessing tools, systems, APIs, and data.

Organizations are advised to apply the new token protections when AI agents use those identity mechanisms.

NIST and CISA acknowledge that AI agents create additional identity and access management risks that extend beyond the scope of IR 8587 and say further guidance will be needed as agentic systems become more common.

The recommendations cover commercial cloud services used by government agencies along with government-operated cloud infrastructure.

They are designed to support modern SSO, identity federation, API access, workload identities, zero-trust architectures, hybrid environments, and multi-cloud deployments.

The report also stresses interoperability.

Federal systems rarely exist within a single isolated identity environment. Agencies may depend on several cloud providers, legacy applications, on-premises infrastructure, mobile systems, APIs, and third-party services.

Security controls therefore need to function across boundaries without allowing one compromised credential or signing key to become a master key across the enterprise.

IR 8587 gives federal agencies and cloud providers a technical framework for narrowing that risk.

The core principle is straightforward: authentication tokens must be treated as security-critical credentials.

A password can be useless to an attacker when multifactor authentication blocks the login. A valid stolen token may represent an already authenticated session.

That makes protection of the systems issuing, signing, storing, validating, refreshing, revoking, and monitoring those tokens critical to the security of modern federal cloud infrastructure.

CISA is urging federal agencies, cloud service providers, and cloud consumers to review and implement IR 8587 as they strengthen cloud identity systems against sophisticated attacks.

The report makes clear that identity security can no longer be treated as one control among many.

In cloud environments where authorization flows across applications, services, APIs, workloads, and organizations, the integrity of the token can determine whether the entire trust chain holds or collapses.

---

National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA) — NIST Interagency Report 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, September 2026. (Free Download)

---

---

---

---

---

---

---

---

---

---

🔥 NOW AVAILABLE! 🔥

‎👉 Eclipsera – Apple Music

---

---

---

---

---