ASD ISM 1824Lock PDF Application Security Settings Against User Changes
Official control statement
PDF application security settings cannot be changed by human users.
Quoted as published. Everything else on this page is written by Control Stack.
In plain English
The security settings of the PDF software on your systems are locked centrally so people cannot weaken or switch them off, whether by mistake or on purpose.
What this means in practice
PDF readers and editors (for example Adobe Acrobat Reader, Foxit or the PDF handling built into a browser) have security settings that decide how the application behaves when a document tries to do something risky. These settings govern things like whether the document opens inside a protected sandbox, whether JavaScript inside a PDF is allowed to run, whether the file can launch other programs or open web links, and whether embedded content and attachments are treated as trusted. This control says those settings must be set by the organisation and locked so that ordinary people using the computer cannot change them. The user should not be able to open the application's preferences and switch a protection off, add a document or folder to a trusted list, or otherwise loosen the configuration. It matters because PDF files are one of the most common ways malicious content reaches a workstation. An attacker who emails a booby-trapped PDF is relying on the application to do something unsafe when the file opens. If a person can turn off the protections (often because a pop-up or a helpful-looking instruction tells them to), the hardening you rolled out is only as strong as the least cautious person in the office. Locking the settings means the protection is decided once, centrally, and stays in place no matter who is using the machine or what a document asks them to do.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
ML2, ML3
Guideline
Guidelines for system hardeningSection
User application hardeningTopic
Portable Document Format applications
Why it matters
If people can change PDF application security settings, any user can disable protections such as sandboxing, JavaScript blocking or link and attachment restrictions, either deliberately or because a malicious document tricked them into it. A single weakened workstation then becomes an easy entry point: a crafted PDF can run code, launch programs, fetch remote content or exploit an application vulnerability, leading to malware infection, credential theft and a foothold on the network. The organisation also loses assurance that its hardening baseline is actually applied, because the deployed settings and the effective settings can silently drift apart on any machine.
Operational notes
Day to day, this control lives in your endpoint configuration management rather than in people's hands. The PDF application's security settings are defined in a central policy (Group Policy, Intune or another MDM configuration profile, or the vendor's enterprise customisation tooling) and pushed to every device that has the application installed. The settings are applied in a locked or enforced mode so that the relevant options are greyed out, hidden or reverted if a user tries to change them.
When a new PDF application or a major version is introduced, the same locked settings need to be defined for it before it is rolled out; a fresh install with default, user-editable preferences is a gap. If people use more than one PDF application (a dedicated reader plus a browser's built-in viewer, for example), each one needs to be covered.
Expect occasional requests from users who want a feature back, such as clickable links or form scripting for a particular document. Handle these through your normal change and exception process, with the change made centrally and recorded, rather than by giving the user a way to alter the setting locally. Periodically confirm that the effective settings on a sample of workstations still match the policy, particularly after application updates, image rebuilds or policy restructures, because these are the points where lock-down commonly falls away.
Implementation tips
- The IT or endpoint team identifies every PDF application in use across the fleet (dedicated readers and editors, plus browser-integrated PDF viewers) by querying the software inventory tool, so the lock-down can be applied to all of them rather than just the main reader.
- The endpoint administrator defines the required security settings for each PDF application in a central policy, using the vendor's administrative templates or enterprise customisation kit (for example Group Policy ADMX files, an Intune or MDM configuration profile, or a registry or plist policy set), rather than configuring preferences by hand on individual machines.
- The endpoint administrator deploys the settings in enforced or locked mode, using the policy keys the vendor designates as non-overridable (such as lockdown or FeatureLockDown style keys), so the relevant options are greyed out or hidden in the application's preferences and any local change is reverted.
- The endpoint administrator adds the locked PDF settings to the standard operating environment build and the application packaging process, so newly imaged devices and newly installed or upgraded PDF applications receive the locked configuration automatically rather than shipping with editable defaults.
- The IT team sets up a compliance check in the configuration management or endpoint management tool that reads the effective PDF security settings on each device and flags any machine where the values differ from policy, then remediates by re-applying the policy.
Audit / evidence tips
- AskAsk for the list of PDF applications approved and installed across the organisation, and the central policy that configures each of them.Look atCheck that every PDF application in the software inventory, including browser-based viewers, has a corresponding policy that sets its security settings.GoodEach PDF application in use is covered by a documented central policy; there are no readers or viewers that rely on default, user-editable settings.
- AskAsk for an export of the policy objects or configuration profiles that apply the PDF security settings.Look atLook for the specific settings being applied in locked or enforced mode (the vendor's lockdown or non-overridable keys) rather than as user-changeable preference defaults.GoodThe settings are applied through enforced policy keys that the application treats as locked, so users cannot alter them through the preferences interface.
- AskAsk to observe a standard user account opening the PDF application's preferences on a normal workstation.Look atWatch whether the security-related options are greyed out, hidden or revert after a change is attempted.GoodA standard user cannot change or switch off the security settings; the options are locked and any attempted change does not take effect.
- AskAsk for a recent compliance or configuration report showing the effective PDF security settings on a sample of devices.Look atCompare the effective values on each device against the policy and check for any devices flagged as non-compliant or missing the policy.GoodThe effective settings match the policy across the sample, and any non-compliant devices are identified and remediated through a defined process.
- AskAsk how a request to relax a PDF security setting for a user or team would be handled, and for records of any such requests.Look atCheck that changes are made centrally through a change or exception process, not by granting users local control over the settings.GoodExceptions are rare, approved, made in the central policy and recorded; there is no route for an individual user to change the settings on their own device.
Cross-framework mappings
How ISM-1824 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.9 | ISM-1824 requires centrally locking PDF application security settings so users cannot change them | |
E8
| Control | Notes | Details |
|---|---|---|
equalEquivalent(1)expand_less | ||
| E8-AH-ML2.10 | ISM-1824 requires PDF application security settings to be locked so human users cannot change them | |
sync_altPartially overlaps(2)expand_less | ||
| E8-AH-ML2.7 | ISM-1824 requires PDF application security settings to be locked against user changes | |
| E8-AH-ML2.9 | E8-AH-ML2.9 requires PDF software to be hardened using ASD and vendor guidance, ensuring secure baseline settings are applied | |
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.