NIST IR 8597: Publication of Interagency Report on Cloud Token and Assertion Protection

Executive Summary

On December 22, 2024, the Cybersecurity and Infrastructure Security Agency (CISA) and the National Institute of Standards and Technology (NIST) published the initial draft of interagency report IR 8597 “Protecting Tokens and Assertions from Forgery, Theft, and Misuse”. This document is subject to public consultation until January 30, 2026, with comments submitted to iam@list.nist.gov.

This publication comes in direct response to major security incidents at several cloud providers (Storm-0558 in 2023, Midnight Blizzard in 2024), where state actors compromised critical systems through theft, modification, or forgery of identity tokens. The report operates within the framework of Executive Orders 13694 and 14144, as amended by EO 14306 in June 2025.

The report establishes a control framework for Identity Access Management (IAM) systems based on digitally signed assertions and tokens. It defines respective responsibilities of Cloud Service Providers (CSPs) and cloud consumers (notably federal agencies) in secure management of the complete token lifecycle: issuance, signing, distribution, validation, usage, revocation, and logging.

Guiding principles rest on CSP application of Secure by Design, architectural transparency, security control configurability, and interoperability. The report advocates adoption of sender-constraining technologies such as DPoP (Demonstration of Proof-of-Possession) and mTLS for high-privilege tokens.

Context and Triggering Incidents

Storm-0558 (May-June 2023)

The Storm-0558 attack, attributed to an APT group linked to the People’s Republic of China, constitutes the foundational incident that catalyzed this initiative. The group compromised 22 enterprise organizations and 503 associated personal accounts via exploitation of a compromised Microsoft Account (MSA) key.

Technical Timeline:

April 2021: exfiltration of a private MSA key via crash dump present in debugging environment connected to Microsoft corporate network
May-June 2023: use of the key to forge Azure AD tokens enabling Exchange Online access via Outlook Web Access
June 16, 2023: detection of malicious activity by a U.S. government customer

Technical Vectors Exploited:

Compromised MSA key enabled signing of valid OpenID v2.0 tokens for multiple Azure AD application types
Exploitation of validation error in Microsoft code: Exchange Online systems accepted tokens signed with consumer MSA key to access enterprise resources
Absence of strict issuer/scope validation at token validation library level
Compromised key was present in crash dump due to undetected race condition during extraction from secure signing environment
Compromise of Microsoft engineer account via token-stealing malware to access debugging environment

Organizational Consequences: The Cyber Safety Review Board report (April 2024) identified a corporate culture neglecting investment in security and rigorous risk management. Microsoft was criticized for inaccurate public statements regarding the origin of the compromised key, initially attributed to a crash dump but never found despite investigations.

Midnight Blizzard (November 2023 – March 2024)

The Midnight Blizzard operation, attributed to Russian APT group Nobelium (SVR), targeted Microsoft’s corporate environment with espionage objectives aimed at leadership and cybersecurity teams.

Initial Access Vector:

Password spraying attack using residential proxies to evade detection
Compromise of legacy non-production test account without multi-factor authentication (MFA)
Compromised account had elevated access to corporate environment

Attack Progression:

Identification and compromise of legacy test OAuth application with elevated access
Creation of new user account in Microsoft corporate environment
Use of created account to consent to attacker-controlled malicious OAuth applications
Exploitation of test application to grant Office 365 Exchange Online “full_access_as_app” role via Exchange Web Services (EWS) API

Activity Period:

November 2023: intrusion began
January 12, 2024: malicious activity detected
March 2024: confirmation of attacker source code access

Identified Failures:

Absence of cleanup of legacy test accounts and tenants
MFA not enabled on privileged accounts
Insufficient monitoring of OAuth consents and account creations
Detection via EWS logs only, absence of proactive telemetry

Regulatory Framework and Executive Orders

Executive Order 13694 (Obama, April 2015)

EO 13694 “Blocking the Property of Certain Persons Engaging in Significant Malicious Cyber-Enabled Activities” establishes the initial framework of sanctions against malicious actors in cyberspace. It uses authorities conferred by the International Emergency Economic Powers Act (IEEPA), National Emergencies Act (NEA), and Immigration and Nationality Act (INA).

Original Scope:

Sanctions limited to “significant” events
Targeting computer network compromise activities
Illicit misappropriation of funds or information

Subsequent Modifications:

EO 13757 (December 2016): additional measures
EO 13984 (January 2021): extension of sanctions criteria

Executive Order 14144 (Biden, January 16, 2025)

EO 14144 “Strengthening and Promoting Innovation in the Nation’s Cybersecurity” constitutes a major overhaul of federal cybersecurity policy in the final days of the Biden administration.

Principal Provisions:

Mandatory attestations of secure development practices for software vendors to federal government
Cybersecurity requirements in Federal Acquisition Regulation (FAR)
Directives for deployment of digital driver’s licenses and digital identity verification
Post-quantum cryptography adoption mandates
Improved AI adoption for security applications and cybersecurity function automation
Removal of “significant” threshold for cybersecurity sanctions from EO 13694
Extension of sanctions grounds: intellectual property misappropriation, confidential business information, personal identifiers, financial information, unauthorized access to U.S. systems

New CSP Responsibilities:

Application of Secure by Design principles
Architectural transparency
Security control configurability
Cryptographic protection of signing keys
Automatic key rotation
Vulnerability disclosure via CVE process

Executive Order 14306 (Trump, June 6, 2025)

EO 14306 “Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity and Amending Executive Order 13694 and Executive Order 14144” selectively modifies EO 14144 provisions while maintaining its general framework.

Changes Made:

Explicit identification of People’s Republic of China as most active and persistent cyber threat
Maintenance of significant threats from Russia, Iran, North Korea
Removal of certain secure software development attestation requirements (machine-readable format, centralized CISA validation)
Exemption of National Security Systems and debilitating impact systems (except post-quantum cryptography provisions)
Reorientation of sanctions authorities toward “foreign” actors only
Maintenance of Cyber Trust Mark obligation for IoT products sold to government (deadline January 4, 2027)
Establishment of rules-as-code pilot program for machine-readable versions of OMB, NIST, CISA cybersecurity policies and guidance
Directive to NIST to develop guidelines for secure management of access tokens and cryptographic keys used by CSPs

NIST Charge:

Update of Secure Software Development Framework (SSDF)
Establishment of industry consortium at National Cybersecurity Center of Excellence (deadline August 1, 2025)
Update of NIST SP 800-53 with guidance on secure patch and update deployment
Development of guidelines for secure management of access tokens and CSP cryptographic keys (origin of IR 8597)

Technical Content of NIST IR 8597

Document Architecture

IR 8597 report addresses IAM controls for systems relying on digitally signed assertions and tokens in access decision-making. It establishes a shared responsibility model between CSPs and cloud consumers.

Technical Scope:

Access tokens
Refresh tokens
SAML assertions
OpenID Connect tokens (ID Tokens)
Cryptographic signing keys
Validation and introspection systems

Token Lifecycle

The report structures its recommendations around the complete token lifecycle:

1. Issuance

Design Principles:

Preference for opaque tokens at resource server level
Token lifetime limitation according to privilege level
Use of unique session identifiers (jti claims)
Issuance conditional on proof-of-possession presence for high-privilege flows

CSP Controls:

Isolation of token issuance systems
Signing key protection in Hardware Security Modules (HSM) FIPS 140 Level 1 minimum for AAL2, mandatory for AAL3
Signing key separation per RP (Relying Party) for shared-key MACs
Nonce generation for replay prevention

Consumer Controls:

Contractual issuance policy validation
Issued token lifetime verification
OAuth consent and application creation audit

2. Signing and Cryptographic Protection

Algorithmic Standards:

Asymmetric signature: use of same public/private key pair authorized for signing assertions to multiple RPs
Symmetric key MAC: different key mandatory for each RP
Public key publication in verifiable manner (HTTPS-protected URL, well-known location)
Approved algorithms per FIPS cryptography

Key Protection:

Storage in HSMs or Azure Confidential VM environments
Automatic signing key rotation
Isolation of foundational key management systems
Credential scanning in crash dumps and production environment exports

Microsoft Post-Storm-0558 Evolutions:

Migration of MSA and Entra ID signing services to Azure Confidential VMs
Use of single hardened identity SDK to validate 90% of tokens issued by Entra ID for Microsoft applications
Stateful validation of identity tokens rather than validation based solely on self-contained claims

3. Distribution and Transport

Distribution Channels:

Front-channel (via browser): mandatory assertion encryption (FAL2 minimum)
- SAML: XML-Encryption encryption
- OpenID Connect: JSON Web Encryption (JWE) encryption
Back-channel (direct IdP-RP): optional encryption if authenticated protected channel

In-Transit Protection:

TLS 1.2 minimum required for all exchanges
TLS alone insufficient for FAL2: requires message-level encryption
Reason: TLS only protects individual links, not assertion itself in front-channel flows

Audience Restriction:

All RPs must verify assertion audience contains identifier for their RP
Prevention of injection and replay of assertions generated for one RP at another RP
Implementation via aud claims in JWT or AudienceRestriction in SAML

4. Validation

RP-side Validation:

Source authentication (verifier)
Assertion integrity confirmation
Signature verification with approved cryptography
Strict issuer/scope validation (Storm-0558 lesson)
Audience restriction verification
Validity duration control

Storm-0558 Identified Failures:

Microsoft libraries provided cryptographic signature validation API but without automatic scope validation
Developers incorrectly assumed libraries performed complete validation
Acceptance of requests for enterprise email with token signed by consumer key
Correction via library update and mandatory issuer/scope validation addition

Validation Recommendations:

Avoid blind trust in self-contained JWTs at resource boundaries
Prioritize online validation (introspection) for long-lived or privileged tokens
Standardization of token acquisition and validation mechanisms
Stateful validation rather than based solely on token claims

5. Usage and Sender-Constraining

Bearer Token Problem: Traditional bearer tokens allow any holder to access protected resources. In case of theft, the token can be replayed until expiration without possibility of distinguishing between legitimate user and attacker.

DPoP (Demonstration of Proof-of-Possession) – RFC 9449:

Application-level sender-constraining mechanism, binding token to public/private key pair.

Technical Operation:

Client generation of asymmetric key pair (public/private)
Creation of DPoP proof JWT containing:
- Public key in JWT header
- Claims htm (HTTP method) and htu (target URL)
- Claim iat (issuance timestamp)
- Claim jti (unique JWT identifier)
- Signature with private key
Sending of DPoP proof in DPoP HTTP header during token request
Authorization server binds public key to token via confirmation claim (cnf) containing JWK SHA-256 Thumbprint (jkt)
For each token use, client generates new DPoP proof with:
- Same keys
- htm/htu values corresponding to current request
- Hash of access token (claim ath)
Resource server verifies:
- DPoP proof signature with included public key
- Correspondence between proof public key and token jkt
- htm/htu claims validity
- jti uniqueness (replay prevention)

DPoP Advantages:

Works at application level, suitable for SPAs and mobile applications
Does not require X.509 certificates
Operationally lighter than mTLS
Prevents use of stolen tokens without corresponding private key

mTLS (Mutual TLS) – RFC 8705:

Transport-level sender-constraining mechanism via client certificates.

Characteristics:

Gold standard for sender-constrained tokens
Mutual client-server validation via X.509 certificates
High operational complexity (certificate issuance, management, revocation)
Impossible for public clients (SPAs, mobile applications) unable to securely store secrets
Infrastructure complexity: edge termination, TLS renegotiation
Preferred if available but DPoP recommended as alternative

IR 8597 Recommendations:

Adoption of DPoP or mTLS for refresh tokens
Mandatory for high-privilege flows
DPoP token scheme (not Bearer) to indicate sender-constraining
Refresh token rotation with token family invalidation upon suspicious reuse detection

6. Revocation

Revocation Mechanisms:

Immediate token revocation upon compromise notification
Token family invalidation (refresh token rotation)
Coordinated revocation between IdP and RPs
Revocation list publication (similar to CRL/OCSP for certificates)

Revocation Triggers:

Abnormal activity detection (unusual pattern, multiple geographies)
Suspicious consent changes
Token replay detection
User-reported or automatic detection of compromise

Organizational Controls:

Documented and tested revocation policy
Notification procedures for concerned parties
Coordination between security and operations teams

7. Logging and Telemetry

Events to Log:

Token issuances (with context: client, scope, duration)
OAuth consent events
Administrator consents
Token introspection calls
Validation failures
Token revocations
Application privilege modifications

Recommended SIEM Detections:

Unusual refresh patterns
Token reuse from multiple geographies
Consent changes
Abnormal introspections
Token use after revocation attempt

Multi-Source Correlation:

Correlation with EDR for host-based indicators
Network context enrichment
Unified timeline of identity events

Retention and Compliance:

Retention policy per risk assessment
Compliance with NARA records retention schedules for federal agencies
Balance between investigation and privacy

Guiding Principles for CSPs

Secure by Design

Application of security principles from design rather than as post-deployment addition.

Implementation:

Security by default in configurations
Attack surface minimization
Defense in depth with multiple control layers
Fail secure: failure toward secure state

Token-Specific Controls:

Minimum default lifetime per privilege level
Sender-constraining enabled by default for sensitive flows
Automatic signing key rotation
Strict validation enabled by default (no opt-in required)

Transparency

Publication of information enabling consumers to verify security controls.

Elements to Document:

Token issuance and validation system architecture
Cloud deployment models used
Applied cryptographic controls
Token lifetime policies
Available revocation mechanisms
Logging and telemetry capabilities
Metadata endpoints (/.well-known)

Disclosure Standards:

CVE publication of all vulnerabilities, including token validation logic flaws
Collaboration with CVE Program to develop CWEs adapted to cloud environments
Timely and comprehensive disclosure to enable informed risk decisions

Configurability

Provision of configurable controls enabling consumers to align security posture with their threat environment.

Required Configurable Parameters:

Token lifetimes (access, refresh, ID tokens)
Rotation policies
Logging level
Sender-constraining mechanisms (DPoP/mTLS activation)
Issued token scopes
Audience restrictions

Management Interfaces:

Programmatic APIs for configuration
Integration with policy management systems
Configuration validation before application
Rollback capabilities

Interoperability

Respect for open standards to enable integration and portability.

Supported Standards:

OAuth 2.0 and extensions (RFC 6749, RFC 8693, RFC 9449)
OpenID Connect
SAML 2.0
JWT (RFC 7519)
JWE (RFC 7516)
JWS (RFC 7515)
Token introspection (RFC 7662)
Token revocation (RFC 7009)

Avoiding Proprietary Lock-in:

Open standard implementation without mandatory proprietary extensions
Documentation of optional proprietary extensions
Migration path to alternative implementations

Guiding Principles for Cloud Consumers (Federal Agencies)

Architectural Understanding

Pre-Procurement Due Diligence:

Analysis of CSP IAM architecture
Identification of deployment models (public, private, hybrid, community cloud)
Mapping of token and assertion flows
Identification of validation and control points

Risk Alignment:

Agency threat model assessment
Mapping of CSP controls to agency security requirements
Control gap identification
Determination of necessary compensating controls

Required CSP Documentation:

IAM architecture diagrams
Token/assertion data flows
Detailed shared responsibility model
Certifications and audits (FedRAMP, SOC 2, ISO 27001)

Contractual Requirements

Security SLAs:

Maximum token lifetimes per type and privilege level
Guaranteed revocation timelines
Minimum logging level
Log retention
Incident notification involving tokens/assertions

Contractual Transparency:

Access to IAM configuration metadata
Periodic reporting on identity-related security incidents
Disclosure of architectural changes impacting security
Access to independent audit results

Migration Clauses:

Identity and data portability
Revocation procedures during offboarding
Post-contract retention timeline

Organizational Controls

Governance:

Clear ownership of cloud IAM management
Approval process for new integrations
Periodic OAuth consent review
Application and service principal audit

Operations:

Active monitoring of token issuance and usage
Usage anomaly investigation
Compromised token incident response procedures
Regular revocation mechanism testing

Training:

Awareness of token risks (phishing, token theft)
Procedures for reporting suspected compromise
Best practices for credential management in the cloud

Immediate Operational Recommendations

For Security Teams

Token Lifecycle Hardening:

Current State Audit:
- Inventory of token types used (access, refresh, ID tokens, SAML assertions)
- Mapping of current lifetimes
- Identification of long-lived or non-expiring tokens
- Census of legacy applications using insecure patterns
Technical Control Implementation:
- Prefer opaque tokens with mandatory introspection for long-lived tokens
- Avoid blind trust in self-contained JWTs without online validation
- Implement sender-constraining (DPoP/mTLS) for refresh tokens and privileged flows
- Enable refresh token rotation with per-session identifiers (jti)
- Invalidate token families upon suspicious reuse detection
Visibility Improvement:
- Centralize logs of token issuance, consent events, introspection calls
- Build SIEM detections for abnormal refresh patterns, token reuse from multiple geographies, consent changes
- Correlate with EDR for host-based indicators (token stealer malware)
- Establish normal behavior baseline per application type and user
Cleanup and Hygiene:
- Revoke undocumented legacy identity endpoints
- Enforce strict issuer/audience validation at API gateways
- Disable test accounts and applications in production environments or with elevated privileges
- Audit and cleanup of non-production tenants with production environment access

For Procurement Managers

Requirements in RFPs/Contracts:

Architectural Transparency:
- Complete CSP IAM architecture documentation
- Token/assertion flow diagrams
- Explicit shared responsibility model
- Identification of cryptographic protection mechanisms used
Security Guarantees:
- Signing key protection in HSMs with FIPS 140 certification
- Automatic key rotation with specified timeline
- DPoP and mTLS support for sender-constraining
- Maximum token lifetimes per type
- Guaranteed revocation timelines
Visibility and Controls:
- Available logging levels
- Token introspection APIs
- IAM policy configuration interfaces
- Audit and reporting mechanisms
Compliance and Audit:
- Applicable certifications (FedRAMP, SOC 2 Type II, ISO 27001)
- Frequency and scope of independent audits
- Vulnerability disclosure process
- Compliance history
Incident Response:
- Notification procedures for incidents involving token compromise
- Revocation SLAs
- Forensics and investigation capabilities
- Incident support

For Developers and Architects

Secure Pattern Implementation:

Cloud-Native Application Design:
- Use short-lived tokens with automatic refresh
- Implement DPoP for client-heavy applications
- Avoid token storage in localStorage (use httpOnly cookies or in-memory storage)
- Implement token binding at application level
Rigorous Validation:
- Never trust solely on self-contained JWT claims
- Implement strict issuer/audience validation
- Verify cryptographic signatures with keys obtained from authenticated sources
- Systematically validate timestamp and expiration
- Reject tokens with “none” algorithm
Secret Protection:
- Never include tokens or credentials in plaintext in source code or binaries
- Use secrets managers for storage
- Regular credential rotation
- Minimize token lifetime in memory
Logging for Investigation:
- Log token issuance and validation (not tokens themselves)
- Include sufficient context for investigation (timestamp, client ID, user ID, scope, validation result)
- Protect logs against modification
- Implement appropriate retention

Public Consultation Process

Timeline

Draft Publication: December 22, 2024
Consultation Period End: January 30, 2026
Duration: approximately 13 months

This extended duration enables thorough review by multiple stakeholders: federal agencies, CSPs, security researchers, practitioners.

Comment Submission

Email Address: iam@list.nist.gov

Recommended Format:

Clear and actionable comments
Specific language proposals for service-level statements
Identification of missing or to-be-standardized telemetry fields
Migration timelines for proposed control adoption
Operational impact of suggested technical controls on existing systems

Priority Audiences:

Federal agencies: feedback on applicability and feasibility in government contexts
Major CSPs: feedback on implementation constraints, existing industry standards, compatibility
Security teams: technical control validation, gap identification
Researchers: formal analysis of proposed mechanisms, potential weakness identification

Value of Structured Comments

The most useful comments for NIST and CISA will include:

Technical Precision:
- References to existing standards (RFCs, ISO, NIST SP)
- Concrete use cases and real attack scenarios
- Measurable security metrics
Operational Impacts:
- Implementation complexity estimation
- Migration costs from existing architectures
- Realistic deployment timelines
- Potential user friction
Alternatives and Trade-offs:
- Proposal of alternative security-equivalent approaches
- Identification of security/usability/performance trade-offs
- Compensating controls for legacy environments
Standardization:
- Standardized format proposals (JSON schemas, YAML)
- Interoperability mechanisms between CSPs
- Common APIs for configuration and monitoring

Sectoral Implications

Financial Sector and Financial-Grade APIs (FAPI)

IR 8597 report closely aligns with FAPI profiles developed by OpenID Foundation for financial sector.

FAPI 1.0 Advanced:

Mandatory mTLS for certificate-bound tokens
Used by UK Open Banking Initiative (OBIE) and Brazil Open Finance

FAPI 2.0:

Allows DPoP as mTLS alternative
Flexibility for financial institutions to migrate toward application-level sender-constraining
Growing adoption in open banking regimes (OBIE, Brazil OBB)

Applicable Regulations:

EU PSD2 (Payment Services Directive 2)
UK Open Banking
Brazil Open Finance
Australia Consumer Data Right (CDR)

Common Requirements:

Strong Customer Authentication (SCA)
Explicit consent for data access
Protection against replay and man-in-the-middle
Complete audit trail

IR 8597 provides implementation guidance aligned with these regulatory requirements.

Multi-Cloud and Hybrid Environments

Specific Challenges:

Multiple IdPs and trust boundaries
Inter-cloud identity federation
Revocation policy synchronization
Distributed logging

Recommendations:

Clear federation architecture with identified trust anchors
Standardization of token formats inter-CSPs
Unified SIEM platform for multi-cloud correlation
Coordinated revocation procedures between CSPs

U.S. Federal Government

Direct Applicability: The report explicitly targets federal agencies as cloud consumers and imposes requirements on CSPs serving these agencies.

Integration with Existing Frameworks:

NIST SP 800-53 (Security and Privacy Controls)
NIST SP 800-63 (Digital Identity Guidelines)
NIST SP 800-171 (Protecting Controlled Unclassified Information)
FedRAMP (Federal Risk and Authorization Management Program)

Expected Compliance Timeline: Future OMB directives and CISA binding operational directives (BODs) will establish mandatory compliance timelines for federal agencies based on final IR 8597 report.

Future Perspectives and Evolutions

Post-Quantum Cryptography (PQC)

EO 14306 explicitly maintains post-quantum cryptography adoption requirements even for systems exempted from other provisions.

Token Implications:

Transition of signature algorithms (RSA, ECDSA) toward quantum-resistant alternatives
NIST standardized CRYSTALS-Dilithium (FIPS 204) for digital signatures
Anticipated migration timeline in coming years
Temporary dual-signature for compatibility during transition

Technical Challenges:

Increased PQC signature size impacting token size
Verification performance
Compatibility with existing infrastructures

Artificial Intelligence and Anomaly Detection

EO 14306 charges agencies with incorporating AI software vulnerabilities and compromises into their vulnerability management processes.

Applications to Token Security:

Detection of abnormal usage patterns via ML
Identification of forged tokens based on behavioral anomalies
OAuth consent graph analysis to detect suspicious chains
Automatic risk classification for new applications

Considerations:

Training dataset quality and bias
False positives and operational impact
Decision explainability for audit and compliance

Evolution of OAuth and OpenID Connect Standards

Ongoing Initiatives:

OAuth 2.1: best practices consolidation (draft in progress)
FAPI 2.0: financial-grade security profiles (being adopted)
Grant Management (RFC 9635): explicit grant and consent management
Rich Authorization Requests (RFC 9396): authorization_details for fine-grained permissions

Future Integration into IR 8597: Next report versions will likely integrate these emerging standards once stabilized and adopted in industry.

Conclusion

Publication of NIST IR 8597 marks a significant step in cloud identity security maturation. In response to major incidents impacting critical organizations, NIST and CISA establish a comprehensive framework of technical and organizational controls for token and assertion lifecycle protection.

The report transcends simple reaction to past incidents to propose structural reform of cloud IAM security approach, anchored in Secure by Design, transparency, configurability, and interoperability principles. Emphasis on shared responsibility recognizes that cloud identity security requires coordinated engagement between providers and consumers.

Sender-constraining technologies (DPoP, mTLS), rigorous validation, centralized logging, and coordinated revocation mechanisms constitute technical pillars of the proposed framework. Alignment with recent Executive Orders and integration into federal standards ecosystem ensure political and technical coherence.

The extended public consultation period (until January 30, 2026) offers substantial opportunity for stakeholders to contribute to report refinement. Structured feedback on operational applicability, migration impacts, and technical alternatives will significantly enrich the final document.

Organizations operating in the cloud, whether governmental or private, will benefit from in-depth analysis of real incidents (Storm-0558, Midnight Blizzard) and extracted operational lessons. Implementation of IR 8597 recommendations constitutes strategic investment in identity infrastructure resilience against sophisticated state adversaries and insider threats.

Convergence between U.S. government requirements and international standards (FAPI for open banking, PSD2 regulations) creates momentum for broad adoption of advocated practices beyond U.S. federal perimeter alone. CSPs and multinational enterprises will find in this report a solid technical foundation to harmonize their security controls globally.

Attention given to tokens and assertions as first-class cryptographic assets, rather than simple web artifacts, reflects necessary evolution of cloud security posture. In an environment where distributed identities simultaneously constitute authentication vector and attackers’ preferred target, this paradigm shift imposes itself as strategic imperative.

References and Resources

Official Documents

NIST IR 8597 (Draft): Protecting Tokens and Assertions from Forgery, Theft, and Misuse – csrc.nist.gov
Executive Order 14144: Strengthening and Promoting Innovation in the Nation’s Cybersecurity (January 16, 2025)
Executive Order 14306: Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity (June 6, 2025)
Executive Order 13694: Blocking the Property of Certain Persons Engaging in Significant Malicious Cyber-Enabled Activities (April 1, 2015)

Technical Standards

RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
RFC 6749: OAuth 2.0 Authorization Framework
RFC 7519: JSON Web Token (JWT)
RFC 7662: OAuth 2.0 Token Introspection
RFC 7009: OAuth 2.0 Token Revocation
NIST SP 800-63-3: Digital Identity Guidelines
NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations

Incident Reports

US Cyber Safety Review Board Report (April 2024): Storm-0558 Investigation – dhs.gov
Microsoft Security Blog: Analysis of Storm-0558 techniques for unauthorized email access
Microsoft Security Blog: Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard
CISA Advisory: SVR Cyber Actors Adapt Tactics for Initial Cloud Access

Implementation Resources

NIST Cybersecurity Framework: nist.gov/cyberframework
CISA Zero Trust Maturity Model: cisa.gov/zero-trust
OpenID Foundation FAPI Working Group: openid.net/wg/fapi
Cloud Security Alliance: cloudsecurityalliance.org