ASD ISM 1824 Lock PDF application security settings against user changes
What it says
PDF application security settings cannot be changed by human users.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishThe 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of PDF applications approved and installed across the organisation, and the central policy that configures each of them.
Look at
Check that every PDF application in the software inventory, including browser-based viewers, has a corresponding policy that sets its security settings.
Good evidence
Each PDF application in use is covered by a documented central policy; there are no readers or viewers that rely on default, user-editable settings.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export of the policy objects or configuration profiles that apply the PDF security settings.
Look at
Look 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.
Good evidence
The settings are applied through enforced policy keys that the application treats as locked, so users cannot alter them through the preferences interface.
- Check 3 of 5What an auditor asks for
Ask for
Ask to observe a standard user account opening the PDF application's preferences on a normal workstation.
Look at
Watch whether the security-related options are greyed out, hidden or revert after a change is attempted.
Good evidence
A standard user cannot change or switch off the security settings; the options are locked and any attempted change does not take effect.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a recent compliance or configuration report showing the effective PDF security settings on a sample of devices.
Look at
Compare the effective values on each device against the policy and check for any devices flagged as non-compliant or missing the policy.
Good evidence
The effective settings match the policy across the sample, and any non-compliant devices are identified and remediated through a defined process.
- Check 5 of 5What an auditor asks for
Ask for
Ask 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 at
Check that changes are made centrally through a change or exception process, not by granting users local control over the settings.
Good evidence
Exceptions 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.
Mappings
Closest match in ASD Essential Eight: E8-AH-ML2.10, PDF software security settings cannot be changed by users, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.9.
ISM-1824 requires centrally locking PDF application security settings so users cannot change them. Annex A 8.9 requires organisations to establish, document, implement, monitor and review secure configurations across hardware, software, services and networks. ISM-1824 is a specific, product/domain-focused instance of broader configuration management expectations in Annex A 8.9.
ASD Essential Eight: 3 mappings
This control is equivalent to E8-AH-ML2.10.
ISM-1824 requires PDF application security settings to be locked so human users cannot change them. E8-AH-ML2.10 states the same requirement: PDF software security settings cannot be changed by users. Both controls focus on preventing user-initiated weakening of PDF security configuration via centrally enforced immutability.
This control partially overlaps E8-AH-ML2.7.
ISM-1824 requires PDF application security settings to be locked against user changes. E8-AH-ML2.7 similarly requires office productivity suite security settings to be immutable by users, reflecting the same governance pattern of centrally enforced application hardening. They overlap on the concept of preventing users from weakening application security through immutability, applying to different application families (PDF software vs office suites).
This control partially overlaps 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. ISM-1824 relates by requiring PDF application security settings cannot be changed by users, which helps preserve the hardened configuration established under E8-AH-ML2.9. E8-AH-ML2.9 focuses on selecting and applying hardening settings, whereas ISM-1824 focuses on enforcing configuration immutability to prevent user-driven weakening of those settings.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.