Third-Party Patching for SCCM

Patch over 335+ third-party updates across 190 products in SCCM

Knowledge Base ArticlesDownload Trial

Why are Updates Code-Signed as “Patch My PC 3rd Party Application Component”

In this blog post, we will be talking about some changes we needed to make for a small number of third-party products whose installers are unsigned by their vendor.

One of the new requirements when using the System Center Configuration Manager 1806+ Third-Party Software Updates feature is every update’s installer file must be digitally signed when published as full-content within the SCCM console.

If you right-click an update where the installer isn’t signed and choose to Publish Third-Party Software Update Content, you will receive an error in the binary validation in the SMS_ISVUPDATES_SYNCAGENT.log log file.

The following errors will be shown in the SMS_ISVUPDATES_SYNCAGENT.log log file when an unsigned third-party update is published as full-content.

SyncUpdate: File ‘D:\Microsoft Configuration Manager\ISVTemp\hdrdeabp.51d\7z1604-x64.msi’ does not appear to be signed or there was an error retrieving the signing certificate. Signatures are required.

Signature check on downloaded binary has failed, reason: 0.



Since System Center Updates Publisher (SCUP) does allow unsigned updates to be published, we expect Microsoft made the code-signing certificate requirement for SCCM due to the increased automated available in SCCM to add another layer of validating binaries for any third-party software updates being published from their product.

List of Product Whose Vendors Don’t Code-Sign

We are maintaining a list of active products whose vendors who don’t sign their installer binaries.

  • 7-Zip
  • Apache OpenOffice
  • Apache Tomcat
  • Archi
  • FastStone Capture
  • GanttProject
  • ImgBurn
  • Inkscape
  • IZArc
  • K-Lite “Basic & Mega”
  • MapInfoPro
  • MicroDicom
  • MinuteTraq
  • Notepad++
  • PaintDotNet
  • PeaZip
  • PKZip
  • Programmer’s Note
  • ProjectLibre
  • RStudio
  • ScreenpressoSetup
  • SeaMonkey
  • ShareX
  • Terminals RDP

Why don’t vendor’s code-sign their installers?

Great question, code-signing does add another layer of integrity to binaries and has been around for a long time. The vast majority of software vendors do code-sign their binaries, but we do see many open sourc projects such as Notepad++ and 7-Zip choose to not to code-sign due to cost and increased complexity and instead post file hashes.

Our Workaround – Using a Special Code-Signing Certificate for Third-Party Binaries

As a workaround for products above that was in our catalog before the SCCM publishing feature, we will sign their installer binaries using a special code-signing certificate. The code-signing certificate we use to sign binaries that aren’t directly from Patch My PC will have a different common name.

CN: Patch My PC 3rd Party Application Component

How Are the Unsigned Binaries Validated Before Being Code-Signed by Patch My PC?

We will still perform all the same security validation test for malware and bloatware on the vendor’s unsigned binaries before signing the binaries for compatibility for SCCM. We will include both the vendor’s unsigned hash and our signed hash in the VirusTotal scans in our RSS Feed and Email Newsletter for any new catalog update.

Our code-signing of unsigned binaries isn’t a way to validate the integrity of the vendor’s installers but instead is a workaround for the compatibility issue for unsigned binaries in the SCCM third-party software updates feature. We recommend reviewing our deep dive security validation guide for more details on how we validate the integrity of vendors installers for more technical information.

Any New Products Must Always Be Code-Signed by the Vendor

For any new product request, we now require the installer to be code-signed by the vendor as part of our requirements. We will only retroactively code-sign unsigned installers for products already included in our catalog before this requirement.