Why this post, and why now
IoT security used to be framed as a cloud problem with a device-side afterthought. That framing is now obsolete.
The numbers: the Cisco 2026 State of Wireless Report — surveying 6,098 wireless decision-makers across 30 markets — found that 85% of organizations with 250+ employees experienced a wireless security incident in the prior 12 months, and 36% of those involved compromised IoT or OT devices. Cloud-side defenses don’t help when the attacker is already inside through a forgotten sensor.
At the same time, a single cloud misconfiguration at an IoT vendor (Mars Hydro, early 2025) exposed 2.7 billion records — device IDs, Wi-Fi credentials, API tokens. Cloud-side defenses do matter when the attacker comes in through the back.
IoT security in 2026 is not a choice between edge and cloud. It spans silicon, firmware, connectivity, cloud, and process — and it is led from the engineering organization, not from the SOC.
This Q&A covers the questions we hear most often from engineering leaders, updated with the data that matters this year
Q: Why is IoT security a concern across every stage of development, not just the cloud?
Because attackers don’t respect your architecture diagram. They follow the path of least resistance, and every layer of an IoT system has a uniquely exploitable surface:
- Sensors and controllers are frequently the first target. They must be hardened with secure boot, hardware root-of-trust, and disabled debug interfaces. A $2 microcontroller with JTAG exposed is a gift to anyone with physical access.
- Edge compute processes sensitive data locally, often before any encryption is applied. Real-time security at this layer is non-negotiable.
- Fog compute keeps data and applications closer to the user, which can improve both privacy and resilience, but introduces its own orchestration and trust challenges.
- Cloud needs strong authentication, data encryption at rest and in transit, tight IAM scoping, and continuous posture management.
A useful mental model: if any layer of your stack trusts any other layer unconditionally, you have a security problem. Zero-trust IoT design assumes every boundary is hostile and every message requires authentication.
Q: What makes IoT systems especially hard to secure?
Four structural reasons:
- Legacy hardware. Palo Alto Networks research indicates 57% of IoT devices are highly vulnerable due to outdated operating systems or missing encryption. Many deployed devices predate the threat models we now take for granted.
- Default credentials. Industry studies find that 35% of IoT devices still ship or operate with “admin” as the default password, and fewer than 20% of consumer IoT apps enforce multi-factor authentication. The simplest attack is still often the most successful.
- Patch latency. It takes an average of 48 days for a manufacturer to release a critical security patch for an IoT device, and 75% of IoT devices lack an automated update mechanism. Meanwhile, 60% of IoT devices have unpatched known CVEs older than two years.
- Long lifecycles. Industrial IoT devices routinely remain deployed for 10–25 years. The cryptography that was strong in 2016 is weak today. Your device will outlive at least one generation of security assumptions — plan for it.
Q: Where does IoT security actually begin, in engineering terms?
At the silicon.
- Hardware security module (HSM) for key storage
- Secure boot with a measured, verified chain from ROM to application
- Trusted execution environment (TEE) for sensitive workloads
- Disabled or authenticated debug interfaces on production units
- Unique device identity provisioned in manufacturing, tied to the HSM
Without these, every software-layer defense is building on sand. An attacker who can flash arbitrary firmware can defeat any cloud authentication scheme.
Beyond silicon, threat modeling — analysis of intended and unintended use, attack surfaces, and risk — must be the first design-phase activity, not a pre-launch checkbox. If your threat model doesn’t exist until certification, it’s already too late.
Q: What are the most common threats we should design against in 2026?
Five categories account for the majority of production IoT incidents:
- Cyber-attacks against embedded systems. Cloud-connected infrastructures hold large volumes of sensitive data, making IoT fleets attractive pivots. The entire hardware and software architecture must be secured, not just the front door.
- Malicious insiders. Current or former employees, contractors, or partners who abuse legitimate access. Harder to detect than external attacks because the access is real.
- Denial-of-service. A malicious actor overwhelms a device, gateway, or backend to interrupt normal operation. In 2025–2026, the Aisuru/TurboMirai botnet achieved 20+ Tbps DDoS capability with 700% year-over-year growth, prompting Microsoft Azure to block a record 15.72 Tbps attack. Compromised IoT devices were the weapon.
- Poor authentication and weak certificate management. More incidents trace to expired certificates, weak passwords, and misconfigured mutual TLS than to novel exploits.
- The broken perimeter assumption. In cloud environments, devices and users are no longer on segmented, organization-controlled networks. Authentication must be strong at every connection, every time
Q: How does rigorous project management actually improve IoT security?
Because security problems are almost always schedule problems in disguise.
The SANS 2026 report found that 27% of organizations have experienced breaches as a direct consequence of workforce skills gaps, and 42% say those gaps are blocking adoption of new technologies. In industrial settings, that’s a delivery-risk issue, not a training one.
Rigorous project management helps by:
- Integrating security at every phase, not bolting it on at the end
- Matching methodology to the work — Waterfall for certification-bound hardware, Agile for software and cloud
- Running verification and validation that actually catches the bugs it was designed to catch, with documented traceability
- Keeping security on the critical path so it doesn’t become the first thing cut when a gate slips
When security is on the critical path, it gets done. When it’s “owned by everyone,” it gets done by no one.
Q: Engineering leaders often face a skills gap on IoT security. How should we address it?
Three options, usually in combination:
- Bring in external expertise. Embedded cryptography, secure boot chains, RF security, and cloud IAM for IoT are genuinely scarce skills. Partnering with a firm that has done a hundred of these projects can remove months from your roadmap.
- Build internal capability deliberately. Not every IoT security skill needs to be in-house — but the ability to judge the work does. Invest in one or two senior engineers who can credibly review an HSM integration or a threat model, even if execution is outsourced.
- Codify what you learn. Every project should leave your organization better instrumented for the next one: reusable secure-boot code, a refined threat-modeling template, a hardened cloud baseline.
Q: Tight deadlines vs. thorough security — how do we resolve this?
By changing when the work happens, not whether it happens.
Secure-by-design principles implemented from day one take less total time than security after the fact. They also produce better outcomes because the decisions that matter most — processor choice, boot architecture, key management, OTA strategy — are deeply entangled with security properties.
A pragmatic sequence:
- Threat model before architecture freeze, not after.
- Static analysis, fuzzing, and formal methods where relevant.
- Language-based security for safety-critical components (Rust adoption in embedded is accelerating for this reason).
- HSM + secure boot specified at silicon-selection time.
- OTA update capability proven functional before volume production.
Q: How do we scale IoT securely as the fleet grows?
Two things dominate:
- Cloud-edge balance. Processing the right data at the edge reduces both latency and attack surface. The less sensitive data that traverses public networks, the smaller the blast radius of any given breach.
- Continuous monitoring. Anomaly detection on device telemetry, certificate expiration monitoring, unusual traffic patterns — this is what makes a 10,000-device fleet defensible. Without it, you have a 10,000-node botnet waiting to happen.
At scale, the discipline is less about novel controls and more about consistency — every device configured the same way, rotated on the same schedule, observed through the same pipeline.
Q: How do we justify IoT security investment to stakeholders who see only cost?
With the numbers.
|
$4.44M |
Global average cost of a data breach. |
|
$10.22M |
US average — the highest of any country. |
|
$4.82M |
Average breach cost in critical infrastructure — up 107% year over year. |
|
$11.2M |
Healthcare average — the highest of any industry, for 15 consecutive years. |
|
2.7× |
Estimated ratio of non-compliance cost to compliance cost for IoT systems. |
Reframe the conversation: the question isn’t “what does security cost?” — it’s “what does the next breach cost, and what’s our exposure?” A secure-by-design IoT program shows ROI by reducing risk, cutting certification cycles, and building security primitives you can reuse rather than rebuild.
Q: What regulatory frameworks should we have on the roadmap right now?
At minimum, six:
- EU Cyber Resilience Act (CRA) — reporting obligations from September 11, 2026; main obligations December 2027
- UK PSTI Act — already in force; prohibits universal default passwords on consumer IoT
- US Cyber Trust Mark — voluntary labeling scheme for consumer IoT
- GDPR — fines related to IoT data breaches are up 40% since 2021
- HIPAA — if your device touches health data
- ISO/IEC 27001 — the widely adopted information security management baseline
For industrial IoT, add NIS2 (EU), sector-specific standards like IEC 62443 for industrial automation, and post-quantum readiness assessments as cryptographic migrations begin.
Looking ahead
Security is not a feature you add at the end. It’s a design property you either build in or spend years trying to retrofit. Engineering leaders who treat it as a core discipline — integrated across the full development lifecycle, updated continuously, with hard trade-offs made early — tend not to end up in the breach headlines.
At Orthogone, 110+ engineers work across hardware, software, FPGA, and cloud, with direct experience securing IoT systems from silicon to SaaS. If you’re navigating these trade-offs and want a second opinion, reach out.
Sources cited
Cisco 2026 State of Wireless Report • SANS 2026 Report • IBM Cost of a Data Breach 2025 • Palo Alto Networks IoT Vulnerability Research • IoT Analytics Connected Devices Report 2025 • Infosecurity Magazine • industry IoT security research aggregators.
