Edge Computing Explained: Architecture, Use Cases and Security

Edge computing means running compute and decision logic close to where data is produced, on a device, a server in a store or factory, or a telecom site, instead of a distant cloud region. Teams do it for latency, bandwidth, privacy and offline operation. The price is a fleet of small, exposed computers you must update and trust.

This guide covers how NIST and ETSI define the edge, how edge differs from fog and cloud, the architecture layer by layer, use cases in retail, manufacturing, telecom and vehicles, orchestration with K3s, KubeEdge and LF Edge projects, offline operation, fleet updates, and security from physical access to IEC 62443. It ends with a step by step build of a small, air gapped edge site. For a shorter primer, see What is edge computing and what are its security risks?.

Key takeaways

• There is no single definition of "edge". NIST SP 500-325 (March 2018) treats edge computing as the layer of end devices and places fog computing between those devices and the cloud. ETSI's Multi-access Edge Computing (MEC) means virtualised infrastructure "in or close to the network edge" of a telecom operator.
• Edge is a placement decision, not a product. The same container can run in a cloud region, a MEC host, an on premises server or a gateway. Choose by latency, bandwidth, data residency, offline needs and how many sites you can operate.
• Lightweight Kubernetes is the common orchestration layer. K3s documents 2 cores and 2 GB of RAM for a server and 1 core and 512 MB for an agent. KubeEdge, CNCF graduated since 11 September 2024, keeps the control plane central and stores edge metadata locally.
• Offline is the normal case. Design workloads to start, run and log without the cloud, then reconcile later.
• Fleet updates are the hardest operational problem. Pin versions, roll out in rings, limit concurrency and keep a rollback path.
• Physical access changes the threat model. Secure boot, measured boot, disk encryption and short lived identities matter more at a store than in a locked data hall.
• Sign everything that moves, and verify on the device. The Update Framework (TUF) and Uptane describe how to survive a compromised update server.
• Industrial edge means IEC 62443, from asset owner programmes (62443-2-1) to secure product development (62443-4-1).
• The software supply chain is the part you control most. Fixing a vulnerable image before it ships to hundreds of sites is far cheaper than after.

Timeline: how edge computing was standardised

Dates come from the primary documents we fetched. ISA years are edition years, not necessarily first publication.

The security guidance and the platform work matured in parallel, and the industrial standards came first: 62443 parts existed years before "edge" became a cloud term.

What is edge computing, according to NIST and ETSI?

The NIST view: edge, fog and mist

NIST SP 500-325, the Fog Computing Conceptual Model, is the clearest public attempt to pin the words down. Its Annex A says that, for the purpose of the document, edge computing is "the network layer encompassing the end devices and their users", providing local computing on a sensor, meter or similar network accessible device. It notes this peripheral layer is often called the IoT network.

Fog computing is a layered model of fog nodes, physical or virtual, sitting between smart end devices and centralised cloud services. NIST lists the attributes fog nodes need: autonomy (making local decisions), heterogeneity, hierarchical clustering, manageability and programmability, and stresses low latency from being co located with the devices. Mist computing is a lightweight form of fog in the network fabric, using microcomputers and microcontrollers, such as a sensor hub that filters readings.

The distinction NIST draws is that fog is hierarchical and also covers storage, control and processing acceleration, while edge computing "tends to be limited to a small number of peripheral devices". NIST says fog is not a mandatory layer.

The ETSI view: Multi-access Edge Computing

ETSI's Industry Specification Group for Multi-access Edge Computing approaches the edge from the telecom side. ETSI GS MEC 003 V3.2.1 (April 2024) says MEC enables applications as software only entities that run on a virtualisation infrastructure "located in or close to the network edge". The framework groups entities into system level, host level and network level.

A MEC host contains a MEC platform plus a virtualisation infrastructure providing compute, storage and network. Host level management covers the MEC platform manager and the virtualisation infrastructure manager; system level management centres on the MEC orchestrator. Applications reach the platform over the Mp1 reference point for service registration and discovery, traffic and DNS rules, persistent storage and time of day. ETSI also defines services only an operator can offer: Radio Network Information (radio conditions) and Location (where served devices are), both for authorised applications. MEC can also run inside an NFV environment, with the platform as a virtualised network function.

Which definition should you use?

For a factory or retail system, NIST's device, fog and cloud layering maps to sensors, a site server and a cloud region. If you buy low latency compute from a mobile operator, you are buying ETSI style MEC. Many systems use both.

One terminology warning: some government advisories use "edge device" for perimeter appliances such as firewalls and VPN gateways. That is a different topic, though the lesson overlaps: exposed, long lived boxes are hard to patch.

Edge vs fog vs cloud: what is the difference?

Going down the table buys capacity and operational maturity at the cost of network dependence. Going up buys speed and independence at the cost of managing many small computers in places you do not control.

Edge computing architecture, layer by layer

A useful mental model has five layers. Each one has its own failure modes and its own security controls.

1. Devices and sensors

Cameras, PLCs, meters, robot controllers and vehicle ECUs produce the data, often over Modbus, OPC UA, MQTT or CAN rather than HTTP. Many cannot run containers. NISTIR 8259A (May 2020) defines a core baseline of device cybersecurity capabilities, a good starting checklist for anything you buy or build.

2. Gateways and protocol adapters

A gateway translates device protocols and filters data. LF Edge's EdgeX Foundry targets interoperability between devices and applications at the IoT edge, Fledge collects and processes industrial operational data, and eKuiper runs stream analytics on constrained devices so only results go upstream.

3. Edge compute nodes

One to a handful of servers or industrial PCs per site run containers or virtual machines: inference, local databases, control logic, store systems or video analytics. Each needs an OS, a container runtime, an orchestrator and an update path. LF Edge's EVE builds EVE OS, an open Linux based operating system for distributed edge computing.

4. Control plane and management

Something decides what runs where and collects status: a K3s control plane on site, a central control plane with remote nodes (KubeEdge), a MEC orchestrator, or a fleet manager such as LF Edge's Open Horizon. LF Edge's FIDO Device Onboard provides automated "zero touch" onboarding.

5. Cloud and central services

Model training, storage, identity, artifact registries and the CI pipelines that build what the edge runs. The edge depends on them but must not stop when they are unreachable.

Data flow and reconciliation

Telemetry moves up; desired state, models, images and certificates move down. Both directions can be cut for minutes or weeks, so write down what a node does when it cannot reach the control plane, how much it buffers, and how conflicts resolve on reconnect. KubeEdge's MetaManager keeps metadata in a local SQLite database and syncs pod status on an interval. K3s agents keep a client side load balancer of server endpoints and reconnect when a server returns.

Edge computing use cases

These are patterns, not customer stories.

Retail

Stores run point of sale, inventory, loss prevention video analytics and self checkout. The edge helps because a store must keep selling when the WAN fails and shipping every camera stream to the cloud is expensive. Security priorities: payment segmentation, back office hardware that many people can touch, and pushing one update safely to thousands of identical sites.

Manufacturing and industrial

Plants run machine vision inspection, predictive maintenance, historians and supervisory control. Control loops need deterministic latency and production cannot stop for a cloud outage. NIST SP 800-82 Rev. 3 stresses OT's unique performance, reliability and safety requirements, which is why patching an industrial edge node is never as simple as patching a web server. See our post on IEC 62443 roles, zones, conduits and safety.

Telecom and 5G

Operators run network functions and third party applications on MEC hosts near the radio network: video optimisation, cloud gaming, private 5G and location aware services. Security priorities: multi tenancy on shared hosts, isolating operator functions from third party applications, and authorising access to radio and location data.

Vehicles and transport

Vehicles carry many ECUs, a central gateway, driver assistance and telematics; roadside units and depots add more sites. Safety decisions cannot wait for the network. Security priorities: signed updates, rollback protection and recovery after a key or server compromise. Uptane, a Linux Foundation Joint Development Foundation project, describes itself as a software update security system for the automotive industry designed to minimise damage from a compromise and assure rapid recovery.

Energy, healthcare, remote sites such as mines and ships, and AI inference near cameras follow the same patterns. For AI, the model files and serving runtime become software you must inventory and update.

Edge hardware: what to look for

Choose by site, not benchmark, and check these properties by category:

• Environmental rating: fanless, wide temperature, dust and vibration ratings for factories, vehicles and cabinets.
• Storage endurance: K3s documentation warns that SD cards and eMMC cannot handle etcd's write load and recommends an external SSD on ARM boards.
• Root of trust: TPM 2.0 for measured boot and keys, and UEFI Secure Boot with keys you can manage.
• Firmware resiliency: NIST SP 800-193 organises it around protecting against unauthorised changes, detecting them and recovering rapidly. Ask suppliers how each is done and for how long updates ship.
• Out of band management and accelerators: a BMC, GPU or NPU each brings firmware, drivers and runtimes to patch.
• Architecture: K3s supports x86_64, armhf and arm64, but every image then needs a variant per architecture.

Orchestration: K3s, KubeEdge and the LF Edge projects

K3s

K3s is a lightweight Kubernetes distribution for constrained and remote environments. Per its architecture documentation, a server node runs the control plane and datastore, an agent node runs neither, and both run the kubelet, container runtime and CNI. A single server can use embedded SQLite; high availability uses embedded etcd or an external datastore.

Two details matter for security. Agents open a websocket to the server and K3s routes kubelet traffic through that reverse tunnel, so agents only need to reach servers on TCP 6443. And the Flannel VXLAN port (UDP 8472) must never be exposed to the world; the documentation warns that doing so opens the cluster network to anyone. K3s also documents air gapped installs through a private registry or image tarballs on each node, the latter described as appropriate for edge sites where a registry is not practical.

KubeEdge

KubeEdge extends Kubernetes orchestration and device management to edge hosts, with a cloud part and an edge part. On the edge, Edged manages containers, EdgeHub is a websocket client to the cloud, EventBus speaks MQTT, DeviceTwin stores device status and MetaManager keeps metadata in local SQLite. In the cloud, CloudHub, EdgeController and DeviceController manage nodes, pods and devices. The CNCF lists KubeEdge as accepted on 18 March 2019, incubating on 16 September 2020 and graduated on 11 September 2024.

The key difference from K3s is where the control plane lives: K3s usually runs a small cluster per site, while KubeEdge keeps it central and treats edge hosts as remote nodes with locally cached state.

LF Edge projects

LF Edge lists Impact stage projects Akraino (edge infrastructure blueprints), EdgeX Foundry, EVE, Fledge and Open Horizon; Growth stage projects including FIDO Device Onboard and State of the Edge; and newer ones such as eKuiper, InfiniEdge AI and Ocre, which uses WebAssembly and Zephyr for small OCI like containers on constrained devices.

Comparison table: edge orchestration options

None of these is "best". They trade simplicity at each site against central control and blast radius: a central control plane is one place to secure and one place that can hurt every site.

Connectivity and offline operation

• Outbound only connections. K3s agents and KubeEdge's EdgeHub both connect out to the control plane, so sites need no inbound holes.
• Local images. A node that reboots during an outage without cached images stays down. Pre load tarballs or run a site registry mirror.
• Credential lifetimes. Certificates must outlast the longest expected outage yet expire soon enough to limit a stolen box. Write that number down.
• Time. A wrong clock breaks certificate checks and update freshness. Provide a local time source and monitor drift.
• Store and forward telemetry, with a size limit and a rule for what is dropped first, plus a rule for which side wins a conflict after reconnecting.

Update and fleet management

Updating 3,000 servers in 3,000 stores, some offline and one unplugged by staff every night, is its own discipline. Principles that hold across tools:

1. Declare the desired version; nodes pull and converge, including after an outage.
2. Pin versions, using digests for images. Never follow "latest".
3. Stage rollouts from lab to a canary ring to widening rings, halting on failed health checks.
4. Limit concurrency per site and across sites.
5. Keep a rollback path: A/B OS partitions and previous images cached locally.
6. Verify on the node, not just in transport.

K3s documents automated upgrades through the system upgrade controller: Plan custom resources describe which nodes upgrade to which version, and a concurrency field sets how many upgrade at once. Plans can follow a release channel or a fixed version; for fleets, a fixed version promoted through rings is safer. The docs note the Kubernetes version skew policy still applies.

Signing updates: TUF and Uptane

The Update Framework defines four top level roles. Root delegates trust to the other roles' keys and its private keys should be kept offline. Targets signs metadata describing trusted files and can delegate. Snapshot signs the latest version of all targets metadata, preventing mix and match attacks. Timestamp signs frequently refreshed metadata so clients detect indefinite freeze attacks. TUF assumes the repository may be compromised and limits the damage. Uptane applies this thinking to vehicles. Read both before building your own OTA mechanism, and see our post on OTA update threats: spoofing, tampering, replay and rollback.

Edge computing security

Edge security is cloud security plus physical security plus OT safety, minus most of the staff.

Physical access

• Lock cabinets; use tamper evident seals where locks are impractical.
• Disable unused USB ports and external boot; set a firmware password.
• Encrypt disks with keys sealed to the TPM and measured boot state.
• Store no long lived admin credentials or fleet wide secrets on the box.
• Treat returned or replaced units as untrusted until wiped and re enrolled.

Secure and measured boot

Secure Boot checks signatures on boot components; measured boot records what loaded into the TPM so a verifier can refuse secrets or workloads to a node that booted something unexpected. NIST SP 800-193's protect, detect and recover model applies directly.

Zero trust

NIST SP 800-207 (August 2020) tenets fit the edge closely: all communication is secured regardless of network location, access is granted per session by dynamic policy that includes the observable state of the requester, and the enterprise monitors the integrity and posture of all its assets. Its assumptions include that the private network is not an implicit trust zone and that not all resources sit on enterprise owned infrastructure, and it names edge devices among assets outside the traditional perimeter. In practice:

• Workload identity. SPIFFE specifies short lived identity documents, called SVIDs, usable for mutual TLS or signed JWTs. Short lived identity limits the value of a stolen box.
• Device posture in access decisions: a node on an old image gets fewer permissions, or none.
• No flat site networks: segment devices, edge compute, management interfaces and guest networks.

Isolation inside the node

Run containers as non root with read only root filesystems, apply NetworkPolicies so a video analytics pod cannot reach the payment service, keep OT control and analytics on separate nodes, and keep kubelet, BMC and SSH off store and shop floor networks.

The software supply chain

Every edge image bundles an OS base, runtimes, libraries, your code and often a model. When a library vulnerability lands, the question is which of 40 images on which of 3,000 sites carry it. Only an SBOM per image and a central inventory answer that quickly.

Industrial edge: IEC 62443

ISA/IEC 62443 addresses industrial automation and control systems (IACS) throughout their lifecycle. ISA notes the ISA and IEC editions are identical and that shared responsibility is a founding principle. Parts most relevant to edge projects:

An edge server running analytics in a plant is a component inside a zone. The conduit between it and the cloud, and between it and the control network, needs explicit rules. If you build edge software that ships into plants, 62443-4-1 describes the development process an asset owner will increasingly ask you to show.

Threats and controls at a glance

Decision table: should this workload run at the edge?

Use this table per workload, not per company. Many systems end up split across tiers.

If more than two rows in the "cloud" direction apply, keep it in the cloud. If the only reason for the edge is "it sounds faster", measure first.

Step by step: a small air gapped K3s edge site with verified images

This walkthrough builds a two node K3s site that runs without internet access, pulls images only from a site registry, verifies image signatures before they reach that registry, and upgrades in a controlled way. Commands follow the K3s and Sigstore documentation; adapt versions and addresses to your environment. Nothing here deletes data, but test on lab hardware first.

1. Prepare the hardware and OS

Use SSD storage for the server node, enable UEFI Secure Boot, set a firmware password and disable external boot. On Raspberry Pi OS, K3s needs cgroups enabled; the documentation says to append cgroup_memory=1 cgroup_enable=memory to /boot/firmware/cmdline.txt.

2. Stage the K3s artifacts on a connected build machine

Download the K3s binary, the install script and the air gap image tarball for your architecture from the official release, and record their checksums.

# On a connected build machine. Pin an exact release.
K3S_VERSION="v1.33.4+k3s1"
ARCH="amd64"
curl -LO "https://github.com/k3s-io/k3s/releases/download/${K3S_VERSION}/k3s"
curl -LO "https://github.com/k3s-io/k3s/releases/download/${K3S_VERSION}/k3s-airgap-images-${ARCH}.tar.zst"
curl -LO "https://github.com/k3s-io/k3s/releases/download/${K3S_VERSION}/sha256sum-${ARCH}.txt"
curl -sfL https://get.k3s.io -o install.sh

# Check the downloads against the published checksums
sha256sum --check --ignore-missing "sha256sum-${ARCH}.txt"

Copy those files to the site on approved media.

3. Verify and mirror your application images

Verify each application image signature before it enters the site registry. The Sigstore documentation shows key based verification:

# Verify the signature with your organisation's public key before mirroring
cosign verify --key cosign.pub registry.build.example.com/edge/vision-app@sha256:<digest>

# Scan the exact image you are about to ship, and keep the results with the release
safeguard scan --image registry.build.example.com/edge/vision-app@sha256:<digest>

Then copy the verified image by digest into the site registry with your normal registry tooling.

4. Point K3s at the site registry

K3s reads /etc/rancher/k3s/registries.yaml on each node and uses it to generate the containerd configuration. A mirror entry sends pulls for a public registry to your site registry:

# /etc/rancher/k3s/registries.yaml on every node
mirrors:
  docker.io:
    endpoint:
      - "https://registry.site01.example.internal:5000"
  registry.build.example.com:
    endpoint:
      - "https://registry.site01.example.internal:5000"
configs:
  "registry.site01.example.internal:5000":
    tls:
      ca_file: /etc/rancher/k3s/site-registry-ca.pem

5. Install the server without internet access

# Place the K3s images where the agent imports them at start
sudo mkdir -p /var/lib/rancher/k3s/agent/images/
sudo cp k3s-airgap-images-amd64.tar.zst /var/lib/rancher/k3s/agent/images/

# Install the binary and run the install script offline
sudo install -m 0755 k3s /usr/local/bin/k3s
INSTALL_K3S_SKIP_DOWNLOAD=true ./install.sh

# Read the join token for agents (store it as a secret, not in a ticket)
sudo cat /var/lib/rancher/k3s/server/node-token

6. Join the agent

# On the agent node, after copying the same binary and images
INSTALL_K3S_SKIP_DOWNLOAD=true \
K3S_URL=https://<SERVER_IP>:6443 \
K3S_TOKEN=<YOUR_TOKEN> \
./install.sh

7. Lock down the network

Follow the K3s inbound rules: agents need TCP 6443 to the server; nodes need UDP 8472 between each other only if you use Flannel VXLAN, or UDP 51820 for the WireGuard backend; kubelet port 10250 between nodes. Block everything else from the site network, and never expose 8472 beyond the nodes.

# Example with ufw on the server: only the agent subnet may reach the API
sudo ufw default deny incoming
sudo ufw allow from 10.20.30.0/24 to any port 6443 proto tcp
sudo ufw allow from 10.20.30.0/24 to any port 10250 proto tcp
# Flannel VXLAN (the default backend): node subnet only, never the world
sudo ufw allow from 10.20.30.0/24 to any port 8472 proto udp
sudo ufw allow from 10.42.0.0/16
sudo ufw allow from 10.43.0.0/16
sudo ufw enable

Add a default deny NetworkPolicy per namespace, then allow only the flows each workload needs.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: vision
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

8. Upgrade with a pinned, rate limited plan

Install the system upgrade controller from your mirrored manifests, then define a Plan with a fixed version and a concurrency of one. Promote the version string through your rings rather than following a channel.

apiVersion: upgrade.cattle.io/v1
kind: Plan
metadata:
  name: server-plan
  namespace: system-upgrade
spec:
  concurrency: 1
  cordon: true
  nodeSelector:
    matchExpressions:
      - key: node-role.kubernetes.io/control-plane
        operator: In
        values: ["true"]
  serviceAccountName: system-upgrade
  upgrade:
    image: rancher/k3s-upgrade
  version: v1.33.4+k3s1

Mirror the upgrade image into the site registry too, or the plan will stall offline. Watch progress with kubectl -n system-upgrade get plans,jobs.

9. Record what you shipped

For each site, record the K3s version, OS image, firmware versions, and the digest and SBOM of every application image. Keep the scan output from step 3 with the release. When the next advisory lands, you want to answer "which sites run the affected version" with a query.

Where Safeguard fits, honestly

Safeguard is not an edge platform, a device manager, an endpoint protection tool or a firmware scanner. It does not enrol devices, attest boot state, push OTA updates or generate hardware bills of materials. Most of the physical and boot chain controls in this post are outside its scope.

The overlap is the software you build and ship to the edge. Safeguard scans repositories, container images and SBOM files (safeguard scan with a directory, an image or an SBOM file), matches components against vulnerability databases, uses reachability analysis to rank what your code actually calls, and shows which projects contain a given component and version. Policies and gates can block an image from release when it fails your rules, and autonomous remediation can open fix pull requests (switched off by default). For an edge fleet, that is the step before rollout: knowing what is in each image and fixing it once in the pipeline, rather than after it has reached every site. When an edge vendor supplies an SBOM for an appliance or gateway image, Safeguard can analyse that too, but the fix for the vendor's own code still has to come from the vendor.

Common mistakes

• Treating the edge site as a small data centre. It has no guards, no spare parts and often no staff who know what a node is. Design for unattended operation and remote recovery.
• Following "latest" on edge nodes. Unpinned images and release channels turn every upstream release into an unplanned fleet rollout.
• Forgetting that images must be available offline. A node that reboots during an outage with no cached images stays down.
• Putting a fleet wide secret on every box. One stolen device then compromises every site. Use per device identity and short lived credentials.
• Exposing management ports. Kubelet, VXLAN, BMC and SSH reachable from a store or plant network is a common gap. K3s documentation explicitly warns about port 8472.
• Running control plane storage on SD cards. K3s documentation says SD cards and eMMC cannot handle etcd's IO load.
• Skipping signature verification on the device. Signing in CI is not enough if the node never checks.
• Having no inventory of what runs where. Without per site versions and per image SBOMs, every advisory becomes a manual survey.
• Upgrading every node at once. Concurrency limits and rings exist because one bad build can take down every site.

FAQ

What is edge computing in simple terms?

Edge computing means processing data near where it is created, on the device itself, a server in the same building, or a telecom site close to users, instead of sending it all to a central cloud. It reduces latency and bandwidth and lets systems keep working when the network fails.

What is the difference between edge and fog computing?

NIST SP 500-325 describes edge computing as the layer of end devices and their users, and fog computing as a hierarchical layer of fog nodes between those devices and the cloud that adds storage, control and processing. In everyday use, "edge" often covers both.

What is ETSI MEC?

Multi-access Edge Computing is ETSI's framework for running applications on virtualised infrastructure in or close to a telecom network edge. It defines MEC hosts, platforms and orchestration, and services such as radio network information and location that operators can expose to authorised applications.

Is edge computing more secure than cloud computing?

Not by default. It can reduce exposure by keeping data local, but it adds physical access risk, many more systems to patch, and long offline periods. It is as secure as your device identity, boot integrity, update signing and segmentation make it.

What are the main security risks of edge computing?

Physical theft and tampering, malicious or rolled back updates, a compromised central control plane, lateral movement on flat site networks, vulnerable dependencies replicated across the fleet, exposed management ports, and stale certificates or clocks after long outages.

What is K3s used for at the edge?

K3s is a lightweight Kubernetes distribution suited to small sites and constrained hardware. Its documented minimums are 2 cores and 2 GB of RAM for a server and 1 core and 512 MB for an agent, and it supports air gapped installation and ARM hardware.

What is the difference between K3s and KubeEdge?

K3s usually runs a complete small cluster at each site. KubeEdge keeps the Kubernetes control plane central and runs an edge part on each node that keeps metadata locally in SQLite. KubeEdge also includes MQTT based device management.

How do you update thousands of edge devices safely?

Declare pinned versions centrally, roll out in rings starting with a canary group, limit concurrency, gate on health checks, keep a rollback image on the device, and verify signed update metadata on the device using a TUF or Uptane style design.

Does zero trust apply to edge computing?

Yes. NIST SP 800-207 names edge devices among the resources outside the traditional perimeter. Its tenets, such as securing all communication regardless of location and using device posture in access decisions, fit edge sites closely.

Which standard applies to industrial edge computing?

The ISA/IEC 62443 series covers industrial automation and control systems across their lifecycle, including asset owner programmes, zones and conduits, system security levels, secure product development and component requirements. NIST SP 800-82 Rev. 3 gives complementary OT security guidance.

Fix it without waiting for upstream

An edge fleet runs the same container images, libraries and Kubernetes components on every node, so a vulnerable dependency is copied to every site at once, and fixing it in the pipeline before rollout is far cheaper than chasing it across hundreds of boxes. The fit is partial: the steps below cover the open source software and images you build and ship to the edge, not device firmware, boot chains or the code inside a vendor's sealed appliance.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real terminal session with the Safeguard CLI. It reads a vulnerability finding and its advisory, asks before each command, upgrades a dependency, runs the tests with your approval and pushes nothing. The same flow applies to the service code you package into edge images: fix the dependency once in the repository, rebuild the image, and promote it through your rollout rings.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and runs scans from the terminal. That suits an edge build or staging machine on a restricted network, where you want to scan the exact image or SBOM you are about to mirror into a site registry without sending source anywhere else.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask which of your projects contain a component named in a new advisory, as long as the edge images and services are in your Safeguard inventory.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• NIST SP 500-325, Fog Computing Conceptual Model (March 2018)
• NIST SP 800-207, Zero Trust Architecture (August 2020)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines
• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
• NISTIR 8259A, IoT Device Cybersecurity Capability Core Baseline
• ETSI GS MEC 003 V3.2.1, Multi-access Edge Computing Framework and Reference Architecture
• ETSI, Multi-access Edge Computing technology page
• LF Edge, projects
• K3s documentation, Architecture
• K3s documentation, Requirements
• K3s documentation, Air gap install
• K3s documentation, Private registry configuration
• K3s documentation, Automated upgrades
• KubeEdge documentation, Why KubeEdge
• KubeEdge documentation, MetaManager
• CNCF, KubeEdge project page
• ISA, ISA/IEC 62443 series of standards
• The Update Framework specification
• Uptane
• SPIFFE overview
• Sigstore, Verifying signatures with cosign

Last reviewed: 23 October 2026.