ASD ISM 2047Secondary-Channel Notification of Authentication Factor Resets
Official control statement
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.
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.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for software developmentTopic
Secure software development
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.
Operational notes
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.
Implementation tips
- 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.
- 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.
- 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.
- 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.
- 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.
Audit / evidence tips
- AskAsk for the inventory of software that can reset an authentication factor for a human user, together with the reset paths each one supports.Look atCheck 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.GoodEvery 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.
- AskAsk to see the notification configuration in the main identity provider or self-service reset portal.Look atLook 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.GoodPassword, authenticator and token resets each trigger a message to registered email, SMS or an enrolled device rather than only an on-screen confirmation.
- AskAsk for the helpdesk procedure for resetting a user's password or re-enrolling their MFA.Look atCheck whether the procedure uses tooling that automatically sends the secondary-channel notice, and whether it prohibits manual reset methods that would bypass it.GoodOperator 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.
- AskAsk for a sample of recent reset notifications, or a live demonstration of a test reset.Look atLook 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.GoodThe 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.
- AskAsk how the software captures the secondary contact details used for reset notices, and what happens when a user reports an unexpected reset notice.Look atLook at the user profile or enrolment fields that hold the secondary channel, and the service desk escalation path for suspected unauthorised resets.GoodA 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.
Cross-framework mappings
How ISM-2047 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.16 | ISM-2047 requires secondary-channel notification to the human user whenever an authentication factor reset occurs, providing a direct use... | |
| Annex A 5.17 | ISM-2047 requires that when a human user's authentication factor is reset, the user is notified via a secondary channel to detect unautho... | |
| Annex A 8.5 | ISM-2047 requires an operational safeguard for secure authentication operations: notifying a user via a secondary channel when an authent... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Software development
See all Guidelines for software development controls, or browse the full ASD ISM library.