ISM-2141: Short-Lived Credentials for Workloads

ISM-2141 says that when software signs in to other systems by itself, it should use credentials that are issued on demand and expire quickly, in preference to passwords, API keys and access keys that work until someone changes them. Where a fixed credential cannot be avoided, the controls beside it keep it in a secrets management solution (ISM-2142), unique to one application and environment (ISM-2143), changed when it leaks (ISM-2144) and revoked when nothing needs it (ISM-2146). All five are new in the September 2026 Information Security Manual.

#What does ISM-2141 require?

In plain English:

• Applications and workloads. Software that signs in without a person at the keyboard: a web application reading its database, a scheduled job copying files to cloud storage, a build pipeline deploying code, an integration between two cloud services. In ASD's words, they "may require credentials to authenticate to systems, services and data repositories without direct human involvement."
• Long-lived static credentials. A password, API key, access key, client secret or certificate that is set once and keeps working until someone changes it. It usually sits in a configuration file or a pipeline's settings, and anyone who copies it can use it from anywhere.
• Short-lived dynamically issued credentials. The platform the software runs on vouches for it and hands it a credential on request, which expires after minutes or hours and is renewed automatically. Nobody types it, stores it or has to remember to change it.
• "In preference to". Our reading: short-lived credentials are the default for anything new and anything that can be moved, and a static credential stays only where the system at the other end accepts nothing else. ASD's guidance expects some to remain ("Where static credentials are required"), and ISM-2142 to ISM-2146 cover those.

ASD sets no maximum lifetime. Our reading: minutes or hours, not months, so a copy stolen today is useless tomorrow. GitHub's tokens for build pipelines, for example, are "only valid for a single job" (GitHub).

ASD's credential management guidance applies to every kind of account, "service accounts" included, and to "non-interactive authentication". ISM-2141 applies at every classification ASD marks, from non-classified systems to TOP SECRET, and is not part of the Essential Eight.

#Why are long-lived credentials a problem?

ASD gives the reason beside the control: "Where such credentials are long-lived or reused by multiple applications, workloads or operating environments, their compromise can provide malicious actors with persistent access to systems and increase the extent of a compromise." Two public cases show how.

Static secrets get copied. In March 2025 a third-party step for GitHub build pipelines, tj-actions/changed-files, was compromised. CISA reported that the compromise "allows for information disclosure of secrets including, but not limited to, valid access keys, GitHub Personal Access Tokens (PATs), npm tokens, and private RSA keys", which attackers could find by reading the pipelines' logs, and advised: "Rotate all identified secrets immediately as they should be considered compromised" (CISA). A long-lived key printed in a log works for whoever finds it until it is changed; a token that expired with the job is worth little by the time anyone reads the log.

Static secrets get forgotten. Cloudflare reported that on 23 November 2023 it found an attacker on its self-hosted Atlassian server, who had got in "by using one access token and three service account credentials that had been taken, and that we failed to rotate, after the Okta compromise of October 2023". They "were not rotated because mistakenly it was believed they were unused", and Cloudflare went on to rotate "every production credential (more than 5,000 individual credentials)" (Cloudflare). Every static credential is one more to find and change after an incident, and the forgotten ones are the ones that get used.

#How does it fit with the other controls?

The controls around ISM-2141 handle the static credentials that remain:

• ISM-2142: they are centrally managed in "a credential or secrets management solution", which ASD says "can assist with their secure storage, access control and lifecycle management". Our ISM-1402 guide covers where stored credentials may live.
• ISM-2143: each application has its own, not shared with others or across "development, testing, staging and production environments". A production key copied into a test system is only as safe as the test system.
• ISM-2144: a static credential is changed if it is compromised or suspected of being compromised, or found stored or sent across a network in the clear. The monthly scan for credentials in the clear (ISM-1875) finds most of them.
• ISM-2146: a static credential is revoked when it is no longer required, including for applications "that have been decommissioned". Cloudflare's case shows why that needs a list and a test, not a belief.
• ISM-1619: Windows service accounts are created as group Managed Service Accounts, which ASD says "do not require manual credential management by system administrators". Our reading: not short-lived in the ISM-2141 sense, but it takes the static password out of people's hands for Windows services on premises. Our ISM-1685 guide covers service accounts.

AI agents that call other systems are workloads too (see our ISM-2156 guide).

#What replaces static credentials?

Most platforms now let software prove what it is and receive a credential that expires. The option depends on where the software runs:

• Inside a cloud platform. The platform gives the resource an identity and hands it credentials automatically. Microsoft says its managed identities "eliminate the need for developers to manage these credentials" and "Credentials aren't even accessible to you" (Microsoft). AWS's advice is to "Require workloads to use temporary credentials with IAM roles to access AWS" (AWS).
• From a build pipeline or another cloud. Workload identity federation lets one platform vouch for software to another, so no key is copied between them. GitHub says pipelines can "exchange short-lived tokens directly from your cloud provider", so "You won't need to duplicate your cloud credentials as long-lived GitHub secrets" (GitHub). Google says its version "eliminates the maintenance and security burden associated with service account keys" (Google).
• For databases and older systems. A secrets management solution can create a login when the application asks and remove it when the lease ends. HashiCorp, for example, describes one that "generates database credentials dynamically based on configured roles", so services "no longer need to hardcode credentials" (HashiCorp).
• Between your own services. Certificates issued for hours and renewed automatically can identify one service to another; the open SPIFFE standard centres on "short lived cryptographic identity documents" (SPIFFE).

Where none of these is possible, the credential stays static under ISM-2142 to ISM-2146.

#How do you meet ISM-2141?

1. List every credential software uses: application settings, pipeline secrets, cloud access keys and client secrets, API keys for integrations, database logins, scripts, certificates. For each, record what it reaches, its owner, where it is stored, and when it was last changed and last used.
2. Ask of each: can the platform issue a short-lived credential instead? Cloud resources reaching cloud services, pipelines deploying to a cloud, and applications reaching a database usually can.
3. Start with the riskiest: broad access, production, credentials stored in pipelines or code, and any shared between applications or environments.
4. Move each to the platform's own identity, test it, then delete the old credential (ISM-2146). A key nobody uses that still works is still a key.
5. Block new long-lived keys where the platform has a policy for it, with a recorded exception for any that must exist.
6. Vault the static credentials that remain (ISM-2142), one per application and environment (ISM-2143), each with an owner and a review date, changed automatically where the vault can.
7. Scan and act: systems at least monthly for credentials in the clear (ISM-1875), code before it is accepted (ISM-2030), and change whatever turns up (ISM-2144).
8. Record the exceptions: which systems still need a static credential, why, who owns it and when it will be looked at again.

#What evidence shows ISM-2141 is met?

Ask	Look at	Good looks like
Which applications and workloads sign in to other systems?	The inventory of non-human credentials	Every credential listed with owner, purpose, type, location and last use
Do cloud workloads use the platform's own identity?	Cloud identity settings; the list of access keys and client secrets	Managed identities or roles in use; few long-lived keys, each with a recorded exception
Do build pipelines hold cloud secrets?	Pipeline secrets and variables	Deployments use short-lived tokens through federation; no stored cloud keys
How long do issued credentials last?	Token, certificate and lease settings	Minutes or hours, renewed automatically
Where do the remaining static credentials live?	The secrets management solution (ISM-2142)	All of them there; none in code, configuration files or pipeline settings
Are any shared?	Credentials per application and environment (ISM-2143)	One each; no production credential in test
What happens when one leaks or is no longer needed?	Change and revocation records (ISM-2144, ISM-2146)	Changed promptly after each finding; revoked when an application is retired

#What gets in the way?

Software that only accepts a password or key. Older applications, network appliances and many cloud service APIs take only a fixed key, and AWS itself lists cases that still need long-term keys, such as "WordPress plugins" (AWS). Keep those under ISM-2142 to ISM-2146, record the exception, and ask the supplier about short-lived options at each renewal.

Fear of breaking production. Changing a static credential by hand is where outages happen. Cloudflare reported that on 21 March 2025, while rotating a service's credentials, its team "inadvertently deployed the new credentials (ID and key pair) to a development instance of the service instead of production", and services saw errors for "1 hour and 7 minutes" (Cloudflare). Short-lived credentials remove that manual step. For static ones, automate the change and confirm the new credential is in use before removing the old, as Cloudflare now requires.

Nobody knows what is out there. Keys made by former staff, contractors and integrators for projects long finished, and new ones made because setup guides often start with a pasted key. The inventory is most of the work, and ISM-2146 needs it too.

Smaller and larger organisations. A smaller organisation usually has a handful of integrations between cloud services: apps registered in its identity platform with a client secret, the backup service, the website's deployment, the accounting system's connections. Its IT provider and suppliers can say which use fixed keys, and the platforms' own identity features are often part of what it already pays for. A larger one has hundreds of applications across several clouds, container platforms and pipelines, and needs a platform team, one standard way for workloads to prove their identity, policies that block new long-lived keys, and owners for every exception.

The business case. The costs are engineering time to change how software signs in and, for some, a secrets management licence. What it buys is fewer secrets to steal, fewer to change after a leak, and a smaller clean-up: Cloudflare's response to four missed credentials was to rotate more than 5,000.

#What tools and skills help?

• The cloud platform's built-in workload identities and federation, as Microsoft, AWS, Google and, for build pipelines, GitHub document.
• A secrets management solution that stores the static credentials that remain, controls and logs access, changes them on a schedule and, for some systems such as databases, issues credentials on demand.
• A certificate service that issues short-lived certificates to services and renews them automatically.
• Secret scanning for code, pipelines, file shares and cloud storage (ISM-1875, ISM-2030), so leaked keys are found and changed.
• Skills: someone who understands how each platform proves a workload's identity, can read a cloud permission policy, and can change a credential without an outage.

Which of the products you already pay for help here? The free coverage check shows which ISM and Essential Eight controls your current products can reach, in about three minutes. To see ISM-2141 among the other credential controls, open it in our sample coverage report, or read what an ISM assessment involves.

#What changed in recent ISM releases?

ISM-2141 is new: ASD added it in the September 2026 release, at revision 0, with ISM-2142 and ISM-2143, the three controls in the new subsection "Application and workload credentials" of the system access guidelines (ASD). The same release added ISM-2144 under "Changing credentials" and ISM-2145 and ISM-2146 under "Revoking credentials", and moved the existing credential controls, ISM-1619 among them, into the new credential management section. Our ISM September 2026 summary covers the rest.

#Sources

• ASD, Information security manual: the credential management controls and guidance quoted on this page
• ASD, ISM September 2026 changes
• CISA, Supply chain compromise of third-party tj-actions/changed-files (March 2025)
• Cloudflare, Thanksgiving 2023 security incident and Cloudflare incident on March 21, 2025
• GitHub, OpenID Connect; Microsoft, Managed identities for Azure resources; AWS, Security best practices in IAM; Google Cloud, Workload Identity Federation
• HashiCorp, Database secrets engine; SPIFFE, SPIFFE overview