Skip to content
System hardening
ASD ISMISM-2128

ASD ISM 2128 Limit kernel-mode code installation to privileged users who need it

What it says

The ability to install, load or modify kernel-mode code, including drivers, kernel modules and extensions, is limited to privileged users who require such abilities as part of their duties or functions.

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

What it means

In plain English

Only privileged users whose duties require it can install, load or modify drivers, kernel modules and extensions, keeping ordinary accounts away from the core of the operating system.

The kernel is the core of an operating system. It runs with the highest level of trust, and anything that runs inside it (drivers, kernel modules, kernel extensions) inherits that trust. Code at this level can read any memory, intercept any process, disable security tooling and hide itself from the operating system, which is why rootkits and many advanced attacks aim for it. This control says that the ability to install, load or modify kernel-mode code must be limited to privileged users, and even then only to those who genuinely need it for their duties or functions. A standard user account should never be able to add a driver or load a module. A privileged account should only be able to do so when that person's role actually involves it, for example a platform engineer who maintains hardware drivers, rather than every administrator by default. Why it matters: if a user, or malware running as that user, can load kernel-mode code, then every other security control on that device can be bypassed or switched off. Restricting who can touch the kernel closes one of the most powerful pathways an attacker can take once they have a foothold on a system.

Why it matters

If kernel-mode code can be installed, loaded or modified by users who are not privileged, or by privileged users who have no need for it, an attacker who compromises any of those accounts can load a malicious driver or module and take complete control of the device. Kernel-level malware can disable endpoint protection, tamper with logging, hide processes and files, and persist through reboots, making detection and clean-up extremely difficult. Unwanted or poorly tested drivers loaded by unauthorised staff can also destabilise systems and cause outages. Widely granted kernel modification rights turn a single compromised account into a full compromise of the operating system.

How to implement

  1. The security or platform lead defines which roles genuinely require the ability to install, load or modify kernel-mode code, by listing the duties (such as hardware driver maintenance or kernel module management) that depend on it and documenting the approved roles.

  2. System administrators configure each operating system so that standard users cannot install drivers, load kernel modules or load kernel extensions, using platform controls such as Windows driver installation policies, Linux module loading restrictions and macOS kernel or system extension approval settings.

  3. Identity or access administrators create a dedicated privileged group for kernel-mode code changes, separate from general administrator groups, and grant membership only to individuals in the approved roles following a documented access request.

  4. The platform team removes driver installation, module loading and extension loading rights from general administrator roles, so that privileged users outside the approved roles cannot install, load or modify kernel-mode code, and requires members of the dedicated group to perform such changes through the normal change process.

  5. Access governance staff run a periodic review of the kernel-mode change group, confirm each member still holds an approved role, and remove anyone whose duties have changed, with removals also triggered by the leaver and role-change process.

Keep it running

Day to day, this control lives in how privileged access is granted and how operating systems are configured.

  • Keep a short, named list of roles whose duties require installing, loading or modifying kernel-mode code (drivers, kernel modules, extensions). Membership in these roles should be justified against the person's job, not granted with general administrator access.
  • Configure operating systems so that driver installation, module loading and extension loading are denied to standard users and to privileged accounts outside those roles. Use the platform's own mechanisms, such as user rights assignments, module loading restrictions, kernel extension approval policies and administrative policy settings, to limit these actions to the approved roles.
  • Route legitimate driver and module changes through the normal change process so that the privileged user with the required role performs the change, rather than sharing that capability more widely to speed things up.
  • When staff change role or leave, remove them from the kernel modification roles at the same time as other access is adjusted.
  • Review the role membership on a regular cycle and remove anyone whose duties no longer require it.
  • Monitor for driver or module load events by accounts outside the approved roles and treat them as a security event.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the documented list of roles and individuals permitted to install, load or modify kernel-mode code, including drivers, kernel modules and extensions.

    Look at

    Check that each role has a stated duty or function that requires kernel-mode changes, and that the individuals listed actually hold those roles.

    Good evidence

    A short, current list where every member is a privileged user with a clear job-related need, and no blanket inclusion of all administrators.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the operating system configuration or policy settings that restrict driver installation, kernel module loading and kernel extension loading.

    Look at

    Look at the actual settings on sampled Windows, Linux and macOS systems to confirm standard users are blocked and that only the approved privileged group is permitted.

    Good evidence

    Enforced technical settings on all sampled systems that match the documented role list, rather than reliance on procedure alone.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the access request and approval records for recent additions to the group that can modify kernel-mode code.

    Look at

    Check that each addition references the person's duties and was approved by someone accountable for the platform or security.

    Good evidence

    Every recent grant is tied to a documented need and an approval, with no self-granted or undocumented additions.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the most recent periodic review of privileged users with kernel-mode modification rights, and the leaver or role-change records for the same period.

    Look at

    Compare the group membership before and after the review, and check that people who changed role or left were removed promptly.

    Good evidence

    Evidence of a completed review with removals actioned, and no former staff or people in unrelated roles still holding the capability.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for driver, module or extension load and installation logs from a sample of systems over a recent period.

    Look at

    Check which accounts performed kernel-mode changes and compare them against the approved role list.

    Good evidence

    All recorded kernel-mode changes were made by accounts in the approved privileged group, and any exceptions were investigated.

Mappings

Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.5.15Access control policies and proceduresPartially meets
  • A.8.2Management of privileged access rightsPartially meets
Essential Eight

ASD Essential Eight: 1 mapping

  • E8-RA-ML3.1Limit privileged access to what is necessary for dutiesPartially meets

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