Essential Eight ML3: .NET 3.5 and PowerShell 2.0 hardening

What user application hardening maturity level 3 asks for

To reach Maturity Level Three for user application hardening, an organization must show that .NET Framework 3.5 is disabled or removed (ISM-1655), that Windows PowerShell 2.0 is disabled or removed (ISM-1621), and that PowerShell is configured to run in Constrained Language Mode (ISM-1622). These three controls are the ML3 additions in the Essential Eight baseline for this strategy, and an assessor will expect to see each one applied on endpoints and servers in scope, not only on a reference build. The point of all three is to remove options an adversary can use without bringing their own tools. Old .NET runtimes and PowerShell 2.0 can run scripts and components that bypass the logging and script controls added in newer versions, and unrestricted PowerShell gives an attacker a flexible, trusted interpreter already present on the host. This is the living-off-the-land risk that ML3 is designed to narrow.

The hard part is usually dependency, not configuration. Line-of-business applications, installers, reporting tools and older automation scripts often still call .NET 3.5 or PowerShell 2.0, and removing them can break a process that nobody has documented. Constrained Language Mode is also disruptive when enforced without testing, because scripts that use COM objects, Add-Type or other restricted features will fail. Before enforcing, confirm with each application owner which runtimes and PowerShell features they depend on, test scripts in a non-production group, and record exceptions with a planned retirement date. The evidence an assessor will ask for includes the configuration state on each in-scope device and a clear account of how exceptions are approved and tracked. Where Wazuh's Security Configuration Assessment or a similar tool is used, confirm which of these settings its policies check, because a policy that does not test them will not prove ML3 on its own.

Which systems fall under user application hardening maturity level 3

Maturity Level Three removes .NET Framework 3.5 and Windows PowerShell 2.0 and constrains PowerShell to Constrained Language Mode, so the work depends on which hosts run those components. The cards below are the scoping decisions to settle with each host class owner before anyone changes a configuration.

Workstations versus servers

Scope the ML3 changes separately for user workstations and servers, because the same registry or feature change can have very different effects on each. Workstations usually carry the widest mix of browsers, Office and PDF software, while servers host services that may silently depend on legacy runtimes. Ask the Windows team to produce a list of both host classes with their build, role and owner, then mark which ones are in the ML3 boundary. Name one accountable owner per class.

Legacy applications that need .NET 3.5

Some line-of-business applications still require .NET Framework 3.5, which includes .NET 2.0 and 3.0, and ISM-1655 requires it to be disabled or removed. Identify these applications before the change through software inventory, vendor support records and application owner interviews. Each one needs either a supported replacement, a documented exception with an owner and end date, or isolation on a host outside the ML3 boundary. Do not assume an application is unused because nobody has complained recently.

PowerShell hosts used by administrators

Administrators depend on PowerShell for daily work, so Constrained Language Mode will change how their scripts, modules and remote management sessions behave. Inventory the admin workstations, jump hosts and management servers where PowerShell runs, and test standard scripts against Constrained Language Mode before enforcement. Assign the admin team as owner of these hosts and agree how privileged scripts will be signed or reviewed. Confirm the exact enforcement method with Microsoft documentation for your Windows version.

Service accounts and scheduled PowerShell jobs

Service accounts and scheduled tasks often run PowerShell without any human session, which makes them easy to miss during scoping. Find every scheduled task, service and automation job that invokes PowerShell or the PowerShell 2.0 engine, including jobs on backup, monitoring and patching tools. Record the owning team for each job, and test each one under Constrained Language Mode before the setting is applied to the host it runs on.

Management tooling and endpoint security

Constrained Language Mode can break endpoint detection agents, configuration management and remote support tools that rely on full language features. Ask each tool vendor whether its agents, collectors and script runners work under Constrained Language Mode, and record the answer in writing. Name the owner of each management or security product as part of the host class decision, because a blocked agent can leave a host unmonitored without any visible alert.

Third-party and vendor-managed devices

Devices that a vendor, managed service provider or contractor administers are often outside the organization's direct change control, yet they may still sit on the same network. Confirm in the contract whether the vendor will apply the ML3 settings, provide evidence of them, and accept a configuration baseline. Where a vendor cannot make the change, document the device as out of scope with compensating controls and a named internal owner who is accountable for the risk.

How an assessor tests user application hardening maturity level 3

This table sets out how an assessor tests each of the three ML3 controls, what evidence they request and the findings that most often cause failures. Read each row as a test step: the method, the evidence to prepare in advance, and where implementations usually break down.

Control and test	Evidence requested	Common findings
ISM-1655: .NET Framework 3.5 disabled or removed. Assessor samples endpoints across each image and role, then checks the optional feature state of .NET Framework 3.5 (including .NET 2.0 and 3.0).	Feature state export per sampled endpoint, image build manifest, and configuration management report showing the setting applied.	Legacy feature enabled on older images or specific application servers, with no approved exception on file.
ISM-1621: Windows PowerShell 2.0 disabled or removed. Assessor checks the optional feature state on the same sample and confirms the engine cannot be started from a command prompt.	Optional feature state output, test command results showing the 2.0 engine does not start, and the golden image definition.	PowerShell 2.0 re-enabled by a new image build, a driver or vendor package, or a restored snapshot that predates the fix.
ISM-1622: PowerShell set to Constrained Language Mode. Assessor opens a live session on sampled endpoints and confirms the language mode reported by the session is Constrained.	Sample session output showing the language mode value, the policy or enforcement setting that sets it, and the sampling record.	Mode reported as Full Language on administrator or developer machines, or enforcement only applied to some user groups.
Exceptions and ownership. Assessor reviews any endpoint or account that differs from the baseline and checks for a named owner, a reason and a review date.	Exception register with owner, justification, compensating controls and approval record.	Exceptions with no documented owner, no expiry, or approvals given after the configuration was already changed.
Continuous evidence. Assessor asks how the organization detects drift between scheduled checks and assessment dates.	Scheduled policy results, drift alerts and records of remediation for failed checks.	Evidence captured once at the assessment date, with no recurring result that shows the state held over time.

How to implement the ML3 hardening steps in sequence

The sequence moves the organization from knowing which legacy features still run to a enforced PowerShell baseline with documented exceptions. Each step produces a record an assessor can check, so the ML3 position can be shown rather than asserted. Work begins with dependencies because removing a feature that a business application still needs is the most common reason this change stalls.

Inventory dependencies on .NET 3.5 and PowerShell 2.0
Identify every endpoint and server that has .NET Framework 3.5 (which includes .NET 2.0 and 3.0) or Windows PowerShell 2.0 enabled, and every application or script that relies on them. Ask the application owners and the platform team to confirm which workloads truly need each component, and record the result in a dependency register. The step is done when every enabled instance has a named owner and a stated reason, or is marked for removal. Confirm the inventory method with your endpoint management tooling, since feature state differs between images and in-service hosts.
Remove or disable legacy features in test images
Using the dependency register, disable or remove .NET Framework 3.5 and Windows PowerShell 2.0 in test builds of the standard workstation and server images, covering the controls ISM-1655 and ISM-1621. Test the business applications from the register against those builds, and log any breakage in a change record that names the feature removed, the test result and the rollback path. The step is done when the test images boot, the register's dependent applications pass testing, and the change record is approved by the change authority.
Pilot Constrained Language Mode on a monitored group
Configure PowerShell to use Constrained Language Mode, as ISM-1622 requires, on a small group of workstations and servers that already forward PowerShell logs to central monitoring. Watch for scripts that fail, administrators whose tooling is blocked, and any signs that the restriction is being bypassed. Record the outcomes in pilot results, including the scripts reviewed, the failures and how each was resolved. The step is done when the pilot group runs its normal work for a period you set with the security team and the results are reviewed and signed off.
Enforce the baseline through policy
Move the Constrained Language Mode setting and the legacy feature removal from manual configuration into centrally managed policy, so that new and rebuilt endpoints receive them automatically. Apply the policy to the pilot group first, then to the wider estate in controlled waves, and keep the policy under version control. The enforced baseline is the policy definition plus a compliance report showing which devices pass. The step is done when the report shows the intended population passing and the remaining gaps are tracked to an owner.
Verify compliance continuously with configuration checks
Schedule configuration checks that confirm the feature state and the PowerShell language mode on every endpoint, so drift is caught after enforcement rather than discovered at assessment. Open-source options such as Wazuh Security Configuration Assessment or Fleet policies can run these checks against registry keys and device state, but confirm the specific checks against your own images. Route failures into the incident or change workflow. The step is done when failing devices generate a ticket and the check results are retained as evidence.
Record exceptions and review them
Where a business application cannot run without .NET 3.5, PowerShell 2.0 or unrestricted language mode, record a formal exception in an exception log. Each entry should name the system, the dependency, the compensating measures, the risk owner who accepted it and a review date set by that owner. Remove or re-approve exceptions at each review. The step is done when every remaining deviation from the enforced baseline appears in the log with an accepted owner. Ask any outside assessor which exception evidence they expect before the review cycle is set.

Which open-source tools can produce ML3 hardening evidence

Four self-hosted open-source tools can collect configuration and endpoint state that supports the ML3 hardening controls. Each shows a different kind of evidence, from policy compliance scans to live queries and forensic collection, so teams usually combine them rather than relying on one. None of them decides whether an ML3 control is met; the organization and its assessor make that call.

Wazuh configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports misconfigurations with remediation advice. It checks files, directories, registry keys and running processes, so it can show whether a .NET Framework 3.5 or Windows PowerShell 2.0 setting is present on each host. Teams can add custom policies for the exact state their ML3 design requires. Before relying on it, confirm that a policy covers the .NET feature state and the PowerShell language mode, since a generic benchmark may not test them the way the ISM controls describe.

Fleet policies for pass or fail

Fleet policies ask each device a yes or no question written as an osquery query. The policies page shows which devices in a fleet pass or fail each one, which suits a direct check such as whether PowerShell 2.0 is still enabled or whether the PowerShell execution context is set to Constrained Language Mode. Write each policy so that a pass means the ML3 requirement is met, then keep the failing device list as dated evidence. Confirm how your Fleet version reports results for devices that have not checked in recently.

osquery system tables

osquery exposes running processes, loaded kernel modules, network connections and file hashes as SQL tables. For this control, the process table can show whether PowerShell 2.0 or a .NET 3.5 host is running, and the file table can confirm that a feature's files exist on disk. The osqueryd daemon runs scheduled queries across an entire fleet, which turns a one-time check into recurring evidence. Confirm which tables cover the registry or Windows optional feature state on your target operating system, because table availability differs by platform.

Velociraptor hunts for offline hosts

Velociraptor collects forensic artifacts defined in VQL from endpoints, and hunts collect one or more artifacts across a group of systems. A hunt can be scheduled to run on machines that were offline and collect when they reconnect, which matters for laptops that are often away from the network. Each hunt gets a notebook for analyzing the combined results, so a team can show the state of every workstation at one point in time. Velociraptor is a forensic and investigation tool first, so confirm that your artifacts actually read the .NET feature state and PowerShell language mode before counting them as control evidence.

What evidence passes an ML3 hardening assessment

What configuration baseline exports will an assessor expect to see?

The assessor expects exported configuration baselines for each browser, Microsoft Office, PDF software and PowerShell setting that the ML3 controls cover, showing the values applied to the production image or policy set. Export them from the tool that enforces the settings, such as Group Policy, Intune or your configuration management system, and keep the export with its date and the policy version. An export that only shows intent, without proof it reached endpoints, rarely satisfies an assessor on its own. Pair each export with a sample from a live host. Your team owns the baseline and its owner. An implementation partner can help build the export routine, but the organization owns the evidence. Review the baseline at each change window and at least once per quarter, recording who approved the review.

How do I prove .NET Framework 3.5 and PowerShell 2.0 are disabled?

A feature state report showing that .NET Framework 3.5 (which includes .NET 2.0 and 3.0) and Windows PowerShell 2.0 are disabled or removed on each in-scope host answers the two ML3 requirements directly. Generate the report from the operating system's feature inventory across a representative sample, and include the full population for systems that are hard to sample. Record the feature name, the state, the host identifier and the collection time. Scheduled osquery queries or a Wazuh configuration check can refresh this data, and the output can be stored as a dated file. Confirm the exact method with your assessor, since the evidence format is their call. Your staff owns the report, and a named engineer should sign off each refresh, typically monthly for production estates.

What does a PowerShell language mode check show an assessor?

A language mode check shows whether PowerShell on sampled hosts runs in Constrained Language Mode, which is the ML3 requirement for restricting PowerShell. Collect the value of the language mode from a session on each sampled host, along with the host name, user context and timestamp. Sampling should cover workstations, servers and the admin jump hosts where exceptions are most likely. Document the sampling method, since assessors check whether it is representative. Also record any host where the mode differs and link it to a change record. Keep the sample results in the evidence repository and refresh them on a schedule your assessor has agreed. Ownership sits with the security operations team, with the platform team responsible for remediating drift.

What change records should exist for hardening exceptions?

Every deviation from the ML3 baseline should have a change record that names the affected hosts or users, the business reason, the compensating control, the approver, the expiry date and the review outcome. Assessors look for exceptions that are approved, time-limited and tracked, not for a perfect estate with no exceptions. Store records in your change management system and cross-reference them from the baseline and scan reports. Expired exceptions should trigger a review, not silently continue. Ownership of the exception register belongs to the change advisory board or equivalent. Reviews are usually tied to each change cycle, and a full exception review should be scheduled at least once a quarter.

How do scan and policy results show hardening over time?

Pass or fail results over time show that hardening is maintained, not just achieved once. Wazuh Security Configuration Assessment can check endpoints for misconfigurations against YAML policies, including custom checks for registry keys and processes. Fleet policies, written as yes or no osquery questions, show which devices on each fleet pass or fail each check, and their history gives a trend line. Retain the raw results and the trend charts, and note when a policy changed so assessors can tell a real improvement from a rule edit. Your security team owns triage of failures, and results should be reviewed at least monthly, with each failure either fixed or linked to an exception record.

How should I keep these artifacts current between audits?

Keep each artifact on a fixed refresh schedule with a named owner and a named reviewer, and store every version in one evidence repository. A simple pattern works well:

Baseline exports: owner is the platform lead, refreshed at each policy change and reviewed quarterly.
Feature state reports: owner is the endpoint engineer, refreshed monthly.
Language mode samples: owner is security operations, refreshed monthly with a documented sample method.
Exception records: owner is the change board, reviewed quarterly and at expiry.
Scan and policy trends: owner is security operations, reviewed monthly.

Agree the cadence with your assessor before the audit window, because a cadence the assessor accepts is the one they will check. The organization owns these records. An implementation partner can set up the collection and the repository, and can document the routine, but cannot issue the assessment result.

What meeting user application hardening maturity level 3 costs

This table breaks the cost of ML3 application hardening into components, showing who is paid, whether each cost is one-time or recurring, and what pushes it up. Read it as a checklist for requesting a fixed-scope quote, since no prices or durations are supplied for this control. The main takeaway is that open-source tooling removes license spend but not the engineering and testing effort of removing legacy frameworks and constraining PowerShell.

Cost component	Who is paid	One-time or recurring	What drives it up
Dependency discovery for .NET Framework 3.5 and PowerShell 2.0	Internal engineers or implementation partner	One-time	Number of legacy applications and scripts that still call .NET 2.0 to 3.5 or PowerShell 2.0
Image and configuration changes	Internal platform team or implementation partner	One-time, then recurring with each image build	Host count, number of distinct golden images and build pipelines
Constrained Language Mode application testing	Application owners, QA staff, implementation partner	One-time, plus retesting on script or module changes	Number of admin tools, custom scripts and third-party modules that rely on full language features
Tooling and licenses	Tool vendor (commercial options) or none for open source	Recurring for commercial licenses; open-source software carries no license fee	Commercial endpoint or compliance suites priced per endpoint; self-hosted open-source tools still need hosting and staff time
Hosting and operating self-hosted tools	Internal infrastructure team or managed service provider	Recurring	Number of monitored endpoints, retention period for configuration and log data, and upgrade frequency
Evidence upkeep	Internal compliance or security team	Recurring	Frequency of configuration drift, change control volume and how often evidence is refreshed for assessment
External review or readiness assessment	Independent assessor or consultant	One-time per review cycle	Scope of systems in review and whether the review tests configuration evidence or only documentation
Auditor sampling	Independent assessor or certification body, paid by the organization	Recurring per assessment cycle	Number of hosts sampled and the depth of configuration evidence the assessor requests

Who does what for ML3 hardening: your team, a partner and the auditor

Your organization owns the control outcome. Only your staff can decide that legacy frameworks are no longer needed, that a PowerShell restriction is acceptable for a given workload, and that a deviation from the ISM baseline is justified and approved. Application owners confirm which business tools depend on .NET Framework 3.5 or Windows PowerShell 2.0 before anything is removed, because breaking a line-of-business application is the most common reason this work stalls.

Accountable control owner: a named person, usually in security or IT operations, signs off each ISM control in the ML3 profile and keeps its evidence current.
Application owners: they test dependent applications, report compatibility problems and accept the residual risk of any exception.
Exception approval: any control that cannot be met as written needs a documented, time-limited decision from someone with authority to accept risk.
Change management: removals and policy changes go through your normal change process, so rollback plans and maintenance windows are recorded by your staff.
Ongoing operation: your team reviews failing endpoints and keeps the configuration from drifting after the initial hardening.

Ask any partner to show you which decisions remain with your team in the written scope.

Where ML3 hardening efforts usually fall short

Most ML3 user application hardening work fails after the initial change, not during it. The gaps below tend to reappear through image rebuilds, undocumented dependencies, untested script changes, open-ended exceptions and point-in-time evidence. Each card names one gap and the fix that keeps the control in place.

PowerShell 2.0 reappearing after rebuilds

Windows PowerShell 2.0 must be disabled or removed at ML3 (ISM-1621). Teams often disable it on a running machine, then find it back after a new gold image is built from an older template or a feature update re-enables the optional component. The check is simple: confirm the feature state on every image and on a sample of live endpoints after each build, and treat a re-enabled engine as a failed control rather than a cosmetic drift. Record the check in the build pipeline so it runs on every release.

Undocumented .NET 3.5 dependencies

.NET Framework 3.5, which includes .NET 2.0 and 3.0, must be disabled or removed at ML3 (ISM-1655). Removal fails when a legacy line-of-business application, installer or reporting tool quietly depends on it. Before removal, inventory which applications load these runtimes, obtain written confirmation from each owner, and test the affected workflows in a staging image. Keep a dependency register with a named owner for any system that cannot yet be migrated, so the gap is visible rather than discovered during an assessment.

Constrained Language Mode enforced untested

PowerShell must use Constrained Language Mode at ML3 (ISM-1622). Turning it on across all endpoints can break administrative scripts, deployment tooling and monitoring agents that rely on full language features, and the breakage often surfaces during an incident. Pilot the mode on a representative group of admin workstations and servers, run the scripts your operations teams use every week, and log every failure with its fix. Confirm the setting is applied through policy and that a test script shows the restricted mode is active.

Exceptions without owners or expiry

Almost every legacy environment has a few machines or scripts that cannot meet the baseline on day one. The risk is that these exceptions accumulate with no accountable owner, no reason on record and no end date, so they become permanent gaps. Require each exception to name an accountable owner, the specific control affected, a compensating measure and a review date. Review the list on a fixed schedule and close expired items. An exception list without these fields will not survive an assessor's sampling.

Evidence collected once, not kept current

A clean configuration report from the week of rollout proves little about the state of the estate months later. ML3 requires that hardening remain in effect, so evidence should be generated continuously or on a recurring schedule. Use a self-hosted configuration assessment tool such as Wazuh Security Configuration Assessment to scan endpoints against policies, and a query tool such as Fleet policies to show which devices pass or fail each check. Store dated results with each review cycle so the trend is visible to an assessor.

Questions buyers ask about user application hardening maturity level 3

How long does user application hardening at maturity level 3 take to implement?

The duration depends on how many applications, browsers, Office versions and PowerShell environments sit in scope, and on how much legacy software still depends on .NET Framework 3.5 or Windows PowerShell 2.0. Timing is driven by four factors: the size of the device estate, how many line-of-business applications must be tested after removing legacy components, the change control process for workstations and servers, and whether PowerShell scripts used by administrators or automation need rewriting to work under Constrained Language Mode. Ask any partner for a written plan that lists each phase, the systems in each phase and the testing gates, rather than a single overall figure. Treat a timeline offered without an inventory of legacy dependencies as an estimate that has not yet been tested.

Can we implement user application hardening level 3 in-house?

Yes, in most organizations the controls are implemented by the internal team, provided it has access to the endpoint management tooling, the authority to remove legacy features and the skills to test business applications after changes. The work is largely configuration and testing: identifying where .NET Framework 3.5 and Windows PowerShell 2.0 are still used, disabling or removing them, setting PowerShell to Constrained Language Mode and then confirming the result across the estate. Teams often bring in outside help for the inventory, for rewriting scripts that break, or for independent verification before an assessment. Whatever the split, the organization owns the controls and the evidence. An implementation partner can prepare systems and evidence, but only an independent assessor issues the assessment outcome.

What do application owners need to provide during ML3 hardening?

Application owners are the people who know whether a business system actually needs .NET Framework 3.5 or Windows PowerShell 2.0, so their input decides what can be removed safely. They should confirm the runtime and scripting dependencies of each application, identify which vendors have certified newer versions, and schedule test windows with the endpoint team. They also need to review PowerShell scripts that rely on features blocked in Constrained Language Mode and either update them or document an approved exception. For illustrative purposes, a finance application that calls a legacy .NET component would need either a vendor upgrade or a documented risk decision before the component is removed. Clear sign-off from application owners is a practical record that the change was tested and accepted.

How much does user application hardening level 3 cost, and what drives the price?

No fixed figure applies to every organization, and this page does not publish one. Costs fall into three groups: internal staff time for inventory, testing and change management; licensing for endpoint management or configuration tooling already in use; and any external services for implementation, script remediation or verification. One-time costs include the discovery exercise, the initial removal of legacy components and the testing effort. Recurring costs include reviewing new applications for legacy dependencies, retesting after patches and maintaining evidence. Costs rise with the number of applications, the age of the estate, the number of custom scripts and the level of vendor involvement. When requesting a quote from a partner, ask for a written scope listing systems, deliverables, exclusions and the evidence to be produced. DeployOpen does not publish a price list, and quotes follow from the written scope.

Can an implementation partner issue an Essential Eight assessment for us?

No. An implementation partner can plan, configure, document and prepare evidence for user application hardening, but it cannot issue an assessment or certificate. The Essential Eight is a set of mitigation strategies rather than a certification scheme, so there is no ASD certificate to obtain. Maturity is evidenced through an assessment of each strategy's implementation and effectiveness against the maturity model, and that assessment must be carried out by an independent assessor. Organizations should ask whether the assessor is independent of the implementation work, which evidence it will request and how findings will be recorded. DeployOpen prepares systems, controls and evidence for compliance assessments; it does not issue audit reports, attestations or certifications.

How do we keep ML3 PowerShell and .NET controls current after the first assessment?

The controls stay effective only if they are monitored continuously. The main risks are new applications that reintroduce .NET Framework 3.5 or Windows PowerShell 2.0, new images or devices built from old templates, and administrators who run scripts that Constrained Language Mode blocks, which can lead to informal workarounds. Practical recurring tasks include scheduled configuration checks, reviewing exceptions, and retesting after major operating system and application updates. Open-source tools can support this. Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies that check files, registry keys and running processes, and it can be extended with custom policies. osquery exposes running processes and installed software as SQL tables, and Fleet policies ask yes or no questions of devices as osquery queries, with a page showing which devices pass or fail each policy. Confirm that any chosen tool can check the specific registry and feature settings you need before relying on it.

How DeployOpen scopes and prepares ML3 hardening evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so ML3 hardening for .NET Framework 3.5, Windows PowerShell 2.0 and Constrained Language Mode is built into systems you control. We prepare the configurations and evidence, while your organization owns the controls and an independent assessor reaches the conclusion.

How we scope

Engagements are fixed-scope, with the device groups, operating systems and browsers covered agreed in writing before work starts.
The written scope lists which hosts are in ML3 scope and which are excluded, with reasons recorded.
We confirm which PowerShell entry points, including scripts and automation accounts, must run in Constrained Language Mode.

How we build

We check each host for .NET Framework 3.5 and Windows PowerShell 2.0 features and disable or remove them where found.
We configure PowerShell to Constrained Language Mode through your existing management tooling, then test that approved scripts still run.
We extend timely event log analysis to workstations and non-internet-facing servers so that ML3 log checks have data to work from.

How we hand over

You receive configuration records, test results and before-and-after compliance reports for each in-scope device group.
Documentation maps each change to its ISM control identifier, so your assessor can trace the evidence to the requirement.
Exception handling for any legacy script or tool that cannot run in Constrained Language Mode is documented with an owner and review date.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover recurring configuration checks that detect drift from the ML3 baseline on monitored endpoints.
An independent auditor or certification body issues any report or conclusion. We prepare the systems and evidence for that assessment.

User application hardening maturity level 3