Skip to content
System access
ASD ISMISM-1894

ASD ISM 1894 Phishing-resistant multi-factor authentication for human users of data repositories

What it says

Multi-factor authentication used for authenticating human users of data repositories is phishing-resistant.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Where people log in to data repositories with multi-factor authentication, the second factor must be one that a phishing site or fake login page cannot capture and replay.

Data repositories (databases, file shares, document stores, data lakes and similar systems that hold an organisation's information) are prime targets because one successful login can expose large amounts of data at once. Multi-factor authentication (MFA) is meant to stop a stolen password being enough, but not all MFA is equal. Codes sent by SMS or email, one-time codes from an authenticator app, and push-notification approvals can all be tricked out of a user by a convincing fake login page or by a "prompt bombing" attack that wears the user down until they tap approve. This control requires that, when human users authenticate to data repositories using MFA, the MFA method is phishing-resistant. Phishing-resistant methods (for example security keys and passkeys based on FIDO2 or WebAuthn, and smart cards with certificate-based authentication) bind the login to the genuine site and never hand a reusable secret to the user, so there is nothing for an attacker to capture or replay. The scope is specific: it applies to human users (not service accounts or system-to-system connections) and to data repositories. The real-world risk it addresses is an attacker harvesting a user's credentials and their MFA code or approval through a phishing campaign, then walking straight into the repository as that user.

Why it matters

If MFA for data repository users is not phishing-resistant, a single successful phishing email or fake login page can give an attacker both the password and the second factor, letting them access, copy or alter the repository's data as a legitimate user. Because repositories concentrate large volumes of information, the result is often a large-scale data breach with regulatory, legal and reputational consequences, and the organisation may believe it was protected by MFA when in practice that protection was bypassed.

How to implement

  1. The data owner and IT team compile an inventory of data repositories (databases, file shares, document management systems, data lakes and similar) and record how human users authenticate to each, identifying any that still allow SMS, email, one-time-code or push-approval MFA.

  2. The identity and access team enables phishing-resistant methods in the identity provider, such as FIDO2 security keys, platform or synced passkeys, or certificate-based smart card authentication, and integrates each data repository with that identity provider where it is not already connected.

  3. The identity and access team configures an authentication-strength or conditional access policy that requires a phishing-resistant method for every human user accessing a data repository, and removes SMS, email, app-code and push-approval options for those users so there is no weaker fallback.

  4. The service desk issues security keys or guides users through passkey registration during onboarding, and defines a verified recovery process for lost or damaged authenticators that re-issues a phishing-resistant credential rather than temporarily enabling a phishable method.

  5. The security team runs a periodic check (for example quarterly) of identity provider sign-in reports for data repositories, confirms that every successful human login used a phishing-resistant method, and raises a ticket to remediate any repository or user group where a weaker method was accepted.

Keep it running

Day to day, this control lives in the identity provider and in the authentication settings of each data repository. Administrators need an up-to-date inventory of which systems count as data repositories and which identity provider or local authentication each one uses, so that the phishing-resistant requirement is enforced everywhere rather than only on the obvious systems.

Onboarding and offboarding processes must include issuing, registering and revoking phishing-resistant authenticators (for example security keys or passkeys), and a supported process for lost or broken authenticators that does not fall back to a phishable method such as SMS codes. Conditional access or authentication-strength policies should be set so that repository access is only granted when a phishing-resistant method was used, and weaker methods should be removed as allowed options for these users rather than merely discouraged.

Watch for drift: new repositories, new user groups, break-glass accounts and vendor or contractor users are common places where weaker MFA quietly reappears. Periodic reviews of authentication logs and policy settings keep the control effective over time.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the inventory of data repositories and the record of which authentication method or identity provider each one uses for human users.

    Look at

    Check that the inventory is current and that every listed repository has a documented MFA method for human users.

    Good evidence

    Every repository is accounted for and each shows a phishing-resistant method, with no gaps or systems marked as unknown.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the identity provider's authentication-strength or conditional access policy that applies to data repository access.

    Look at

    Look at which methods the policy accepts and which user groups and applications it covers.

    Good evidence

    The policy requires a phishing-resistant method (for example FIDO2, passkey or certificate-based) for all human users of the repositories and does not list SMS, email, one-time codes or push approval as acceptable alternatives.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for a sample of recent sign-in logs for one or more data repositories.

    Look at

    Check the authentication method recorded against successful human logins.

    Good evidence

    Successful logins consistently show a phishing-resistant method, and any attempts using weaker methods were rejected.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the onboarding and authenticator recovery procedures used by the service desk.

    Look at

    Look at how new users receive their authenticator and what happens when one is lost or broken.

    Good evidence

    Users are issued security keys or register passkeys before gaining repository access, and recovery re-issues a phishing-resistant credential rather than falling back to a code sent by SMS or email.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the most recent review or exception register covering MFA methods for data repository users.

    Look at

    Check whether reviews are done at a defined interval and how any user or repository still on a weaker method is tracked.

    Good evidence

    Reviews are recent and regular, exceptions are few, time-bound and approved, and each has a remediation plan to move to a phishing-resistant method.

Mappings

Closest match in ASD Essential Eight: E8-MF-ML3.3, Phishing-resistant multi-factor authentication for data repositories, which asks for the same thing.

ISO 27001

ISO/IEC 27001: 1 mapping

  • A.8.5Secure authentication technologies and proceduresPartially meets
Essential Eight

ASD Essential Eight: 4 mappings

  • E8-MF-ML3.3Phishing-resistant multi-factor authentication for data repositoriesEquivalent
  • E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially meets
  • E8-MF-ML2.3Multi-factor authentication online services must be phishing-resistantPartially overlaps
  • E8-MF-ML3.1Multi-factor authentication is used to authenticate users of data repositoriesDepends on

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.