Företagsnätverk – det lager som ingen lägger märke till förrän det slutar fungera

5 november 2026
Andrew Hay
Andrew Hay, operativ chef

Nätverksinfrastrukturen är det område som oftast förbises i diskussionen om suveränitet. Applikationerna och dataplattformarna utvärderas, medan nätverket behandlas som en slags infrastruktur. Kommissionens moln

Sovereignty Framework vägrar att hoppa över detta, och det finns goda skäl till det. Det är i den här infrastrukturen som paketen passerar jurisdiktionsgränser, där firmware signeras och där förvaltningsplanet i det tysta exporterar dina driftsdata till ett utländskt moln.

Hur företagsnätverk ser ut idag

Två mönster dominerar.

  • Ett stort europeiskt företag som använder SD-WAN och SASE från en av de ledande amerikanska leverantörerna, med molnbaserade styrenheter som är placerade i USA eller i en europeisk region med huvudkontor i USA. Denna miljö uppnår vanligtvis SEAL-1 enligt SOV-5 och SOV-7, oavsett var enheterna fysiskt är placerade.
  • Ett europeiskt företag som använder nätverk för campus och datacenter från en europeisk leverantör, med lokal förvaltning, men som förlitar sig på firmware från länder utanför EU i den underliggande hårdvaran. Denna anläggning kan uppnå SEAL-2 när det gäller de operativa målen, men fastnar på SOV-5 på grund av hårdvarulagret.

De SOV-mål som präglar nätverksbyggandet

SOV-5, leveranskedja

Detta är det mål som nätverksteamen underskattar mest. Ramverket ställer frågor om var hårdvaran tillverkas, varifrån firmware signeras och uppdateras samt hur överskådlig underleverantörskedjan är.

I de flesta företagsnätverk kommer firmwareuppdateringarna från länder utanför EU och är signerade med nycklar som inte härrör från EU. Detta utgör en SOV-5-risk, oavsett om paketen någonsin lämnar landet eller inte.

SOV-7, säkerhet och efterlevnad

Frågan om var nätverksdriftscentralen (NOC) och säkerhetsdriftscentralen (SOC) ska placeras är mer aktuell inom nätverksbranschen än någon annanstans, eftersom den driftsdata som NOC hanterar – flödesloggar, konfigurationsändringar och topologidata – i sig är känslig.

Om NOC:n är belägen i en jurisdiktion utanför EU, finns även telemetrin där, och enligt regelverket betraktas den som data som passerar gränsen.

SOV-6, teknik

Öppna standarder kontra proprietära standarder.

Ett nätverk som bygger på dokumenterade protokoll och öppna API:er är portabelt.

Ett nätverk som bygger på en egenutvecklad styrenhet med egna telemetriformat gör det inte. Ramverket gynnar det första och straffar det andra.

Problemet med förvaltningsplanet

Molnhanterade nätverk är den enskilt största frågan som rör suveränitet i de flesta företag idag, och den som man lättast förbiser.

När en nätverksleverantör flyttar sin styrenhet till molnet inträffar tre saker samtidigt.

  • Konfigurationsdata lämnar kundens lokaler.
  • Telemetridata lämnar kundens lokaler.
  • API-slutpunkter för styrning faller under leverantörens ansvarsområde.

Ramverket bryr sig inte om att detta är praktiskt. Det bedömer den juridiska exponeringen. En molnbaserad SD-WAN-miljö med en styrenhet som är hostad i USA uppfyller inte SEAL-2-kraven, oavsett vad som står i säljpresentationen.

Det finns tre ståndpunkter som går att försvara:

  1. Flytta kontrollenheten till en instans som drivs inom EU, med support inom EU och nyckelförvaring inom EU. Vissa leverantörer erbjuder detta, andra inte.
  2. Byt till en EU-leverantör vars databehandlingssystem som standard är placerat inom EU. Detta är ofta en mer omfattande fråga än vad organisationen kan hantera under en enda cykel.
  3. Övergå till en modell med egenhostad styrenhet på EU-infrastruktur och acceptera den därmed förknippade driftskostnaden. Detta är ofta den enda vägen till SEAL-3.

Frågan om firmware och signering

Det är när det gäller firmware som debatterna om suveränitet blir besvärliga, eftersom det nästan inte finns några europeiska halvledare på den vanliga marknaden för företagsnätverk.

Ramverket tar hänsyn till detta och ställer inte krav på att varje lager ska bestå av europeiskt kisel. Däremot ställs krav på öppenhet, revisionsrättigheter och kontroll över uppdateringsprocessen.

Praktiska ställningar som ger bra poäng:

  • Ett programuppdateringsarkiv som drivs av EU, och som kontrolleras av kunden eller av en EU-integratör, med signerade firmware-avbildningar som verifieras lokalt.
  • En dokumenterad förteckning över underleverantörer med revisionsrättigheter, inklusive den geografiska placeringen av signeringsnycklarna.
  • En avtalsklausul som kräver att varje ändring av det land där firmware utvecklas eller signeras ska anmälas.

Åtta frågor om nätverk för din nästa uppgradering

  1. Var är förvaltningsplanet placerat, och under vems jurisdiktion faller det?
  2. Var lagras driftsdata, och hur länge?
  3. Vilket land signerar firmware för varje hårdvaruserie, och vem förfogar över signeringsnycklarna?
  4. Hur ser NOC:s geografiska täckning ut, och kan vi teckna ett avtal om en NOC som endast gäller inom EU?
  5. Vilka kontroll-API:er är dokumenterade och öppna, och vilka är proprietära?
  6. Hur ser vår utträdesstrategi ut om leverantören byter jurisdiktion för sin kontrollserver under avtalets löptid?
  7. Vilka underleverantörer ingår i leveranskedjan, och vilka granskningsrättigheter har vi gentemot dem?
  8. Vilket SEAL-betyg skulle vi idag kunna redovisa för en tillsynsmyndighet, utifrån de kriterier som kommissionen faktiskt tillämpar?

Vad detta innebär för köpare

Nätverket presterar sämre än vad de flesta IT-chefer tror, och åtgärderna är mindre besvärliga än att byta leverantör helt och hållet.

Börja med förvaltningsplanet och uppdateringsvägen för firmware. Dessa två ändringar innebär vanligtvis att en miljö höjs en hel SEAL-nivå.

I inlägg fem går vi igenom kommissionens beräkningsverktyg med hjälp av ett litet, realistiskt exempel, så att du kan börja beräkna värdet på din egen fastighet innan din nästa anbudsinfordran går ut.