Vier authenticatiebypasses in één week, allemaal in de beheerlaag

Kort vooraf: vier NCSC-adviezen in acht dagen, geen enkele in een applicatie. En op 15 augustus telt de vraag welke klantomgevingen dat beheerplatform kon bereiken.

Maandagochtend kwam NCSC-2026-0275 binnen. Authenticatiebypass in N-able N-central, alle versies tot en met 2026.3.1: een aanvaller omzeilt de authenticatiecontrole via een alternatieve route binnen de applicatie. N-central is een RMM. Het platform waarmee beheerpartijen honderden klantomgevingen tegelijk beheren.

Het was het vierde advies van deze soort in acht dagen.

Op 31 juli: NCSC-2026-0274, een bypass in de SAML 2.0-authenticatie van SolarWinds Web Help Desk, CVE-2026-28323, CVSS 9.8. Op 30 juli: NCSC-2026-0271, een hard-coded wachtwoord in de webinterface van Cisco Secure Firewall Management Center. Die laatste staat inmiddels in de KEV-catalogus van CISA (CVE-2026-20316), wat betekent dat er bewijs van actief misbruik is. En op 29 juli: NCSC-2026-0269, een kritieke authenticatiebypass in de Directory Service van VMware vCenter, CVE-2026-59309, CVSS 9.8, met het advies “update onmiddellijk”.

Vier stuks. Firewall management center, niet de firewall. vCenter, niet de virtuele machine. De RMM, niet het endpoint. De helpdesk die federatie doet, niet de gefedereerde applicatie.

De laag die op geen enkel plaatje staat

Beheersoftware heeft per definitie de rechten van alles wat zij beheert. Dat is geen ontwerpfout, dat is de functie. De agent op uw servers draait met systeemrechten omdat hij anders niets kan patchen. Het serviceaccount van uw monitoringplatform heeft brede leesrechten omdat het anders niets ziet. De koppeling naar de klant-tenant heeft beheerrechten omdat u anders geen beheer levert.

Wat mij opvalt in architectuurdossiers is dat die laag er vrijwel nooit in staat. Netwerktopologie: aanwezig. Identity: aanwezig. Workloads, back-up, herstelmodel: aanwezig. Het platform dat bij dat alles naar binnen kan, met de hoogste rechten in de hele keten, staat er als “tooling” bij, of helemaal niet. Het is infrastructuur die als gereedschap wordt behandeld.

Ik keek onlangs naar een architectuur met drie zones: DMZ, productie en een high-secure zone. Netjes getekend, netjes gescheiden. Eén beheerplatform, verbonden met alle drie. Daar is geen fout gemaakt: die verbinding is precies waarvoor het platform is aangeschaft. Maar de zonering die op papier houdt, houdt niet dwars door de laag die er als enige doorheen loopt.

En ergens in dat pad zit het account dat tijdelijk was. Aangemaakt om één ding werkend te krijgen, op één specifieke middag, met een omvang die niemand twee dagen kon uitzoeken. Het staat er nog. Het staat er altijd nog.

Voor beheerpartijen is de straal een klantenlijst

Bij een eindklant is de vraag na zo’n advies begrensd: staat dit ding bij ons, en hoe snel is het gepatcht. Bij een beheerpartij is de vraag dat niet, en dat verschil is de kern van dit stuk.

Kijk naar wat er vanuit uw beheeromgeving naar buiten loopt. Delegated admin-relaties (GDAP) naar Microsoft Entra-tenants van klanten, elk met een rolomvang die ooit is ingericht en zelden is teruggebracht. Serviceprincipals in klantabonnementen, sommige met een standing rol in plaats van een activeerbare. Automatiseringsaccounts die uit het Conditional Access-beleid zijn uitgezonderd, omdat de automatisering brak toen ze er wel onder vielen. Ik heb die uitzondering vaker gezien dan ik wil toegeven, en ze is bijna altijd tijdelijk bedoeld.

Als het platform dat die paden bezit een authenticatiebypass heeft, dan is de blootstelling niet één omgeving. Ze is de lijst.

”Maar wij zijn toch geen essentiële entiteit?”

Dat hoor ik regelmatig, en de aanname erachter klopt niet.

Aanbieders van beheerde diensten en beheerde beveiligingsdiensten vormen onder NIS2 een eigen sector, ICT-dienstenbeheer (b2b), en zijn in de Nederlandse Cyberbeveiligingswet die op 15 augustus 2026 in werking treedt dus zelf een entiteit met een zorgplicht. Niet als leverancier van iemand anders, maar op eigen titel, inclusief registratieplicht bij het NCSC en meldplicht bij het CSIRT.

En stel dat u er buiten valt. Dan valt u nog steeds binnen de toeleveringsketen van iedere klant die er wél onder valt, en die klant heeft onder Artikel 21, lid 2, onder d een verplichting rond ketenbeveiliging waar u het onderwerp van bent. In beide gevallen komt dezelfde vraag uw kant op. Alleen de afzender verschilt.

De vraag die na 15 augustus terugkomt

Niemand gaat u vragen of u NCSC-2026-0275 hebt gepatcht. Dat is een gesloten vraag met een datum, en die beantwoordt u binnen een dag.

De vraag die terugkomt is breder, en hij komt van een bestuur dat sinds 15 augustus moet kunnen aantonen dát het toeziet:

• Welke klantomgevingen kon dit platform bereiken?
• Met welke rechten, en waren die activeerbaar of permanent?
• Sinds wanneer, en wie heeft dat toegekend?

(Wie dat uit het hoofd weet, mag deze alinea overslaan. Ik ken die persoon nog niet.)

Dat is een architectuurvraag, geen patchvraag. Een kwetsbaarhedenrapport vertelt u wat er kapot was. Een lijst toegangspaden vertelt u wat er bereikbaar was, en dat is het bewijs waar een toezichthouder en een aansprakelijk bestuur allebei op uitkomen. Zie ook waarom vijf adviezen in één week vooral een blootstellingsvraag zijn.

Wat ik deze week zou controleren

Vijf dingen, in deze volgorde. Niet omdat ze allemaal dringend zijn, maar omdat ze samen die drie vragen beantwoorden.

1. Inventariseer uw beheerlaag als architectuurcomponent. RMM, monitoring, back-up, helpdesk, hypervisorbeheer. Zet ze op het plaatje waar ze niet op staan.
2. Trek de GDAP-relaties na, per klant. Welke rollen, en zijn ze nog nodig in die omvang. Verlopen relaties die nooit zijn opgeruimd tellen mee.
3. Zoek de uitzonderingen in Conditional Access. Elk account dat erbuiten valt is een pad dat uw MFA-bewijs niet dekt. Documenteer waarom, of haal het eruit.
4. Kijk welke serviceprincipals een permanente rol houden in klantabonnementen in plaats van een via PIM activeerbare.
5. Leg vast wat u vindt, met datum. Niet voor de toezichthouder. Voor de volgende keer dat er om 08:00 een advies binnenkomt en iemand vraagt of het u raakt.

Punt vijf is de reden dat ik PAA ben gaan bouwen: ik was het handmatig reconstrueren van toegangspaden per tenant zat, telkens opnieuw, telkens onder tijdsdruk.

De adviezen van vorige week zijn over twee weken oud nieuws. De vraag eronder blijft staan, en die gaat over wat uw beheerlaag kan bereiken op een dag dat er niets aan de hand is.

Kort samengevat

• Tussen 27 juli en 3 augustus 2026 publiceerde het NCSC vier adviezen over authenticatiebypass, alle vier in beheersoftware: N-able N-central (NCSC-2026-0275), SolarWinds Web Help Desk (0274, CVSS 9.8), Cisco Secure FMC (0271, actief misbruikt volgens CISA KEV) en VMware vCenter (0269, CVSS 9.8).
• Beheersoftware heeft de rechten van alles wat zij beheert en staat zelden in het architectuurdossier.
• Voor een beheerpartij is de blootstelling bij zo’n bypass de klantenlijst, via GDAP-relaties, serviceprincipals en accounts die buiten Conditional Access vallen.
• Aanbieders van beheerde diensten vallen onder de Cyberbeveiligingswet als eigen sector (ICT-dienstenbeheer b2b), en anders via de ketenverplichting van hun klanten.
• Vanaf 15 augustus 2026 is de bewijsvraag welke omgevingen bereikbaar waren, met welke rechten en sinds wanneer.