07-09-2026

Voor veel organisaties vallen in 2026 belangrijke supportdeadlines samen. Umbraco 13 bereikt op 14 december 2026 End of Life en Kentico Xperience 13 bereikt op 31 december 2026 End of Support. Ook bij Sitecore en Optimizely schuiven versies door naar een volgende supportfase. In gesprekken met onze klanten roept dat telkens dezelfde vraag op: is onze website na die datum onveilig?

Het korte antwoord is genuanceerder dan de datum suggereert. Een website die op 31 december veilig draait, is op 1 januari niet plotseling lek. Wat wegvalt, is de zekerheid dat de leverancier een nieuw ontdekt beveiligingslek nog voor je repareert.

In een eerder artikel beschreven we waarom een End-of-Life-CMS je digitale groei kan blokkeren. In dit artikel kijken we naar de gevolgen voor de veiligheid van je website en naar wat je kunt doen zolang een migratie nog even op zich laat wachten.

Is een website direct onveilig na End of Support?

Nee. End of Support is geen aan-uitknop voor veiligheid.

Een website die op de laatste dag van de supportperiode goed beveiligd is, kan ook daarna nog enige tijd veilig blijven draaien. Het probleem ontstaat wanneer er een nieuwe kwetsbaarheid wordt ontdekt en je CMS-versie buiten de support valt.

Dan is er mogelijk geen leverancier meer die:

• onderzoekt of jouw versie geraakt wordt;
• een beveiligingsupdate ontwikkelt;
• een officiële patch beschikbaar stelt;
• ondersteuning biedt bij het oplossen van het probleem.

De verantwoordelijkheid verschuift dan in grotere mate naar je eigen organisatie en naar je technologiepartner. Je moet zelf sneller kunnen vaststellen of je omgeving kwetsbaar is, welke tijdelijke maatregelen nodig zijn en hoe je een oplossing implementeert.

De vraag is daarom niet alleen: Is mijn website vandaag veilig?

Belangrijker is: Wat gebeurt er als er morgen een nieuw beveiligingslek wordt ontdekt?

Kun je dan snel bepalen of jouw website geraakt wordt? Is er een leverancier die het probleem repareert? En kun je binnen een dag een oplossing testen en live zetten?

Wat betekent End of Life in de praktijk?

Leveranciers gebruiken verschillende termen voor het einde van een supportperiode. De precieze betekenis verschilt per product en per contract, maar de onderliggende vraag is steeds dezelfde: Wie repareert straks een nieuw gevonden kwetsbaarheid in jouw CMS-versie?

Kentico Xperience 13

Kentico spreekt bewust van End of Support. Kentico Xperience 13 blijft na 31 december 2026 gewoon draaien, maar vanaf 1 januari 2027 verschijnen er volgens het supportbeleid geen reguliere verbeteringen, reparaties of beveiligingsupdates meer.

De website verdwijnt dus niet automatisch en stopt niet vanzelf. Wel neemt de onzekerheid toe zodra er een nieuw probleem wordt gevonden.

Umbraco 13

Umbraco 13 bereikt op 14 december 2026 End of Life. Vanaf dat moment zijn reguliere product- en beveiligingsupdates niet langer beschikbaar. Voor Umbraco 13 is er wel een mogelijkheid om tegen betaling verlengde ondersteuning af te nemen, onder de voorwaarden die Umbraco daarvoor hanteert.

Sitecore en Optimizely

Sitecore werkt met verschillende supportfases. Wat je precies blijft ontvangen, hangt af van de versie en het afgesloten contract. Ook bij Optimizely verschillen de supportmogelijkheden per product en versie.

De termen verschillen dus per leverancier. De praktische consequentie is vergelijkbaar: zodra je versie buiten de reguliere support valt, moet je zelf meer verantwoordelijkheid nemen voor monitoring, risicobeoordeling en herstel.

Welke CMS- en platformdeadlines zijn belangrijk?

Kijk bij lifecyclemanagement niet alleen naar de einddatum van je CMS. Ook de software waarop je CMS draait, kan eerder buiten support raken.

Bij Umbraco en Kentico is .NET bijvoorbeeld een belangrijke onderliggende component. Daarnaast hebben ook databases, hostingomgevingen, webservers, plugins en externe packages hun eigen support- en updatecycli.

Microsoft beëindigt volgens de huidige supportkalender op 10 november 2026 de ondersteuning van .NET 8 en .NET 9. Maar .NET 10 blijft volgens diezelfde kalender tot november 2028 ondersteund.

Een organisatie die alleen naar de CMS-datum kijkt, kan dus een eerdere deadline missen. Controleer lifecycledata altijd in de actuele documentatie van de betreffende leverancier voordat je deze in een planning of publicatie opneemt.

Waarom hangt de veiligheid van je website niet alleen van het CMS af?

Een moderne website bestaat uit een keten van onderdelen met ieder een eigen levenscyclus:

• het CMS;
• het softwareplatform, zoals .NET;
• de database;
• de webserver en hosting;
• externe packages, plugins en modules;
• JavaScript-bibliotheken;
• koppelingen met andere systemen;
• gebruikersaccounts en beheerrechten;
• maatwerkcode;
• monitoring, back-ups en deploymentprocessen.

Je CMS kan volledig bijgewerkt zijn terwijl er ergens anders in de softwareketen een verouderd onderdeel met een bekende kwetsbaarheid meedraait. Andersom kan een ouder CMS goed zijn afgeschermd, terwijl een nieuw CMS verkeerd is geconfigureerd.

De veiligheid van je website is daarom de optelsom van de hele technische keten. Die keten verdient één duidelijke eigenaar.

Welke voorbeelden laten zien waarom support belangrijk is?

Hoe waardevol support is, merk je vooral zodra er iets misgaat.

Umbraco bracht op 18 augustus 2026 updates uit voor meerdere kwetsbaarheden, waaronder één ernstig beveiligingslek. De ondersteunde versies 17 en 18 kregen die update. De eveneens geraakte versies 14, 15 en 16 niet.

Optimizely bracht begin 2025 reparaties uit voor onder meer een kwetsbaarheid waarmee schadelijke code in webpagina’s kon worden geplaatst. Voor klanten die niet direct konden bijwerken, waren tijdelijke maatregelen beschikbaar.

Zolang je versie wordt ondersteund, kun je bij een dergelijk probleem terugvallen op de leverancier. Zodra je versie buiten support valt, moet je mogelijk zelf:

• vaststellen of jouw omgeving kwetsbaar is;
• bepalen hoe groot het risico is;
• tijdelijke maatregelen nemen;
• een eigen oplossing ontwikkelen;
• een patch testen en onderhouden;
• versneld migreren naar een ondersteunde versie.

Welke maatregelen kun je nemen vóór de supportdatum?

Een migratie naar een nieuw platform staat zelden binnen een maand. Ook als je al besloten hebt te migreren, is het belangrijk om de bestaande omgeving zo goed mogelijk te beschermen.

Vier maatregelen leveren in de praktijk vaak het meeste op.

1. Houd systemen up-to-date

Gebruik altijd de laatste veilige versies van het CMS, het onderliggende softwareplatform, de database, het besturingssysteem en alle externe packages, plugins en modules. Maak patching onderdeel van een vast proces. Houd bij welke componenten en versies worden gebruikt, wanneer updates beschikbaar zijn en wie verantwoordelijk is voor beoordeling, testen en uitrol.

2. Beperk toegang tot de beheeromgeving

Een publiek toegankelijke beheeromgeving vergroot het aanvalsoppervlak. Stel deze daarom alleen open voor bekende IP-adressen, bijvoorbeeld van je eigen organisatie en technologiepartner. Combineer dit waar mogelijk met centraal inloggen, multifactorauthenticatie, sterke wachtwoorden en minimale toegangsrechten. Verwijder oude accounts, monitor mislukte inlogpogingen en controleer periodiek welke beheerdersrechten nog nodig zijn. Deze maatregelen voorkomen geen CMS-kwetsbaarheden, maar beperken wel de mogelijkheden voor aanvallers.

3. Gebruik een Web Application Firewall

Een Web Application Firewall, of WAF, controleert het verkeer naar je website en kan bekende aanvalspatronen blokkeren voordat ze de applicatie bereiken. Een WAF vervangt echter geen updates en goede beveiliging. Zorg daarom voor actuele regels, beperkte uitzonderingen en monitoring van geblokkeerd verkeer. Test nieuwe regels eerst in detectiemodus en controleer de werking na wijzigingen aan de website. Een verkeerd ingestelde WAF kan legitiem verkeer blokkeren of een vals gevoel van veiligheid geven.

4. Controleer packages en dependencies

Websites gebruiken vaak externe packages, plugins en libraries. Deze kunnen kwetsbaarheden bevatten of besmet raken, waardoor aanvallers meerdere websites tegelijk kunnen bereiken. Houd daarom bij welke dependencies worden gebruikt en controleer ze automatisch op bekende kwetsbaarheden, bijvoorbeeld met NuGet Audit in de buildpipeline. Beperk toegestane packagebronnen en de personen die nieuwe packages mogen toevoegen. Gebruik waar passend Package Source Mapping, controleer JavaScript-packages op herkomst en Trusted Publishing via OIDC en verwijder ongebruikte onderdelen.

Wat verandert AI aan het dreigingsbeeld?

AI maakt cyberaanvallen niet automatisch volledig zelfstandig. De belangrijkste verandering voor organisaties zit voorlopig vooral in snelheid, kosten en schaal.

Anthropic publiceerde in april 2026 onderzoek naar Claude Mythos Preview, een AI-model dat opvallend sterk bleek in het opsporen van kwetsbaarheden en het bouwen van aanvalscode. Het Britse AI Security Institute publiceerde een eigen evaluatie van diezelfde capaciteiten.

Deze experimenten vonden plaats onder strak geregelde omstandigheden. Het model kreeg:

• de broncode van het onderzochte programma;
• een afgeschermde testomgeving;
• een expliciete opdracht om een kwetsbaarheid te zoeken.

Alleen het onderzoek naar één kwetsbaarheid vroeg ongeveer duizend pogingen. Volgens Anthropic bleven de kosten daarbij onder de 20.000 dollar.

Dat is iets anders dan een aanvaller die zich afvraagt of de website van een regionale onderwijsinstelling toevallig op een oude Umbraco-versie draait. Voor zo’n organisatie is een speciaal ontwikkelde, nog onbekende aanval meestal niet het meest waarschijnlijke scenario.

Waarom extra beveiliging geen vervanging is voor CMS-support

Aanvullende maatregelen kunnen het risico aanzienlijk verlagen, maar ze repareren geen fout in software waarvoor geen update meer verschijnt.

Een WAF houdt bekende aanvalspatronen tegen, maar niet iedere nieuwe kwetsbaarheid. Een inbraaktest geeft inzicht in de situatie op dat moment, maar geen garantie voor de toekomst. Multifactorauthenticatie beschermt beheeraccounts, maar maakt verouderde maatwerkcode niet veilig.

Zie aanvullende beveiliging daarom als:

• een extra beschermingslaag;
• een manier om tijd te winnen;
• onderdeel van risicobeheersing;
• geen structureel alternatief voor een ondersteund platform.

Wanneer moet je beginnen met migreren?

Begin niet op de End-of-Life-datum, maar ruim daarvoor. Een gecontroleerde migratie kost tijd en de benodigde doorlooptijd hangt onder meer af van:

• de hoeveelheid content;
• templates en contentmodellen;
• maatwerkcode;
• koppelingen en integraties;
• formulieren en zoekfunctionaliteit;
• gebruikers en rechten;
• redirects en SEO-metadata;
• analytics;
• testcapaciteit;
• besluitvorming en budget.

Start daarom zodra de supportdatum bekend is met een inventarisatie van de huidige omgeving. Bepaal daarna het risico, de gewenste migratieroute en de benodigde planning.

Een tijdelijke oplossing kan bestaan uit extended support of aanvullende beveiligingsmaatregelen. Leg wel vast hoe lang die oplossing houdbaar is en wat daarna de volgende stap wordt.

Kan AI helpen bij een CMS-migratie?

AI kan onderdelen van een migratie versnellen. Bijvoorbeeld door templates, contentstructuren, koppelingen en maatwerkcode te analyseren. Ook kan AI helpen bij het opsporen van dubbele content en het voorbereiden van migratiescripts.

AI vervangt daarbij geen technische beoordeling. Securitygevoelige code, integraties en uitzonderingen moeten altijd door ervaren specialisten worden gecontroleerd.

De combinatie van AI en specialistische kennis kan organisaties helpen om sneller inzicht te krijgen in hun huidige omgeving en repetitief migratiewerk te versnellen. Daardoor kan een overstap naar een ondersteunde versie sneller en betaalbaarder worden dan een paar jaar geleden. Zo herstel je de basis voor veiligheid en support, zonder dat je organisatie maandenlang zelf met de migratie bezig hoeft te zijn.

Klaar voor de volgende stap?

We brengen samen je huidige CMS, technische afhankelijkheden en supportdeadlines in kaart. Daarna bepalen we welke maatregelen nu nodig zijn en welke migratieroute het beste past bij je organisatie. Ontdek nu hoe we helpen bij een veilige CMS-migratie.

Plan een CMS-scan