ASD ISM 1594 Delivering user credentials via secure channel or split parts
What it says
Credentials for human users are provided via a secure communications channel or, if not possible, split into two parts with one part provided to the human user and the other part provided to their supervisor.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishHand new or reset credentials to people over a secure channel, or split them in two and give one half to the user and the other half to their supervisor.
Every time someone is issued a password, passphrase, PIN, token or other credential, that credential has to travel from whoever created it to the person who will use it. This control is about that hand-over moment. The preferred method is a secure communications channel, meaning one where the credential cannot be read or captured by anyone other than the intended person while it is in transit. If no secure channel is available, the fallback is to split the credential into two parts: one part goes to the user and the other part goes to their supervisor, so the two people must combine their halves before the credential can be used. Why it matters: a credential sent in plain text (an unencrypted email, a chat message, a note left on a desk, a phone call overheard in an open office) can be intercepted and used by an attacker before the legitimate user has even logged in. Initial and reset credentials are a favourite target because they are often distributed in predictable ways and are frequently still valid when they are stolen. Splitting the credential means that anyone who captures a single message only has half the secret, which is useless on its own, and it also creates a second person who knows the credential was issued and can notice if something looks wrong.
Free. Save your status, tasks and notes.
Why it matters
If credentials are handed out over insecure channels, anyone who can read the message, mailbox, chat history or paper note gets a working login for that user. This can lead to account takeover, unauthorised access to systems and data, and activity that appears to be performed by the legitimate user, making the intrusion hard to detect and attribute. Without the split-part fallback, a single intercepted message is enough to compromise the account.
How to implement
The identity or service desk lead should document a credential delivery procedure that names the approved secure communications channel(s) for issuing credentials to human users, and states plainly that this is the default for onboarding, resets and re-issues.
System administrators should configure the standard secure channel into the tooling used to create and reset accounts, so that the credential is delivered through that channel automatically rather than being copied into email or chat by hand.
The service desk lead should write the fallback procedure for cases where no secure channel is possible: how the credential is split into two parts, how each part is sent, and that one part goes to the user and the other to their supervisor.
People managers and HR should keep an accurate record of each user's supervisor in the identity or HR system, so that service desk staff can identify the correct recipient of the second credential part without guessing.
The security team should train service desk and administration staff on both methods, and require them to record which method was used for each credential issuance so that use of the fallback can be reviewed.
Keep it running
In day-to-day operation this control lives inside onboarding, password-reset and privileged-account issuance processes. The service desk and system administrators need a clearly defined default secure channel (for example an in-person hand-over, an encrypted delivery mechanism or a channel the organisation has assessed as secure) and a documented decision rule for when that channel cannot be used, such as a remote worker with no encrypted route yet established. When the fallback is triggered, staff need to know how to divide the credential, how to send each part, and who the user's supervisor is for that purpose. Keep the practice consistent across all human user credentials, not just first-day passwords, so that resets and re-issues follow the same path. Because the control depends on people following a procedure at a busy moment, it helps to build the secure channel into the tooling (so that the easy path is the compliant one) and to record which method was used for each issuance so that exceptions can be reviewed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented procedure that describes how credentials are delivered to human users.
Look at
Check that it names a secure communications channel as the default and describes the split-part fallback with one part to the user and one part to the supervisor.
Good evidence
A current, approved procedure covers both delivery methods and the conditions under which the fallback applies.
- Check 2 of 5What an auditor asks for
Ask for
Ask to be walked through a recent new-user onboarding and a recent password reset.
Look at
Trace how the credential physically or electronically reached the user and whether the channel used matches the documented secure channel.
Good evidence
Credentials in the sampled cases were delivered through the approved secure channel with no plain-text copies in email, chat or tickets.
- Check 3 of 5What an auditor asks for
Ask for
Ask for examples where the secure channel could not be used and the split-part method was applied.
Look at
Confirm the credential was divided into two parts, that the parts went to the user and to their supervisor, and that neither part alone was the full credential.
Good evidence
Records show the split was performed correctly and the supervisor recipient matches the user's recorded supervisor.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the service desk identifies a user's supervisor when the fallback is needed.
Look at
Look at the identity or HR data source used and whether it is kept current.
Good evidence
Supervisor details are drawn from a maintained system rather than ad hoc knowledge, so the second part reliably reaches the right person.
- Check 5 of 5What an auditor asks for
Ask for
Ask how staff who issue credentials are trained on this procedure and whether issuance records capture the delivery method.
Look at
Review training records and a sample of issuance logs or tickets for a delivery-method field.
Good evidence
Relevant staff have completed training, and each issuance records which method was used, enabling review of exceptions.
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-1594 requires that initial or reset human user credentials are delivered via a secure communications channel, or otherwise split and issued via two separate paths (user and supervisor). ISO/IEC 27001:2022 Annex A 5.17 requires an organisational process to control the allocation and management of authentication information, including guidance to personnel on handling it. ISM-1594 is a specific, prescriptive delivery/issuance safeguard that sits within (and operationalises part of) the broader authentication-information management process required by Annex A 5.17.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.