When organizations used to build applications in the past (mostly on-prem, but also in the public cloud), a common practice for allowing services to authenticate between each other was to create a service account (sometimes referred to as an application account) and embed its credentials in code or configuration files.
Another common way to gain access to services was to use static credentials such as keys. For example – AWS IAM user access keys.
In this blog post, I will explain the risks related to using static credentials and provide recommendations when designing and building modern applications in the cloud.
Introduction to static credentials
Before we begin a conversation about static credentials, it is important to under why we need them in the first place.
Naturally, we don’t want to use a human (such as a developer, a DevOps or a DBA) credentials as part of code or configuration files to authenticate an application component (such as an API endpoint, or a front-end web application) to a backend service (such as a database, storage, message queue, etc.)
The most common practice for many years, which originated in on-prem legacy applications, was to create a service or application account and use it for non-interactive login.
Such identities are now known as NHI (or non-human identity), and since they were used as part of applications, and not as part of human/interactive login, they used to have static credentials (hopefully, long and complex passwords), and in most cases, their credentials were kept permanent and were never replaced (i.e., long-lived credentials).
Static credentials risks
Static credentials create persistent and often invisible weaknesses in cloud environments, offering attackers simple entry points while limiting an organization’s ability to detect misuse, enforce strong controls, or contain incidents effectively.
Below is a list of risks relating to the use of static credentials:
- High blast radius - Broad, persistent access makes any compromise immediately severe.
- Susceptibility to accidental exposure - Frequent real-world leaks through code repos, logs, and CI artifacts make this a major threat vector.
- Lack of automatic short-lived expiration - Keys remain valid long after they should not, enabling silent long-term abuse.
- Difficult rotation and poor key hygiene - Operational friction leads to rarely rotated, aging credentials that attackers can exploit for extended periods.
- No strong binding to workloads - Attackers can use stolen credentials from any location or infrastructure, increasing exploitability.
- Credential reuse across environments - Compromise of a single environment cascade laterally, expanding impact.
- Limited visibility and enforcement - Weak contextual signals hinder detection and prevent the application of strong access controls.
- Target for automated reconnaissance - Attackers routinely harvest exposed keys, though the actual impact depends on whether exposure occurs.
- Poor alignment with zero trust principles - Creates structural security gaps but typically manifests through other higher-ranked risks.
- Operational drag on incident response - Increases containment time but is a downstream effect rather than a primary threat.
Vault as an interim solution
In the past, organizations used to deploy solutions such as CyberArk Privileged Access Manager or BeyondTrust Password Safe.
As organizations began to embrace the public cloud, organizations began to use managed secrets managers such as AWS Secrets Manager or HashiCorp Vault (as a vendor-agnostic solution).
Although the mentioned solutions assisted in managing the entire lifecycle of static credentials (from generation, storage, retrieval and revocation), and the credentials weren’t as long as in the past, it still kept the problem of having static credentials.
The Long-term solution
The recommended solution is to avoid long-lived credentials when building modern applications in the cloud.
The alternative to using short-lived credentials depends on the use case.
General purpose
For most cloud workloads (such as compute, storage, database, messaging, integration, APIs, etc.), use a solution such as:
- AWS IAM Role - is a temporary permission identity that workloads or users can assume to access AWS resources without relying on long-lived credentials.
Managed Kubernetes
For allowing Pods within a managed Kubernetes environment access to cloud services, use a solution such as:
- AWS EKS Pod Identity - lets Kubernetes pods in an Amazon EKS cluster assume an IAM role and receive temporary credentials.
External (Federated) Identities
For scenarios that you need to grant access to external/federated identities through OIDC, temporary (or short-lived credentials) to resources in the cloud eco-system, use a solution such as:
- AWS Security Token Service (AWS STS) - issues short-lived, scoped credentials that external or federated identities obtain through the AssumeRole API, allowing them to access AWS resources temporarily without relying on long-lived access.
AI Agents
For scenarios that you need to grant access to AI agents, access to resources in the cloud eco-system, use a solution such as:
- Amazon Bedrock AgentCore Identity - Purpose-built IAM service for Bedrock agents with centralized agent identity directory, inbound authorizer (SigV4/OAuth/JWT), and outbound credential provider.
Summary
When managing non-human identities, always prefer temporary (roles/managed identities) over static or long-lived credentials.
If the target service does not support temporary credentials, use short-lived credentials and regularly rotate the credentials to avoid potential credential breaches.
Whatever you do, never store credentials as part of code, configuration files, Git repositories, etc.
This blog post focused on solutions offered by the hyper-scale cloud providers; naturally, there are commercial solutions offering similar functionalities, including a single pane of glass for managing non-human identities for the entire cloud environments, including multi-cloud environments.
Disclaimer: AI tools were used to research and edit this article. Graphics are created using AI.
About the author
Eyal Estrin is a seasoned cloud and information security architect, AWS Community Builder, and author of Cloud Security Handbook and Security for Cloud Native Applications. With over 25 years of experience in the IT industry, he brings deep expertise to his work.
Connect with Eyal on social media: https://linktr.ee/eyalestrin.
The opinions expressed here are his own and do not reflect those of his employer.
Top comments (0)