Edge Security Assessment Checklist

This checklist is for IoT, OT, network, and product security teams responsible for fleets of edge devices: gateways, cameras, sensors, retail and industrial compute, and 5G edge nodes. Edge environments differ from the data center in ways that matter for security. Devices are physically accessible, run for many years, connect intermittently, and often have limited compute for security tooling.

The device sections follow the six capabilities in NIST IR 8259A (device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness). NIST SP 800-213 covers how to turn them into procurement requirements.

How to use this checklist

1. Assess each device model once, then assess fleet-level controls separately.
2. Record "not supported by the device" separately from "not configured". The first is a procurement problem, the second an operations one.
3. Reassess when you add a new device model or vendor.

Device identity and hardware

• □ Each device has a unique identity, ideally backed by a hardware key in a TPM or secure element.
• □ Secure boot verifies firmware signatures from a hardware root of trust.
• □ Debug interfaces such as JTAG and UART are disabled or locked in production units.
• □ Tamper detection or response exists where physical access is plausible.
• □ Keys and sensitive data are encrypted at rest.

Software and firmware updates

• □ Firmware updates are signed and verified before install, with rollback protection against downgrade attacks.
• □ The vendor documents a support period and update cadence.
• □ A firmware SBOM is available, so you can check components against new vulnerabilities.
• □ Updates can be staged and recover from failure, for example with A/B partitions, over constrained links.

Configuration and access

• □ No default or shared passwords; credentials are unique per device.
• □ Unused services and ports are disabled.
• □ Management interfaces are reachable only from a management network with strong authentication.
• □ Configuration baselines are enforced and drift is detected.

Network

• □ Devices authenticate to the network before gaining access, for example with 802.1X or certificates.
• □ Edge devices are segmented from IT systems and from each other by function, with default-deny rules.
• □ Device-to-cloud traffic uses mutual TLS, and certificate lifecycle is automated.
• □ Egress is limited to required destinations.

Monitoring and lifecycle

• □ Device logs and health telemetry are centralized.
• □ Traffic baselines exist, with alerts on new destinations or unusual volumes.
• □ Any device can be quarantined or remotely disabled.
• □ The asset inventory is reconciled against the network regularly to find rogue devices.
• □ Onboarding and decommissioning are secure: zero-touch provisioning in, key wipe and certificate revocation out.

Common pitfalls

• Assuming physical security. Edge devices sit in shops, poles, and plant floors.
• Buying devices the vendor cannot update. Make update support a procurement requirement.
• Flat networks where one compromised camera reaches everything.
• Manual certificate management, which leads to mass expiry outages across a fleet.