ISM-1412: How to Harden Web Browsers

ISM-1412 asks that every web browser you use is configured to both ASD's and the browser vendor's hardening guidance, and that where the two disagree on a setting, the more restrictive one applies. In practice that means a written baseline for each browser you allow, pushed out as policy people cannot change (ISM-1585), and reviewed as browsers and guidance change. It is part of the Essential Eight at Maturity Levels Two and Three, built on Maturity Level One's browser rules for ads, Java and Internet Explorer 11.

#What does ISM-1412 require?

In plain English:

• Which browsers. Every web browser on the organisation's workstations, not only the default one. ISM-1412 sits in ASD's user application hardening guidelines, which cover applications "typically installed on workstations", including "web browsers, including their extensions".
• Whose guidance. Both ASD's and the vendor's. For Microsoft Edge, ASD's Blueprint for Secure Cloud starts from Microsoft's own security baseline, which "is complemented by the ASD Edge hardening configuration policy for alignment with the principles of the ISM" (ASD). For Google Chrome, ASD's assessment guide points to Google's Chrome Browser Enterprise Security Configuration Guide.
• When they disagree. Setting by setting, the stricter value wins. ASD's assessment guide puts it as "In cases where ASD hardening guidance and vendor hardening guidance conflict, the most restrictive guidance should take precedence" (ASD). Where only one source covers a setting, apply that one.
• What hardened means. Settings that are applied and enforced on every device, not a document on a shelf. The same guide notes that "hardening guidance can be configured via group policy setting templates that are made available by vendors."

ISM-1412 applies at every classification ASD marks, from non-classified systems to TOP SECRET. ASD's Essential Eight Maturity Model has the same words at Maturity Levels Two and Three, so it is part of any Essential Eight assessment at those levels.

#Why does it matter?

Defaults are made for everyone. ASD's reasoning: "When web browsers are deployed in their default state, or with an unapproved configuration, it can lead to an insecure operating environment that may allow malicious actors to gain an initial foothold on networks." The browser is where people meet untrusted content all day: links, downloads, sign-in pages and advertising.

The browser now holds the business. Email, files, finance and administration consoles all run in it. ASD's Blueprint says of the browser that "its role as a critical control plane for endpoint security continues to grow" (ASD).

A setting people can change can be talked away. ASD warns that "human users' ability to change the security settings of web browsers can be exploited by malicious actors using social engineering", and its assessment guide adds that people "may tinker with these settings to enable content or change settings when guided to do so by malicious actors" (ASD).

Two sources catch more than one. Each covers settings the other leaves alone. ASD's Blueprint layers its own Edge policy over Microsoft's baseline to enforce "granular controls included in ASD hardening recommendations and other better practice configurations that are not addressed by the baseline" (ASD).

#How does it fit with the other controls?

The web browser controls work as a set:

• ISM-1585: browser security settings cannot be changed by human users. Without it, ISM-1412's settings are suggestions.
• ISM-1485: browsers do not process web advertisements from the internet. ASD notes that "Malicious actors are known to indiscriminately use 'malvertising' in their attempts to compromise systems."
• ISM-1486: browsers do not process Java from the internet. Oracle, which makes Java, says "Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore" (Oracle). Check every other browser you allow all the same.
• ISM-1654: Internet Explorer 11 is disabled or removed. It sits in operating system hardening, but the Essential Eight lists it under user application hardening.

Four user application controls round it out. ISM-1915 asks for approved configurations to be "developed, implemented and maintained", which is the written baseline ISM-1412 needs. ISM-1235 restricts extensions to an organisation-approved set. ISM-1467 asks for the latest release of browsers and their extensions. ISM-2110, added in June 2026, applies ISM-1412's rule to every user application.

#How do you meet ISM-1412?

1. List the browsers in use on every kind of device you manage, including any installed for a single website. Decide which you will support. ASD's Blueprint warns that "Unless maintained as a deliberate, risk-assessed decision with equivalent hardening applied, secondary browsers often become the weakest link and the entry point for a security breach" (ASD). Remove or block the rest.
2. Collect the guidance for each browser: the vendor's published baseline and ASD's guidance, with their versions or dates.
3. Compare setting by setting. Where they conflict, take the stricter value; where only one covers a setting, apply it; record each decision. Your tools will not do this for you: ASD's Blueprint notes that where device and user policies set the same Edge setting differently, "Intune does not apply the most restrictive setting."
4. Write the result down as the approved configuration (ISM-1915), with each departure from it and who accepted the risk. Developers who need browser developer tools are the classic case; the Blueprint says this "should be managed through a separate, targeted policy with appropriate risk acceptance".
5. Enforce it as mandatory policy through Group Policy or device management. Microsoft explains the difference for Edge: "Mandatory policies override user preferences and prevent the user from changing the policy settings. Recommended policies provide a default setting that the user can override" (Microsoft). Only mandatory policy keeps ISM-1585.
6. Build the Maturity Level One basics into the same baseline: ads blocked by a forced ad-blocking extension or by web content filtering (ISM-1485); no Java (ISM-1486); Internet Explorer 11 disabled or removed (ISM-1654); extensions blocked by default with an approved list (ISM-1235); automatic updates with a forced restart (ISM-1467).
7. Pilot, then roll out. Test with a small group, then check a sample of devices: Microsoft's own check for Edge is to "go to edge://policy to see all policies that are applied" (Microsoft).
8. Review on a schedule and whenever a new baseline appears. ASD's Blueprint notes that Microsoft's Intune baselines "are updated less frequently than the browser itself, missing new security features", so new browser features need a decision of their own.

#What evidence shows ISM-1412 is met?

Ask	Look at	Good looks like
Which browsers are in use?	The software inventory for workstations	Only approved browsers; anything else removed or blocked
Which guidance was used?	The approved configuration (ISM-1915)	ASD's and the vendor's guidance named with versions, and the stricter value recorded where they differ
Is it applied?	Group Policy results or device management reports, and the browser's own policy page	The baseline enforced on every in-scope device, for every approved browser
Can people change it?	A standard user's browser settings	Settings greyed out, marked as managed by the organisation or shown with a padlock (ISM-1585)
Are the basics in place?	An advertising test page, a Java test page, Internet Explorer 11's status	No ads, no Java, Internet Explorer 11 disabled or removed and blocked from running
Which extensions run?	The extension policy and a report of installed extensions	Blocked by default, an approved list, nothing else installed (ISM-1235)
Is it current?	Baseline review records and browser versions	Reviewed since the latest vendor baseline; browsers on the latest release (ISM-1467)
What is left out?	The exceptions register	Each relaxation justified, approved, limited to the people who need it and dated for review

ASD's assessment guide describes the same checks (ASD).

#What gets in the way?

More than one browser. Each needs its own baseline, its own policy templates and its own evidence. A second browser installed for one supplier's website quietly doubles the work, or goes unhardened.

Guidance that is silent. ASD's detailed browser settings are for Edge on Windows; the Blueprint notes that where its policies "are not supported on macOS, Android, or iOS, alternative controls or compensating measures may be required if those platforms are in scope" (ASD). For other browsers and platforms, the vendor's guidance may be the only source; record that, and what you added.

Legacy web applications. Old internal sites that need Internet Explorer or Java are the usual reason a baseline gets weakened. ASD's Blueprint allows Edge's IE mode "Where legacy web applications require IE rendering", using a centrally managed site list, and ASD's assessment guide asks for an application control rule against iexplore.exe because "standard users will still be able to launch Internet Explorer 11, even in Microsoft Windows 11". For Java on an intranet, the guide accepts compensating controls such as "internet-based Java content is blocked via a web content filter."

Ad blocking. An ad-blocking extension must be forced on and locked, or the filtering done on the network. ASD is clear that "built-in settings within web browsers to block pop-ups do not meet the intent of this control."

Friction. Blocked extensions and disabled developer tools generate helpdesk calls. A simple request process for new extensions, with someone who actually assesses them, keeps the allow-list honest. Smaller and larger organisations. A smaller organisation can often standardise on one browser, apply the vendor's baseline and ASD's additions through the device management it already has, and keep a page of documentation; its IT provider usually does the work, so ask them for the baseline and the evidence. A larger one has several browsers, platforms, legacy applications and virtual desktops, and needs a configuration owner, change control and compliance reporting.

The business case. The cost is mostly time: building and testing the baseline, then reviewing it as browsers and guidance change. The management tools are often already licensed. What it buys is a smaller target where staff spend most of their working day, and one of the requirements for Essential Eight Maturity Level Two.

#What tools and skills help?

• Device management or Group Policy that can push mandatory browser policy to every device and report which devices comply.
• The vendors' published baselines. Microsoft describes its Intune security baselines as "a group of preconfigured Windows settings that help you apply and enforce granular security settings that the relevant security teams recommend" (Microsoft), and ASD's assessment guide points to Microsoft's Security Baselines blog for Edge. Google offers its Chrome Browser Enterprise Security Configuration Guide "for recommendations and critical considerations when enabling or disabling Chrome browser security policies for your organization" (Google).
• ASD's Blueprint for Secure Cloud, which sets out its Edge settings as device management policies (ASD).
• Browser management consoles for extension requests, approvals and reporting. ASD's Blueprint recommends "A deny-all, permit-by-exception policy" for add-ons.
• Web content or DNS filtering that blocks advertising and other risky content for every browser at once.
• Application control, so unapproved browsers and Internet Explorer 11 cannot run.
• Skills to read two baselines side by side, test changes on a pilot group and run an exceptions process someone actually reviews.

Which of your current licences already provide these? The free coverage check shows which ISM and Essential Eight controls the products you already pay for can reach, in about three minutes. To see ISM-1412 among the other hardening controls, open it in our sample coverage report, or read what an ISM assessment involves.

#What changed in recent ISM releases?

ISM-1412 is not new: ASD's catalogue records it at revision 6, last updated in December 2023. That release amended it "to recommend that the most restrictive guidance take precedence when conflicts occur", as it did for the matching controls on operating systems, office suites, PDF software and server applications (ASD).

In June 2026, ASD added ISM-2110, "recommending that user applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur". ISM-1235's extension rule "was expanded to all user applications", and ISM-1467 was "expanded to include extensions for all of the application types listed" (ASD).

In September 2026, ISM-1585 was among the controls amended from "users" to "human users"; ISM-1412's wording did not change (ASD). The Essential Eight Maturity Model still says "users". Our ISM September 2026 summary covers the rest.

#Sources

• ASD, Information security manual: ISM-1412, the web browser and user application hardening controls, and the section guidance quoted on this page
• ASD, Essential Eight Maturity Model and Essential Eight assessment process guide: User application hardening
• ASD, Blueprint for Secure Cloud: Microsoft Edge for Business
• ASD, ISM December 2023 changes, ISM June 2026 changes and ISM September 2026 changes
• Microsoft, Configure Microsoft Edge for Windows with policy settings, Learn about Intune security baselines and the Microsoft Security Baselines blog
• Google, Chrome Browser Enterprise Security Configuration Guide (Windows); Oracle, Java and Chrome NPAPI support