ASD ISM 1593 Verify user identity before issuing, resetting, disabling or enrolling credentials
What it says
Human users provide sufficient evidence to verify their identity when first requesting credentials, when requesting the reset of any credentials, when requesting the temporary disabling of any credentials, and when requesting the enrolment or re-enrolment of any credentials.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishBefore anyone gets new credentials, a reset, a temporary disable, or an enrolment, they must first prove they are who they claim to be.
Credentials (passwords, passphrases, tokens, authenticator apps and similar) are the keys to your systems. This control says that whenever a human user asks for something to be done with those keys, they must first give enough evidence to prove their identity. The statement names four moments where this applies: when a person first requests credentials, when they ask for any credential to be reset, when they ask for any credential to be temporarily disabled, and when they ask to enrol or re-enrol any credential (for example, registering a new phone or hardware token as an authenticator). It matters because these request points are where attackers go when they cannot break the credential itself. A phone call to the service desk saying "I'm locked out, can you reset my password" or "I have a new phone, can you set up my authenticator again" is far easier than cracking a strong passphrase or defeating multi-factor authentication. Temporary disabling is included because switching off a credential can also be abused, for example to lock a legitimate user out or to weaken a login step before an attack. If identity is not properly checked at each of these moments, the strength of the credential itself becomes irrelevant.
Free. Save your status, tasks and notes.
Why it matters
Without identity verification at these points, an attacker can obtain, reset or re-enrol another person's credentials simply by asking, gaining access to systems and data as that person. Multi-factor authentication can be sidestepped by enrolling an attacker-controlled device, and legitimate users can be locked out through fraudulent disable requests. The result is account takeover, unauthorised access to information, and disruption of business, often without any sign of a technical compromise.
How to implement
Identity or security management defines, in a written procedure, what counts as sufficient evidence of identity for each of the four request types (first issue, reset, temporary disable, enrolment or re-enrolment) and publishes it to everyone who handles those requests.
The service desk lead builds the verification step into every credential request workflow, including the ticketing template and call script, so that a technician must record the evidence checked before the reset, disable or enrolment action is available to them.
The identity platform administrator configures self-service password reset and authenticator enrolment portals so that a user must complete an identity check before the reset or enrolment proceeds, rather than allowing it on a username alone.
HR and the identity team agree a process for first-time credential issue in which new starters receive credentials only after their identity has been confirmed, for example through the onboarding identity checks, and the confirmation is recorded against the request.
The security team trains service desk and identity staff on the procedure, including how to handle urgent or senior requests and what to do when a requester cannot provide sufficient evidence, and repeats the training when the procedure changes.
Keep it running
Day to day, this control lives in the service desk and in any self-service identity portal. Every request that touches credentials, whether for a new starter, a forgotten password, a lost or replaced authenticator, or a request to temporarily switch a credential off, should follow the same rule: verify first, act second. Staff handling these requests need a clear, documented procedure that tells them what evidence is sufficient for each type of request and what to do when a requester cannot provide it.
Watch for pressure and shortcuts. Requests framed as urgent, coming from senior people, or arriving late in the day are where verification tends to be skipped. Make sure the procedure covers all channels (phone, email, chat, walk-up and self-service) so that a requester cannot simply pick the channel with the weakest check. Keep a record of each request and the verification performed so that the process can be reviewed and any suspicious pattern of requests investigated.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request the documented procedure for handling credential requests from human users.
Look at
Check that it covers all four request types named in the control: first issue, reset, temporary disable, and enrolment or re-enrolment, and that it states what evidence of identity is required for each.
Good evidence
A current, approved procedure that explicitly addresses each request type and defines sufficient evidence, with no request type left to the technician's discretion.
- Check 2 of 5What an auditor asks for
Ask for
Request a sample of recent service desk tickets for password resets and authenticator re-enrolments.
Look at
Look for a recorded identity verification step in each ticket, showing what evidence was checked and by whom before the action was taken.
Good evidence
Every sampled ticket shows verification performed and recorded before the reset or enrolment, with no cases of action taken on a name or username alone.
- Check 3 of 5What an auditor asks for
Ask for
Request evidence of how self-service reset and enrolment portals verify identity.
Look at
Examine the configuration or a walkthrough of the portal to see what a user must prove before a reset or a new authenticator enrolment is allowed.
Good evidence
The portal requires an identity check before completing the reset or enrolment, and the configuration matches the written procedure.
- Check 4 of 5What an auditor asks for
Ask for
Request records of requests to temporarily disable credentials.
Look at
Check that these requests were treated the same way as resets, with identity verified and recorded before the credential was disabled.
Good evidence
Disable requests are logged, the requester's identity was verified against the procedure, and there is no separate weaker path for this request type.
- Check 5 of 5What an auditor asks for
Ask for
Request training records and any review or audit of the credential request process.
Look at
Look for evidence that staff handling these requests have been trained on the verification procedure and that the process has been checked for compliance.
Good evidence
Relevant staff have completed training on the current procedure, and a periodic review shows verification is being carried out consistently across all channels.
Mappings
Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.16.
ISM-1593 requires verification of a user's identity before specific credential lifecycle actions (issue, reset, disable, enrol/re-enrol) are performed. Annex A 5.16 requires the full identity life cycle to be managed, which encompasses identity proofing/verification as part of joiner-mover-leaver and access provisioning processes. ISM-1593 is one specific control activity within the broader identity lifecycle management practices required by Annex A 5.16.
This control partially overlaps A.5.17.
ISM-1593 requires human users to provide sufficient evidence of identity before credentials are issued, reset, temporarily disabled, or enrolled/re-enrolled. Annex A 5.17 requires a controlled process for allocating and managing authentication information, which typically includes secure issuance and reset workflows where identity verification is a key step. Annex A 5.17 is broader about end-to-end authentication information management (handling, storage, distribution), while ISM-1593 is narrowly focused on the identity-proofing step at key credential lifecycle events.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.