ASD ISM 1585 Lock web browser security settings against human user changes
What it says
Web browser 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 EnglishBrowser security settings are enforced centrally and locked, so people using the device cannot weaken or switch them off through the browser's own settings pages.
This control requires that the security settings in web browsers are locked so that human users cannot change them. It is not enough to configure a browser securely once; the settings must be enforced in a way that the person at the keyboard cannot alter, whether by opening the browser's settings menu, editing preference files, or overriding a policy. Why it matters: the web browser is the main way people reach the internet, and it is the entry point for many attacks, including drive-by downloads, malicious scripts, phishing pages and unwanted extensions. Browser security settings (such as download controls, content and script handling, certificate warnings, extension permissions and safe browsing protections) exist to block those attacks. If a user can turn a protection off because it is inconvenient, or is talked into doing so by an attacker, the organisation's careful configuration counts for nothing. The phrase "human users" is deliberate: settings should be controlled by the organisation's management tooling, not by individual people on individual machines. In practice this usually means pushing browser settings as mandatory (locked) policies from a central management system, rather than as recommended defaults the user can override, and confirming the browser shows those settings as managed and greyed out.
Free. Save your status, tasks and notes.
Why it matters
If users can change browser security settings, a single click can disable protections against malicious downloads, unsafe scripts, invalid certificates or rogue extensions. Attackers routinely coach victims through "just allow it" steps, and well-meaning staff disable protections that get in the way of a task. The result is that the organisation's hardened browser baseline silently drifts, device by device, and a compromised browser can become the foothold for malware, credential theft and wider network intrusion, with no record that the protection was ever switched off.
How to implement
The endpoint or device management team defines the organisation's browser security settings in the management platform (for example Group Policy, Intune, Jamf or the browser's enterprise policy files) and sets each one as a mandatory or locked policy, not a recommended default, so the browser enforces it and rejects user changes.
System administrators apply the locked policy set to every supported browser in the fleet, including the browser bundled with the operating system, and confirm on a test device that the security settings appear as managed (greyed out or marked as controlled by the organisation) in the browser's settings and policy pages.
System administrators remove the user's ability to bypass the policy layer by restricting local administrator rights and write access to browser preference and policy locations, so a person cannot edit configuration files or registry keys to undo the enforced settings.
The security team documents which browser settings are treated as security settings (for example download restrictions, script and content controls, certificate warning behaviour, safe browsing and extension permissions) and reviews the list after each major browser release so newly introduced security settings are added to the locked set.
The service desk handles any request to relax a browser security setting as a change request applied centrally by administrators, rather than granting the user permission to alter the setting on their own device.
Keep it running
Day to day, this control lives in the browser policy configuration of the organisation's device management platform. The security settings in the browser baseline should be set as mandatory or locked policies, not as defaults or recommendations, so the browser refuses user changes rather than merely suggesting a value.
Every supported browser in the fleet needs its own locked policy set, including browsers bundled with the operating system. When a browser is updated, check whether new security-relevant settings have appeared and add them to the locked set, and confirm that existing policies still apply after the update.
Requests from staff to relax a browser security setting should go through the normal change process and be applied centrally by administrators, never by giving the user the ability to change it themselves. Spot-check devices periodically by opening the browser's policy or settings page and confirming the security settings are shown as managed and cannot be edited.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for an export of the browser policy configuration applied to user devices for each supported browser.
Look at
Check whether the security settings are set as mandatory or locked policies rather than recommended or default values.
Good evidence
Every security-relevant setting is defined as a mandatory policy that the browser enforces and the user cannot override.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see a live user device with each supported browser open at its settings and policy pages.
Look at
Look at whether the security settings are greyed out or labelled as managed by the organisation, and try to change one.
Good evidence
The settings cannot be edited by the logged-in user and the browser reports them as managed by policy.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the list of browsers approved and installed across the fleet.
Look at
Compare it against the browsers that have locked policies applied, including any browser bundled with the operating system.
Good evidence
Every browser present on user devices, not just the primary one, has locked security settings applied.
- Check 4 of 5What an auditor asks for
Ask for
Ask how users are prevented from editing browser preference files, policy files or registry keys directly.
Look at
Look at whether standard users hold local administrator rights or write access to those locations.
Good evidence
Standard users have no administrative rights and cannot modify the locations that hold browser policy or preferences.
- Check 5 of 5What an auditor asks for
Ask for
Ask for records of recent requests to relax or change a browser security setting.
Look at
Check who made the change, how it was approved and whether it was applied centrally.
Good evidence
Changes are approved through the change process and applied by administrators, with no user-level exceptions granted.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML1.4, Web browser security settings locked down to users, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.1.
ISM-1585 requires locking down browser security settings so human users cannot disable or reduce protections. ISO/IEC 27001:2022 Annex A 8.1 requires protection of information on or accessible via user endpoint devices, which commonly includes securing endpoint applications like browsers that handle web content and credentials. Locking browser settings per ISM-1585 supports the endpoint protection objective in Annex A 8.1, but Annex A 8.1 is broader and includes many other endpoint safeguards beyond browser configuration.
This control partially meets A.8.9.
ISM-1585 requires web browser security settings to be centrally enforced such that human users cannot change them. ISO/IEC 27001:2022 Annex A 8.9 requires secure configurations to be established, implemented, monitored and reviewed across hardware, software, services and networks, which includes browser configuration baselines and enforcement mechanisms. ISM-1585 is a specific configuration-hardening outcome for browsers, while Annex A 8.9 is broader and covers configuration management governance and lifecycle controls beyond browsers.
ASD Essential Eight: 3 mappings
This control is equivalent to E8-AH-ML1.4.
E8-AH-ML1.4 requires that web browser security settings are locked down so users cannot change them. ISM-1585 states the same requirement, explicitly mandating that web browser security settings cannot be changed by users. The scope and intent align closely, with both focused on preventing user-driven weakening of browser security posture.
This control supports E8-AH-ML1.2.
E8-AH-ML1.2 requires that web browsers do not process Java content from the internet. ISM-1585 supports this by preventing users from changing browser security settings, helping ensure Java-blocking settings cannot be weakened or bypassed by end users. ISM-1585 does not itself require Java to be disabled; it reinforces the enforceability and durability of E8-AH-ML1.2.
This control depends on E8-AH-ML2.1.
ISM-1585 requires that web browser security settings cannot be changed by users. E8-AH-ML2.1 requires hardening web browsers using ASD and vendor guidance, which relies on those hardened settings remaining enforced rather than user-altered. ISM-1585 therefore supports E8-AH-ML2.1 by ensuring the hardened configuration cannot be weakened by end users.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.