Zo stelt u een EoS-governancebeleid op voor legacy en gespecialiseerde klantapparatuur

Apparatuur die het einde van de support heeft bereikt (verouderde of gespecialiseerde hardware) blijft de kosten opdrijven en risico’s veroorzaken zolang die niet uit een technische klantomgeving wordt verwijderd. Managed service providers (MSP’s) kunnen dat risico beheersen door deze devices volgens een vast schema te identificeren, te volgen en uit te faseren. Deze gids laat zien hoe u een EoS-governancebeleid opstelt voor legacy en gespecialiseerde klantapparatuur.

Wilt u snel een visueel overzicht? Bekijk dan onze videogids Een governancebeleid voor einde support opstellen voor legacy en gespecialiseerde klantapparatuur.

Zo stelt u een governancebeleid op voor EoS-devices

Een EoS-governancebeleid is een gedocumenteerde standaard die vastlegt wanneer legacy en gespecialiseerde devices worden uitgefaseerd, wie elke uitfasering goedkeurt en hoe elke uitfasering wordt vastgelegd. Het helpt MSP’s en IT-teams om uitfaseringen vooraf te plannen en elke beslissing consistent, gedocumenteerd en in lijn met compliance-eisen te houden.

Vereisten:

• Nauwkeurige inventarisgegevens van de klant met device-informatie (waaronder uitrolddatum, versies van het besturingssysteem en garantiedekking)
• Afstemming met stakeholders over de verantwoordelijkheden voor support en uitfasering
• Toegang tot tools voor tracking en automatisering, zoals gedeelde trackers, eigen scripts, een platform voor professional services automation (PSA) of NinjaOne
• Kennis van de geldende compliance-eisen (bijvoorbeeld HIPAA, PCI, ISO 27001)

Bepaal de reikwijdte en de criteria voor uitfasering

Begin met vastleggen welke devices in aanmerking komen voor uitfasering en werk uit onder welke voorwaarden dat proces start. Zo voorkomt u inconsistente beslissingen, over het hoofd geziene devices en discussies met klanten.

Identificeer eerst de categorieën devices die binnen de reikwijdte vallen, zoals:

• Legacy devices: Hardware die de door uw organisatie ondersteunde lifecycle (meestal 5 tot 7 jaar) heeft overschreden of niet langer aan de supportvereisten voldoet.
• Gespecialiseerde apparatuur: Nichedevices in gespecialiseerde omgevingen, zoals laboratoria of kiosken of met propriëtaire software
• Niet-ondersteunde assets: Devices die geen updates voor OS, drivers of firmware meer ontvangen
• Niet-compliant devices: Devices zonder de vereiste beveiligingsfuncties (bijvoorbeeld TPM, encryptie)

Bepaal vervolgens de triggers voor uitfasering, zoals:

• Einde van de fabrikantsupport: Hardware of software wordt niet langer onderhouden
• Beveiligingsbaseline wordt niet gehaald: Niet-ondersteund OS of geen patches beschikbaar
• Overbodigheid: De rol van het device is achterhaald door infrastructuurupgrades
• Operationeel risico: Frequente storingen, impact door uitvaltijd of prestatieproblemen

Een kader voor uitzonderingen is eveneens een goede beveiliging, bijvoorbeeld tijdelijke verlengingen of bedrijfskritische devices waarvoor voortgezet gebruik gedocumenteerd moet worden onderbouwd.

Maak een formele template voor uw EoS-beleid

De volgende stap is het standaardiseren van de documentatie van deze beslissingen over uitfasering. Dit levert een herhaalbaar kader op dat consistentie ondersteunt en onduidelijkheid voorkomt tijdens audits, quarterly business reviews (QBR’s) of budgetbesprekingen. U wilt elke keer dezelfde velden vastleggen, bijvoorbeeld:

Veld	Omschrijving/doel	Voorbeeldinvoer
Devicecategorie	Bepaalt het type apparatuur dat onder het beleid valt	“Legacy Win7-werkstations”, “IoT-sensoren zonder TLS”
Supportvenster	Standaardduur van de support vóór uitfasering	“7 jaar vanaf uitrol” of “OS-support +12 maanden (of volgens het lifecyclebeleid van uw organisatie)”
Einddatum	Formele laatste supportdatum voor het device	“31-12-2026”
Stappen voor uitfasering	Stapsgewijze acties om verantwoord buiten gebruik te stellen	Back-up → Verwijdering → Wissen van data → Vervanging
Meldingsproces	Communicatieplan voor stakeholders	Waarschuwingsmail 90 dagen vooraf → herinnering na 30 dagen → laatste melding
Eigenaar	Persoon of team dat verantwoordelijk is voor beoordeling, goedkeuring en uitvoering	IT-manager, vCIO van de klant of MSP Operations Lead
Omgang met uitzonderingen	Legt de voorwaarden vast voor tijdelijke verlengingen of bijzondere goedkeuringen	“Elk kwartaal beoordeeld, vereist goedkeuring van de CIO”
Auditnotities	Ruimte om de bevestiging van uitfasering, de verificatie van het wissen en archiefverwijzingen te noteren	“Device uitgefaseerd op 30-6-2024 – wissen geverifieerd”

Bewaar alle verzamelde informatie in een gedeelde opslagplaats (bijvoorbeeld SharePoint, Google Drive of een PSA-knowledge base) en stem die af op uw overige lifecycledocumentatie (bijvoorbeeld onboarding en refresh-SOP’s), zodat het een levende standaard voor consistentie wordt.

Segmenteer legacy assets en volg ze apart

Legacy devices los van de hoofdinventaris voor het dagelijkse fleetbeheer volgen is een goede praktijk om te voorkomen dat u ze over het hoofd ziet. Dankzij die segmentatie kunnen MSP’s risico’s monitoren, vervangingen plannen en aan klanten duidelijk maken welke assets een uitzondering vormen op het standaard lifecycleproces.

Neem bij het volgen van deze assets velden op zoals:

• Devicenaam en model
• Rol of bedrijfsfunctie
• Uitroldatum en huidige leeftijd
• Huidige EoS-status (waarschuwing, verlopen, uitzondering)
• Geplande streefdatum voor vervanging of uitfasering

Overweeg om de volgende bronnen samen te gebruiken om een helder en bruikbaar beeld te houden van alle legacysystemen:

• Een gedeeld Excel- of Sheets-bestand voor gezamenlijk inzicht
• Aangepaste velden in NinjaOne voor rol en lifecyclefase
• NinjaOne-tags zoals EOL_Warning, Legacy_OS of Unsupported_Hardware

Spoor kandidaten automatisch op met lichte scripts

Overweeg om EoS-beoordelingen te automatiseren en zo te versnellen. U kunt kleine, veilige scripts uitvoeren op endpoints of op uw RMM-inventaris om devices te vinden die mogelijk aan de criteria voor een EoS-beoordeling voldoen. Die resultaten sluist u vervolgens door naar uw tracker en workflows.

Hier volgt een voorbeeld van een PowerShell-script dat u lokaal, via NinjaOne-automatisering of op een devicegroep kunt uitvoeren om Windows-installaties ouder dan een vastgestelde leeftijdsgrens te signaleren voor een EoS-beoordeling:

$cutoff = (Get-Date).AddYears(-5) $info = Get-ComputerInfo $installDate = [datetime]$info.OsInstallDate [PSCustomObject]@{ ComputerName = $info.CsName OsInstallDate = $installDate } | Export-Csv -Path "EOL_Candidates.csv" -NoTypeInformation }

In dit script:

• $cutoff = (Get-Date).AddYears(-5) bepaalt uw leeftijdsgrens. In dit voorbeeld worden Windows-installaties ouder dan 5 jaar gemarkeerd voor beoordeling. Pas dit aan naar 6–7 jaar als dat uw interne beleid is.
• Get-ComputerInfo verzamelt lokale systeemgegevens, waaronder de installatiedatum van het OS en de computernaam.
• if ($installDate -lt $cutoff) controleert of de installatiedatum ouder is dan de grenswaarde.
• [PSCustomObject] zet de uitvoer om in een overzichtelijk, gestructureerd object.
• Export-Csv -Path “EOL_Candidates.csv” -NoTypeInformation exporteert de resultaten naar een CSV-bestand dat u handmatig aan een ticket kunt koppelen of kunt importeren in een EoS-tracker of een compatibel PSA-systeem.

U kunt de detectie verder verbeteren door het volgende te controleren:

• OS-versie of nabijheid van het einde van de lifecycle (Windows 10 bereikte bijvoorbeeld het einde van de mainstream support op 14 oktober 2025, waardoor devices die niet zijn aangemeld voor het programma Extended Security Updates (ESU) van Microsoft geen beveiligingsupdates meer ontvangen; ESU voor consumenten loopt tot 12 oktober 2027 en commerciële ESU loopt in stappen van een jaar tot 10 oktober 2028)
• Hiaten in de beveiligingsbaseline (bijvoorbeeld aanwezigheid van TPM, Secure Boot, schijfversleuteling, ondersteunde AV/EDR)
• Rol en kritiek belang van het device
• Garantie versus leeftijd
• Datum van de laatste vervanging of refresh
• Consistentie van de uptime of onbeheerd gebruik

Een praktische workflow ziet er ongeveer zo uit:

1. Voer het basisscript volgens een vast schema uit (bijvoorbeeld dagelijks ’s nachts of wekelijks), afhankelijk van de beoordelingsfrequentie van uw organisatie.
2. Vul aan met extra velden (OS-versie, TPM, garantie).
3. Voorzie gemarkeerde endpoints in NinjaOne van tags (EOL_Warning, Unsupported_OS, No_TPM).
4. Synchroniseer de CSV met uw gedeelde EoS-tracker (of voeg deze automatisch toe via de API).
5. Laat PSA-tickets of QBR-rapporten aanmaken voor alles wat “Unsupported” is of “< 90 dagen tot einde support EOS”.

Informeer stakeholders en plan beoordelingen

Nadat u EoS-kandidaten hebt gemarkeerd, communiceert u met uw klanten en biedt u gestructureerde beoordelingen aan om het proces transparant te houden. Laat hen weten wat eraan komt, zodat ze hun budget kunnen afstemmen en niet worden overvallen door plotselinge uitfaseringen. Enkele beste praktijken:

• Gebruik automatisch gegenereerde PSA-notificaties en -tickets wanneer devices een leeftijds- of supportgrens overschrijden.
• Plan elk kwartaal beoordelingen die aansluiten op QBR’s en budgetcycli.
• Verstuur meldingen in fasen (bijvoorbeeld waarschuwing 90 dagen vooraf → herinnering na 30 dagen → definitieve melding van uitfasering).
• Deel rapporten met klanten waarin gemarkeerde devices, hun status en aanbevelingen voor uitfasering worden uitgelicht.

Beheer het goedkeurings- en uitfaseringsproces

Voor gemarkeerde EoS-apparatuur is nog altijd een helder en toerekenbaar proces nodig vóór de uitfasering, zeker wanneer het device een kritieke of gespecialiseerde functie vervult. Zo voorkomt u dat assets voortijdig worden verwijderd en kunnen klanten meebeslissen.

Overweeg dit proces, dat operationeel risico afweegt tegen transparantie naar de klant:

1. Trigger: Het device voldoet aan de EoS-criteria (leeftijd, niet-ondersteund OS, compliance-hiaat).
2. Melden: De aangewezen eigenaar (MSP Operations Lead, IT-manager of vCIO) ontvangt een notificatie of ticket.
3. Beoordelen: Bepaal of het device langer in gebruik blijft, wordt geïsoleerd of wordt vervangen en weeg daarbij bedrijfskritisch belang, gespecialiseerd gebruik of verzoeken om een uitzondering mee.
4. Goedkeuren: Formele akkoordverklaring van de IT-leiding of de contactpersoon bij de klant is vereist vóór er actie wordt ondernomen.
5. Uitvoeren: Voer de stappen voor uitfasering uit (bijvoorbeeld back-up, wissen van data, verwijderen of vervangen van hardware)
6. Archiveren: Werk de tracker bij met de uitfaseringsdatum, de bevestiging van het wissen en notities.
7. Bewaren: Houd de gegevens bij voor audits, compliance en toekomstig gebruik.

Rond het proces af met archivering en auditnotities

De laatste stap is een correcte documentatie van elk uitgefaseerd device om de beveiliging en traceerbaarheid te waarborgen. Denk aan de volgende taken:

• Werk de tracker bij: Noteer de uitfaseringsdatum, de gegevens van de vervanging en de bevestiging dat de data zijn gewist.
• Archiveer logs: Bewaar ze in een beveiligde, centrale map zodat u klaar bent voor audits.
• Bewijs van compliance: Houd notities bij die aansluiten op de wettelijke vereisten (HIPAA, PCI, ISO enzovoort).
• QBR-rapportage: Gebruik de gearchiveerde gegevens om klanten een meetbare afname van technische schuld te laten zien.

Overzicht van beste praktijken

Uw EoS-governancebeleid moet eenvoudig, herhaalbaar en transparant zijn. Hier volgen enkele beste praktijken waarmee MSP’s blinde vlekken voorkomen, handmatig werk beperken en vertrouwen bij klanten opbouwen

Element	Doel
Duidelijke EoS-criteria	Voorkomt onduidelijkheid over wanneer en waarom een device moet worden uitgefaseerd
Standaarddocumentatie	Zorgt dat elke uitfasering een herhaalbaar, transparant proces volgt
Segmentatie van de inventaris	Markeert risicovolle devices zonder de rapportage over de kernfleet te vervuilen
Lichte automatisering	Vermindert handmatige tracking en brengt kandidaten efficiënt in beeld, zeker bij grote fleets
Formele beoordeling en goedkeuring	Houdt de compliance intact en stemt de communicatie met de klant af op de beslissingen
Auditklare uitfaseringslogs	Zorgt voor traceerbaarheid, ondersteunt compliance en toont due diligence aan

Waarom een governancebeleid voor EoS-apparatuur belangrijk is

Verouderde hardware, zoals sterk gespecialiseerde of legacy apparatuur, wordt snel een risico doordat support, patches en andere cruciale updates ontbreken, waardoor systemen blootstaan aan ernstige gevaren. Een EoS-governancebeleid voor dit soort apparatuur zou moeten helpen om:

• Beveiligingsrisico’s te verkleinen: Onveilige en kwetsbare endpoints slim uitfaseren of isoleren is cruciaal voordat ze toegangspoorten worden voor bedreigingen voor het bredere systeem.
• Operationele continuïteit te waarborgen: Legacy apparatuur kan op elk moment uitvallen. Formele criteria voor uitfasering helpen om die snel te vervangen en uitvaltijd te beperken.
• Klaar te zijn voor compliance-audits: Heldere documentatie van hoe en wanneer niet-ondersteunde devices worden uitgefaseerd helpt organisaties te voldoen aan regelgeving zoals HIPAA, PCI of ISO en voorkomt dat tijdens beveiligingsbeoordelingen nalatigheid wordt vastgesteld.
• Financiële planning en kostenbeheersing te ondersteunen: Klanten kunnen op aankomende vervangingsdata anticiperen en zo hun budget afstemmen op het lifecyclebeheer van hun apparatuur.
• De communicatie met en verwachtingen van klanten te verbeteren: Een goed beheerde en systematische device-lifecycle met formele workflows voor meldingen vergroot het vertrouwen en de transparantie.

Integratiemogelijkheden met NinjaOne

NinjaOne biedt geen ingebouwde logica voor EoS-governance, maar geeft MSP’s wel het inzicht en het automatiseringskader dat dit governanceproces ondersteunt. Hieronder staan enkele belangrijke integratiemethoden:

Integratiemethode	Wat het oplevert	Voorbeeld van een use case
Aangepaste velden	Lifecyclegegevens opslaan (EoS-status, laatste refresh, risiconiveau)	Devices filteren die tijdens beoordelingen het einde van hun leven naderen
Geplande rapporten	Automatisch rapporten genereren over niet-ondersteunde OS-builds of oude uitrollen	Delen tijdens QBR’s om technische schuld te belichten
Geautomatiseerde scripts	Controles uitvoeren op leeftijd, OS-versie of ontbrekende beveiligingsfuncties	Gemarkeerde endpoints automatisch taggen en exporteren naar uw EoS-tracker voor beoordeling
Notificatiebeleid	Proactieve meldingen activeren wanneer devices aan de EoS-criteria voldoen	PSA-tickets aanmaken wanneer een device wordt gemarkeerd als voorbij de supportdatum
Gegevensexport	Devicegegevens exporteren voor trackers of samenwerking	NinjaOne-rapporten synchroniseren met Excel/Sheets of PSA-dashboards
Tags	Devices categoriseren en visueel markeren op basis van lifecyclestatus of risico	Tags zoals EOL_Warning, Legacy_OS of Unsupported_Hardware toepassen om snel te filteren en automatiseringen te starten

EoS-governance als strategisch voordeel

Een governancebeleid voor einde support (EoS) bij legacy en gespecialiseerde klantapparatuur geeft structuur aan het risicovolle proces van het uitfaseren van devices. De bovenstaande stappen helpen MSP’s beveiligingsrisico’s te verkleinen en compliance te ondersteunen, terwijl ze aansluiten op de behoeften van hun klanten. Volg altijd de beste praktijken om een workflow op te bouwen die uw rol als strategische partner van uw klanten laat zien.

Gerelateerde onderwerpen:

• IT-activa-inventaris: definitie, beheer en beste praktijken
• IT-asset-lifecycle en -management (ITAM) uitgelegd
• Wat is software die het einde van de support heeft bereikt? Een gids
• Overzicht van endpoint-lifecyclebeheer