Notify Users of Authentication Resets via Secondary Channel
When a software authentication factor is reset, users are informed through an additional communication method.
🏛️ Framework
ASD Information Security Manual (ISM)
🧭 Control effect
Responsive
🔐 Classifications
NC, OS, P, S, TS
🗓️ ISM last updated
May 2025
✏️ Control Stack last updated
19 Mar 2026
🎯 E8 maturity levels
N/A
Guideline
Guidelines for software developmentWhere software allows an authentication factor to be reset, the user is notified of the reset through a secondary channel.
Source: ASD Information Security Manual (ISM)
Plain language
When you're allowed to reset a password or other security check, this control makes sure you're informed through a different method, like an email or text. This matters because if someone else tries to mess with your account, you'll know about it right away and can act quickly to protect your information.
Why it matters
Without secondary-channel notification, users may not detect unauthorised factor resets, enabling attackers to take over accounts unnoticed.
Operational notes
Send reset alerts via a separate channel (e.g., SMS, email, push) immediately on factor reset, using automation and logging to verify delivery.
Implementation tips
- Business owners should ensure the software used supports dual notification methods. This means checking that, after a password reset, the software can alert users through a separate method like an email or SMS. Work with your software provider to confirm this feature is available and enabled.
- IT teams need to configure the software to send the secondary notification properly. This involves going into the system settings and adding details like the user's phone number or secondary email where notifications should be sent. Test this by resetting an account and checking that the notification arrives correctly.
- Office managers should educate staff about what security notifications look like. Organise a brief session to show example emails or texts they should expect if their authentication settings are changed. Encourage them to report any unexpected notifications immediately.
- Customer service teams should be trained on how to respond to user inquiries about reset notifications. Develop a process guideline so they can quickly verify if a notification is legitimate and how to advise clients to proceed if they suspect unauthorised activity.
- Procurement teams should ensure contracts with service providers include terms requiring dual notification of resets. When selecting new software, include specifications for security features like secondary notification channels as part of your criteria for decision-making.
Audit / evidence tips
-
Ask: the system configuration document: Request details showing how secondary notifications are set up within the software
Good: includes screenshots or descriptions showing active secondary notification settings
-
Ask: a record of test notifications: Request logs showing recent reset notifications were sent to users through a secondary channel. Examine the date, time, and method of notifications. Good evidence shows consistent and timely notification entries aligned with user reset actions
-
Ask: about staff training materials: Request to see any guides or slides used to educate staff about reset notifications
Good: includes dates of training sessions and attendee lists
-
Ask: incident response procedures: Obtain documents outlining steps to handle unauthorised reset notifications. Check the clarity and efficiency of the process described. The best case is a well-defined procedure featuring quick responses and user guidance
-
Ask: service provider contracts
Good: agreement explicitly requires that reset actions notify users through multiple channels
Cross-framework mappings
How ISM-2047 relates to controls across ISO/IEC 27001, Essential Eight, and ASD ISM.
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
ISO 27001
| Control | Notes | Details |
|---|---|---|
| Partially overlaps (1) | ||
| Annex A 5.17 | Annex A 5.17 requires a managed process for authentication information, including secure handling and communication practices around cred... | |
| Related (1) | ||
| Annex A 8.5 | Annex A 8.5 requires secure authentication procedures, including protecting credential lifecycle events like resets | |