AWS STS

AWS STS in the AWS access chain

AWS Security Token Service sits in the middle of the access chain: it exchanges an authenticated caller context for temporary credentials tied to a role or assumed identity. That design matters because the service is not a permission system by itself, it is the mechanism that issues time-limited credentials the rest of AWS will honor.

Because STS is used to move from a source identity into an assumed role, the security question is usually not “can STS authenticate?” but “what trust relationship does STS allow to be expressed, and how tightly is that trust constrained?”

Why temporary credentials change the security model

STS reduces reliance on long-lived access keys by replacing them with short-lived session credentials. That lowers the blast radius of key leakage, but it also makes session design, expiry, and role trust policy part of the security boundary. If a session is issued too broadly, too long, or to the wrong principal, the temporary nature of the credential does not prevent misuse.

In practice, STS is what makes role-based access portable across accounts, applications, federation flows, and automation. The benefit is cleaner credential hygiene, but the tradeoff is that trust policy mistakes can become direct authorization errors.

Common AWS STS use cases and trust patterns

Teams commonly use STS for cross-account access, federated workforce access, workload authentication, and ephemeral access in CI/CD. In each case, the caller proves something about itself first, then receives credentials that inherit the permissions of the target role. The important control is therefore the trust policy and the conditions attached to it, not just the role permission policy.

Features such as session tags, source identity, web identity federation, and role chaining make STS powerful, but they also increase the need for consistent naming, attribution, and revocation discipline. These mechanisms are most valuable when they let defenders understand who assumed what, from where, and for how long.

For a practical overview of how STS fits into broader cloud identity design, see Cloud Workload Identity Guide and the AWS STS and AssumeRole Guide.

How to assess and govern AWS STS usage

Exposure review starts with inventorying where STS is used, which roles are assumed, and which identities can reach those roles. The next questions are whether those trust paths are intentional, whether external or third-party assumptions are constrained, and whether session duration matches the operational need.

That governance view should extend to temporary credential lifetime design across humans, workloads, and integrations. If sessions stay active far longer than the job that requested them, STS shifts from a least-privilege enabler into a durable access path.

For lifetime design and rollout considerations, Token Lifetime Policy Design Guide is useful background.

Detection, revocation, and post-usage review

When STS is central to an access path, monitoring should focus on AssumeRole events, unusual session duration, unexpected source identities, cross-account assumptions, and suspicious patterns of role chaining. Because STS credentials are temporary, defenders often miss misuse if they only look for static key abuse.

Post-incident review should ask whether any sessions were issued under overly broad trust conditions, whether session tags or source identity were present, and whether the role could be assumed by principals that were no longer expected to have access. If compromise is suspected, revocation and trust-policy tightening need to happen together.

Where third-party delegation is involved, the attack pattern described in MITRE ATT&CK T1199 Trusted Relationship Guide is a useful lens for understanding how attackers abuse trusted access paths.

Related resources from NHI Mgmt Group

• How should security teams use AWS STS to reduce standing access in cloud environments?
• What is the difference between AWS STS and permanent IAM credentials?
• How should teams design AWS application access when Cognito Identity Pools, STS, and IAM roles all participate in the credential flow?
• Why does using temporary credentials through STS reduce risk compared with long-lived AWS credentials?