Skip to content
System access
ASD ISMISM-1173

ASD ISM 1173 Multi-factor authentication for privileged human users of systems

What it says

Multi-factor authentication is used to authenticate privileged human users of systems.

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

What it means

In plain English

Every person who holds privileged access to a system must prove who they are with more than a password before that access is granted.

Privileged users are the people who can change how a system works: administrators, engineers with root or domain-level rights, database owners, cloud console owners and anyone else whose account can alter configuration, security settings or other people's access. This control requires that when such a person logs in to a system, they are authenticated with multi-factor authentication (MFA), meaning at least two different types of proof, such as something they know (a password or PIN), something they have (a hardware security key, smart card or authenticator app) or something they are (a biometric). Why it matters: privileged accounts are the most valuable target an attacker can take. A stolen or guessed administrator password gives an intruder the same reach as your most trusted staff. Phishing, credential-stuffing from earlier breaches, malware that logs keystrokes and simple password reuse all defeat a password on its own. MFA breaks that chain, because the attacker also needs the second factor, which is far harder to obtain remotely. The control applies to human users specifically, so the focus is on interactive logins by people, not on service or machine accounts, and it applies to privileged access to systems generally, not just to one platform.

Why it matters

If privileged human users can authenticate with a password alone, a single phished, reused or leaked credential hands an attacker full administrative control. From there they can disable logging, create backdoor accounts, exfiltrate data, deploy ransomware across the environment or alter security settings, and the compromise is likely to go undetected for longer because the activity looks like legitimate administration. The organisation would also fail to meet the ISM's requirement for privileged authentication and be unable to demonstrate a basic safeguard expected by auditors, insurers and customers.

How to implement

  1. Identity and access owner: build and maintain an inventory of every system and every account or role that carries privileged rights, by exporting admin group memberships from directories, cloud tenants, network devices, databases and SaaS admin portals, so the scope of enforcement is known.

  2. Platform administrators: turn on MFA enforcement (not just availability) for privileged accounts in each system's native controls, for example conditional access policies for directory admins, MFA on cloud console root and IAM admin roles, and MFA-backed authentication on network device management interfaces.

  3. Security architects: route privileged access to systems that cannot enforce MFA natively through a jump host, bastion or privileged access management tool that performs MFA before brokering the session, so every privileged human login passes through a factor check.

  4. Security team: choose and issue phishing-resistant or at least app-based second factors (hardware security keys, smart cards, platform authenticators or authenticator apps) to all privileged users, and disable weaker options such as SMS codes for these accounts where the platform allows it.

  5. Service desk and IAM team: document and run a secure enrolment and recovery process so that new privileged users are issued a second factor before their rights are activated, lost tokens are replaced only after identity verification, and no temporary bypass leaves an account on password-only access.

Keep it running

Day to day, this control lives in the identity and access management function. Someone needs to own the definition of which accounts and roles count as privileged, keep that list current as systems are added or roles change, and make sure each of those systems (directories, servers, network devices, cloud consoles, hypervisors, databases, SaaS admin portals, backup tools) enforces MFA for privileged logins rather than merely offering it. Joiner, mover and leaver processes should provision and revoke second factors alongside the privileged account itself. Helpdesk staff will handle lost or broken tokens, so a secure re-enrolment process is needed that does not quietly fall back to password-only access. Expect periodic exceptions to be requested for legacy systems that cannot natively enforce MFA; these should be handled by fronting the system with a jump host, privileged access management (PAM) tool or gateway that does enforce it, or by documenting a risk-accepted exception with a remediation date. Monitoring should flag any privileged login that occurred without MFA, since that usually signals a misconfiguration or an unmanaged system.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the current inventory of privileged accounts and roles across all in-scope systems, together with a statement of who owns and maintains it.

    Look at

    Check that the inventory covers directories, servers, cloud consoles, network devices, databases and SaaS admin portals, and that it has been updated recently.

    Good evidence

    A complete, dated inventory exists, is owned by a named person or team, and matches what the systems themselves report when spot-checked.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the MFA enforcement configuration for privileged accounts on a sample of systems, such as conditional access policies, cloud IAM settings or PAM policies.

    Look at

    Confirm the policy is set to require MFA for privileged logins with no exclusions or bypass groups, rather than simply making MFA optional.

    Good evidence

    Each sampled system shows an enforced rule that applies to all privileged human accounts, and any exclusion group is empty or justified in writing.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for authentication logs for privileged users over a recent period.

    Look at

    Look for privileged sign-ins and check whether each one records a completed second-factor step.

    Good evidence

    Every privileged login in the sample shows MFA was satisfied, and any password-only entries have been investigated and explained.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask how privileged access is handled for systems that cannot enforce MFA natively, such as legacy appliances or older applications.

    Look at

    Review the jump host, bastion or PAM configuration that fronts those systems, or the documented risk acceptance if one exists.

    Good evidence

    Legacy systems are reachable for administration only through an MFA-protected path, or a formally approved exception with a remediation date is on file.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the enrolment and token recovery procedure for privileged users and evidence of it being followed.

    Look at

    Check that a second factor is issued before privileged rights are activated and that recovery requires identity verification without leaving the account password-only.

    Good evidence

    Recent onboarding and recovery tickets show factors issued or replaced through the documented process, with no standing bypass.

Mappings

Closest match in ASD Essential Eight: E8-MF-ML2.1, Multi-factor authentication for privileged users of systems, 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: 5 mappings

  • E8-MF-ML2.1Multi-factor authentication for privileged users of systemsEquivalent
  • E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially meets
  • E8-MF-ML2.3Multi-factor authentication online services must be phishing-resistantPartially overlaps
  • E8-MF-ML3.1Multi-factor authentication is used to authenticate users of data repositoriesPartially overlaps
  • E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINSupports

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