What user application hardening at ML1 asks browsers to do
If your organization is preparing for an Essential Eight assessment or answering a customer questionnaire that asks for Maturity Level One evidence on browsers, the requirement comes down to four controls in the Information Security Manual (ISM). Browsers must not process Java from the internet (ISM-1486) or web advertisements from the internet (ISM-1485). Internet Explorer 11 must be disabled or removed (ISM-1654), and human users must not be able to change web browser security settings (ISM-1585). Together they target two risks: drive-by content delivered through a web page, and legacy browser engines that no longer receive the protections modern browsers rely on. ASD sets these requirements, but your organization owns them, and an assessor will test whether they hold on your endpoints, not whether a policy document says they should.
The work is harder than it looks because each control has to be enforced centrally and proven on real devices. A group policy or configuration profile that exists on paper does not show that a laptop in a branch office, a remote worker's machine or a shared kiosk actually runs with Java blocked, Internet Explorer removed and the browser settings locked. Confirm which browsers your estate runs, which of them still expose Java or ad content by default, and whether Internet Explorer 11 is present as a feature, a stub or a separate install on any image. Then decide who owns the enforcement mechanism and who owns the evidence. Your endpoint management or configuration tool can enforce settings, but an assessor will want to see current state per device, so plan for a recurring check that shows which devices pass and which fail.
Two questions help scope the first pass. First, do you know every device that can reach the internet through a browser, including those outside your managed fleet? Second, can you show, for a sample of endpoints, the setting value that is in force today and the date it was last verified? If either answer is uncertain, confirm the scope with your assessor or the Australian Cyber Security Centre's Essential Eight maturity model before you commit to a tooling approach. Those answers determine the effort, which is usually driven more by device count and image variation than by the controls themselves.
Which browsers, endpoints and teams fall under ML1 scope
Four scoping questions decide how much work ML1 user application hardening will be: which browsers and platforms are in use, whether Internet Explorer 11 survives anywhere, how managed and unmanaged devices differ, and who owns the policy that applies the settings. Answer them before estimating effort, because each one changes which controls need evidence and where that evidence comes from.
Browser builds and platforms in use
Inventory every browser build on every operating system, including versions that users installed themselves. The ML1 controls ask that browsers not process Java or web advertisements from the internet, so each build needs its own configuration path. Chrome, Edge and Firefox often take different policy mechanisms, so a single setting may not reach all of them. Confirm with the vendor which setting names apply to each build you run, and record the version that was tested.
Internet Explorer 11 dependencies
Check whether Internet Explorer 11 still exists in any operating system image, legacy line-of-business application or embedded web view. ISM-1654 requires it to be disabled or removed, but some internal applications call its rendering engine directly, so disabling it can break a workflow. Ask application owners to name any dependency, and record the exception path if a removal date is not yet set. Evidence should show the state on each image, not only on a sample machine.
Managed and unmanaged devices
Managed devices receive browser policy from a central console, so the settings can be enforced and reported. Unmanaged devices, such as contractor laptops or bring-your-own devices that reach internal services, may not accept those policies at all. Decide whether these devices are in scope at all, and if so, whether access is restricted to managed hardware. The browser settings that users must not be able to change only hold if the device is under your control.
Group policy and device management owners
Name the team that owns Group Policy, Intune or another device management tool, and the team that owns the browser image. Those teams are often different, and a setting enforced by one may be overwritten by the other. Write down who approves a change to a browser security setting and who reviews drift. Without a named owner for each setting, the control cannot be shown to be operating.
Compliance drift detection
Choose how you will confirm that settings stay in place after deployment. Wazuh Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies that can be extended with custom checks. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail. Either tool can produce the evidence, but you must confirm each check against your own browser builds before relying on it.
How an assessor tests Java, advertising, IE11 and browser settings
This table sets out, for each Maturity Level One browser control, the ISM control ID, what the assessor inspects, the evidence requested and the findings that most often delay sign-off. Read each row as a test plan: the configuration is checked first, then sampled endpoints, then whether a user can reverse the setting.
| Control and requirement | Assessor test approach | Evidence requested | Common findings |
|---|---|---|---|
| ISM-1486: Java from the internet | Inspect the managed browser policy for Java handling, then sample endpoints to confirm Java content from internet sources is not processed. | Exported browser policy, management console screenshots, and test results from a Java-enabled test page. | Java plug-in left enabled on legacy browser profiles; no approved exception record. |
| ISM-1485: Web advertisements from the internet | Confirm the policy blocks advertisements from internet sources, then test a sample of browsers against a known ad-serving test page. | Policy export, test page results, and the list of extensions that could override ad blocking. | Ad blocking relies on an unmanaged extension that users can disable or remove. |
| ISM-1654: Internet Explorer 11 | Check that Internet Explorer 11 is disabled or removed on the build image and on a sample of live endpoints. | Build image manifest, endpoint inventory showing IE11 status, and any documented exception. | IE11 kept for a legacy line-of-business app with no approval, or still reachable through a compatibility mode. |
| ISM-1585: Users cannot change browser security settings | Attempt to change security settings as a standard user on sampled endpoints and confirm the policy locks them. | Screenshots or logs of a standard user attempting a change, and the policy that enforces the lock. | Settings locked only for some browsers; unmanaged browser profiles let users sign in and change options. |
| Exception handling | Ask for each exception, check it has an owner, a business reason, a compensating control and an approval date, then confirm it has an expiry. | Exception register with approvals, review dates and compensating control records. | Exceptions without approval, or exceptions that never expire. |
| Endpoint coverage | Compare the endpoint inventory with the managed browser population to find unmanaged devices or profiles. | Inventory reports from the management platform and a reconciliation against directory records. | Contractor or kiosk devices outside the management scope. |
| Monitoring of compliance | Review how configuration drift is detected, such as a scheduled compliance check against the browser policy. | Compliance scan reports, the policy definitions used, and records of remediation of failing endpoints. | Scans run once at build time only, so later drift goes unnoticed. |
How to implement ML1 browser hardening in sequence
This sequence takes an organization from an unknown browser estate to a documented, tested state where browsers refuse Java and internet web advertisements, Internet Explorer 11 is gone, and standard users cannot weaken browser security settings. Each step ends with a named artifact that an assessor can inspect.
Inventory browsers and Internet Explorer 11 dependencies
The IT or endpoint team lists every web browser in use across managed endpoints, including versions and install sources, and identifies any line-of-business application or legacy intranet site that still depends on Internet Explorer 11. Owners of those dependencies confirm whether they can move to a modern browser or need a documented exception. The step is complete when the team holds a browser inventory and a dependency register that names an owner for each item. Output: the browser inventory and the IE11 dependency register.
Set Java and web advertisement blocking policies
The endpoint or platform engineering team writes browser policies that stop browsers from processing Java content from the internet and block web advertisements from the internet, as the ML1 controls ISM-1486 and ISM-1485 describe. Policies are pushed through the organization's device management or configuration tooling and tested on a pilot group before wider rollout. Confirm the exact policy keys and their behavior for each browser in your estate with the browser vendor's administrative documentation. Output: the policy definitions in version control and a pilot deployment record.
Disable or remove Internet Explorer 11
The team disables or removes Internet Explorer 11 on every managed endpoint where it is present, using the mechanism appropriate to the operating system build in use, as ISM-1654 requires. Where a dependency from step one still needs it, the team records the exception with its owner, compensating controls and review date, and the exception is approved by the accountable manager. The step is done when a scan shows Internet Explorer 11 disabled or removed on all in-scope devices except approved exceptions. Output: the removal change record and the exception register.
Lock browser security settings for standard users
Administrators apply browser configuration so that standard users cannot change browser security settings, the requirement in ISM-1585. Administrative accounts remain the only way to change those settings, and the change is tested by signing in as a standard user and attempting to modify the settings. Confirm the lock mechanism with each browser vendor and with the operating system's policy options before you rely on it. Output: the locked configuration baseline and a test record showing standard-user changes are refused.
Validate settings on a sample of endpoints
A security engineer checks a representative sample of endpoints across departments, operating system builds and browser versions to confirm that the policies, IE11 state and locked settings are in effect. A compliance-capable scanner or configuration assessment tool can run these checks against configuration files, registry keys and running processes, and failing devices are routed to remediation. The sample size and selection method should be agreed with the assessor in advance. Output: the validation scan results with pass and fail counts per check and the remediation tickets for failures.
Record the output of each step
The compliance lead assembles the artifacts from every earlier step into one evidence folder mapped to ISM-1486, ISM-1485, ISM-1654 and ISM-1585, with dates, owners and the version of the configuration baseline in force. The record is kept current because browser versions, policies and exceptions change over time, and the same evidence set is what an independent assessor will ask to see. Confirm with your assessor which evidence format and retention period they expect. Output: a dated ML1 browser hardening evidence pack with an index that links each control to its artifacts.
Which evidence shows ML1 browser hardening is in place
An assessor testing the browser controls at Maturity Level One will want evidence that the settings exist, that they reach every in-scope device, and that users cannot undo them. The six artifacts below cover configuration, endpoint state, legacy removal, exceptions and user rights. Each one needs an owner and a refresh routine so it still reflects the environment at audit time.
Exported browser policy configuration
Export the effective policy for each browser in scope, showing that web browsers do not process Java or web advertisements from the internet. Store the export with the date, the policy source (for example, a directory group policy object or a device management profile) and the browser version it applies to. Refresh it after every policy change and at least once per review cycle, and compare it against the last approved baseline to catch drift. The reader should confirm that the export shows the enforced value, not just the default.
Device compliance reports
Reports from your endpoint management or configuration assessment tool show whether each device actually has the browser settings applied. A policy that exists in a console but never reaches a laptop is a common audit finding. Keep a dated report per device group and record failing devices with their remediation status. Wazuh's Security Configuration Assessment and Fleet policies both produce pass or fail results per endpoint that can serve this purpose.
Internet Explorer 11 removal record
ISM-1654 requires Internet Explorer 11 to be disabled or removed. Keep a record that names the devices, the method used (removal or disablement) and the verification date, with a screenshot or query result for each device class. Include servers and images used for new builds, since legacy components often return through older golden images. Confirm with your vendor how the browser is disabled on each supported Windows release, because the mechanism differs between versions.
Approved exceptions register
Some systems will need a browser feature, such as Java for a line-of-business application, that ML1 would otherwise block. Record each exception with the business justification, the named owner, the affected devices, the compensating control and a review date. An exception without a review date tends to become permanent, and assessors often test whether the register is current. Review the register on the same schedule as the policy baseline.
Standard user restriction test
Proof that human users cannot change protected browser security settings is usually a test result, not a policy document. Sign in as a standard user on a representative device, attempt to change the protected settings, and record the outcome with a timestamp. Repeat the test after operating system updates, since they can alter how restrictions apply. This evidence speaks directly to ISM-1585, which asks that users be unable to change those settings.
Change and review history
Assessors check whether the browser configuration is managed, not merely set once. Keep a change log that records each modified policy, the approver, the reason and the test performed before release. Link each entry to the exported configuration it produced. Set a recurring review, and retain the log across the audit period so the reviewer can trace a setting from request to deployment to verification.
What meeting ML1 browser hardening costs in money and effort
This table breaks the cost of ML1 browser hardening into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations are stated because none are supplied for this topic, so use the rows to build your own cost model and to frame what you ask for in a written quote.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Browser management and device licensing | Your software vendor or reseller for any management suite; your internal team for configuration | Recurring (licence renewals), with a one-time setup | Number of managed devices, whether you already own an endpoint management tool, and the browser versions in use. Confirm licensing terms with your vendor. |
| Engineering time to write and test policy | Your platform or endpoint engineers, or an implementation partner under a fixed scope | One-time, then periodic review | Number of browsers and device groups, how many policy settings you must set, and how many test rounds you run before rollout |
| Compatibility work for IE11 or Java dependencies | Application owners, your engineers, and the vendors of legacy line-of-business applications | One-time for remediation, recurring if exceptions must be renewed | How many applications still depend on Internet Explorer 11 or Java, and whether vendors can offer supported alternatives. Ask for a dependency inventory in any quote. |
| Evidence upkeep | Your compliance or security team, sometimes supported by an implementation partner | Recurring | How often policies change, whether configuration is exported automatically, and how many devices you must show as passing |
| External review or auditor sampling | Your independent assessor or auditor, who sets its own fees | Recurring, usually tied to each assessment cycle | Scope of the assessment, number of devices or samples the assessor selects, and the quality of evidence you can produce on request |
How self-hosted open-source tools can produce ML1 evidence
Assessors want to see that the ML1 browser settings are in place and stay in place, not just that they were configured once. Two self-hosted open-source tools can produce that recurring evidence from the endpoints themselves, but each answers a different question, so the cards below set out what each one checks and where it stops.
Wazuh configuration assessment
Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and can be extended with custom policies. It checks files, directories, registry keys and running processes, and reports remediation advice for each failed check. For ML1, confirm that the policy you run tests the browser and registry settings behind ISM-1486, ISM-1485, ISM-1654 and ISM-1585, since a general benchmark may not cover every browser build or Java and advertising setting. Custom policies are the usual way to close those gaps.
Fleet policies for browser settings
Fleet (MIT) policies ask each device a yes or no question written as an osquery query, such as whether a browser setting holds its required value. The policies page then shows which devices on each fleet are passing and which are failing. This gives a current, per-device view that is easy to hand to an assessor, and failing devices can be followed up before the next review. Confirm that your queries read the registry or configuration state the browser actually uses, and that the fleet covers every managed endpoint, not only the ones reporting most reliably.
Scans do not replace the configuration
Neither tool sets the browser configuration. Blocking Java from the internet, blocking web advertisements, disabling Internet Explorer 11 and locking browser security settings must be applied through group policy, device management or another enforcement mechanism that your organization controls. Wazuh and Fleet then confirm that the setting is present and report drift. Treat a passing scan as evidence of the result, and keep the enforcement record, change history and exception approvals as the other half of the evidence.
Mapping results to ML1 controls
Keep a register that links each failing or passing check to the ISM control it supports, using the control IDs in the ISM OSCAL catalog for ML1 (ISM-1486, ISM-1485, ISM-1654 and ISM-1585). Record the policy name, the query or rule version, the date of the run and the owner of any exception. Assessors usually ask how a result relates to a control and how often the check runs, so a dated export from each tool, filed against the control ID, answers both questions. Confirm with your assessor which format they accept.
Who owns the tooling work
Installing and tuning Wazuh or Fleet, writing custom policies, and building the evidence register are implementation tasks that an organization can do itself or hand to an implementation partner under a written scope. The organization keeps ownership of the controls and the decisions about exceptions. An independent assessor, not the tool vendor or the implementation partner, decides whether the evidence meets the maturity model. Ask any partner to state in the scope which checks they will write, how they will test them, and what they will hand over at the end.
Who owns ML1 browser hardening, and what a partner can take
Your organization owns the control objective. Accountability for ISM-1486, ISM-1485, ISM-1654 and ISM-1585 sits with the people who run the browser estate and who answer for it to the business, not with the partner or the assessor. Someone inside the organization must decide which browsers are approved, who approves exceptions to Java or advertisement handling, and who signs off the policy that users cannot change security settings.
- Approved browser list: Decide which browsers are in scope and confirm that Internet Explorer 11 is disabled or removed on every device, including legacy servers and kiosks.
- Policy decisions: Approve the rules for Java and web advertisements from the internet, and record any business exception with an owner and an end date.
- Settings lock: Confirm that standard users cannot change browser security settings, and that administrators understand which changes are authorized.
- Operational duty: Assign a team to review drift reports and remediate failing devices on a schedule the organization can keep.
- Evidence custody: Keep the policy, the exception register and the scan results in a location the assessor can access.
Before engaging anyone, check that a named owner can explain each of the four controls in plain terms and show where the evidence is stored.
An implementation partner prepares systems and evidence. For this requirement, that usually means building the browser policy, deploying it to managed endpoints, setting up a scanner such as Wazuh Security Configuration Assessment or a Fleet policy query to check the result, and packaging the output so the organization and its auditor can read it. A partner can take the policy build, the validation runs and the evidence packaging, which are the parts that consume the most engineering time.
- Policy build: Draft browser configuration for the approved browsers and map each setting to the relevant ISM control.
- Validation: Run test scans against sample devices and record which devices pass or fail.
- Evidence packaging: Export configuration files, scan results and a change log in a consistent structure.
- Handover documentation: Explain what was configured, how to re-run the checks and what each failing result means.
A partner cannot decide that the organization is compliant, and it cannot sign an assessment. Ask the partner to state in writing what it delivers and what remains with your team.
The independent assessor, auditor or certification body is the only party that issues a report or conclusion about maturity. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate, but an assessor still forms a view on whether each strategy is implemented and effective at the target level. The assessor tests the evidence, samples devices, and checks that the organization's own processes produce results over time.
- Independence: The assessor must not have designed the configuration it is testing without disclosing that relationship and managing the conflict.
- Sampling: Expect the assessor to select devices and ask for the scan output behind them, not only a policy document.
- Effectiveness: A configured setting that is not checked regularly may not satisfy an assessor, even when it was correct on the day it was applied.
- Conclusion: Only the assessor's written findings count as an assessment result.
Confirm the assessor's scope, sampling method and fee basis in writing before the work begins.
How much effort and outside help does ML1 browser hardening need?
How long does ML1 browser hardening take to implement?
No supplied figure gives a duration, so confirm timing with your own environment before committing to a date. The work is mostly configuration: blocking Java and internet web advertisements in browsers, disabling or removing Internet Explorer 11, and locking browser security settings so users cannot change them. Duration depends on how many browser builds, managed device groups and user profiles you run, how many of them already have policy, and how long your change process takes to test and roll out settings. Ask any partner to show how they will size the work from your estate before agreeing a timeline in writing.
Can our own team implement ML1 browser controls without outside help?
Often yes, if you already manage browsers through group policy, Microsoft Intune or a similar endpoint tool and have someone who can test changes without breaking line-of-business applications. The controls themselves are configuration decisions, not new products. Outside help is usually most useful for legacy applications that depend on Java or Internet Explorer 11, for documenting the evidence an assessor will ask for, and for checking that settings persist on every device. Decide this by auditing your current policy coverage first.
What does ML1 browser hardening need from our organization?
It needs an inventory of browsers and versions in use, a named owner for browser policy, a test group that represents real business applications, and an exception process for any application that still needs Java or Internet Explorer 11. Your organization owns the control decisions and the risk acceptance for exceptions. Plan for change windows, user communication and a way to confirm that policy is applied on each managed device.
What drives the cost of ML1 browser hardening?
Cost is mainly labor and is driven by the number of device groups and browser variants, the number of legacy applications that depend on blocked features, how much testing is needed, and how much evidence must be produced. Recurring costs appear when new browser versions, new devices or new applications must be checked against the same settings. Ask for a quote that separates one-time policy design and testing from ongoing monitoring, exception handling and periodic evidence collection, and that names who performs each task.
Is removing Internet Explorer 11 always possible?
Not always. Removing or disabling Internet Explorer 11 is the expected outcome for ML1, but some older line-of-business applications still depend on it. Where that is true, you need a documented plan to migrate the application, isolate it or carry an approved exception, and you should confirm with your assessor how they will treat that exception. Start by finding every application that launches Internet Explorer or its engine before you set the removal date.
Does a self-hosted tool satisfy the ML1 browser control on its own?
No. A tool can help you configure, detect and report on browser settings, but the organization still has to implement the control and be able to show it working across its estate. Wazuh Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and can check files, registry keys and running processes. Fleet policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices pass or fail. Confirm with each tool's documentation that the checks you need exist, and treat its output as supporting evidence rather than proof of compliance.
What should we ask a partner for in a written scope?
Ask for the list of ML1 controls in scope by control ID, the browsers and device groups covered, the legacy applications and exceptions handled, and the configuration method used. Ask which deliverables you receive, such as policy exports, test records, monitoring queries and an evidence pack, and who owns each. Confirm that the partner prepares systems and evidence and that independent assessors issue any report. DeployOpen works on fixed scopes agreed in writing before work starts, and does not publish a price list, so ask for a quote tied to that scope.
How DeployOpen scopes and prepares ML1 browser hardening evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the browser hardening settings and evidence that ML1 asks for. Your organization keeps ownership of its controls, and only an independent assessor can judge whether ML1 has been met.
How we scope
- Confirm the browser fleet, operating systems and managed endpoints that fall within the ML1 boundary.
- Record which browsers and versions are in use, and whether Internet Explorer 11 is present anywhere.
- Agree in writing which controls (ISM-1486, ISM-1485, ISM-1654, ISM-1585) and which evidence formats are covered.
How we build
- Configure browsers so they do not process Java or web advertisements from the internet.
- Disable or remove Internet Explorer 11 and lock browser security settings against user changes.
- Deploy Wazuh Security Configuration Assessment or Fleet policies to check these settings continuously across endpoints.
How we hand over
- Provide a written record of each setting, its configured value and the tool that checks it.
- Export policy pass and fail results so your assessor can trace each ML1 control to evidence.
- Document known gaps and the remediation steps your team owns, so nothing is hidden at assessment time.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer for drift and browser updates.
- Ask for a quote built from the written scope, covering one-time build work and any recurring support.
