ASD ISM 2144Change Application Static Credentials Found Compromised or Exposed in Clear
Rotate the fixed passwords, keys and tokens that applications and workloads use whenever they are compromised, suspected compromised, or found stored or transmitted unencrypted.
Plain language
Applications and workloads often rely on static credentials: fixed passwords, API keys, service account secrets and tokens that do not change on their own. This control says those credentials must be changed when any of three things happens: the credential is compromised or you suspect it has been, it is found sitting on a system in the clear (for example in a config file, script, log or source repository without encryption), or it is found travelling across a network in the clear (for example over unencrypted HTTP, FTP or an old database protocol). Why it matters: a static credential is only as safe as the last place it was seen. Once a secret has been exposed, you cannot know who copied it, and an attacker who holds it can quietly authenticate as the application for as long as the credential stays valid. Discovering the exposure is only half the job; the exposure is not closed until the credential itself is replaced and the old value stops working.
Framework
ASD Information Security Manual (ISM)
Control effect
Responsive
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 changed if: - they are compromised or suspected of being compromised - they are discovered stored on systems in the clear - they are discovered being transferred across networks in the clear.
Why it matters
If exposed or compromised application credentials are left unchanged, anyone who saw or captured them keeps working access to the systems, data and services those applications use, often without triggering alerts because the access looks legitimate. Fixing the storage or transport problem without rotating the credential leaves the attacker's copy fully valid, allowing persistent access, data theft or misuse of the workload's privileges long after the original weakness was corrected.
Operational notes
Day to day this control is a response step that sits behind other activities: incident response, secrets scanning, network monitoring and code review. Each of these can surface a trigger (a suspected compromise, a secret found in the clear at rest, or a secret seen in the clear in transit), and the operational task is to make sure every trigger leads to the credential actually being changed, not just the finding being logged.
Practical points to keep in view:
- Treat "suspected" compromise as sufficient. Waiting for proof leaves the credential live for longer.
- Rotation usually touches more than one place: the credential must be regenerated at the source (database, cloud provider, API), updated wherever the application reads it, and the old value revoked or confirmed invalid.
- Coordinate with application owners so rotation does not cause outages; a known change window is better than an unplanned one, but a compromised credential should not wait for convenience.
- After rotating, remove or overwrite the cleartext copy that caused the finding and fix the transport path so the new credential does not end up in the clear again.
- Keep a record of what was found, when the credential was changed and who confirmed the old value no longer works.
Implementation tips
- Security team: define in the incident response procedure that any confirmed or suspected compromise of an application or workload credential triggers mandatory rotation, with a named owner for each application secret and a target time to complete the change.
- Platform or DevOps engineers: run secrets scanning over source repositories, configuration files, scripts, container images and logs so that static credentials stored in the clear are found, and route every hit to the application owner as a rotation task.
- Network and security operations: use network monitoring or protocol inspection to detect credentials being sent in the clear (unencrypted HTTP, FTP, LDAP simple bind, plain database logins) and raise a ticket to rotate the affected credential and move the connection to an encrypted channel.
- Application owners: document a rotation runbook per application that lists where each static credential is issued, where it is consumed and how to revoke the old value, so rotation can be done quickly and completely when a trigger occurs.
- Security operations and application owners: after each rotation, verify that the old credential is rejected (test a login or API call with it), remove the cleartext copy or fix the unencrypted transport that caused the finding, and record the closure in the ticket.
Audit / evidence tips
- AskAsk for the procedure that covers changing application and workload credentials, including what events require a change.Look atCheck that it explicitly names all three triggers from the control: compromise or suspected compromise, discovery stored in the clear, and discovery transferred across a network in the clear.GoodThe procedure covers every trigger, assigns an owner and a timeframe, and requires the old credential to be revoked, not just a new one issued.
- AskAsk for recent incidents or tickets where an application credential was compromised or suspected of being compromised.Look atLook for evidence the credential was actually changed, when, and confirmation that the previous value was invalidated.GoodEvery such incident shows a completed rotation close to the time of detection, with the old credential confirmed to no longer work.
- AskAsk for secrets scanning results or code review findings that identified credentials stored in the clear.Look atTrace a sample of findings to the follow-up action and check whether the credential was rotated and the cleartext copy removed.GoodEach finding links to a rotation record; none were closed simply by deleting the file while leaving the same credential in use.
- AskAsk for network monitoring alerts or reports that show credentials being sent unencrypted.Look atCheck what happened after detection: whether the credential was changed and the connection moved to an encrypted path.GoodDetections lead to both a credential change and a transport fix, with dates and responsible people recorded.
- AskAsk for the inventory or runbooks that describe where each application's static credentials are issued and consumed.Look atConfirm the information is complete enough to rotate a credential everywhere it is used without missing a copy.GoodOwners can show, for a sample application, every location the credential lives and demonstrate a past rotation that updated all of them.
Cross-framework mappings
How ISM-2144 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-2144 mandates rotating static credentials when compromise is suspected or when they are stored or transmitted in cleartext | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| E8-RA-ML2.5 | ISM-2144 requires static credentials used by applications and workloads to be changed when they are compromised/suspected of being compro... | |
handshakeSupports(1)expand_less | ||
| E8-AC-ML2.7 | ISM-2144 requires changing static application/workload credentials when compromise is suspected or when they are stored or transferred in... | |
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.