Edge Computing Security Guide: Nodes, Identity, Boot

Edge computing moves workloads, data and credentials out of the data centre and onto hundreds or thousands of small nodes that sit in shops, factories, vehicles, cell sites and street cabinets, where nobody can guard them. Each node is a miniature data centre with a hypervisor or container runtime, local storage, a management agent and a credential that lets it talk back to the cloud. Losing one node to theft or tampering should be an inconvenience, not a route into the whole estate. This guide covers the edge compute layer: gateways, micro data centres, lightweight Kubernetes clusters and IoT runtimes that run your code close to devices. It is written for platform, infrastructure and security engineers designing or operating an edge fleet. Network perimeter appliances such as VPN concentrators and firewalls are covered separately in the Edge Device Security Guide, and constrained sensors in the IoT Security Guide.

Key takeaways

Assume physical access. Design every edge node on the basis that someone will eventually hold it, image its disk and probe its ports, so keys belong in a TPM or secure element and disks must be encrypted with keys bound to measured boot.
Identity is the control plane. Each node and each workload needs its own hardware-anchored, short-lived identity; a shared fleet credential turns one stolen box into a fleet compromise.
Trust what you can measure. Remote attestation (IETF RATS, RFC 9334) lets the cloud decide whether a node booted known-good firmware and software before it receives secrets or workloads.
Onboarding is where most fleets are weakest. Zero-touch onboarding such as FIDO Device Onboard (FDO) replaces passwords typed by field technicians with cryptographic ownership transfer.
Plan for disconnection and recovery. Nodes must fail safe when offline, apply signed updates atomically with rollback, and be revocable and re-imageable remotely.

What makes edge computing different

Edge computing shares the technology stack of the cloud (Linux, containers, Kubernetes, service meshes) but strips away the assumptions that make cloud security manageable. The table compares the two.

Property	Cloud or data centre	Edge node	Security consequence
Physical security	Guarded halls, controlled access	Shop back office, roadside cabinet, vehicle	Theft, disk imaging, debug port access and hardware implants are realistic
Scale and heterogeneity	Few large, uniform hosts	Thousands of small nodes, mixed hardware generations	Inventory drift, uneven patch levels, many firmware variants
Connectivity	Always on, high bandwidth	Intermittent, metered, sometimes satellite or cellular	Updates and revocation are delayed; local decisions must be safe without the cloud
Operators on site	Trained staff	Contractors or none	Onboarding and repair cannot rely on technicians handling secrets
Trust boundary	Behind layered network controls	Often on untrusted or shared networks (retail Wi-Fi, carrier MEC)	Every connection must be mutually authenticated and encrypted
Data	Centralised, well classified	Raw video, telemetry and personal data processed locally	Local retention, encryption and deletion rules are needed per site

Edge deployments usually fall into three tiers: device edge (gateways and controllers next to sensors), on-premises edge (a small cluster in a store, plant or hospital) and network or provider edge (compute hosted by a telecoms operator, such as ETSI Multi-access Edge Computing (MEC) platforms). The controls below apply to all three, with the weight shifting from physical protection at the device edge to tenant isolation at the provider edge. For the mobile network side, see the 5G Security Guide.

Threat model for edge fleets

Map threats to the controls that actually stop them. ATT&CK and ATLAS identifiers below were checked against ATT&CK v20 and ATLAS 5.6.0.

Threat	ATT&CK technique	Primary controls
Stolen node, disk imaged for credentials	T1552.004 Private Keys	Keys non-exportable in TPM or HSM; full-disk encryption sealed to boot measurements; remote revocation
Malicious peripheral or implant on site	T1200 Hardware Additions	Disable unused USB and debug interfaces, tamper-evident enclosures, port allow-listing
Modified bootloader or firmware	T1542.001 System Firmware; T1495 Firmware Corruption	Secure boot, measured boot, NIST SP 800-193 protection, detection and recovery
Exposed management API or dashboard	T1190 Exploit Public-Facing Application; T1133 External Remote Services	No inbound management; outbound-only agents; mTLS; patch cadence
Poisoned container image or update	T1195.002 Compromise Software Supply Chain; T1525 Implant Internal Image	Signed images and updates, admission policy, provenance checks
Container breakout on a shared node	T1611 Escape to Host	Pod Security Admission "restricted", no privileged pods, read-only root filesystems
Reuse of a fleet-wide credential	T1078 Valid Accounts	Per-node and per-workload identity, short lifetimes, anomaly detection on cloud APIs

The Tesla Kubernetes cryptojacking incident shows the last two rows in combination: an administration console without a password exposed cloud credentials stored inside a pod, which the attackers used for mining. Edge clusters repeat that pattern at scale when dashboards are left reachable and pods hold long-lived cloud keys.

Hardware root of trust, secure boot and attestation

Everything else rests on the node being able to prove what it is and what it is running.

Hardware root of trust: select hardware with a discrete or firmware TPM 2.0 (ISO/IEC 11889) or, for constrained devices, a secure element or the Trusted Computing Group's Device Identifier Composition Engine (DICE), which builds a unique cryptographic identity for resource-constrained devices from minimal hardware. Microsoft's Azure IoT Edge security framework names TPM, DICE, TrustZone and SGX as acceptable roots of trust for physically exposed devices.
Secure boot and measured boot: secure boot refuses unsigned boot components; measured boot records hashes of each stage into TPM Platform Configuration Registers so a verifier can see what actually ran. You need both: secure boot blocks known-bad code, measured boot proves the chain to someone remote.
Firmware resiliency: NIST SP 800-193 Platform Firmware Resiliency Guidelines set three principles: protection against unauthorised change, detection of change that does happen, and recovery to a known-good state. For an unattended node, recovery (a protected golden image and a watchdog that falls back to it) matters as much as prevention. See the Firmware and Boot Security Guide.
Protect the signing keys: secure boot is only as strong as the vendor's signing key custody. The MSI signing keys leak exposed firmware and Intel Boot Guard private keys for more than 100 products, and keys fused into deployed hardware are hard to revoke. Ask suppliers how firmware signing keys are held and how revocation works before you buy.
Remote attestation: RFC 9334 (IETF RATS architecture, January 2023, Informational) defines the roles: the Attester (the edge node) produces Evidence, a Verifier appraises it against Reference Values and Endorsements from the manufacturer, and a Relying Party (your secrets service or orchestrator) acts on the Attestation Result. In the passport model the node carries its result to relying parties; in the background-check model the relying party forwards Evidence to the verifier. Gate secret release and workload scheduling on a fresh, passing result.

Node and workload identity

Edge fleets are non-human identity estates: every gateway, cluster agent, container and update client holds a credential. Treat them with the same lifecycle discipline as cloud service accounts. See the Device and IoT Identity Guide and the Identity for IoT Fleets Guide.

Unique, hardware-held node keys: generate the private key inside the TPM or HSM so it never exists in software. AWS IoT Greengrass v2, for example, stores the core device's private key and X.509 certificate in an HSM or TPM through its PKCS#11 provider component (aws.greengrass.crypto.Pkcs11Provider), referencing them as pkcs11:object=...;type=private URIs; its documentation recommends generating keys on the HSM's own random number generator and marking them non-exportable. Check each platform's limits: Greengrass notes, for example, that its local Moquette MQTT broker key cannot be held in the HSM.
Workload identity, not baked-in secrets: issue short-lived identities to workloads after attesting the node and the workload. In SPIFFE/SPIRE, the agent on each node proves the node's identity to the server using node attestors (cloud instance identity documents, hardware-backed keys, Kubernetes service account tokens or single-use join tokens), then attests local workloads by process, user or Kubernetes selectors and hands out X.509 or JWT SVIDs over a local Unix socket. See the SPIFFE and SPIRE Guide.
Federate to the cloud: exchange the node or workload identity for short-lived cloud tokens instead of storing access keys on disk. See the Cloud Workload Identity Guide.
Revocation that works offline: short certificate lifetimes (hours to days) are more reliable at the edge than CRL or OCSP checks that need connectivity.

Zero-touch onboarding

Field onboarding is where shared passwords, USB sticks with configuration files and default credentials creep in. FIDO Device Onboard (FDO 1.1, FIDO Alliance Proposed Standard, April 2022) addresses this with late binding: the device is manufactured once and the owner chooses the management platform when it is installed.

FDO step	Who runs it	What happens	What to check
DI (Device Initialize)	Manufacturer, in the factory	Installs initial credentials and a GUID, and starts the ownership voucher	Supplier controls over the factory step; voucher delivery to you with the order
Ownership voucher transfer	Each party in the supply chain	Voucher, a chain of signed public keys, is extended to the next owner	That the final entry is your owner key before deployment
TO0	Owner	Registers the device GUID with a Rendezvous Server for a limited time	Registration only for devices you expect to install
TO1	Device	Contacts the Rendezvous Server to learn where its owner is	Rendezvous is trusted only to store the mapping, not to authorise
TO2	Device and owner	Mutual authentication; owner replaces device credentials and passes management configuration	Credential replacement is mandatory; log the onboarding event

Where FDO is not supported, platform-specific provisioning (for example, a device provisioning service with TPM or X.509 attestation) achieves a similar outcome. The rule is the same: no human should type or carry a secret to make a node join the fleet.

Hardening the edge runtime

Most on-premises edge clusters run a lightweight Kubernetes distribution. The K3s hardening guide is a useful concrete reference because it maps to CIS Kubernetes Benchmark items; equivalent settings exist in other distributions. See the Kubernetes Security Guide for the full cluster picture.

Kernel and host: set protect-kernel-defaults: true so the kubelet refuses to start if kernel parameters differ from expected values, and apply the required sysctls (for example kernel.panic_on_oops=1, vm.overcommit_memory=1) from /etc/sysctl.d/90-kubelet.conf. Use a minimal, preferably immutable, host OS with an A/B partition scheme.
Secrets at rest: enable secrets-encryption: true so Kubernetes Secrets are encrypted in the datastore, and combine it with full-disk encryption sealed to the TPM so a stolen disk yields nothing.
Pod security: configure Pod Security Admission with enforce, audit and warn all at restricted, exempting only system namespaces. This blocks privileged pods, host namespaces and privilege escalation, which are the usual container breakout paths.
Admission and API server: enable the NodeRestriction and EventRateLimit admission plugins, set service-account-extend-token-expiration=false, and set automountServiceAccountToken: false on default service accounts. See the Kubernetes Service Account Token Guide.
Audit logging: enable API server audit logs (K3s example: audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log, audit-log-maxage=30, audit-log-maxbackup=10, audit-log-maxsize=100) and forward them when connected.
Network policy: default-deny NetworkPolicies in every namespace, with explicit allows for DNS (TCP and UDP 53) and ingress controllers. The K3s guide notes CIS requires a policy in every namespace, so new namespaces need one too. See the Network Segmentation Guide.
Certificate files: tighten permissions on cluster PKI material (the K3s guide sets chmod 600 on server TLS certificates, whose defaults are 644).
Image pull policy offline: the K3s guide notes AlwaysPullImages can break air-gapped or pre-loaded clusters; rely on image signature verification at admission rather than forced pulls.

Connectivity, updates and data handling

Outbound-only management: agents should dial out to the control plane over mutually authenticated TLS (TCP 443 or MQTT over TLS on 8883). No inbound SSH, RDP or web consoles from the internet. Remote support goes through a brokered, recorded, time-limited session.
Signed, atomic updates: sign OS images, container images and configuration; verify on the node before applying; use A/B partitions or transactional updates with automatic rollback if health checks fail after reboot. Stage rollouts in rings (lab, pilot sites, 10 per cent, full fleet). See the Patch Management Guide.
Software inventory: keep an SBOM per image so you can answer "which sites run the vulnerable library" in minutes. See the SBOM Guide.
Local secrets: deliver secrets only after attestation, keep them in memory or TPM-sealed storage, and scope them to the site. The AWS Greengrass secret manager, for instance, uses the device's hardware-protected key to decrypt deployed secrets. See the Secrets Management Guide.
Data minimisation: process raw video or personal data locally, send only derived results upstream, and set retention limits on local buffers. Encrypt local data at rest; Microsoft's IoT Edge framework recommends BitLocker on Windows edge hosts and leaves Linux options to the operator.
Offline behaviour: define what each node may do when disconnected (for example continue serving cached policy for 72 hours, then stop accepting new workloads) so a cut cable cannot be used to extend a revoked node's life indefinitely.

Choosing an approach

Situation	Recommended pattern	Trade-off
Fewer than 50 sites, one hardware model	Managed edge runtime from your cloud provider, TPM-backed device certificates, provider OTA	Quick to run; ties you to one provider's onboarding and update model
Hundreds of sites, mixed hardware	Lightweight Kubernetes, GitOps for configuration, SPIFFE-style workload identity, FDO or equivalent onboarding	More engineering effort; portable and consistent across vendors
Hosting on telecom provider edge (MEC)	Treat as multi-tenant cloud: confidential computing where available, strict tenant isolation, own key management	Less physical risk, more dependence on the provider's isolation. See the Confidential Computing Guide
Safety-relevant OT sites	Edge node in a dedicated zone between OT and IT, one-way data flows where possible, change windows agreed with operations	Slower updates; required by OT safety constraints. See the OT Security Guide

Implementation roadmap

Inventory and classify: list every edge site, node, hardware model, firmware version and credential type. Mark which nodes hold personal data or reach OT networks.
Fix the identity foundation: move node keys into TPM or HSM, remove shared fleet credentials, and replace long-lived cloud access keys on nodes with federated short-lived tokens. Test on lab hardware first.
Turn on secure and measured boot in audit mode: collect measurements across the fleet to build reference values before enforcing, because firmware variance will otherwise lock out good nodes.
Introduce attestation gates for secret release on a pilot ring of 5 to 10 sites; keep a documented override (a break-glass approval) so a verifier outage does not stop the business.
Harden the runtime to CIS-aligned settings in a staging cluster, run workloads for a week, then roll out by ring with automatic rollback.
Adopt zero-touch onboarding for all new hardware purchases: require FDO vouchers or equivalent in procurement contracts.
Close the loop with monitoring, quarterly re-attestation reviews and a tested "lost node" procedure (revoke identity, wipe remotely, rotate any site-scoped secrets).

Detection and measurement

What to log: attestation results and failures, boot measurement changes, enclosure tamper switches, USB insertion events, Kubernetes audit events (new privileged pods, RoleBinding changes, exec into pods), update success and rollback, and cloud API calls made with each node's identity.
Useful alerts: a node identity used from an unexpected IP or region; a node that stops reporting for longer than the agreed offline window; a measurement that matches no reference value; outbound connections to destinations outside the allow-list.

Metric	Target
Nodes with hardware-held, non-exportable identity keys	100 per cent of new nodes; legacy plan with a date
Nodes passing attestation in the last 24 hours	Above 98 per cent, with every failure triaged
Median time to apply a critical update across the fleet	Within the patch policy window (for example 14 days)
Long-lived cloud access keys stored on nodes	Zero
Time from "node reported lost" to identity revoked	Under 1 hour
Update rollbacks per release	Tracked per ring; rising rates halt the rollout

Common failure patterns

One credential for the whole fleet: a shared certificate or API key baked into the golden image. Extracting it from one stolen box gives access as every node.
Secure boot without key custody: trusting vendor firmware signing without asking how keys are protected and revoked, as the MSI leak illustrates.
Management consoles reachable from the network: Kubernetes dashboards, container runtime APIs or vendor web UIs left open on site networks, as in the Tesla incident.
Attestation in report-only mode forever: measurements are collected but never used to block secret release, so a tampered node still gets everything.
Unencrypted local buffers: camera footage or transaction queues written in clear to SD cards or local disks that leave the site during repairs.
Updates without rollback: a bad update bricks remote nodes, so teams start delaying updates and the fleet drifts out of patch compliance.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Fleet inventory	ID.AM-01, ID.AM-02	CM-8	1, 2	A.5.9
Device and workload identity	PR.AA-01, PR.AA-03	IA-3, SC-12	5, 6	A.5.16, A.8.24
Boot and firmware integrity	PR.PS-01	SI-7, SI-7(15), CM-14	4	A.8.9
Data at rest on nodes	PR.DS-01	SC-28	3	A.7.9, A.8.1
Runtime hardening and isolation	PR.PS-01	CM-7, SC-39	4	A.8.9
Network boundaries	PR.IR-01	SC-7, AC-4	12, 13	A.8.20, A.8.22
Supply chain and updates	GV.SC-05, PR.PS-02	SR-3, SR-4, SR-11	2, 7	A.5.21, A.8.8
Monitoring	DE.CM-09	SI-4	8, 13	A.8.15, A.8.16

NIST IR 8259A sets a baseline of device cybersecurity capabilities (device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness) that is a useful procurement checklist for edge hardware.

Practitioner checklist

Every edge node has a unique identity key generated and held in a TPM, HSM or secure element.
No long-lived cloud access keys or shared fleet credentials are stored on nodes or in images.
Secure boot and measured boot are enforced, with reference values maintained per hardware and firmware version.
Secrets and workloads are released only to nodes with a fresh, passing attestation result.
New hardware is onboarded with FDO or an equivalent zero-touch, credential-replacing process.
Runtime is hardened to CIS-aligned settings: restricted pod security, secrets encryption, audit logs, default-deny network policy.
Management is outbound-only over mutual TLS; no inbound consoles reachable on site or internet networks.
Updates are signed, staged in rings and roll back automatically on failed health checks.
Local data is encrypted at rest with TPM-sealed keys and has a defined retention limit.
A tested lost-node procedure revokes identity within an hour and rotates site-scoped secrets.

Edge Computing Security Guide: Securing Distributed Compute and Devices