# Digdirs arkitekturprinsipp 4: Tillit og sikkerhet

**Last updated:** 2026-04
**Status:** Gjeldende
**Category:** Norwegian Public Sector AI Governance

---

## Introduksjon

Tillit er fundamentet for digitaliseringen av offentlig sektor. Innbyggere, næringsliv og frivillige organisasjoner må ha tillit til at offentlige virksomheter løser sine oppgaver på en god og sikker måte. Digital sikkerhet er ikke bare en teknisk forutsetning – den er en betingelse for å opprettholde samfunnets tillit til offentlig forvaltning.

For AI-løsninger stiller dette spesielle krav. AI-systemer behandler ofte sensitive personopplysninger, tar beslutninger som påvirker enkeltmenneskers rettigheter, og opererer i en kontekst der forklarbarhet og etterprøvbarhet er lovpålagt. Manglende sikkerhet i AI-løsninger kan true både personvern, rettssikkerhet og demokratiske prosesser. Samtidig må sikkerheten balanseres mot tilgjengelighet – tjenester som er så sikre at de blir ubrukelige, svekker også tilliten.

Digdirs arkitekturprinsipp for tillit og sikkerhet bygger på en helhetlig tilnærming der teknologi, organisasjon og jus samvirker. For AI-arkitekter innebærer dette å integrere sikkerhet fra tidligste designfase (security by design), følge NSMs grunnprinsipper for IKT-sikkerhet, og anvende moderne sikkerhetskonsepter som Zero Trust – samtidig som løsningene forblir brukervennlige og tjenesteorienterte.

## Prinsippets kjerneinnhold

### Digdirs formulering

Digitaliseringsdirektoratet (Digdir) har definert **prinsipp 7: "Sørg for tillit til oppgaveløsningen"** som ett av syv nasjonale arkitekturprinsipper. Dette prinsippet er obligatorisk for statlig sektor og anbefalt for kommunesektoren.

Prinsippet innebærer at:
- Innbyggere, næringsliv og frivillige organisasjoner skal ha tillit til at offentlige virksomheter løser sine oppgaver på en god og sikker måte
- Digital sikkerhet er en forutsetning for å opprettholde tillit til offentlig sektor
- Arbeidet med informasjonssikkerhet skal være **risikobasert**, med fleksibilitet og rom for tilpasning til virksomhetens størrelse, egenart og risiko
- Tjenester må utvikles med **innebygget personvern** (privacy by design) og informasjonssikkerhet må ivaretas

### Forholdet til NSM grunnprinsipper

NSMs (Nasjonal sikkerhetsmyndighet) grunnprinsipper for IKT-sikkerhet er et sett med anbefalinger som utdyper hvordan virksomheter kan sikre sine informasjonssystemer. Prinsippene er relevante for alle norske virksomheter, men hovedmålgruppen er virksomheter som forvalter kritiske samfunnsfunksjoner og/eller kritisk infrastruktur.

NSMs grunnprinsipper fokuserer på **teknologiske og organisatoriske tiltak** og dekker:
- Identifisering og autentisering
- Tilgangsstyring og autorisasjon
- Logging og overvåking
- Sikkerhet i utvikling og drift
- Kryptering og nettverkssikkerhet
- Beredskap og gjenoppretting

For AI-løsninger er NSMs prinsipper særlig relevante fordi de:
- Krever risikobasert tilnærming (kritisk for AI med høy påvirkning)
- Fremhever logging og sporbarhet (nødvendig for AI-transparens)
- Vektlegger sikkerhet gjennom hele systemets livssyklus (fra treningsdata til produksjon)

### Tillitskjeden i digitale tjenester

Tillit i digitale offentlige tjenester bygges gjennom en kjede av tillitselementer:

1. **Identitetssikkerhet** – Brukeren må være trygg på at tjenesten er ekte (autentisitet) og at identiteten deres er beskyttet
2. **Datasikkerhet** – Personopplysninger og sensitive data må beskyttes mot innsyn, endring og tap
3. **Prosesssikkerhet** – Beslutninger og behandling må være korrekt, konsistent og etterprøvbar
4. **Juridisk sikkerhet** – Tjenesten må overholde lover og forskrifter (GDPR, Forvaltningsloven, Arkivloven)
5. **Teknisk sikkerhet** – Infrastruktur og kode må være robust mot angrep
6. **Organisatorisk sikkerhet** – Virksomheten må ha kompetanse, rutiner og styring på plass

For AI-løsninger legges det til:
7. **Modellsikkerhet** – AI-modellen må være beskyttet mot manipulasjon, bias og utilsiktede utfall
8. **Forklarbarhet** – Brukere og forvaltning må kunne forstå hvordan AI-beslutninger tas

Brytes ett ledd i kjeden, svekkes tilliten til hele tjenesten.

## Sikkerhetskrav for AI-løsninger

### Konfidensialitet i AI-modeller

**Trusler:**
- **Model extraction** – Angriper gjenskaper modellen gjennom mange spørringer
- **Training data leakage** – Modellen avslører sensitiv treningsdata (spesielt i LLM-er)
- **Membership inference** – Angriper kan dedusere om spesifikke data var med i treningssettet

**Tiltak:**
- Krypter modellvekter i hvile og transit (Azure Key Vault, Managed Identity)
- Bruk **differential privacy** i treningsprosessen for å beskytte individuelle datapunkter
- Begrens API-tilgang med rate limiting og anomaly detection
- Vurder **federated learning** for å unngå sentralisering av sensitive data
- Implementer **model versioning** og access control (Azure ML Model Registry)

**Microsoft-implementering:**
- Azure AI Foundry: Managed endpoints med Azure Private Link
- Azure OpenAI: Customer-managed keys (CMK) for data encryption
- Azure Machine Learning: Network isolation med VNet/Subnet

### Integritet av treningsdata

**Trusler:**
- **Data poisoning** – Angriper injiserer skadelige data i treningssettet for å manipulere modellens oppførsel
- **Label flipping** – Endring av merkelapper (labels) i supervised learning-data
- **Backdoor attacks** – Subtile mønstre legges inn for å trigge feil output under spesifikke forhold

**Tiltak:**
- Valider og verifiser datakvalitet før trening (Azure Data Factory, Synapse)
- Bruk **immutable storage** for treningsdata (Azure Blob Storage med WORM-policy)
- Implementer **data lineage tracking** – dokumenter herkomst, transformasjoner og bruk
- Kjør **anomaly detection** på treningsdata før bruk
- Versjonskontroller datasett (Azure ML Data Assets)
- Bruk **content filtering** på input til modeller (Azure OpenAI Content Safety)

**Microsoft-implementering:**
- Azure AI Search: Indexing med role-based access control (RBAC)
- Purview: Data governance og lineage tracking
- Azure OpenAI: Innebygd content filtering (prompt shields, groundedness detection)

### Tilgjengelighet av AI-tjenester

**Trusler:**
- **Denial of Service (DoS)** – Angriper overbelaster AI-endepunkter
- **Model inversion** – Komplekse spørringer som forbruker enorme ressurser
- **Resource exhaustion** – Mangel på compute eller tokens i produksjon

**Tiltak:**
- Implementer **rate limiting** og quota management (Azure API Management)
- Bruk **auto-scaling** med øvre grenser (Azure Container Apps, AKS)
- Aktiver **Azure DDoS Protection** for nettverkstrafikk
- Definer **SLA-er** og overvåk latency/throughput (Azure Monitor, Application Insights)
- Bruk **circuit breakers** for å unngå kaskadesvikt
- Implementer **fallback-strategier** (cached responses, degraded mode)

**Microsoft-implementering:**
- Azure OpenAI: Provisioned Throughput Units (PTU) for garantert kapasitet
- Azure AI Foundry: Managed endpoints med auto-scaling
- Azure Front Door: Global load balancing og DDoS-beskyttelse

### Sporbarhet og logging

**Krav (spesielt i offentlig sektor):**
- **Audit trails** – Hvem gjorde hva, når, og hvorfor?
- **Model provenance** – Hvilken modellversjon ble brukt for en gitt beslutning?
- **Data lineage** – Hvilke data lå til grunn for utfallet?
- **Explanation logs** – Hvorfor kom modellen til denne konklusjonen?

**Tiltak:**
- Logg alle API-kall til AI-tjenester (Azure Monitor, Application Insights)
- Lagre **request/response pairs** med metadata (timestamp, user ID, model version)
- Bruk **correlation IDs** for å spore transaksjoner på tvers av systemer
- Implementer **immutable audit logs** (Azure Event Hubs, Log Analytics)
- Integrer med **Microsoft Sentinel** for SIEM og threat detection
- Opprett **dashboards** for compliance-rapportering (Power BI, Azure Workbooks)

**Spesielt for offentlig sektor:**
- Logging må være **arkivvennlig** (Noark5-kompatibel ved arkivpliktige vedtak)
- Oppbevaringstid må følge Arkivloven og forskrifter
- Personopplysninger i logger må behandles i henhold til GDPR (pseudonymisering, sletting)

**Microsoft-implementering:**
- Azure OpenAI: Diagnostikk-logging til Log Analytics
- Azure AI Foundry: Model monitoring med data drift detection
- Purview: Compliance-rapportering og data governance

## Zero Trust for AI

### Prinsippene anvendt på AI

Zero Trust er en sikkerhetsstrategi som **antar at brudd allerede har skjedd** og verifiserer hver forespørsel som om den kom fra et ukontrollert nettverk. Regjeringen har gjennom stortingsmeldingen *"Nasjonal kontroll og digital motstandskrift for å ivareta nasjonal sikkerhet – Så åpent som mulig, så sikkert som nødvendig"* satt fokus på Zero Trust-modellen.

Zero Trust bygger på tre kjerneprinsipper:
1. **"Never trust, always verify"** – Aldri stol på, alltid verifiser
2. **Least privilege access** – Minste nødvendige tilgang (Just-In-Time, Just-Enough-Access)
3. **Assume breach** – Anta at brudd har skjedd; minimer skadeomfang

For AI-løsninger betyr dette:

**1. Verify explicitly (verifiser eksplisitt)**
- Autentiser og autoriser hver tilgang til AI-modeller og data basert på **brukeridentitet, enhetshelse, lokasjon og risikosignaler**
- Bruk **Conditional Access** for AI-endepunkter (krever f.eks. MFA for høy-risiko inferens)
- Valider **input til modeller** før prosessering (prompt injection-forsvar)

**2. Use least privilege access (minste privilegium)**
- Begrens tilgang til treningsdata, modeller og inferens-APIer via **RBAC** (Role-Based Access Control)
- Bruk **Managed Identities** for tjeneste-til-tjeneste-autentisering (ingen hardkodede nøkler)
- Implementer **Just-In-Time (JIT)** admin-tilgang for modelltrening og deployment
- Segmenter AI-workloads i egne **VNets/subnets** med mikrosegmentering

**3. Assume breach (anta brudd)**
- **Krypter data** i hvile og transit (TLS 1.3, customer-managed keys)
- **Overvåk kontinuerlig** for anomalier (uvanlige API-kall, data exfiltration)
- Implementer **network segmentation** for å hindre lateral movement
- Bruk **immutable backups** av modeller og data for gjenoppretting

### Microsoft Zero Trust-modellen *(Verified MCP 2026-04)*

**Oppdaterte Zero Trust-ressurser fra Microsoft:**
- Ny adopsjonsramme: Zero Trust adoption framework (business-outcome fokusert implementering)
- Azure IaaS-spesifikk veiledning: Apply Zero Trust principles to Azure IaaS overview
- Nettverksfokus: Kryptering av all nettverkstrafikk, mikrosegmentering med NSG og Azure Firewall, avvikle legacy VPN til fordel for identitetsbaserte tilnærminger
- Confidential computing: For høysensitiv AI-workload — beskytter data under prosessering
- Ressursbeskyttelse mot destruktive angrep: Resource locks, immutable backups, geo-replication

Microsoft har utviklet en omfattende Zero Trust-arkitektur som dekker seks pilarer:

| Pilar | Relevans for AI-arkitekter |
|-------|----------------------------|
| **Identities** | Microsoft Entra ID for bruker/tjeneste-autentisering; Conditional Access for risiko-basert tilgang til AI-tjenester |
| **Devices** | Intune for enhetsstyring; kun managed devices får tilgang til sensitive AI-endepunkter |
| **Applications** | Defender for Cloud Apps overvåker AI-API-bruk; App-level RBAC for modeller |
| **Data** | Information Protection for klassifisering og kryptering av treningsdata; Purview for data governance |
| **Infrastructure** | Defender for Cloud for sikkerhetsstyring av Azure-ressurser; network micro-segmentation |
| **Networks** | Azure Firewall, Private Link, DDoS Protection; ingen implicit trust i nettverkssegmenter |

**AI-spesifikke Zero Trust-tiltak i Microsoft-stacken:**
- **Azure OpenAI**: Managed Identity-autentisering, VNET-injection, Private Endpoints
- **Azure AI Search**: RBAC på index-nivå, network isolation, CMK-kryptering
- **Azure Machine Learning**: VNET-isolerte workspaces, Managed Identity for compute, private endpoints for model serving
- **Copilot Studio**: Data Loss Prevention (DLP), Conditional Access, audit logging

### Implementering i Azure

**Steg 1: Identitetsstyring**
- Bruk **Microsoft Entra ID** som identitetsleverandør for alle AI-tjenester
- Aktiver **Conditional Access** med politikker basert på:
  - Brukerrisiko (Entra ID Protection)
  - Enhetsstatus (Intune compliance)
  - Lokasjon (geografisk/IP-basert)
  - Applikasjonssensitivitet (AI-modeller med PII krever MFA)

**Steg 2: Nettverkssegmentering**
- Opprett **dedikerte VNets** for AI-workloads (trening, inferens, data)
- Bruk **Azure Firewall** eller **Network Security Groups (NSGs)** for mikrosegmentering
- Aktiver **Private Link** for Azure OpenAI, AI Search, Storage Accounts
- Implementer **hub-and-spoke-topologi** med sentralisert sikkerhetskontroll

**Steg 3: Datakryptering**
- Bruk **customer-managed keys (CMK)** via Azure Key Vault for:
  - Azure Storage (treningsdata)
  - Azure OpenAI (fine-tuned modeller)
  - Azure AI Search (indexer)
- Aktiver **TLS 1.3** for all data i transit
- Implementer **double encryption** for ekstra sensitive datasett

**Steg 4: Kontinuerlig overvåking**
- Integrer AI-tjenester med **Microsoft Sentinel** (SIEM/SOAR)
- Aktiver **Defender for Cloud** for posture management
- Bruk **Network Watcher Traffic Analytics** for nettverkssynlighet
- Implementer **AI-drevet anomaly detection** (Defender XDR)

**Steg 5: Automatisert respons**
- Opprett **Logic Apps/playbooks** for å automatisk:
  - Blokkere ondsinnede IP-er i Azure Firewall
  - Isolere kompromitterte enheter (Defender for Endpoint)
  - Eskalere høy-risiko AI-inferenser til security team
  - Oppdatere NSG-regler ved mistenkelig trafikk

**Eksempel på Zero Trust-arkitektur for Azure OpenAI:**

```
User (Entra ID + Conditional Access)
  ↓ (MFA, device compliance, location check)
Azure Front Door (DDoS, WAF)
  ↓ (Private Link)
Azure OpenAI (VNet-injected, Managed Identity)
  ↓ (RBAC, Private Endpoint)
Azure AI Search (CMK-encrypted index)
  ↓ (Managed Identity)
Azure Storage (WORM-enabled treningsdata)
  ↓
Microsoft Sentinel (logging, threat detection)
```

## Beslutningsveiledning

### Når skal jeg anvende Zero Trust-prinsipper for AI?

| Scenario | Zero Trust nødvendig? | Rasjonale |
|----------|----------------------|-----------|
| AI-modell bruker **personopplysninger** (helseopplysninger, økonomi, personnummer) | **JA** | GDPR art. 32 krever tekniske tiltak; Zero Trust oppfyller "tilstrekkelig sikkerhet" |
| AI-modell tar **automatiserte beslutninger** med rettslig virkning (f.eks. tildeling av ytelser) | **JA** | GDPR art. 22 og Forvaltningsloven krever sporbarhet og rettssikkerhet |
| AI-tjeneste er **eksponert eksternt** (API, web app) | **JA** | Angrepsflate mot internett; implicit trust er høyrisiko |
| AI-workload kjører i **multi-tenant-miljø** (delte ressurser) | **JA** | Risiko for data leakage mellom tenants |
| Intern AI-tool for **ikke-kritiske oppgaver** (f.eks. meeting summaries) | Delvis | Start med Managed Identity og RBAC; full Zero Trust hvis data-klassifisering øker |
| Eksperimentell AI-modell i **sandkasse-miljø** (isolert, ingen produksjonsdata) | Delvis | Implementer basis-sikkerhet (Managed Identity, network isolation); full Zero Trust ved produksjonssetting |

### Beslutningstabell: Valg av sikkerhetstiltak

| Krav | Tiltak | Microsoft-tjeneste |
|------|--------|-------------------|
| Beskytte treningsdata mot uautorisert tilgang | RBAC + Private Link + CMK | Azure Storage + Key Vault |
| Forhindre model extraction | Rate limiting + anomaly detection | Azure API Management + Defender for Cloud |
| Sikre API-autentisering | Managed Identity + Conditional Access | Entra ID + Azure OpenAI |
| Logge AI-beslutninger for etterprøvbarhet | Audit logging + immutable storage | Log Analytics + Event Hubs |
| Beskytte mot prompt injection | Input validation + content filtering | Azure OpenAI Content Safety |
| Hindre data leakage i LLM-svar | Groundedness detection + PII redaction | Azure OpenAI (prompt shields) + Purview |
| Opprettholde tilgjengelighet under angrep | DDoS Protection + auto-scaling | Azure Front Door + PTU (OpenAI) |
| Overvåke og respondere på trusler | SIEM + automated playbooks | Microsoft Sentinel + Logic Apps |

### Vanlige feil å unngå

**Feil 1: "AI-modellen kjører i Azure, så den er automatisk sikker"**
- Realitet: Azure tilbyr sikkerhetsfunksjoner, men du må aktivere og konfigurere dem (shared responsibility model)
- Løsning: Bruk Defender for Cloud til å identifisere sikkerhetsgap; følg Azure Security Benchmark

**Feil 2: "Vi trenger ikke logging fordi modellen bare gir anbefalinger, ikke beslutninger"**
- Realitet: Offentlig sektor har loggeplikt for alle automatiserte prosesser som påvirker saksbehandling (Forvaltningsloven § 11)
- Løsning: Implementer audit logging selv for advisory AI; vurder arkivplikt med jurist

**Feil 3: "Vi bruker API-nøkler for autentisering – det er trygt nok"**
- Realitet: API-nøkler i kode/config er en topp-10 sikkerhetsrisiko; kan lekke via GitHub, logs, etc.
- Løsning: Bytt til Managed Identity; roter eksisterende nøkler via Key Vault

**Feil 4: "Vi kjører AI-modell og database i samme VNet, så nettverkssikkerhet er god"**
- Realitet: Flat nettverksarkitektur tillater lateral movement ved brudd
- Løsning: Implementer mikrosegmentering med NSGs; least privilege network access

**Feil 5: "Zero Trust er for komplisert for vår lille virksomhet"**
- Realitet: Zero Trust skalerer; start med grunnleggende tiltak (Managed Identity, RBAC, MFA)
- Løsning: Bruk Microsoft Security Copilot til å identifisere quick wins; implementer inkrementelt

**Feil 6: "Vi trenger ikke å kryptere data fordi vi har godt nettverk-perimeter"**
- Realitet: Perimeter-basert sikkerhet er foreldet; brudd skjer innenfor nettverket
- Løsning: Krypter data i hvile (CMK) og transit (TLS 1.3); anta at nettverket er kompromittert

## For arkitekten (Cosmo)

Når du designer AI-løsninger for norsk offentlig sektor, bruk disse spørsmålene for å vurdere tillit og sikkerhet:

### Identitet og tilgangsstyring
1. **Hvordan autentiseres brukere og tjenester?** (API-nøkler, Managed Identity, Entra ID?)
2. **Bruker løsningen Conditional Access for risiko-basert tilgang?** (Hvilket risikonivå kreves for MFA?)
3. **Er RBAC implementert med least privilege?** (Hvem har tilgang til treningsdata, modeller, logs?)
4. **Hvordan roteres og lagres hemmeligheter?** (Key Vault, auto-rotation?)

### Datasikkerhet
5. **Hvor lagres treningsdata, og hvordan beskyttes de?** (Kryptering i hvile? WORM-enabled?)
6. **Inneholder treningsdata personopplysninger?** (Hvis ja: DPIA gjennomført? Behandlingsgrunnlag?)
7. **Hvordan sikres data lineage og provenance?** (Purview, Azure ML Data Assets?)
8. **Er det implementert tiltak mot data poisoning?** (Validering, versjonskontroll, anomaly detection?)

### Modellsikkerhet
9. **Hvordan beskyttes modellen mot extraction/inversion-angrep?** (Rate limiting, differential privacy?)
10. **Er fine-tuned modeller kryptert med customer-managed keys?** (CMK via Key Vault?)
11. **Hvordan oppdages og håndteres model drift?** (Azure Monitor, Responsible AI Dashboard?)
12. **Er det implementert fallback-strategi ved modellsvikt?** (Cached responses, manual override?)

### Nettverks- og infrastruktursikkerhet
13. **Er AI-workloads nettverksisolerte?** (VNet, Private Link, NSGs?)
14. **Bruker løsningen hub-and-spoke-topologi?** (Sentralisert firewall/sikkerhetskontroll?)
15. **Er DDoS Protection aktivert?** (Azure Front Door, Azure DDoS Protection?)
16. **Hvordan håndteres lateral movement ved brudd?** (Mikrosegmentering, Zero Trust-nettverk?)

### Logging og sporbarhet
17. **Logges alle AI-inferenser med tilstrekkelig metadata?** (User ID, timestamp, model version, input/output?)
18. **Er audit logs immutable og arkivvennlige?** (Event Hubs, Noark5-integrasjon?)
19. **Hvor lenge lagres logger?** (Oppfyller Arkivloven og GDPR?)
20. **Er logging integrert med SIEM for threat detection?** (Microsoft Sentinel, Defender XDR?)

### Overvåking og respons
21. **Hvilke sikkerhetsindikatorer overvåkes?** (Anomalier i API-bruk, data exfiltration, prompt injection-forsøk?)
22. **Er det definert playbooks for automatisert respons?** (Logic Apps, Sentinel playbooks?)
23. **Hvordan testes beredskap for AI-sikkerhetsbrudd?** (Red team-øvelser, penetrasjonstesting?)
24. **Hvem varsles ved sikkerhetshendelser?** (Security Operations Center, dataansvarlig, Datatilsynet?)

### Compliance og governance
25. **Er det gjennomført DPIA for AI-løsningen?** (Vurdert risiko for personvern?)
26. **Overholder løsningen NSMs grunnprinsipper?** (Hvilke prinsipper er implementert?)
27. **Er det utarbeidet ROS-analyse?** (Risiko- og sårbarhetsanalyse?)
28. **Hvordan dokumenteres sikkerhetsarkitekturen?** (ADR-er, arkitekturdiagrammer?)

### Zero Trust-modenhet
29. **Hvilken Zero Trust-modenhet har løsningen?** (Tradisjonell, avansert, optimal?)
30. **Hvilke av de tre Zero Trust-prinsippene er implementert?** (Verify explicitly, least privilege, assume breach?)
31. **Er det identifisert legacy-komponenter som må fasøes ut?** (VPN, statiske firewalls, hardkodede nøkler?)
32. **Hvordan måles og forbedres Zero Trust-modenhet over tid?** (Security scorecard, kontinuerlig forbedring?)

## Kilder og verifisering

### Norske myndigheter
- [Digdir: Overordnede arkitekturprinsipper](https://www.digdir.no/digital-samhandling/overordnede-arkitekturprinsipper/1065)
- [Digdir: Felles sikkerhet i forvaltningen](https://www.digdir.no/informasjonssikkerhet/felles-sikkerhet-i-forvaltningen/4106)
- [Digdir: NSMs grunnprinsipper](https://www.digdir.no/informasjonssikkerhet/nsms-grunnprinsipper/2219)
- [NSM: Grunnprinsipper for IKT-sikkerhet](https://nsm.no/regelverk-og-hjelp/rad-og-anbefalinger/grunnprinsipper-for-ikt-sikkerhet/introduksjon/)
- [NSM: Grunnprinsipper for IKT-sikkerhet v2.1 (PDF)](https://nsm.no/getfile.php/1313975-1717589722/NSM/Filer/Dokumenter/Veiledere/NSMs%20Grunnprinsipper%20for%20IKT-sikkerhet%20v2.1.pdf)
- [Helsedirektoratet: Zero Trust-modellen – et paradigmeskifte innen digital sikkerhet?](https://www.helsedirektoratet.no/digitalisering-og-e-helse/normen-personvern-og-informasjonssikkerhet/normen/zero-trust-modellen--et-paradigmeskifte-innen-digital-sikkerhet)
- [Regjeringen: Én digital offentlig sektor](https://www.regjeringen.no/no/dokumenter/en-digital-offentlig-sektor/id2685559/)

### Microsoft dokumentasjon
- [Microsoft Security: Zero Trust](https://www.microsoft.com/nb-no/security/business/zero-trust)
- [Microsoft Learn: Zero Trust security in Azure](https://learn.microsoft.com/en-us/azure/security/fundamentals/zero-trust) *(Verified MCP 2026-04)*
- [Microsoft Learn: Secure networks with SASE, Zero Trust, and AI](https://learn.microsoft.com/en-us/security/zero-trust/deploy/networks)
- [Microsoft Learn: Innovate and automate using AI services (security)](https://learn.microsoft.com/en-us/azure/app-modernization-guidance/innovate/innovate-and-automate-using-ai-services#build-responsible,-secure-ai-systems)
- [Microsoft Learn: Zero Trust partner kit resources](https://learn.microsoft.com/en-us/security/zero-trust/zero-trust-partner-kit)

### Norske konsulentselskap (kontekstualisering)
- [PwC: Sikkerhetsarkitektur og Zero Trust-strategi](https://www.pwc.no/no/tjenester/risk-advisory-services/cyber-security/sikkerhetsarkitektur.html)
- [PwC: Zero Trust-arkitektur: gjør det skyen din sikrere?](https://www.pwc.no/no/pwc-aktuelt/zero-trust-arkitektur.html)
- [Avoki: Implementere Zero Trust-arkitektur](https://www.avoki.com/no/kunnskap-innsikter/artikler/post/implementere-zero-trust-arkitektur/)
- [Serit: Zero Trust: En fremtidsrettet tilnærming til IT-sikkerhet](https://serit.no/zero-trust-en-fremtidsrettet-tilnaerming-til-it-sikkerhet/)

**Sist verifisert:** 2026-04-09
