Het dashboard voor patch-compliance geeft 96% aan. Windows is up-to-date, macOS is up-to-date, het beveiligingsteam geeft zijn goedkeuring en het rapport gaat naar de auditor. Het probleem is dat 96% alleen het beeld van het besturingssysteem weergeeft. Het eindpunt dat onder die groene tegel zit, draait ook een Chrome-build van eind deze zomer, een Adobe Reader-versie met drie gepubliceerde CVE's, een Zoom-client die dateert van vóór het laatste beveiligingsadvies en een Java-runtime waar niemand in het team in de afgelopen achttien maanden nog aan heeft gedacht. Niets van dat alles komt terug in de score.
Dat is de leemte die patchbeheer voor applicaties van derden zou moeten opvullen, en voor de meeste IT-teams en MSP’s is dit het deel van het patchprogramma dat, in verhouding tot het werkelijke risico, stilletjes ondergefinancierd is. Volgens de Qualys Enterprise Benchmark 2026 bedraagt de gemiddelde tijd die nodig is om complexe applicaties van derden te repareren vijf maanden en tien dagen. Aanvallers opereren echter binnen een tijdsbestek van dagen, soms zelfs uren. Deze twee tijdschema’s zijn onverenigbaar.
De RMM-oplossingen van Kaseya verzorgen het patchbeheer voor miljoenen eindpunten voor MSP’s en interne IT-teams wereldwijd. Ze bieden een duidelijk operationeel beeld van waar patchprogramma’s van derden onder druk standhouden en waar ze tekortschieten. In deze gids wordt uitgelegd wat patchbeheer door derden inhoudt, waarom de uitvoering ervan lastiger is dan het patchen van besturingssystemen, waar de prioriteit moet liggen, hoe het programma operationeel moet worden opgezet en wat automatisering moet bieden om gelijke tred te houden met het releasetempo.
Wat is patchbeheer door een externe partij?
Patchbeheer voor software van derden is het proces waarbij updates worden geïdentificeerd, beoordeeld, geïmplementeerd en gecontroleerd voor de software die op uw eindapparaten draait en die niet door de leverancier van het besturingssysteem wordt geleverd. Dat is een brede categorie. Denk hierbij aan browsers, pdf-lezers, conferencing-clients, runtime-omgevingen zoals Java en .NET, productiviteitspakketten, ontwikkeltools, compressieprogramma’s en de lange reeks bedrijfsapplicaties die zich in de loop van de tijd in elke omgeving opstapelen.
Het valt onder hetzelfde bredere kader van patchbeheer als het patchen van besturingssystemen, maar kent andere beperkingen. Microsoft, Apple en de grote Linux-distributies verspreiden hun updates via gestandaardiseerde, goed georganiseerde kanalen. Externe leveranciers doen dat niet. Er is geen ‘Patch Tuesday’ voor Slack. Er is geen centrale catalogus die het releaserooster van Adobe koppelt aan dat van Mozilla, aan dat van Oracle en aan de niche-bedrijfsapp die het financiële team in 2019 heeft geïnstalleerd. Elke leverancier brengt updates uit op zijn eigen tempo, in zijn eigen formaat en via zijn eigen kanaal, en iemand moet ze allemaal tegelijk bijhouden.
De term ‘derde partij’ is hier erg veelomvattend. Het omvat alles, van een browser die door alle gebruikers binnen het bedrijf wordt gebruikt tot een gespecialiseerde technische tool die op drie computers is geïnstalleerd. Beide vallen onder dezelfde operationele noemer en beide kunnen het startpunt zijn voor een inbreuk.
Waarom het installeren van patches van derden belangrijker is dan ooit
Jarenlang werd ervan uitgegaan dat kwetsbaarheden in besturingssystemen de grootste zorg vormden en dat applicaties slechts een ondergeschikte zorg waren. Dat is al een tijdje niet meer het geval. De cijfers bevestigen nu steeds meer wat aanvallers al lang wisten.
Uit het onderzoek ‘State of Patch Management 2025’ van Adaptiva, uitgevoerd in samenwerking met Demand Metric, bleek dat 87% van de organisaties het afgelopen jaar te maken had met kwetsbaarheden in applicaties van derden die gepatcht moesten worden. Dat is geen uitzondering. Het is de standaardtoestand van vrijwel elke IT-omgeving waarin moderne software draait.
De CISA-catalogus met bekende misbruikte kwetsbaarheden (KEV ) vertelt hetzelfde verhaal vanuit een ander perspectief. De KEV-lijst bevat kwetsbaarheden die actief door aanvallers worden misbruikt, en niet alleen theoretische kwetsbaarheden met een CVSS-score, en een aanzienlijk deel van de nieuwe vermeldingen betreft applicaties van derden in plaats van de kern van besturingssystemen. Browsers, documentlezers, conferentietools en runtime-bibliotheken verschijnen maand na maand. Ze worden op grote schaal ingezet, er worden regelmatig beveiligingsupdates uitgebracht, en de kloof tussen de release door de leverancier en de installatie door de eindgebruiker is waar aanvallers hun werk doen.
Het tempo maakt het nog ingewikkelder. Tijdens de Patch Tuesday van april 2026 heeft Microsoft alleen al in zijn eigen softwarepakket 163 CVE’s verholpen. Tel daar nog Adobe, Oracle, Google, Mozilla, Cisco, Atlassian en een tiental andere bedrijven bij op, en het maandelijkse volume waarmee elk patchprogramma gelijke tred moet houden, begint echt een enorme opgave te worden. Het handmatig doorlopen van een feed van die omvang is geen haalbare strategie.
Uit het Verizon Data Breach Investigations Report 2025 blijkt dat bij 20% van de datalekken misbruik van kwetsbaarheden de eerste toegangsweg was — een stijging van 34% ten opzichte van vorig jaar. Die stijging is niet alleen te wijten aan zero-day-kwetsbaarheden op besturingssysteemniveau. Ze weerspiegelt de voortdurende misbruiking van kwetsbaarheden in software van derden waarvan organisaties ofwel niet wisten dat ze die gebruikten, ofwel nog niet aan het patchen waren toegekomen.
Uitdagingen bij patchbeheer door derden
Als je eenmaal weet dat het risico reëel is, rijst natuurlijk de vraag waarom zoveel programma’s die kwetsbaarheid dan toch ongedekt laten. Het antwoord is van technische aard, niet van motivatie. Het patchen van software van derden is om vier onderling samenhangende redenen structureel moeilijker dan het patchen van het besturingssysteem.
Versnippering van leveranciers
De update-infrastructuur van Microsoft is bedoeld voor Microsoft-software. Die van Apple is bedoeld voor macOS. Voor de rest bestaat er geen vergelijkbaar uniform kanaal. Elke ISV heeft zijn eigen releaseportaal, zijn eigen formaat voor beveiligingsadviezen en zijn eigen distributiemechanisme. Om releases voor 50 of 100 applicaties van derden handmatig bij te houden, moet je je abonneren op tientallen afzonderlijke feeds en elke melding omzetten in concrete actie. Dat is een fulltime functie waarvoor de meeste teams geen personeel hebben.
Variabiliteit in cadans
Patch Tuesday biedt een vast ritme voor Windows. Updates van andere leveranciers volgen geen vast patroon. Een kritieke browserfix kan halverwege de week verschijnen. Een runtime-update kan zonder aankondiging worden uitgebracht. Een conferencing-tool kan een beveiligingsupdate uitbrengen op dezelfde dag dat een leverancier van printerstuurprogramma's een CVE publiceert. Het volume is niet voorspelbaar en de timing evenmin, wat betekent dat een patchprogramma dat is opgezet rond een maandelijkse cyclus, door zijn opzet routinematig tijdgevoelige updates van derden zal missen.
Diversiteit onder installateurs
OS-patches worden via gestandaardiseerde mechanismen geleverd. Applicaties van derden maken gebruik van MSI, EXE, MSIX, App-V, leveranciersspecifieke updaters, webgebaseerde installatieprogramma’s en af en toe een op maat gemaakt implementatiescript. Elk formaat heeft zijn eigen vlaggen voor stille installatie, zijn eigen herstartgedrag, zijn eigen logica voor versiedetectie en zijn eigen foutmodi. Om deze verscheidenheid betrouwbaar te automatiseren, is ofwel een tool nodig die door de leverancier is getest voor elke applicatie, ofwel aangepaste scripts die door uw team voor onbepaalde tijd moeten worden onderhouden.
Ontdekking
Je kunt geen patches toepassen op iets waarvan je niet weet dat het er is. Gebruikers installeren applicaties buiten de door IT goedgekeurde kanalen om. Bij overnames worden onbeheerde softwareparken overgenomen. Afdelingen standaardiseren op tools waarvan het endpointteam niets heeft gehoord. Zonder continue, agent-gestuurde detectie die elke geïnstalleerde applicatie en versie op elk beheerd apparaat in kaart brengt, werkt het patchprogramma op basis van een inventaris die al bij voorbaat onjuist is.
Deze vier beperkingen verdwijnen niet door er hard aan te werken. Ze zijn inherent aan het ecosysteem van software van derden zelf. Een goed werkend programma is een programma dat hierop is afgestemd in plaats van ertegenin te gaan.
Welke toepassingen verdienen de hoogste prioriteit?
Niet elke applicatie van derden brengt hetzelfde risico met zich mee — en door ze allemaal over één kam te scheren, lopen programma’s uiteindelijk evenveel risico als wanneer er helemaal geen programma’s zouden zijn. De juiste aanpak is om ze in te delen op basis van implementatieomvang, exploitatiegeschiedenis en afstand tot de netwerkrand, en vervolgens de frequentie en SLA te concentreren op de hoogste categorie.
Browsers staan bovenaan vrijwel elke lijst. Chrome, Edge, Firefox en Brave zijn op elk eindpunt geïnstalleerd, geven per definitie onbetrouwbare inhoud van het internet weer en ontvangen meerdere keren per maand beveiligingsupdates. Vaak stellen ze de toepassing van updates uit tot na een herstart, wat betekent dat een beschikbare patch pas daadwerkelijk wordt geïnstalleerd als de gebruiker het venster sluit. Een SLA van 24 tot 48 uur voor kritieke browserupdates, met handhaving, is een redelijke basisnorm.
Vervolgens zijn er PDF- en documentlezers. Adobe Acrobat en Reader hebben een lange lijst met kritieke CVE’s en worden al jarenlang aangevallen via kwaadaardige documenten die via e-mail worden verspreid. Het installeren van de nieuwste versie op elk eindpunt is voor de meeste teams de goedkoopste manier om het succespercentage van phishing-aanvallen aanzienlijk te verlagen.
De derde groep bestaat uit runtime-omgevingen. Java, OpenJDK, de .NET-runtimes en diverse JavaScript-engines vormen de basis voor bedrijfsapplicaties die voor beveiligingstools wellicht niet als afzonderlijke afhankelijkheden zichtbaar zijn. Een kwetsbaarheid in een runtime heeft gevolgen voor elke applicatie die daarop is gebouwd, en de omvang van de schade kan groot zijn, zelfs als de runtime zelf onopvallend lijkt.
Clients voor vergaderen en samenwerken vormen een vierde categorie. Zoom, Teams (in de zelfstandige versie), Slack en soortgelijke tools worden overal geïnstalleerd, werken met onbetrouwbare externe links en bestanden en worden regelmatig bijgewerkt. Hun aanvalsoppervlak is vergelijkbaar met dat van een browser, ook al worden ze in de inventaris van bedrijfsmiddelen anders weergegeven.
Compressieprogramma’s, archiveringsprogramma’s, afhankelijkheden voor ontwikkelaars en de lange staart van bedrijfsapplicaties vullen het plaatje aan. Ze dragen elk een aanzienlijk deel van het risico, en het juiste kader om ze te rangschikken is hetzelfde risicogebaseerde model dat ook voor het patchen van besturingssystemen zou moeten gelden: ernst (CVSS), exploitatiestatus (KEV-vermelding, feeds met dreigingsinformatie, openbare exploits) en zakelijke context (verbinding met het internet, gevoelige gegevens, potentieel voor laterale beweging). Zie best practices voor patchbeheer voor meer informatie over het integreren van dat raamwerk in het bredere programma.
Beste praktijken voor het installeren van patches van derden: hoe stel je een programma op?
Een goed functionerend patchprogramma van een derde partij volgt in grote lijnen hetzelfde traject als het bredere patchbeheerproces, maar bij de uitvoering in elke fase moet rekening worden gehouden met de extra complexiteit die software van een derde partij met zich meebrengt.
Het inventariseren van systemen moet continu, agentgestuurd en volledig zijn. Een wekelijkse software-audit van het activaregister volstaat niet. De agent moet elke geïnstalleerde applicatie, elke versie en elke door de gebruiker geïnstalleerde instantie op elk beheerd eindpunt in kaart brengen, en deze gegevens vrijwel in realtime bijwerken. Zodra dat inzicht wegvalt, is het patchprogramma precies in die mate blind.
Monitoring werkt volgens hetzelfde principe. Zodra je weet wat er is geïnstalleerd, heb je een feed nodig die aangeeft wanneer elke leverancier een beveiligingsupdate uitbrengt, bij voorkeur ingedeeld naar ernst. Het is een hele klus om zo’n feed intern op te zetten voor vijftig leveranciers. De realistische oplossing is een patching-tool waarvan de leverancier nieuwe releases binnen enkele uren na publicatie toevoegt aan een geteste catalogus, zodat het team één feed hoeft te volgen in plaats van vijftig.
Het vaststellen van prioriteiten is het punt waarop het patchen van applicaties van derden in de praktijk het vaakst afwijkt van het patchen van het besturingssysteem. De hierboven beschreven risicoclassificatie wordt rechtstreeks verwerkt in uw SLA-structuur, die expliciet in uw patchbeheerbeleid moet worden vastgelegd. Een beleid waarin applicaties van derden worden genoemd, deze worden ingedeeld in ernstniveaus met vastgelegde SLA’s en waarin gedocumenteerde uitzonderingen worden vereist, maakt een einde aan de impliciete prioritering van „eerst het besturingssysteem, daarna applicaties van derden“, die de kloof in de eerste plaats veroorzaakt.
Het testen verloopt echt anders. OS-patches worden vóór de release gecontroleerd door Microsoft, Apple of de betreffende Linux-beheerder. Patches van derden worden gecontroleerd door de ISV en, idealiter, door de kwaliteitscontrole van de catalogus van uw patchplatform. Het resterende risico is interactie tussen applicaties: een browserupdate die het weergavegedrag verandert en een interne webapp onbruikbaar maakt, een Java-runtime-update die compatibiliteitsproblemen met een bedrijfssoftwarepakket aan het licht brengt, een Teams-build die een aangepaste integratie beïnvloedt. Een kleine pilotring van representatieve eindpunten, met een wachttijd van 24 tot 48 uur voor routine-updates en een verkorte smoke-test voor actief misbruikte kwetsbaarheden, vangt het meeste hiervan op voordat het de productie bereikt.
Bij de implementatie wordt de geteste update binnen de door u vastgestelde onderhoudsvensters naar de rest van het netwerk uitgerold, met een herhalingslogica voor eindpunten die bij de eerste poging offline waren en terugdraaipaden voor het geval er fouten optreden. Dit is het deel van het programma dat het meest in het oog springt wanneer het handmatig wordt uitgevoerd, omdat de omvang ervan de beschikbare uren opslokt en de afhandeling van uitzonderingen het routinewerk verdringt.
Verificatie maakt het plaatje compleet. Het signaal dat voor u van belang is, is de geïnstalleerde versie, niet de status van de implementatie. Een implementatierapport kan ‘verzonden’ aangeven, terwijl een stille installatiefout ervoor zorgt dat de oude versie op het apparaat blijft staan. Alleen door per applicatie en per apparaat te controleren welke versie er daadwerkelijk draait, weet u of de patch ook echt is geïnstalleerd.
Rapportage vindt plaats per applicatie, niet per apparaat. Een apparaat waarop de nieuwste versie van Chrome draait, maar waarop Java drie versies achterloopt, voldoet in geen enkel opzicht aan de eisen die een auditor zou stellen. De rapportage moet worden uitgesplitst per applicatie, per ernstniveau en per SLA-overtreding, met de uitsplitsingen per klant die MSP’s nodig hebben voor verklaringen aan hun klanten.
Waarom geautomatiseerd patchbeheer door een externe partij essentieel is
Zonder dat klopt de rekensom gewoon niet. Vijftig applicaties van derden, tientallen releases per maand per grote leverancier, honderden of duizenden eindpunten, release-schema’s van leveranciers die niet op elkaar aansluiten en SLA’s die voor de patches met het hoogste risico in uren worden gemeten. Geen enkel team kan dat handmatig bijhouden — en degenen die het toch proberen, raken als eerste achterop bij de software van derden, omdat de kosten van die achterstand daar in de dagelijkse praktijk het minst zichtbaar zijn.
Geautomatiseerd patchbeheer neemt het routinematige werk uit handen van het team: vaststellen of een applicatie een update nodig heeft, het geteste pakket uit de catalogus ophalen, het via een stille installatie implementeren tijdens het afgesproken onderhoudsvenster, het afhandelen van herstarts en het opnieuw uitvoeren van mislukte installaties. Mensen blijven betrokken bij het afhandelen van uitzonderingen, het goedkeuren van wijzigingsvensters voor gevoelige systemen en het kleine percentage applicaties dat daadwerkelijk handmatige tussenkomst vereist.
Er zijn twee aspecten van automatisering door externe partijen die het vermelden waard zijn, omdat ze in de bredere discussie over automatisering onvoldoende aandacht krijgen.
Ten eerste is er de kwaliteit van de catalogus. Automatisering is slechts zo goed als de applicatiecatalogus waarop deze is gebaseerd. Een platform dat er twee weken over doet om een cruciale browserupdate te verpakken, biedt gedurende die periode evenveel beveiliging als helemaal geen platform. De vragen die het stellen waard zijn bij het evalueren van de patchmogelijkheden van een derde partij zijn: hoeveel applicaties worden standaard ondersteund, hoe snel worden nieuwe releases van leveranciers in de catalogus opgenomen (met name voor beveiligingsupdates) en welke kwaliteitscontrole wordt er op elk pakket toegepast voordat het de productie-endpoints bereikt?
Het tweede punt is de afhankelijkheidsstructuur. Een slechte OS-patch leidt vaak tot storingen in het besturingssysteem. Een slechte patch van een derde partij leidt vaak tot storingen in de applicatie die ervan afhankelijk is, wat kan betekenen dat een bedrijfsworkflow, een integratie of een productiviteitstool die het hele bedrijf gebruikt, niet meer werkt. De risicobeperking is hetzelfde als bij elk patchprogramma: implementatieringen, wachttijden, geautomatiseerde terugdraaiing. De operationele tolerantie voor storingen is echter lager, omdat gebruikers een storing in Adobe Reader sneller opmerken dan een kernelupdate.
Het nalevingsaspect
Compliancekaders doen niet langer alsof software van derden een apart aandachtspunt is. PCI DSS 4.0-eis 6.3.3 heeft betrekking op alle systeemcomponenten, waaronder applicaties, en niet alleen op besturingssystemen. ISO 27001:2022 Bijlage A 8.8 behandelt het beheer van technische kwetsbaarheden zonder uitzonderingen. De beveiligingsregel van HIPAA is in handhavingsmaatregelen geïnterpreteerd als zijnde van toepassing op het patchen van applicaties als onderdeel van "redelijke en passende" beveiligingsmaatregelen. NIS2, van kracht in alle EU-lidstaten, vereist bewijs van tijdige afhandeling van kwetsbaarheden, waarbij geen onderscheid wordt gemaakt tussen besturingssystemen en applicaties. SOC 2 Trust Services Criteria CC7.1 heeft betrekking op monitoring en herstel van nieuwe kwetsbaarheden in het gehele systeem.
De praktische consequentie is in alle gevallen dezelfde. Een audit waarbij uw patchprogramma wordt onderzocht en waarbij onbeheerde browsers, niet-gepatchte PDF-lezers of verouderde Java-runtimes worden aangetroffen, zal altijd tot bevindingen leiden, hoe vlekkeloos uw Windows-nalevingsrapport er ook uitziet. De verdediging tegen die bevinding bestaat uit operationeel bewijs: nalevingsrapportages per applicatie, gedateerde implementatiegegevens, gedocumenteerde uitzonderingen en SLA’s die in de praktijk worden nageleefd en niet alleen op papier bestaan.
Hoe Kaseya het patchen van software van derden vereenvoudigt
Het patchen door derden is geen kwestie van kennis. Elk IT-team en elke MSP weet dat applicaties gepatcht moeten worden. Het is een operationeel probleem, en dat operationele probleem is structureel: meer leveranciers, meer patchcycli, meer installatieformaten, een groter detectiegebied en een standaardworkflow die de voorkeur geeft aan het patchen van besturingssystemen, omdat dat eenvoudiger te automatiseren is.
De oplossing is om third-party niet langer als een apart programma te beschouwen, maar het in hetzelfde kader te brengen als de werkzaamheden die al lopen. Dezelfde inventaris. Dezelfde risicoclassificatie. Dezelfde SLA's in het beleid. Dezelfde implementatieringen. Dezelfde automatisering. Dezelfde nalevingsrapportage per applicatie. De onderliggende tooling moet een geteste catalogus van derde partijen ondersteunen op het tempo waarop leveranciers daadwerkelijk releases uitbrengen, maar het programmaontwerp is geen apart programma. Het is hetzelfde programma, met een volledige scope.
Dat ontwerpprincipe vormt de basis van de RMM-oplossingen van Kaseya: het patchen van besturingssystemen, software van derden en firmware verloopt via één agent, één beleidskader, één reeks onderhoudsvensters en één overzicht van de naleving. De module ‘Advanced Software Management’ van Datto RMMis de genoemde functie voor software van derden, die de patchdekking uitbreidt tot meer dan 200 kant-en-klare applicaties met een catalogus die vóór de release op miljoenen apparaten is getest en voortdurend wordt uitgebreid.
De module ondersteunt ook het installeren en verwijderen van applicaties via hetzelfde beleidsraamwerk, waarmee een lacune wordt gedicht die de meeste patchtools laten bestaan: applicaties waarvan de levensduur is verstreken en die moeten worden verwijderd – en niet alleen bijgewerkt – voordat ze kunnen worden misbruikt. Voor MSP's betekent dit beleidsconfiguratie per klant en nalevingsrapportage per klant vanuit één console. Voor interne IT-teams is het een uniform overzicht van de patchstatus van zowel het besturingssysteem als software van derden, met het audittraject dat nalevingskaders vereisen, geproduceerd als een bijproduct van de workflow in plaats van een driemaandelijkse exercitie in het verzamelen van bewijsmateriaal.
Het alternatief is dat een gedocumenteerd aanvalsoppervlak onbeschermd blijft, terwijl het dashboard voor OS-patches op groen blijft staan. Dat is precies de zwakke plek waar aanvallers op inspelen — en uit de huidige gegevens over misbruik blijkt dat ze daar gelijk in hebben.
