ASD ISM 2128Limit Kernel-Mode Code Installation to Privileged Users Who Need It
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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
Operating system hardeningTopic
Hardening operating system configurations
Official control statement
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.
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.
Operational notes
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.
Implementation tips
- 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.
- 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.
- 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.
- 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.
- 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.
Audit / evidence tips
- AskAsk for the documented list of roles and individuals permitted to install, load or modify kernel-mode code, including drivers, kernel modules and extensions.Look atCheck that each role has a stated duty or function that requires kernel-mode changes, and that the individuals listed actually hold those roles.GoodA short, current list where every member is a privileged user with a clear job-related need, and no blanket inclusion of all administrators.
- AskAsk for the operating system configuration or policy settings that restrict driver installation, kernel module loading and kernel extension loading.Look atLook 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.GoodEnforced technical settings on all sampled systems that match the documented role list, rather than reliance on procedure alone.
- AskAsk for the access request and approval records for recent additions to the group that can modify kernel-mode code.Look atCheck that each addition references the person's duties and was approved by someone accountable for the platform or security.GoodEvery recent grant is tied to a documented need and an approval, with no self-granted or undocumented additions.
- AskAsk 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 atCompare the group membership before and after the review, and check that people who changed role or left were removed promptly.GoodEvidence of a completed review with removals actioned, and no former staff or people in unrelated roles still holding the capability.
- AskAsk for driver, module or extension load and installation logs from a sample of systems over a recent period.Look atCheck which accounts performed kernel-mode changes and compare them against the approved role list.GoodAll recorded kernel-mode changes were made by accounts in the approved privileged group, and any exceptions were investigated.
Cross-framework mappings
How ISM-2128 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(2)expand_less | ||
| Annex A 5.15 | ISM-2128 requires an explicit access rule that limits kernel-mode code installation/loading/modification to authorised privileged users w... | |
| Annex A 8.2 | ISM-2128 requires limiting the ability to install, load or modify kernel-mode code to privileged users who need it for their functions | |
E8
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| E8-RA-ML3.1 | ISM-2128 requires that installing, loading or modifying kernel-mode code is restricted to privileged users with a duty-based need | |
handshakeSupports(2)expand_less | ||
| E8-RA-ML1.1 | ISM-2128 restricts kernel-mode code changes to privileged users with a business need | |
| E8-RA-ML2.7 | ISM-2128 limits who can install, load or modify kernel-mode code, often implemented via privileged group membership | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.