U kunt niet migreren wat u niet kunt inventariseren: de cryptografische bill of materials die banken nog steeds missen
Elke post-quantumroadmap in het bankwezen gaat uit van een inventaris die niet bestaat. De plannen zijn geschreven, de stuurgroepen vergaderen, de scorecards staan op oranje. Onder dat alles ligt de aanname dat iemand, ergens, een lijst kan opleveren van elke plek waar de bank een cryptografische bewerking uitvoert: welk algoritme, welke sleutellengte, welke bibliotheek, welk certificaat, wanneer verlopend. Vrijwel geen enkele instelling kan dat. De eerste mijlpaal van de NCSC is geen migratiemijlpaal, maar een inventarisatiemijlpaal, met 2028 als datum, en het is de mijlpaal die niemand heeft begroot.
Managementsamenvatting
- De volgorde is inventarisatie, dan agility, dan migratie. De richtlijn van de NCSC legt een gedefinieerde inventarisatiemijlpaal vast in 2028, de migratie met de hoogste prioriteit in 2031 en de voltooiing in 2035. Een instelling die begint te migreren voordat zij heeft geïnventariseerd, migreert de systemen die zij toevallig kent.
- Het register dat u heeft, beantwoordt de vraag niet die u nu krijgt. DORA artikel 8 verplicht financiële entiteiten ICT-assets te identificeren, te classificeren en te documenteren en hun onderlinge afhankelijkheden in kaart te brengen. Het vereist geen enkele cryptografische eigenschap, waardoor een register dat aan artikel 8 voldoet compleet kan zijn en toch nutteloos voor de planning van crypto-agility.
- De standaard bestaat al. Cryptografische assets — algoritmen met sleutellengte, modus en curve; sleutels; certificaten; protocollen — zijn representeerbaar in CycloneDX, dat is gepubliceerd als ECMA-424. Dit is een schemavraagstuk, geen inkoopvraagstuk.
- Het lastigste kwart kunt u niet zelf scannen. Hardware security modules, betaalappliances, door leveranciers ingebedde bibliotheken en SaaS-aanbieders laten zich niet inventariseren door er een scanner op te richten. Dat deel van de inventaris bouwt u op uit contractuele attestatie, en de clausule moet er zijn voordat de roadmap er kan zijn.
De deadline die niemand heeft begroot
Lees de gepubliceerde migratietijdlijnen zorgvuldig en de volgorde is ondubbelzinnig. De roadmap van het National Cyber Security Centre zet inventarisatie — een volledig beeld van welke systemen en diensten van cryptografie afhankelijk zijn — op 2028, het migratiewerk met de hoogste prioriteit op 2031, en de voltooiing over alle systemen, diensten en producten op 2035. Het transitierapport van NIST, IR 8547, loopt op een verenigbaar spoor: kwantumkwetsbare publiekesleutelalgoritmen waaronder RSA en ECC worden na 2030 buiten gebruik gesteld en na 2035 verboden.
De meeste bankprogramma's hebben 2035 als de datum verinnerlijkt. Dat is het verkeerde uiteinde van het schema om vanaf te plannen.
Twee data doen er veel meer toe. De eerste is 2028, want inventarisatie is de invoer voor alles wat daarna komt: u kunt een migratie niet afbakenen, begroten of faseren tegen een onbekende noemer. De tweede is 2030, want "buiten gebruik gesteld" is geen zacht woord in een gereguleerde instelling: het is het punt waarop verder vertrouwen op een algoritme een beslissing wordt die iemand moet tekenen.
Tussen nu en 2028 liggen minder dan dertig maanden. Dat is één, misschien twee budgetcycli om een capaciteit op te bouwen waar de meeste instellingen nog niet aan begonnen zijn.
Uw DORA-register legt alles vast behalve de cryptografie
Hier zit het deel dat mensen verrast. De meeste grote Europese banken houden al een gedetailleerde, regelmatig herziene inventaris van ICT-assets bij, omdat DORA hun dat oplegt.
Artikel 8 van Verordening (EU) 2022/2554 verplicht financiële entiteiten alle door ICT ondersteunde bedrijfsfuncties, de informatie en ICT-assets die deze ondersteunen en hun rollen en afhankelijkheden in relatie tot ICT-risico te identificeren, te classificeren en adequaat te documenteren — en de configuratie van die assets en de verbindingen daartussen in kaart te brengen en onder review te houden.
Dat is een serieuze inventaris. Het is ook de verkeerde vorm voor dit probleem.
Tabel 1: het register dat u heeft en het register dat de mijlpaal van 2028 vraagt
| Vraag | ICT-assetregister (DORA artikel 8) | Cryptografische inventarisatie (CBOM) |
|---|---|---|
| Wat is dit asset en wie is de eigenaar? | Ja — dit is de kern van het register | Niet het doel ervan |
| Hoe kritiek is het en waarvan hangt het af? | Ja — classificatie en afhankelijkheidsanalyse | Overgenomen uit het assetregister |
| Welke algoritmen gebruikt het, en waar? | Nee | Ja — per component, met sleutellengte, modus en curve |
| Welke bibliotheek implementeert ze, in welke versie? | Deels, via de SBOM als die bestaat | Ja, als expliciete relatie |
| Welke certificaten presenteert het, en wanneer verlopen die? | Zelden, en meestal in een aparte PKI-tool | Ja |
| Waar staan de sleutels en hoe zijn ze beschermd? | Nee | Ja — inclusief of er een HSM in het pad zit |
| Is dit asset kwantumkwetsbaar? | Niet af te leiden | Direct te beantwoorden |
De laatste rij is het hele argument. Een instelling kan volledig voldoen aan artikel 8, haar onderzoek doorstaan en toch niet kunnen beantwoorden hoeveel van haar systemen in 2030 breken, zonder daarvoor van nul af een inventarisatieproject op te tuigen.
Dit is geen kritiek op DORA. Artikel 8 is geschreven om vragen over veerkracht en concentratie te beantwoorden, en dat doet het goed. Het is eenvoudigweg niet geschreven om een vraag over crypto-agility te beantwoorden, en de twee registers moeten aan elkaar worden gekoppeld in plaats van gedraaid als aparte spreadsheets van aparte teams.
Wat een CBOM werkelijk bevat
Een Cryptography Bill of Materials is een formele inventaris van de cryptografische assets in een systeem: de algoritmen, sleutels, certificaten en protocollen, en hun relaties tot de softwarecomponenten die ze gebruiken.
Het belangrijke structurele punt is dat het geen nieuw bestandsformaat is. Ondersteuning voor cryptografische assets is bijgedragen aan CycloneDX, de door OWASP gesteunde bill-of-materials-specificatie, die is gepubliceerd als Ecma International-standaard ECMA-424. Een CBOM is dus een CycloneDX-document met de cryptografievelden ingevuld. Het valideert met hetzelfde schema, beweegt door dezelfde pipelines en landt in dezelfde artefactregistry als de SBOM's die een instelling al produceert voor de toeleveringsketen.
Dat telt zwaarder dan het klinkt. Het verschil tussen een standaard die het haalt en een standaard die vastloopt, zit meestal in de vraag of er nieuw leidingwerk voor nodig is. Hier niet.
Tabel 2: CBOM-assetklassen en de migratievraag die elk beantwoordt
| Assetklasse | Wat wordt vastgelegd | De vraag die het beantwoordt |
|---|---|---|
| Algoritme | Primitieve, sleutellengte, modus, curve, padding en de functie die het vervult | Welke van onze bewerkingen zijn kwantumkwetsbaar, en bij welke parametersterkte? |
| Sleutel | Type, lengte, formaat, status en waar het materiaal staat | Welke sleutels worden beschermd door een HSM en welke staan in applicatiegeheugen? |
| Certificaat | Subject, uitgever, handtekeningalgoritme, geldigheidsvenster | Wat verloopt er vóór het migratievenster, en wat is getekend met een buiten gebruik gesteld algoritme? |
| Protocol | Protocol en versie, met de aangeboden cipher suites | Wat wordt er feitelijk op de lijn onderhandeld, in tegenstelling tot wat het configuratiebestand beweert? |
| Gerelateerde component | De bibliotheek, versie en codelocatie die het bovenstaande implementeren | Als deze bibliotheek wordt vervangen, wat verhuist er dan mee? |
De laatste rij maakt van een inventaris een plan. Een lijst van algoritmen vertelt u de omvang van het probleem. Een lijst van algoritmen gekoppeld aan de componenten die ze implementeren vertelt u de vorm van het werk — en dat is waaruit een migratievolgorde daadwerkelijk wordt opgebouwd.
Inventarisatie is vier problemen, niet één
Inventarisatie behandelen als één werkstroom is de meest voorkomende manier waarop deze programma's stranden. Het zijn vier verschillende problemen met vier verschillende tools, vier verschillende eigenaren en zeer uiteenlopende betrouwbaarheidsniveaus.
1. Broncode — wat de code vraagt. Statische analyse over uw eigen repository's vindt cryptografische aanroepen, hard gecodeerde parameters en de aangeroepen bibliotheken. Open tooling bestaat: het CBOMkit-project en de bijbehorende SonarQube-plug-in detecteren cryptografische assets in broncode en produceren CycloneDX. Hoogste betrouwbaarheid, smalste dekking — het ziet alleen code die u zelf hebt geschreven en nog steeds bouwt.
2. Binaries en containers — wat er werkelijk uitgaat. Broncodeanalyse mist alles wat als gecompileerde afhankelijkheid binnenkomt of in een base image is gebakken. Container- en bestandssysteemscans dichten een deel van dat gat. Verwacht dat de twee beelden elkaar tegenspreken; die tegenspraak is zelf een bevinding.
3. Het netwerk — wat er werkelijk wordt onderhandeld. Configuratie is een intentie, geen waarneming. Passieve observatie van live TLS-onderhandeling over de hele omgeving is de enige manier om te ontdekken dat een dienst die TLS 1.3 documenteert nog steeds iets ouders accepteert bij een interne tegenpartij die nooit is geüpgraded. In een betalingsomgeving is dat vaak precies de tegenpartij die ertoe doet.
4. Het leveranciers- en hardwaredomein — wat u helemaal niet kunt scannen. Hardware security modules, betaalterminals, netwerkappliances, mainframesubsystemen en elke SaaS-aanbieder in de keten. Geen enkele scanner komt daarbij. Dit kwart inventariseert u door ernaar te vragen, onder contract, en daar concentreert zich de werkelijke blootstelling van wholesale banking, want de systemen die clearen en settelen komen onevenredig vaak van leveranciers.
Met het vierde begint u nu, want het heeft de langste doorlooptijd en het is geen technische taak. Het is een inkooptaak: een clausule over cryptografische disclosure en crypto-agility in het contract krijgen, en in de verlengingssjabloon, zodat het antwoord in 2028 binnenkomt als verplichting van de leverancier in plaats van als gunst. Elk kwartaal dat die clausule niet in de sjabloon staat, is een kwartaal aan verlengingen die later moeten worden opengebroken.
Er een beheersmaatregel van maken in plaats van een project
De faalmodus waarop ik zou wedden, is niet dat banken de inventaris overslaan. Het is dat ze die eenmalig laten opstellen, in 2028 een verdedigbare momentopname opleveren en hem laten verlopen — omdat hij is gefinancierd als projectresultaat binnen een post-quantumprogramma in plaats van gebouwd als onderhouden beheersmaatregel.
Een cryptografische inventarisatie veroudert sneller dan een assetregister. Certificaten roteren. Bibliotheken worden opgehoogd door afhankelijkheidsautomatisering. Een base image verandert en een hele dienst krijgt stilzwijgend een andere TLS-stack. Een momentopname uit 2028 is in 2029 materieel onjuist, en dat is precies wanneer het prioriteringswerk voor 2031 ervan afhangt.
Drie toezeggingen voorkomen dat.
Genereer hem in de pipeline, niet in een uitvraag. Een CBOM hoort door de build te worden geproduceerd, naast de SBOM, en als geversioneerd artefact bij de release te worden opgeslagen. Een inventaris die is samengesteld door applicatie-eigenaren een vragenlijst te mailen, is bij aankomst al verouderd en laat zich niet diffen.
Diff hem, en alarmeer op de diff. Het waardevolle signaal is niet de inventaris; het is de verandering in de inventaris. Een dienst die een nieuwe cryptografische afhankelijkheid heeft gekregen, een certificaat dat korter is geworden, een algoritme dat opduikt waar het er eerder niet was — dat zijn de gebeurtenissen die een beheersmaatregel waard zijn. Het is dezelfde redenering die het diffen van SBOM's nuttiger maakt dan het archiveren ervan.
Koppel hem aan het register dat u al bijhoudt. De CBOM beantwoordt "welke cryptografie"; het artikel 8-register beantwoordt "hoe kritiek, van wie, en wat ervan afhangt". Geen van beide is op zichzelf een prioritering. Gekoppeld leveren ze de enige rangorde die telt: kwantumkwetsbare bewerkingen gesorteerd op de kriticiteit van de bedrijfsfunctie die erbovenop draait. Die koppeling is het werkelijke resultaat van een inventarisatieprogramma, en het is de moeite waard dat in het plan ook zo te benoemen.
Het operationele draaiboek
- Herformuleer de mijlpaal van 2028 als capaciteit, niet als rapport. Het resultaat is een onderhouden, machineleesbare inventaris die zichzelf opnieuw genereert, niet een document dat eenmalig voor een toezichthouder wordt gemaakt.
- Produceer nu CBOM's uit de build, te beginnen bij nieuwe diensten. Probeer de omgeving niet in één keer te doen. Bedraad het in de pipeline voor alles wat dit jaar wordt gebouwd of materieel wordt gewijzigd, zodat dekking aangroeit in plaats van een campagne te vergen.
- Zet de contractuele clausule dit kwartaal in de verlengingssjabloon. Cryptografische disclosure en een toezegging over crypto-agility. Dit heeft de langste doorlooptijd van alles op de lijst en het hangt van geen enkele toolkeuze af.
- Voer netwerkobservatie eerst uit op de betaal- en settlementpaden. Daar richt het gat tussen configuratie en werkelijkheid de meeste schade aan en daar concentreren zich legacy-tegenpartijen.
- Koppel de CBOM aan het artikel 8-register en prioriteer op de koppeling. Publiceer de gerangschikte lijst. Dat is het artefact dat een technische inventaris omzet in een bestuurskamergesprek over volgorde en geld.
- Diff elke hergeneratie en alarmeer op nieuwe kwantumkwetsbare afhankelijkheden. Een inventaris zonder diff is een archief.
De instellingen die 2031 comfortabel halen, zijn niet degene met het meest gevorderde beeld van ML-KEM. Het zijn degene die op elke willekeurige ochtend, en zonder daarvoor een project op te tuigen, kunnen beantwoorden waar hun cryptografie zich feitelijk bevindt.
Veelgestelde vragen
Is een CBOM iets anders dan een SBOM?
Het is hetzelfde documenttype met andere velden ingevuld. Ondersteuning voor cryptografische assets is opgenomen in CycloneDX, dat is gepubliceerd als ECMA-424, waardoor een CBOM tegen hetzelfde schema valideert en door dezelfde tooling loopt als een SBOM. Instellingen die al SBOM's genereren, staan hier dichter bij dan ze meestal aannemen.
Verplicht DORA tot een cryptografische inventarisatie?
Niet in die bewoordingen. Artikel 8 van Verordening (EU) 2022/2554 verplicht tot identificatie, classificatie en documentatie van ICT-assets en het in kaart brengen van hun configuratie en onderlinge afhankelijkheden. Cryptografische eigenschappen horen niet bij de attributen die u moet vastleggen, en daarom kan een register dat aan artikel 8 voldoet geen vraag over kwantumkwetsbaarheid beantwoorden zonder te worden uitgebreid.
Waarom moet inventarisatie zo ver vóór migratie klaar zijn?
Omdat het de invoer voor prioritering is. De NCSC-richtlijn zet inventarisatie op 2028 en de migratie met de hoogste prioriteit op 2031, juist zodat er een gedefinieerd interval is om de omgeving te rangschikken en het werk te faseren. Beide samenpersen betekent migreren wat het best begrepen is in plaats van wat er het meest toe doet.
Hoe inventariseren we cryptografie binnen leverancierhardware en SaaS?
U scant die niet; u eist disclosure. Hardware security modules, betaalappliances en dienstverleners moeten worden gedekt door een contractuele verplichting tot cryptografische disclosure en crypto-agility. Omdat dit afhangt van verlengingscycli in plaats van technische inspanning, heeft het de langste doorlooptijd van het hele programma en hoort het als eerste te starten.
Moeten we wachten tot de tooling volwassen is voordat we beginnen?
Nee, en het toolingargument is meestal een dekmantel voor het budgetargument. Open implementaties produceren nu al CycloneDX-inventarissen van cryptografie uit broncode en uit container images, en de specificatie is een bekrachtigde standaard. De beperking op een mijlpaal in 2028 is dekking en contractueel bereik, niet beschikbaarheid van tools.
Referenties
- Europees Parlement en de Raad van de Europese Unie, 2022. Verordening (EU) 2022/2554 betreffende digitale operationele weerbaarheid voor de financiële sector (DORA). Brussel: Publicatieblad van de Europese Unie. Beschikbaar op: Europees Parlement en de Raad van de Europese Unie, 2022..
- National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. Londen: NCSC. Beschikbaar op: National Cyber Security Centre, 2025..
- National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Gaithersburg: U.S. Department of Commerce. Beschikbaar op: National Institute of Standards and Technology, 2024..
- National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg: U.S. Department of Commerce. Beschikbaar op: National Institute of Standards and Technology, 2024..
- OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Beschikbaar op: OWASP Foundation, 2026..
- OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Beschikbaar op: OWASP CycloneDX, 2026..
- IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Beschikbaar op: IBM Research, 2026..
Laatst herzien .
Dit artikel herpubliceren
Kopieer opmaak voor Medium
# U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau > Originally published at [https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/](https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/) De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast. Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Kopieer opmaak voor Mastodon
U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast. https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Kopieer geformatteerd voor LinkedIn
U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast. Dit zijn de belangrijkste strategische inzichten: - De deadline die niemand heeft begroot. Lees de gepubliceerde migratietijdlijnen zorgvuldig en de volgorde is ondubbelzinnig. - Uw DORA-register legt alles vast behalve de cryptografie. Hier zit het deel dat mensen verrast. - Wat een CBOM werkelijk bevat. Een Cryptography Bill of Materials is een formele inventaris van de cryptografische assets in een systeem: de algoritmen, sleutels, certificaten en protocollen, en hun relaties tot de softwarecomponenten die ze… - Inventarisatie is vier problemen, niet één. Inventarisatie behandelen als één werkstroom is de meest voorkomende manier waarop deze programma's stranden. Hoe gaat uw organisatie om met de uitdagingen die in dit artikel worden beschreven? → https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ #CryptographicBillOfMaterials #Cbom #Cyclonedx #Ecma424 #CryptografischeInventarisatie Sebastien Rousseau | CC-BY-4.0
Dit artikel citeren
U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau
De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast.
BibTeX
@online{rousseau2026u,
author = {Rousseau, Sebastien},
title = {{U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau}},
year = {2026},
url = {https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/},
urldate = {2026}
}RIS
TY - GEN AU - Rousseau, Sebastien TI - U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau PY - 2026 UR - https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ ER -
Vancouver
Rousseau S. U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau. sebastienrousseau.com. 2026 Jul 28. Available from: https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Chicago
Rousseau, Sebastien. "U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau." sebastienrousseau.com. July 28, 2026. https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/.
APA
Rousseau, S. (2026, July 28). U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Dit artikel herpubliceren
U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau
De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast.
Dit artikel valt onder de licentie Creative Commons Attribution 4.0 International. Herpublicatie vereist attributie aan de canonieke URL.
U kunt niet migreren wat u niet inventariseert: de ontbrekende CBOM — Sebastien Rousseau De NCSC-deadline voor inventarisatie valt in 2028, vóór elke migratiedeadline. Banken halen die niet: het DORA-assetregister legt geen cryptografie vast. Originally published at https://sebastienrousseau.com/nl/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau. Licensed under CC-BY-4.0.
