Skip to content
System access
ASD ISMISM-1595

ASD ISM 1595 Credentials issued to human users are changed on first use

What it says

Credentials provided to human users are changed on first use.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Any credential handed to a person (an initial password, passphrase or PIN) is treated as temporary and must be replaced by the user the first time they use it.

When an organisation gives a person a credential, such as an initial password, a passphrase, or a PIN for a new account or a reset, that credential has passed through other hands. An administrator generated it, a help desk operator may have read it out, and it may sit in an email, a ticket, a printout or a chat message. Because more than one person knows it, it cannot yet be treated as a secret belonging to the user alone. This control requires that every credential provided to a human user is changed the first time it is used. The user replaces the issued value with one that only they know, which closes the window in which the credential is shared knowledge. It applies to all credentials that are handed to people, not just passwords for new starters: it also covers resets, temporary access, and any other case where an issued value is supplied to a person. The real-world risk is straightforward. Issued credentials are often predictable (a standard pattern, a welcome-pack default) or are left sitting in inboxes and tickets long after they were used. If they are never changed, anyone who saw or can guess the issued value can sign in as that user indefinitely, and the activity will look legitimate because it is the user's own account.

Why it matters

If issued credentials are not changed on first use, a temporary password, passphrase or PIN that an administrator, help desk staff member, or anyone with access to the delivery channel has seen remains valid indefinitely. An attacker who obtains it from an email, ticket, printout or predictable pattern can sign in as the legitimate user, and the resulting access is difficult to distinguish from genuine activity, which undermines accountability and enables unauthorised access to systems and data.

How to implement

  1. Identity or directory administrators enable the "user must change credential at next logon" (or equivalent) setting as a mandatory step in every account creation and credential reset procedure, and bake it into the provisioning script or identity management workflow so it cannot be skipped.

  2. The help desk lead updates the credential reset procedure so that every reset issued to a person is created with the forced-change flag set, and includes a checklist step confirming the flag before the reset value is communicated to the user.

  3. System owners of platforms that are not connected to the central directory (standalone applications, network devices, local accounts) configure the forced first-use change natively where the product supports it, and where it does not, define a supervised process in which the user changes the issued credential immediately with the administrator present and the change is recorded.

  4. The identity team includes credentials such as PINs and passphrases for tokens, mobile devices and multi-factor enrolment in the same procedure, so that any issued value a person receives, not just a directory password, is replaced by the user on first use.

  5. The identity team schedules a periodic review that samples recently created or reset accounts and compares the credential issue timestamp with the user's own change timestamp, and raises a remediation ticket for any account where the issued credential is still in use.

Keep it running

In day-to-day operation this control lives inside the account provisioning and credential reset processes. Wherever a person is issued a credential (new account creation, a help desk password reset, a temporary PIN for a device or token, a break-glass or emergency access value handed to a named individual), the system or process must force the user to replace it at first use rather than relying on the user to remember to do so.

The most common gap is not new starters, where the "change at first logon" flag is usually well established, but the secondary paths: manually created accounts on systems that are not joined to the central directory, credentials set by administrators during troubleshooting, and credentials issued for applications or devices that do not support a forced change. Those exceptions need to be identified and handled, for example by having the administrator or user complete the change immediately in a supervised step.

Keep an eye on drift over time. Provisioning scripts, imaging templates and identity tooling get updated, and the forced-change setting can be silently lost. Periodic spot checks of recently issued credentials, comparing the issue time against the time of the user's own change, are an effective way to confirm the control is still operating.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the account provisioning and credential reset procedures that apply to human users.

    Look at

    Look for an explicit, mandatory step requiring the issued credential to be flagged for change at first use, covering new accounts, resets and any other issued credentials such as PINs and passphrases.

    Good evidence

    The procedures make the forced change a required step rather than an optional recommendation, and cover every path by which a person can be issued a credential.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask to observe a new account being created or a credential being reset in the live identity system.

    Look at

    Watch whether the change-at-next-logon (or equivalent) setting is applied automatically by the tooling or workflow, or depends on the operator remembering to tick it.

    Good evidence

    The forced-change setting is applied automatically by the provisioning tooling, and the demonstration shows the user being prompted to replace the credential on first sign-in.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for a list of accounts created or reset in a recent period, with the credential issue time and the last credential change time.

    Look at

    Compare the two timestamps and identify accounts where the issued credential appears never to have been changed by the user.

    Good evidence

    Every sampled account shows a user-initiated change shortly after the issue time, and any exceptions have a documented reason and a remediation action.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the inventory of systems that issue credentials to people but are not managed through the central directory, such as standalone applications, network devices and local accounts.

    Look at

    Check how the first-use change is enforced on each one, and whether systems that cannot enforce it have a defined supervised alternative.

    Good evidence

    Each system either enforces the change technically or has a documented, evidenced manual process, and there are no systems where issued credentials simply persist.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask how credentials other than directory passwords, such as PINs and passphrases for tokens, devices and multi-factor enrolment, are handled when issued to users.

    Look at

    Look for evidence that these are also treated as temporary and replaced by the user on first use, rather than being excluded from the control.

    Good evidence

    All issued credential types are covered by the same first-use change requirement, and the organisation can show configuration or records demonstrating this for each type.

Mappings

Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control partially meets.

ISO 27001

ISO/IEC 27001: 1 mapping

  • A.5.17Management of authentication informationPartially meets

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.