ASD ISM 1683 Central logging of multi-factor authentication events
What it says
Successful and unsuccessful multi-factor authentication events are centrally logged.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishMulti-factor authentication attempts, whether they succeed or not, are logged together in a central system.
This control is about making sure that all attempts to log in with extra security steps, whether successful or not, are recorded in one place. It's important because if there is suspicious activity, these records help us understand what happened so we can respond quickly and protect against security breaches.
Free. Save your status, tasks and notes.
Why it matters
Without central MFA event logging, failed and successful authentication attempts may be missed, delaying detection of account compromise.
How to implement
The IT team should set up a central logging system specifically for tracking multi-factor authentication (MFA) events.
They can do this by configuring the system settings to automatically send records of each login attempt to a central server or service.
Managers should ensure that the logging system integrates well with existing cyber security tools.
This may involve coordinating with the IT team to test the logging processes and ensure that alerts are triggered when unusual patterns or failed login attempts occur.
System owners need to work with the IT staff to determine what data should be logged for each MFA attempt.
This typically includes the time, user ID, and location of the attempt, helping identify any unusual access patterns.
Business owners are responsible for making sure that the logs are regularly reviewed.
They should set up a timetable for someone in the IT team to check the logs weekly, making sure any suspicious activity is investigated promptly.
HR should collaborate with IT to provide training to employees on the importance of MFA and logging practices.
They can organise workshops or send informational emails to ensure everyone understands how MFA logging protects the organisation.
Keep it running
Centrally log all successful and failed MFA events from all systems; review and protect logs weekly to detect abnormal patterns.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The current logging configuration document: Request a report or screenshot showing the systems configured to collect multi-factor authentication logs.
Look at
The details to ensure that all relevant systems are included.
Good evidence
Will provide evidence of comprehensive logging across all systems and user accounts.
- Check 2 of 5What an auditor asks for
Ask for
To see the alert procedures for failed MFA attempts: Request documentation that describes how alerts are handled when logging shows suspicious activity.
Look at
The response times and escalation procedures.
Good evidence
Shows clear steps for responding to alerts with timelines.
- Check 3 of 5What an auditor asks for
Ask for
A sample set of logs from the last month: Request a selection of event logs from the central system showing successful and unsuccessful MFA attempts. Look to see that the logs are detailed and well-organised.
Good evidence
Will include clear timestamps, user details, and outcomes.
- Check 4 of 5What an auditor asks for
Ask for
To review user access records: Request access records to cross-check how logged events match actual access approvals.
Look at
Consistency between access granted and MFA events logged.
Good evidence
Confirms that logs correspond correctly to access permissions.
- Check 5 of 5What an auditor asks for
Ask for
Reports on any recent suspicious MFA activity: Request records of how any suspicious events were handled.
Look at
The action steps taken and their outcomes.
Good evidence
Demonstrates that all incidents were appropriately logged, investigated, and resolved.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML2.6, MFA success and failure events are centrally logged, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.15.
ISM-1683 requires successful and unsuccessful MFA events to be centrally logged. Annex A 8.15 requires organisations to produce, store, protect, and analyse logs for relevant activities and events more broadly. ISM-1683 is a specific application of Annex A 8.15 focused on one high-value event type (MFA outcomes) and the centralisation aspect, while Annex A 8.15 covers a wider range of events and additional log handling expectations.
ASD Essential Eight: 2 mappings
This control is equivalent to E8-MF-ML2.6.
ISM-1683 requires that both successful and unsuccessful multi-factor authentication (MFA) events are centrally logged. E8-MF-ML2.6 states the same requirement for centrally logging MFA success and failure events. Both controls align in intent, scope (MFA events), and specificity (success and failure, central logging).
This control supports E8-AH-ML2.15.
ISM-1683 requires successful and unsuccessful MFA events to be centrally logged. E8-AH-ML2.15 requires timely analysis of cyber security events to identify incidents, and centrally logging MFA outcomes provides a reliable event source for detecting and triaging authentication attacks. E8-AH-ML2.15 emphasises analysis and incident identification, while ISM-1683 focuses on ensuring the MFA event data is captured centrally in the first place.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.