ASD ISM 1470 Disable Unneeded Accounts, Components, Services and Application Functionality
What it says
Unneeded user accounts, components, services and functionality of user applications are disabled or removed.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUnneeded user accounts, components, services and functionality within user applications must be disabled or removed so that nothing extra remains available for an attacker to misuse.
Software and systems often ship with far more than your people actually use: spare login accounts, optional add-ons (components), background services, and built-in features inside everyday programs like web browsers, email clients and office software. This control says to switch off or delete anything you do not need. Each of these four areas matters: (1) **user accounts** that are no longer used, such as leftover logins from people who have left or test accounts; (2) **components**, which are optional add-on parts of an application; (3) **services**, which are background processes the software runs; and (4) **functionality of user applications**, meaning specific features inside the programs your staff use day to day. The idea is simple. The fewer accounts, parts and features that exist, the fewer ways there are for an attacker to get in or cause harm. This is often called reducing the "attack surface". A feature that is turned off cannot be exploited, so cleaning out the unused ones makes your systems both tidier and safer.
Free. Save your status, tasks and notes.
Why it matters
Unused accounts, components, services and app features each give attackers an extra way in. Removing them shrinks the attack surface and lowers the chance of a breach.
How to implement
The IT team should build and maintain a list of every user account on each system, then disable or delete any account that no longer belongs to an active, authorised user, including leftover logins from departed staff, test accounts and default vendor accounts.
System owners should review the optional components and add-ons installed with each user application and remove the ones the business does not use, so that only the parts staff actually rely on remain present.
IT administrators should examine the background services each application or system runs and stop any that are not needed for the way your organisation uses that software, reducing the number of running processes that could be targeted.
Whoever configures the standard build for user applications such as web browsers, email clients and office suites should turn off built-in features that are not required, for example unused scripting, automatic content downloads or legacy file formats, and apply that hardened configuration to every machine.
IT should record this hardened baseline in a documented standard and re-check accounts, components, services and application features whenever software is updated or a new version is rolled out, because updates can quietly re-enable things that were previously switched off.
Keep it running
Treat this as ongoing, not a one-off. Re-check accounts, components, services and application features after every software update, since upgrades can re-enable items you previously removed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
how the organisation identifies and removes unneeded user accounts.
Look at
a current account list with disabled or deleted entries tied to departures, test accounts and default accounts.
Good evidence
shows accounts are reviewed on a schedule and removed promptly with records kept.
- Check 2 of 5What an auditor asks for
Ask for
which optional components of user applications have been removed and why.
Look at
documentation listing the components removed from each application.
Good evidence
explains that only components the business actually uses remain installed.
- Check 3 of 5What an auditor asks for
Ask for
what background services have been disabled and how that decision was made.
Look at
a list of stopped services with a reason for each.
Good evidence
ties each disabled service to it not being needed for business use.
- Check 4 of 5What an auditor asks for
Ask for
to see the hardened configuration applied to user applications such as browsers, email clients and office software.
Look at
a documented standard that turns off unneeded built-in features.
Good evidence
shows the same hardened settings applied consistently across all machines.
- Check 5 of 5What an auditor asks for
Ask for
how the four areas are kept clean after software updates.
Look at
evidence that accounts, components, services and application features are re-checked after upgrades.
Good evidence
shows updates do not silently re-enable removed items.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML1.1, Disable or remove Internet Explorer 11, which this control covers in full and more.
ASD Essential Eight: 5 mappings
This control is broader than E8-AH-ML1.1.
ISM-1470 requires disabling or removing unneeded components, services and functionality in common applications to minimise exploitable features. E8-AH-ML1.1 aligns by mandating that Internet Explorer 11 is disabled or removed, which is a clear example of removing an unneeded/legacy browser component. E8-AH-ML1.1 is a single-product requirement, whereas ISM-1470 covers a wider set of applications and their internal functions and services.
This control is broader than E8-AH-ML3.1.
ISM-1470 requires unneeded components, services and functionality across common user applications (e.g. office suites, browsers, email clients, PDF software and security products) to be disabled or removed to reduce attack surface. E8-AH-ML3.1 is a specific instance of this approach by requiring legacy .NET Framework versions (3.5/3.0/2.0) to be disabled or removed. E8-AH-ML3.1 is narrower and technology-specific, while ISM-1470 is broader and applies across multiple application classes and their optional features/services.
This control is broader than E8-AH-ML3.2.
E8-AH-ML3.2 requires organisations to disable or remove Windows PowerShell 2.0 specifically. ISM-1470 requires disabling or removing unneeded components, services and functionality across multiple application types as part of general hardening. Disabling PowerShell 2.0 is a concrete instance of removing an unneeded/unsafe legacy function, but ISM-1470 is broader in scope than E8-AH-ML3.2.
This control partially overlaps E8-AH-ML2.1.
E8-AH-ML2.1 focusses on hardening web browsers using the most restrictive guidance. In comparison, ISM-1470 mandates that unnecessary components, services, and functionality must be disabled or removed. This control specifically aims to reduce attack surfaces, which E8-AH-ML2.1 also accomplishes by setting comprehensive hardening baselines.
This control partially overlaps E8-AH-ML2.9.
E8-AH-ML2.9 requires PDF software to be hardened using ASD and vendor hardening guidance, applying the most restrictive guidance where there is conflict. ISM-1470 relates by requiring unneeded components, services and functionality of PDF applications (along with other application types) to be disabled or removed, which is a common hardening activity included in PDF hardening baselines. E8-AH-ML2.9 is broader in that it covers the full set of hardening settings derived from guidance (not just removing/ disabling features), while ISM-1470 is broader in application scope (multiple software classes) but narrower in the specific hardening technique it mandates.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.