Skip to content
System access
ASD ISMISM-1893

ASD ISM 1893 Multi-factor authentication for third-party services holding sensitive customer data

What it says

Multi-factor authentication is used to authenticate human users to third-party online customer services that process, store or communicate their organisation's sensitive customer data.

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

What it means

In plain English

Staff logging in to outside online services that hold your sensitive customer data must prove who they are with more than a password.

Most organisations hand sensitive customer data to outside online services: a hosted CRM, a support-desk platform, a payments portal, a mailing tool, a cloud file share. Your own people log in to those services from a browser, and the only thing standing between an attacker and every customer record is that login. This control says that when a human user signs in to a third-party online customer service that processes, stores or communicates your organisation's sensitive customer data, the login must use multi-factor authentication (MFA). A password alone is not enough; the user must also present something else, such as a code from an authenticator app, a push approval or a hardware security key. It matters because passwords fail constantly. They get phished, reused across sites, guessed, or leaked in someone else's breach. A third-party service is exposed to the whole internet, so a working password can be tried from anywhere in the world. Because the data sitting behind that login belongs to your customers, a compromise is not just an internal problem; it is their privacy, and your obligations to them, on the line. MFA means a stolen password on its own no longer opens the door. The scope is deliberately specific: human users (not service accounts or API keys, which other controls address), third-party online services (not systems you host yourself), and services that handle sensitive customer data (not every SaaS tool you subscribe to).

Why it matters

If MFA is not enforced on these services, a single phished, reused or leaked staff password lets an attacker log in to a platform full of your customers' sensitive data from anywhere on the internet, with no further barrier. That can mean bulk exfiltration of customer records, fraudulent transactions or communications sent in your name, notifiable data breach obligations, regulatory scrutiny and loss of customer trust. Because the service is operated by a third party, you may also have limited visibility of the intrusion until the damage is done.

How to implement

  1. The information security manager, working with procurement and finance, builds and maintains a register of every third-party online customer service the organisation uses, records whether each one processes, stores or communicates sensitive customer data, and flags those that do as in scope for mandatory MFA.

  2. The IT or identity team integrates each in-scope service with the organisation's identity provider via SAML or OIDC single sign-on where the vendor supports it, and applies a conditional access or authentication policy that requires MFA for every human sign-in to that application.

  3. For in-scope services that cannot use single sign-on, the service administrator enables the vendor's tenant-wide 'require MFA for all users' setting in the admin console, and disables any option that lets individual users skip or defer enrolment.

  4. The IT service desk adds MFA enrolment for in-scope services to the onboarding checklist, issues authenticator apps or hardware security keys to new users before granting them access, and provides written enrolment instructions so no user receives customer-data access on a password alone.

  5. The security team schedules a quarterly review in which the service administrator exports the user list from each in-scope service, checks that every human account shows MFA enrolled and enforced, and raises tickets to remediate or disable any account that does not.

Keep it running

Day to day this control lives in two places: a register of which third-party online services handle sensitive customer data, and the tenant or account settings of each of those services.

Keep the register current. New SaaS subscriptions, trials that become permanent, and shadow-IT tools adopted by a single team all need to be caught and assessed for whether they process, store or communicate sensitive customer data. Procurement, finance (who see the invoices) and IT should all feed into it.

For each in-scope service, MFA should be enforced at the tenant level rather than left to individual users to opt in. Where the service supports single sign-on through your identity provider, route the login through it so MFA is enforced centrally and consistently; where it does not, use the service's native MFA enforcement setting. Check that break-glass or admin accounts on the service are covered too, since they are still human users.

Joiners, movers and leavers matter. New users must be enrolled in MFA before they can access customer data, and MFA settings should be re-verified when accounts are re-enabled or when the vendor changes its authentication options. Periodically export the user list from each service and confirm every human account shows MFA as enrolled and enforced. If a vendor cannot support MFA at all, that is a finding to escalate, not a quiet exception.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the register of third-party online services the organisation uses and the assessment of which ones process, store or communicate sensitive customer data.

    Look at

    Check that the register is recent, that each entry has a clear yes or no on sensitive customer data, and compare it against a sample of SaaS invoices or the single sign-on application list to spot services that are missing.

    Good evidence

    The register is current, every service handling sensitive customer data is marked in scope, and spot checks against invoices and the SSO catalogue find nothing unaccounted for.

  2. Check 2 of 5What an auditor asks for

    Ask for

    For each in-scope service, ask for a screenshot or export of the tenant-level authentication settings, or of the identity provider policy that governs sign-in to that application.

    Look at

    Look for a setting that requires MFA for all users rather than merely making it available, and check whether any groups, roles or legacy authentication paths are excluded.

    Good evidence

    MFA is enforced for all human users at the tenant or policy level, with no opt-out and no excluded groups other than documented non-human accounts.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for a current export of the user accounts on two or three in-scope services, showing each account's MFA enrolment status.

    Look at

    Check whether every human account shows MFA enrolled, and pay particular attention to administrators, shared logins and accounts that were recently created or re-enabled.

    Good evidence

    Every human account is enrolled in MFA, and any account without it is either a documented service account or has already been disabled.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask to observe a user, or an auditor test account, signing in to an in-scope service.

    Look at

    Watch whether the login prompts for a second factor after the password and whether it is possible to get to customer data without completing it.

    Good evidence

    The second factor is demanded on every sign-in and access is refused until it is completed.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the onboarding procedure and the most recent periodic MFA review for in-scope services, including any tickets raised as a result.

    Look at

    Check that MFA enrolment happens before access to customer data is granted, that the review actually took place on schedule, and that any gaps found were closed.

    Good evidence

    Onboarding requires MFA before access, reviews are performed on schedule with evidence, and exceptions are remediated and tracked rather than left open.

Mappings

Closest match in ASD Essential Eight: E8-MF-ML1.5, Multi-factor authentication for third-party services with sensitive customer data, 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: 9 mappings

  • E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataEquivalent
  • E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINBroader than
  • E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially meets
  • E8-MF-ML1.1Require multi-factor authentication for sensitive online servicesPartially overlaps
  • E8-MF-ML1.2Multi-factor authentication for third-party services handling sensitive dataPartially overlaps
  • E8-MF-ML1.4Use multi-factor authentication for online services handling customer dataPartially overlaps
  • E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataPartially overlaps
  • E8-MF-ML2.2Use multi-factor authentication for unprivileged user accessPartially overlaps

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