Levenscyclusbeheer van ISO 15118-certificaten in 2026: van TLS-urgentie tot CRA-naleving

TL;DR (Samenvatting van de actie van de uitvoerende macht)

• De overstap naar TLS is een harde grens (geen suggestie): Van 24 februari 2026DigiCert zal stop met accepteren openbare TLS-certificaatverzoeken met geldigheid meer dan 199 dagenen certificaten die vanaf die datum zijn uitgegeven, hebben een Maximale geldigheidsduur: 199 dagenDit is voor veel aanbieders de praktische omschakeling: de verlengingssnelheid neemt direct toe.
• Het stappenplan van 200→100→47 dagen is al vastgelegd: De basisvereisten van het CA/Browser Forum schrijven een gefaseerde reductie voor: 200 dagen vanaf 15 maart 2026, 100 dagen vanaf 15 maart 2027, En 47 dagen vanaf 15 maart 2029.
• CRA voegt een termijn voor naleving toe: De CRA-rapportageregels vereisen Vroegtijdige waarschuwing binnen 24 uur, Volledige melding binnen 72 uur.en definieerde definitieve rapportageperiodes voor actief misbruikte kwetsbaarheden en ernstige incidenten.
• Het grootste verborgen risico is niet de vervaldatum: De systeemfoutmodus is vertrouwen anker drijf— Roots/intermediates/cross-signing wijzigingen zijn niet gesynchroniseerd tussen EVSE, lokale controllers en backend-validatiepaden.
• Eerste investering om de uptime te beschermen: Systeemgestuurde automatisering (ACME + voorraadbeheer + gefaseerde uitrol) plus randcontinuïteit (lokale validatie/caching, bewijslogboeken en beheer van tijdsynchronisatie).

Inleiding: In 2026 wordt Plug & Charge een operationeel systeem.

In 2026 is Plug & Charge (P&C) geen functie meer die je instelt en vervolgens vergeet, maar een continu besturingssysteem.
Het ISO 15118-vertrouwensvlak (PKI + TLS + intrekking + updates) wordt nu beheerst door tijdlijnen die geen handmatige workflows tolereren.

Om de systeemgrenzen te begrijpen – waar ISO 15118 verantwoordelijk voor is en waar OCPP verantwoordelijk voor is – begin dan met ons bijbehorende artikel:
ISO 15118 versus OCPP: de realiteit van de implementatie in 2026.

De directe druk is TLS-levenscycluscompressieOperationeel gezien kun je niet "wachten tot maart".
DigiCert zal stop met accepteren openbare TLS-verzoeken die het overschrijden 199 dagen beginnend 24 februari 2026,
en certificaten die vanaf die dag worden uitgegeven, zullen een Maximale geldigheidsduur: 199 dagen.
DigiCert benadrukt ook een cruciaal operationeel detail: de maximaal toegestane geldigheidsduur wordt bepaald door de uitgiftedatum, niet wanneer de bestelling wordt geplaatst.

Tegelijkertijd introduceert de EU-verordening inzake cyberweerbaarheid (CRA) een tweede termijn: rapportageregels vereisen...
24-uurs waarschuwing En 72-uurs melding voor actief misbruikte kwetsbaarheden en ernstige incidenten die producten met digitale elementen treffen.

Deze handleiding richt zich op de architectuur en risicobeheersing voor het gebruik van ISO 15118-certificaten onder deze beperkingen.

Mijlpalen en vereiste acties voor 2024-2026 (Gantt-diagram met tekst)

Operationele opmerking: 24 februari 2026 is vaak het echte omslagpunt, omdat het uitgiftegedrag van grote certificeringsinstanties dan verandert.

Beleidsnota: De gefaseerde levensduurverminderingen zijn vastgelegd in de basisvereisten (200/100/47 dagen).

Het levenscyclusmodel: Inrichting → Gebruik → Vernieuwing → Intrekking

Levenscycluskaart (wat je moet kunnen bedienen)

1. OEM-levering: Sleutels gegenereerd/geïnjecteerd; vertrouwensbasis vastgesteld (HSM/beveiligd element).
2. Contractinschrijving: Contractcertificaten gekoppeld aan gebruikerscontracten (afhankelijk van het ecosysteem).
3. Inbedrijfstelling van EVSE: Baselines voor de vertrouwensopslag, beleidsregels en tijdsynchronisatiebaselines zijn vastgesteld.
4. Operationele validatie: TLS-handshakes, ketenopbouw, controle op intrekking, handhaving van beleid.
5. Verlenging / heruitgifte: Automatisering + gefaseerde uitrol + terugdraaien.
6. Intrekking / incidentafhandeling: Compromittering/onjuiste uitgifte/misbruik → intrekken/roteren/terugvorderen.
7. Herstel en verzoening: Herstel de dienstverlening met behoud van traceerbaarheid en de integriteit van de facturering.

Het onderschatte zwakke punt: het afdrijven van het vertrouwen in het anker.

De meeste "mysterieuze P&C-storingen" in omgevingen met meerdere OEM's worden niet veroorzaakt door een enkel verlopen certificaat, maar door een complexer probleem.
padvalidatiefouten veroorzaakt door verschuiving van het vertrouwensanker:

• Er verschijnen nieuwe wortels/tussenliggende wortels (een realiteit met meerdere wortels).
• Kruisondertekening Veranderingen beïnvloeden de haalbare ketens.
• De backend-vertrouwensarchieven worden sneller bijgewerkt dan de EVSE/lokale controllers.
• Intrekkingsartefacten raken verouderd aan de rand.

Beschouw updates van vertrouwensankers als een veiligheidskritisch wijzigingsproces:

• Versiebeheerde vertrouwensarchieven
• Canary-uitrol
• Terugdraaiplannen
• Telemetrie over validatiefouten per uitgever/serienummer/pad
• Een expliciete eigenaar voor "wie wat wanneer bijwerkt".

Mislukte kruisbewegwijzering en routeplanning (de realiteit van 2026): In ecosystemen met meerdere root-roots volgens ISO 15118,
Plug & Charge mislukt vaak niet omdat een certificaat ongeldig is, maar omdat het laadstation geen geldig certificaat kan genereren.
certificaatpad na wijzigingen in de kruisondertekening (nieuwe tussenpersonen, brug-CA's, opnieuw uitgegeven ketens).
Naarmate meer OEM's en PKI-domeinen zich aansluiten, neemt de complexiteit van de paden toe. Als edge trust stores (EVSE/lokale controllers)
Als de backend-certificaten achterlopen op updates, kunnen TLS-handshakes mislukken, zelfs als de backend-certificaten op zichzelf "geldig" lijken.

Afbeelding 1 (aanbevolen visualisatie): Padvalidatie in multi-root ISO 15118

(Toon V2G Root / OEM Root / Contract Root, tussenliggende verbindingen en kruisverbindingsbruggen.)
Markeer waar een nieuw, kruisgesigneerd tussenliggend document de padopbouw op de EVSE verstoort als de vertrouwensarchieven niet synchroon worden bijgewerkt.

Kernboodschap: De meeste stroom- en beveiligingsstoringen die aan "PKI" worden toegeschreven, zijn in werkelijkheid padvalidatiefouten Dit wordt veroorzaakt door afwijkingen in de ondertekening tussen verschillende systemen en niet-gesynchroniseerde vertrouwensarchieven.

ACME & Automation: Mensgestuurd versus systeemgestuurd bij een levensduur van minder dan 199/200 dagen

Waarom handmatige vernieuwing een gegarandeerde oorzaak van stroomuitval wordt.

Korte looptijden betekenen dat verlengingen continu nodig zijn. DigiCert's overstap naar 199 dagen vanaf 24 februari 2026
Dit maakt het voor veel wagenparken direct operationeel. En de bredere tijdlijn voor de sector is al vastgesteld:
200 dagen (vanaf 15 maart 2026), dan 100 dagen, Dan 47 dagen.

Voor elke vloot gelden de volgende vernieuwingscycli:

Vernieuwingsevenementen per jaar ≈ N × (365 / L)

Waar N is het aantal TLS-eindpunten en L is de geldigheidsduur van het certificaat (dagen).
Als L Als de uptime afneemt, wordt door mensen aangestuurde vernieuwing wiskundig onverenigbaar met de uptime-doelstellingen.

Scenario (Omvangbepaling op bestuursniveau)

Voor een CPO-bedrijf 5.000 eindpuntenEen levensduur van 199 dagen houdt het volgende in:

Vernieuwingsevenementen/jaar ≈ 5000 × (365 / 199) ≈ 9171

Op deze schaal, zelfs een 1% menselijke foutenratio vertaalt zich naar ongeveer
92 door certificaten veroorzaakte storingen per jaar—voordat rekening wordt gehouden met de impact van de spitsuren,
SLA-boetes of een kettingreactie van storingen binnen een hub.

ACME in laadnetwerken: wat moet het automatiseren?

ACME (Automated Certificate Management Environment) maakt van verlengingen beleidsgestuurde processen voor:

• EVSE ↔ backend TLS
• Lokale controller / Edge Proxy TLS
• Site gateways en hub controllers

Systeemgestuurde workflow (architectuurpatroon)

1. Inventaris elk eindpunt (uitgever, serienummer, keten, vervaldatum, laatste rotatie).
2. Verleng vóór beleid (verlengen bij een vaste drempel, niet "vlak voor de vervaldatum").
3. Hardware-ondersteunde sleutels Vermijd waar mogelijk het exporteren van privésleutels.
4. Gefaseerde uitrol inclusief gezondheidscontroles (handdruk + autorisatie + start van de sessie).
5. Automatische terugdraaiing bij verhoogde uitvalpercentages.
6. Bewijslogboeken voor elke uitgifte/implementatie (traceerbaarheid van compliance-niveau).

Mensgestuurd versus systeemgestuurd

• Door mensen aangestuurd: tickets, spreadsheets, late verlengingen, onduidelijke eigendomsstructuur, risicovolle noodwijzigingen.
• Systeemgestuurd: Deterministisch beleid, geautomatiseerde uitgifte, gecontroleerde uitrol, continue telemetrie, controleerbaar bewijsmateriaal.

Intrekkingscontroles: de "P&C-killer" (CRL versus OCSP, zwakke netwerken en verdedigbaar beleid)

Waarom OCSP/CRL-systemen falen in garages en depots.

• Zwakke/intermitterende LTE/5G-verbinding
• Beperkte uitgang (firewalls/captive portals)
• Validatiestappen die gevoelig zijn voor latentie
• Externe afhankelijkheden (OCSP-responders, CRL-distributiepunten)

Resultaat: EVSE kan een sessie starten, maar kan deze niet voltooien. validatie van intrekking betrouwbaar.

CRL versus OCSP: praktische afwegingen

• CRL: Grotere downloads, maar cachebaar en op schema te vernieuwen (goed voor continuïteit aan de rand van het netwerk).
• OCSP: Lichtgewicht op aanvraag, maar vereist vaak directe bereikbaarheid op het zwakste punt.

In 2026 is de juiste houding opgebouwd uit verschillende lagen:

• Geplande CRL-caching voor extra betrouwbaarheid
• OCSP waar de connectiviteit betrouwbaar is
• Expliciet beleid voor verslechterde omstandigheden

Waarom het steeds moeilijker wordt om een 'zachte mislukking' te verdedigen

Historisch gezien zorgde een "soft-fail"-mechanisme (het toestaan van een sessie als de intrekkingscontroles een time-out bereiken) ervoor dat de beschikbaarheid gewaarborgd bleef.
In 2026 wordt een soft-fail moeilijker te rechtvaardigen omdat:

• De levensduur is korter (minder tolerantie voor achterhaalde aannames).
• De meldingstermijn van CRA dwingt tot strengere discipline bij incidenten en tot betere bewijsvoering.

Een verdedigbaar ontwerp vereist een expliciet, gedocumenteerd beleid:

• Een harde mislukking voor openbare/risicovolle omgevingen
• Genade met bewijs voor gesloten vloten (beperkt venster + compenserende maatregelen)
• Het vastleggen van bewijsmateriaal voor elke verslechterde beslissing

Architectonische oplossingen (patronen, geen productbeloftes)

Patroon 1: Edge-voorvalidatie + caching

• CRL's in de cache opslaan met gedefinieerde geldigheidsperioden.
• Tussenproducten en gevalideerde ketens in de cache opslaan
• Vooraf ophalen tijdens perioden met goede connectiviteit

Patroon 2: OCSP-nieten (indien mogelijk)

OCSP-stapling verplaatst de levering van intrekkingsbewijzen weg van de zwakste schakel, waardoor de afhankelijkheid van de CA-infrastructuur tijdens de sessieopbouw wordt verminderd.

Implementatie-aantekening (ingebedde realiteit): Controleer in EVSE-omgevingen of de ondersteuning voor uitbreidingen met betrekking tot nieten aanwezig is.
in uw ingebouwde TLS-stack en buildconfiguratie (bijv. mbedTLS, wolfSSL) en valideer het gedrag op oudere hardware.
omdat de volledigheid van de functionaliteit en de beperkingen van het geheugen/RTOS variëren.

Patroon 3: Multi-root trust governance

• Uniform updatekanaal voor de vertrouwensopslag voor meerdere OEM-ankers
• Canary-updates + terugdraaien wanneer er pieken optreden in padopbouwfouten

Patroon 4: Tijdsynchronisatiebeheer (niet onderhandelbaar)

• NTP-beleid (of PTP waar van toepassing)
• Driftbewaking en waarschuwingsdrempels
• Gedefinieerd gedrag wanneer klokken niet betrouwbaar zijn.

Offline continuïteit: Plug & Charge blijft bruikbaar tijdens onderbrekingen in de verbinding tussen de edge en de cloud.

Wat offline continuïteit wel (en niet) is.

Offline continuïteit is niet "PKI omzeilen". Het is gecontroleerde degradatie die het volgende behoudt:

• Integriteit van sleutels en vertrouwensarchieven
• Controleerbaarheid voor facturering en incidentafhandeling
• Expliciete beperkingen op wat lokaal gevalideerd kan worden (en hoe lang).

Lokale controllers / edge-proxies als beschikbaarheidsprimitieven

• Lokale vertrouwenscaches (ankers/tussenliggende waarden/CRL's) onderhouden
• Handhaaf beperkte lokale autorisatiebeleidsregels.
• Buffermetingen/logboeken voor latere afstemming
• Verklein de impact van WAN-aanvallen door als lokaal eindpunt voor EVSE te fungeren.

Afbeelding 2 (aanbevolen visualisatie): Edge Proxy als vertrouwenscache op locaties met een zwak netwerk

(Toon EVSE's die verbinding maken met een lokale Edge Proxy/Local Controller. De proxy beheert in de cache opgeslagen vertrouwensankers/tussenliggende certificaten.)
(Geplande CRL-verversing, tijdsynchronisatiebewaking en bewijslogboeken; het buffert gebeurtenissen naar de cloud CSMS/PKI wanneer de uplink instabiel is.)

Kernboodschap: Edge-proxies verminderen de afhankelijkheid van externe OCSP/CRL-eindpunten en maken gecontroleerde offline continuïteit mogelijk zonder de PKI te omzeilen.

CRA & VMP: van rapportagedeadlines in september 2026 naar een controleerbaar operationeel model

CRA-rapportageregels: ontwerp volgens de 24-uurs/72-uursklok

De CRA-rapportageregels vereisen dat fabrikanten melding maken van actief misbruikte kwetsbaarheden en ernstige incidenten met gevolgen voor de veiligheid.
over de beveiliging van producten met digitale elementen:

• Vroegtijdige waarschuwing binnen 24 uur bewustwording
• Volledige melding binnen 72 uur
• Eindverslag binnen vastgestelde tijdsvensters (afhankelijk van de incidentcategorie)

Een grootschalige verstoring van Plug & Charge veroorzaakt door massale intrekking of een inbreuk op de vertrouwensankers. komen mogelijk in aanmerking
als een ernstig incident, afhankelijk van de impact en de bewijzen van misbruik.

Vulnerability Management Process (VMP): minimale levensvatbare mogelijkheden

1. De waarheid over de vloot: Asset- en versie-inventaris (EVSE-firmware, controllerimages, trust store-versies).
2. SBOM-integratie (dynamisch): SBOM gekoppeld aan implementeerbare artefacten; continue correlatie met kwetsbaarheidsinformatie.
3. VEX-gestuurd blootstellingsbeheer: Behoud VEX-verklaringen om onderscheid te maken tussen "aanwezig maar niet exploiteerbaar" en "exploiteerbaar in onze implementatie", zodat een geloofwaardige afbakening binnen het T+24-uursvenster mogelijk is.
4. Waarom VEX belangrijk is binnen de 24-uursklok: SBOM vertelt je wat er aanwezig is; VEX helpt je bepalen wat er is exploiteerbaarwaardoor valse alarmen worden verminderd en operationele teams geen tijd meer verspillen aan het onderzoeken van ruis die niet bruikbaar is.
5. Intake en triage: Adviezen van leveranciers, CVE's, interne bevindingen; prioriteer exploitatiemogelijkheden + blootstelling.
6. T+24 uur workflow voor het verkennen van de omgeving: SBOM + VEX + inventariscorrelatie om getroffen populaties te identificeren; initiële beslissingen over inperking; bewijsmateriaal vastleggen.
7. T+72h notificatieworkflow: Bevestigde reikwijdte, risicobeperkingen, uitrol-/terugdraaiplan, communicatieverslag.
8. Werkproces voor het eindrapport: Validatiebewijs + grondoorzaak + preventieve verbeteringen na beschikbaarheid van corrigerende maatregelen.
9. Patch cadans engineering: gefaseerde uitrol, terugdraaiplannen, ondertekende documenten, verificatiepoorten.
10. Handhaving van de vertrouwensketen: Beveiligd opstarten + beveiligde firmware-updates; ondertekeningssleutels beschermd in HSM/beveiligde elementen.
11. Logboekregistratie op basis van bewijsmateriaal: Certificaatgebeurtenissen, wijzigingen in de vertrouwensopslag, intrekkingsfouten, status van de tijdsynchronisatie.

Een zeer ernstig vertrouwensprobleem: Als de intrekking wordt geactiveerd door een gecompromitteerde root- of uitgiftesleutel,
Beschouw dit als een ernstig vertrouwensincident dat onmiddellijke beheersing vereist, inclusief acties voor de gehele vloot met betrekking tot de vertrouwde systemen.
en de gereedheid voor rapportage conform de CRA-richtlijnen, afhankelijk van de impact en het bewijsmateriaal met betrekking tot exploitatie.

Checklist voor incidentrespons bij CRA (operationeel sjabloon)

T+0 (Detectie / Bewustwording)

• Bewijsmateriaal voor het bevriezen van gegevens: logboeken, certificaatgebeurtenissen, versies van de vertrouwensopslag, status van de tijdsynchronisatie
• Identificeer de getroffen onderdelen: EVSE-firmware, lokale controllers, backend TLS-eindpunten.
• Neem contact op met de PKI-provider / backend-beveiligingscontactpersoon.

T+24 uur (Vroegtijdige waarschuwing)

• Kerndoelstelling: Gebruik SBOM + VEX + vlootinventaris om de getroffen bevolking te bepalen en een op bewijs gebaseerd vroegtijdig waarschuwingssysteem in te dienen.
• Bepaal de inperkingsmethode: intrekken/roteren, terugdraaien van de truststore, isolatie van de site
• Ontwerp van een vroegtijdig waarschuwingspakket: reikwijdte, lopende maatregelen, tussentijdse richtlijnen

T+72 uur (Volledige gereedheid voor melding)

• Bevestig de getroffen bevolkingsgroepen per regio/locatie; lever een saneringsplan en een implementatiemethode aan.
• Stel een communicatie- en escalatieverslag op voor klant/operator.

Eindrapportvenster

• Dien een definitief rapport in conform de CRA-vereisten (de timing is afhankelijk van de incidentcategorie).
• Validatiebewijs na de fix + geleerde lessen

Kosten- en risicoberekening (sjablonen die u in uw wagenpark kunt integreren)

Handmatig model voor arbeidskosten bij vernieuwing

Laten:

• N = aantal TLS-eindpunten (EVSE + controllers + gateways + beheerde backend-nodes)
• L = geldigheidsduur certificaat (dagen)
• T = menselijke tijd per vernieuwing (uren)
• C = totale arbeidskosten (USD/uur)

Arbeidskosten ≈ N × (365 / L) × t × c

Model voor uitvalrisico (verlopen of mislukte implementatie)

Laten:

• P_miss = waarschijnlijkheid van gemiste/mislukte verlenging per cyclus
• H_down = verwachte uitvaltijd in uren per incident
• C_uur = uurlijkse impact op de bedrijfsvoering (gemiste inkomsten, boetes, SLA-credits)

Kosten_uitval ≈ P_miss × H_down × C_hour

Beslissingshandleiding: Wanneer online intrekkingscontroles mislukken (OCSP/CRL-time-out)

1. Openbaar terrein of gesloten wagenpark/depot?
   • Openbaar → voorkeur Een harde mislukking (of strikt gecontroleerde genade, alleen met bewijs en compenserende maatregelen)
   • Vloot/depot → Genade met bewijs kan acceptabel zijn voor beperkte vensters
2. Is de betrouwbaarheid van een netwerk voorspelbaar?
   • Ja → Online OCSP/CRL + monitoring
   • Nee → Edge-voorvalidatie + caching (CRL-verversingsvensters, gecachede ketens)
3. Kun je de online afhankelijkheid tijdens een sessie verminderen?
   • Waar mogelijk → adopteren OCSP-nietpatroon (duw de proefdruk dichter naar de rand)
4. Beschikt u over bewijsmateriaalregistratie en tijdsynchronisatiebeheer?
   • Zo niet, los deze dan eerst op; beleid voor beperkte modus is moeilijk te verdedigen zonder deze oplossingen.

Praktische verantwoordelijkheidsmatrix (grenzen die storingen voorkomen)

Glossarium

• PKI: Openbare sleutelinfrastructuur (uitgifte, validatie, vertrouwensankers, intrekking)
• ACME: Geautomatiseerde certificaatbeheeromgeving (geautomatiseerde uitgifte/vernieuwing)
• OCSP / CRL: Protocol voor online certificaatstatus / Lijst met ingetrokken certificaten
• OCSP-nieten: De server presenteert een bewijs van intrekking om de afhankelijkheid van live OCSP te verminderen.
• Vertrouwensankers: Root-/tussenliggende certificaten die uw validators vertrouwen
• SBOM: Software-stuklijst (componenteninventaris voor het in kaart brengen van kwetsbaarheden)
• VEX: Vulnerability Exploitability eXchange (statusverklaringen over de exploiteerbaarheid)
• TLS 1.3: Modern TLS-profiel; handshake + certificaatvalidatie blijven gevoelig voor latency
• VMP: Proces voor kwetsbaarheidsbeheer (intake, triage, patchen, rapporteren, bewijsmateriaal)

Toekomstgerichte risico's: Crypto-wendbaarheid en PQC-gereedheid

Hoewel 2026 in het teken staat van korte TLS-levensduren en CRA-rapportage, zouden laadinfrastructuurbeheerders alvast moeten beginnen met het evalueren van...
crypto-wendbaarheidBij duurzame assets (voertuigen en laders) moeten architecturen hardware-lock-in voorkomen door ervoor te zorgen dat...
HSM/beveiligde elementen en ingebouwde stacks kunnen toekomstige updates van algoritmen en certificaatprofielen ondersteunen zonder dat een hardwarevernieuwing nodig is.

Veelgestelde vragen

Kan Plug & Charge ook offline werken?

Gedeeltelijk – met opzet. Offline P&C maakt gebruik van gecontroleerde degradatie door middel van lokale vertrouwenscaching (ankers/tussenliggende waarden/CRL's waar mogelijk).
Expliciete respijtbeleidsregels en gebufferde auditlogboeken voor reconciliatie. Het mag PKI niet omzeilen; het moet de afhankelijkheid van de live cloud verminderen.
met behoud van integriteit en controleerbaarheid.

Hoe vaak moeten we certificaten met een geldigheidsduur van minder dan 199/200 dagen verlengen?

Plan meerdere vernieuwingscycli per jaar per eindpunt. Voor veel operators begint de operationele omschakeling.
24 februari 2026 omdat DigiCert openbare TLS-certificaten zal uitgeven met een maximum 199 dagen geldig vanaf die datum.
Op het bredere ecosysteemniveau definiëren de basisvereisten een gefaseerde reductie tot 200/100/47 dagen.

Wat leidt tot rapportageverplichtingen bij de CRA?

De CRA-rapportageregels vereisen 24-uurs waarschuwing En 72-uurs melding voor actief misbruikte kwetsbaarheden en ernstige incidenten,
plus de uiterste rapportagetermijnen. Een grootschalige verstoring van het vertrouwen in de verzekeringssector (bijvoorbeeld een kwaadwillige intrekking of een inbreuk op de validatie) kan in aanmerking komen, afhankelijk van de omstandigheden.
op basis van bewijsmateriaal over impact en exploitatie; een CRA-gerelateerd VMP moet dit ondersteunen. SBOM + VEX + vlootinventaris Een endoscopisch onderzoek binnen de eerste 24 uur.