Hardening 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
19 June 2026
E8 maturity levels
N/A
Guideline
Guidelines for system hardeningSection
User Application HardeningOfficial 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
- For a sampled application (for example Microsoft Office), pick several settings from the hardening baseline and confirm the recorded value equals the more restrictive of the ASD and vendor recommendations wherever the two differ.
- Pull the live configuration from a sample endpoint (GPO result, Intune profile, or registry/settings export) and confirm it matches the documented hardening baseline for browsers, Office, PDF readers and .NET.
- Confirm high-risk features are actually disabled or constrained on endpoints: for example Office macros restricted/blocked, browser active and legacy content disabled, and PDF reader embedded JavaScript and launch actions turned off.
- Check that hardening is enforced centrally via Group Policy or MDM/Intune rather than configured manually per device, by inspecting the deployed policy objects and their assignment scope.
- Confirm the baselines were re-evaluated against both ASD and vendor guidance after recent application version updates, using the change/version log.
- Review a benchmark or compliance scan report and confirm endpoints pass the application hardening checks, with any deviations formally documented as exceptions.
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_alt Partially 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 |
|---|---|---|
| link Related (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.