ASD ISM 2110Hardening User Applications with ASD and Vendor Guidance
User 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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
User application hardeningTopic
Hardening user application configurations
Official control statement
User applications are hardened using ASD and vendor hardening guidance, with the most restrictive guidance taking precedence when conflicts occur.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskRequest 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 atPick several settings from the baseline and, wherever the ASD and vendor recommendations differ, compare the recorded value against both sources.GoodFor every conflicting setting sampled, the baseline records the more restrictive of the ASD and vendor recommendations.
- AskRequest 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 atCompare 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.GoodThe live configuration matches the documented baseline, and hardening is applied centrally through Group Policy or MDM/Intune rather than configured manually on each device.
- AskRequest a demonstration on a sample endpoint of the high-risk application features covered by the hardening guidance.Look atCheck 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.GoodEach high-risk feature is actually disabled or constrained on the endpoint, consistent with the hardening baseline.
- AskRequest the change or version log for the sampled user applications and their hardening baselines.Look atFind recent application version updates and check whether the baseline was re-evaluated against both ASD and vendor guidance after each one.GoodEach recent version update is followed by a recorded review of the baseline against current ASD and vendor guidance, with any resulting changes applied.
- AskRequest a recent benchmark or compliance scan report covering application hardening on endpoints, plus the exceptions register.Look atReview the pass and fail results for the application hardening checks and trace any failures to a documented exception.GoodEndpoints pass the application hardening checks, and any deviations are formally documented as approved exceptions rather than left unexplained.
Cross-framework mappings
How ISM-2110 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 8.26 | ISM-2110 requires user applications to be hardened using ASD and vendor hardening guidance, including resolving conflicts by choosing the... | |
E8
| Control | Notes | Details |
|---|---|---|
linkRelated(5)expand_less | ||
| 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.2 | ISM-2110 requires user applications to be hardened using ASD and vendor guidance, choosing the most restrictive settings when guidance co... | |
| E8-AH-ML2.2 | ISM-2110 requires user applications to be hardened against common exploitation techniques using ASD and vendor hardening guidance, select... | |
| E8-AH-ML2.5 | ISM-2110 requires user applications to be hardened in accordance with ASD and vendor hardening guidance, applying the most restrictive gu... | |
| E8-AH-ML2.10 | ISM-2110 requires organisations to harden user applications using ASD and vendor guidance, prioritising the strictest requirements | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System hardening
See all Guidelines for system hardening controls, or browse the full ASD ISM library.