Skip to content
Software development
ASD ISMISM-2047

ASD ISM 2047 Secondary-channel notification of authentication factor resets

What it says

Where software allows an authentication factor to be reset for a human user, the human user is notified of the reset through a secondary channel.

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

What it means

In plain English

When a person's password, passkey, token or other login factor is reset, the software tells them through a different channel so they can spot a reset they did not ask for.

Most software lets a login factor be reset. A password can be changed, a lost authenticator app can be re-enrolled, a security key can be swapped out, or a helpdesk operator can issue a temporary credential. That reset function is also one of the easiest ways for an attacker to take over an account, because they never need to know the old factor at all. This control says that whenever software allows an authentication factor to be reset for a human user, the software must notify that user through a secondary channel. The key word is secondary. The message must go somewhere the reset itself did not touch, such as a registered email address when the password was reset in a web portal, an SMS to a known mobile number, a push message to an already-enrolled device, or a notice in a separate corporate messaging tool. If the notice is only shown inside the session that performed the reset, the person who did the reset sees it, and that may not be the real user. It matters because the legitimate user is often the only person who can tell the difference between a reset they requested and one they did not. A prompt notice through a channel the attacker does not control gives that person the chance to raise the alarm, and it turns a silent account takeover into an event someone notices.

Why it matters

Without secondary-channel notification, an attacker or a mistaken administrator can reset a user's password, authenticator or token and the real user has no way of knowing. The account can be used, data read or altered, and further access requested under the user's name, and the takeover stays invisible until the user is locked out or the damage is discovered by other means. The window between compromise and detection grows, and the organisation loses the cheapest early-warning signal it has for credential abuse.

How to implement

  1. Development teams list every reset path their software offers for a human user's authentication factor (self-service, helpdesk-initiated, administrator console, API or script) in the design documentation and record the secondary channel each path notifies, so that no reset route is left without a notification.

  2. Developers build the secondary-channel notification into the reset function itself, so that the same code path that resets a password, authenticator or token also sends a notice to registered email, SMS, or a push message to an already-enrolled device, never only to the session or channel that performed the reset.

  3. Developers route operator-initiated and administrator-initiated resets through the same notifying function as self-service resets, and avoid exposing direct data-store edits or console shortcuts that would bypass the notice.

  4. The development team writes the notification template in plain language stating which factor was reset, the time, and a clear instruction to contact the service desk immediately if the user did not request it, and includes a contact route that does not rely on the account that was just reset.

  5. Developers include secondary contact fields (email address, mobile number, enrolled device) in the software's user profile, populate them at enrolment, and let users update them when they change, so notifications reach a channel the genuine user actually monitors.

Keep it running

In day-to-day operation this control lives in two places: the design of any software the organisation develops or maintains that can reset an authentication factor (its reset flows, the notification logic behind them, and the secondary channel recorded for each user), and the accuracy of the secondary contact details held for each user.

Whoever owns each reset-capable application should know which reset paths exist (user self-service, helpdesk-initiated, administrator console, API or script) and confirm that every one of them triggers a notification to a channel other than the one used for the reset. Onboarding and account-change processes should capture and keep current the email address, mobile number or enrolled device that will receive these notices, because a notification sent to an address the user no longer checks is no notification at all.

The service desk needs a simple response path for a user who says "I got a reset notice but I did not request it", including who to escalate to. Notification templates should say clearly what was reset, when, and what to do if it was not expected. When a new release adds a reset capability or changes an existing one, the notification behaviour should be checked again rather than assumed to carry over.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the inventory of software that can reset an authentication factor for a human user, together with the reset paths each one supports.

    Look at

    Check whether the list covers self-service, helpdesk, administrator and scripted resets across identity providers, MFA platforms and applications with local accounts, and whether each path has a notification channel recorded against it.

    Good evidence

    Every reset path is listed and each one names a secondary channel that receives the notice. Gaps, if any, are known and have a remediation date.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask to see the notification configuration in the main identity provider or self-service reset portal.

    Look at

    Look at which events trigger a message and where the message is delivered, and confirm that the destination is separate from the session or channel used to perform the reset.

    Good evidence

    Password, authenticator and token resets each trigger a message to registered email, SMS or an enrolled device rather than only an on-screen confirmation.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the helpdesk procedure for resetting a user's password or re-enrolling their MFA.

    Look at

    Check whether the procedure uses tooling that automatically sends the secondary-channel notice, and whether it prohibits manual reset methods that would bypass it.

    Good evidence

    Operator resets go through the same notifying workflow as self-service resets, and the procedure tells staff not to use direct edits that skip the notice.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for a sample of recent reset notifications, or a live demonstration of a test reset.

    Look at

    Look at the content of the message, the channel it went to, how soon after the reset it was sent, and whether it tells the user what to do if they did not request the change.

    Good evidence

    The message arrives promptly on a channel the user monitors, clearly names the factor reset, and gives a contact route that does not depend on the reset account.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask how the software captures the secondary contact details used for reset notices, and what happens when a user reports an unexpected reset notice.

    Look at

    Look at the user profile or enrolment fields that hold the secondary channel, and the service desk escalation path for suspected unauthorised resets.

    Good evidence

    A secondary channel is held for every user who can have a factor reset, and the service desk has a defined escalation for a user who receives a notice they did not expect.

Mappings

Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.5.16Identity life cycle managementPartially meets
  • A.5.17Management of authentication informationPartially meets
  • A.8.5Secure authentication technologies and proceduresPartially meets

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