AWS Security Token Service is the service that issues temporary credentials for AWS access. These tokens expire after a short period and can be scoped to specific permissions, which reduces the value of stolen credentials. It is a core control for replacing static secrets with ephemeral access.
What AWS Security Token Service Changes About AWS Access
AWS Security Token Service changes access from long-lived secrets to short-lived credentials that can be limited to a narrower set of permissions. That matters because the value of stolen access is reduced when credentials expire quickly and are issued only for the specific task, role, or session that needs them.
For AWS environments, the practical effect is not just shorter lifetime, but a different trust model. Instead of distributing static keys broadly, teams can issue temporary credentials on demand and attach the permissions needed for a specific use case, which helps contain blast radius when a credential is exposed.
Why Temporary Credentials Matter
Temporary credentials are important because credential theft is far less useful when the stolen material is time-limited and permission-scoped. In AWS, this is one of the main ways to reduce dependence on static access keys, especially for automation, federated access, and role-based use cases.
This is also why STS is often discussed alongside token exchange and delegation patterns. A temporary credential can represent a delegated action rather than a standing identity secret, which makes it better suited to workflows that need bounded authority instead of persistent access.
In practice, STS supports a security posture where the question is not “who has a permanent key?” but “who can obtain short-lived access, under what conditions, and for how long?” That shift is one of the strongest controls against secret reuse and overexposure.
How AWS STS Is Used in Real Workloads
STS is commonly used when workloads, humans, or external systems need to assume a role or obtain temporary access for a session. The temporary credential then carries a defined permission set, which can be narrower than the base identity that requested it.
That makes STS especially relevant in cross-account access, federated login, CI/CD automation, and workload-to-AWS authentication. Instead of embedding permanent secrets into scripts or pipelines, organisations can exchange an upstream trust decision for a short-lived AWS session.
The key design question is whether the session truly reflects the intended use case. If the role is too broad, or if sessions last too long, the protection benefit drops even though the credential is still temporary. Temporary access is only useful when the permissions and trust conditions are equally controlled.
Controls That Keep Temporary Access Safe
STS is strongest when paired with tight role trust policies, minimal permissions, and short session durations. It should also be supported by logging and review, because temporary access still needs to be traceable after issuance.
AWS STS and AssumeRole Guide explains the trust conditions, session tags, source identity, and revocation considerations that shape safe STS use.
Token Lifetime Policy Design Guide is useful for understanding how session duration, renewal patterns, and operational limits affect temporary access across people and workloads.
For broader AWS security context, the AWS Security Guide covers account structure, logging, and AWS-native security services that help make temporary access easier to govern and detect.
Failure Modes and Security Implications
STS does not remove risk, it changes it. If a role is overprivileged, a temporary credential can still provide too much access during its valid window. If session controls are weak, an attacker who steals the token may still move quickly enough to cause damage before expiry.
The security implication is that STS must be treated as a control over exposure, not as a complete defence. Temporary credentials reduce the usefulness of theft, but they do not prevent abuse of the permissions already granted, especially when trust policies, role scope, or session handling are too permissive.
Because STS is also part of delegation, weak trust boundaries can create confused-deputy style problems and unintended cross-account access. In other words, the danger is rarely the token format itself, but the authority it conveys and the conditions under which that authority is issued.
RFC 8693: OAuth 2.0 Token Exchange is a useful reference point for delegation semantics, on-behalf-of flows, and the general idea of exchanged authority being narrower than a standing secret.
RFC 9700: Best Current Practice for OAuth 2.0 Security reinforces the value of short-lived tokens, sender-constrained usage, and reducing the impact of token theft.
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, CIS Controls v8 and NIST CSF 2.0 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-bounded credentials that must be governed as authenticators. |
| IA-9 — Service Identification and Authentication | STS is widely used by services and workloads that authenticate with temporary credentials. | |
| AC-6 — Least Privilege | STS sessions should carry only the permissions needed for the requested task. | |
| Recommendation — Set short lifetimes, rotate trust material, and revoke temporary credentials quickly when risk changes. Use scoped temporary credentials for workload-to-workload access instead of static secrets. Constrain assumed roles to the minimum permissions required for each session. | ||
| CIS Controls v8 | CIS-5 — Account Management | STS is a core account and session access mechanism that replaces standing credentials. |
| CIS-8 — Audit Log Management | STS sessions need logging so issued access can be monitored and investigated. | |
| Recommendation — Manage temporary access paths centrally and remove standing keys where STS can be used. Centralize logs for STS issuance and use to support detection and post-incident review. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege Access | STS directly supports least-privilege access by narrowing permissions and lifetime. |
| DE.CM-01 — Monitoring for Unauthorized Events | STS activity should be monitored for anomalous role assumptions and misuse. | |
| Recommendation — Use temporary credentials to enforce least privilege for each AWS session. Monitor STS issuance and session activity for abnormal access patterns. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | STS is used to replace long-lived AWS secrets with short-lived credentials. |
| NHI-05 — Overprivileged NHI | STS sessions can still be over-scoped even when temporary, so privilege must be controlled. | |
| Recommendation — Prefer temporary credentials over static AWS keys wherever possible. Limit the permissions attached to each assumed role to the minimum needed. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org