ASD ISM 2110 Hardening user applications with ASD and vendor guidance
What it says
User applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUser applications are hardened by applying both ASD and vendor hardening guidance to their configurations, and where the two conflict the more restrictive setting is applied.
This control is about locking down the configuration of everyday user applications such as web browsers, Microsoft Office, PDF readers and the .NET framework. You harden them against two sources of guidance at once: the ASD hardening guides and the software vendor's own hardening advice. When the two disagree on a setting, you must apply whichever option is more restrictive (the stricter, more secure value wins). The goal is to remove insecure default settings and unneeded features so the application is harder to abuse.
Free. Save your status, tasks and notes.
Why it matters
If user applications keep their default or insecure configurations, attackers can exploit them as an initial-access vector: malicious Office documents running macros, browsers executing untrusted active content or weak scripting, PDF readers launching embedded JavaScript or executables, and unconstrained .NET or scripting features being abused to run code. Without applying both ASD and vendor hardening (and the most restrictive value on conflict), exploitable features stay enabled, giving adversaries an easy foothold for code execution and lateral movement from an ordinary user's workstation.
How to implement
Obtain the current ASD hardening guidance for each high-risk user application (web browsers, Microsoft Office, PDF readers, .NET framework) and the matching vendor hardening guide, then build one configuration baseline per application listing every recommended setting.
Where an ASD setting and a vendor setting for the same control conflict, apply the more restrictive value in the baseline and record a one-line rationale noting which source was stricter so the choice is traceable.
Disable or constrain unneeded high-risk features per the guidance: for example block or restrict Office macros (especially macros from the internet), disable browser legacy/active content and unneeded plugins, disable PDF reader embedded JavaScript and launch/execute actions, and restrict .NET scripting where not required.
Encode each baseline as enforceable policy: build Group Policy Objects (using vendor ADMX templates such as the Office and browser administrative templates) for domain-joined devices.
For cloud-managed or modern endpoints, deploy the same hardening settings as Microsoft Intune (or other MDM) configuration profiles so the settings are pushed and locked to managed devices.
Run a configuration scan (ASD/CIS-style benchmark tooling) after deployment to confirm live settings match the baseline, then re-review and re-apply the baselines whenever a new application version is released.
Keep it running
Maintain a documented hardening baseline per application (browsers, Microsoft Office, PDF readers, .NET) that records each setting, its ASD-recommended value, its vendor-recommended value, and the chosen value with a note where the more restrictive option was selected. Re-check both the ASD hardening guides and vendor hardening advice whenever a new application version ships, as new versions add features and change defaults that may need re-hardening. Enforce the baselines centrally through Group Policy or MDM (for example Microsoft Intune) rather than by manual configuration, and periodically scan endpoints to confirm the live settings still match the baseline and have not drifted. When ASD and vendor guidance conflict, keep a short rationale showing the stricter value was applied so the decision is defensible at audit.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Request the documented hardening baseline for a sampled user application (for example Microsoft Office) together with the ASD and vendor hardening guidance it was built from.
Look at
Pick several settings from the baseline and, wherever the ASD and vendor recommendations differ, compare the recorded value against both sources.
Good evidence
For every conflicting setting sampled, the baseline records the more restrictive of the ASD and vendor recommendations.
- Check 2 of 5What an auditor asks for
Ask for
Request the live configuration from a sample endpoint (a GPO result, Intune profile, or registry/settings export) and the deployed policy objects that apply it.
Look at
Compare the endpoint's applied settings for browsers, Office, PDF readers and .NET against the documented hardening baseline, and inspect the policy objects and their assignment scope to see how the settings are enforced.
Good evidence
The live configuration matches the documented baseline, and hardening is applied centrally through Group Policy or MDM/Intune rather than configured manually on each device.
- Check 3 of 5What an auditor asks for
Ask for
Request a demonstration on a sample endpoint of the high-risk application features covered by the hardening guidance.
Look at
Check whether Office macros are restricted or blocked, browser active and legacy content is disabled, and PDF reader embedded JavaScript and launch actions are turned off.
Good evidence
Each high-risk feature is actually disabled or constrained on the endpoint, consistent with the hardening baseline.
- Check 4 of 5What an auditor asks for
Ask for
Request the change or version log for the sampled user applications and their hardening baselines.
Look at
Find recent application version updates and check whether the baseline was re-evaluated against both ASD and vendor guidance after each one.
Good evidence
Each recent version update is followed by a recorded review of the baseline against current ASD and vendor guidance, with any resulting changes applied.
- Check 5 of 5What an auditor asks for
Ask for
Request a recent benchmark or compliance scan report covering application hardening on endpoints, plus the exceptions register.
Look at
Review the pass and fail results for the application hardening checks and trace any failures to a documented exception.
Good evidence
Endpoints pass the application hardening checks, and any deviations are formally documented as approved exceptions rather than left unexplained.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML1.1, Disable or remove Internet Explorer 11, which this control covers in full and more.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.26.
ISM-2110 requires user applications to be hardened using ASD and vendor hardening guidance, including resolving conflicts by choosing the most restrictive configuration. ISO/IEC 27001:2022 Annex A 8.26 requires security requirements for applications to be identified, specified and approved when developing or acquiring applications, which can include hardening and secure configuration baselines. The overlap is around defining and applying security requirements for applications, but ISM-2110 is operational hardening guidance-focused, while Annex A 8.26 is broader across the application lifecycle (development/acquisition requirements) and governance/approval.
ASD Essential Eight: 5 mappings
This control is broader than E8-AH-ML1.1.
ISM-2110 requires hardening of user applications in line with ASD and vendor hardening guidance, prioritising the strictest requirement. E8-AH-ML1.1 requires disabling or removing Internet Explorer 11, which is a specific application-hardening action consistent with ASD guidance and would be implemented as part of meeting ISM-2110 for browser/application baselines. E8-AH-ML1.1 is a single-application measure, while ISM-2110 is a general obligation applying across all user applications.
This control is broader than E8-AH-ML1.2.
ISM-2110 requires user applications to be hardened using ASD and vendor guidance, choosing the most restrictive settings when guidance conflicts. E8-AH-ML1.2 mandates a specific browser hardening outcome (browsers must not process Java from the internet) that would typically be achieved by applying ASD/vendor browser hardening baselines under ISM-2110. The candidate is narrower because it targets one feature in one application category, whereas ISM-2110 covers hardening across all user applications.
This control is broader than E8-AH-ML2.2.
ISM-2110 requires user applications to be hardened against common exploitation techniques using ASD and vendor hardening guidance, selecting the most restrictive settings where guidance conflicts. E8-AH-ML2.2 mandates a particular Microsoft Office hardening control (blocking Office from creating child processes) that would typically be included in Office hardening baselines applied to meet ISM-2110. The candidate is narrower because it is one prescriptive setting for one application suite, while ISM-2110 covers all user applications and all relevant hardening guidance.
This control is broader than E8-AH-ML2.5.
ISM-2110 requires user applications to be hardened in accordance with ASD and vendor hardening guidance, applying the most restrictive guidance where there is conflict. E8-AH-ML2.5 is a specific Microsoft Office hardening requirement (prevent activation of OLE packages) that would typically be derived from ASD/Microsoft guidance applied under ISM-2110. E8-AH-ML2.5 is therefore a concrete subset implementation example within the broader hardening obligation of ISM-2110.
This control is broader than E8-AH-ML2.10.
ISM-2110 requires organisations to harden user applications using ASD and vendor guidance, prioritising the strictest requirements. E8-AH-ML2.10 focuses specifically on locking down PDF application security settings so users cannot weaken them, which is a common hardening outcome expected when applying vendor/ASD baselines under ISM-2110. The candidate is narrower because it applies to one application class and one hardening outcome, while ISM-2110 covers all user applications and the full set of hardening guidance.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.