Who Holds the Keys to Your Patching?

On 21 October, details of two critical PHP flaws leaked to VirusTotal at 02:29 UTC. By 07:34, hosting providers were reporting active exploitation, and PHP released the fix at 13:52, according to Recorded Future. Amazon later said the first exploitation attempts started on 17 October, four days before any patch existed.

In Patch Less I argued that the long tail of utilities on user devices should be patched automatically, with a third-party tool or Microsoft’s own catalogue. Timelines like this one are the reason. But that automation raises a question I keep coming back to: when you hand patching to a third-party tool, whose keys are you handing over?

A disclaimer first. I’m not a packaging specialist. I don’t build PSADT wrappers or write detection rules for a living, and people who do will know more about catalogues and version handling than I ever will. So this post leaves packaging aside and looks at the trust boundary: who holds the credential, what the permission really grants, and what happens when it’s compromised.

Your patch tool is a tier-0 asset

Adele Vance is the endpoint engineer at a mid-sized Swiss company. She’s tired of repackaging Notepad++ every few weeks, so she signs up for a cloud patching service. She clicks Authorize, signs in with a Global Administrator account, one of the few roles allowed to approve it, and accepts the permission dialog. Ten minutes later, the first updates appear in Intune. Her manager is happy. The help desk is happy.

What Adele granted in that dialog is, among other things, the Microsoft Graph application permission DeviceManagementApps.ReadWrite.All. In plain words: create a Win32 app with any install command line and assign it to all devices. The Intune Management Extension then runs that command as SYSTEM. Whoever holds this permission can run code on every managed device in the company.

I call that a tier-0 asset: something that, once compromised, gives control over everything below it. We protect domain controllers and Global Administrator accounts this way. But do organisations think of their patching connector in the same category?

There are two ways a patching tool connects to your tenant, and they look the same on the permission list:

• A multi-tenant enterprise app. The vendor owns the app registration and its credential. You only consent to it.
• A customer-owned app registration. You register the app in your own tenant and you hold the secret or certificate.

The difference matters for three reasons. First, Conditional Access for workload identities only works on single-tenant service principals registered in your tenant. Microsoft states plainly that third-party SaaS and multi-tenant apps aren’t covered. So you can’t restrict the vendor’s connector to known IP ranges or block it on risk. Second, you can’t rotate the credential or see how it’s stored. Third, one credential at the vendor works for every tenant that consented. Kaseya VSA in 2021 showed what happens when attackers take over one management tool that reaches many organisations at once.

None of this says a vendor is careless. Patch My PC, for example, documents its catalogue process well: binaries come from the vendor’s official source, the hash is recorded, the catalogue is signed, and the publisher only publishes when the hashes match. My point is a different one. With a vendor-held credential, you can’t manage the risk. You can only accept it.

The self-hosted middle ground

There’s a third option between a SaaS connector and building everything yourself. Patch My PC’s Publisher, for example, runs on any suitable Windows server you operate, an Azure VM included. It uses the same catalogue as the cloud service, but the app registration and its credential live in your tenant and on your server.

That changes more than who holds the secret. The installers pass through a machine you control before they reach Intune, so your own controls get a look at them first:

• Conditional Access for workload identities works on the connector, because it’s a single-tenant service principal. You can pin it to the server’s IP address.
• You can restrict the server’s outbound traffic to the download domains the vendor publishes, so a manipulated catalogue entry pointing somewhere else fails.
• Your endpoint protection on the server can scan installers before they’re published (check that nobody added an antivirus exclusion for the download folder), and you can pause publishing for specific products when something looks wrong.

The price is a server that is now a tier-0 host itself. It needs the same treatment as your other tier-0 systems: no shared admin accounts, its own privileged access path, patching, monitoring and a certificate instead of a client secret. Some teams will reasonably decide they’d rather pay a vendor to run that. That’s a valid choice, as long as it’s made knowingly.

Permissions I wouldn’t grant

My rule is simple. A patching tool needs to create and update apps and assign them to groups that already exist. Any permission beyond that belongs to a different product.

From there, my list:

No Group.ReadWrite.All. Robopack, for example, lists it as a core permission, although it also lets you connect with your own app registration. Patching never needs to write groups; creating them is a convenience feature. The cost is write access to most security groups in your tenant. A compromised connector could add a device to a Conditional Access exclusion group, or a user to the target group of another app. Pre-create your assignment groups and let the tool use them.

No write access to device configuration or managed devices. If a patching tool asks for DeviceManagementConfiguration.ReadWrite.All or DeviceManagementManagedDevices.ReadWrite.All, it’s either poorly scoped or doing more than patching. Both are reasons to stop the evaluation.

No Directory.Read.All where GroupMember.Read.All is enough. It’s read-only, but a compromised connector would hand the attacker a full map of your directory.

DeviceManagementServiceConfig.ReadWrite.All is the one I’d negotiate. Patch My PC needs it to keep apps updated that you use as blocking apps in the Enrollment Status Page. They state that Microsoft offers nothing narrower, and that revoking it only stops those ESP updates. A defined function with a defined cost. That’s a decision for your risk appetite, not for my opinion.

No vendor-held multi-tenant app with DeviceManagementApps.ReadWrite.All in a FINMA-regulated tenant. The reason is the tier-0 section above: you can’t apply Conditional Access to it, you can’t rotate it, and you can’t see how it’s protected.

You’ll hear the counterargument: “Microsoft’s own services work the same way.” True. But Microsoft already holds that level of trust through the tenant itself. Every additional vendor adds a new trust boundary. I made the same argument about privilege management tools in my EPM post, and it applies here too.

The approval everyone turns off

In June 2026, Microsoft extended Intune Multi Admin Approval to Graph calls made by automation. On paper, that closes the gap: a second administrator approves every change to apps, including changes made by a service principal.

In practice, both vendors I checked recommend excluding their app from it. Patch My PC writes that adding its application as an exclusion “is the supported way to keep your MAA policy in place”. Robopack is more direct: without the exclusion, “pushing out 10 apps and 30 policies would mean clicking approve 40 times”.

They’re right. Approving every catalogue update by hand would become rubber-stamping within a month. Microsoft’s own documentation is just as clear about the other side: each exclusion creates a gap in your approval workflow that could be exploited if the excluded app is compromised. An exclusion without detection is a gap you’ve documented yourself. If you exclude, at least:

• Alert on app creations and assignments by the connector’s service principal in the Intune audit log, especially assignments to broad groups, app names that don’t match catalogue products, encoded PowerShell in install commands, and activity outside the vendor’s usual release window.
• Use App Control rules that only allow binaries signed by the original software vendor. This blocks a payload injected through a compromised connector. Scope the rules to the product, not only the certificate: some vendors sign their whole catalogue with one certificate, including the remote-access tool you never meant to allow. It doesn’t help against a compromised vendor build like 3CX in 2023, where the malware carried the vendor’s own valid signature. App Control also helps in the days before any patch exists. In the PHP case, a WAF rule had to do that job until the fix arrived; on endpoints, App Control and attack surface reduction rules play the same role.

The same applies to Microsoft’s own Enterprise App Catalog. It has no third-party credential, which is a real advantage. But Microsoft’s FAQ states that it “doesn’t assert compliance, authorization, authenticity, or integrity” for the apps it distributes. App Control still applies.

And what about WinGet or Chocolatey?

Whenever I bring up application patching, someone asks why we don’t just use Chocolatey. Naive questions are often the useful ones, so it deserves an answer. For a developer laptop, it’s a fair choice. For a bank’s managed estate, it’s a bit like asking why we don’t buy our laptops at the electronics store around the corner. Cheaper, quicker, works fine, right up to the day you need warranty, spare parts and someone to call.

Both package managers rely on community repositories. Chocolatey’s community packages go through moderation, with automated checks, VirusTotal scans and human sign-off. But many packages are scripts that download the real installer from the internet at install time, and the site itself says reliability “cannot be guaranteed”. The WinGet community repository checks manifests, installer hashes, malware scans and SmartScreen reputation of the download URL. In both cases, the people who maintain a package are volunteers you have no contract with.

None of that makes them bad tools. It makes them a different trust model. If you want to use them in a regulated estate, do what Chocolatey itself recommends and WinGet supports with private sources: an internal repository with packages you’ve reviewed and host yourself. At that point you’re running your own catalogue, with all the work the first sections of this post describe, and you’re back to the self-hosted option, just with more do-it-yourself.

Choosing by risk appetite

There’s no single right answer above the non-negotiables. What I’d ask of every organisation is to pick a row deliberately and write down why.

I started this topic wanting to know which tool to buy. I ended up with a better first question: what is a patching tool allowed to do in my tenant? Once you answer that, the shortlist gets much shorter.