Skip to content
System access
ASD ISMISM-1680

ASD ISM 1680 Multi-factor authentication for human users of third-party services holding non-sensitive data

What it says

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

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

What it means

In plain English

Turn on MFA for every staff login to third-party online services that hold your non-sensitive data, wherever the service offers it.

Most organisations rely on a long list of cloud and web-based services run by other companies: marketing tools, survey platforms, project trackers, booking systems, newsletter senders and similar. Many of these hold only non-sensitive data, so they tend to get less attention than the systems holding classified or highly sensitive information. This control says that when a person logs in to one of those third-party online services, and the service offers multi-factor authentication (MFA), the organisation uses it. MFA means the login needs more than a password, such as a code from an authenticator app or a physical security key, so a stolen or guessed password alone is not enough. The scope has three deliberate boundaries. It applies to human users (people logging in, not system-to-system or service accounts). It applies to third-party online services (services run and hosted by someone else, accessed over the internet). And it applies to services that process, store or communicate the organisation's non-sensitive data. The phrase "where available" matters too: the control does not require you to abandon a service that has no MFA option, but it does require you to switch MFA on wherever the provider supports it. Why it matters: passwords for these lower-priority services are often weaker, reused across sites, or exposed in third-party breaches that the organisation never hears about. An attacker who logs in with a valid password can read or alter data, send messages that appear to come from your organisation, pivot to connected accounts through password reuse, or use the foothold for phishing and fraud. "Non-sensitive" does not mean "harmless"; it means the data is not classified as sensitive, and the accounts around it still carry real risk. MFA is one of the cheapest and most effective ways to shut that door.

Why it matters

If MFA is left off for third-party online services, a single compromised password (from phishing, credential stuffing, reuse across sites or a breach at another provider) gives an attacker full access to that service as a legitimate user. Consequences include exposure or tampering of the organisation's data held in the service, misuse of the account to send fraudulent messages or content under the organisation's name, escalation to other services where the same password is reused, and reputational harm when customers or partners are affected. Because these services sit outside the organisation's own network, the intrusion may go unnoticed for a long time, and the organisation may be unable to demonstrate that it applied a widely available, low-cost safeguard.

How to implement

  1. The IT or security lead builds a register of every third-party online service that processes, stores or communicates the organisation's non-sensitive data, by combining procurement records, expense claims, single sign-on logs and a short staff survey, and records for each service whether the provider supports MFA.

  2. The internal owner of each service enables MFA for all human user accounts in that service's admin console, choosing the strongest method the provider supports (authenticator app or security key ahead of SMS), and sets it to mandatory at the organisation or tenant level where that option exists.

  3. The identity and access administrator connects services that support single sign-on to the organisation's identity provider and applies an MFA policy there, so that MFA is enforced centrally and consistently across those services rather than configured one service at a time.

  4. The service desk writes a short enrolment and recovery guide for staff, covering how to set up an authenticator, what to do if a phone is lost, and who to contact, and issues it to every user when they are first given access to a third-party service.

  5. The security lead schedules a quarterly check of the register, during which each service owner confirms in the admin console that MFA is still enforced, re-checks any service previously recorded as lacking MFA to see whether the provider now offers it, and enables it where it has become available.

Keep it running

**Keeping an inventory current.** The control only works if the organisation knows which third-party online services its people use for non-sensitive data. Maintain a register of these services, who owns each one internally, whether the provider offers MFA, and whether MFA is enforced. Review it when new services are procured and on a regular cycle, since staff often sign up for tools without telling IT.

**Enforcing rather than inviting.** Where the provider allows it, set MFA as mandatory at the tenant or organisation level, or route logins through the corporate identity provider so MFA is applied centrally. Relying on each user to opt in leaves gaps.

**Handling "where available".** For services with no MFA option, record that fact in the register with the date checked, and re-check periodically because providers add MFA over time. When MFA becomes available, enable it promptly.

**New users.** New users of a service should be enrolled in MFA at the time their account is created, so that no human user authenticates to the service with a password alone.

**Supporting users.** Provide a simple way for staff to enrol authenticators, replace a lost device and recover access, so that MFA does not get switched off "temporarily" to solve a support ticket.

**Checking it stays on.** Periodically confirm MFA settings in each service's admin console or through the identity provider's reports, since provider changes, plan downgrades or administrator actions can silently disable enforcement.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the register of third-party online services that handle the organisation's non-sensitive data, showing for each one whether the provider offers MFA and whether it is enforced.

    Look at

    Check that the register is recent, has a named owner per service, and includes commonly overlooked tools such as marketing, survey and scheduling platforms, not just the obvious ones.

    Good evidence

    A current, complete register with an MFA status for every service, an explanation for any service where MFA is not available, and a date showing when availability was last re-checked.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask to see the admin console or tenant settings for a sample of services in the register.

    Look at

    Look for the MFA enforcement setting at the organisation level and confirm it is switched on for all human users rather than left as an optional per-user choice.

    Good evidence

    MFA is mandatory for all human user accounts in each sampled service, and no users are exempt without a documented reason.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the identity provider's MFA policy and the list of third-party services connected to it through single sign-on.

    Look at

    Confirm the policy requires MFA for those services and that the connected-service list matches the register, so nothing is bypassing the central policy through a direct login.

    Good evidence

    A clear MFA policy applied to all federated third-party services, with any direct-login accounts on those services either disabled or covered by the service's own MFA.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the user list of two or three services, showing each account's MFA enrolment status.

    Look at

    Look for active human user accounts with MFA not yet set up, or with MFA enrolment pending or bypassed, and check that any exemptions are documented.

    Good evidence

    Every active human user is enrolled in MFA, with no accounts still authenticating by password alone.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask how the organisation handles services that do not offer MFA and how often it re-checks whether MFA has become available.

    Look at

    Look for evidence that the lack of MFA was recorded rather than ignored, and that periodic re-checks have actually happened and led to MFA being enabled when providers added it.

    Good evidence

    Documented review dates for each service lacking MFA and at least one example of MFA being switched on after a provider introduced it.

Mappings

Closest match in ASD Essential Eight: E8-MF-ML1.3, Use multi-factor authentication for non-sensitive third-party services, 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: 7 mappings

  • E8-MF-ML1.3Use multi-factor authentication for non-sensitive third-party servicesEquivalent
  • E8-MF-ML1.2Multi-factor authentication for third-party services handling sensitive dataPartially overlaps
  • E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataPartially overlaps
  • E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINPartially overlaps
  • E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially overlaps
  • E8-MF-ML3.2Phishing-resistant multi-factor authentication for online customer servicesPartially overlaps
  • E8-MF-ML2.3Multi-factor authentication online services must be phishing-resistantDepends on

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