ASD ISM 2077 Avoid email for out-of-band authentication
What it says
Email is not used for out-of-band authentication purposes.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishDo not use email for secondary authentication steps to increase security.
This control is about not using email as a second way to verify someone's identity when trying to access important information. Email can be hacked or misused, and if that happens during a verification process, an unauthorised person might get into your systems. This could lead to stolen data or other security troubles.
Free. Save your status, tasks and notes.
Why it matters
Using email for out-of-band authentication exposes codes/links to mailbox compromise; attackers who access email can complete MFA and take over accounts.
How to implement
IT manager should ensure alternative methods for out-of-band authentication are used.
This means selecting a more secure option like text message verification, phone calls, or special apps that provide verification codes. Roll these out by training staff and updating security settings in all applications that require out-of-band authentication.
Business owners should work with IT to review current authentication methods.
Make a list of systems that rely on email for verifying identities and replace them with more secure options. Use new security tools that do not rely on email and ensure they are correctly integrated into daily operations.
Security teams need to educate staff on the risks of email verification.
Hold workshops or create easy-to-understand guides explaining why email isn't safe for this purpose and what alternatives are being used. Regular communication helps everyone understand the changes and remember why they're important.
System administrators should remove email verification options from existing systems.
Update security settings and user guides to reflect new processes. This involves changing configuration settings in software to disable email for these verifications and testing the updated systems to make sure everything works smoothly.
Keep it running
Do not send OTPs or magic links via email. Use authenticator apps, FIDO2/WebAuthn or SMS, and verify enrolment/recovery flows exclude email.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The list of systems using out-of-band authentication methods: Request documentation showing which systems use secure alternatives to email for verification.
Look at
Clear identification of non-email methods like phone apps or SMS.
Good evidence
The document lists systems, chosen methods, and notes confirming email is not used.
- Check 2 of 5What an auditor asks for
Ask for
To see security training records: Request evidence of staff training regarding authentication changes.
Look at
Details that show who attended sessions and what topics were covered.
Good evidence
Training logs showing participation and specific topics on avoiding email for authentication.
- Check 3 of 5What an auditor asks for
Ask for
Procurement criteria documents: Request criteria used when purchasing software relating to authentication security.
Look at
Specific requirements that state email should not be used as a verification method.
Good evidence
Clearly written vendor requirements indicating email isn't accepted for verification.
- Check 4 of 5What an auditor asks for
Ask for
To see configuration settings: Request a demonstration of security settings on chosen systems.
Look at
Settings screens showing alternative verification methods are enabled and email is disabled.
Good evidence
A settings page or screenshot proving email is not an active option for verification.
- Check 5 of 5What an auditor asks for
Ask for
Incident response records: Request any incident reports related to authentication breaches. Look to see if emails were potentially involved in past incidents and what was done to mitigate.
Good evidence
Records confirming no email-related breaches due to proactive removal of email for verification.
Mappings
Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.5.
ISM-2077 requires that email is not used for out-of-band authentication purposes. This is a specific application of secure authentication design covered by Annex A 8.5, which requires implementing secure authentication technologies appropriate to access restrictions. Annex A 8.5 is broader because it covers the overall operation of authentication mechanisms, whereas ISM-2077 focuses narrowly on excluding email as an out-of-band method.
ASD Essential Eight: 5 mappings
- E8-MF-ML3.2Phishing-resistant multi-factor authentication for online customer servicesPartially overlaps
This control partially overlaps E8-MF-ML3.2.
E8-MF-ML3.2 requires phishing-resistant MFA for customers accessing online customer services. ISM-2077 prohibits using email for out-of-band authentication, reducing exposure to phishing and mailbox compromise that would undermine MFA flows. ISM-2077 supports achieving the phishing-resistant objective in E8-MF-ML3.2, but it does not itself mandate MFA or guarantee phishing-resistance.
This control depends on E8-MF-ML2.2.
E8-MF-ML2.2 requires MFA to authenticate unprivileged users of systems. ISM-2077 supports this by prohibiting email as an out-of-band authentication method, reducing the risk that MFA implementations used under E8-MF-ML2.2 are weakened by interceptable channels. ISM-2077 is about secure MFA design choices rather than mandating MFA coverage for unprivileged user access.
This control depends on E8-MF-ML2.3.
ISM-2077 requires that email is not used as an out-of-band authentication channel. This supports E8-MF-ML2.3 because email-based verification codes and links are generally not phishing-resistant, so prohibiting email helps drive adoption of stronger MFA factors for online services. E8-MF-ML2.3 is broader in requiring phishing-resistant MFA overall, while ISM-2077 is a specific prohibition on one weak out-of-band method.
This control depends on E8-MF-ML2.5.
ISM-2077 requires that organisations do not use email for out-of-band authentication. This supports E8-MF-ML2.5 because email is commonly used as a second step for system access, and eliminating it reduces exposure to mailbox compromise and phishing that would defeat MFA. E8-MF-ML2.5 sets a broader requirement for phishing-resistant MFA for system access, whereas ISM-2077 focuses only on excluding email as the out-of-band channel.
This control depends on E8-MF-ML3.3.
E8-MF-ML3.3 requires phishing-resistant MFA to protect access to data repositories from phishing attacks. ISM-2077 supports this outcome by prohibiting email as an out-of-band authentication channel, which is commonly phishable and susceptible to account takeover. ISM-2077 is narrower (channel restriction) and does not by itself ensure phishing-resistant MFA for data repositories.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.