ISM-1402 asks that any credential kept on a system is protected in one of three ways: held in a password manager, held in a hardware security module, or, for passwords a database checks, salted, hashed and stretched before they are stored. A password in a spreadsheet, a script, a configuration file or a shared document meets none of them. ASD backs the control with a scan for credentials stored in the clear at least monthly (ISM-1875) and a rule that any found are changed (ISM-1590, ISM-2144).

#What does ISM-1402 require?

In plain English:

• Which credentials. Anything used to prove who or what is signing in: passwords and passphrases, and the secrets applications use, such as API keys and access tokens. ASD's credential management guidance applies to every kind of account, including "break glass accounts and service accounts", and to "interactive authentication and non-interactive authentication" alike.
• Stored on systems. Wherever a credential sits at rest: a laptop, server, file share, code repository, cloud storage or database.
• Three acceptable homes. A password manager, an encrypted vault that hands credentials to the people allowed to use them. A hardware security module, which ASD defines as "A physical computing device that safeguards cryptographic keys and provides cryptographic processing." Or, for a database, salting, hashing and stretching. ASD's guidance puts it in one sentence: "credentials can be stored in a password manager or hardware security module, while credentials stored in a database should be hashed, salted and stretched."
• All three steps, for the database option. A fast hash on its own does not meet it, and neither does encrypting passwords so they can be decrypted later.

One question sorts most cases: does anyone, or anything, need the credential back? If a person or an application has to use it again (a login for a supplier's portal, the password a scheduled task signs in with, an API key), it belongs in a password manager or a secrets vault, or in a hardware security module if it is a key. If a system only has to check it (your own application checking the password a customer types), store only a salted, stretched hash of it.

ISM-1402 applies at every classification ASD marks, from non-classified systems to TOP SECRET. It is not part of the Essential Eight, although some of its neighbours are: Credential Guard (ISM-1686), Remote Credential Guard (ISM-1897) and Local Security Authority protection (ISM-1861) sit at Maturity Level Three.

#Why does it matter?

Attackers look for stored credentials first. MITRE ATT&CK, the public catalogue of attacker techniques, describes how "Adversaries may search compromised systems to find and obtain insecurely stored credentials", in places from plain text files to chat messages, and notes that "Volt Typhoon has obtained credentials insecurely stored on targeted network appliances" (MITRE). A file of passwords on a share turns one compromised account into every account in the file.

Password files get stolen, and how they were stored decides what happens next. NIST explains that password hashing schemes exist "to make each password guess more expensive for an attacker who has obtained a hashed password file" (NIST). Account lockouts no longer help, because "Cracking hashes is usually done on adversary-controlled systems outside of the target network" (MITRE).

Each step closes a different gap, as the OWASP Password Storage Cheat Sheet explains:

• Hashing is a one-way scramble: the system keeps a fingerprint of the password and compares fingerprints at sign-in. Encryption is the wrong tool, because "attackers can retrieve the original plaintext from the encrypted data."
• Salting adds a random value, different for every password, so "an attacker has to crack hashes one at a time", and two people with the same password get different fingerprints.
• Stretching makes each hash deliberately slow to work out, which "reduces the speed and/or increases the cost for which an attacker can attempt to crack the password hash."

A key in a hardware security module cannot simply be copied. Of certification authority keys, ASD and its partners note that "If a HSM is used, the private key for CAs cannot be backed up and exfiltrated by malicious actors" (ASD).

#How does it fit with the other controls?

ISM-1402 says where credentials may live. The controls around it find the ones that live elsewhere:

• ISM-1875: a scan at least monthly for credentials stored in the clear. ASD lists where to look: "documents, configuration files, network file shares, software repositories, cloud storage or other data repositories."
• ISM-1590 and ISM-2144: credentials for user accounts, and static credentials used by applications and workloads, are changed if discovered stored in the clear. Moving a found password into a vault is not enough; assume it has been read.
• ISM-2142: application and workload credentials are centrally managed in "a credential or secrets management solution", the application world's password manager. ISM-2141 goes further and prefers short-lived credentials issued on demand.
• ISM-2030: code commits are scanned, and credentials, keys and secrets are blocked from the organisation's authoritative source code.
• ISM-1957: private keys for Microsoft AD CS certification authority servers are protected by a hardware security module. Here it is the only option, not one of three.
• ISM-1686 and ISM-1861: Credential Guard and Local Security Authority protection, for the credentials Windows itself holds while people are signed in. ASD pairs them with Remote Credential Guard (ISM-1897) and limiting cached credentials to one previous logon (ISM-1749) to "provide additional protection for credentials". Microsoft's Credential Guard overview explains what it isolates.

Our ISM-1685 guide covers the credentials of break glass, local administrator and service accounts.

#How do you meet ISM-1402?

1. Find where credentials are stored today. Ask each team, then search file shares, document libraries, code repositories, scripts, configuration files, wikis, tickets, chat and cloud storage. A spreadsheet of supplier logins counts as much as a server's configuration file.
2. Sort each one by the question above: read back, or only checked?
3. Give people an organisation-managed password manager, with multi-factor authentication on it and shared vaults for shared accounts. Decide what to do about passwords saved in web browsers. For Microsoft Edge, ASD's Blueprint for Secure Cloud says "Disable where a dedicated EPM solution is deployed" (an enterprise password manager) and "Permit where no alternative exists and the risk of unmanaged credential reuse outweighs the risk of browser-stored passwords" (ASD).
4. Move application and service credentials into a secrets vault (ISM-2142), read at run time instead of from files. Use short-lived credentials where the platform can issue them (ISM-2141), and scan commits so new ones are blocked (ISM-2030).
5. Put keys that must never leave into a hardware security module: certification authority private keys (ISM-1957) and the master keys that protect other secrets.
6. Store only salted, stretched hashes in applications that check passwords. ISM-1402 names no algorithm or work factor. OWASP's current advice is to "Use Argon2id with a minimum configuration of 19 MiB of memory, an iteration count of 2, and 1 degree of parallelism", or PBKDF2 with "a work factor of 600,000 or more" where FIPS-140 compliance is required (OWASP). NIST asks for a salt of "at least 32 bits" and a cost factor "as high as practical without negatively impacting verifier performance" (NIST).
7. Change every credential you found in the clear (ISM-1590, ISM-2144), then delete the copies, including old versions in document and code history where you can.
8. Scan at least monthly (ISM-1875) and follow each finding through to a changed credential.

#What evidence shows ISM-1402 is met?

#What gets in the way?

Habit. The passwords document on the shared drive, the spreadsheet of supplier logins, the note in a ticket. People keep them because they are quick, so the replacement must be just as quick: a password manager with shared vaults, in place before the old file goes.

Old applications and scripts. Some software can only read its password from a file. Restrict who can read it, record an exception with an owner, and replace the software when you can.

Software you did not write. You cannot see how a product stores the passwords it checks, so ask the vendor in writing which hashing scheme and work factor it uses. For cloud services, the provider holds what checks your people's passwords, which makes it a supplier assurance question; signing in through your own identity platform means fewer services hold a password at all.

The vault becomes the target. MITRE lists "password managers and cloud secrets vaults" among the places attackers search (MITRE). Protect the vault with multi-factor authentication, keep its administrators few, and watch its access logs.

Smaller and larger organisations. A smaller organisation can usually meet ISM-1402 with a business password manager, a one-page standard and a search of its file shares; it mostly buys software, so the hashing question goes to vendors, and its IT provider should say where it keeps the administrator credentials. A larger one has hundreds of applications, credentials spread across teams and clouds, and certification authorities that need hardware security modules, so the work becomes a programme with owners.

The business case. The costs are licences, a secrets vault, hardware security modules where keys need them, and the time to find and change exposed credentials. What it buys is that a stolen laptop, a copied file share or a leaked password database does not hand over everything else.

#What tools and skills help?

• A business password manager with shared vaults, multi-factor authentication and access logs. ASD's Blueprint notes that a dedicated one "offers centralised control and advanced security" (ASD).
• A secrets vault or privileged access management platform that stores, hands out and changes application and service credentials, and records who used them.
• A hardware security module, as an appliance or a cloud service. AWS describes one as "a computing device that processes cryptographic operations and provides secure storage for cryptographic keys" (AWS).
• The password hashing your development framework already has. OWASP notes that "a majority of modern languages and frameworks provide built-in functionality to help store passwords safely."
• Secret scanning for code repositories, file shares and cloud storage. GitHub, for example, says its secret scanning "scans your entire Git history on all branches of your repository for hardcoded credentials" (GitHub).
• Windows' own credential protection. Microsoft says Credential Guard "prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials" (Microsoft).
• Skills to find credentials, change them without breaking what uses them, and review how developers store passwords.

Which of your current licences already provide these? The free coverage check shows which ISM and Essential Eight controls the products you already pay for can reach, in about three minutes. To see ISM-1402 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-1402 is not new: ASD's catalogue records it at revision 6, last updated in March 2022. In the September 2026 release it moved, with the rest of the credential controls, from "Guidelines for system hardening › Authentication hardening" to "Guidelines for system access › Credential management", with its wording unchanged. The same release added ISM-2141 to ISM-2146 on application, workload and user account credentials, including ISM-2142's secrets management and ISM-2144's rule to change credentials found in the clear. ISM-2030's commit scanning "was amended to include credentials", and ISM-1875 and ISM-1590 were edited "without changing their intent" (ASD). Our ISM September 2026 summary covers the rest.

#Sources

• ASD, Information security manual: the credential management controls and guidance
• ASD, ISM September 2026 changes
• ASD, Blueprint for Secure Cloud: Microsoft Edge for Business
• ASD and partners, Detecting and mitigating Active Directory compromises
• NIST, SP 800-63B-4: password verifiers
• OWASP, Password Storage Cheat Sheet
• MITRE ATT&CK, T1552, T1110.002 and T1555
• Microsoft, Credential Guard overview; AWS, What is AWS CloudHSM?; GitHub, About secret scanning