ASD ISM 2146Revoking Static Application and Workload Credentials When No Longer Required
Static credentials that applications and workloads use (API keys, service account passwords, tokens) are actively revoked as soon as the need for them ends.
Plain language
Applications and workloads often authenticate to other systems using static credentials: API keys, service account passwords, client secrets, access tokens and similar long-lived secrets that do not change on their own. This control requires that when such a credential is no longer needed, it is revoked, meaning it is disabled or deleted so it can no longer be used to authenticate. The need for a credential ends in many ways. An application is decommissioned, a workload is migrated to a different platform, an integration is retired, a credential is replaced during rotation, or a temporary project finishes. In every case the old credential should stop working. This matters because static credentials rarely expire by themselves. If they are simply forgotten rather than revoked, they remain valid indefinitely, often sitting in old configuration files, code repositories, build pipelines, backups or a former developer's notes. Nobody is watching them because the thing they belonged to no longer exists, yet an attacker who finds one can use it to reach whatever systems it still grants access to. Orphaned credentials are a common and quiet way into an environment, and revoking them promptly closes that door.
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
Official control statement
Static credentials used by applications and workloads are revoked when they are no longer required.
Why it matters
If static credentials for applications and workloads are not revoked when no longer required, valid secrets accumulate that nobody owns or monitors. An attacker who recovers one from a leaked repository, an old backup, a decommissioned server or a compromised developer workstation can authenticate as a trusted application and access data or services undetected, because the credential still looks legitimate. Because orphaned credentials are not tied to any active system, the misuse is unlikely to be noticed quickly, and the organisation may be unable to say what the credential could reach. This turns a routine decommissioning oversight into a long-lived, unmonitored path for data theft, lateral movement and abuse of connected services.
Operational notes
Day to day, this control lives inside the change, decommissioning and credential rotation processes rather than as a stand-alone task.
- Every static credential issued to an application or workload should have a known owner and a record of what it is for, so that "no longer required" can actually be determined.
- Decommissioning an application, retiring an integration, migrating a workload, or completing a project should include an explicit step to revoke the credentials that the application or workload used, not just switch the system off.
- When a credential is rotated or replaced, the superseded credential is revoked once the new one is confirmed working, rather than left active "just in case".
- Revocation should be done at the source of truth (the identity provider, cloud platform, secrets manager, database or API service that issued the credential), so the credential stops working everywhere, not just in one configuration file.
- Periodic reviews of application and workload credentials help catch cases where the triggering event was missed, for example a system decommissioned without a change record.
- Each revocation should be recorded (what was revoked, when, by whom and why) so the organisation can demonstrate the control and investigate if a revoked credential is later seen in use.
Implementation tips
- The security or platform team maintains an inventory of static credentials used by applications and workloads (API keys, service account passwords, client secrets, tokens), recording for each one the owning application, the issuing system and a named owner, so that every credential can be traced to a need.
- Application owners add a mandatory credential-revocation step to the decommissioning and change checklists, so that retiring an application, integration or workload cannot be marked complete until the credentials it used have been revoked at the issuing system and the ticket records this.
- Platform engineers revoke credentials at the source of truth (identity provider, cloud IAM, secrets manager, database or the third-party service that issued them) rather than only deleting them from configuration, and verify afterwards that authentication with the old credential fails.
- The team that performs credential rotation revokes the superseded credential once the replacement is confirmed working, using the secrets manager or platform tooling to disable the old value rather than leaving both active.
- The security team schedules a periodic review (for example quarterly) that compares the credential inventory against currently running applications and workloads, and revokes any credential whose owning system no longer exists or whose owner confirms it is no longer needed.
Audit / evidence tips
- AskAsk for the inventory or register of static credentials used by applications and workloads.Look atCheck whether each credential is linked to a specific application or workload, an issuing system and a named owner, and whether the register is kept current.GoodEvery application and workload credential is listed with an owner and purpose, so the organisation can tell when a credential is no longer required.
- AskAsk for the decommissioning or change procedure used when applications, integrations or workloads are retired or migrated.Look atLook for an explicit step that requires the application's static credentials to be revoked, and for evidence that the step is completed in recent tickets.GoodRecent decommissioning records show credentials were revoked at the issuing system, with the date and the person who did it.
- AskAsk for a sample of applications or workloads decommissioned in the last twelve months.Look atTrace each one to its credentials and confirm in the identity provider, cloud platform, secrets manager or service console that those credentials are disabled or deleted.GoodNone of the sampled credentials remain active, and the revocation dates align closely with the decommissioning dates.
- AskAsk how credential rotation is handled for applications and workloads.Look atCheck whether superseded credentials are revoked after the replacement is confirmed, or whether old values remain valid alongside new ones.GoodRotation records and platform settings show the previous credential is disabled once the new one is in use, with no long-lived overlap.
- AskAsk for the most recent periodic review of application and workload credentials.Look atLook for a comparison of active credentials against currently running applications, and for revocations that resulted from the review.GoodThe review identifies orphaned or unneeded credentials and shows they were revoked, with follow-up recorded for any exceptions.
Cross-framework mappings
How ISM-2146 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 5.17 | ISM-2146 requires static credentials used by applications and workloads (e.g | |
| Annex A 5.18 | ISM-2146 requires organisations to promptly revoke static application/workload credentials when they are no longer needed | |
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.16 | ISM-2146 requires static credentials used by applications and workloads to be revoked when no longer required | |
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.