Skip to content
System access
ASD ISMISM-1892

ASD ISM 1892 Multi-factor authentication for organisation users of online customer services

What it says

Multi-factor authentication is used to authenticate human users to their organisation's 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, administrators and support agents who sign in to the organisation's own online customer services handling sensitive customer data must use multi-factor authentication, not a password alone.

This control is about the organisation's own people, not its customers. When a staff member, administrator, support agent or other human user of the organisation signs in to an online customer service that the organisation operates, and that service processes, stores or communicates sensitive customer data, they must prove who they are with multi-factor authentication (MFA). That means something more than a password, such as an authenticator app, a security key or a smartcard, combined with the password. The sibling control ISM-1173 deals with customers logging in to online customer services. ISM-1892 covers the other side of the same service: the organisation's personnel who reach the back end, administration console, case management or support tooling of that service. It matters because these users typically see far more than any single customer does. A support agent or administrator can often look up many customer records, change account details or export data. A password alone can be phished, guessed or reused from another breach, and an attacker who obtains it gains that same broad reach. Requiring a second factor means a stolen password by itself is not enough to get in.

Why it matters

If the organisation's staff, administrators or support agents can reach online customer services holding sensitive customer data with only a password, a single phished, reused or guessed credential gives an attacker the same wide access that user has. That can expose many customers' records at once, allow bulk export of sensitive customer data, enable changes to customer accounts from a trusted internal position, and lead to notifiable data breach obligations, regulatory action and loss of customer trust.

How to implement

  1. The security or identity team compiles an inventory of the organisation's online customer services that process, store or communicate sensitive customer data, and for each one records how staff, administrators and support agents authenticate (corporate single sign-on, local service accounts, vendor portal logins).

  2. The identity administrator configures a conditional access or authentication policy in the corporate identity provider that requires multi-factor authentication for every user group or role granted access to those customer services, and assigns the customer service applications to that policy.

  3. The service owner enables built-in MFA on any customer service that keeps its own local administrator or agent accounts, then disables or migrates any local account that cannot use a second factor so no password-only path to sensitive customer data remains.

  4. The onboarding or service desk team adds MFA enrolment (authenticator app, security key or smartcard) as a mandatory step in the access request process for these services, so a new staff member or support agent cannot be granted access until their second factor is registered.

  5. The identity administrator disables legacy authentication protocols and password-only fallback options on these services, configures a verified re-enrolment procedure for lost or replaced factors, and sets up logging or alerting for sign-ins to customer services that complete without MFA.

Keep it running

In day-to-day operation this control shows up in how the organisation's own people get into its customer-facing services and the systems behind them.

  • **Know which services are in scope.** Maintain a list of the online customer services the organisation operates that process, store or communicate sensitive customer data, together with every path by which organisation users authenticate to them (administration consoles, agent desktops, case management tools, content or configuration portals, support impersonation features).
  • **Enforce MFA at the identity provider or the service itself.** Where these services use the corporate identity provider (single sign-on), apply a policy that requires MFA for the groups or roles that access them. Where a service has its own local accounts for administrators or agents, turn on MFA within that service and treat any local account that cannot do MFA as an exception to be removed.
  • **Cover joiners, movers and leavers.** Provisioning a staff member, contractor or support agent into a customer service should include enrolling their second factor before access is granted. Role changes should re-check that MFA still applies to the new role.
  • **Handle lost or reset factors through the service desk.** Have a verified process for re-enrolling a user who loses a phone or hardware token, so that MFA is not quietly bypassed by issuing a password-only login "temporarily".
  • **Watch for bypasses.** Review MFA exclusions, break-glass accounts, legacy authentication protocols and API keys used by humans, and ensure they do not become a password-only route into sensitive customer data.
  • **Confirm coverage periodically.** Review the accounts that can reach these services and confirm each human user has MFA enforced, not just enrolled.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask the organisation to list its online customer services that process, store or communicate sensitive customer data, and to identify the internal user groups (staff, administrators, support agents) that access each one.

    Look at

    The inventory of in-scope services and the mapping of organisation users and roles to those services, including administration consoles and support tooling.

    Good evidence

    A current inventory exists, each in-scope service is identified, and every internal access path for human users is named rather than only the customer-facing login.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask how MFA is enforced for organisation users of those services, and request the identity provider or application policy that does so.

    Look at

    Conditional access or authentication policy configuration showing MFA required for the relevant groups or roles, and the customer service applications assigned to that policy.

    Good evidence

    MFA is required, not merely available, for all organisation user groups that can reach the in-scope services, with no blanket exclusions.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask whether any in-scope service has its own local administrator, agent or support accounts outside single sign-on, and how MFA applies to them.

    Look at

    The service's local account list and its MFA settings, plus any exception register for accounts that cannot use a second factor.

    Good evidence

    Local human accounts have MFA enabled within the service, and any account unable to use a second factor has been disabled or migrated, so no human user reaches sensitive customer data without MFA; any remaining password-only local account is a finding, not an accepted exception.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for a sample of recent sign-ins by staff or support agents to an in-scope customer service.

    Look at

    Identity provider or application sign-in logs for the sampled users showing the authentication methods used.

    Good evidence

    Every sampled sign-in by an organisation user shows a second factor was satisfied; no password-only sessions appear.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask how a staff member or support agent is given access to a customer service and what happens when they lose their second factor.

    Look at

    The access provisioning procedure and the service desk process for re-enrolling a lost or replaced factor, with a recent example of each.

    Good evidence

    MFA enrolment is a prerequisite for access being granted, and re-enrolment requires identity verification rather than a temporary password-only login.

Mappings

Closest match in ASD Essential Eight: E8-MF-ML1.4, Use multi-factor authentication for online services handling 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: 6 mappings

  • E8-MF-ML1.4Use multi-factor authentication for online services handling customer dataEquivalent
  • E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataEquivalent
  • E8-MF-ML1.1Require multi-factor authentication for sensitive online servicesPartially meets
  • E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataPartially overlaps
  • E8-MF-ML2.3Multi-factor authentication online services must be phishing-resistantPartially overlaps
  • E8-MF-ML2.6MFA success and failure events are centrally loggedSupports

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