ASD ISM 2144 Change application static credentials found compromised or exposed in clear
What it says
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.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishRotate the fixed passwords, keys and tokens that applications and workloads use whenever they are compromised, suspected compromised, or found stored or transmitted unencrypted.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the procedure that covers changing application and workload credentials, including what events require a change.
Look at
Check 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.
Good evidence
The procedure covers every trigger, assigns an owner and a timeframe, and requires the old credential to be revoked, not just a new one issued.
- Check 2 of 5What an auditor asks for
Ask for
Ask for recent incidents or tickets where an application credential was compromised or suspected of being compromised.
Look at
Look for evidence the credential was actually changed, when, and confirmation that the previous value was invalidated.
Good evidence
Every such incident shows a completed rotation close to the time of detection, with the old credential confirmed to no longer work.
- Check 3 of 5What an auditor asks for
Ask for
Ask for secrets scanning results or code review findings that identified credentials stored in the clear.
Look at
Trace a sample of findings to the follow-up action and check whether the credential was rotated and the cleartext copy removed.
Good evidence
Each finding links to a rotation record; none were closed simply by deleting the file while leaving the same credential in use.
- Check 4 of 5What an auditor asks for
Ask for
Ask for network monitoring alerts or reports that show credentials being sent unencrypted.
Look at
Check what happened after detection: whether the credential was changed and the connection moved to an encrypted path.
Good evidence
Detections lead to both a credential change and a transport fix, with dates and responsible people recorded.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the inventory or runbooks that describe where each application's static credentials are issued and consumed.
Look at
Confirm the information is complete enough to rotate a credential everywhere it is used without missing a copy.
Good evidence
Owners can show, for a sample application, every location the credential lives and demonstrate a past rotation that updated all of them.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.17.
ISM-2144 mandates rotating static credentials when compromise is suspected or when they are stored or transmitted in cleartext. ISO/IEC 27001:2022 Annex A 5.17 covers the broader management and allocation of authentication information. ISM-2144 would be a specific part of an Annex A 5.17 process.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.5.
ISM-2144 requires static credentials used by applications and workloads to be changed when they are compromised/suspected of being compromised, or found stored or transmitted in the clear. E8-RA-ML2.5 relates by requiring service account credentials to be long, unique, and managed, reducing exposure risk and supporting rotation practices. ISM-2144 is condition-triggered, while E8-RA-ML2.5 is a preventative measure.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.