What Is IoT and Edge Computing? Definition & Examples

IoT and edge computing place connected devices and local processing close to where data is created, reducing delay and dependence on central cloud systems. In identity security, they expand the NHI footprint with device identities, embedded credentials, and local access paths that must be governed, monitored, and revoked with the same discipline as human IAM.

How IoT and Edge Computing Work

IoT pushes computation toward connected sensors, actuators, gateways, and embedded controllers so systems can act with less delay and less dependence on a remote cloud. Edge computing extends that pattern by processing data near the source, which is especially useful when bandwidth is limited, latency matters, or local autonomy is required.

That architecture changes the security boundary. Instead of a small number of central systems, organisations now operate many distributed endpoints, local brokers, and device-managed services that each may need inventory, trust decisions, telemetry, and revocation paths. The result is a larger operational surface, not just a larger device count.

Why IoT and Edge Expands the Identity Surface

In practice, IoT and edge environments create more non-human identities than traditional enterprise systems because devices, firmware components, gateways, and local services often authenticate independently. Those identities may rely on certificates, tokens, pre-shared keys, API credentials, or embedded secrets that were provisioned long before anyone thought about lifecycle cleanup.

This matters because each local trust relationship can become durable and hard to see. When a device or edge workload is provisioned once and then left in place, access can outlive the asset, its owner, or its business purpose. That is why governance has to cover enrollment, naming, attestation, rotation, and retirement as a single control problem rather than separate tasks.

Operational Security Challenges at the Edge

Edge deployments often run in constrained, intermittently connected, or physically exposed environments. Those conditions make patching, monitoring, and centralized policy enforcement harder, and they also create pressure to cache credentials or allow local fallback access when the cloud is unavailable.

Local autonomy is useful, but it can also mask drift. A gateway that keeps working after central policy changes may still be honoring stale entitlements, stale certificates, or overbroad service permissions. In that sense, edge resilience and edge risk are closely linked: the same design choice that improves uptime can extend the lifetime of compromised or unnecessary access.

Governance and Lifecycle Control for Distributed Devices

The core control problem is lifecycle discipline. IoT and edge estates need reliable discovery, ownership, provisioning standards, certificate or key rotation, dependency tracking, and decommissioning so that device identity does not become permanent by accident. Without that discipline, organisations lose the ability to prove which device is trusted, which local process may act on data, and which secrets are still valid.

Good governance also means being explicit about where trust is anchored. A cloud policy may define the intended state, but the actual authorization decision may happen locally on the device, gateway, or edge cluster. That makes inventory accuracy, configuration review, and revocation speed just as important as the original enrollment process.

Risk and Threat Considerations

IoT and edge environments are attractive because they combine distributed trust, embedded credentials, and weaker physical and operational control than central platforms. If a device identity, local secret, or gateway credential is stolen, an attacker can persist at the edge, impersonate a legitimate component, or move laterally into adjacent services that trust that component.

Failure mechanism: Stale certificates, hard-coded secrets, weak onboarding, and incomplete offboarding let compromised or obsolete device identities remain trusted long after they should have been revoked.

Impact: That can expose telemetry, unlock local administrative paths, enable command injection into connected systems, and create a hidden foothold that survives routine cloud-side monitoring.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 provides the primary governance reference for this term.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	IoT and edge identities depend on credential and secret lifecycle control.
	IA-9 — Service Identification and Authentication	Edge workloads and device-to-device trust rely on non-human authentication.
	SC-7 — Boundary Protection	Edge systems extend the trust boundary beyond the central cloud.
Recommendation — Manage device and service authenticators so edge credentials are rotated, protected, and revoked promptly. Authenticate device and service interactions with unique identities and strong mutual trust controls. Segment edge environments and tightly control ingress, egress, and trust paths.

Practitioner Guidance

Why practitioners should care: Treat edge and IoT identity as a lifecycle-managed control surface, not as a hardware issue. The security outcome depends on whether each device, gateway, and local service has a clear owner, a bounded purpose, and a revocation path that actually works when the asset is retired or compromised.

What to watch for: Pay attention to embedded secrets, shared certificates, default credentials, unmanaged gateways, and devices that cannot report reliably into central monitoring. Those are usually the places where trust outlives control.

IoT and Edge Computing