Share this post
The software obligation behind every edge device
The hardware decision is visible. The software management obligation that comes with it usually isn't.
Procurement specifies the hardware. Compliance specifies the network. The software management obligation that comes with the device usually isn't owned by anyone at the point of purchase, and the gap surfaces months later as version drift, missing patches, and audit answers that nobody can produce confidently.
The 25 questions in this checklist surface that obligation while it's still negotiable. They span five areas worth pressure-testing with your IT, OT, and procurement teams before a PO is signed. A printable PDF version is at the bottom of the page if you'd rather walk into a procurement meeting with a hard copy.
Deployment and Day-One Readiness
The state a device arrives in determines how much work it takes to make it manageable. The questions below test whether the hardware is ready to deploy out of the box, or whether you've signed up for a configuration project alongside the procurement.
Can the device run containerized workloads natively?
Modern industrial edge applications ship as containers. If the device doesn't include a supported container runtime out of the box, you're committing to install, qualify, and maintain that runtime yourself for the life of the fleet. Confirm whether the OEM ships and maintains the runtime, or whether that obligation transfers to you on day one.
Does the device ship with a management agent pre-installed?
A management agent is what makes the device addressable from a central console. If it isn't pre-installed, every device needs a specialist on-site for setup, multiplied across every site you operate. Ask whether the agent is installed and configured at the factory, and whether it activates with the rest of the device on first boot. For an example of how this looks when management ships pre-installed, see our blog ont the edgeNode Portainer from Softing.
What does first-time setup look like for a non-specialist on-site?
The realistic measure of usability is whether a plant technician with no container experience can bring the device online quickly. Ask for the actual time, the actual skill level required, and whether setup needs anything beyond power and a network cable.
Does remote management require inbound firewall rules to be opened?
Industrial networks are typically designed with strict inbound restrictions to align with OT security policy. Devices that require inbound rules force exceptions to that architecture. Confirm the device communicates outbound-only, so it fits the security model you already have rather than requiring you to weaken it.
Is the software stack open to third-party applications?
A locked stack means the OEM decides what software can run on hardware you own. If you need to add a new application later, an OPC UA gateway, a vision model, a different historian, check whether you can deploy it through standard container tooling, or whether you're tied to whatever the OEM ships and chooses to ship.
AI Workload Readiness
If the device will run AI inference (image classification, predictive maintenance, anomaly detection, computer vision QA), the questions about workload support are different from general software questions. Most modern edge hardware is being specified with these workloads in mind.
Does the device support GPU or AI-accelerator hardware?
NVIDIA, Hailo, Intel, AMD, or proprietary silicon, each requires a supported driver stack, kernel modules, and firmware. Confirm the OEM ships and maintains that stack with security patches included. If the driver stack is your responsibility, you've inherited a second software lifecycle on top of the application one.
Can container workloads access the GPU or accelerator directly?
GPU passthrough into containers is non-trivial in production. The capability exists, but configuration varies by vendor and often breaks on driver updates. Confirm it's been tested in the field with workloads similar to yours, not just demonstrated in a vendor lab.
How are AI models updated independently of the application?
Models change more often than the applications that run them. A retrained inference model should be pushable to the device without redeploying the full container or re-flashing the device. Ask how model updates are versioned, distributed, and rolled back, and whether the management layer treats models as a distinct artifact.
Does the device have sufficient memory and storage for production AI workloads?
Inference at the edge is memory-hungry, particularly for vision and multi-model workloads. Datasheet specifications can be baseline figures, not steady-state operating numbers. Confirm headroom for the model size, batch size, and concurrent applications you actually expect to run, plus OS and management overhead.
Is the AI workload lifecycle managed centrally across the fleet?
A single model update across 300 devices is either one action or 300. Confirm that model deployment, versioning, and rollback work fleet-wide from one console, and that you can target subsets of the fleet (a region, a hardware class, a line) without per-device intervention.
Fleet Management at Scale
Managing one device is not the same as managing 30, and managing 30 is not the same as managing 30,000.
Can you push a software update to all devices simultaneously from one place?
This is the difference between a manageable fleet and a serial intervention problem. Confirm that updates can be staged, scheduled, and pushed centrally, and that the management layer doesn't require sequential per-device steps. The cost of a fleet without this capability shows up in the labor budget, not the hardware budget.
Can you roll back an update fleet-wide if something goes wrong?
Every update will eventually go wrong on at least one device. Rollback should be a one-click, fleet-wide action with a defined time to recovery. Ask what the rollback procedure looks like, how long it takes, and what state the device is in mid-rollback.
How do you ensure every device in the installed base runs the same software version?
Drift is the default. Devices deployed in different quarters, by different integrators, in different sites will diverge in version unless something actively prevents it. Confirm how the management layer enforces version consistency and how it surfaces non-compliant devices for action.
Does the fleet management approach work across mixed hardware vendors?
Most operations end up with mixed hardware over time, whether through acquisition, supplier change, or workload requirements. A management layer tied to one OEM's hardware traps you in a single supplier and loses value the moment you diversify. Ask whether the layer is hardware-agnostic in practice, not just in marketing.
If you add twenty more devices next year, does your management approach scale?
Adding devices should be a simple step, not a configuration project. Confirm that onboarding a new device is templated and automated, and doesn't require provisioning effort proportional to fleet size. If each new device is a new integration, you don't have fleet management. You have a growing collection of one-off deployments.
Who is responsible for software management on these devices once deployed?
This is the contract question, not the technical one. IT, OT, the OEM, and the integrator will each assume someone else owns it unless the responsibility is written down. Define the owner in the procurement contract.
Security and Compliance
Compliance frameworks are pushing operators to demonstrate they can patch and account for connected infrastructure within defined timeframes. The relevant standard varies by sector: NIS2 for industrial and critical infrastructure, FIPS 140-3 for defense and federal, HIPAA for healthcare, PCI for retail. The underlying question is the same: can you?
Can you push a security patch to every device in your fleet within 48 hours?
This is the operational test of every compliance framework that touches connected infrastructure. Confirm not whether the device supports remote patching in principle, but whether you can demonstrate a 48-hour fleet-wide patch with the infrastructure you'll actually have in production.
Can you produce an accurate software version inventory across your fleet on request?
This is the audit question. Auditors don't ask whether you could produce the inventory. They ask you to produce it, and the answer is binary. Confirm that the management layer maintains a real-time version inventory across containers, runtime, OS, and firmware, and that it can export the inventory in a format an auditor will accept.
Was the device developed under a recognized secure development framework?
Sector determines the relevant standard. IEC 62443 for industrial OT, FIPS 140-3 for defense and federal, equivalents in healthcare and retail. Confirm the standard the OEM developed against, ask for the certification or attestation, and confirm it covers the device you're buying, not just a related product line.
How does the vendor deliver security updates, and how quickly?
A vulnerability response process is one of the harder things to evaluate before you need it. Ask for the vendor's published vulnerability disclosure policy, the average time to patch, and a history of published advisories. Vendors without a public process are a risk indicator.
Does the device support role-based access control for software management?
Different sites, different teams, and different vendors need different levels of access to the same fleet. Confirm that the management layer supports RBAC granular enough to separate plant-level operators from corporate IT and from external integrators, and that access is auditable.
Vendor Relationship and Total Cost
OEM pricing on post-deployment changes is where the real cost of a locked architecture becomes visible. Ask these questions before you need the answers.
Is the software stack on your hardware dependent on a specific cloud provider, or are you agnostic?
Cloud-tied management means the device's manageability is contingent on the OEM's chosen cloud relationship. If that relationship changes, your fleet's manageability changes with it. Confirm whether management can run on-premises, in your cloud of choice, or in an air-gapped environment, and whether the option is contractual or just technically possible. For more information, see our Cloud IoT vs. Dedicated Edge Management comparison.
What does it cost to add a new data point or application after installation?
OEM-locked architectures often price change requests separately from the device itself. A new measurement point, a new application, a new integration can each carry separate fees that aren't visible on the original quote. Ask for the rate for post-deployment changes before you sign.
Are you paying for data access or for the hardware?
Some OEM models charge ongoing subscription fees for access to data the device is already collecting locally. The data is on hardware you own, but reading it requires a recurring fee. Confirm what you actually own, what you're licensing, and what the cost trajectory looks like over the deployment lifetime.
What happens to your management capability if you change hardware vendors in five years?
The cost of vendor change shows up in the management layer, not the hardware. If your management layer is portable across vendors, switching is a procurement decision. If it isn't, switching means rebuilding the operational layer from scratch, and the OEM knows this. Confirm portability before you commit.
