IoT Analytics projected 21.1 billion connected IoT devices for 2025, growing to 39 billion by 2030. SonicWall’s 2025 threat report logged a 124% spike in IoT attacks. And the number-one technique attackers used to get in? Brute-forcing default SSH and Telnet credentials.
Not a zero-day. Not a sophisticated supply-chain compromise. Default passwords.
I’ve spent over 15 years deploying IoT solutions across aviation, logistics, and MRO operations. The security failures I’ve witnessed firsthand almost never involved advanced hacking. They involved a device that shipped with “admin/admin,” firmware nobody updated, and an asset nobody formally owned after installation. If you’re figuring out how to secure IoT solutions, the answer starts well before you configure a firewall. It starts at procurement.
Why IoT Attacks Still Win on Basics
The scale of connected devices creates a systems problem. Nozomi Networks’ second-half 2024 review confirmed that brute-forcing default credentials remained the leading IoT access technique across monitored environments, with data manipulation the most common detected activity in manufacturing, transportation, and energy. That same report tallied 241 new CISA advisories and 619 ICS-CERT vulnerabilities across 70 affected vendors.
The Verkada breach makes this concrete. In March 2021, an attacker accessed more than 150,000 live customer cameras along with addresses, audio recordings, and Wi-Fi credentials. The FTC alleged Verkada failed to require unique passwords, adequately encrypt data, or implement basic network controls. A centralized shared credential turned thousands of geographically separate cameras into a single blast radius.
That pattern applies to any IoT fleet. Asset trackers on cargo pallets. Environmental sensors in cold-chain warehouses. Monitors on ground support equipment. If one compromised identity unlocks the entire pool, the pool is the vulnerability.
Meanwhile, the gap between exploit publication and patching keeps widening. SonicWall’s data shows attackers used publicly available exploit code within 48 hours 61% of the time, while organizations took 120 to 150 days to implement patches on average. Attackers move in hours. Defenders move in quarters.
Six Controls That Cover Most of Your IoT Risk
NIST’s IoT Device Cybersecurity Capability Core Baseline (NISTIR 8259A) defines six device capabilities I use as acceptance criteria before signing a purchase order. Not as a compliance checkbox after deployment. Before the device enters the fleet. If a vendor can’t demonstrate these six, no amount of network segmentation compensates for hardware born insecure.
1. Authoritative asset inventory
Every device gets a record: identity, owner, location, firmware version, connectivity type, business criticality, data it handles, support status, and permitted communications. Forescout’s analysis of more than 8 million devices across financial services, government, healthcare, manufacturing, and retail found smart buildings, medical devices, networking equipment, and VoIP phones among the riskiest categories. You cannot prioritize risk on devices you don’t know you have.
In aviation and logistics, this connects directly to asset tracking discipline. If your container pool, ULD fleet, or ground support equipment disappears from visibility after handoff, it disappears from your security posture too. The operational habit that makes asset tracking work (knowing where every asset is, who owns it, what state it’s in) is the same habit that underpins IoT security.
2. Unique device identity, no defaults
Every device gets a unique credential or hardware-backed certificate at provisioning. No shared passwords. No factory defaults surviving past first boot. Nozomi’s brute-force data and the Verkada case illustrate the same lesson: shared or default identities turn individual device compromise into fleet-wide exposure. One credential, one device, no exceptions.
3. Least-privilege network access
Segment IoT devices into purpose-specific network zones. A tracker on a cargo pallet should not share a segment with your ERP system. NIST’s zero trust architecture rejects implicit trust based on network location, requiring authentication and authorization of both the subject and the device before any session.
In practice: VLANs or microsegmentation for device groups, firewall rules that permit only required flows, no direct Internet exposure for management interfaces, and east-west traffic treated as untrusted. In OT environments (hangars, factories, ports), passive monitoring and controlled conduits are often safer than aggressive scanning that could interrupt a production process.
4. Data protection in transit and at rest
TLS for all transmissions. Encrypted storage for credentials, configuration data, and sensitive telemetry. Key rotation on schedule. This protects against interception and tampering. But encryption alone is not sufficient. Encryption without identity, access control, and update capability is a locked door with the key taped to the frame.
5. Signed firmware updates with rollback
Every update must be authenticated, integrity-verified, staged, tested, and capable of rollback. The Update Framework describes a secure update system as one that validates metadata and downloads while avoiding harm from checking or installing updates. It recommends compartmentalized trust, key replacement, and resilience against key compromise.
Remember the patch-gap data: 48 hours for attackers versus 120 to 150 days for defenders. A mature update program closes that window through signed packages, staged rollouts, automated deployment tracking, and emergency recovery paths. This is where device selection at procurement matters most. If the vendor has no update infrastructure, you inherit an unpatched device for its entire lifespan.
6. Continuous monitoring and state awareness
Devices should report their security state: firmware version, configuration changes, failed authentication attempts, anomalous behavior. Passive network monitoring detects drift without installing agents on constrained hardware. Cloud and OT platforms add value here, but only if someone owns the alerts and has authority to act.
The most common failure is buying a monitoring dashboard nobody watches. Monitoring without a response process is expensive logging.
The Legacy Problem Nobody Budgets For
Here is the reality check most vendor whitepapers skip: a significant portion of your IoT fleet probably cannot be updated.
Devices deployed in aviation MRO, port operations, building systems, and industrial environments often run for 10 to 15 years. Manufacturers discontinue support. Firmware repositories go offline. The device works fine operationally, but it carries known vulnerabilities with no patch path. The OWASP IoT Top 10 calls out outdated components and missing secure updates as distinct risks for exactly this reason. Organizations implementing Industry 4.0 must address these legacy security challenges as part of their digital transformation roadmap.
You have three options:
- Replace the device. The cleanest answer and often the most expensive in the short term. But factor in monitoring, isolation, and risk-acceptance costs for keeping a vulnerable device running, and the math shifts.
- Isolate and compensate. Move the device to a tightly controlled segment. Remove Internet access. Disable unused services. Restrict management to a jump host. Monitor behavior passively. Document residual risk with an accountable owner who understands what “residual” means in practice.
- Accept the risk formally. Some organizations do this implicitly by ignoring legacy devices. Doing it formally means recording the decision, the exposure, the conditions under which the decision expires, and the person responsible when conditions change.
In aviation and freight operations, I see this pattern constantly: first-generation trackers on reusable containers, aging environmental sensors in temperature-controlled warehouses, legacy monitors on ground support equipment. The question is not whether these devices are perfect. It is whether someone owns them, monitors them, and has a plan when they cross a risk threshold. A DO-160 airfreight-approved tracker like the Thingfox T2 doesn’t just solve a compliance requirement. It solves a lifecycle security problem because the hardware, update path, and support commitment were designed for environments where “replace it next quarter” is not always possible.
Regulation Is Rewriting the Liability Map
Three regulatory frameworks are reshaping who is responsible for IoT security, and the direction is clear: liability is moving upstream toward manufacturers and solution providers.
The EU Cyber Resilience Act entered into force in December 2024. Vulnerability reporting obligations begin September 11, 2026. Main obligations, including lifecycle security requirements, CE marking, and vulnerability handling, apply from December 11, 2027. If you sell or deploy connected products in the EU, these are engineering deadlines.
The UK PSTI regime has been in force since April 2024, requiring unique or user-defined passwords, vulnerability reporting information, and transparent minimum security-update periods for consumer connectable products.
In the U.S., the FCC Cyber Trust Mark program is voluntary and covers consumer wireless IoT products through accredited testing and a QR-linked information registry. The ioXt Alliance was named Lead Administrator effective April 2026.
For organizations deploying IoT solutions at scale, the practical implication is contractual. Your procurement process should require:
- A machine-readable software bill of materials (SBOM) for every device and firmware version
- A documented vulnerability disclosure policy with committed response timelines
- A defined minimum support period with patch delivery commitment
- Evidence of update infrastructure (not just a promise to “release patches as needed”)
- End-of-life notice and data handling procedures
CISA’s Secure by Demand guidance gives buyers specific questions to ask about authentication, SBOMs, memory safety, provenance, and vulnerability disclosure. Treat it as your procurement appendix.
What Measurable IoT Security Looks Like
When these controls are in place, the results are specific and auditable:
- 100% asset accountability. Every deployed device has a known owner, firmware version, support status, and permitted communication path. No dark assets. No “we think there are about 200 trackers somewhere in the network.”
- Mean time to patch under 30 days for critical vulnerabilities. Against the 120-to-150-day industry average SonicWall documented, this alone closes the most exploited window between disclosure and compromise.
- Zero default credentials in production. If brute-forcing defaults is still the top IoT attack vector, eliminating defaults removes the top attack vector. That is not a security strategy. That is basic arithmetic.
These outcomes are not theoretical. They are the operational standard for any fleet deployment that treats security with the same rigor as connectivity, whether you are tracking reusable containers across ocean routes, monitoring ground support equipment on the tarmac, or managing environmental sensors in a temperature-controlled supply chain.
If your IoT fleet feels invisible after deployment, or your solution provider can’t clearly answer questions about update paths and credential management, that gap is where the next breach lives. Talk to our team about building IoT deployments where security is designed in from procurement, not bolted on after the fact.
Frequently Asked Questions
What is the single most important step to secure IoT devices?
Eliminate default credentials before any device enters production. Nozomi Networks’ telemetry consistently identifies brute-forcing default SSH and Telnet passwords as the leading IoT attack technique. Unique per-device identities remove the most commonly exploited entry point across every sector.
Is network segmentation enough to protect IoT solutions?
No. Segmentation limits blast radius, which is valuable, but it does not fix hardcoded passwords, missing update paths, or insecure APIs. Treat segmentation as one layer in a defense-in-depth approach that also includes unique identity, encryption, signed updates, and continuous monitoring.
How do I secure legacy IoT devices that no longer receive patches?
Isolate them in a dedicated network segment, remove Internet access, disable unused services, restrict management to jump hosts, and monitor behavior passively. Document residual risk formally. Plan replacement on a timeline tied to business criticality and exploitability, not convenience.
What security standards should I require for IoT procurement?
Use NISTIR 8259A as a device capability baseline and the OWASP IoT Top 10 as a threat checklist. For consumer products, reference the FCC Cyber Trust Mark and ETSI EN 303 645. No single certification guarantees security; continuous updates, monitoring, and lifecycle ownership remain essential.
How does IoT security differ in aviation and industrial environments?
Devices in aviation, MRO, and heavy industry often run for 10 to 15 years, operate in harsh conditions (vibration, temperature extremes, humidity), and may carry safety or regulatory constraints that prevent unplanned reboots or agent installation. Security relies more heavily on passive monitoring, compensating controls, procurement-stage requirements, and lifecycle ownership than on conventional endpoint software.
What should I demand from an IoT solution provider before purchasing?
At minimum: a software bill of materials (SBOM), a vulnerability disclosure policy, a defined support and patch period, unique per-device credentials at provisioning, signed firmware updates with rollback capability, encrypted communications, and a clear end-of-life data handling commitment. If the vendor can’t answer these questions clearly, reconsider the purchase.
+1 508 292 2210
