ASD ISM 1590 Changing user account credentials after compromise, exposure or shared membership change
What it says
Credentials for user accounts 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 - membership of a shared user account changes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishReset user account passwords and other credentials as soon as they are compromised, found in the clear on systems or networks, or when someone joins or leaves a shared account.
A credential (usually a password, but also a passphrase, key or token used to log in to a user account) only protects an account while it stays secret. This control lists four situations where that secrecy can no longer be relied on, and requires the credential to be changed in each one: - **Compromised or suspected compromise.** Someone outside the intended user may already know the credential, for example after a phishing incident, a malware infection, a leaked database or a report from a threat intelligence source. Suspicion is enough; you do not wait for proof. - **Found stored in the clear on a system.** If a credential turns up in a plain-text file, a script, a configuration file, a spreadsheet, source code or a ticket, anyone who can read that location can use it, and you cannot know who already has. - **Found being transferred across a network in the clear.** A credential sent over an unencrypted protocol, in an email, or in a chat message can be captured by anyone who can observe that traffic. - **Membership of a shared user account changes.** When a person leaves a group that uses a shared account, they still know the credential unless it is changed. Changing it keeps access limited to current members and preserves some accountability for who can use the account. Why it matters: attackers rarely need to break in when they can simply log in. A credential that has been exposed but not changed is an open door that stays open indefinitely, and the longer it stays open the more likely it is to be used.
Free. Save your status, tasks and notes.
Why it matters
If credentials are not changed after these events, anyone who obtained them (an attacker, a former team member, or a person who read the file or network capture) retains working access to the account for as long as the credential remains valid. This can lead to unauthorised access to systems and data, actions taken under a legitimate user's identity, and difficulty attributing activity on shared accounts. Because the exposure is often silent, the organisation may not realise the account is being used by someone else until damage has already occurred.
How to implement
The security or IT operations manager writes a credential reset procedure that names the four triggers in the control (compromise or suspected compromise, credentials found stored in the clear, credentials found transmitted in the clear, and shared account membership change) and states that the reset happens before or alongside any further investigation.
The service desk lead adds a 'credential compromise' request type to the ticketing system and gives service desk staff the rights and script to force a password change on a user account, so a report from a user, security tooling or a threat intelligence feed can be actioned immediately rather than escalated.
The security team schedules regular scans of file shares, source code repositories, configuration files and endpoints for credentials stored in plain text, and routes every hit to the owner of the affected account with a reset instruction and a request to remove the clear-text copy.
The network or security operations team configures monitoring to flag credentials sent over unencrypted protocols or in messages and email, and treats each detection as a trigger to reset the exposed credential and correct the transmission method.
Each shared account owner maintains a membership list for that account and, whenever a member leaves or joins, changes the credential and passes the new one only to current members through an approved secure channel, recording the change in the account's register.
Keep it running
Day to day, this control depends on two things: knowing when one of the four trigger events has happened, and having a quick, routine way to reset the affected credential.
- Treat each trigger as a standard incident or service request type so the reset is not improvised. Suspected compromise reports from users, security tooling alerts, findings from scans for clear-text credentials, network monitoring findings, and shared-account membership changes should all land in the same process.
- Make the reset the first action, not the last. Investigation can continue after the credential has been changed.
- For shared accounts, keep a current list of who has access so a membership change is visible and triggers a reset. Distribute the new credential only to remaining members through an approved channel.
- When a credential is found in the clear, also remove or protect the offending copy, otherwise the new credential may end up stored or sent the same way.
- Record what was changed, when, and why, so the pattern of triggers can be reviewed and repeat causes addressed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented procedure that describes when and how user account credentials are changed.
Look at
Check that it explicitly covers all four triggers: compromise or suspected compromise, credentials found stored in the clear, credentials found transmitted in the clear, and changes to shared account membership.
Good evidence
The procedure names each trigger, assigns responsibility for the reset, and does not make the reset conditional on confirming the compromise first.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a sample of incident or service desk tickets where a credential compromise was reported or suspected.
Look at
Compare the time the report was raised with the time the credential was actually changed in the directory or identity system.
Good evidence
Each ticket shows the credential was reset promptly after the report, with the reset visible in system logs, not just noted in the ticket.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the results of the most recent scans for credentials stored in the clear on systems, and the follow-up actions.
Look at
Trace a few findings through to the account owner being notified, the credential being changed, and the clear-text copy being removed.
Good evidence
Every finding has a matching credential change and remediation record, and repeat findings for the same credential do not occur.
- Check 4 of 5What an auditor asks for
Ask for
Ask how credentials sent across networks in the clear are detected, and for any recent detections.
Look at
Check that a detection led to a reset of the exposed credential and a change to how it was being transmitted.
Good evidence
Detections are treated as triggers in the same process as other compromises, with a reset recorded for each one.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the register of shared user accounts, including current membership and the history of credential changes.
Look at
Pick a few accounts where a member has left or joined and check whether the credential was changed at that time.
Good evidence
Each membership change lines up with a credential change, and the new credential was distributed only to current members through an approved channel.
Mappings
Closest match in ISO/IEC 27001: A.5.18, Managing access rights to information assets, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.18.
ISM-1590 requires changing credentials when compromise/exposure is suspected or confirmed, or when membership of a shared account changes. Annex A 5.18 covers provisioning, reviewing, modifying, and removing access rights in line with access control rules and policy. ISM-1590 fits within Annex A 5.18 as a specific modification action (credential reset) triggered by incident/exposure or shared-account lifecycle change, whereas Annex A 5.18 spans the full access-rights lifecycle beyond credentials.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.5.
ISM-1590 requires credentials to be changed when they are compromised/suspected compromised, exposed in the clear, or when shared account membership changes. E8-RA-ML2.5 requires administrator, service, and break glass account credentials to be long, unique, unpredictable and managed. They overlap in credential governance for high-value accounts, but ISM-1590 is primarily about rotation/reset on specific triggers, while E8-RA-ML2.5 is about credential strength and ongoing management irrespective of compromise events.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.