Notify Users of Authentication Resets via Secondary Channel
When a software authentication factor is reset, users are informed through an additional communication method.
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.
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 developmentOfficial control statement
Where software allows an authentication factor to be reset, the user is notified of the reset through a secondary channel.
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
- AskThe system configuration document: Request details showing how secondary notifications are set up within the software GoodIncludes screenshots or descriptions showing active secondary notification settings
- AskA 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
- AskAbout staff training materials: Request to see any guides or slides used to educate staff about reset notifications GoodIncludes dates of training sessions and attendee lists
- AskIncident 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
- AskService provider contracts GoodAgreement explicitly requires that reset actions notify users through multiple channels
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 |
|---|---|---|
| sync_alt Partially overlaps (1) expand_less | ||
| Annex A 5.17 | Annex A 5.17 requires a managed process for authentication information, including secure handling and communication practices around cred... | |
| link Related (1) expand_less | ||
| Annex A 8.5 | Annex A 8.5 requires secure authentication procedures, including protecting credential lifecycle events like resets | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.