Varje kvantsäker färdplan i banksektorn förutsätter en inventering som inte finns. Planerna är skrivna, styrgrupperna sammanträder, styrkorten står på gult. Under alltihop ligger ett antagande om att någon, någonstans, kan ta fram en lista över varje ställe där banken utför en kryptografisk operation — vilken algoritm, vilken nyckellängd, vilket bibliotek, vilket certifikat, som löper ut när. Nästan inget institut kan det. NCSC:s första milstolpe är ingen migreringsmilstolpe: det är en milstolpe för kartläggning och inventering, med 2028 som slutdatum, och den är den enda ingen har kostnadsberäknat.
Sammanfattning för ledningen
- Ordningen är kartläggning, sedan agilitet, sedan migrering. NCSC:s vägledning sätter en definierad kartläggningsmilstolpe 2028, migrering av högsta prioritet 2031 och färdigställande till 2035. Ett institut som börjar migrera innan det har inventerat kommer att migrera de system det råkar känna till.
- Registret du har svarar inte på frågan du nu står inför. DORA artikel 8 kräver att finansiella entiteter identifierar, klassificerar och dokumenterar IKT-tillgångar och kartlägger deras inbördes beroenden. Den kräver inte en enda kryptografisk egenskap, så ett register som uppfyller artikel 8 kan vara komplett och ändå oanvändbart för planering av kryptoagilitet.
- Standarden finns redan. Kryptografiska tillgångar — algoritmer med nyckelstorlek, läge och kurva; nycklar; certifikat; protokoll — kan representeras i CycloneDX, som är publicerad som ECMA-424. Det här är en schemafråga, inte en inköpsfråga.
- Den svåraste fjärdedelen är inte din att skanna. Hårdvarusäkerhetsmoduler, betalningsapparater, leverantörsinbäddade bibliotek och SaaS-leverantörer kan inte inventeras genom att rikta en skanner mot dem. Den delen av inventeringen byggs på avtalsreglerat intygande, och klausulen måste finnas innan färdplanen kan finnas.
Deadlinen ingen har kostnadsberäknat
Läs de publicerade migreringstidplanerna noga och ordningsföljden är entydig. National Cyber Security Centres färdplan placerar kartläggning och inventering — en fullständig bild av vilka system och tjänster som är beroende av kryptografi — 2028, migreringsarbetet med högsta prioritet 2031 och färdigställande i alla system, tjänster och produkter 2035. NIST:s övergångsrapport, IR 8547, går på ett förenligt spår: kvantsårbara algoritmer för publik nyckel, däribland RSA och ECC, avvecklas efter 2030 och förbjuds efter 2035.
De flesta bankprogram har tagit till sig 2035 som datumet. Det är fel ände av tidplanen att planera från.
Två datum betyder långt mer. Det första är 2028, eftersom kartläggningen är indata till allt som ligger nedströms — du kan inte omfångsbestämma, kostnadsberäkna eller sekvensera en migrering mot en okänd nämnare. Det andra är 2030, eftersom "avvecklad" inte är ett mjukt ord i ett reglerat institut: det är punkten där fortsatt tillit till en algoritm blir ett beslut som någon måste skriva under.
Mellan nu och 2028 ligger färre än trettio månader. Det är en, kanske två, budgetcykler för att bygga en förmåga de flesta institut inte har påbörjat.
Ditt DORA-register redovisar allt utom kryptografin
Här kommer den del som överraskar folk. De flesta stora europeiska banker för redan en detaljerad, regelbundet granskad inventering av IKT-tillgångar, eftersom DORA tvingar dem till det.
Artikel 8 i Regulation (EU) 2022/2554 kräver att finansiella entiteter identifierar, klassificerar och tillräckligt dokumenterar alla IKT-understödda affärsfunktioner, informationen och de IKT-tillgångar som stöder dem samt deras roller och beroenden i förhållande till IKT-risk — och kartlägger konfigurationen av dessa tillgångar och kopplingarna mellan dem, under löpande översyn.
Det är en seriös inventering. Den har också fel form för det här problemet.
Tabell 1: Registret du har och registret som 2028-milstolpen kräver
| Fråga | IKT-tillgångsregister (DORA artikel 8) | Kryptografisk inventering (CBOM) |
|---|---|---|
| Vad är den här tillgången och vem äger den? | Ja — det är registrets kärna | Inte dess syfte |
| Hur kritisk är den, och vad är den beroende av? | Ja — klassificering och kartläggning av inbördes beroenden | Ärvs från tillgångsregistret |
| Vilka algoritmer använder den, och var? | Nej | Ja — per komponent, med nyckelstorlek, läge och kurva |
| Vilket bibliotek implementerar dem, i vilken version? | Delvis, via SBOM:en om en sådan finns | Ja, som en uttrycklig relation |
| Vilka certifikat presenterar den, och när löper de ut? | Sällan, och oftast i ett separat PKI-verktyg | Ja |
| Var finns nycklarna, och hur skyddas de? | Nej | Ja — inklusive om en HSM ligger i vägen |
| Är den här tillgången kvantsårbar? | Går inte att härleda | Direkt besvarbar |
Den sista raden är hela argumentet. Ett institut kan vara fullt förenligt med artikel 8, klara sin granskning och ändå vara oförmöget att svara på "hur många av våra system går sönder 2030" utan att beställa ett kartläggningsprojekt från grunden.
Det här är ingen kritik mot DORA. Artikel 8 skrevs för att besvara frågor om motståndskraft och koncentration, och den besvarar dem väl. Den skrevs helt enkelt inte för att besvara en fråga om kryptoagilitet, och de två registren behöver kopplas ihop i stället för att drivas som separata kalkylark ägda av separata team.
Vad en CBOM faktiskt innehåller
En Cryptography Bill of Materials är en formell inventering av de kryptografiska tillgångarna i ett system — algoritmerna, nycklarna, certifikaten och protokollen, och deras relationer till de programvarukomponenter som använder dem.
Den viktiga strukturella poängen är att det inte är ett nytt filformat. Stödet för kryptografiska tillgångar bidrogs in i CycloneDX, den OWASP-stödda specifikationen för materialförteckningar, som är publicerad som en Ecma International-standard, ECMA-424. En CBOM är därmed ett CycloneDX-dokument med kryptografifälten ifyllda. Den valideras med samma schema, rör sig genom samma pipelines och landar i samma artefaktregister som de SBOM:er ett institut redan producerar för leveranskedjan.
Det betyder mer än det låter. Skillnaden mellan en standard som levererar och en standard som stannar av ligger oftast i om den kräver nya rördragningar. Den här gör det inte.
Tabell 2: CBOM:s tillgångsklasser och migreringsfrågan var och en besvarar
| Tillgångsklass | Vad som registreras | Frågan den besvarar |
|---|---|---|
| Algoritm | Primitiv, nyckelstorlek, läge, kurva, utfyllnad och den funktion den utför | Vilka av våra operationer är kvantsårbara, och med vilken parameterstyrka? |
| Nyckel | Typ, storlek, format, tillstånd och var nyckelmaterialet finns | Vilka nycklar skyddas av en HSM och vilka ligger i applikationsminnet? |
| Certifikat | Subjekt, utfärdare, signaturalgoritm, giltighetsfönster | Vad löper ut före migreringsfönstret, och vad är signerat med en avvecklad algoritm? |
| Protokoll | Protokoll och version, med de chiffersviter som erbjuds | Vad förhandlas faktiskt på nätet, till skillnad från vad konfigurationsfilen påstår? |
| Relaterad komponent | Biblioteket, versionen och kodplatsen som implementerar ovanstående | Om det här biblioteket byts ut, vad följer med? |
Den sista raden är den som gör en inventering till en plan. En lista över algoritmer talar om problemets storlek. En lista över algoritmer kopplad till de komponenter som implementerar dem talar om arbetets form — och det är det en migreringssekvens faktiskt byggs av.
Kartläggning är fyra problem, inte ett
Att behandla kartläggningen som ett enda arbetsspår är det vanligaste sättet dessa program misslyckas på. Det är fyra distinkta problem med fyra olika verktyg, fyra olika ägare och mycket olika konfidensnivåer.
1. Källkod — vad koden begär. Statisk analys över dina egna kodförråd hittar kryptografiska anrop, hårdkodade parametrar och de bibliotek som anropas. Öppen verktygskedja finns: projektet CBOMkit och dess SonarQube-plugin upptäcker kryptografiska tillgångar i källkod och genererar CycloneDX. Högst konfidens, smalast täckning — den ser bara kod du själv skrev och fortfarande bygger.
2. Binärer och containrar — vad som faktiskt levereras. Källkodsanalys missar allt som dras in som ett kompilerat beroende eller bakas in i en basavbildning. Skanning av containrar och filsystem täpper till en del av den luckan. Räkna med att de två vyerna motsäger varandra; motsägelsen är i sig ett fynd.
3. Nätet — vad som verkligen förhandlas. Konfiguration är en avsikt, inte en observation. Passiv observation av TLS-förhandling i drift över hela beståndet är enda sättet att få veta att en tjänst som dokumenterar TLS 1.3 fortfarande accepterar något äldre mot en intern motpart som aldrig uppgraderade. I ett betalningsbestånd är den motparten ofta den som betyder något.
4. Leverantörs- och hårdvarubeståndet — det du inte kan skanna alls. Hårdvarusäkerhetsmoduler, betalterminaler, nätverksapparater, stordatorsubsystem och varje SaaS-leverantör i kedjan. Ingen skanner når dessa. Den här fjärdedelen inventeras genom att fråga, under avtal, och det är där storbankernas verkliga exponering koncentreras, eftersom de system som clearar och avvecklar oproportionerligt ofta är levererade av tredje part.
Den fjärde är den att börja med nu, eftersom den har längst ledtid och inte är en teknisk uppgift. Det är en inköpsuppgift: att få in en klausul om kryptografiskt röjande och kryptoagilitet i avtalet, och i förnyelsemallen, så att svaret 2028 kommer som en leverantörsförpliktelse i stället för som en tjänst. Varje kvartal den klausulen saknas i mallen är ett kvartal av förnyelser som måste öppnas igen senare.
Gör det till en kontroll snarare än ett projekt
Felläget jag skulle satsa på är inte att bankerna hoppar över inventeringen. Det är att de beställer den som en engångsinsats, levererar en försvarbar ögonblicksbild 2028 och låter den förfalla — därför att den finansierades som en leverans i ett kvantsäkerhetsprojekt i stället för att byggas som en löpande kontroll.
En kryptografisk inventering förfaller snabbare än ett tillgångsregister. Certifikat roteras. Bibliotek uppdateras av automatiserad beroendehantering. En basavbildning ändras och en hel tjänst får tyst en annan TLS-stack. En ögonblicksbild tagen 2028 är väsentligt fel 2029, vilket är precis när prioriteringsarbetet inför 2031 är beroende av den.
Tre åtaganden hindrar det.
Generera den i pipelinen, inte i en enkät. En CBOM ska produceras av bygget, jämsides med SBOM:en, och lagras som en versionshanterad artefakt kopplad till releasen. En inventering som sätts ihop genom att mejla ett frågeformulär till applikationsägarna är inaktuell vid ankomsten och går inte att diffa.
Diffa den, och larma på diffen. Den värdefulla signalen är inte inventeringen; det är förändringen i inventeringen. En tjänst som fick ett nytt kryptografiskt beroende, ett certifikat som förkortades, en algoritm som dök upp där den inte fanns förut — det är händelserna värda en kontroll. Det är samma resonemang som gör diffning av SBOM:er mer användbart än arkivering av dem.
Koppla den till registret du redan för. CBOM:en besvarar "vilken kryptografi"; artikel 8-registret besvarar "hur kritiskt, vems, och vad som hänger på det". Ingen av dem är en prioritering på egen hand. Ihopkopplade producerar de den enda rangordning som betyder något: kvantsårbara operationer sorterade efter kritikaliteten hos den affärsfunktion som vilar på dem. Den kopplingen är den faktiska leveransen i ett kartläggningsprogram, och den förtjänar att namnges som sådan i planen.
Den operativa handlingsplanen
- Omformulera 2028-milstolpen till en förmåga, inte en rapport. Leveransen är en löpande, maskinläsbar inventering som återskapar sig själv, inte ett dokument som tas fram en gång åt en tillsynsmyndighet.
- Producera CBOM:er från bygget nu, med nya tjänster först. Försök inte ta hela beståndet i ett svep. Koppla in det i pipelinen för allt som byggs eller väsentligt ändras i år, så att täckningen växer i stället för att kräva en kampanj.
- Lägg in avtalsklausulen i förnyelsemallen det här kvartalet. Kryptografiskt röjande och ett åtagande om kryptoagilitet. Det här har längst ledtid av allt på listan och är oberoende av varje verktygsbeslut.
- Kör nätobservation mot betalnings- och avvecklingsflödena först. Det är där glappet mellan konfiguration och verklighet gör mest skada och där äldre motparter koncentreras.
- Koppla CBOM:en till artikel 8-registret och rangordna på kopplingen. Publicera den rangordnade listan. Det är artefakten som omvandlar en teknisk inventering till ett styrelsesamtal om sekvensering och pengar.
- Diffa varje ny generering och larma på nya kvantsårbara beroenden. En inventering utan diff är ett arkiv.
De institut som klarar 2031 bekvämt är inte de med den mest avancerade synen på ML-KEM. Det är de som kan svara, vilken morgon som helst och utan att beställa ett projekt, på frågan om var deras kryptografi faktiskt finns.
Vanliga frågor
Är en CBOM något annat än en SBOM?
Det är samma dokumenttyp med andra fält ifyllda. Stödet för kryptografiska tillgångar togs upp i CycloneDX, som är publicerad som ECMA-424, så en CBOM valideras mot samma schema och rör sig genom samma verktygskedja som en SBOM. Institut som redan genererar SBOM:er står närmare det här än de brukar anta.
Kräver DORA en kryptografisk inventering?
Inte i de termerna. Artikel 8 i Regulation (EU) 2022/2554 kräver identifiering, klassificering och dokumentation av IKT-tillgångar samt kartläggning av deras konfiguration och inbördes beroenden. Kryptografiska egenskaper hör inte till de attribut den ålägger dig att registrera, och därför kan ett register som uppfyller artikel 8 inte besvara en fråga om kvantsårbarhet utan att utökas.
Varför måste kartläggningen bli klar så långt före migreringen?
Därför att den är indata till prioriteringen. NCSC:s vägledning sätter kartläggningen till 2028 och migreringen med högsta prioritet till 2031 just för att det ska finnas ett definierat intervall att rangordna beståndet och sekvensera arbetet i. Att pressa ihop de två betyder att man migrerar det som är bäst förstått i stället för det som betyder mest.
Hur inventerar vi kryptografi inuti leverantörshårdvara och SaaS?
Du skannar den inte; du kräver röjande. Hårdvarusäkerhetsmoduler, betalningsapparater och tjänsteleverantörer måste omfattas av en avtalsreglerad förpliktelse om kryptografiskt röjande och kryptoagilitet. Eftersom det här hänger på förnyelsecykler snarare än på teknisk insats har det längst ledtid i hela programmet och bör starta först.
Bör vi vänta på att verktygen mognar innan vi börjar?
Nej, och verktygsargumentet är oftast ett ombud för budgetargumentet. Öppna implementationer genererar redan kryptografiska CycloneDX-inventeringar från källkod och från containeravbildningar, och specifikationen är en ratificerad standard. Restriktionen för en 2028-milstolpe är täckning och avtalsmässig räckvidd, inte verktygstillgång.
Referenser
- European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Bryssel: Europeiska unionens officiella tidning. Tillgänglig via: European Parliament and Council of the European Union, 2022..
- National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. London: NCSC. Tillgänglig via: 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. Tillgänglig via: 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. Tillgänglig via: National Institute of Standards and Technology, 2024..
- OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Tillgänglig via: OWASP Foundation, 2026..
- OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Tillgänglig via: OWASP CycloneDX, 2026..
- IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Tillgänglig via: IBM Research, 2026..
Senast granskad .
Återpublicera denna artikel
Kopiera format för Medium
# Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau > Originally published at [https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/](https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/) NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi. Read the full article on sebastienrousseau.com: https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Kopiera format för Mastodon
Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi. https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Kopiera formaterat för LinkedIn
Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi. Här är de viktigaste strategiska lärdomarna: - Deadlinen ingen har kostnadsberäknat. Läs de publicerade migreringstidplanerna noga och ordningsföljden är entydig. - Ditt DORA-register redovisar allt utom kryptografin. Här kommer den del som överraskar folk. - Vad en CBOM faktiskt innehåller. En Cryptography Bill of Materials är en formell inventering av de kryptografiska tillgångarna i ett system — algoritmerna, nycklarna, certifikaten och protokollen, och deras relationer till de programvarukomponenter… - Kartläggning är fyra problem, inte ett. Att behandla kartläggningen som ett enda arbetsspår är det vanligaste sättet dessa program misslyckas på. Hur hanterar din organisation de utmaningar som beskrivs i denna artikel? → https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ #CryptographicBillOfMaterials #Cbom #Cyclonedx #Ecma424 #KryptografiskInventering Sebastien Rousseau | CC-BY-4.0
Citera den här artikeln
Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau
NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi.
BibTeX
@online{rousseau2026du,
author = {Rousseau, Sebastien},
title = {{Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau}},
year = {2026},
url = {https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/},
urldate = {2026}
}RIS
TY - GEN AU - Rousseau, Sebastien TI - Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau PY - 2026 UR - https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ ER -
Vancouver
Rousseau S. Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau. sebastienrousseau.com. 2026 Jul 28. Available from: https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Chicago
Rousseau, Sebastien. "Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau." sebastienrousseau.com. July 28, 2026. https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/.
APA
Rousseau, S. (2026, July 28). Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau. sebastienrousseau.com. https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/
Återpublicera den här artikeln
Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau
NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi.
Den här artikeln är licensierad under Creative Commons Attribution 4.0 International. Återpublicering kräver attribution till den kanoniska URL:en.
Du kan inte migrera det du inte kan inventera: CBOM-luckan i bankerna — Sebastien Rousseau NCSC:s kartläggningsdeadline 2028 infaller före varje migreringsdeadline. Bankerna klarar den inte – DORA-registret redovisar ingen kryptografi. Originally published at https://sebastienrousseau.com/sv/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau. Licensed under CC-BY-4.0.