8 mønstre for Zero Trust-attestering af IoT-enheder

Den første forudsætning for Zero Trust i IoT er en entydig, hardware-forankret identitet, der ikke kan kopieres eller udtrækkes af angribere. I praksis opnås det ved at placere nøglemateriale og kryptografiske operationer i en hardware root-of-trust (HRoT), som kun eksponerer sikre API’er til resten af systemet.

De fire mest udbredte hrot-teknologier

• TPM 2.0 (Trusted Platform Module)
  Industriens de-facto standard til pc’er, servere og avancerede gateways. Giver isoleret nøglelager, EK/SRK, PCR-registre og kommandoer til attestation.
• Secure Element (SE)
  Diskrete eller indbyggede kredse (fx Microchip ATECC608B, NXP SE050) med begrænset funktions­omfang men ultralavt strømforbrug. Perfekt til batteridrevne sensorer.
• PUF-baseret nøgleafledning
  Udnytter fysiske variationer i silicium til at generere nøgler “on the fly”, så der intet hemmeligt materiale eksisterer i hukommelsen mellem opstarter.
• DICE (Device Identifier Composition Engine)
  Et lagdelt koncept fra TCG, hvor hver boot-fase udleder en ny nøgle fra forrige måling (compound device identifier). Ideelt til simple MCU’er uden fuld TPM.

Etablering af identiteten: Fra silicium til certifikat

1. Produktions­øjeblikket
   Under fremstillingen klargøres HRoT med enten en fabriksindskrevet Endorsement Key (TPM) eller en selvgenereret root key (SE/PUF). Nøglen kan aldrig eksporteres.
2. Generation af enhedsnøgle
   En ECC- eller RSA-nøglepar genereres inde i HRoT og public key hentes ud som SubjectPublicKeyInfo.
3. Binding til certifikat
   Public key signeres af producentens CA og bliver til et X.509-certifikat. Overholder man IEEE 802.1AR kaldes dette et Initial Device Identity (IDevID).
4. Udrulning og ejerskifte
   Ved onboarding udstedes et nyt Locally Significant Device Identity (LDevID) fra organisationens egen CA via EST, BRSKI eller lignende protokol.

Hvorfor er hardware-rodfæstet identitet kritisk?

• Uforanderlighed - private keys kan ikke kopieres; klonede devices afsløres straks.
• Skalerbar tillid - X.509/IDevID indgår sømløst i eksisterende PKI’er, VPN’er og mTLS.
• Automatiseret livscyklus - nøgle­rotation, certifikatfornyelse og revokation kan ske uden fysisk adgang til enheden.
• Basis for attestering - HRoT signer målinger (PCR/RTMR) og gør dem ikke-afviselige overfor fjern-verifiers.

Bedste praksis og faldgruber

Design­checkliste til arkitekten

Før du går videre til næste Zero Trust-mønster, bør du kunne svare ja til:

• Har hver enhed en HRoT der er verificerbar via serienummer eller endorsement-certifikat?
• Er private nøgler non-exportable og beskyttet mod side-channel angreb?
• Understøtter din PKI både IDevID og automatisk LDevID-udstedelse?
• Er der defineret en plan for nøgle­rotation og secure decommission?

Når disse forudsætninger er på plads, står du med en solid, kryptografisk rygrad til resten af Zero Trust-stakken - fra sikker opstart til dynamisk adgangskontrol. Næste skridt er at bevise, at firmwaren der startes på denne identitet, også er til at stole på.

Robust Zero Trust-attestering starter længe før enheden går på netværket - den begynder i selve opstartsprocessen. Ved at kombinere Secure/Verified Boot og Measured Boot opnås både integritetskontrol og et kryptografisk bevis, som kan videresendes til en attesteringsinstans.

Fra firmware-rom til os: Sådan kædes tilliden

1. Immutable første­trins-kode (BL0) i ROM udgør den absolutte Root of Trust. Hash/firma­ware­nøgle er brændt ind via OTP/fuse.
2. Secure/Verified Boot i BL1 validerer digital signatur på næste komponent (BL2, DTB, kernel osv.). Fejler signaturen, stoppes boot eller der skiftes til recovery-billede.
3. Measured Boot eksekverer parallelt: hver komponent hashes og extendes ind i TPM 2.0 PCR’er (PCR 0-7) eller RTMR-registre (TEE/Arm CCA). Resultatet er en kronologisk log, som ikke kan ændres uden at nulstille enheden.
4. Når sidste led (OS/TEE) er oppe, udtrækkes PCR/RTMR-værdier og pakkes som evidence (f.eks. EAT token). Disse værdier sammenlignes senere med reference­målinger i et trust-anchor-database (CoRIM/CoSWID).

Forseglede målinger og bevistransport

• Sealing: Målinger kan bindes til en asymmetrisk nøgle parret med PCR-tilstand (TPM2_Create). Dermed bliver privキー ubrugelig, hvis bootkæden ændres - et effektivt anti-rollback-værn.
• Freshness & anti-replay: Verifier sender en nonce, som inkluderes i signaturen (Quote). Dermed garanteres, at evidensen stammer fra den aktuelle boot og ikke er genbrugt.
• Letvægts-transport: På MCU’er anvendes ofte COSE_Sign1 over EDHOC/OSCORE, mens gateways bruger klassisk TLS 1.3.

Fail-safe og recovery-strategier

Selv den bedste verifikation kan mislykkes; derfor anbefales:

• A/B-partitioner med health-markering og automatisk rollback ved boot-timeout.
• Golden-image i skrivebeskyttet flash som nød-fallback.
• Secure Boot-policy, der låser ved gentagne fejl og kræver autoriseret gendannelsesnøgle fra backend.

Designanbefalinger

1. Sørg for entydig målekæde: Hold hvert trin lille og deterministisk; selv ubetydelige forskelle (f.eks. tidsstempel i U-Boot) ændrer hash’en.
2. Standardiser PCR-mapping: Følg TCG’s IoT-profil eller PSA Certified-guidelines, så målinger kan parse’s automatisk på tværs af leverandører.
3. Log + signér eksterne udvidelser: FPGA-bitstreams, option-cards og konfigfiler bør indgå i chain of trust, ellers undermineres sikkerheden.
4. Test mod strømudfald: Interrupted firmware-opdatering skal ikke efterlade enheden i brick-state. Brug journaling-FS eller doubled-buffer writes.

Ved konsekvent at anvende Secure/Verified Boot og Measured Boot skabes en transparent, kryptografisk sporbar opstart, der kan demonstrere integritet til enhver tid - et helt centralt fundament under enhver Zero Trust-strategi for IoT-enheder.

For at gøre attestering af IoT-enheder interoperabel, kræver Zero Trust-modellen et fælles sprog og en fælles proces. Det leveres af IETF’s ”Remote Attestation Procedures” (RATS) og det tilhørende EAT-token (Entity Attestation Token). Tilsammen skaber de en standardiseret pipeline fra rå målinger på enheden til politik-baserede adgangsbeslutninger i skyen.

Rats-rollerne og deres samspil

1. Attester - selve IoT-enheden (eller dens TEE/TPM), der producerer Evidence.
2. Verifier - en tjeneste, der validerer evidensen mod Endorsements og Reference Values og udsteder et Attestation Result.
3. Relying Party - f.eks. en API-gateway, broker eller adgangskontrolmotor, der træffer endelig beslutning på baggrund af resultatet.

Ved at adskille rollerne kan man skalere attestering på tværs af tusinder af enheder uden at hver enkelt tjeneste behøver at forstå alle hardware-detaljer.

Eat - Det bærende beviserformat

• Serialiseres i CBOR og underskrives/-krypteres med COSE.
• Indeholder standard-claims som nonce, iat, ueid, oemid, hw_version, samt udvidelige ”sw-measurement”-claims.
• Kan transporteres i CWT-struktur (CBOR Web Token) eller som ”evidence bag” i en COSE-struktur, så både små sensorer og kraftigere gateways kan genbruge samme grammatik.

Endorsements & reference values

Verifieren skal kende ”hvad der er godt nok”:

• Endorsements: Kryptografiske beviser fra producenten - f.eks. chip-certifikater, OEM-manifester eller DICE-kæder.
• Reference Values: Godkendte firmware- og konfigur-hashes, der publiceres og signeres som CoRIM (Concise RIM) eller CoSWID (Software ID).

Med CoRIM/CoSWID kan leverandørerne udgive maskinlæsbare ”gode” målinger, som Verifieren automatisk kan slå op mod EAT-evidence.

Sikker transport - Fra sensor til sky

• TLS 1.3/mTLS for fulde TCP-stakke.
• DTLS 1.3 til UDP-baserede protokoller (CoAP, QUIC osv.).
• EDHOC + OSCORE når hver byte tæller - 3-vejs nøgleudveksling med under 1000 B overhead, hvorefter OSCORE beskytter CoAP-trafikken end-to-end.

Skalerbar verificering i praksis

• Batch- og cache-strategier: Verifieren kan cache valid EAT-evidens i få minutter for at reducere load ved højfrekvent rapportering.
• Streaming-mode: Ved store sensorflåder kan en MQTT-broker fungere som Relying Party og kræve Attestation Result som forbindelse-krav (CONNACK).
• On-prem/offline: En lokal Verifier kan fungere i fabrikshaller med intermitterende net, og senere ”synke” referenceværdier og revokationer mod centralskyen.

Med den fulde RATS-pipeline - EAT-evidence, verificering mod CoRIM/CoSWID og sikret transport - får organisationen et fælles attestations-grundlag, der kan integreres direkte i Zero Trust-politikker uden proprietære protokoller eller manuelle proces-huller.

I det klassiske IoT-setup bliver enheden kun attesteret én gang - under onboarding. Zero Trust-princippet dikterer derimod, at tillid er en flygtig tilstand, som skal (gen)etableres løbende. Kontinuerlig runtime- og posture-attestering sørger for, at både firmware, konfiguration og driftsparametre til enhver tid matcher de forventede referenceværdier.

Hvornår skal der re-attesteres?

• Periodisk: F.eks. hver 15. minut, én gang i døgnet eller efter SLA-krav.
• Hændelsesdrevet: Ved firmwareopdatering, konfigurationsændring, tilslutning af ny periferienhed, mærkbar afvigelse i sensordata, CPU-peak m.m.
• Adgangsudløst: Før adgang til et særligt følsomt API, et mikrosegment eller ved anmodning om privilegeret handling.

Udvidede claims - Ud over boot-målinger

EAT-tokenet bør nu bære et bredere sæt claims, der viser den aktuelle posture:

• Patch-niveau: Versions-/build-nr. og patch-komplians mod CoSWID/CoRIM.
• Konfigurationshash: Måling af kritiske filer, kernel-parametre, ACL’er osv.
• Runtime-integritet: Hash af running image, aktivt containersignatur eller TPM-PCR-udvidelser fra IMA.
• Sensor- og sundhedsdata: Temperatur, batteri, signalstyrke, hukommelsesforbrug, watchdog-status.
• Geolokation og netværkskontekst (valgfrit): GPS, Wi-Fi BSSID, SIM ICCID til detektion af flytning/tyveri.

Freshness, nonces og anti-replay

• Verifieren udsender en nonce eller en epoch_id, som skal inkluderes og signeres af Attester.
• Tidsstempel (iat) i EAT-tokenet muliggør tidsvindues-validering (clock drift ± 5 s).
• Tokens caches i en replay-cache; duplikater nægtes inden for konfigureret TTL.
• Optionelt kan one-time-keys (OTK) eller session-specifikke PCR-udvidelser bruges til at knytte attesteringen til en unik TLS-session.

Skalerbarhed i storflåder

Millioner af enheder kan ikke alle henvende sig direkte til den centrale Verifier. Følgende mønstre går igen:

1. Hierarkisk validering: Gateway/edge-noder samler og validerer attesteringer lokalt og sender kun aggregated results videre.
2. Delta-attestering: Kun claims der er ændret siden sidste godkendte måling sendes (redundans fjernes).
3. Cache-baseret “fast path”: Gentagne identiske målinger slår op i en accept-cache i Verifier (f.eks. Redis) og springer dyr kryptografisk verifikation over, hvis signaturen stadig er gyldig.

Fra posture til politik

Efter verifikation oversættes målingerne til risk scores eller kategoriske tags (f.eks. healthy, outdated-patch, tampered). En PDP anvender disse til at træffe dynamiske beslutninger:

• Read-only adgang til MQTT-broker, hvis patch-niveau er forældet.
• Karantænesegment, hvis runtime-integritet fejler.
• Step-up-attestering (ekstra nonce, længere måling) ved følsomme transaktioner.

Med kontinuerlig runtime- og posture-attestering opgraderes Zero Trust-kontrollen fra et øjebliksbillede til en real-time pulstagning på IoT-flåden, hvilket reducerer MTTD, forhindrer lateral bevægelse og sikrer, at kun enheder i verificeret god stand får adgang til kritiske ressourcer.

Efter attesteringsbeviset er valideret, skal resultatet omsættes til en dynamisk adgangsbeslutning - helst i real-tid og uden menneskelig indblanding. Her er det klassiske PDP/PEP-mønster (Policy Decision Point / Policy Enforcement Point) fundamentet, men udvidet med risk scoring og kontekst-data fra hele økosystemet.

Pipelines for beslutnings­processen

1. Indsamling af claims
   Verifieren udstiller et signeret “attestation result” (fx et EAT-token). Tokenet sendes til PEP’en (API-gateway, service-mesh sidecar, SDN-switch …).
2. Kontekst-berigelse
   PEP’en slår supplerende attributter op - enhedsejer, forretningskritikalitet, sensitivitet - i CMDB, MDM eller asset-register og pakker alt i et policy-request.
3. Policy-evaluering
   PDP’en (Rego/OPA, XACML, Cedar e.l.) matcher attributter mod policies og beregner en risikoscore. Enheder kan tildeles “grøn”, “gul” eller “rød” posture.
4. Handling
   Resultatet sendes retur til PEP’en, der håndhæver beslutningen: tillad, read-only, karantæne, eller kræv step-up (fx firmware-patch eller menneskelig godkendelse).

Eksempel på claim-til-handling-mapping

Risk-adaptive kontroltrin

• Step-up access - kræv ekstra attestering, firmware-opdatering eller OOB-godkendelse fra driftsansvarlig.
• Karantæne - flyt enheden til isoleret VLAN/segment, hvor kun patch-servere er tilgængelige.
• Read-only - tillad kun telemetri, ingen styringskommandoer.
• Graceful degradation - throttling eller begrænsning af API-rate, når risikoniveau stiger.

Integration med drift og devsecops

Beslutninger må aldrig ende i et “silo-vacuum”. Derfor bør PDP’en udsende events til:

• ITSM / ticket-system (ServiceNow, Jira): automatisk opgave når enhed havner i karantæne.
• SIEM/SOAR: korrelation med øvrige hændelser og playbooks til automatisk patch-push.
• CI/CD-pipelines: blokér deployment af ny microservice, hvis afhængige sensorer ikke består attestering.

Skalerbarhed og ydeevne

Millioner af IoT-enheder kræver cache-venlig og stateless arkitektur:

• PEP’en kan cache short-lived policy-beslutninger (5-10 min) for at reducere latency.
• Brug incrementelle attesterings-claims: send kun forskelle siden sidste check.
• Segmentér policies pr. enhedsklasse (sensor, actuator, gateway) for at begrænse regelsætstørrelsen.

Eksempel på rego-policy (open policy agent)

package iot.accessdefault allow = "deny"allow = "allow" { input.measured_boot == "OK" input.fw_version >= "1.4.0" input.patch_level >= input.current_patch - 1}allow = "readonly" { input.measured_boot == "OK" risk_score := risk(input) risk_score >= 50}allow = "quarantine" { input.measured_boot == "FAIL"}# Simple riskscore helperrisk(i) = score { score := (i.vuln_count * 10) + (100 - i.battery_level)}

Rego-eksemplet illustrerer, hvordan attestations-claims (measured_boot, fw_version etc.) kombineres med dynamiske kontekst-faktorer (battery_level, vuln_count) for at skabe fleksible og let versionerbare policies.

Nøgletakeaways

1. Brug attestationsdata direkte som attributter i ABAC-politikker.
2. Sæt risk-adaptive kontroller op som automatiserede “guard-rails”, snarere end manuelle undtagelser.
3. Integrér med CMDB/MDM og DevSecOps-processer, så politik-ændringer udrulles lige så hurtigt som kode.
4. Sørg for løbende review og test af policies - et forkert match kan lamme hele produktionslinjen.

Zero Trust-visionen dikterer, at kryptering og adgangskontrol knyttes til den enkelte enheds identitet - ikke til IP-adresse eller placering i netværket. Det opnås ved at udstede unikke certifikater eller identiteter til hver IoT-node og lade dem autentificere sig indbyrdes via mutual TLS (mTLS) eller tilsvarende letvægts­protokoller.

Mtls med enhedscertifikater og spiffe-id’er

• Udnyt de X.509-certifikater, der allerede er genereret under hardware-rodfæstet identitet, som Device Certificates i en mTLS-håndtryk.
• Standardiser identitetsformatet med SPIFFE (Secure Production Identity Framework For Everyone), og automatisér udstedelse/rotation via SPIRE server og agenter.
• Indfør server name indication (SNI) baseret på SPIFFE-URI’en (fx spiffe://acme.dk/device/sensor-1234) for at muliggøre finmasket politikmatch i gateways og service mesh.
• Beskyt private nøgler ved at holde dem in-hardware (TPM, Secure Element) - så selv kompromitterede OS’er ikke kan eksportere dem.

Letvægtskryptering til constrained enheder

Ikke alle IoT-enheder kan løfte det fulde TLS-/X.509-overhead. Her giver IETF’s COSE-baserede protokoller en stærk løsning:

• OSCORE (Object Security for Constrained RESTful Environments) beskytter CoAP-pakker ende-til-ende med AEAD-kryptering, helt ned til 6LoWPAN-niveau.
• EDHOC (Ephemeral Diffie-Hellman Over COSE) etablerer sessionsnøgler med færre bytes end et klassisk TLS-handshake; perfekt til NB-IoT/LoRa WAN.
• Begge protokoller kan bindes til enhedens hardware-root-key eller IDevID, så de samme identitetspointre anvendes på tværs af TLS og COSE.

Mikrosegmentering: Begræns tillidens radius

Når alle noder har en entydig identitet, kan trafikken segmenteres logisk efter princippet “least privilege” i stedet for traditionelle VLAN-grænser:

• SDN/SD-WAN: Brug controlleren til at udvide policies (ACL’er, QoS, IPS) baseret på SPIFFE-labels snarere end IP-net.
• Service mesh (Istio, Linkerd, Kuma): Injicér sidecars, der automatisk håndhæver mTLS, deny-by-default og certifikatrotation for edge-gateways og kraftigere Linux-noder.
• Protokolspecifik isolation:
  • MQTT: Mapper certifikat-SAN eller SPIFFE-URI til topic-wildcards; tillad kun sensors/+/telemetry og bloker $SYS/#.
  • CoAP: Brug OSCORE Context ID som segment-tag; kun noder med samme ID kan dele payloads.
  • AMQP 1.0: Indfør vHosts pr. applikationsdomæne og bind ACL’er til klientcertifikatets tenant-claim.
• Nul-tillid til management-porte: Isolér OTA-opdatering og device management i egne segmenter med strengere policies (fx “kun EST-trafik, ingen MQTT”).

Praktiske designråd

1. Etabler én Certificate Authority - eller en hierarkisk CA-struktur - der taler både EST/ACME (mTLS) og EDHOC-cert-formats.
2. Skab policy-as-code i Git, så SDN-flowregler og mesh-AuthorizationPolicies versioneres og testes automatisk.
3. Overvåg segmentgrænserne: eksportér flow logs til SIEM og korrelér dem med attestationsdata for at opdage afvigelser i realtid.
4. Planlæg graceful degradation: hvis CA eller SPIRE er nede, tillad kun cachede certifikater i en begrænset periode med nedsat funktionalitet.

Ved konsekvent at koble kryptering til identitet og lade mikrosegmentering håndhæve mindste-rettighed på protokolniveau, skabes et robust Zero Trust-fundament - selv for de mest begrænsede IoT-enheder og de mest komplekse edge-miljøer.

Zero Trust-­modellen stopper ikke ved onboarding. Hvis forsyningskæden kompromitteres, eller firmware ikke kan spores hele vejen fra build-server til enhed, falder hele sikkerhedsantagelsen til jorden. Derfor skal hver eneste artefakt i enhedens livscyklus kunne attesteres, verificeres og - når tiden er inde - bortskaffes sikkert.

Sbom som grundlæggende krav

• Software Bill of Materials (SBOM) i formaterne SPDX eller CycloneDX skal medleveres ved første levering og ved hver firmwareopdatering.
• Hash-summer over komponenterne indgår som referenceværdier, der kan matches mod CVE-databaser eller en intern Vulnerability Exchange (VEX).
• SBOM'en versioneres og signeres, så den kan sendes videre som en endorsement til attesterings-verificatoren (jf. RATS-modellen).

Signerede firmware-pakker & sikre ota-processer

• Al firmware signeres med en hierarkisk nøglekæde forankret i enhedens hardware-root-of-trust (TPM, Secure Element m.fl.).
• Brug The Update Framework (TUF) til at beskytte metadata (root/targets/snapshot/timestamp-nøgler) og Uptane til miljøer med offline ECUs eller gateway-opdateringer.
• For container-baserede workloads kan Sigstore/cosign sikre, at både container-image og attestationsdata (Rekor log) er uforanderlige.
• Over-the-air (OTA) kan køres via HTTPS, CoAP+OSCORE eller MQTT+TLS; selve opdateringsklienten validerer både signatur og versionsnummer før installation for at forhindre downgrade-angreb.

Nøgle- og certifikatlivscyklus

• Provisionering: Enheden kommer med en fabriks-IDevID; under onboarding udstedes en operationel LDevID via EST, EST-coaps eller ACME/IOT-profile.
• Rotation & fornyelse: Certifikater kan være kortlivede (f.eks. 24-48 timer) for at reducere behovet for CRL’er. En sikker agent trigger automatisk fornyelse inden udløb.
• Revokation: Benyt OCSP (eventuelt stapling) for online-enheder. Til intermitterende devices kan man udsende delta-CRL’er eller gøre brug af short-lived certs + “grace period”.
• Nøgler ligger i hardware-beskyttet lager; ved hver firmwareopdatering verificeres, at nøgleattributter (eksempelvis “neverExtractable”) stadig er intakte.

Sikker afvikling & datasletning (decommission)

• Når enheden skal tages ud af drift, initieres en remote wipe-procedure, der først fjerner applikationsdata, derefter nøgler (TPM Clear) og til sidst SBOM/firmware-metadata.
• Sletningen kvitteres med et attestationsbevis, som sendes til CMDB/asset-systemet som dokumentation for compliance (f.eks. GDPR eller NIS2).
• I cirkulære forretningsmodeller kan enheden derefter reprovisioneres med ny IDevID eller destrueres efter secure erase af flash-lagre.

Ved at kombinere sporbarhed (SBOM), kryptografisk integritet (signerede artefakter) og automatiseret nøgle­hygiejne får organisationen end-to-end bevis for, at både kode og hardware er til at stole på - fra fabrikslinjen til skrotpladsen.

Når tusindvis af IoT-enheder skal attesteres og onboardes på tværs af fabrikker, butikker eller bygninger, er det ineffektivt at lade hver enkelt enhed etablere en fuldTLS-session, sende EAT-tokens og forhandle protokoller direkte med en cloud-baseret Verifier. En edge-mægler fungerer som en lokal “proxy for tillid”, der:

• Validerer proof-of-attestation tæt på kilden og slipper kun godkendte enheder igennem.
• Terminere tunge kryptografiske protokoller (TLS/DTLS/EDHOC) for at spare batteri og CPU på sensorer.
• Mapper proprietære eller lave-niveau claims til et standardiseret, skyvenligt EAT-format.
• Bufferer og genudsender beviser ved afbrudte forbindelser - afgørende for edge-scenarier med ujævn dækning.

Arkitektur i praksis

1. Enhed → Edge-mægler
   Sensoren bootstrappes med sin IDevID (IEEE 802.1AR fabrikscertifikat) og sender en BRSKI-anmodning (RFC 8995) sammen med en EAT-token. Mægleren kontrollerer signaturer og målinger mod lokale referenceværdier.
2. BRSKI MASA-interaktion
   Hvis fabrikscertifikatet ikke er kendt lokalt, kontakter mægleren Manufacturer Authorized Signing Authority (MASA) for at få et “voucher artifact”, der beviser ejerforhold og konfigurationspolitik.
3. EST-proxy
   Når identiteten er valideret, oversætter mægleren BRSKI-flows til Enrollment over Secure Transport (EST) og udsteder et LDevID (lokalt certifikat) til enheden - evt. via offline-voucher, hvis der ingen netforbindelse er.
4. Claim-normalisering
   Rå målinger (PCR-hashes, firmware-versioner, SBOM-hash osv.) pakkes i et CBOR-encoded EAT og signeres/forsegles af mægleren med sin egen trust-anchor, inden data sendes videre til Verifier/Policy-motoren i skyen.
5. Policy-beslutning → Edge-mægler
   Skyen returnerer en access-token/policy, som mægleren håndhæver via lokale PEP-kontroller (SDN-flow, MQTT-ACL, firewall-regler, API-gateway).

Automatisering i stor skala

• Zero-Touch Onboarding: Nye enheder plug-and-play - mægleren kender fabriks- og ejerpolitik via MASA-voucher og behøver ingen manuel CLI-konfiguration.
• Sertifikat-livscyklus: Mægleren kører EST “simple re-enroll” til cert-fornyelse, OCSP-stapling for revocation, og nøgle-rotation kan skemalægges i batches.
• Offline/Intermitterende net: Voucher-cache, EST-slevesignede burst-certifikater og store-and-forward af EAT-evidence giver robusthed i miner, skibe og landzoner.
• Horisontal skalering: Flere mægler-noder kan indgå i et mesh med delt trust-store, eventuelt med k8s DaemonSets eller SD-WAN-appliances.

Designovervejelser og best practices

1. Least privilege: Edge-mægleren skal kun have de certifikater og vouchers, der er nødvendige for sin site-scope.
2. Hardening: Kør i TEE/SEV eller container-sandboxes, brug immutabel OS og TPM-baseret selv-attestering af mægleren.
3. Observability: Eksportér attestations-metrics (antal voucher-forespørgsler, failed EAT, cert-rotation) til SIEM/Prometheus.
4. Fallback-strategi: Definer hvad der sker, når MASA er nede - midlertidig karantæne, read-only eller nød-whitelisting.

Med en veldesignet edge-mægler kan organisationer opnå “trust-at-scale” - uden at drukne hverken sky-infrastruktur ellerlav-power-enheder i unødvendig kompleksitet, samtidig med at Zero Trust-principperne efterleves hele vejen fra fabrik til sky.