Manage Learn to apply best practices and optimize your operations.

Patch management: Are off-cycle, third-party patches trustworthy?

Often, waiting for Microsoft to release a patch is a bother. One solution is to fix these vulnerabilities with off-cycle, third-party patches. But off-cycle patches are not without their own risks. Brien Posey describes potential problems from installing them on your system.

Convenient as off-cycle, third-party patches may seem, people who are contemplating installing them should ask...

themselves if the patches are truly trustworthy.

First some background: Since the year 2000, Microsoft has made source code available to customers, partners, developers, academic institutions and governments. The company licenses some of this source code in a way that allows it to be modified and legally redistributed. It is therefore safe to assume that companies offering non-Microsoft patches to Microsoft products have probably based those patches on modified Microsoft source code.

Third-party patching extras
Third-party Microsoft patches could get new life
Microsoft's patch process is as orderly and predictable as it has ever been, but some say the software giant's methodical ways may lead to more third-party patches.

Microsoft vs. third-party tools for patching
If you're tasked with patching Windows and you need to choose a tool to get the job done, is a Microsoft product the best way to go? Jason Chan answers this question and more here.

In effect, then, IT administrators deploying off-cycle patches from third parties, in many instances, will have no idea what the patch contains. So before you consider deploying an off-cycle patch, you should ask yourself how much you trust the company that produced it. Even patches from a company without any malicious intent, can inadvertently be infected by malicious code.

In the worst case, if a company producing third-party patches has less than honorable intentions, it potentially could distribute a patch containing spyware or code that makes it easier to exploit the vulnerability that the patch supposedly addresses.

Assuming that the company producing the patch is not embedding malicious code in its patches (intentionally or unintentionally), then the biggest risk to applying a third-party patch is that the patch may introduce bugs into the product that it is supposed to patch. After all, in the case of a Windows patch at least, many of these fixes are actually replacing operating system code.

Though it's true that a legitimate Microsoft patch can potentially introduce a bug into the product that it is patching, if a bug is caused by another company's fix, you can't turn to Microsoft for help. Even if you have a problem that is not related to a third-party patch, you run the risk of Microsoft's technical support staff refusing to help you once they figure out that you have third-party patches installed on your system.

My final caveat isn't so much a risk as much as it is an inconvenience. As I'm sure you know, many organizations use Windows Server Update Services (WSUS) to deploy Microsoft patches. Because WSUS is based on Windows Update, it most likely cannot be used to deploy third-party patches. This means that if a company wants to deploy third-party patches, admins will have to either deploy those patches manually or invest in a more flexible patch management solution.

Got a patch management question?
If you have a question about Microsoft patches or third-party patches, feel free to email it to our patch management expert Jason Chan
In my opinion, the risk of accidentally introducing bugs or malicious code into a system, along with the risk of Microsoft not supporting the system, far outweighs the risk of having to wait for a legitimate Microsoft patch. After all, Microsoft does have a history of expediting patches for more serious security issues. At times, Microsoft even provides detailed instructions on how to protect a system against a newly discovered vulnerability until a patch can be produced.

If you do decide to use third-party patches, then I recommend using them judiciously and temporarily. Then remove the patch when a legitimate Microsoft patch becomes available.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit his personal Web site at

Dig Deeper on Enterprise desktop management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.