ASD ISM 1679Multi-factor Authentication for Third-party Services Handling Sensitive Data
Official control statement
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.
In plain English
Staff 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.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
ML1, ML2, ML3
Guideline
Guidelines for system accessTopic
Multi-factor authentication
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk 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 atCheck 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.GoodA 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.
- AskAsk for screenshots or exported configuration from the admin console of each in-scope service showing the multi-factor authentication setting.Look atLook 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.GoodEvery in-scope service shows MFA as mandatory for all human users, with no unrestricted password-only login path remaining.
- AskAsk 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 atCompare 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.GoodAll active human accounts are enrolled in a second factor, and any exceptions are few, documented and time-limited.
- AskAsk for the joiner, mover and leaver procedure and a sample of recent new-starter records for access to an in-scope service.Look atCheck 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.GoodThe procedure requires enrolment before access, and the sampled records show it was followed without gaps.
- AskAsk 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 atLook 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.GoodExceptions are rare, approved, tracked to closure, and the recovery process includes an identity check before a new factor is registered.
Cross-framework mappings
How ISM-1679 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.5 | ISM-1679 specifically requires MFA for users authenticating to third-party online services that process, store, or communicate the organi... | |
handshakeSupports(1)expand_less | ||
| Annex A 5.17 | ISM-1679 requires MFA for human users accessing third-party online services that handle sensitive organisational data | |
E8
| Control | Notes | Details |
|---|---|---|
equalEquivalent(1)expand_less | ||
| E8-MF-ML1.2 | ISM-1679 requires multi-factor authentication for human users accessing third-party online services that process, store or communicate th... | |
sync_altPartially overlaps(4)expand_less | ||
| E8-MF-ML1.1 | E8-MF-ML1.1 requires MFA for users authenticating to the organisation's online services that handle sensitive organisational data | |
| E8-MF-ML1.5 | ISM-1679 requires multi-factor authentication (MFA) for human users accessing third-party online services that process, store or communic... | |
| E8-MF-ML1.7 | E8-MF-ML1.7 requires MFA to combine two factors (possession plus knowledge/biometric unlock) | |
| E8-MF-ML3.3 | ISM-1679 requires MFA for human access to third-party online services that process, store or communicate sensitive organisational data | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.