Requirements · IoT and M2M connectivity
Security requirements for connected IoT devices in the field
Last updated 25 October 2026 · 2 sources listed · Reading time about 3 minutes
Short answer
Connected devices should have unique credentials, encrypted communication, a secure update mechanism, minimal exposed services and a defined support period. Because devices are physically accessible and long-lived, plan for secure boot, key storage and a way to retire or revoke devices. Reference recognised baselines from standards bodies and regulators in your target markets.
Who this is for: An engineering or procurement lead specifying baseline security for devices that will run unattended for years on networks you do not control.
What to evaluate
Unique device identity
Shared default credentials let one compromise spread across an entire fleet.
How to check: Confirm every device has individual keys or certificates provisioned at manufacture.
Encrypted communication
Data crossing public networks can be intercepted or altered.
How to check: Verify transport encryption and server authentication on all device connections.
Secure update capability
Flaws are found over a device's life and must be fixed without site visits.
How to check: Test signed over-the-air updates and rollback behaviour on failed updates.
Minimal attack surface
Open ports, debug interfaces and unused services give attackers entry points.
How to check: Disable debug access in production and review open services.
Support period and vulnerability handling
Buyers need to know how long fixes will be provided and how issues are reported.
How to check: Ask for a stated support period and a published vulnerability disclosure process.
Revocation and decommissioning
Lost, stolen or retired devices must not retain access to your systems.
How to check: Check how credentials are revoked and data wiped at end of life.
Comparison
| Control | Protects against | How to verify |
|---|---|---|
| Unique credentials | Fleet-wide compromise from one leaked secret | Inspect provisioning process |
| Transport encryption | Interception and tampering on the network | Review protocol configuration |
| Signed updates | Malicious or corrupted firmware | Attempt to install unsigned firmware |
| Secure boot and key storage | Physical tampering and key extraction | Review hardware design documents |
| Revocation process | Retired devices still trusted | Test removing a device from the system |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Unique device identity | |||
| Encrypted communication | |||
| Secure update capability | |||
| Minimal attack surface | |||
| Support period and vulnerability handling | |||
| Revocation and decommissioning | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Are credentials unique per device and how are they provisioned?
- How are firmware updates signed and delivered?
- What is the stated security support period for the device?
- Is there a published process for reporting vulnerabilities?
- Are debug interfaces disabled in production units?
- How is data protected if a device is stolen?
- Which security standards or baselines does the product follow?
Typical trade-offs
Add a secure hardware element
- Upside
- Stronger protection of keys against physical attack
- Downside
- Increases bill of materials and design complexity
Support over-the-air updates
- Upside
- Fix vulnerabilities without site visits
- Downside
- Consumes data and power and creates an update channel that must itself be secured
Isolate devices on a private network
- Upside
- Reduces exposure to internet-wide scanning
- Downside
- Adds network design and provider dependencies
Common mistakes
- Shipping with a shared default password; generate unique credentials at manufacture.
- Leaving debug ports enabled for convenience in production.
- Treating security as a one-off launch task rather than a support commitment.
- Storing keys in plain firmware images that can be extracted from a captured device.
Related questions
Which standards should I follow for IoT security?
Start with baseline guidance from standards bodies and regulators in your markets, such as national cybersecurity agencies and international standards organisations that publish baseline requirements for consumer and industrial devices. Some jurisdictions have legal requirements around default passwords, vulnerability disclosure and support periods. Check the rules where you sell, and have your design reviewed against a recognised baseline.
How long should I support a deployed device?
Support should match the device's expected life in the field and the sensitivity of what it controls. A utility meter may run for many years, so you need a plan for fixes across that span, including component supply and cryptographic updates. State the support period to buyers, and plan the budget and staffing needed to maintain it. Retiring support without notice leaves customers exposed.
What happens if a device is stolen?
A thief may extract keys or use the device to reach your systems. Mitigate with per-device credentials that can be revoked, hardware-protected key storage where risk justifies it, encrypted local data and monitoring for devices that appear in unexpected places. Make sure operations staff know how to revoke a device quickly, and test that process before an incident occurs.
Do small deployments need these controls?
The principles apply at any size, though the investment can scale with risk. Even a small deployment should avoid default passwords, encrypt traffic and have a way to update firmware. Smaller teams can lean on managed connectivity and device management platforms that provide many controls out of the box. Weigh potential harm if devices are compromised, including access to wider networks.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- NIST Cybersecurity for IoT Program — NIST, retrieved 27 October 2026
- Cybersecurity and Infrastructure Security Agency — CISA, retrieved 27 October 2026
Related guides
How to choose · IoT and M2M connectivity
How to choose a connectivity technology for a fleet of IoT devices
Match the radio to the data pattern. Devices that send small packets rarely and must last on a battery suit low-power wide-area technologies, while those needing frequent or larger data, mobility or voice suit cellular. Short-range options fit within buildings. Weigh coverage where devices will live, battery life, data volume, certification and the longevity of the network technology.
Comparison · IoT and M2M connectivity
IoT SIM cards versus embedded SIMs versus Wi-Fi for connected devices
Removable SIMs are simple and swappable but can be removed or damaged. Embedded SIMs are soldered, tamper resistant and support remote profile changes, which helps for devices that cross markets or must switch providers. Wi-Fi avoids cellular fees but depends on a customer's network and credentials. Choose by deployment environment, lifespan and whether you control the site.
Cost factors · IoT and M2M connectivity
What drives the cost of connecting IoT devices at scale
Connectivity cost is more than a monthly line fee. It includes module and certification costs, data volume and pooling terms, roaming, platform fees, installation, support visits and eventual replacement. Costs rise with data volume, number of countries and tight service levels. Model the whole device life and ask providers how overage, inactive lines and contract exits are treated.
How to choose · Wi-Fi and home networking
How to choose a mesh Wi-Fi system for a larger or awkward home
A mesh system uses several nodes that act as one network, which suits multi-storey homes, thick walls and long layouts. Choose by coverage area, whether nodes link through a dedicated wireless channel or a cable, the number of Ethernet ports, and the management and security features. Wired backhaul between nodes gives the steadiest performance where cabling is possible.
Requirements · Smartphones
Requirements for using your own phone on another carrier or abroad
A phone works on another network only if it is unlocked, supports the radio bands and technologies that network uses, and is not blocked as lost, stolen or unpaid. Check the lock status, the band list, the SIM and eSIM format, and any financing balance before switching. Rules about unlocking differ by country, so confirm with your provider or regulator.
How to choose · Roaming and international
Mobile connectivity for business travellers and international teams
Business travel connectivity should be chosen around reachability, predictable cost and security. Consider a plan with international bundles, a managed eSIM programme or pooled data across employees, combined with device management, VPN use and travel policy rules for networks and spend limits.
Problems & fixes · Home internet
Slow or unreliable home internet: finding the cause and when to blame the provider
Separate the problem by testing with a cable straight to the router, then compare against wireless. If a wired test is poor at all hours, the fault is likely the line or provider; if only Wi-Fi is poor, it is placement, interference or router limitations. Keep dated test records so that a complaint or exit right is supported by evidence.
All IoT and M2M connectivity guides · All Telecommunications