ASD ISM 1505 Multi-factor authentication for human users of data repositories
What it says
Multi-factor authentication is used to authenticate human users of data repositories.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishPeople who log in to databases, file shares, document stores and similar data repositories must prove who they are with a second factor, not a password alone.
A data repository is anywhere the organisation keeps its data in bulk: databases, data warehouses, file shares, document management systems, cloud storage buckets, backup stores and similar. These are where the most valuable information sits, so they are where an attacker with a stolen password does the most damage. This control says that when a person (as opposed to a system or service account) signs in to one of these repositories, the sign-in must use multi-factor authentication. That means the person has to present something more than a password, such as a code from an authenticator app, a hardware security key or a passkey, before access is granted. It matters because passwords on their own are routinely stolen through phishing, malware, credential-stuffing from other breaches and password reuse. If a repository accepts a password alone, one leaked credential is enough to read or take the whole data set. Requiring a second factor means a leaked password is not enough by itself, which blocks the most common route to a large data theft. The scope is deliberately about human users. Service and application accounts that connect to repositories are handled by other controls; this one is about every person who logs in, whether they are an administrator, an analyst, a developer or a business user.
Free. Save your status, tasks and notes.
Why it matters
If human users can reach data repositories with a password alone, any phished, guessed, reused or leaked password gives an attacker direct access to the organisation's stored data. That can lead to bulk theft of personal or sensitive information, tampering with records, ransomware staging from a position of trusted access, and notifiable data breaches with regulatory, financial and reputational consequences. Because repositories concentrate data, a single compromised account without MFA can expose far more than a compromised endpoint or mailbox.
How to implement
Have the security team compile a register of all data repositories (databases, data warehouses, file shares, document management systems, cloud storage, backup stores) and record for each the login paths available to people, including native client connections and web consoles, so nothing is missed.
Have identity or platform administrators route human access to each repository through the organisation's identity provider (SAML, OIDC or equivalent) and apply a conditional access or authentication policy that requires MFA for that application.
Where a repository cannot use single sign-on, have the platform owner enable the repository's own MFA feature (for example authenticator app, hardware key or certificate-plus-PIN) and turn off password-only login for all human accounts, including administrators.
Have the identity team make MFA enrolment a prerequisite in the access provisioning process, so a request for database, file share or storage access is only fulfilled once the requester has a registered second factor.
Have database and storage administrators disable or firewall direct login paths that bypass MFA, such as native SQL client ports open to user networks or local accounts on file servers, so the only way for a person to reach the data is through the MFA-protected path.
Keep it running
Keep an inventory of every data repository and record, for each one, how human users authenticate to it. Repositories that are reached through single sign-on inherit MFA from the identity provider, so confirm the SSO policy actually enforces MFA for that application and that no local or direct login path bypasses it.
Watch for the common gaps: direct database logins over native clients (for example SQL tools connecting straight to the database engine), file shares reached with local credentials, legacy systems that only support username and password, cloud storage consoles with their own login, and break-glass or shared administrator accounts. Each of these is still a human user of a data repository and needs a second factor, or needs its direct login disabled so access only flows through an MFA-protected path.
Build MFA enrolment into onboarding so a new user cannot receive repository access before they have a second factor registered. When someone leaves or changes role, remove their repository access as normal; MFA does not replace that step.
Review authentication logs for the repositories periodically to confirm sign-ins are recording a second factor, and treat any password-only human sign-in as a finding to be fixed rather than an exception to be tolerated.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of data repositories and how human users authenticate to each one.
Look at
Check that every repository type is listed (databases, file shares, document stores, cloud storage, backups) and that each has a named authentication path with MFA rather than a blank or 'password'.
Good evidence
A complete register where every repository shows an MFA-enforced login path for people, with any exceptions formally recorded and tracked.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the identity provider or conditional access policy that applies to repository applications.
Look at
Confirm the policy requires MFA, is scoped to all human users including administrators, and has no exclusion groups that quietly exempt people.
Good evidence
A policy requiring MFA for all users of the repository applications with no broad exclusions, and a change history showing it has been in force.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the native authentication configuration of a sample of repositories, such as a database engine, a file server and a cloud storage console.
Look at
Look for whether password-only login is still possible for human accounts, either through the console or through direct client connections.
Good evidence
Password-only login for people is disabled or blocked, and the only working path for a person requires a second factor.
- Check 4 of 5What an auditor asks for
Ask for
Ask for recent authentication logs from a sample of data repositories.
Look at
Trace a selection of human sign-ins and check each one records a second factor; look for any successful password-only sign-ins by named individuals.
Good evidence
Every human sign-in in the sample shows MFA, and any password-only events belong to approved service accounts rather than people.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the access provisioning and onboarding procedure for repository access.
Look at
Check whether MFA enrolment must be complete before access is granted, and whether the process covers privileged and break-glass accounts.
Good evidence
The procedure blocks repository access until a second factor is registered, and privileged accounts are held to the same requirement.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML3.1, Multi-factor authentication is used to authenticate users of data repositories, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.15.
ISM-1505 requires MFA to be used to authenticate users of data repositories. ISO/IEC 27001:2022 Annex A 5.15 requires establishing and implementing access control policies and procedures for controlling logical and physical access to information and associated assets. ISM-1505 is a specific logical access control mechanism that would typically be mandated within, and is therefore a subset of, the broader policy/procedural requirements in Annex A 5.15.
This control partially meets A.8.5.
ISM-1505 requires MFA to be used to authenticate users of data repositories. ISO/IEC 27001:2022 Annex A 8.5 requires secure authentication technologies and procedures based on access restrictions and access control policy, which can include MFA among other methods across many systems and use cases. ISM-1505 is therefore a specific implementation instance within the broader secure-authentication requirement of Annex A 8.5.
ASD Essential Eight: 9 mappings
This control is equivalent to E8-MF-ML3.1.
ISM-1505 requires multi-factor authentication (MFA) to be used to authenticate users of data repositories. E8-MF-ML3.1 states the same requirement for MFA on data repository access. The scope and intent align closely, with both focusing specifically on user authentication to data repositories.
This control is broader than E8-MF-ML3.3.
E8-MF-ML3.3 requires phishing-resistant MFA for authenticating users of data repositories. ISM-1505 requires MFA for users of data repositories but does not, by itself, require that the MFA method is phishing-resistant. E8-MF-ML3.3 therefore adds a specific strength/quality requirement on top of the baseline MFA requirement in ISM-1505.
This control partially overlaps E8-MF-ML1.1.
E8-MF-ML1.1 requires multi-factor authentication (MFA) for users accessing the organisation's online services that process, store or communicate sensitive data. ISM-1505 relates by requiring MFA for users of data repositories, which are a common class of system used to store or provide access to sensitive data. The overlap is strongest where those repositories are delivered as online services, but ISM-1505 can also apply to internal/non-online repositories while E8-MF-ML1.1 is specifically scoped to online services handling sensitive data.
This control partially overlaps E8-MF-ML1.3.
ISM-1505 requires multi-factor authentication (MFA) to be used to authenticate human users of data repositories. E8-MF-ML1.3 mandates MFA for users accessing third-party online services, including SaaS-based repositories. ISM-1505 focuses on repository access regardless of hosting, while E8-MF-ML1.3 emphasizes third-party service usage.
- E8-MF-ML1.4Use multi-factor authentication for online services handling customer dataPartially overlaps
This control partially overlaps E8-MF-ML1.4.
E8-MF-ML1.4 requires multi-factor authentication (MFA) for users accessing the organisation's online customer services that process, store or communicate sensitive customer data. ISM-1505 also mandates MFA, but specifically for users of data repositories, which may be part of (or adjacent to) those customer services. The overlap exists when the customer service relies on a repository holding customer data; however, ISM-1505 does not specifically target online customer services, and E8-MF-ML1.4 is not limited to repositories.
This control partially overlaps E8-MF-ML2.2.
E8-MF-ML2.2 requires MFA to authenticate unprivileged users of systems. ISM-1505 relates by requiring MFA for users of data repositories, which is a common system category accessed by unprivileged users. ISM-1505 is narrower to a specific asset type (data repositories) and applies regardless of privilege, whereas E8-MF-ML2.2 is scoped to unprivileged users across systems more generally.
This control supports E8-MF-ML1.7.
ISM-1505 requires that human users of data repositories authenticate using MFA. E8-MF-ML1.7 defines acceptable MFA factor combinations, supporting the correct implementation of MFA for ISM-1505.
This control supports E8-MF-ML2.5.
ISM-1505 requires MFA for human users accessing data repositories. E8-MF-ML2.5 specifies that MFA used must be phishing-resistant, which enhances the security of repository logons.
This control supports E8-MF-ML2.6.
ISM-1505 requires MFA to reduce unauthorised access. E8-MF-ML2.6 requires central logging of MFA events, supporting ISM-1505 by enabling monitoring and investigation of suspicious access attempts.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.