RMM-software laten maken
Remote monitoring and management is de software waarmee een IT-dienstverlener of een interne IT-afdeling apparaten op afstand bewaakt en beheert. Een agent op elke werkplek en server meet wat er gebeurt, meldt wat afwijkt en voert werk uit: updates installeren, scripts draaien, diensten herstarten, meekijken bij een storing. Dat maakt een RMM tegelijk het handigste en het gevoeligste systeem in een beheerlandschap, want het heeft op elk aangesloten apparaat verregaande rechten. Appfront bouwt beheersoftware voor organisaties die daar met een standaardpakket niet uitkomen.
Wat een RMM onderscheidt van losse monitoring
Monitoring meet en signaleert. Een sonde kijkt of een server antwoordt, of een schijf volloopt, of een dienst nog draait, en stuurt een melding zodra een drempelwaarde wordt overschreden. Daarna houdt het op: iemand leest de melding, logt handmatig in en lost het op. Dat werkt prima zolang het om een handvol systemen gaat die op dezelfde locatie staan.
Een RMM voegt aan dat meten handelingsvermogen toe. Dezelfde agent die de schijfvulling rapporteert, kan ook opruimen. Dezelfde agent die ziet dat een beveiligingsupdate ontbreekt, kan die installeren. Het onderscheid zit niet in de meetgegevens maar in de rechten: een RMM mag het apparaat veranderen, meestal met de hoogste rechten die het besturingssysteem kent, zonder dat er iemand achter dat apparaat zit. Daarmee schuift het gereedschap van waarnemen naar ingrijpen, en verandert ook het risicoprofiel.
Het tweede onderscheid is schaal. Losse monitoring is per systeem ingericht. Een RMM is opgezet vanuit een verzameling: honderden of duizenden apparaten, verdeeld over klanten, vestigingen en afdelingen, met beleid dat per groep verschilt. Een enkel apparaat bekijken is dan de uitzondering. De normale werkvorm is een overzicht waarin afwijkingen bovendrijven, met een handeling die u op een hele groep tegelijk uitvoert.
Het derde onderscheid is dat een RMM zelf werk produceert. Een melding die nergens heen gaat is ruis. Een melding die een ticket wordt, aan een technicus wordt toegewezen en pas sluit als de meting weer klopt, is beheer. Dat is de reden dat vrijwel elk beheerplatform een koppeling met een ticketsysteem heeft en dat die koppeling in de praktijk bepaalt of het platform wat oplevert.
Het helpt om ook te benoemen wat een RMM niet is. Het is geen antivirus en geen endpoint detection and response: die gereedschappen zoeken naar kwaadaardig gedrag, terwijl een RMM naar beheertoestand kijkt en hooguit rapporteert of de beveiligingssoftware draait. Het is geen back-upoplossing, al bewaakt het vrijwel altijd of de back-up geslaagd is. Het is ook niet hetzelfde als mobiel apparaatbeheer, dat vooral over configuratieprofielen en toegang tot bedrijfsgegevens gaat en meestal via de kanalen van de fabrikant werkt. In grotere organisaties bestaan die lagen naast elkaar en is de echte vraag wie welke meting als bron beschouwt. Dat vooraf afspreken voorkomt dat twee systemen elkaar tegenspreken over dezelfde machine.
Zit u hier goed? Deze pagina gaat over het beheren van apparaten, niet over het volgen van personen. Zoekt u software die registreert waar medewerkers hun tijd aan besteden, welke applicaties zij gebruiken of welke websites zij bezoeken, dan hoort u bij employee monitoring software. Dat is een wezenlijk andere categorie, met een eigen juridisch kader en een eigen gesprek met de ondernemingsraad. Een RMM meet de toestand van een laptop; employee monitoring meet het gedrag van de persoon erachter. Die twee lopen in de markt vaak door elkaar, en het loont om aan het begin van een project vast te leggen aan welke kant u staat.
Meten en mogen ingrijpen
De agent leest niet alleen uit, hij voert ook uit. Dat scheelt handwerk en vraagt tegelijk om een strak rechtenmodel.
Opgezet vanuit de verzameling
Beleid per groep, handelingen op een hele reeks apparaten tegelijk. Eén apparaat bekijken is de uitzondering.
Een melding wordt werk
Zonder koppeling naar tickets blijft bewaking een dashboard. Met koppeling wordt het een wachtrij met opvolging.
De agent op het apparaat
Alles wat een RMM kan, kan het via de agent. Dat is een klein programma dat als dienst op de werkplek of server draait, meetgegevens verzamelt en opdrachten uitvoert die van het platform komen. Het is het onderdeel waar de meeste techniek in zit en waar de meeste ontwerpkeuzes gemaakt worden, want de agent draait buiten uw bereik: op een laptop die in de trein staat, op een server achter een firewall die u niet beheert, op een machine die pas maandagochtend weer aangaat.
Het eerste ontwerppunt is de richting van de verbinding. Een agent die wacht tot het platform contact opneemt, vereist een open poort naar binnen en dat is precies wat u niet wilt. Vrijwel alle beheerplatformen draaien het daarom om: de agent belt zelf naar buiten, houdt die verbinding open en haalt daar opdrachten op. Voordeel is dat u geen enkele poort hoeft open te zetten. Nadeel is dat het platform daarmee een permanent open kanaal naar elk apparaat heeft, wat een aanvaller die het platform in handen krijgt onmiddellijk kan gebruiken.
Het tweede punt is wat de agent doet als hij niets hoort. Netwerken vallen weg, laptops gaan dicht, verbindingen worden verbroken. Een agent die alleen werkt zolang het platform bereikbaar is, verliest metingen en levert een gat in de historie op. Een agent die lokaal blijft meten, zijn waarnemingen op de schijf bewaart en die bij herstel alsnog verstuurt, houdt de tijdlijn heel. Datzelfde geldt voor opdrachten: een taak die tijdens de onderbreking was gepland moet daarna alsnog uitgevoerd worden, maar niet zes keer omdat de opdracht zes keer opnieuw is aangeboden. Dat vraagt om opdrachten met een eigen kenmerk en een agent die bijhoudt wat hij al gedaan heeft.
Het derde punt is hoeveel de agent zelf mag beslissen. Een volledig aangestuurde agent is voorspelbaar maar traag: elke handeling moet heen en weer. Een agent met lokaal beleid reageert direct, ook zonder verbinding, maar u moet dat beleid dan wel kunnen uitrollen, versioneren en terugdraaien. In de praktijk werkt een tussenvorm: drempelwaarden en herstelacties lokaal, alles wat impact heeft op meerdere apparaten centraal.
Het vierde punt is hoe de agent aan zijn identiteit komt. Bij het uitrollen moet een vers geïnstalleerde agent zich melden bij het platform en daarna herkenbaar blijven als precies dat apparaat. Gebeurt dat met één gedeeld inschrijfgeheim dat in een installatiescript staat, dan kan iedereen die dat script te pakken krijgt een apparaat aan uw omgeving toevoegen, of zich voordoen als een bestaand apparaat. Een inschrijving die eenmalig geldt, aan een korte geldigheidsduur is gebonden en daarna wordt vervangen door een eigen sleutel per apparaat, lost dat op. Die sleutel moet u ook kunnen intrekken, want een gestolen laptop hoort daarna geen opdrachten meer op te halen.
Een apart onderdeel is meekijken en overnemen. Technisch staat dat los van de automatisering: het is een interactieve sessie waarbij een technicus het scherm ziet en de besturing overneemt. Juist omdat dat de meest zichtbare functie is, verdient hij de striktste regels. Wie mag een sessie starten, ziet de gebruiker dat er iemand meekijkt, moet die daar toestemming voor geven, en wordt vastgelegd wie wanneer op welk apparaat heeft ingelogd. Op een server zonder gebruiker ligt dat anders dan op de laptop van een medewerker, en dat verschil hoort in het rechtenmodel te zitten in plaats van in een werkafspraak.
Praktisch gezien is het meeste werk aan de agent geen hoogstandje maar volhouden. Hij moet op meerdere besturingssystemen draaien en zich op elk daarvan gedragen als een nette dienst. Hij mag niet zoveel processorkracht of schijf gebruiken dat gebruikers hem merken. Hij moet zichzelf kunnen bijwerken, want handmatig langs duizend apparaten gaan is geen optie, en die zelfupdate moet terug kunnen vallen op de vorige versie als de nieuwe niet start. Hij moet netjes stoppen bij het afsluiten van het apparaat en weer opkomen bij het opstarten. En hij moet, tot slot, ook op een apparaat te verwijderen zijn zonder resten achter te laten. Dat laatste klinkt triviaal en is het niet: een beheeragent die je niet fatsoenlijk kwijtraakt, is voor een beveiligingsteam een probleem in plaats van een hulpmiddel.
Niet elk apparaat accepteert bovendien een standaardagent. Kassasystemen, meetopstellingen, industriële besturingen en apparatuur die de leverancier heeft dichtgezet, laten vaak geen willekeurige software toe. Voor die apparaten valt u terug op wat ze zelf aanbieden: een netwerkprotocol, een logbestand, een eigen beheerinterface of soms weinig meer dan een statuslampje. Een beheerplatform dat daar rekening mee houdt, kent naast de agent een tweede weg waarlangs een apparaat zijn toestand kan doorgeven. Dat is een van de weinige situaties waarin een standaardpakket structureel tekortschiet, en daarmee ook een van de plekken waar de vraag naar maatwerk vandaan komt.
Wat de agent aan gegevens verstuurt, verdient een expliciete keuze. Technisch kan hij bijna alles zien wat er op het apparaat gebeurt. Dat betekent niet dat hij dat moet doorsturen. Een verstandige afbakening houdt het bij toestandsgegevens: hardware, besturingssysteem, geïnstalleerde software met versienummers, draaiende diensten, schijfruimte, geheugen, netwerk, status van back-up, antivirus en schijfversleuteling, en de resultaten van uitgevoerde taken. Bestandsinhoud, schermbeelden zonder toestemming en toetsaanslagen horen daar niet bij. Die grens vooraf vastleggen scheelt later een lastig gesprek, en maakt bovendien aantoonbaar dat het systeem geen personeelsvolgsysteem is.
Wat een RMM-platform moet kunnen
Deze onderdelen hangen samen. Statusbewaking zonder opvolging levert een dashboard op dat niemand opent, automatisering zonder rechtenmodel levert een risico op, en een inventaris die niet klopt maakt alle rapportage erboven waardeloos. De volgorde waarin u ze bouwt is dan ook zelden vrij: inventaris eerst, dan bewaking, dan handelingen.
Inventaris die zichzelf bijhoudt
Hardware, besturingssysteem, geïnstalleerde software en versienummers per apparaat, automatisch gemeten in plaats van jaarlijks overgetypt.
Statusbewaking met drempels
Metingen met een norm per groep, zodat afwijkend gedrag opvalt en normale schommelingen geen meldingen veroorzaken.
Scripts en automatisering
Herhaalbaar werk vastgelegd als taak, met versiebeheer, een testgroep en een duidelijk zicht op waar de taak wel en niet draait.
Patchbeheer met bewijs
Niet alleen uitrollen, maar ook meten of de update daadwerkelijk actief is en vastleggen waarom een apparaat achterloopt.
Meldingen die tickets worden
Regels voor samenvoegen, onderdrukken en automatisch sluiten, zodat de wachtrij werk bevat en geen achtergrondruis.
Rechten per technicus en klant
Wie mag meekijken, wie mag uitvoeren en op welke groep apparaten, met een spoor dat achteraf te volgen is.
Patchbeheer is het onderdeel waar het misgaat
Vraag een willekeurige beheerorganisatie welk deel van het RMM het meest oplevert en het antwoord is patchbeheer. Vraag welk deel het vaakst niet doet wat het belooft en het antwoord is hetzelfde. Dat is geen toeval. Patchbeheer is het enige onderdeel waarin het platform iets belooft over de werkelijkheid buiten zichzelf, en die belofte is moeilijk waar te maken.
Het begint met het verschil tussen uitrollen en actief zijn. Een update die is gedownload, is niet geïnstalleerd. Een update die is geïnstalleerd, is niet altijd actief: veel patches worden pas van kracht na een herstart, en juist die herstart is het moment waarop gebruikers afhaken. Een platform dat de status vaststelt op het moment van uitrollen laat groene vinkjes zien voor apparaten die al weken op een herstart wachten. Wie stuurt op dat rapport denkt dat het geregeld is.
Daar komt bij dat de status kan teruglopen. Een image dat wordt teruggezet, een gebruiker die een oudere versie installeert, een toepassing die zichzelf bijwerkt en daarbij een component vervangt: allemaal manieren waarop een apparaat dat vorige week klopte deze week niet meer klopt. Patchstatus is daarom geen gebeurtenis maar een meting die u blijft herhalen, met een tijdstempel erbij, zodat zichtbaar is hoe oud het beeld is.
Het tweede probleem is dekking. Het besturingssysteem is het makkelijke deel: er is een leverancier, een kanaal en een vaste ritmiek. Microsoft heeft Windows Server Update Services aangemerkt als niet langer actief in ontwikkeling, waarbij de bestaande mogelijkheden en inhoud wel beschikbaar blijven voor bestaande implementaties. Dat maakt de vraag waar u het patchen van werkplekken en servers belegt actueler dan hij jaren geweest is.
Belangrijker nog is alles wat naast het besturingssysteem staat. Browsers, PDF-lezers, archiveringsprogramma's, runtimes, database-clients, ontwikkelgereedschap: elk met een eigen leverancier, een eigen installatiemethode en een eigen ritme. Dat is het deel waar de meeste kwetsbaarheden in praktijk daadwerkelijk worden misbruikt, en tegelijk het deel dat het lastigst te automatiseren is, omdat er geen gemeenschappelijk kanaal bestaat. Een RMM die alleen het besturingssysteem bijwerkt, dekt het kleinste deel van het risico.
Waarom uitstellen soms de juiste keuze is
Er is nog een reden dat patchbeheer stroef loopt: meteen alles installeren is niet altijd verstandig. Een update kan een toepassing breken waar een afdeling van afhankelijk is, en de partij die dat merkt is niet degene die de update uitrolde. Beheerorganisaties werken daarom met ringen: een kleine groep apparaten krijgt de update eerst, daarna een grotere groep, dan de rest. Dat werkt alleen als het platform die ringen kent, per ring kan uitstellen, en het uitstel zichtbaar houdt in plaats van het te verstoppen.
Rapportage is het laatste stuk en wordt meestal onderschat. Klanten en auditors vragen niet of u patcht, maar of u kunt aantonen dat u patcht. Dat vereist een rapport dat te reproduceren is voor een moment in het verleden: hoe stond dit landschap er vorige maand voor, welke apparaten liepen achter en om welke reden. Een overzicht dat alleen de huidige stand toont, is voor die vraag onbruikbaar. Historie bewaren is een keuze die u vooraf maakt, want achteraf reconstrueren gaat niet.
Wat het beheersbaar maakt is dat elke uitzondering een reden en een houdbaarheidsdatum krijgt. Een apparaat mag achterlopen omdat een leverancier de nieuwe versie nog niet ondersteunt, maar dan hoort daar een notitie bij en een moment waarop iemand daar opnieuw naar kijkt. Zonder die twee elementen groeit de lijst uitzonderingen stilletjes tot hij het grootste deel van het landschap beslaat, en dat is precies het punt waarop het rapport onbruikbaar wordt. Ziet u dit patroon ook in het onderhoud van fysieke installaties terug, dan is onderhoudssoftware op maat de bijbehorende ingang.
- Status opnieuw meten, niet afleiden uit de uitrol
- Herstart als aparte toestand met eigen opvolging
- Toepassingen naast het besturingssysteem meenemen
- Ringen voor gefaseerd uitrollen en gericht uitstellen
- Elke uitzondering met reden en herzieningsmoment
- Tijdstempel per meting, zodat de leeftijd zichtbaar is
- Mislukte installaties met foutcode in plaats van stilte
Test je idee eerst — werkend prototype in 1 dag
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Van melding naar werk: de koppeling met het ticketsysteem
Een beheerplatform zonder opvolging produceert meldingen waar niemand eigenaar van is. Ze verschijnen op een scherm, verdwijnen als de meting weer normaal wordt, en of iemand er iets mee gedaan heeft valt achteraf niet vast te stellen. Zodra een melding een ticket wordt, verandert dat: er is een nummer, een eigenaar, een status en een moment waarop iemand kan vragen waarom het nog openstaat. Dat is de reden dat de koppeling tussen bewaking en ticketsysteem in de praktijk bepaalt of een RMM iets oplevert.
Technisch is de koppeling het eenvoudigste deel. Het platform stuurt een webhook of roept een API aan, het ticketsysteem maakt een ticket met de melding als tekst, en het ticketnummer gaat terug zodat de melding weet waar hij landde. In de andere richting laat u weten dat een ticket gesloten is, zodat het platform de melding kan afsluiten in plaats van hem eeuwig open te houden.
Het moeilijke deel zijn de regels eromheen, en dat is precies waar standaardkoppelingen vaak tekortschieten. De eerste regel gaat over samenvoegen. Valt een switch weg, dan verliest u niet één apparaat maar veertig, en die veertig meldingen zijn samen één probleem. Zonder afhankelijkheden in het model krijgt de wachtrij veertig tickets, waarvan er negenendertig weer sluiten zodra de switch terug is, en heeft de technicus intussen zijn ochtend verloren. Een platform dat weet welk apparaat achter welke verbinding hangt, maakt er één ticket van met veertig geraakte apparaten.
De tweede regel gaat over meldingen die aan en uit blijven gaan. Een schijf die rond de drempelwaarde schommelt levert elke tien minuten een nieuwe melding op. Daar helpt een wachttijd tegen: pas een ticket aanmaken als de toestand een bepaalde periode aanhoudt, en pas sluiten als hij een periode normaal is gebleven. De derde regel gaat over gepland werk. Draait er onderhoud, dan hoort de bijbehorende ruis in een onderhoudsvenster te vallen dat vooraf is ingesteld, zodat de wachtrij niet volloopt met meldingen die u zelf veroorzaakt.
De vierde regel is de gevaarlijkste: automatisch sluiten. Een ticket dat vanzelf dichtgaat zodra de meting normaal is, houdt de wachtrij schoon, maar verbergt ook problemen die vanzelf overgaan en dan terugkomen. Een schijf die 's nachts volloopt en 's ochtends weer ruimte heeft, is een patroon en geen incident. Een verstandige inrichting sluit zulke tickets wel, maar houdt de herhaling bij en escaleert zodra hetzelfde apparaat het derde keer terugkomt.
Een deel van de meldingen hoeft nooit een ticket te worden. Een dienst die is gestopt en zich weer laat starten, een tijdelijke map die opgeruimd kan worden, een printerwachtrij die vastloopt: dat zijn ingrepen die het platform zelf kan uitvoeren voordat er iemand aan te pas komt. Verstandig is wel om ook die ingrepen vast te leggen. Een herstelactie die stilletjes slaagt, verbergt een patroon, terwijl dezelfde dienst die drie keer per week omvalt juist een probleem is dat u wilt zien. Zelfherstel hoort daarom altijd een notitie op te leveren, en na een ingesteld aantal herhalingen alsnog een ticket.
Tot slot: het ticket moet het apparaat meenemen. Niet alleen de naam, maar het type, de eigenaar, de locatie, de klant en een verwijzing naar de laatst gemeten toestand. Een technicus die dat allemaal zelf moet opzoeken, verliest per ticket meer tijd dan de koppeling oplevert. Wilt u de ticketkant zelf laten bouwen of aanpassen, kijk dan bij een ticketsysteem laten maken en bij helpdesksoftware op maat.
Een RMM heeft overal rechten en is daarmee zelf een doelwit
Dit is het onderwerp dat bij een RMM niet aan het eind mag komen. Een beheerplatform heeft per definitie op elk aangesloten apparaat verregaande rechten: het kan software installeren, code uitvoeren, diensten stoppen en een sessie openen. Dat is geen ontwerpfout maar de kern van het product. Het gevolg is wel dat wie de beheerconsole in handen krijgt, in één klap toegang heeft tot alles wat eraan hangt. Voor een IT-dienstverlener betekent dat: alle klanten tegelijk.
Dat is geen theorie. De Known Exploited Vulnerabilities-catalogus van het Amerikaanse CISA, waarin alleen kwetsbaarheden worden opgenomen waarvan misbruik is vastgesteld, bevat door de jaren heen meerdere beheer- en afstandsbedieningsplatformen. Kaseya VSA staat er sinds november 2021 in met CVE-2021-30116, gemarkeerd als gebruikt bij ransomware. ConnectWise ScreenConnect kwam er in februari 2024 bij met CVE-2024-1709, een omzeiling van de authenticatie waarmee een aanvaller met toegang tot de beheerinterface zelf een beheerdersaccount kon aanmaken, eveneens gemarkeerd als gebruikt bij ransomware. N-able N-central volgde in augustus 2025 met CVE-2025-8875 en CVE-2025-8876, en in augustus 2026 met CVE-2026-18556 en CVE-2026-18577, waarbij CISA bij de tweede noteert dat die het gevolg is van een onvolledige reparatie van de eerste.
Het patroon reikt verder dan het platform zelf. In een advies uit juni 2025 beschrijft CISA hoe ransomware-actoren een niet bijgewerkte installatie van SimpleHelp gebruikten om via een softwareleverancier bij diens klanten binnen te komen. Dat is de doorwerking die een beheerplatform bijzonder maakt: één kwetsbaar systeem in het midden, en daarachter alle omgevingen die eraan hangen. Geen van deze leveranciers doet iets bijzonder onverstandigs; ze zijn interessant omdat hun product per ontwerp veel mag. Elk platform in deze categorie draagt datzelfde risico, inclusief een platform dat u zelf laat bouwen.
Er is nog een tweede manier waarop RMM-software in een aanval voorkomt, en die wordt vaak over het hoofd gezien. In een gezamenlijk advies van CISA, de NSA en het MS-ISAC, herzien op 26 januari 2023, staat beschreven hoe aanvallers legitieme beheersoftware niet aanvallen maar gebruiken: via phishing lieten zij slachtoffers ScreenConnect en AnyDesk downloaden als zelfstandige uitvoerbare bestanden. Omdat zulke bestanden geen installatie en geen beheerdersrechten nodig hebben, glippen ze langs controles die alleen naar geïnstalleerde software kijken. Voor uw eigen beheerlandschap betekent dat: houd bij welke beheergereedschappen in uw omgeving thuishoren, en behandel elk ander exemplaar als verdacht. Het volledige advies staat op cisa.gov.
Wat dat betekent voor het ontwerp
Als u accepteert dat het platform zelf het doelwit is, verandert de bouwvolgorde. Authenticatie is dan geen sluitstuk maar het eerste onderwerp: meervoudige authenticatie voor iedereen, zonder uitzondering voor de beheerder die haast heeft. De beheerconsole hoort niet zomaar vanaf het open internet bereikbaar te zijn, terwijl de agents wel overal vandaan moeten kunnen inbellen; dat zijn twee verschillende ingangen die u ook los hoort te behandelen.
Rechten verdienen dezelfde aandacht. Eén rol die alles mag op alle apparaten is comfortabel en zelden nodig. Rechten per technicus, per klantgroep en per type handeling maken de schade bij een gestolen account kleiner. Voor handelingen met groot bereik, zoals een script dat op alle apparaten tegelijk draait, is een goedkeuringsstap door een tweede persoon een van de weinige maatregelen die een aanvaller met geldige inloggegevens echt tegenhoudt.
Beheert u meerdere klanten in hetzelfde platform, dan komt de scheiding daartussen erbij. Die scheiding hoort niet alleen in de weergave te zitten maar ook in de gegevens en in de sleutels: een technicus die per ongeluk of met opzet buiten zijn klantgroep kijkt, moet tegen een muur lopen en niet tegen een filter. Datzelfde geldt voor scripts en beleidsregels, die makkelijk landelijk gedefinieerd worden en dan bij iedereen terechtkomen. Dit is een van de weinige punten waarop zelf bouwen in het voordeel is, omdat u de grenzen zelf bepaalt in plaats van ze af te leiden uit het model van een leverancier. Daar staat tegenover dat het volgen van kwetsbaarheden en het uitbrengen van reparaties dan ook bij uw eigen organisatie ligt.
Logging hoort buiten het platform te landen. Een aanvaller die de beheerconsole overneemt, wist als eerste de sporen. Logregels die naar een aparte omgeving worden weggeschreven, blijven bestaan en maken achteraf reconstructie mogelijk. Datzelfde geldt voor waarschuwingen: als het platform uitvalt of wordt overgenomen, mag de melding daarover niet via datzelfde platform hoeven te lopen.
Tot slot het juridische kader, dat sinds kort concreter is. Op 15 augustus 2026 is in Nederland de Cyberbeveiligingswet in werking getreden, de implementatie van de Europese NIS2-richtlijn, die de Wet beveiliging netwerk- en informatiesystemen vervangt. Organisaties die eronder vallen moeten zich registreren in het entiteitenregister, passende maatregelen nemen op basis van een risicoanalyse en significante incidenten binnen 24 uur melden bij hun CSIRT en de toezichthouder, waarbij het bestuur eindverantwoordelijk is. Of uw organisatie eronder valt hangt af van sector en omvang; partijen die het ICT-beheer van anderen uitvoeren doen er goed aan dat expliciet na te gaan. Het NCSC beschrijft de verplichtingen en de registratie.
- Meervoudige authenticatie zonder uitzonderingen
- Beheerconsole niet open op het internet
- Rechten per technicus en per klantgroep
- Goedkeuring bij handelingen met groot bereik
- Logging weggeschreven buiten het platform
- Waarschuwingskanaal los van het platform zelf
- Inventaris van toegestane beheergereedschappen
- Herstelplan voor het geval het platform uitvalt
Veelgestelde vragen over RMM-software
Een monitoringtool signaleert en stopt daar: hij meet, vergelijkt met een drempelwaarde en stuurt een melding. Een RMM voegt daar handelingsvermogen aan toe. Dezelfde agent die de schijfvulling meet kan ook een script draaien, een update installeren, een dienst herstarten of een sessie openen naar het apparaat. Het verschil zit dus niet in het meten maar in de rechten: een RMM mag het apparaat veranderen. Dat maakt het krachtiger en tegelijk gevoeliger, want die rechten gelden op elk aangesloten apparaat.
Nee, een RMM kijkt naar apparaten en niet naar personen: welke updates ontbreken, of de schijf volloopt, of de back-upagent draait, of de schijfversleuteling aanstaat. Software die registreert wat een medewerker doet, zoals actieve tijd per applicatie, bezochte websites of toetsaanslagen, is een andere categorie met een eigen juridisch kader. Zoekt u dat, kijk dan bij employee monitoring software. Bouwt u een RMM, dan is het verstandig die functies bewust buiten de scope te houden en dat ook te kunnen aantonen.
Omdat het rapport en de werkelijkheid uit elkaar groeien. Het platform meldt dat een update is uitgerold, terwijl het apparaat nog op een herstart wacht, de gebruiker die herstart blijft uitstellen of de update door een ander proces is teruggedraaid. Daarbij verschuift het risico naar de toepassingen naast het besturingssysteem: browsers, PDF-lezers, runtimes en hulpprogramma's. Patchbeheer werkt pas als per apparaat en per pakket zichtbaar is welke versie nu draait, wanneer dat voor het laatst is gemeten en waarom een update niet is doorgekomen.
Technisch is dat meestal een webhook of een API-aanroep die van een melding een ticket maakt, met een verwijzing terug naar het apparaat. De moeilijkheid zit in de regels eromheen: welke meldingen verdienen een ticket, welke worden samengevoegd tot één, wanneer sluit een ticket vanzelf als de meting weer normaal is, en hoe voorkomt u dat een korte netwerkonderbreking honderd losse tickets oplevert. Zonder die regels verandert de wachtrij in een logboek dat niemand meer leest en verdwijnt het echte probleem tussen de ruis.
Door aan te nemen dat het platform zelf het doelwit is. Dat betekent meervoudige authenticatie zonder uitzondering voor beheerders, een beheerconsole die niet zomaar vanaf het open internet bereikbaar is, rechten per technicus en per klantgroep in plaats van één rol die alles mag, scripts die pas na goedkeuring op grote schaal mogen draaien, en logging die naar een omgeving buiten het platform wordt weggeschreven zodat een aanvaller haar niet kan wissen. De Known Exploited Vulnerabilities-catalogus van CISA bevat meerdere beheer- en afstandsbedieningsplatformen, wat laat zien dat dit geen theoretisch scenario is.
Vaak wel, en dat zeggen we liever vooraf dan halverwege. De markt is volwassen: NinjaOne, Datto RMM, ConnectWise, Kaseya VSA, N-able N-central, Atera, Syncro en Action1 dekken samen het gangbare beheerwerk, en daarnaast bestaan er opensourceopties zoals Tactical RMM. Beheert u een regulier Windows- en macOS-landschap, dan koopt u dat kant-en-klaar in. Maatwerk wordt pas interessant bij apparatuur die geen standaardagent accepteert, bij een beheerproces dat niet in het datamodel van een pakket past, of wanneer u beheerfunctionaliteit in uw eigen product wilt opnemen.
Gerelateerde diensten
Employee monitoring software
Zoekt u juist software die kijkt naar wat medewerkers doen in plaats van naar de toestand van hun apparaat, dan is dat een andere categorie met een eigen juridisch kader. Zie employee monitoring software laten maken.
Ticketsysteem op maat
De wachtrij waarin meldingen werk worden, met eigen statussen, afspraken en rapportage per klant: een ticketsysteem laten maken, of breder helpdesksoftware op maat.
Onderhoudssoftware op maat
Draait het niet om werkplekken maar om installaties, machines en periodiek onderhoud in het veld, dan hoort die vraag bij onderhoudssoftware laten maken. Een breder overzicht staat bij software-ontwikkeling.
Uw beheerlandschap onder de loep
Vertel ons hoeveel apparaten u beheert en hoe verschillend ze zijn, wat er nu gebeurt met een melding om drie uur 's nachts, en hoe u vaststelt of een beveiligingsupdate daadwerkelijk actief is. Uit die drie antwoorden blijkt meestal of een bestaand pakket volstaat, of er een koppeling omheen nodig is, of dat maatwerk de verstandigste route is.