How to Disable Adobe Updater Without Leaving Acrobat Unpatched

Updated: October 2026

Switching off the Adobe updater is a two-minute job that half the internet gets wrong, because Adobe ships the updater as four separate things and turning off one leaves the other three running. This guide covers the switch that works, where Adobe documents it, and the install-time option that stops the service being put on the machine at all. It also answers the question the search results keep dodging: whether a machine running Acrobat with updates off is a machine you want on a client network.

Four Adobe Updaters, Four Different Switches

Check which of these is bothering you before changing anything. They are separate components and they fail independently.

The third one catches people out. If the popup says anything about genuine software or a licence, it has nothing to do with the updater and switching off AdobeARMservice will change nothing.

Turn Off Adobe Updates on One Machine

In Acrobat or Reader, go to Edit > Preferences > Updater and pick Do not download or install updates automatically. On current builds the same setting lives under the hamburger menu, then Preferences.

If that option is greyed out, a policy is already applying and the machine is being managed from somewhere else. That is the intended behaviour of the registry key below, so check what your RMM or GPO is pushing before you fight the UI.

The Registry Key That Does It Properly

Adobe documents one supported switch, bUpdater, in the FeatureLockDown reference of its Enterprise Toolkit. Set the DWORD to 0:

code
HKLM\SOFTWARE\Policies\Adobe\<product>\<version>\FeatureLockDown\cServices\bUpdater

<product> is Adobe Acrobat or Acrobat Reader, and <version> is DC on current releases. On 64-bit Windows the same path sits under WOW6432Node, which is where a lot of scripts silently miss:

code
HKLM\SOFTWARE\WOW6432Node\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cServices\bUpdater

Adobe's description of the value is broader than "stop updating". Setting it to 0 disables updates to the product's web-plugin components and all services without exception, sign-in screens included. On a machine where people use cloud storage or e-signature features, that is a bigger change than the person who filed the ticket asked for. Know that before you push it fleet-wide.

It also removes the manual Check for updates menu item. Users cannot update even if they want to, which is the point on a locked-down build and a problem on a laptop that never phones home.

Stop the Service Being Installed at All

The cleaner answer for a build image is to keep the updater off the machine from the start rather than disabling it afterwards. Adobe's installer accepts a property for exactly this:

code
DISABLE_ARM_SERVICE_INSTALL=1

Pass it on the command line and AdobeARMservice is never installed. The Customization Wizard exposes the same thing as a Disable product updates checkbox, which is the route to take if you are already building a transform for your deployment.

This matters more than it sounds. A service that was never installed cannot be reinstated by a later patch, which is exactly where disabling one by hand falls down.

Pushing It Across a Fleet

There is no Adobe ADMX template for this, so the registry value is the delivery mechanism. Push it through your RMM or as a Group Policy Preference:

powershell
$base = 'HKLM:\SOFTWARE\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cServices'
New-Item -Path $base -Force | Out-Null
New-ItemProperty -Path $base -Name 'bUpdater' -PropertyType DWord -Value 0 -Force

Run it against both the native and WOW6432Node paths, and against both product names if the estate has a mix of Reader and full Acrobat. A script that assumes everyone is on Reader will report success across a hundred endpoints and leave every Acrobat install updating.

Disabling the service through services.msc or Set-Service -StartupType Disabled works until the next Acrobat update puts it back. Use the registry value as the durable control and treat the service state as a symptom rather than the setting.

How to Confirm It Took

Read the value back rather than trusting the push. On a 64-bit machine that means checking the path Acrobat uses:

code
reg query "HKLM\SOFTWARE\WOW6432Node\Policies\Adobe\Acrobat Reader\DC\FeatureLockDown\cServices" /v bUpdater

Then open the app. Under Edit > Preferences > Updater, the options should be greyed out and the manual Check for updates item should be gone from the menu. A user who can still click it is a user whose machine the policy never reached, whatever your console reports.

Last, check the service: Get-Service AdobeARMservice. On a machine built with DISABLE_ARM_SERVICE_INSTALL=1 the service does not exist and the command errors, which is the result you want. On a machine where it was disabled by hand, it exists and is stopped, and it will be back after the next product update.

Why the Adobe Updater Keeps Coming Back

Three causes, in the order you will hit them.

You set bUpdater in one place and not the other. The value exists at the product level and under cServices. Set one, leave the other, and updates carry on. Several of the Adobe community threads that fill this search result are titled some version of "I disabled it and it still updates".

You are on 64-bit and wrote to the 32-bit path, or the reverse. Acrobat and Reader have long shipped as 32-bit applications, so on those installs the policy lands under WOW6432Node. A script written against the native path executes cleanly and changes nothing.

A product update reinstalled the service. Turning off the service is not a policy, it is a state, and Adobe's installer is entitled to restore it. This is what DISABLE_ARM_SERVICE_INSTALL and the registry policy are for.

Is It Safe to Disable Adobe Acrobat Update Service?

The short answer: safe to disable, not safe to forget.

Acrobat and Reader carry a long history of CVEs exploited through documents the user was expecting to open, which is what makes an unpatched build worth caring about. A machine with the updater switched off and nothing else patching Acrobat is worse off than one left on defaults, however annoying the defaults are.

So disable the updater when it is causing a problem, then put something in its place. Adobe's own guidance is to roll out updates within 60 days of release, and it ships two tools for doing that without the per-machine updater: AUSST, the Adobe Update Server Setup Tool, which mirrors Adobe's updates to an internal server, and RUM, the Remote Update Manager, which triggers installs remotely. Either of those, or Acrobat handled as a third-party application in your own patch management tooling, turns this from a risk into a scheduling decision.

The version that goes wrong is the one where the updater gets disabled to close a ticket, nobody adds Acrobat to the patch schedule, and the estate quietly sits on a build from two years ago. If you are switching the updater off, the same change should add Acrobat to whatever your RMM already patches.

What to Do Next

For one user with a popup, change the preference in the app and move on. For a build image, pass DISABLE_ARM_SERVICE_INSTALL=1 at install and set bUpdater to 0 in both registry locations, for both product names, in both hives.

Then do the part that makes it defensible: put Acrobat version numbers on a report someone reads. Disabling an updater is a decision about who controls patching, not a decision to stop patching, and the difference only shows up months later in what your security stack finds.