ASD ISM 2141Prefer Short-Lived Dynamically Issued Credentials for Applications and Workloads
Applications and workloads should obtain temporary credentials on demand rather than relying on fixed keys or passwords that stay valid indefinitely.
Plain language
Applications and workloads (services, containers, scheduled jobs, CI pipelines) need credentials to talk to databases, cloud APIs and other systems. Traditionally these were long-lived static secrets: an API key pasted into a config file, a service account password that never changed, an access key baked into a container image. These secrets tend to leak. They end up in source repositories, logs, backups, chat messages and developer laptops, and because they never expire, a copy taken years ago can still work today. This control asks that, wherever possible, applications and workloads instead use short-lived credentials that are issued dynamically at the point of need. The workload proves its identity to an issuing service (for example a cloud identity platform, a secrets manager or a token service), receives a credential that is valid for minutes or hours, uses it, and then obtains a fresh one when it expires. Nothing durable needs to be stored, and anything that does leak stops working quickly on its own. It matters because credential theft is one of the most common ways attackers move from an initial foothold to sensitive data. Short-lived credentials shrink the window of opportunity from "indefinitely" to "until the token expires", and they remove the need for the manual rotation that organisations routinely fail to perform. The control is phrased as a preference: static credentials may still exist where a system cannot support dynamic issuance, but the default design choice should be short-lived and dynamic.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessSection
Credential managementTopic
Application and workload credentials
Official control statement
Applications and workloads use short-lived dynamically issued credentials in preference to long-lived static credentials.
Why it matters
If applications and workloads continue to rely on long-lived static credentials, any secret that leaks (through a code commit, a log file, a compromised build server or a departing contractor's laptop) remains a working key into the organisation's systems for as long as nobody notices and rotates it, which in practice can be years. Attackers who obtain such a credential can quietly access data, escalate privileges or move between systems without triggering any expiry, and revoking the credential often causes outages because nobody knows where else it is used. The organisation also carries the ongoing burden of tracking and manually rotating every static secret, a task that is routinely neglected. Reliance on static credentials where dynamic issuance is available is a gap against this control.
Operational notes
Day to day, this control lives in how new applications and workloads are onboarded and how existing ones are maintained. When a team needs a workload to access a resource, the default path should be to assign it an identity (a cloud role, a workload identity, a service principal, a Kubernetes service account) that can request a short-lived token, rather than to generate and hand over a static key. Platform and cloud teams should maintain the issuing infrastructure (identity providers, token services, secrets managers with dynamic secret engines) and treat its availability as critical, since workloads depend on it to keep running.
Operational teams should keep an inventory of any remaining long-lived static credentials, along with the reason each cannot yet be replaced and a target date or condition for retiring it. Token lifetimes should be set as short as the workload can tolerate, and applications must handle expiry and renewal gracefully so that a rotated or expired credential does not cause outages. Review the inventory of static secrets regularly, watch for new ones creeping in through code scanning or secrets detection, and include the preference for dynamic credentials in architecture and design reviews so it is applied before systems are built rather than retrofitted later.
Implementation tips
- Security architecture, with the platform team, sets a written standard that new applications and workloads must use short-lived dynamically issued credentials by default, and defines the exception process (with owner, justification and expiry) for any long-lived static credential that cannot be avoided.
- Cloud and platform engineers configure workload identity mechanisms (for example cloud instance or pod identities, federated identity for CI pipelines, and secrets-manager dynamic secret engines) so that applications can authenticate with their own identity and receive temporary credentials without any static secret being stored.
- Development teams update application code and deployment templates to request credentials at runtime from the identity or token service, set the shortest lifetime the workload can tolerate, and implement automatic renewal and retry logic so that expiry never causes an outage.
- The security team runs secrets scanning across repositories, container images, configuration stores and CI variables to locate existing long-lived static credentials, then works through the resulting inventory with system owners to migrate each one to dynamic issuance or record an approved exception.
- Platform owners restrict the ability to create long-lived static keys (for example by disabling user access-key creation for service identities or enforcing maximum token lifetimes in the identity provider) so that dynamic credentials become the only easy path for new workloads.
Audit / evidence tips
- AskAsk for the standard or design principle covering how applications and workloads obtain credentials.Look atCheck whether it states a clear preference for short-lived dynamically issued credentials over long-lived static ones, and how exceptions are handled.GoodA current, approved standard makes dynamic short-lived credentials the default for workloads and requires justified, time-bound exceptions for any static credential.
- AskAsk for a sample of recently deployed applications or workloads and how each authenticates to the resources it uses.Look atTrace where the credential comes from: is it requested at runtime from an identity provider, token service or secrets manager, or is it a fixed key stored in configuration?GoodThe sampled workloads authenticate using their own identity and receive temporary credentials at runtime, with no static secret stored in code, images or config.
- AskAsk to see the configuration of the credential-issuing services, such as the identity provider, workload identity federation or secrets manager.Look atReview the configured token or credential lifetimes and whether maximum lifetimes are enforced rather than left at permissive defaults.GoodCredential lifetimes are short (minutes to hours), enforced centrally, and consistent with what the standard requires.
- AskAsk for the inventory of remaining long-lived static credentials used by applications and workloads.Look atCheck that each entry has an owner, a reason dynamic issuance is not yet possible, and a plan or date for retirement, and compare the list against results from secrets scanning.GoodThe inventory is small, complete, actively managed, and shrinking over time, with scanning results matching what is recorded.
- AskAsk for evidence that static credentials are actively discouraged or blocked in the environment.Look atLook for controls such as disabled static key creation for service identities, secrets scanning in the pipeline, or architecture review checklists that flag static credentials.GoodTechnical and process controls make static credentials the exception, and reviewers can point to cases where a proposed static key was replaced with dynamic issuance.
Cross-framework mappings
How ISM-2141 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 5.17 | ISM-2141 requires applications and workloads to prefer short-lived, dynamically issued credentials over long-lived static secrets | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.