ASD ISM 1825 Lock security product settings against changes by human users
What it says
Security product security settings cannot be changed by human users.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSecurity products must be locked so that no person can alter their security settings, keeping protections such as antivirus, EDR and host firewalls intact even if a user or attacker tries to weaken them.
Security products are the tools that protect a system: antivirus and endpoint detection and response (EDR) agents, host-based firewalls, application control, email and web filtering, and similar software. Each of these has security settings that decide how strongly it protects the system: whether real-time scanning is on, which exclusions apply, whether the agent can be paused or uninstalled, and what gets blocked. This control requires that those security settings cannot be changed by human users. A person sitting at the device, whether a staff member, a contractor, or an attacker who has taken over an account, should not be able to open the product and switch protections off, add exclusions, or weaken policy. In practice this means the settings are locked from human interaction (for example through tamper protection and centrally enforced policy) so that a person cannot directly alter them. Why it matters: the first thing many attackers and much malware do after landing on a device is try to disable or blind the security tools, then operate freely. Users under pressure also weaken settings for convenience, adding exclusions or turning off scanning to make something work, and then forget to restore them. If the settings cannot be changed by a human, these paths are closed and the security product keeps doing its job regardless of who is logged in.
Free. Save your status, tasks and notes.
Why it matters
If human users can change the security settings of security products, an attacker who compromises an account, or a user who simply wants to remove an inconvenience, can disable scanning, add exclusions, stop the agent, or turn off blocking. Once that happens the organisation loses the visibility and protection it believes it has: malware runs undetected, lateral movement goes unblocked, and alerts stop flowing to the security team. Because the weakening is done through the product's own interface it can look legitimate and go unnoticed for a long time, so the organisation may not discover the gap until after an incident. The result is a false sense of security and a much larger blast radius when something does get through.
How to implement
Security product administrators enable the product's tamper protection or settings-lock feature (such as anti-tamper in EDR and antivirus platforms) on every managed device, so that no person at the device can disable protection, stop the agent, or edit its settings.
Endpoint engineers apply security product configuration only through the central management console or configuration management policy, and set the policy to enforce mode so any setting changed locally is immediately reverted.
System administrators remove or hide the local settings interface of each security product for all human accounts, including local administrators, by disabling the local user interface, blocking the product's settings pages, and removing local override permissions.
The security team maintains an inventory of security products in use (antivirus, EDR, host firewall, application control, email and web filters) and, for each one, records which feature locks its security settings so that no product is left with human-editable settings.
Security operations configures alerting on the security product's tamper, uninstall and settings-change events, and includes a check of tamper protection status in the build and upgrade process so the lock is re-verified after every product update or image refresh.
Keep it running
Day to day, this control lives in how security products are configured and managed rather than in a process people follow. Whoever administers each security product (endpoint protection, host firewall, application control, mail and web filtering) keeps tamper protection, policy locking, or the equivalent feature enabled, and confirms that local consoles, settings panels and command-line interfaces on the endpoint do not allow a person to change security settings.
Any legitimate change to security settings is made in the central management platform as a policy change, never by a person editing settings on an individual device. Treat requests to "just add an exclusion on my machine" or "turn off scanning for a moment" as change requests handled centrally, not as something a user or local administrator does themselves.
Watch for drift when products are upgraded, when new products are introduced, or when a build image is refreshed, because tamper protection and locked-settings features can be reset to defaults. Monitor the product's own events for attempted changes to settings, uninstall attempts, or agent stops, as these are useful signals of both misconfiguration and active attack. When a locked setting genuinely gets in the way of work, fix it through the central policy so that the lock stays in place for everyone.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of security products deployed on the system and, for each, a description of how its security settings are protected from being changed by people.
Look at
Check that every product on the list has a named locking mechanism, such as tamper protection or enforced central policy, rather than a generic statement that only administrators have access.
Good evidence
Every security product has a specific, documented mechanism that stops any human user, including local administrators, from altering its security settings.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see the central management console policy for a major security product, such as the EDR or antivirus platform.
Look at
Look for tamper protection or settings lock switched on, policy set to enforce rather than audit, and local override or user interface editing disabled in the policy assigned to production devices.
Good evidence
Tamper protection is enabled and enforced for all device groups, and the policy explicitly blocks local changes to security settings.
- Check 3 of 5What an auditor asks for
Ask for
Ask to observe a standard user account and a local administrator account attempting to change a security setting on a live device, for example adding an exclusion or pausing real-time protection.
Look at
Watch whether the settings are greyed out, blocked, or automatically reverted, and whether the product records the attempt.
Good evidence
Neither account can change the security setting, the change is blocked or reverted immediately, and the attempt appears in the product's event log.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a compliance or health report from the security product showing tamper protection or settings-lock status across the device fleet.
Look at
Compare the number of devices reported as protected with the total number of managed devices, and check for devices where the lock is off or unknown.
Good evidence
The report covers the whole fleet, all devices show the lock enabled, and any exceptions have a documented reason and a remediation date.
- Check 5 of 5What an auditor asks for
Ask for
Ask for recent alerts or logs of attempted tampering, agent stops, uninstall attempts or settings changes for the security products, and the process for handling them.
Look at
Check that the events are actually being generated and reviewed, and that any successful changes were made through the central policy rather than by a person on a device.
Good evidence
Tamper events are logged and investigated, and the only recorded settings changes trace back to authorised policy changes in the central console.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.10, PDF software security settings cannot be changed by users, which this control covers in full and more.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1825 requires that security product security settings cannot be changed by human users, preventing users or attackers from weakening protections. Annex A 8.9 requires organisations to establish, document, implement, monitor and review secure configurations across hardware, software, services and networks, which includes controlling who can change security configurations. ISM-1825 is a specific configuration-hardening requirement focused on locking security tools, whereas Annex A 8.9 is broader configuration governance across the entire ICT estate.
ASD Essential Eight: 4 mappings
This control is broader than E8-AH-ML2.10.
ISM-1825 requires that users cannot change security product security settings, preventing weakening of security controls. E8-AH-ML2.10 is a specific instance of this principle for PDF software security settings being immutable by users. ISM-1825 has wider scope as it is not confined to PDF software and applies to security products generally.
This control partially overlaps E8-AH-ML1.4.
ISM-1825 requires locking security product settings so human users cannot alter protections. E8-AH-ML1.4 requires web browser security settings to be locked down so users cannot change them, applying the same prevention of local weakening of security posture. The shared ground is enforcing immutability of security-relevant settings, but E8-AH-ML1.4 targets browser configuration while ISM-1825 targets security product controls such as AV/EDR/host firewalls.
This control partially overlaps E8-AH-ML2.7.
ISM-1825 requires that security product security settings cannot be changed by human users to preserve endpoint protections. E8-AH-ML2.7 similarly mandates that office productivity suite security settings are immutable by users, applying the same anti-tamper principle to a specific application class. E8-AH-ML2.7 is focused on productivity suite hardening rather than security products like antivirus/EDR/firewalls, so the overlap is in the control objective (prevent user changes), not the protected technology category.
This control partially overlaps E8-RM-ML1.4.
ISM-1825 requires that security product security settings cannot be changed by users to maintain enforced protections. E8-RM-ML1.4 specifically requires preventing users from changing Microsoft Office macro security settings, which is an immutability outcome for a particular application security control. The overlap is that both constrain user ability to weaken security posture, but E8-RM-ML1.4 is focused narrowly on macro policy in Office rather than security products broadly as per ISM-1825.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.