User application hardening ML2: requirements and evidence

What user application hardening at ML2 asks for and why it is hard

At Maturity Level Two, user application hardening asks you to harden web browsers, Microsoft Office and PDF software to ASD and vendor guidance, block Office from creating child processes, executable content and code injection, stop users from changing security settings in those applications, and centrally log PowerShell and command line activity. Every ML1 control carries forward into ML2, and the ML2 Essential Eight profile in ISM v2026.09.4 contains 87 ISM controls, up from 46 at ML1. If you are preparing for an assessment or moving up from ML1, your first task is to confirm which of those 87 controls already have evidence and which do not.

The risk behind these controls is well understood. A malicious document or web page that launches a child process, such as a script host or a shell, can turn a single click into code execution. Code injection lets content tamper with other running processes, and Object Linking and Embedding packages can carry payloads past simple checks. The control that matters most in practice is the lock: if users can switch off macro restrictions, disable protected view or relax PDF sandboxing, every technical block above becomes optional. ISM-1823 and ISM-1824 close that gap, so verify that policy, not only the default configuration, enforces them on every managed device.

The difficulty is rarely the individual setting. It comes from three sources. First, vendor guidance and ASD guidance do not always agree, and where they conflict the most restrictive guidance wins (ISM-1412, ISM-1859, ISM-1860), so you need a documented reconciliation for each product in your estate. Second, locking settings across browsers, Office and PDF tools means managing configuration centrally and proving it on endpoints that drift. Third, central logging of PowerShell module, script block and transcription events, and command line process creation events (ISM-1623, ISM-1889), generates large volumes that must be stored, protected from modification (ISM-1815) and analysed in a timely way (ISM-1906). Confirm with your own tooling and the current ISM OSCAL profile what volume and retention you can sustain before you commit to a date.

Which browsers, Office, PDF and PowerShell endpoints are in scope at ML2

At Maturity Level Two, the hardening work follows the software that users and administrators actually run. Each card below names one scoping decision, what it changes in the implementation, and what to confirm before the work is priced or sequenced.

Browser inventory and vendor baselines

Start by listing every browser on managed endpoints, including versions, installation source and any embedded browser components used by line-of-business applications. Each browser needs ASD guidance and the vendor's hardening baseline applied, and where the two conflict the more restrictive setting wins. A browser that is only present through an application update channel is easy to miss and should still be in scope. Confirm which browser builds the organization supports before writing configuration.

Office as a suite or standalone

Whether Microsoft Office runs as a single suite deployment or as individually installed applications changes where the child process, executable content and code injection restrictions must be applied. Mixed estates, with Word on some machines and Excel on others, need a per-application matrix so no application is left unconfigured. Confirm the deployment method and the Office channel in use, since they determine which policy objects or management templates apply.

PDF applications on user endpoints

PDF readers are often installed by departments, bundled with other software, or replaced by browser viewers. Each PDF application in use must be blocked from creating child processes, and users must not be able to change its security settings. Build an inventory from software deployment records and endpoint scans, not from the approved list alone, because an unapproved reader that opens untrusted files is the most likely gap.

PowerShell and the command line on shared admin workstations

PowerShell and command line process creation events must reach central logging, and shared administrator workstations generate far more of these events than standard user devices. Decide which machines are administrative, which accounts sign in to them, and whether logs from privileged sessions are separated for review. Confirm that module logging, script block logging and transcription are enabled on the same device population, since partial coverage produces gaps that an assessor will sample.

Logging infrastructure that receives events

Hardening settings produce evidence only if the events arrive somewhere the organization controls. Confirm the collector, its retention period, its storage location and who can modify or delete stored events. ML2 also expects event logs to be protected from unauthorized modification and deletion and analyzed in a timely manner, so the receiving platform is part of the scope, not an afterthought. Ask whether endpoints in branch offices or remote locations can reach the collector.

Third parties that control endpoint settings

A managed endpoint provider, SaaS management tool or outsourced desktop team may push the browser, Office and PDF settings that the organization is required to own. Identify each party with administrative rights over these settings, what it can change, and whether it produces evidence the organization can present to an assessor. Written responsibility splits are needed here. The organization still owns the control, even when a provider applies the configuration.

How an assessor tests user application hardening at ML2

This table compares each ML2 requirement area for user application hardening by the test approach an assessor typically takes, the evidence they request and the findings that most often delay a level decision. Read it as a checklist for pre-assessment preparation, and confirm each control's exact wording in the ISM Essential Eight profile before relying on it.

Requirement area	Test approach and evidence requested	Common findings
Browser, Office and PDF hardening (ISM-1412, ISM-1859, ISM-1860)	Assessor selects a sample of workstation images and compares applied configuration against ASD and vendor guidance, applying the most restrictive setting where they conflict. Evidence: hardening baseline documents, GPO or Intune exports, and the conflict resolution record.	Baseline is documented but not applied to all device groups, or vendor guidance was updated and the baseline was never revised.
Office child processes (ISM-1667)	Assessor tests whether Office applications can launch child processes, usually by reviewing attack surface reduction or equivalent policy and running a test on a sample device. Evidence: policy export and test result.	Rule is set in audit mode only, or exceptions for line-of-business add-ins are broader than the business case supports.
Office executable content and code injection (ISM-1668, ISM-1669)	Assessor checks that Office cannot create executable content or inject code into other processes, comparing policy scope against the device estate. Evidence: policy configuration and exclusion list with approvals.	Exclusions added during rollout were never reviewed, or policy covers only some Office applications.
OLE package activation (ISM-1542)	Assessor verifies that Object Linking and Embedding packages cannot be activated, typically through a configuration check and a test document. Evidence: configuration export and test record.	Setting is missed on devices managed outside the main policy, such as unmanaged or legacy builds.
PDF child processes (ISM-1670)	Assessor confirms the PDF application is blocked from creating child processes on a sample of endpoints. Evidence: policy export for the PDF product and a test showing the block.	Organization runs more than one PDF product, and only the primary one is hardened.
Locked security settings (ISM-1823, ISM-1824)	Assessor attempts to change office suite and PDF security settings as a standard user, then reviews whether administrative lockdown is enforced centrally. Evidence: user permission test results and policy showing locked settings.	Users retain rights to change trust centre or protected view settings, or local administrators can override policy without a record.
PowerShell module, script block and transcription logging (ISM-1623)	Assessor checks that these three logging types are enabled and that events arrive in the central log platform. Evidence: group policy or configuration export, sample events from the central store and a time-stamped ingestion test.	Logging is enabled on a few reference devices only, or events are collected locally but not forwarded.
Command line process creation logging (ISM-1889)	Assessor verifies that process creation events are recorded with command line content and forwarded centrally. Evidence: audit policy export and sample central events showing command lines.	Command line content is not captured, so events show process names without arguments.
Log protection from modification and deletion (ISM-1815)	Assessor reviews access control on the central log store, separation of duties for administrators, and retention settings. Evidence: access role lists, change logs for the log platform and integrity or immutability settings.	Log administrators can delete or edit events with no alert, or the same account manages both the endpoint and the log store.
Timely analysis of logs and detected events (ISM-1906, ISM-1228)	Assessor samples detected events and checks that internet-facing server logs and security detections are reviewed within the timeframe the organization set. Evidence: alert queues, triage tickets and review records.	Alerts are generated but no review record exists, or the defined review timeframe is not written down.
Incident reporting and response (ISM-0123, ISM-0140, ISM-1819)	Assessor walks through a sample incident to confirm reporting to the CISO, reporting to ASD where required, and enactment of the incident response plan. Evidence: incident register, escalation records and the current response plan.	Incident response plan is out of date, or incidents involving application hardening bypasses are not tracked to closure.

How to implement user application hardening ML2 in six steps

This sequence moves browsers, Office, PDF software and PowerShell from ad hoc settings to hardened, locked configurations with central logging, and it ends with evidence that an assessor can check against the ML2 requirements.

Inventory applications and PowerShell use
The IT or platform team lists every browser, Microsoft Office component, PDF application and PowerShell host in use across managed endpoints, including versions, owners and whether users can install their own copies. Confirm the list against your asset inventory and your device management console, since shadow installs are a common gap. The output is an application register with version, scope and management owner for each product. The step is done when the register matches what the management tooling reports for a sample of devices.
Record applicable guidance and conflict rules
The security or compliance lead maps each product in the register to the ASD guidance in the Information Security Manual for the ML2 Essential Eight baseline, plus the relevant vendor hardening guidance. Where ASD and vendor guidance disagree, record the most restrictive rule as the decision, with the reason. The output is a hardening baseline document listing each control ID, the product it applies to, the chosen setting and any approved exception. The step is done when every ML2 control touching these products has a recorded setting or a documented reason it does not apply.
Apply and lock configurations through existing tooling
The endpoint or platform team implements the baseline through the management tooling the organization already runs, such as group policy, a mobile device management service or configuration profiles. Settings that let users change browser or office security options are locked so the policy controls them. Keep the configuration in version-controlled policy objects so changes leave a history. The output is exported policy objects tied to the baseline document. The step is done when a test device shows the locked settings and a user account cannot override them.
Enable PowerShell and command line logging centrally
The logging owner turns on PowerShell module logging, script block logging and transcription, along with command line capture for process creation events, then forwards those events to a central log store. Confirm that events from a test endpoint arrive at the store with the correct host and user fields. Record the log sources and retention settings. The output is a logging configuration record and a sample query result showing PowerShell and process creation events from several endpoints. The step is done when the sample events are searchable centrally.
Protect logs, analysis and incident routing
The security operations team restricts who can modify or delete event logs, sets up review of logs from internet-facing servers and detected cyber security events, and documents how incidents reach the CISO and the incident response plan, including reporting to ASD where that applies. Test one alert end to end, from detection through the routing path. The output is an access list for the log store, a review procedure with named owners, and an incident routing record. The step is done when the test alert reaches the named owner and the logs cannot be altered by standard operators.
Verify with configuration scans and document deviations
The assurance owner runs configuration assessments against the endpoints, for example with a scanner that checks files, registry keys and running processes against policy, and compares the results with the baseline document. Each failing check is either remediated or recorded as a deviation with an owner, reason and review date. The output is a scan report set, a deviation register and an evidence pack that links each ML2 control to its scan result, policy object and log sample. The step is done when the evidence pack is complete and an independent assessor has been engaged to test it.

Which evidence passes an ML2 user application hardening assessment

An assessor testing user application hardening at Maturity Level Two wants proof that the settings are applied, that they stay applied, and that deviations are approved. The cards below cover the artifacts that show each of these, and how to refresh them between formal assessments so they reflect the current baseline rather than a snapshot taken for the audit.

Approved hardening baseline

This is the document that defines what hardened means for each browser, Office suite and PDF application in scope. Record the guidance it follows: ASD guidance, vendor hardening guidance, and the rule that the most restrictive guidance wins where sources conflict. Give the baseline a version number and an owner. Between audits, review it on a fixed schedule and whenever a vendor releases new hardening guidance, and tie every change to a new baseline version so an assessor can see which version was in force on any given date.

Exported configuration with locked settings

Export the effective configuration of browsers, Office and PDF software from managed endpoints, not from the policy template alone. The export should show that users cannot change security settings, which is the control the assessor will test by attempting a change on a sample device. Keep exports from a sample of devices across each user group. Re-export after each baseline version change and after major application updates, since a feature update can reset or rename a setting.

Office and PDF child process rules

Show the rules that block Microsoft Office from creating child processes, creating executable content, injecting code into other processes, and activating Object Linking and Embedding packages. Show the equivalent rule that blocks PDF applications from creating child processes. Pair the rule definitions with audit or block event records from endpoints, because a rule that exists but never fires is hard to distinguish from one that is not enforced. Confirm the exact rule identifiers and mechanisms with your endpoint management vendor.

Configuration assessment reports and trend

Scheduled configuration assessment scans against your hardening baseline produce the evidence that settings persist across the estate. Wazuh Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies, and recommends remediation for failures. Keep the reports, the policy version used, and a trend view showing pass and fail counts over time. A flat or improving trend across months is more convincing than a single clean report produced the week before an audit.

Central PowerShell and command line logs

Keep samples from the central log store showing PowerShell module logging, script block logging, transcription events, and command line process creation events from workstations and servers. The samples should show the events arriving centrally and carrying enough detail to identify the process and user. Sample a range of dates and hosts. Confirm that log collection covers the endpoints in scope, since an assessor will often ask for a device that is missing from the log source list and check why it is absent.

Log protection and analysis records

At ML2 the logs themselves need protection. Keep the settings that restrict modification and deletion of event logs, including who holds delete rights and how that access is reviewed. Also keep analysis records: evidence that logs from internet-facing servers and detected cyber security events were reviewed in a timely manner, with the reviewer, the date and the outcome. Where an event led to an incident, the incident record should show the report to the CISO and the response steps taken. Review access rights to the log store on a recurring schedule.

Deviation register with approvals

Some settings cannot be applied to every application, for example where a line-of-business add-in depends on a feature that a hardening rule blocks. Record each deviation with the rule affected, the business reason, the compensating measure, the risk owner's approval, and an expiry or review date. An assessor will check whether the register matches what the exports and scans actually show. Review open deviations at each baseline change and close any that no longer have a justification.

What user application hardening ML2 costs in money and effort

This table compares the main cost components of reaching Maturity Level Two for user application hardening, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure quote requests, since most of the spend is engineering time and recurring evidence upkeep rather than software licenses. No prices or durations are given because none are supplied for this topic; confirm them against your written scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it, and what to ask for in a quote
Management and logging licenses or subscriptions	Vendor or reseller for commercial endpoint management and SIEM tools	Recurring	Driven by device count and log volume. Ask whether pricing is per device, per user or per data volume, and what is included in renewal.
Self-hosted open-source tooling	No license fee, but infrastructure and staff time are still required	Recurring for hosting, one-time for setup	Removes license spend, not effort. Ask the partner to itemize build, hosting, patching and support hours separately.
Engineering time to build and lock baselines	Internal platform or endpoint team, or an implementation partner under a fixed scope	One-time	Driven by the number of browsers, Office builds and PDF applications, and by existing group policy or Intune configuration. Ask for the baseline list and the settings each one locks.
Vendor update regression testing	Internal engineers or implementation partner	Recurring	Each browser, Office and PDF release can change hardened settings. Ask how often baselines are re-tested and who approves changes.
Log infrastructure and storage	Internal infrastructure team or hosting provider	Recurring	Driven by command line and PowerShell event volume and retention periods. Ask for storage sizing by fleet size and the retention period used to evidence ML2 logging.
Log protection and access controls	Internal security or infrastructure staff	One-time setup, recurring review	Covers protecting event logs from unauthorised modification and deletion. Ask how write access and deletion rights are restricted and reviewed.
Evidence upkeep	Internal compliance lead or consultant	Recurring	Covers keeping configuration exports, policy pass or fail reports and change records current. Ask what evidence is produced automatically and what needs manual collection.
External review or penetration testing (optional)	Independent testing firm, chosen by the organization	Recurring or per engagement	Not required by ML2 itself. Ask for the testing scope, the hardened applications covered and the report format.
Auditor or assessor sampling time	Independent auditor or assessor, not the implementation partner	Recurring per assessment cycle	Driven by the number of endpoints sampled and the quality of existing evidence. Ask the auditor how they sample and which artifacts they request.

Which open-source tools support ML2 hardening and logging evidence

Maturity Level Two hardening is evidenced through configuration checks on endpoints and central logs from the systems that record them. The tools below cover different parts of that evidence, and none of them proves the whole requirement on its own. Each card names what the tool produces and what the organization still has to confirm.

Wazuh configuration assessment scans

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies. The policies are mostly based on CIS benchmarks and can be extended with custom policies. Checks cover files, directories, registry keys and running processes, and each failed check comes with recommended remediation. For user application hardening, the useful output is a per-endpoint record of whether browser, Office and PDF settings match the chosen baseline. Confirm that the policies cover Office and PDF child process and executable content settings, and that the baseline you select matches the ASD and vendor guidance you adopted.

Fleet policies for device compliance

Fleet policies (MIT) ask each device a yes or no question written as an osquery query. The policies page shows which devices on each fleet pass or fail each policy, which gives a current view rather than a one-time scan. For this requirement, policies can check whether a browser has Java or internet-sourced advertising blocked, whether Office settings are locked, and whether PowerShell logging is enabled. Confirm that each policy tests the setting itself and not a proxy for it, and keep the policy definitions and their results as dated evidence for the assessor.

Application audit logs for other systems

The Nextcloud admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. OpenBao audit devices keep a JSON log of every API request and response, with most sensitive values hashed using HMAC-SHA256. These logs are useful evidence that those applications are being monitored. They do not evidence endpoint hardening. Browser, Office and PDF settings must come from configuration checks on endpoints and from central logging of PowerShell and command line events, so do not present these logs as proof of this requirement.

Confirm coverage and baseline match

No single tool proves Maturity Level Two alone. An assessor will look for three things: configuration evidence for each browser, Office and PDF product, central records of PowerShell module, script block and transcription events and command line process creation, and proof that those records are protected from modification and deletion. Ask the implementation partner to map each tool's output to the ISM controls in the Essential Eight ML2 profile, and confirm the chosen baseline in writing before the evidence is collected. The organization owns that decision and the assessment outcome.

Who does the user application hardening work and who assesses it

Your organization owns the controls. Ownership means the requirement, the configuration baseline and the risk decision stay with your staff, even when an outside party does the build work. For user application hardening at ML2, your team decides which browser, Office and PDF settings are locked, documents how vendor and ASD guidance were reconciled where they conflict, and records who approved each deviation.

Control ownership: Name an accountable owner for the browser, Office and PDF hardening baseline, and for the PowerShell and command line logging requirements.
Deviation approval: Record any exception to the most restrictive guidance, with a business reason, a risk acceptance and an expiry date.
Endpoint operations: Your endpoint management staff push the hardened settings, confirm they persist after updates and handle exceptions for users.
Log review: Someone on your team reviews centrally collected PowerShell and process creation events and acts on detected cyber security events, which ML2 expects to be analysed in a timely manner.
Incident handling: Your incident response plan defines how suspicious Office or PowerShell activity is escalated to the CISO.

Check that each control has a named owner who can explain the baseline and show the most recent review date.

Where user application hardening at ML2 usually falls short

Most organizations that claim Maturity Level Two for user application hardening have the right settings on paper. The gaps appear where policy is applied in one place and overridden in another, where logs exist on some machines but never reach a central store, where event logs can be changed without anyone noticing, and where deviations from guidance were made without a record. Each card below describes one gap and the check that exposes it.

Settings overridden outside policy

A browser, Office or PDF setting can be locked by a group policy or device profile and still be changed by a user through a local preference, a per-profile file or an application update that resets the value. The ML2 requirements expect users not to be able to change office suite and PDF security settings, so the test is practical: sign in as a standard user on a sample of endpoints from each build, open the application's security options, and confirm that each locked setting is greyed out and reports its policy source. Record which policy owns each setting so drift is traceable.

Logging enabled but not forwarded

PowerShell module logging, script block logging, transcription and command line process creation events are often switched on through local policy on some endpoints, while others were built from an older image and never received the setting. Even where the events are generated, they may stay in local event logs that are overwritten. For ML2, ISM-1623 and ISM-1889 require these events to be centrally logged. Check coverage by comparing the list of enrolled endpoints against the set of hosts that actually send these event types to the central platform, and treat any host that is missing from the central store as a gap.

Log tampering without alerts

Central logs protect little if an administrator can edit or delete events and nothing notices. ISM-1815 expects event logs to be protected from unauthorized modification and deletion at ML2 and ML3. In practice, check who holds write, delete and retention permissions on the log store, whether those changes are themselves logged, and whether an alert fires when log sources stop sending or when retention settings change. Ask the implementation partner or internal team to demonstrate a controlled test of deletion attempts and the resulting alert.

Undocumented guidance deviations

Hardening usually starts from ASD and vendor guidance, and the ISM requires the most restrictive guidance to win where sources conflict. Teams often disable a control that breaks a business application, or allow a child process for a plugin, and record the change only in a ticket or in someone's memory. The assessor will ask for the baseline, each deviation, its risk owner, its approval date and any compensating control. Keep a single register that links every deviation to the exact setting and the approval, and review it when either the vendor or ASD guidance changes.

Questions buyers ask about user application hardening ML2

What does maturity level two add to level one for user application hardening?

Level two keeps every level one requirement and adds more of the ISM controls that ASD maps to this strategy. The ISM v2026.09.4 Essential Eight profiles contain 46 controls at ML1 and 87 at ML2, and every ML1 control also sits in ML2. For this strategy, the practical additions are hardening Microsoft Office so it cannot create child processes, create executable content or inject code into other processes, and blocking Object Linking and Embedding package activation. PDF applications must be blocked from creating child processes, and users must be unable to change office suite or PDF security settings. ML2 also requires PowerShell module, script block and transcription events, and command line process creation events, to be centrally logged. Confirm the exact control wording against the ISM OSCAL profiles for your target version.

How much effort does user application hardening at ML2 take, and what drives it?

Effort depends mostly on how many Office and PDF installations you manage, how many of them already run under central policy, and how much the business depends on macros, embedded objects and plug-ins. Hardening Office and PDF software is usually a configuration exercise, but each restriction can break a workflow, so testing with real user groups takes time. Central logging is a separate workstream: you need a collector, retention, access controls on the logs, and alerting that someone reviews. The cost has three parts: internal staff time for policy design and testing, licensing or hosting for logging and policy tools, and any external help. Ask any quote to list the number of endpoints, applications in scope, the logging platform and who owns exception handling after go-live.

Can an internal team reach ML2 for this strategy without a partner?

Yes, if the team has Windows or endpoint administration skills, access to the ASD and vendor hardening guidance, and time to test changes against business workflows. Many organizations do the configuration in-house and bring in outside help only for logging design or for an independent check before assessment. The harder part is evidence: you must show the settings are applied everywhere in scope, that users cannot override them, and that logs are collected and reviewed. An internal team should ask whether it has the capacity to keep those records current after the first assessment, because drift tends to appear when staff change or software updates reset settings. DeployOpen can plan, implement and document this work under a fixed written scope, but the organization still owns its controls and decides what is in scope.

How long does it take to reach ML2 for user application hardening?

No duration can be stated here because it depends on the environment. The main drivers are the size and diversity of the Office, browser and PDF estate, whether configuration is already managed centrally, how many business applications break under the new restrictions, and whether a central logging platform exists or must be built. Organizations that already run device management and a log collector usually have a shorter path than those starting from unmanaged endpoints. Plan for time to test exceptions, obtain sign-off from application owners, and collect enough log history to show that events are being captured. Ask any provider for a schedule tied to a written scope with named milestones, and for the dependencies they expect you to clear, such as access to the management console or log storage.

Can DeployOpen or another firm issue an Essential Eight certificate?

No. There is no ASD certificate for the Essential Eight. It is a set of mitigation strategies, and maturity is shown by assessing how each strategy is implemented and whether it works against the maturity model. An independent assessor performs that assessment and reports on it. DeployOpen prepares systems, configuration, logging and evidence so that an assessor can test them, but it does not issue audit reports, attestations or certifications. Any firm that offers an Essential Eight certificate should be asked which body stands behind it and how that body's independence is maintained. Your own leadership remains responsible for stating your maturity level and for the controls you operate.

Which evidence should we prepare for an ML2 user application hardening assessment?

Assessors typically want to see the hardening baseline you applied, proof it is enforced on in-scope devices, and proof that users cannot change protected settings. Useful records include the policy documents, exported configuration reports for browsers, Office and PDF software, and samples of endpoints showing the settings in force. For logging, keep evidence that PowerShell and command line events reach the central store, that logs are protected from unauthorized change or deletion, and that someone reviews them with a record of follow-up. Open-source tools can produce some of this. Wazuh Security Configuration Assessment checks files, registry keys and running processes against YAML policies, and Fleet policies show which devices pass or fail a yes or no check. Confirm with your assessor which artifacts they accept before you build the process around them.

What changes after ML2 is reached, and what recurring work keeps it?

Reaching ML2 is not the end of the work. Recurring tasks include reviewing new Office, browser and PDF releases against the hardening baseline, re-testing after vendor updates that reset or add settings, approving exceptions with an expiry date, and reviewing logs for PowerShell and command line activity. Staff turnover and new applications also create drift, so the configuration needs an owner and a regular check. Recurring costs are mainly staff time and any retainer for support or continuous testing, which DeployOpen offers as a separate arrangement. Ask any provider to state which tasks are one-time and which recur, and who performs each one after handover.

How DeployOpen prepares ML2 user application hardening evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the hardening and logging behind User application hardening maturity level 2 is built where your systems run. We prepare systems and evidence for your assessor, while your organization owns the controls and an independent assessor reaches the conclusion.

How we scope

We agree a written scope covering which browsers, Office and PDF applications and PowerShell hosts are in ML2 scope.
Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work starts.
We confirm which ISM controls in the Essential Eight ML2 profile map to each system, and who in your organization owns each one.

How we build

We apply ASD and vendor hardening guidance to browsers, Office and PDF software, recording where the most restrictive guidance was applied.
We configure Office and PDF settings so child processes, executable content and code injection are blocked, and users cannot change them.
We centralize PowerShell module, script block and transcription events, plus command line process creation events, into a logging platform for review.

How we hand over

You receive configuration records, test results and a documented evidence pack organized by control ID for your assessor.
We document how central logs are protected from unauthorized modification and deletion, and how events are reviewed.
We walk your team through the runbooks for incident reporting to your CISO and the incident response plan, so ownership is clear.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover re-checking hardening after browser, Office and PDF updates, which changes settings over time.
Ask us to confirm in writing which recurring tasks are included, and which evidence your organization must keep running itself.