ASD ISM 1679 Multi-factor authentication for third-party services handling sensitive data
What it says
Multi-factor authentication is used to authenticate human users to third-party online services that process, store or communicate their organisation's sensitive data.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishStaff logging in to external online services that handle your sensitive data must prove who they are with more than a password, so a stolen credential alone cannot open the account.
Most organisations now hand sensitive data to online services run by someone else: payroll and HR platforms, cloud file storage, customer relationship systems, accounting software, email marketing tools, ticketing systems and many more. Each of these is reached through a login page on the internet, which means anyone in the world who obtains a staff member's password can attempt to sign in as them. This control requires that when a person (as opposed to an automated system account) signs in to any third-party online service that processes, stores or communicates the organisation's sensitive data, they must use multi-factor authentication. That means a password alone is not enough; the person must also present a second factor, such as a code from an authenticator app, a hardware security key or a push approval on a registered device. It matters because passwords are routinely stolen through phishing, credential-stuffing from other breaches, malware and simple reuse. The organisation does not control the third party's login page, network or monitoring, so the strength of the login itself is the main defence it can apply. Multi-factor authentication means a leaked password is no longer sufficient to reach the data. The scope is deliberately broad: it covers every third-party online service that touches sensitive data, not just the well-known ones. Shadow IT, departmental tools and trial subscriptions are in scope if sensitive data ends up in them.
Free. Save your status, tasks and notes.
Why it matters
If human users can reach third-party online services holding sensitive data with only a password, one successful phishing email or a credential reused from an unrelated breach gives an attacker the same access as the legitimate user. Because the service sits outside the organisation's network, the intrusion is unlikely to be seen by internal defences, and the attacker can read, download, alter or delete sensitive records, send messages as the user, or pivot to other services through password resets. The likely consequences are a reportable data breach, regulatory and contractual exposure, financial loss and lasting reputational damage, with the organisation often learning of the compromise only when the data appears elsewhere.
How to implement
IT or security staff: build and maintain a register of every third-party online service the organisation uses, and for each one record whether it processes, stores or communicates sensitive data.
Do this by combining procurement records, finance and expense data for software subscriptions, identity provider application lists and a short survey of business units, so that departmental and trial tools are captured alongside the major platforms.
Service administrators: for every in-scope service, turn on multi-factor authentication as a mandatory, tenant-wide setting in the service's security or admin console, rather than leaving it as a per-user option.
Where the service offers it, block legacy or basic authentication paths that would let a password-only login bypass the requirement.
Identity or IT staff: where a third-party service supports single sign-on, connect it to the organisation's identity provider and apply an MFA policy there, so that one enforced policy covers many services and users enrol one set of factors instead of many.
Confirm that direct local logins to the service are disabled or also require MFA.
Service owners with IT support: run an enrolment campaign for existing human users, giving each person a deadline and instructions to register a second factor, then use the service's admin reporting to identify accounts still without MFA and follow up or suspend them until enrolment is complete.
Build MFA enrolment into the joiner process so new users cannot receive access to an in-scope service before registering a factor.
Procurement and security staff: add support for multi-factor authentication to the requirements for any new third-party online service that will handle sensitive data, and check it during vendor evaluation.
For existing services that cannot support MFA, raise a documented exception, assess whether sensitive data should stay in that service, and set a date to migrate or remediate.
Keep it running
Day to day, this control lives in three places: knowing which third-party services hold sensitive data, keeping multi-factor authentication switched on and enforced in each of them, and making sure every human account is actually enrolled.
- Keep a register of third-party online services and mark which ones process, store or communicate sensitive data. Add new services as they are procured or discovered, including free and trial subscriptions signed up for by individual teams.
- For each in-scope service, enforce multi-factor authentication at the tenant or organisation level rather than relying on individual users to opt in. Where the service supports single sign-on through the corporate identity provider, route logins through it so one MFA policy applies consistently.
- Treat onboarding and offboarding as MFA events. New users must enrol a second factor before they receive access to the service, and departing users' factors and accounts are removed.
- Handle lost or replaced devices through a defined re-enrolment process that verifies the person's identity before a new factor is registered, so recovery does not become a bypass.
- When a service cannot support multi-factor authentication, record it as a gap, decide whether sensitive data should remain in that service, and track the exception until it is resolved.
- Periodically confirm enforcement by pulling the user list and MFA enrolment status from each in-scope service, and chase any human accounts that are not enrolled.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register or list of third-party online services and how each one was assessed for whether it handles the organisation's sensitive data.
Look at
Check that the register is recent, that the sensitive-data classification is recorded per service, and that it was built from more than one source (for example procurement, finance and the identity provider) so smaller or departmental tools are included.
Good evidence
A maintained register that clearly identifies every in-scope service, shows who owns it, and has been updated within the last review cycle with new services added.
- Check 2 of 5What an auditor asks for
Ask for
Ask for screenshots or exported configuration from the admin console of each in-scope service showing the multi-factor authentication setting.
Look at
Look for MFA being enforced at the organisation or tenant level for all human users, not merely enabled as an optional feature, and for any legacy or basic authentication paths being disabled.
Good evidence
Every in-scope service shows MFA as mandatory for all human users, with no unrestricted password-only login path remaining.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a current user list from each in-scope service, or from the identity provider where single sign-on is used, showing the MFA enrolment status of each human account.
Look at
Compare the enrolled accounts against the full list of human users and identify any that are active but not enrolled, including recently created accounts and administrators.
Good evidence
All active human accounts are enrolled in a second factor, and any exceptions are few, documented and time-limited.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the joiner, mover and leaver procedure and a sample of recent new-starter records for access to an in-scope service.
Look at
Check whether MFA enrolment is a prerequisite for granting access rather than a follow-up task, and whether the sampled new starters were enrolled before or at the time access was provisioned.
Good evidence
The procedure requires enrolment before access, and the sampled records show it was followed without gaps.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the exceptions list covering any third-party services that hold sensitive data but do not enforce multi-factor authentication, along with the lost-device or factor re-enrolment procedure.
Look at
Look for a documented reason, an approver, a remediation date and progress for each exception, and confirm the re-enrolment procedure verifies identity so that recovery cannot be used to bypass MFA.
Good evidence
Exceptions are rare, approved, tracked to closure, and the recovery process includes an identity check before a new factor is registered.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML1.2, Multi-factor authentication for third-party services handling sensitive data, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.5.
ISM-1679 specifically requires MFA for users authenticating to third-party online services that process, store, or communicate the organisation's sensitive data. ISO/IEC 27001:2022 Annex A 8.5 requires implementing secure authentication technologies and procedures more generally, based on access restrictions and access control policy. ISM-1679 is a specific instantiation of secure authentication (MFA) for a defined scenario (third-party services handling sensitive data), so it is narrower than Annex A 8.5.
This control supports A.5.17.
ISM-1679 requires MFA for human users accessing third-party online services that handle sensitive organisational data. ISO/IEC 27001:2022 Annex A 5.17 focuses on controlling the allocation and management of authentication information (e.g., enrolment, distribution, handling and user guidance). Annex A 5.17 supports ISM-1679 by ensuring MFA credentials and related authentication information are securely issued and managed, but it does not itself mandate MFA for third-party services.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-MF-ML1.2.
ISM-1679 requires multi-factor authentication for human users accessing third-party online services that process, store or communicate the organisation's sensitive data. E8-MF-ML1.2 states the same requirement for users authenticating to third-party online services handling the organisation's sensitive data. The scope and intent align closely enough that implementing E8-MF-ML1.2 would largely satisfy ISM-1679 and vice versa.
This control partially overlaps E8-MF-ML1.1.
E8-MF-ML1.1 requires MFA for users authenticating to the organisation's online services that handle sensitive organisational data. ISM-1679 relates by requiring MFA for users authenticating to third-party online services that process, store or communicate the organisation's sensitive data. The overlap is MFA for access to online services handling sensitive organisational data, but ISM-1679 focuses on third-party services whereas E8-MF-ML1.1 is framed around the organisation's own online services.
- E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataPartially overlaps
This control partially overlaps E8-MF-ML1.5.
ISM-1679 requires multi-factor authentication (MFA) for human users accessing third-party online services that process, store or communicate the organisation's sensitive data. E8-MF-ML1.5 is closely aligned but is scoped to third-party online customer services handling sensitive customer data, which is a specific subset of third-party services and data types. The overlap is strong on the MFA requirement for third-party services, but ISM-1679 is broader in the types of third-party services and sensitive data it covers.
- E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINPartially overlaps
This control partially overlaps E8-MF-ML1.7.
E8-MF-ML1.7 requires MFA to combine two factors (possession plus knowledge/biometric unlock). ISM-1679 requires using MFA to authenticate users to third-party online services that handle the organisation's sensitive data, relying on a correct MFA implementation. ISM-1679 is scoped to third-party services and sensitive data handling, whereas E8-MF-ML1.7 is a general MFA composition requirement independent of service ownership.
This control partially overlaps E8-MF-ML3.3.
ISM-1679 requires MFA for human access to third-party online services that process, store or communicate sensitive organisational data. E8-MF-ML3.3 requires phishing-resistant MFA specifically for users of data repositories, which can include repositories holding sensitive data. The overlap is that both require MFA for protecting access to sensitive information environments, but ISM-1679 is scoped to third-party online services while E8-MF-ML3.3 is scoped to repository systems and specifies phishing resistance.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.