Application Default Credentials is a Google authentication framework that lets software obtain credentials from the environment instead of hard-coding them. It supports multiple methods, including service account keys and workload identity, which makes it useful for cloud workloads that need to authenticate to Google services from Kubernetes or other runtime environments.
How Application Default Credentials work
Application Default Credentials, or ADC, is a runtime credential discovery pattern. Instead of embedding a secret in code, the application looks for credentials in the environment it is running in and uses the first supported source it finds.
That design matters because the authentication boundary moves from the source repository to the execution environment. In practice, ADC can resolve to a locally configured developer identity, a cloud metadata-based identity, a service account key, or a workload identity binding, depending on where the software runs.
The important security idea is that ADC is not itself a single credential type. It is a selection mechanism that chooses how the application will authenticate, which means the control quality depends heavily on the environment, the runtime configuration, and the strength of the underlying credential source.
Where ADC is used in cloud applications
ADC is most useful when the same application must run in different places, such as a laptop, a CI/CD job, a container, or a Kubernetes cluster. The code can stay the same while the credential source changes with the runtime context.
That flexibility is one reason ADC is common in Google Cloud workloads, especially for services that need to call Google APIs without manual login prompts. It also explains why ADC often appears alongside workload identity patterns and service account based access, because the application still needs a trustworthy non-interactive identity behind the scenes.
For practitioners, the benefit is portability, but the trade-off is opacity. If teams do not know which ADC source a workload is actually using, they may assume it is protected by one mechanism when it is really falling back to a weaker or longer-lived one. That is why ADC should be understood as part of the deployment and identity design, not just as an application developer convenience.
Security implications of credential source selection
The main security value of ADC is that it can reduce hard-coded secrets in source code and configuration. When used well, it supports shorter-lived, environment-bound authentication instead of distributing static keys across teams and systems.
But ADC can also hide risk if the fallback order is not controlled. A workload may silently use a locally available key, a default environment credential, or an overly permissive service account when the intended workload identity binding is missing. In that case, the application still works, but it may be operating with unnecessary standing privilege or with credentials that are harder to rotate and audit.
Because the credential source is selected at runtime, ADC should be treated as an exposure point for secrets handling, privilege scope, and deployment drift. The more environments an application can run in, the more important it becomes to verify which identity source each environment actually supplies.
Common implementation patterns and failure modes
ADC typically shows up in two broad patterns: developer or local credentials used during testing, and runtime workload credentials used in production. Both can be valid, but they should not be conflated, because the operational assumptions are different.
The most common failure mode is credential sprawl, where teams keep service account keys as a convenience even after workload identity is available. Another failure mode is misconfiguration, where an application inherits broader permissions than it needs because the selected credential source belongs to a shared account or a default project identity. NHIMG’s guide section on static vs dynamic secrets is a useful reference point for why long-lived credentials create more residual risk than ephemeral ones.
ADC also becomes harder to govern when it is treated as a universal default rather than a deliberate choice. A healthy implementation distinguishes development, test, and production identities, and it makes the selected credential source visible enough that operators can tell when the runtime has drifted from the intended authentication path.
Risk and Threat Considerations
ADC can reduce secret exposure, but it can also concentrate trust in whichever credential source the runtime discovers first. If that source is a hard-coded key, a shared service account, or an overprivileged default identity, the application may authenticate successfully while quietly expanding the blast radius of compromise.
Failure mechanism: Attackers or misconfigurations exploit the fallback behaviour, exposed key material, or excessive permissions attached to the selected runtime identity. When ADC resolves to a weaker source than the team expects, compromise of the environment can become compromise of the application’s API access.
Impact: The result can be unauthorized access to Google services, privilege escalation across cloud resources, harder incident containment, and slower revocation because the true credential source was never tightly controlled or inventoried.
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 address the attack and risk surface, while CIS Controls v8, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Sprawl and Credential Lifecycle | ADC choices shape whether workloads use static keys or short-lived runtime credentials. |
| NHI-03 — Overprivileged Non-Human Identities | ADC often resolves to service accounts or workload identities whose permissions define exposure. | |
| Recommendation — Prefer short-lived workload credentials and eliminate fallback to static keys where ADC is used. Scope the selected ADC-backed identity to least privilege and review its permissions regularly. | ||
| CIS Controls v8 | 6 — Access Control Management | ADC is an access path, so control over account and privilege assignment directly affects exposure. |
| Recommendation — Remove unnecessary access paths and ensure ADC-backed accounts are provisioned with minimal privilege. | ||
| NIST Zero Trust (SP 800-207) | 3 — Zero Trust Principles | ADC depends on continuously trusted runtime credentials, which aligns with zero-trust verification of access. |
| Recommendation — Verify runtime identity and bind ADC usage to explicit trust decisions rather than implicit network trust. | ||
| NIST CSF 2.0 | PR.AC — Access Control | ADC is fundamentally an authentication and authorization mechanism for application access. |
| PR.PT — Protective Technology | ADC implementation affects how credentials are stored, discovered and protected at runtime. | |
| Recommendation — Enforce access controls that bind ADC to approved identities, environments and resource scopes. Use protective runtime mechanisms that prevent hard-coded or exposed credentials from being selected by ADC. | ||
| NIST SP 800-63 | AAL2 — Authentication Assurance Level 2 | ADC relies on the strength of the underlying authentication method chosen for the workload. |
| Recommendation — Use an authentication method for ADC-backed workloads that matches the required assurance level. | ||
Practitioner Guidance
Why practitioners should care: ADC is convenient only when the credential source is predictable. If teams cannot explain which identity ADC will use in each environment, they cannot reliably reason about access scope, rotation, or incident response.
Common misunderstanding: Teams often assume that “using ADC” automatically means a workload is using the safest available identity. In practice, the security outcome depends on which underlying source is present, whether fallback paths are allowed, and how tightly the selected identity is scoped.
Related resources from NHI Mgmt Group
- Should teams treat AI-related credentials differently from ordinary application secrets?
- What breaks when default credentials exist on an AI workflow account?
- Why do default credentials remain dangerous in operational technology?
- Why do default credentials and standing privilege create PCI DSS risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
