Adobe Acrobat and Reader Enterprise Hardening: Lock Down Sandboxing, JavaScript and Trust Settings

PDF readers open untrusted files from email, the web and shared drives every day, so the way Acrobat and Reader are configured decides how much a malicious PDF can do on the endpoint. Adobe publishes an Application Security Guide for Acrobat and Acrobat Reader that describes the sandbox (Protected Mode, Protected View and AppContainer), Enhanced Security, JavaScript controls, attachment rules and the trust model built on privileged locations. Almost every one of these settings has a user preference and a machine-level FeatureLockDown value that IT can lock, on Windows through the registry and Group Policy, and on macOS through a root-owned plist. This guide turns that material into a baseline you can deploy, test and monitor. It is for endpoint engineers, desktop administrators and security teams responsible for managed Windows and Mac fleets.

This is an independent guide from NHI Mgmt Group, based on Adobe's public documentation as of November 2026. It is not sponsored or reviewed by Adobe. Product features change, so confirm settings against Adobe's current documentation.

Key takeaways

• Lock, do not just set. Values under HKCU\...\Privileged, TrustManager or JSPrefs are user preferences; the matching DWORDs under HKLM\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown are what make a setting stick and grey out the UI.
• Protected View is opt-in. Adobe documents the iProtectedView default as "never"; set it to cover files from untrusted locations (Adobe's recommended option) and keep Protected Mode on, because Protected View depends on it.
• Privileged locations are the bypass list. Files, folders and hosts listed there skip Enhanced Security and can render content that is otherwise blocked, so lock bDisableTrustedFolders and bDisableTrustedSites and publish a short admin-managed list instead.
• Treat JavaScript as a feature you grant. Turn off bEnableJS where workflows allow it; where forms need scripts, use the enterprise tBlackList of risky APIs and keep menu-item JavaScript off (its default since Acrobat 7.0).
• Pick a track and patch on it. Continuous and Classic tracks update differently; decide whether the Adobe updater or your own tooling installs updates, and lock that choice with the ARM Mode value (Adobe documents bUpdater separately: it disables web-plugin component updates and all services, not product updates).

How identity and access work in Acrobat and Reader

On a managed endpoint, "access" for a PDF reader means two things: who is licensed and signed in to the application, and what a document is allowed to do once it is open. The second matters more for hardening, and Acrobat expresses it as trust.

Track identification matters for every registry path below. Adobe's admin guide explains that the version hive is DC for the Continuous track and a year (2015, 2017, 2020) for Classic, and that the first two digits of the minor version field are 20 for Continuous and 30 for Classic. Write your policies for the hive that is actually installed.

Admin roles and privileged access

Hardening a PDF reader is mostly about removing the ability of users, and of documents acting as users, to make privileged changes.

• Machine policy owners: only the team that owns endpoint configuration should edit FeatureLockDown. On Windows these keys sit under HKLM and need administrator rights. On macOS the lockdown file is /Library/Preferences/com.adobe.Acrobat.Pro.plist or com.adobe.Reader.plist, which Adobe says should be a system-level plist owned by root.
• Do not edit the application bundle: Adobe's Mac guide warns against editing the featurelockdown file inside the app package; the application merges Adobe's file with yours at runtime.
• Trust additions are privileged actions: a user who clicks "always trust" in the Yellow Message Bar adds a privileged location. Locking bDisableTrustedFolders = 1 and bDisableTrustedSites = 1 removes that ability; the admin-defined list under FeatureLockDown\cTrustedFolders or cTrustedSites then becomes the only source of trust.
• High-privilege JavaScript: Adobe distinguishes the admin list under FeatureLockDown\(cTrustedSites or TrustedFolders)\cJavaScript from user lists under TrustManager. Keep high-privilege JavaScript to the admin list, and treat the cUnsafeJavaScript user override, which lets blacklisted APIs run in a trusted context, as something to detect and remove.
• Certified document trust: bTrustCertifiedDocuments is off by default. If signed internal forms need it, lock it centrally with bEnableCertificateBasedTrust and keep the list of trusted signing roots short.

Endpoint local admin rights undo all of this, because a local administrator can rewrite HKLM. Pair this baseline with standard user accounts and controlled elevation; see the Endpoint Hardening Checklist.

Integrations, API tokens and service accounts

Acrobat desktop reaches outward through cloud services, storage connectors, e-signature and web links. Each is a path for data to leave or content to arrive, and each is customer-configurable.

The service identities here are your deployment tooling. The account that pushes Group Policy, Intune or Jamf configuration can change every value on this page, so manage it as a privileged non-human identity with its own credential hygiene and change history. See the Non-Human Identity (NHI) Guide.

Logging and detection

Acrobat writes little security telemetry of its own, so detection relies on endpoint tooling watching the reader process and its configuration.

• Configuration drift: monitor registry changes under HKCU\Software\Adobe\<product>\<version>\Privileged, \TrustManager (new cTrustedFolders or cTrustedSites entries, cUnsafeJavaScript, bTrustOSTrustedSites) and \JSPrefs. Locked HKLM values make user changes ineffective, but changes still signal tampering or a user working around policy.
• Sandbox status: Adobe's documented checks are two reader processes running, and File > Properties > Advanced showing "Protected Mode: On". Turn that into an EDR or inventory query for a single, unsandboxed reader process.
• Protected Mode broker log: tBrokerLogfilePath sets a log that records sandbox policy violations. Adobe positions it for troubleshooting, so enable it on a pilot group when testing plugins, not fleet-wide.
• Child processes: alert when the Acrobat or Reader process launches script hosts, shells or unusual executables, which maps to ATT&CK T1204.002 Malicious File after delivery by T1566.001 Spearphishing Attachment. JavaScript in documents maps to T1059.007.
• Version compliance: report installed versions against the latest release on your track from Adobe's security bulletins page.

Hardening baseline

Values below are from Adobe's Application Security Guide and Preference Reference. Paths use the Windows policy form HKLM\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown, where product is, for example, "Adobe Acrobat" or "Acrobat Reader" and version is DC or the Classic year. On 64-bit Windows several Adobe pages show the WOW6432Node form; check which one your build reads before rollout. On macOS, add the same names, with their data type prefix, under FeatureLockDown in the version hive of the root-owned plist.

JavaScript itself is a user preference: bEnableJS = 0 under HKCU\Software\Adobe\<product>\<version>\JSPrefs. Push it through Group Policy Preferences or Intune for groups whose documents never need scripts, and use the enterprise blacklist for everyone else. The same reasoning drives macro control in Office; see the Office Macro Blocking Guide.

Rollout sequence

1. Inventory: record product (Acrobat or Reader), track, version hive and licensing model on every endpoint, and list business workflows that rely on forms, scripts, signatures or connectors.
2. Baseline on a pilot ring: deploy the sandbox, Enhanced Security and trust locks to IT and security staff first; enable tBrokerLogfilePath to catch plugins that break under Protected Mode.
3. Fix exceptions properly: where a plugin needs extra sandbox rights, use Adobe's policy file (ProtectedModeWhitelistConfig.txt with bUseWhitelistConfigFile = 1, or cProtectedModeConfigFiles for plugins) rather than turning Protected Mode off.
4. Publish the admin trust list: add only the internal file shares and hosts that genuinely need privileged status, never a temp directory (Adobe does not allow one).
5. JavaScript and attachments: roll out the API blacklist and attachment permissions to a second ring, then fleet-wide.
6. Lock updates: confirm the updater or your patch tool owns updates, then lock it.
7. Roll back safely: each control is one registry value or plist key, so roll back by removing that value through the same policy object, not by uninstalling the reader.

Common misconfigurations

• Setting HKCU values and calling it done: user preferences can be changed by the user or by a script in their context. Only FeatureLockDown values are enforced.
• Policy written for the wrong hive: a DC path does nothing on a Classic 2020 install, and the reverse. Validate against the installed track.
• Turning off Protected Mode to fix a plugin: this also disables Protected View. Use the sandbox policy file instead.
• Broad privileged locations: trusting a whole mapped drive or a wildcard host gives every file there internet access and exemption from Enhanced Security. Keep entries narrow; Adobe notes recursion is on by default from 10.1.
• Leaving OS zone trust on: bTrustOSTrustedSites extends trust to Windows zones, including Local Intranet, so a sprawling intranet zone becomes a sprawling privileged location.
• Disabling the updater with no replacement: bUpdater = 0 stops Adobe updates and services; if no other tool deploys patches, the fleet drifts. Apply vendor security updates promptly using the Adobe security bulletins for Acrobat and Reader.

Framework mapping

Practitioner checklist

• Record product, track and version hive for every installed reader before writing policy.
• Lock bProtectedMode and bEnableProtectedModeAppContainer to 1 on Windows.
• Set iProtectedView to untrusted locations or all files and lock it.
• Lock Enhanced Security on for standalone and browser use.
• Lock bDisableTrustedFolders, bDisableTrustedSites and bDisableOSTrustedSites; publish an admin trust list.
• Disable JavaScript for groups that do not need it; deploy the enterprise tBlackList for the rest.
• Set attachment permissions so executable and script types cannot open.
• Disable connectors and services the business has not approved.
• Decide who owns updates, lock it, and report version compliance weekly.
• Alert on reader processes spawning shells and on new TrustManager entries.

Standards and references

• Adobe: Application Security Guide for Acrobat and Reader
• Adobe: Sandbox Protections
• Adobe: Enhanced Security
• Adobe: JavaScript Controls
• Adobe: Trust Methods
• Adobe: Mac pre-deployment configuration (Advanced)
• Adobe: Updater preferences (Windows)
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Office Macro Blocking Guide · Endpoint Hardening Checklist · Application Allowlisting Guide · Patch Management Guide · Adobe Admin Console Security