hidekazu-konishi.com

NIST IR 8587 Mapped to AWS Controls - Signing Keys, Audience, Token Lifetimes, Revocation, and What the Settings Leave Open

First Published: 2026-10-18
Last Updated: 2026-10-18

NIST IR 8587 (Protecting Tokens and Assertions from Forgery, Theft, and Misuse) is a document outlining recommendations for safeguarding signed tokens and assertions against forgery, theft, and misuse. The final version was published on September 15, 2026. The recommendations cover the protection and rotation of signing keys, token validation and audience, token lifetime and refresh, revocation, monitoring, and logging. The document is written with numerous statements using uppercase MUST, SHOULD, and MAY, creating a checklist-like appearance.

However, the strength of the recommendations within NIST IR 8587 varies from statement to statement. Some statements are marked with MUST, others with SHOULD, and still others contain guidelines expressed in lowercase must or should, which are not normative. Some statements are also conditioned on an impact level (low, moderate, high) or on a capability being available. The subject of each statement also varies, ranging from identity providers (IdPs) and authorization servers, to relying parties (RPs), cloud service providers (CSPs), and consuming agencies. Furthermore, NIST IR 8587 does not name any cloud provider or cloud product in its recommendations. The terms AWS and Amazon do not appear anywhere in the document.

This article extracts the recommendations from NIST IR 8587, section by section, and annotates each statement with its normative keyword, any conditions, and the addressee of the sentence. It then applies these recommendations to specific AWS settings, including AWS KMS asymmetric keys, Amazon Cognito user pools, AWS IAM Identity Center, AWS STS, Amazon API Gateway JWT authorizers, Application Load Balancers, and Amazon Verified Permissions. The same tables also keep what the settings cannot narrow: what the documentation says users cannot configure (for example, automatic rotation of asymmetric KMS keys), and what was not found in this article's search. This article does not assess whether AWS is compliant with NIST IR 8587, nor does it describe attack procedures or pricing. The information presented in this article was verified as of October 17, 2026.

Related articles on this site:

• JWT Signing Algorithms on AWS Endpoints - What IAM, Application Load Balancer, API Gateway, AppSync, Cognito, and IAM Identity Center Accept, and What They Check Besides the Signature
• Amazon Cognito Federation Complete Implementation Guide - Google, Apple, Microsoft, OIDC, and SAML
• AWS IAM Inbound Workload Federation - IAM Roles Anywhere, OIDC, and SPIFFE Converging on One Trust Policy Condition
• Which alg a JWT Library Accepts When You Do Not Say - Algorithm Allowlists, Key Binding, Unknown Keys in a JWKS, and RFC 8725
• Where AI Agent Authorization Standards Stand - RFCs, IETF Working Group Documents, Individual Drafts, and Specifications from Other Bodies
• OWASP Top 10 for Agentic Applications Mapped to AWS Controls - What Each Control Mitigates and What Residual Risk Remains

Table of Contents

1. 1. Scope and Assumptions
2. 2. How to Read the Tables
3. 3. Which Role You Hold on AWS
4. 4. Signing Key Protection and Rotation (IR 8587 Section 5.1)
5. 5. Validation and Audience (IR 8587 Sections 5.2 and 5.3.1.3)
6. 6. Token Lifetimes and Refresh (IR 8587 Section 5.3.1.1)
7. 7. Revocation and Session Revocation Signals (IR 8587 Section 5.3.1.2)
8. 8. Monitoring, Token Protection, Workloads, and Logging (IR 8587 Sections 5.3.1.4 to 5.3.1.7 and 4.1.4)
9. 9. Considerations Outside the Control Sections (IR 8587 Section 7)
10. 10. Failure Modes
11. 11. Frequently Asked Questions About IR 8587 and AWS Settings
12. 12. Summary
13. 13. References

1. Scope and Assumptions

This section defines the intended audience for this article, the position of IR 8587, the tokens that IR 8587 addresses, the scope of this article, and the date of verification. To state the conclusion upfront, there are six key points:

• The recommendations in IR 8587 are intended for CSPs (Cloud Service Providers) and federal government agencies. IR 8587 itself says that conformance is voluntary for them unless policy or other binding agreements, such as contracts, determine otherwise. It does not by itself impose obligations on AWS users.
• The uppercase MUST, SHOULD, and MAY in IR 8587 appear 70, 48, and 6 times respectively in the document. These numbers represent the frequency of these terms, including instances within definitions and examples, and do not reflect the number of requirements.
• Some recommendations within IR 8587 are subject to conditions or levels of impact. For example, the sentence that limits the usage period of a signing key to 90 days is a SHOULD that applies to high-impact systems.
• Certain recommendations in IR 8587 can be narrowed down with AWS settings, while others cannot. For instance, AWS KMS asymmetric keys are not eligible for automatic rotation, requiring manual rotation. No setting for the rotation period of signing keys in Amazon Cognito user pools was found in the Cognito developer guide and API reference read for this article.
• IR 8587 names the Shared Signals Framework (SSF) and the Continuous Access Evaluation Profile (CAEP) for session revocation signals. No statement describing an AWS feature that receives or sends them was found in this article's search.
• Revocation does not reach everywhere on AWS. The Cognito developer guide states that revoked tokens remain valid when verified locally with a JWT library, and the IAM Identity Center user guide states that ending a user's session does not end active IAM role sessions created from permission sets.

1.1 Intended Audience

This article is intended for:

• Engineers and security professionals who manage identity infrastructure on AWS (including Cognito User Pools, IAM Identity Center, and integration with external Identity Providers).
• Individuals who operate APIs (such as API Gateway, Application Load Balancer, Verified Permissions, or custom code) and are considering using IR 8587 as a checklist.
• People who believe that IR 8587 is a list of MUST statements, that token lifetime validity must be within one hour, that placing keys in KMS satisfies the key requirements, and that AWS supports IR 8587.

The first three beliefs in the last item conflict with the sources this article read, and for the fourth, no source read states it. IR 8587 has many SHOULD statements, and the one-hour sentence is a SHOULD. KMS asymmetric keys are not eligible for automatic rotation. Finally, the text of IR 8587 does not mention AWS, and no AWS document that mentions IR 8587 was found in this article's search (Section 1.2 of this article).

1.2 Bibliographic Details and Status of IR 8587

IR 8587 is a report from NIST's Interagency Report series. Its title is "Protecting Tokens and Assertions from Forgery, Theft, and Misuse," with the subtitle "Implementation Recommendations for Agencies and Cloud Service Providers." The publication history on the NIST CSRC page states that the initial public draft was released on December 22, 2025, and the final version on September 15, 2026. The final PDF states that NIST's Editorial Review Board approved it on August 27, 2026. The cover of the initial public draft PDF states that it was withdrawn on September 15, 2026. As of October 17, 2026, there was no errata published on the CSRC page.

IR 8587 is a document that provides detailed information regarding control IA-13 (Identity Providers and Authorization Servers) from SP 800-53, along with its three associated enhancements. These enhancements focus on protecting cryptographic keys, validating identity assertions and access tokens, and managing tokens. Section 1.2 of IR 8587 states that conformance with this document is voluntary, with the condition in the following sentence.

However, conformance with these guidelines remains voluntary for CSPs and federal agencies unless otherwise determined through policy, including OMB policies, or other binding agreements (e.g., contracts, grants).

Section 3 states that control IA-13 is not yet included in an SP 800-53 control baseline.

At this time, IA-13 and its control enhancements have not been added to an SP 800-53 control baseline but may be in the future.

IR 8587 is directed at both Cloud Service Providers (CSPs) and federal government agencies. A full-text search of IR 8587 finds AWS and Amazon zero times.

A CISA announcement from September 15, 2026, marking the publication of IR 8587, describes individual meetings with CSPs about feedback on the draft as follows.

Dozens of individual meetings with CSPs were also held to discuss feedback that included Google, HashiCorp, an IBM Company, IBM, Microsoft Corporation, Okta Inc., the OpenID Foundation, Oracle America, Inc., Amazon Web Services, and Wiz.

This announcement names AWS as one of the parties to those meetings. It does not describe how AWS responds to the recommendations in IR 8587. No document in which AWS itself mentions IR 8587 was found in this article's search (AWS documentation search and web search on October 17, 2026). This article presents which IR 8587 recommendations each AWS setting corresponds to as this article's reading.

1.3 The Tokens IR 8587 Covers

IR 8587 focuses on systems that rely on tokens and assertions signed with asymmetric keys. Section 1.1 places other systems outside the scope of the controls as follows.

Systems that do not rely on asymmetric signed assertions and tokens (e.g., stateful management, schemes based on symmetric cryptography, API keys) are mentioned where relevant but out of scope for the controls covered.

This sentence matters when reading IR 8587 on AWS. The ID tokens and access tokens issued by Cognito's user pools are JWTs signed with RSA keys. In contrast, temporary credentials issued by AWS STS are not signed JWTs. Requests to AWS APIs carry a Signature Version 4 (SigV4) signature that is created by using the access keys of those credentials and, for temporary credentials, the security token. This article does not treat STS temporary credentials themselves as tokens in the scope of IR 8587. STS appears only in the following roles: as an RP receiving JWTs from external IdPs (e.g., AssumeRoleWithWebIdentity), in descriptions of the scope of revocation, in statements that STS temporary credentials are outside the scope of IR 8587, and in sentences and table rows that link to previously published articles on credential duration and revocation.

1.4 What This Article Covers, and What It Does Not

This article covers four things:

• The recommendation sentences in IR 8587 Sections 4.1.4, 5.1, 5.2, and 5.3, with their normative keywords, conditions, and addressees.
• The ranges, default values, and dates checked for the corresponding AWS settings.
• What AWS settings cannot narrow (what the documentation says users cannot configure, for example automatic rotation of asymmetric KMS keys, and what was not found in this article's search).
• Considerations from IR 8587, Section 7, that are relevant to AWS settings.

This article does not cover the following:

• Detailed information regarding the attack methods listed in Table 7 of IR 8587, Section 6, and past incidents mentioned in Section 2.
• A comprehensive summary of the entire IR 8587 document, or a complete overview of the controls outlined in SP 800-53 and FedRAMP.
• Determining whether AWS is compliant with IR 8587.
• A table of what AWS receivers check besides the signature (e.g., iss, aud, time claims, jti). This information is available on this site's JWT Signing Algorithms on AWS Endpoints.
• The process for revoking and refreshing Cognito tokens. This information is available on this site's Amazon Cognito Federation Complete Implementation Guide.
• The process for terminating temporary credentials in STS before their expiration. This information is available on this site's AWS IAM Inbound Workload Federation.
• The current status of specifications for SSF, CAEP, and RISC. This information is available on this site's Where AI Agent Authorization Standards Stand.
• Which alg values a JWT library accepts. This information is available on this site's Which alg a JWT Library Accepts When You Do Not Say.
• Pricing.

1.5 The Date Checked and the Sources Read

This article's information was verified as of October 17, 2026. For IR 8587, the CSRC publication page and the PDFs of the final version and the initial public draft were read. For AWS, this article read the developer guides, user guides, and API references for AWS KMS, Amazon Cognito, IAM Identity Center, IAM, AWS STS, API Gateway, Elastic Load Balancing, and Verified Permissions, and also reviewed the "What's New" announcements. This article does not involve creating or running any configurations. The ranges of settings, default values, and behavior were taken from statements in the documentation; where this article draws a reading from them, the sentence says so.

2. How to Read the Tables

This section defines the columns in the tables presented in this article, explains how normative keywords are handled, clarifies impact levels and section numbers, lists words used for different things, and describes how this article writes when a statement is not found. Sections 4 through 8 of this article present pairs of recommendation tables and AWS tables, corresponding to each section of IR 8587.

2.1 Columns of the Recommendation Tables

The recommendation tables list the recommendation sentences of IR 8587, one per row. The tables have five columns:

Column	Meaning
IR 8587 Section	The section heading number in the final IR 8587
Keyword	MUST, MUST NOT, SHOULD, SHOULD NOT, or MAY as written in capitals; lowercase (not normative) when the sentence uses a lowercase word
Applies When	The condition in the same sentence, such as an impact level or "if this capability is available"; — when there is none
Addressed To	The subject of the sentence, in IR 8587's own words
Recommendation (Summary)	A summary of the sentence; the verbatim text appears in the prose where it matters

The table includes only those sentences selected as relevant to applying the recommendations to AWS settings. It does not include every sentence from IR 8587. A row that combines two sentences of the same section shows two keywords separated by a slash, such as MUST / SHOULD. The Addressed To column uses the subject of the sentence as it appears in IR 8587, without reinterpreting it as AWS's responsibility or the user's responsibility. This is because IR 8587 does not explicitly mention AWS.

2.2 Columns of the AWS Tables

The AWS table has a Setting column on the left, followed by the five columns below. The same columns are also used on this site in What CAA Can and Cannot Stop When DNS Control Is the Weak Link and Which alg a JWT Library Accepts When You Do Not Say. In this article, a receiver is the AWS service, or your code, that validates a token. The AWS tables also list settings on the issuing side, such as KMS signing keys.

Column	Meaning
Narrowed By	Who sets the condition on AWS: You when it is a setting you choose; AWS (no setting found) when the documentation describes AWS behavior and no setting for it was found in the pages read; — when no AWS feature was found
Condition	What the setting narrows
Set In	The setting, parameter, or API that holds it
If You Set Nothing	The default, or what is accepted when you do not set it; if the source has no sentence for that case, the cell says so
What It Does Not Cover	What the setting does not narrow, even when you set it

The values in the Narrowed By column indicate whether the pages read name a setting. It does not represent the scope of AWS's responsibility.

2.3 How the Normative Keywords Are Counted

IR 8587, Section 1.2, defines normative terms as follows:

Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS, the term does not represent a normative requirement.

Section 1.2 assigns meaning to four terms: MUST and MUST NOT, SHOULD and SHOULD NOT. While MAY is used in uppercase throughout the document, Section 1.2 does not define the meaning of MAY. After the list of defined terms, and outside that list, Section 1.2 adds the following statement:

Agencies may choose to include these requirements in whole or in part based on risk management needs.

In the full text of IR 8587, the term MUST appears 70 times, SHOULD appears 48 times, and MAY appears 6 times. The 70 instances of MUST include 7 instances of MUST NOT, and the 48 instances of SHOULD include 3 instances of SHOULD NOT. These counts reflect both the instances within Section 1.2's definitions and the examples in Section 3 ((e.g., MUST, MAY)). Excluding definitions and examples, MUST appears 67 times, SHOULD appears 46 times, and MAY appears 5 times. This article does not refer to either of these counts as representing the number of requirements. This is because a single sentence may contain the term MUST multiple times, and a single recommendation may span multiple sentences.

There are two instances where uppercase and lowercase letters are mixed. These are in Section 5.3.1.2, which states MUST not accept refresh tokens, and in Section 5.2.1.2, which states Keys MUST not be usable outside of their defined scope. This article counts these two as MUST statements and quotes them as written. In Section 5.1.1.5, the term sHOULD appears once. This article does not include it in the count of SHOULD.

Lowercase must, should, and may are not normative. The sentence in Section 5.3.1.1 on refresh token replay (must protect) and the sentences in Sections 5.3.1.4 and 7.6 on shared signals (should) use lowercase. The tables of this article label these as lowercase (not normative).

2.4 Impact Levels and Conditions on an Available Capability

Several recommendations in IR 8587 are contingent upon the impact level of a system. These impact levels are categorized according to FIPS 199 (Low, Moderate, High), and Section 4.1.2 of IR 8587 states that the RMF, along with FIPS 199 and FIPS 200, guides the impact categorization. These categories are for federal government information systems. This article presents recommendations that depend on impact levels with their conditions attached. It does not specify which level is applicable to systems that lack such classifications.

Another condition takes the form of a capability being available. An example is If this capability is available, connected RPs MUST reject tokens that have been revoked in Section 5.3.1.2. This MUST assumes that a mechanism exists to deliver revocation status to the RP.

2.5 Section Numbers

This article references sections of IR 8587 using the numbering of the final version's headings. The final version of the text contains cross-references that still reflect the numbering from the initial draft. For example, Table 5 in Section 5.3.1.1 references revocation as Sec. 4.3.1.2 and session analysis as Sec. 4.3.1.4, while Section 5.2.1.1 references refresh as (see Sec. 4.3.1.1). In the final version's headings, these references correspond to Section 5.3.1.2, Section 5.3.1.4, and Section 5.3.1.1, respectively. The section numbers accompanying the mitigation measures column in Table 7 of Section 6, such as 4.1.1.4 and 4.3.1.3, also reflect the numbering from the initial draft. This article does not reproduce the column numbers from Table 7.

2.6 One Word, Different Things

In this article, the same word can refer to different things. This article distinguishes them as follows:

• Session: Refers to four distinct types: user interactive sessions within IAM Identity Center (e.g., signing in to the AWS access portal), IAM role sessions (STS temporary credentials, including those created from Identity Center permission sets), authentication sessions of an Application Load Balancer (ALB) (kept by the cookie the ALB returns), and managed login sessions within Cognito (using browser cookies).
• Revocation: Refers to five distinct things: Cognito RevokeToken (revoking a refresh token), Cognito GlobalSignOut and AdminUserGlobalSignOut (revoking a user's tokens), IAM Revoke active sessions (an operation that stops role sessions), ending an active session in IAM Identity Center, and the session revocation signals of IR 8587 (sent with SSF and CAEP).
• CSP: In this article, CSP refers to the Cloud Service Provider as defined in IR 8587. It does not refer to Content Security Policy in the context of web development.

2.7 When the Sources Do Not Say, and When Writing an Inference

When a statement cannot be found, this article names the sources searched and the date, and states that the statement was not found. It does not state that the feature does not exist. The wording used is no statement was found, or an equivalent such as no description was found. Connecting the recommendations in IR 8587 with AWS settings is this article's reading. When this article writes a reading, the same sentence says so.

3. Which Role You Hold on AWS

The recommendations in IR 8587 have different subjects from sentence to sentence. Whether an AWS user is the subject of a particular sentence depends on how they are using AWS. This section will correlate the roles described in IR 8587 with three distinct positions on AWS.

3.1 Role Terms in IR 8587

Sections 2.1 and 2.3.2 of IR 8587 define the roles of systems utilizing tokens as follows:

• IdP (Identity Provider) and Authorization Server: Authenticates users and issues tokens and assertions. This includes token services that exchange and refresh tokens.
• RP (Relying Party) and Resource Server: Receives and validates tokens, and determines access.
• CSP (Cloud Service Provider) and Consuming Agencies: These represent the entities providing cloud services and the federal government agencies that utilize them. Section 1.3 outlines the shared responsibility model for both parties.

3.2 Three Positions on AWS

AWS users hold one or more of the following three positions:

• Users of an IdP provided by a CSP: This involves having Cognito user pools or IAM Identity Center issue tokens. In the case of Cognito, the user pool holds the signing key, and no setting for how the key is stored was found. What the user chooses are settings such as lifetime and revocation.
• Operators of their own IdP: This involves using their own issuer to sign tokens using asymmetric keys stored in AWS KMS. The user designs key storage, rotation, and the distribution of public keys.
• Relying Parties (RPs): These entities receive and validate tokens using services such as API Gateway's JWT authorizer, ALB authentication, Verified Permissions, or their own custom code. AWS STS, which receives JWTs from external IdPs, also falls into this role.

The following diagram illustrates these three positions.

3.3 IR 8587 Table 1 (a SaaS Example)

Table 1 in Section 1.3 of IR 8587 provides an example of responsibility areas within a SaaS environment. In this table, Token Issuance/Signing and Secrets Vaults/Hardware Security Modules are marked under the Cloud Service Provider (CSP) column, while Session Management and Application Logging/Monitoring are marked under the Consumer column. User Education, Incident Response, Continuous Monitoring, and Token Revocation are marked under both columns. The text following the table clarifies that the actual boundaries of responsibility vary depending on the service model, contractual agreements, and the technical capabilities published by the CSP. This article reads the table as a SaaS example and does not apply it to individual AWS services. The user's position differs depending on whether they use Cognito or IAM Identity Center, or sign tokens with KMS keys themselves.

4. Signing Key Protection and Rotation (IR 8587 Section 5.1)

IR 8587, Section 5.1, addresses the generation, distribution, storage, usage periods, and rotation of keys used to sign tokens and assertions, as well as their revocation and destruction. This section first presents a table of recommendations, and then details AWS settings for scenarios where you are signing with an AWS KMS asymmetric key, and when using Cognito for signing.

4.1 Recommendation Table

IR 8587 Section	Keyword	Applies When	Addressed To	Recommendation (Summary)
5.1.1.1	MUST	—	(Keys used by IdPs and authorization servers)	Generate keys within cryptographic modules validated under FIPS 140
5.1.1.1	MUST / SHOULD	—	Organizations	Associate each key with its purpose, system, and device (MUST); maintain a key inventory (SHOULD)
5.1.1.2	SHOULD	—	(Secret or private keys)	Never communicate or export secret or private keys in plaintext
5.1.1.2	MUST	—	Recipients	Validate the authenticity of the public key and that its algorithm and key size fit the expected usage
5.1.1.2	MUST	—	(Metadata documents or JWKS endpoints)	Serve metadata and JWKS endpoints over HTTPS
5.1.1.3	MUST	Moderate impact or above	Organizations	Store signing keys in a hardware-based, hardware-backed, or otherwise isolated key storage mechanism
5.1.1.3	MUST NOT	—	(Signing keys and key material)	Do not store signing keys persistently on the applications, servers, VMs, or containers that use them
5.1.1.3	MUST	High impact	Organizations	Also protect the use of signing keys within an isolated execution environment
5.1.1.3	MAY	Low impact	Organizations	Use any of the techniques above, or software-based isolation
5.1.1.4	MUST / SHOULD	—	Organizations	Document approved cryptoperiods (MUST); employ automated key rotation (SHOULD)
5.1.1.4	SHOULD	High impact	(Signing keys)	Maximum active usage period of no more than 90 days
5.1.1.4	MAY / SHOULD	Moderate and low impact	(Usage periods)	Longer periods can be appropriate (MAY), but less than one year (SHOULD)
5.1.1.4	MUST	—	Organizations	Document the rollover process, from key creation to destruction
5.1.1.5	SHOULD	—	Organizations	Signal that a key is no longer trusted, typically by removing it from published metadata
5.1.1.5	MUST	After removal from distribution	(Retired private or secret keys)	Clear or erase all instances, including backup and archived copies

Rows with a bracketed Addressed To field indicate that the subject of IR 8587 is an object, such as a key or endpoint, rather than a person or organization.

4.2 Generation and Storage - Three Tiers by Impact Level

IR 8587, Section 5.1.1.3, categorizes the storage of signing keys into three tiers based on impact level. For systems at moderate impact or above, the following statement applies:

For systems assessed at moderate impact or above, organizations MUST store signing keys using a hardware-based, hardware-backed, or otherwise isolated key storage mechanism.

Regardless of the impact level, the following statement requires that the signing key not be persistently stored on the server or container that utilizes it.

Signing keys and key material MUST NOT be persistently stored on the applications, servers, virtual machines, or container systems that use them.

For high-impact systems, Section 5.1.1.3 adds, with MUST, that the use of the key itself be protected within an isolated execution environment. It gives examples of such measures, including HSMs, embedded processors, isolated execution environments, and remote cryptographic signing services. The description of remote cryptographic signing services includes cloud HSM services and managed signing services. For systems with low impact, the following statement applies:

For systems assessed at low impact, organizations MAY implement any of the above techniques or MAY use software-based isolation.

The AWS KMS Developer Guide describes KMS keys as follows:

The AWS KMS keys that you create in AWS KMS are protected by FIPS 140-3 Security Level 3 validated hardware security modules (HSM). They never leave AWS KMS unencrypted.

Regarding asymmetric keys, the following statement applies:

In an asymmetric KMS key, the private key is created in AWS KMS and never leaves AWS KMS unencrypted.

Signatures are generated by calling the KMS Sign operation within KMS. In this article's reading, configurations that use KMS asymmetric keys to generate signatures are considered to fall under the category of remote cryptographic signing services as listed in Section 5.1.1.3. However, IR 8587 does not name specific cloud services among its examples of key storage, so stating that KMS falls under this category is a conclusion of this article, not IR 8587 itself. Furthermore, Section 5.1.1.3 addresses the storage and isolation of keys and cryptographic functions; placing a key within KMS is separate from complying with key rotation requirements in Section 5.1.1.4 or the purpose restriction in Section 5.2.1.2.

KMS key policies and IAM policies allow you to restrict the principals that can call kms:Sign. You can also use the kms:SigningAlgorithm condition key to restrict the signing algorithms used in Sign and Verify requests. However, the AWS KMS Developer Guide describes the scope of this condition key as follows:

This condition key has no effect on operations performed outside of AWS KMS, such as verifying signatures with the public key in an asymmetric KMS key pair outside of AWS KMS.

RPs that receive tokens typically retrieve the public key from a JSON Web Key Set (JWKS) and verify the signature outside of KMS. The kms:SigningAlgorithm condition key does not restrict the RP's judgment. Discussions regarding restricting the alg values accepted by the RP are covered on this site in Which alg a JWT Library Accepts When You Do Not Say.

The Cognito developer guide states that the kid (key ID) in access tokens and ID tokens refers to a 2048-bit RSA private signing key held by the Cognito user pool. No statement about how the signing keys are stored, or about a setting for it, was found in the Cognito pages read for this article.

4.3 Usage Periods and Rotation - Asymmetric KMS Keys Are Rotated Manually

IR 8587, Section 5.1.1.4, regarding key usage periods and rotation, includes the following statement:

To enforce consistent application of these cryptoperiods and reduce the risk of human error, organizations MUST document approved cryptoperiods and SHOULD employ automated key rotation mechanisms.

The maximum usage period varies based on the impact level.

For high-impact systems, signing keys SHOULD have a maximum active usage period of no more than 90 days. For moderate and low impact systems, longer usage periods MAY be appropriate but SHOULD be less than one year.

Both 90 days and one year are SHOULD. In all cases, the same section also asks with SHOULD for shorter usage periods if key protection mechanisms are weaker or the ability to rapidly detect and recover from compromise is limited. This maximum applies to the period during which the key is actively used for signing. According to the same section, the period during which a new public key is made available prior to its use, and the period during which the system continues to accept the old public key, are not subject to this maximum. The same section requires that the rollover process (key creation, publication, activation for signing, overlap, deactivation, removal from distribution, revocation, and destruction) be documented with MUST. On splitting the limits by impact level, NIST's announcement of September 15, 2026, states that one of the major changes from the draft was to tie the usage period of signing keys to system classification and the sensitivity of transactions, rather than to deployment models.

In AWS KMS, asymmetric keys are not eligible for automatic rotation. The KMS API reference states:

Automatic key rotation is supported only on symmetric encryption KMS keys. You cannot enable automatic rotation of asymmetric KMS keys, HMAC KMS keys, KMS keys with imported key material, or KMS keys in a custom key store.

The KMS developer guide states that asymmetric keys are not eligible for on-demand rotation either, and that they are rotated manually. Manual rotation involves creating a new KMS key and changing the target of the alias that your application references to point to the new key. The developer guide notes that when calling Verify with an asymmetric key, you must specify the KeyId parameter (the KMS key ID or key ARN, not the JWT kid), and the request will fail if the alias no longer points to the original key. When using the key to sign tokens, in addition to this, the user still has to add the new public key to the JWKS first and keep the old public key until the old tokens expire. For KMS asymmetric keys, the automatic rotation that IR 8587 Section 5.1.1.4 asks for with SHOULD is a mechanism that users build themselves.

Regarding the signing keys for Cognito user pools, the Cognito developer guide states:

Amazon Cognito might rotate signing keys in your user pool.

The same page recommends caching public keys using the kid as a key and periodically refreshing them. The ability for users to configure the rotation period for Cognito signing keys, or any description of the period itself, was not found in the Cognito developer guide and API reference that this article reviewed.

4.4 Public Key Distribution and What Recipients Check

IR 8587, Section 5.1.1.2, requires that when distributing public keys using JWKS or similar methods, the authenticity and integrity of the keys be ensured, and asks recipients for the following check.

Recipients MUST validate the authenticity of the public key and verify that its algorithm and key size are consistent with expected usage.

The subject of this sentence is the recipient (Recipients). When a recipient validates a JWT using their own code, whether or not they verify the association between the key and the alg parameter depends on the contract of the library they are using. This website's Which alg a JWT Library Accepts When You Do Not Say provides a table outlining the key and alg associations for 13 different libraries. Key length validation is not the subject of that article.

Among AWS receivers, for the API Gateway JWT authorizer, the developer guide states that it only supports RSA-based algorithms and caches the public key for a maximum of two hours. This website's JWT Signing Algorithms on AWS Endpoints addresses the alg and key caching behavior for different AWS endpoints.

4.5 Revocation and Destruction

IR 8587, Section 5.1.1.5, asks with SHOULD that organizations signal that a key should no longer be trusted, and says that this is typically done by removing the key from published metadata (such as OIDC's JWKS and SAML metadata). After removal from distribution, all instances of retired private or secret keys, including operational, backup, and archived copies, MUST be cleared or erased.

In KMS, key deletion is scheduled with the ScheduleKeyDeletion operation. The API reference states that a waiting period between 7 and 30 days can be specified. Removing a public key from your own JWKS is work for the user, outside KMS.

4.6 AWS Table

Setting	Narrowed By	Condition	Set In	If You Set Nothing	What It Does Not Cover
Who may sign with a KMS key	You	Which principals may call kms:Sign	Key policy and IAM policies	If you do not provide a key policy, AWS KMS attaches a default key policy	Whether the RP accepts the resulting token
Signing algorithm on KMS requests	You	Which SigningAlgorithm values Sign and Verify accept	kms:SigningAlgorithm condition key	Any algorithm compatible with the key spec	Verification outside AWS KMS (stated in the KMS Developer Guide)
Key purpose	You	Whether the key is for signing	KeyUsage = SIGN_VERIFY in CreateKey, at key creation	Required for asymmetric keys; you can't change it after creation	Which kinds of tokens or applications the key signs
Rotation of an asymmetric KMS key	You	When a new key signs and the old key stops	A new KMS key, UpdateAlias, and your JWKS	No rotation; automatic and on-demand rotation are not supported	Publishing the new public key and retiring the old one
Key deletion	You	When key material is destroyed	ScheduleKeyDeletion with a 7 to 30 day waiting period	Not deleted	Copies of the public key that recipients cached
Cognito user pool signing keys	AWS (no setting found)	When the signing key changes	No statement was found of a setting	The documentation says Cognito might rotate signing keys	No statement was found on the rotation period

5. Validation and Audience (IR 8587 Sections 5.2 and 5.3.1.3)

IR 8587 Section 5.2 addresses the elements to be included in tokens and assertions, as well as the scope and usage of signing keys. Section 5.3.1.3 deals with audience. This section, following the recommendation table, maps the tokens issued by Cognito and the settings of AWS receivers.

5.1 Recommendation Table

IR 8587 Section	Keyword	Applies When	Addressed To	Recommendation (Summary)
5.2.1	MUST	—	Issuers; RPs	Issuers properly format, structure, and sign; RPs evaluate each token at the lowest level of usage
5.2.1.1	MUST	—	Agencies and CSPs	Document each token type available to consuming agencies and its mandatory data elements
5.2.1.1	MUST	—	(Assertions and tokens)	Contain at least issuer, subject or client, audience, issuance time, validity window, identifier or nonce, authentication time, and signature
5.2.1.1	SHOULD	OAuth-based authorization tokens	(Tokens)	Contain scopes
5.2.1.2	MUST	—	(Signing keys)	Keys that sign assertions and tokens are scoped at the lowest reasonable level; keys that sign assertions are scoped to a specific environment
5.2.1.2	MUST	—	(Keys)	Keys MUST not be usable outside of their defined scope.
5.2.1.2	MUST NOT	—	(Token and assertion signing keys)	Not be used for any other purpose
5.2.1.2	MUST	—	RP and resource server	Confirm the scope, validity, source, and integrity of all tokens before granting access
5.3.1.3	MUST	—	(All tokens and assertions); all access control mechanisms	Include explicit audience fields; reject tokens with incorrect or missing audience restrictions
5.3.1.3	SHOULD	—	Access control mechanisms	Generate a security alert on a missing or incorrect audience
5.3.1.3	MUST	—	IdPs and token services	Limit the scope of tokens to the minimum necessary

5.2 Elements a Token Must Contain

IR 8587, Section 5.2.1.1, mandates (via MUST) that tokens and assertions include at least eight elements, in accordance with SP 800-63C. These elements are: the issuer's identifier, the subject or client identifier, the audience identifier, the issuance time, the validity time window, the token identifier or nonce, the authentication time, and the signature.

Examples of access token payloads, as shown in the Cognito developer guide, include claims such as iss, sub, client_id, auth_time, iat, exp, and jti. The documentation says that claims of two kinds are present only under a condition. The first is the pair of token identifier claims. The Cognito developer guide states that when token revocation is enabled in the app client, the access token and ID token will include the jti and origin_jti claims. The same page notes that for newly created user pool clients, token revocation is enabled by default. The refresh token rotation page says that the same two claims are added after you enable refresh token rotation, and the access token page lists jti without stating a condition. No statement was found of what a client with both features disabled carries. The second is aud in the access token, which is discussed in Section 5.4 of this article.

5.3 Key Scope and Purpose

IR 8587, Section 5.2.1.2, requires with MUST that keys used to sign assertions and tokens be scoped at the lowest reasonable level (e.g., a single tenant, a single customer), and that keys used to sign assertions be scoped to a specific environment (development, testing, production). Regarding purpose, the relevant text states:

Token and assertion signing keys MUST NOT be used for any other purpose.

You set KeyUsage when you create a KMS key. For signing keys, this is SIGN_VERIFY. The KMS API reference describes this as follows:

You can't change the KeyUsage value after the KMS key is created.

The KeyUsage restricts the key's use, preventing encryption and key agreement. However, even with a SIGN_VERIFY key, signing things other than tokens (such as software artifacts or arbitrary messages) is not restricted by the KeyUsage itself. In this article's reading, the way to narrow the purpose restriction of Section 5.2.1.2 in KMS is a key used only for token signing, with a key policy that limits the principals that can call kms:Sign to the issuer. The environment sentence names keys that sign assertions; applying it to a token signing key is also this article's reading. In that reading, scope by environment is narrowed by separating AWS accounts and keys for each environment.

Regarding Cognito, the developer guide states that it signs access tokens and ID tokens with different keys.

Amazon Cognito signs access tokens with a different key from the key that signs ID tokens.

No statement was found in the Cognito pages read for this article on whether keys are scoped below the user pool (for example, per app client).

5.4 Audience

IR 8587, Section 5.3.1.3, discusses audience.

As such, all tokens and assertions MUST include explicit audience fields, and all access control mechanisms MUST reject tokens with incorrect or missing audience restrictions.

The subject of the second MUST in this sentence refers to the access control mechanism, that is, the RP side. What AWS receivers read as the audience differs by receiver. In the case of the API Gateway JWT authorizer, the aud and client_id are handled as follows.

API Gateway validates client_id only if aud is not present.

Cognito access tokens use the client_id claim to identify the app client. Regarding the aud claim in Cognito access tokens, the Cognito developer guide states:

Present only if your application requested a resource binding from your authorization server.

Against the first MUST in IR 8587 Section 5.3.1.3 (that all tokens include explicit audience fields), Cognito access tokens always include the client_id that identifies the app client. The aud claim, which indicates the API, is present only when a resource binding is requested. Whether the client_id is read as the audience depends on the receiver. Verified Permissions, for a Cognito identity source, compares the aud claim in the ID token and the client_id in the access token against a configured list of client IDs. The Verified Permissions user guide states that it does not validate a relying-party audience URL for Cognito identity sources. The list of client IDs (clientIds), however, is not required according to the API reference. The documentation describes the comparison when values are entered; no statement on the case with no values was found in the pages read. A table of how each receiver reads the audience is available in Section 4.3 of JWT Signing Algorithms on AWS Endpoints.

Section 5.3.1.3 also asks with SHOULD that a security alert be generated immediately when a token with a missing or incorrect audience is received. This article did not investigate which AWS setting corresponds to this SHOULD.

5.5 AWS Table

Setting	Narrowed By	Condition	Set In	If You Set Nothing	What It Does Not Cover
Token identifier in Cognito tokens	You	Whether access and ID tokens carry jti and origin_jti	EnableTokenRevocation or refresh token rotation on the app client	Token revocation is enabled by default for new app clients	Uniqueness checks at the RP
Audience at an API Gateway JWT authorizer	You	Which aud (or client_id) values are accepted	JwtConfiguration Audience	Audience is required for the JWT authorizer type	Other receivers; a security alert on rejection (not investigated for this article; Section 5.4 of this article)
Audience at Verified Permissions (Cognito identity source)	You	Which app client IDs are accepted	clientIds in CognitoUserPoolConfiguration	Not required by the API; no statement was found on the empty case	The relying-party audience URL, which is not validated for Cognito identity sources
Audience at Verified Permissions (OIDC identity source, access tokens)	You	Which aud values are accepted	audiences in OpenIdConnectAccessTokenConfiguration	Not required by the API; no statement was found on the empty case	Token type, which you must pass yourself for OIDC sources
Key purpose and key scope for your own issuer	You	Which tokens one key signs, and in which environment	Separate KMS keys per purpose and environment; key policy	One key can sign anything that its key policy allows	KeyUsage does not limit what kind of message is signed
Cognito signing keys per token type	AWS (no setting found)	Access tokens and ID tokens are signed with different keys	No statement was found of a setting	Applied by Cognito	No statement was found on keys scoped below the user pool

6. Token Lifetimes and Refresh (IR 8587 Section 5.3.1.1)

IR 8587, Section 5.3.1.1, addresses the lifetimes of access tokens and ID tokens, as well as refresh tokens. This section will differentiate between MUST and SHOULD statements to determine the ranges and default values for Cognito and IAM Identity Center settings.

6.1 Recommendation Table

IR 8587 Section	Keyword	Applies When	Addressed To	Recommendation (Summary)
5.3.1.1	SHOULD	—	(Automatic refresh mechanisms)	Be implemented with expiration policies tailored to token type, scope, and context
5.3.1.1	MUST	—	(Access tokens and identity tokens)	Have defined, short lifetimes
5.3.1.1	MUST	—	Authorization services and policy enforcement points	Reject expired tokens
5.3.1.1	SHOULD	—	(Access tokens and identity tokens)	Be valid for no more than one hour
5.3.1.1	SHOULD	—	CSPs	Make token validity configurable, with baseline periods by FISMA categorization and assurance level
5.3.1.1	MUST	—	CSPs	Document and present the availability and effectiveness of risk mitigation capabilities
5.3.1.1	SHOULD	—	CSPs; consumers	CSPs make the capabilities available; consumers implement them where possible
5.3.1.1	SHOULD	—	CSPs	Make refresh token validity configurable by consuming agencies
5.3.1.1	SHOULD NOT	Refresh tokens for human users in interactive sessions	(Refresh token lifetime)	Exceed the reauthentication time frames in SP 800-63B-4
5.3.1.1	SHOULD	Refresh tokens for API access, workloads, and non-human interactions	(Refresh tokens)	Be as short as possible, with compromise detection and device registration
5.3.1.1	SHOULD	—	CSPs and agencies	Implement automatic token refresh, with refresh tokens subject to expiration and revocation
5.3.1.1	lowercase (not normative)	—	Authorization servers	Protect refresh tokens from replay (e.g., sender-constraining or rotation)

6.2 Reading MUST and SHOULD Separately

In Section 5.3.1.1, the lifetime sentences with MUST and SHOULD sit next to each other. The MUST sentences are as follows:

Accordingly, access tokens and identity tokens MUST have defined, short lifetimes. Expired tokens MUST be rejected by authorization services and policy enforcement points.

The number "one hour" appears in another sentence in the same paragraph.

While a single, minimum threshold is challenging to pin down due to the availability of different security features, it is recommended that access tokens and identity tokens SHOULD be valid for no more than one hour.

MUST asks for a defined, short lifetime. No more than one hour is SHOULD. The same paragraph asks with SHOULD that CSPs make the lifetime configurable by consumers and provide baseline periods based on FISMA categorization and authentication assurance level. The paragraph following the table states that lifetimes can be adjusted depending on whether capabilities such as sender constraining and device registration are available.

6.3 Ranges and Defaults in Cognito and IAM Identity Center

In Cognito user pools, you can set the token validity period for each app client. The Cognito developer guide states that you can configure the validity period for access tokens and ID tokens between 5 minutes and 1 day. The API reference for UserPoolClientType specifies the default value as follows:

If you don't specify otherwise in the configuration of your app client, your access tokens are valid for one hour.

Regarding ID tokens, the API reference also uses the same format, specifying a duration of 1 hour. The developer guide states that refresh tokens can be configured between 60 minutes and 10 years, while the API reference specifies the default value as 30 days.

The sources disagree on one point. The API reference for AccessTokenValidity states that the valid range, when converted to seconds, is between 1 and 86400. The developer guide states the minimum is 5 minutes. This article will present both values without considering either as incorrect.

The Cognito developer guide includes the following note regarding the use of managed login. Managed login sets a 1-hour cookie in the browser. Even if the access token is set to a shorter duration than 1 hour, this does not affect the validity of the cookie, allowing users to reauthenticate without providing additional credentials for the first hour after their initial sign-in. Against the one-hour SHOULD of IR 8587, in this article's reading, an access token duration shorter than one hour does not shorten the first hour in which a user of managed login can reauthenticate without additional credentials. The refresh token page says in its section on token refresh that the managed login session cookie is valid for one hour, and in its section on signing out that managed login session cookies don't expire automatically and that signed-out users should be redirected to the Logout endpoint, where Cognito clears the session cookie. The sources disagree on the lifetime of the cookie, within the same page as well.

Regarding user interactive sessions in IAM Identity Center, the user guide states:

The default session duration for user interactive sessions is 8 hours.

The same page indicates that you can configure a session duration between 15 minutes and 90 days. This session refers to the sign-in session for the AWS access portal and AWS managed applications. The user guide describes this duration as the maximum time a user can remain signed in without reauthentication. The duration of IAM role sessions created from permission sets is governed by a separate setting, which is covered in the AWS IAM Identity Center Complete Setup Guide.

The duration of temporary credentials from STS (DurationSeconds) and the session duration for authentication on ALB (SessionTimeout, default is 7 days) are detailed in Section 5.4 of JWT Signing Algorithms on AWS Endpoints. As mentioned in Section 1.3 of this article, temporary credentials from STS are not the tokens covered by IR 8587; therefore, this article does not apply the 1-hour statement in Section 5.3.1.1 to those credentials.

6.4 Refresh Tokens

Section 5.3.1.1 uses lowercase "must" to describe preventing replay attacks on refresh tokens.

Authorization servers must protect refresh tokens from being replayed (e.g., through sender-constraining or rotation).

This sentence is not normative. Sender constraining and rotation are given as examples of the means.

Cognito allows you to configure refresh token rotation on the app client. When enabled, a new refresh token is issued with each refresh, and the original refresh token is invalidated. You can configure a grace period of up to 60 seconds for the original refresh token to allow for retries. The Cognito developer guide describes the relationship between rotation and validity period as follows:

Rotation reissues a refresh token within the same fixed validity window. It doesn't extend the window.

To enable rotation, you must turn off the REFRESH_TOKEN_AUTH authentication flow and perform the refresh using GetTokensFromRefreshToken. The steps for configuring refresh and rotation in Cognito are detailed in Sections 12.1 and 13.5 of the Amazon Cognito Federation Complete Implementation Guide on this site.

No statement describing how to protect Cognito refresh tokens with sender constraining (DPoP, mTLS) was found in this article's search (the Cognito developer guide, the API reference for UserPoolClientType, and a What's New search).

6.5 AWS Table

Setting	Narrowed By	Condition	Set In	If You Set Nothing	What It Does Not Cover
Cognito access and ID token validity	You	How long each token is accepted	AccessTokenValidity, IdTokenValidity, TokenValidityUnits	One hour each	Managed login session cookies, whose lifetime the sources state differently (Section 6.3 of this article); revocation before expiry
Cognito refresh token validity	You	How long the refresh token can be used to get new tokens	RefreshTokenValidity	30 days	Replay of a refresh token, unless rotation is on
Cognito refresh token rotation	You	Whether each refresh issues a new refresh token and invalidates the old one	RefreshTokenRotation and GetTokensFromRefreshToken	Not rotated; the original refresh token remains valid	Extending the validity window; sender constraining
IAM Identity Center user interactive session	You	How long a user stays signed in to the AWS access portal	Session duration in the Identity Center settings (15 minutes to 90 days)	8 hours	IAM role sessions already created from permission sets; existing sessions (a change applies only to new sessions)
STS temporary credentials and ALB authentication sessions	You	Duration of credentials or the authentication session	DurationSeconds; SessionTimeout	3,600 seconds (AssumeRole, AssumeRoleWithWebIdentity); 7 days (ALB); see JWT Signing Algorithms on AWS Endpoints, Section 5.4	Not tokens in IR 8587's scope (STS); not mapped to the one-hour SHOULD

7. Revocation and Session Revocation Signals (IR 8587 Section 5.3.1.2)

IR 8587, Section 5.3.1.2, addresses token revocation and the mechanism for notifying the RP of revocation status. This section will first examine the limitations of stateless tokens, as described within IR 8587 itself. Subsequently, it will outline the extent to which revocation is propagated within AWS, detail what ending an IAM Identity Center session does not reach, and discuss what was found and what was not found regarding SSF and CAEP.

7.1 Recommendation Table

IR 8587 Section	Keyword	Applies When	Addressed To	Recommendation (Summary)
5.3.1.2	MUST	The identity token or assertion is suspected of compromise	IdPs and token services	MUST not accept refresh tokens associated with it without first reauthenticating the user
5.3.1.2	SHOULD	To the extent possible	IdPs and token services	Provide token and assertion revocation capabilities
5.3.1.2	SHOULD	—	IdPs and token services	Provide a means to propagate revocation status to associated RPs
5.3.1.2	MUST	If this capability is available	Connected RPs	Reject revoked tokens and terminate active sessions associated with them
5.3.1.2	SHOULD	—	CSPs and consuming agencies	Implement session revocation signals
5.3.1.2	MUST	—	CSPs; consuming agencies	CSPs convey the extent and methods of revocation; agencies assess the risks of revocation scenarios

7.2 The Limits of Stateless Tokens

Section 5.3.1.2 first states that stateless tokens do not always allow for immediate and complete revocation.

Immediate and global token revocation is not always possible in stateless token implementations before the expiration of token validity periods.

Furthermore, it describes how combining short-lived access tokens with refresh tokens and reauthentication can limit the time a compromised token remains usable. Regarding refresh tokens associated with an identity token or assertion suspected of being compromised, the following statement is made:

Effective implementation of this means that IdPs and token services MUST not accept refresh tokens that are associated with an identity token or assertion that has been suspected of compromise without first reauthenticating the user.

The MUST for RPs comes with a condition.

If this capability is available, connected RPs MUST reject tokens that have been revoked and terminate active sessions associated with revoked tokens.

This capability is the means of delivering revocation status to RPs that IR 8587 names, with SHOULD, in the sentence just before this one (a token introspection endpoint, a token status list, shared signaling).

7.3 How Far Revocation Reaches on AWS

Previously published articles on this site cover, with quotations, how far revocation reaches on AWS. This article summarizes each briefly and links to those articles.

• Cognito Token Revocation: The Cognito developer guide states that while revoked tokens cannot be used with Cognito's APIs, they remain valid if verified using a JWT library that checks the signature and expiration date. Procedures and considerations are discussed in Sections 12.2 and 12.3 of the Amazon Cognito Federation Complete Implementation Guide.
• Verified Permissions: The Verified Permissions API reference states that tokens for users from an identity source remain valid until their expiration, and that token revocation does not affect the validity of tokens in the policy store. This is covered in Section 5.4 of JWT Signing Algorithms on AWS Endpoints.
• STS Temporary Credentials: To stop issued credentials before they expire, you deny them in the role's policy with a condition on aws:TokenIssueTime. The unit of control is the role. This is discussed in Sections 7.5 and 7.6 of AWS IAM Inbound Workload Federation. The IAM user guide notes that sessions for service-linked roles cannot be revoked.

The Cognito developer guide describes the reach of token revocation mainly in terms of Cognito API calls that require a token. No description was found in the pages of the Cognito developer guide read for this article, detailing Cognito endpoints that propagate revocation status to local JWT verification endpoints (RPs) – such as token introspection. In this article's reading, the premise of the conditional MUST requirement (IR 8587), a mechanism for propagating revocation status, cannot be read as met for local JWT verification RPs.

The following diagram illustrates how far revocation reaches on AWS and where it stops.

7.4 Ending an IAM Identity Center Session

IAM Identity Center allows administrators to terminate active user sessions. A note on the user guide's procedure page states what ending a session does not reach:

Ending an active session for an IAM Identity Center user doesn't end any active IAM role sessions in the AWS Management Console or AWS CLI.

The page describing Identity Center's authentication sessions explains that application sessions end at the next refresh attempt, typically within 30 minutes. Regarding IAM role sessions, it states:

Within 12 hours or less – IAM role sessions operate independently and only end when their configured duration expires.

In other words, even after ending a session in Identity Center, the IAM role sessions that the user created from permission sets continue until the duration configured in the permission set expires (up to 12 hours). The IAM user guide notes that roles created from Identity Center permission sets cannot be edited in IAM, and directs you to revoke the active permission set session in Identity Center. This article did not read the Identity Center page for that operation; it is a different operation from ending an active session.

7.5 SSF and CAEP - What Was Searched

IR 8587, Section 5.3.1.2, names SSF and CAEP as standard mechanisms that include a session revocation signal, and writes the following SHOULD.

The SSF has seen significant adoption, and CSPs and consuming agencies SHOULD implement session revocation signals to provide greater session termination capabilities.

IR 8587 gives the publisher of SSF as Open Identity Foundation. The OpenID Foundation publishes the SSF and CAEP specifications. Section 7.2 of this site's Where AI Agent Authorization Standards Stand discusses the status of the specifications for both.

IR 8587 Sections 5.3.1.4 and 7.6 also recommend shared signals, but the use of "should" in those sections is in lowercase and does not represent a normative requirement.

For Cognito user pools, IAM Identity Center, Verified Permissions, and other AWS services, no description of a feature that receives or sends SSF streams or handles CAEP session revocation events was found in this article's search. The search covered the following (October 17, 2026):

• Searching AWS documentation (using the AWS Knowledge MCP Server) using terms such as "Shared Signals Framework," "CAEP," "Continuous Access Evaluation Profile," "security event token," "SSF transmitter," and "SSF receiver."
• Reviewing the "What's New" section of the same search.
• Web searches using terms such as "AWS" combined with "Shared Signals" or "CAEP," as well as "Cognito," "IAM Identity Center," and "Verified Access."
• Examining the lists of operations for Cognito user pools (including all items under UserPoolClientType), the management APIs and Identity Store APIs for IAM Identity Center, and the OIDC APIs, using terms such as "signal," "stream," and "event."

AWS Verified Access evaluates access using data from IAM Identity Center and OIDC trust providers. The Verified Access user guide states:

Verified Access evaluates each application access request in real time.

This is an evaluation performed with each request, and is distinct from receiving CAEP events. This article does not state that AWS does not support SSF or CAEP. What was not found is a description in this article's search.

7.6 AWS Table

Setting	Narrowed By	Condition	Set In	If You Set Nothing	What It Does Not Cover
Cognito refresh token revocation	You	Whether a refresh token and the tokens it issued can be revoked	EnableTokenRevocation; RevokeToken	Enabled by default for new app clients	Tokens verified locally by a JWT library (Amazon Cognito Federation Complete Implementation Guide, Section 12.3)
Cognito user sign-out	You	Revoke a user's refresh, ID, and access tokens	GlobalSignOut; AdminUserGlobalSignOut	Not applied unless you call the operation	Tokens verified locally by a JWT library; re-authentication with a managed login session cookie until the user is sent to the Logout endpoint (the sources state the cookie lifetime differently; Section 6.3 of this article)
Verified Permissions	AWS (no setting found)	Tokens are checked for expiration and signature	IsAuthorizedWithToken	Revocation has no effect on token validity in the policy store	Revocation status from the IdP
IAM role sessions (STS)	You	Deny credentials issued before a time	Revoke active sessions (AWSRevokeOlderSessions); aws:TokenIssueTime	Credentials last until they expire	Service-linked roles; per-session revocation (AWS IAM Inbound Workload Federation, Sections 7.5 and 7.6)
IAM Identity Center active sessions	You	End a user's sign-in session	Identity Center console, Users, Active sessions	Sessions last for the configured duration	Active IAM role sessions in the console or AWS CLI
Session revocation signals (SSF, CAEP)	—	Propagate revocation to connected RPs	No statement was found	—	Searched on 2026-10-17 (Section 7.5 of this article)

8. Monitoring, Token Protection, Workloads, and Logging (IR 8587 Sections 5.3.1.4 to 5.3.1.7 and 4.1.4)

Sections 5.3.1.4 through 5.3.1.7 of IR 8587 address the monitoring of token usage, the protection of tokens in logs and pipelines, workload tokens, and logging. Section 4.1.4 concerns ensuring that authorization decisions are not solely based on token validity. This section consolidates these topics.

8.1 Recommendation Table

IR 8587 Section	Keyword	Applies When	Addressed To	Recommendation (Summary)
4.1.4	SHOULD NOT	—	Authorization systems	Make access decisions based solely on the validity of a token; also use the context
5.3.1.4	MUST	—	CSPs and consumers	Implement capabilities to monitor token and assertion usage patterns
5.3.1.4	MUST	—	(Token and assertion usage data)	Be provided in a format consumable by SIEM software
5.3.1.4	lowercase (not normative)	—	IdPs, token services, and access management tools	Implement shared signals
5.3.1.5	MUST	—	(All tokens)	Be protected from exposure in system logs, CI/CD pipelines, and build or deployment artifacts
5.3.1.5	MUST	—	(Pipelines)	Retrieve secrets only through secret management systems and inject them at runtime
5.3.1.6	MUST / SHOULD	—	Workload identities	Use tightly scoped, short-lived tokens (MUST); use sender-constrained mechanisms whenever feasible (SHOULD)
5.3.1.7	MUST	—	All components	Maintain tamper-resistant logs of token and assertion-related events
5.3.1.7	MUST NOT	—	(Tokens and assertions; PII in tokens)	Be stored in logs
5.3.1.7	MUST / SHOULD	—	CSPs	Log token-related data available to federal consumers (MUST); make it available programmatically (SHOULD)

8.2 Monitoring

Section 5.3.1.4 requires with MUST that both CSPs and consumers implement capabilities to monitor token usage, and with MUST that this data be provided in a format that SIEM software can consume.

On the AWS side, the following resources are available. The KMS Developer Guide states that AWS CloudTrail records calls to the KMS API (although it is possible to exclude KMS operations from the logs), and provides an example of a logged Sign event. The Cognito Developer Guide states that user pools with threat protection enabled in the Plus feature plan log user activity for sign-ins, sign-outs, and other authentication operations, and can output this data to CloudWatch Logs, Amazon Data Firehose, and Amazon S3. These are inputs to monitoring. In this article's reading, the mechanism that detects abnormal token usage (such as geographical location, device, or velocity) and notifies RPs is a part that the user builds.

8.3 Keeping Tokens Out of Logs and Pipelines

Section 5.3.1.7 discusses logging and includes the following:

The tokens and assertions themselves MUST NOT be stored in logs. Additionally, PII or personal data contained in tokens MUST NOT be stored in logs.

Regarding logs from AWS services, the IAM Identity Center user guide indicates that, in examples of CloudTrail logs documenting token exchange, the values for subjectToken, assertion, and code are shown as HIDDEN_DUE_TO_SECURITY_REASONS. The KMS developer guide also states that, for security reasons, certain items, such as responses to cryptographic operations, are omitted from the logs.

Conversely, logs generated by the user's applications reside on the user's side. For example, if a Lambda function behind an API Gateway logs request headers directly, the token in the Authorization header may remain in the logs. Section 5.3.1.5 requires with MUST that tokens also be kept out of CI/CD pipelines and artifacts. In this article's reading, these two sections are recommendations that are more applicable to how users design their applications and pipelines, rather than to specific AWS settings.

8.4 Short-Lived Workload Tokens and Sender Constraining

Section 5.3.1.6 describes workload tokens with the following statement:

Workload identities — including non-person entities, automated services, and machine-to-machine processes — MUST use tightly scoped, short-lived tokens that are issued exclusively through approved enterprise identity platforms and SHOULD use sender-constrained mechanisms (e.g., mTLS, DPoP [16][17]) whenever feasible.

The subject of this statement is workload identities. It is not addressed to the tokens of human users.

Within Cognito's user pools, it is possible to issue access tokens for machine-to-machine authorization with the client credentials flow. A "What's New" announcement from August 31, 2026, indicated that it is now possible to obtain machine-to-machine access tokens using the GetClientToken API, even without configuring the user pool's domain. Lifetime and scope are narrowed with the same app client settings as in Section 6 of this article. Descriptions of configuring Cognito access tokens to bind them to the sender using DPoP or mTLS were not found in the same scope as Section 6.4 of this article.

The STS temporary credentials that AWS workloads use to call AWS APIs are not tokens in the scope of IR 8587, as described in Section 1.3 of this article. The integration of external workloads accessing AWS using their own IdP's JWT is covered in this site's AWS IAM Inbound Workload Federation.

8.5 Not Deciding on Token Validity Alone

Section 4.1.4 describes the authorization mechanism with the following text:

Authorization systems SHOULD NOT make access decisions based solely on the validity of a token but also based on the context in which it is presented.

The IsAuthorizedWithToken operation of Verified Permissions verifies the token's expiration date and signature, and then makes a determination based on Cedar policies. It can utilize the context passed with the request, as well as the attributes of the resource, in the policy conditions. In this article's reading, this context is what the context in Section 4.1.4 corresponds to. The application used by the user determines what context is passed. The design of Verified Permissions and Cedar is further detailed in this site's AWS Verified Permissions and Cedar Policy Language Complete Guide.

8.6 AWS Table

Setting	Narrowed By	Condition	Set In	If You Set Nothing	What It Does Not Cover
Records of AWS KMS events in CloudTrail	You	Whether AWS KMS events (all of them, not individual signing calls) are recorded in a trail, and where trails deliver them	AWS CloudTrail trails and retention	KMS operations are logged as CloudTrail events	Use of the signed token after issuance
Cognito user activity logs	You	Sign-in and authentication events with risk assessment	Plus feature plan, threat protection, log streaming	Export requires the Plus feature plan with threat protection active (Audit-only at minimum); by default, the events are captured to storage in the user pool	Token use at RPs
Tokens in AWS service logs	AWS (no setting found)	Token values in CloudTrail records	Applied by the service	Some fields are hidden or omitted (Identity Center and KMS examples); the AssumeRoleWithWebIdentity entry includes the Subject of the web identity token	Logs your application writes
Tokens in your application logs and pipelines	You	Whether tokens and PII reach logs and artifacts	Your code, logging configuration, and CI/CD	Whatever your code writes	—
Context in authorization decisions	You	Decisions beyond token validity	Verified Permissions policies and the context you pass	Decided by the policies alone	Context your application does not pass
Machine-to-machine tokens from Cognito	You	Scope and lifetime of workload access tokens	App client, resource server scopes, GetClientToken	One-hour access tokens	Sender constraining; no statement was found

9. Considerations Outside the Control Sections (IR 8587 Section 7)

IR 8587 Section 7 lists considerations that fall outside the control sections. This article covers three of them, one paragraph each.

IR 8587 Section 7.3 asks with SHOULD that tokens containing personal information or claims that indicate privileges be encrypted at the payload level, and gives JWE for JWTs as an example. Cognito access tokens and ID tokens are signed JWTs, and no description of a setting that lets users make them JWE was found in the Cognito pages read for this article.

IR 8587 Section 7.6 mentions a framework for risk and shared signals, suggesting that agencies and CSPs should consider adopting it. The should here is lowercase. The situation on the AWS side is as far as Section 7.5 of this article describes.

IR 8587 Section 7.7 addresses the transition to post-quantum cryptography, citing FIPS 204's ML-DSA. The AWS KMS Sign API reference lists ML_DSA_SHAKE_256 as a supported signing algorithm. AWS's approach to post-quantum cryptography is further detailed on this site's Post-Quantum Cryptography Standardization Timeline and Migration on AWS.

10. Failure Modes

This section lists common misinterpretations that can occur when applying IR 8587 to AWS.

• Reading IR 8587 as a checklist: IR 8587 is a recommendation for CSPs and federal government agencies, and conformance is voluntary unless policy or other binding agreements determine otherwise. It does not require fulfilling every row in the tables, and IR 8587 Section 1.2 says, after defining the normative terms, that agencies may choose to include these requirements in whole or in part based on risk management needs (Sections 1.2 and 2.3 of this article).
• Interpreting the frequency of capitalized words as the number of requirements: The counts for MUST (70), SHOULD (48), and MAY (6) are occurrences, including definitions and examples (Section 2.3 of this article).
• Reading no more than one hour as a MUST: The MUST is for a defined, short lifetime; no more than one hour is a SHOULD (Section 6.2 of this article).
• Applying a 90-day rotation to all systems: 90 days is a SHOULD that applies to high-impact systems; for moderate and low impact, the SHOULD is less than one year (Section 4.3 of this article).
• Assuming that placing keys in KMS fulfills IR 8587 Section 5.1: Asymmetric KMS keys are not eligible for automatic rotation, and the purpose restriction and public key distribution remain the user's design (Sections 4.3, 4.4, and 5.3 of this article).
• Reading that kms:SigningAlgorithm narrows the alg at the RP: This condition key has no effect on verification outside of KMS (Section 4.2 of this article).
• Reading that Cognito revocation reaches all RPs: It does not reach RPs that verify JWTs locally (Section 7.3 of this article).
• Reading that ending an IAM Identity Center session stops access to AWS: Ending the session alone does not end IAM role sessions created from permission sets; they continue until their configured duration expires, and the IAM user guide directs you to revoke the active permission set session in Identity Center (Section 7.4 of this article).
• Reading STS temporary credentials as tokens within IR 8587: The security controls within IR 8587 apply to tokens and assertions signed with asymmetric keys (Section 1.3 of this article).
• Reading not found as not supported: What this article states for SSF and CAEP is that no description was found in its search (Sections 2.7 and 7.5 of this article).
• Referring to IR 8587 using the section numbers in Table 7: The column numbers in Table 7 are the initial public draft numbers and differ from the headings of the final version (Section 2.5 of this article).

11. Frequently Asked Questions About IR 8587 and AWS Settings

This section addresses common questions that arise when applying IR 8587 to AWS, with answers within what the body sections of this article verified.

Q1. Is there an obligation to follow IR 8587 on AWS?

IR 8587 itself states that for CSPs and federal government agencies, conformance with these guidelines is voluntary, unless otherwise determined through policy or other binding agreements such as contracts and grants. IR 8587 is addressed to CSPs and federal agencies, not to AWS users in general, and the document does not mention AWS by name.

Q2. Must access tokens be valid for no more than one hour?

IR 8587, Section 5.3.1.1, requires, with MUST, defined short lifetimes and the rejection of expired tokens. The limit of one hour is a SHOULD. Cognito's access tokens and ID tokens default to a one-hour validity period, and the developer guide gives a range of 5 minutes to 1 day (the API reference gives a different minimum; Section 6.3 of this article).

Q3. Can an asymmetric KMS key be rotated automatically?

No. The KMS API reference states that automatic key rotation only applies to symmetric encryption keys and cannot be enabled for asymmetric keys. The developer guide indicates that asymmetric keys are rotated manually. Creating new keys and switching the alias and the JWKS are left to users.

Q4. Can you set the rotation period of Cognito user pool signing keys?

No statement about such a setting was found in the Cognito developer guide and API reference read for this article. The developer guide does state that Cognito may rotate signing keys and recommends caching and refreshing public keys on a per kid basis.

Q5. Can AWS receive CAEP session revocation events?

In this article's search (October 17, 2026, Section 7.5 of this article), no description of an AWS feature that receives or sends SSF or CAEP events was found. This does not mean that AWS does not support them. IR 8587 Section 5.3.1.2 asks CSPs and consuming agencies to implement session revocation signals with SHOULD. The MUST for connected RPs depends on a separate condition: that a means of propagating revocation status to RPs is available (for example, token introspection, a token status list, or shared signaling).

Q6. If you end a user's session in IAM Identity Center, does the user lose access to AWS?

The IAM Identity Center user guide states that even after an active session of a user is ended, active IAM role sessions in the AWS Management Console and AWS CLI will not end. These IAM role sessions will continue until the duration configured in the permission set expires (up to a maximum of 12 hours). The IAM user guide directs you to revoke the active permission set session in Identity Center (Section 7.4 of this article).

Q7. Are AWS STS temporary credentials in the scope of IR 8587?

Section 1.1 of IR 8587 places systems that do not rely on asymmetrically signed tokens and assertions (schemes based on symmetric cryptography, API keys, and so on) outside the scope of its controls. Since temporary STS credentials are not signed JWTs, this article does not treat them as tokens under IR 8587. In the diagram in Section 3.2 of this article, STS is placed as an RP receiving JWTs from an external IdP. Credential duration and revocation are in the tables of Sections 6.5 and 7.6 of this article as rows that link to previously published articles.

Q8. When was the information in this article verified?

The information was verified on October 17, 2026. IR 8587 was reviewed based on the final version dated September 15, 2026, and the CSRC page showed no errata. The ranges and defaults of the AWS settings were verified by reviewing the developer guides, user guides, and API references for each service, all on the same date.

12. Summary

This article confirmed six points:

• IR 8587 is a recommendation for CSPs and federal government agencies, and conformance is voluntary unless policy or other binding agreements determine otherwise. The text does not mention AWS directly. This article lays out which recommendations AWS settings correspond to as this article's reading.
• The controls of IR 8587 cover asymmetrically signed tokens and assertions. This article does not treat STS temporary credentials as IR 8587 tokens.
• The strength of the normative keyword differs from sentence to sentence. For lifetimes, the MUST is a defined, short lifetime, and no more than one hour is SHOULD. For key usage periods, no more than 90 days at high impact and less than one year at moderate and low impact are SHOULD.
• A KMS asymmetric key keeps the signing key in an HSM, but it is not eligible for automatic rotation. Rotation, purpose restriction, and public key distribution remain the user's design. No setting for Cognito signing keys was found in the pages read for this article.
• Cognito revocation does not reach local JWT verification, and revocation does not affect token validity in Verified Permissions. Ending a user's session in IAM Identity Center alone does not end the IAM role sessions created from permission sets.
• Descriptions of AWS features that receive or send SSF and CAEP were not found in this article's search. IR 8587 asks for session revocation signals with SHOULD.

13. References

• NIST IR 8587 Protecting Tokens and Assertions from Forgery, Theft, and Misuse (CSRC)
• NIST IR 8587 (PDF)
• AWS KMS Developer Guide - AWS Key Management Service
• AWS KMS Developer Guide - Asymmetric keys in AWS KMS
• AWS KMS Developer Guide - Rotate AWS KMS keys
• AWS KMS Developer Guide - Rotate keys manually
• AWS KMS Developer Guide - AWS KMS condition keys
• AWS KMS Developer Guide - Logging AWS KMS API calls with AWS CloudTrail
• AWS KMS API Reference - GetKeyRotationStatus
• AWS KMS API Reference - CreateKey
• AWS KMS API Reference - Sign
• AWS KMS API Reference - ScheduleKeyDeletion
• Amazon Cognito Developer Guide - Verifying JSON web tokens
• Amazon Cognito Developer Guide - Understanding the access token
• Amazon Cognito Developer Guide - Understanding the identity (ID) token
• Amazon Cognito Developer Guide - Refresh tokens
• Amazon Cognito Developer Guide - Revoking tokens
• Amazon Cognito Developer Guide - Exporting logs from Amazon Cognito user pools
• Amazon Cognito API Reference - UserPoolClientType
• Amazon Cognito now supports machine-to-machine authorization without a user pool domain (What's New, August 31, 2026)
• IAM Identity Center User Guide - User interactive sessions
• IAM Identity Center User Guide - View and end active sessions for your workforce users
• IAM Identity Center User Guide - Understanding authentication sessions in IAM Identity Center
• IAM Identity Center User Guide - CloudTrail use cases for IAM Identity Center
• IAM User Guide - Revoke IAM role temporary security credentials
• CISA and NIST Release Guidelines to Protect Federal Cloud Identity Systems from Token Theft, Forgery, and Misuse (CISA, September 15, 2026)
• Hands Off my Tokens! NIST Finalizes Interagency Report 8587 (NIST CSRC News, September 15, 2026)
• AWS Verified Access User Guide - What is AWS Verified Access?
• IAM User Guide - AWS Signature Version 4 for API requests
• AWS STS API Reference - AssumeRole
• API Gateway Developer Guide - Control access to HTTP APIs with JWT authorizers
• Elastic Load Balancing - Authenticate users using an Application Load Balancer
• Verified Permissions API Reference - IsAuthorizedWithToken
• Verified Permissions User Guide - Client and audience validation for Amazon Cognito
• Verified Permissions User Guide - Client and audience validation for OIDC providers
• Verified Permissions API Reference - CognitoUserPoolConfiguration
• Verified Permissions API Reference - OpenIdConnectAccessTokenConfiguration
• JWT Signing Algorithms on AWS Endpoints - What IAM, Application Load Balancer, API Gateway, AppSync, Cognito, and IAM Identity Center Accept, and What They Check Besides the Signature
• Amazon Cognito Federation Complete Implementation Guide - Google, Apple, Microsoft, OIDC, and SAML
• AWS IAM Inbound Workload Federation - IAM Roles Anywhere, OIDC, and SPIFFE Converging on One Trust Policy Condition
• Which alg a JWT Library Accepts When You Do Not Say - Algorithm Allowlists, Key Binding, Unknown Keys in a JWKS, and RFC 8725
• Where AI Agent Authorization Standards Stand - RFCs, IETF Working Group Documents, Individual Drafts, and Specifications from Other Bodies
• AWS IAM Identity Center Complete Setup Guide - Multi-Account SSO Design Patterns from Organization Structure to ABAC
• AWS Verified Permissions and Cedar Policy Language Complete Guide
• Post-Quantum Cryptography Standardization Timeline and Migration on AWS - From Algorithm Selection to Service Support
• OWASP Top 10 for Agentic Applications Mapped to AWS Controls - What Each Control Mitigates and What Residual Risk Remains
• OWASP Top 10 for Large Language Model Applications Mapped to AWS Controls - What Each Control Covers, Where It Stops, and What the Application Still Owns

References:
Tech Blog with curated related content