What Is AWS STS? Definition & Examples

AWS Security Token Service, the service that issues temporary, time-limited credentials for an assumed identity or role. It is the credential issuance step in the AWS access chain and is commonly used to reduce reliance on static access keys.

AWS STS as a Temporary Credential Issuer

AWS Security Token Service sits at the centre of the AWS access chain because it exchanges an existing trust relationship for short-lived credentials. That makes it the mechanism that turns an authenticated identity or role into usable session access without exposing long-lived access keys.

In practice, STS is what enables temporary access for human users, applications, workloads, and cross-account access patterns. The important security property is not just that it issues tokens, but that those tokens are scoped, time-bound, and tied to the permissions of the assumed role or session policy.

Where STS Fits in AWS Authorization

STS does not define what an identity may do on its own. It depends on IAM roles, trust policies, and permission boundaries to decide which principal can assume which role and what the resulting session can access. That is why STS is best understood as an authorization bridge rather than a standalone control.

Its role is especially important in federated access and cross-account access, where a caller is authenticated elsewhere and then receives temporary AWS credentials for a specific AWS principal. The security model improves when the assumed session is narrower than a static key, but only if the trust policy is accurate and the permissions granted to the role are least privilege.

For cloud workload identity patterns, STS is the point where identity assurance becomes operational access. NHIMG’s Cloud Workload Identity Guide is a useful companion for understanding how AWS STS fits into keyless workload access across cloud platforms.

Common Ways STS Is Used

One common use is AssumeRole, where a principal receives temporary credentials for a role in the same or another account. Another is web identity federation, where an external identity provider or OIDC flow is exchanged for AWS credentials without creating a new long-lived AWS secret.

STS is also used indirectly by many AWS services that need to act on behalf of something else, such as EC2 instance profiles or Lambda execution roles. In those cases, the service is not the identity itself, but it becomes the delivery path for temporary credentials tied to the workload’s permitted scope.

Because STS sessions are ephemeral, they help reduce key sprawl and simplify revocation compared with static access keys. The trade-off is that session issuance becomes highly sensitive, since a mistake in trust configuration can grant access quickly and at scale.

Why STS Matters for Security and Operations

STS is a control point for reducing standing credential exposure, but it also concentrates trust decisions. When STS is used well, it supports short-lived access, federation, and separation of duties; when it is used poorly, it can hide broad privilege behind a temporary session that is hard to distinguish from legitimate use.

Session duration, role scope, external identity trust, and the use of role chaining all affect the blast radius of a compromised session. The operational lesson is that the security of STS depends less on the token itself and more on how tightly the trust relationship and downstream permissions are defined.

NHIMG’s 230M AWS environment compromise illustrates how exposed cloud credentials can become a large-scale access problem, while TruffleNet BEC Attack — Stolen AWS Credentials shows how stolen AWS credentials can be abused for downstream compromise and lateral movement.

Risk and Threat Considerations

STS reduces reliance on static secrets, but it also creates a high-value trust exchange point. If an attacker can assume a role, abuse a federation path, or steal a live session, they can operate with valid AWS credentials that may look normal to basic monitoring.

Failure mechanism: Weak trust policies, overbroad role permissions, or compromised upstream identities can let an attacker mint temporary credentials that inherit more access than intended. Session tokens are short-lived, but they are still powerful until they expire or are revoked through the underlying trust relationship.

Impact: Misuse of STS can lead to unauthorized resource access, privilege escalation across accounts, and stealthy cloud persistence through repeated session issuance. The practical consequence is that a temporary credential model can still produce durable exposure when the trust boundary is too loose.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	STS issues time-limited credentials that must be managed across their lifecycle.
	IA-9 — Service Identification and Authentication	STS commonly authenticates services, workloads, and cross-service assumptions.
	AC-6 — Least Privilege	STS sessions should inherit only the minimum permissions needed for the assumed role.
Recommendation — Rotate and expire STS-adjacent credentials and tokens on defined schedules. Require strong service authentication before allowing role assumption. Scope STS-issued sessions to the minimum permissions required.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	STS is a temporary credential issuance mechanism central to non-human authentication patterns.
	NHI-05 — Overprivileged NHI	STS session permissions are often the practical manifestation of workload or service privilege.
	NHI-07 — Long-Lived Secrets	STS is commonly used to replace static AWS keys with short-lived credentials.
Recommendation — Harden role trust and federation so STS cannot mint credentials from weak assertions. Reduce role permissions so STS sessions cannot exceed their intended scope. Prefer STS-issued short-lived credentials over static access keys.
NIST SP 800-63	Digital Identity Guidelines	Federated identity and assurance underpin external-to-AWS role assumption flows.
Recommendation — Apply strong identity proofing and phishing-resistant authentication before federation.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	STS embodies verify-before-access and least-privilege session issuance.
Recommendation — Evaluate each STS session as a separately authorized trust decision.

Practitioner Guidance

Why practitioners should care: STS is only as strong as the trust policy and the role it issues. If either side is too broad, temporary credentials become a fast path to excessive access rather than a reduction in risk.

What to watch for: Pay close attention to long session durations, wildcard trust relationships, and roles that are reused across too many workloads or accounts. These patterns often signal that the temporary-credential design is becoming hard to govern.

Practitioner takeaway: Treat STS as an authorization control plane, not just a convenience service, and design every assumed role so its trust scope and permissions are intentionally narrow.

AWS STS