IoT Security: 4 Layers, NIST Guidance, and Practical Defenses

IoT security is the practice of protecting internet-connected devices, the networks they use, and the data they generate from unauthorized access and attack. It matters because a compromised camera, thermostat, or medical sensor can expose private data, knock critical services offline, or create physical safety risks. If you do one thing today, change every default password on your connected devices and move them onto their own isolated network segment.

“TL;DR:

• Maintain a live inventory and a defined patch schedule for every device, because unsupported firmware leaves newly discovered vulnerabilities open indefinitely.
• Before buying, check published update periods, signed firmware, and a vulnerability contact; devices without support can retain newly discovered flaws indefinitely.
• MQTT and CoAP do not become secure automatically: enable TLS or DTLS, require endpoint authentication, and keep brokers off the public internet.
• If devices handle EU personal data or US patient information, map collection, storage, access, and retention early to meet GDPR or HIPAA duties.

BitruptBuild IoT Platforms With Security in MindBitrupt builds custom software for healthcare and other sectors, with end-to-end solutions designed to be scalable and secure.Explore Bitrupt’s engineering services

Table of Contents

• 1. What iot security covers and why it matters
• 2. Common iot security risks and vulnerabilities
• 3. Real-world examples and notable incidents
• 4. Standards, frameworks, and authoritative guidance to consult
• 5. Practical best practices to secure IoT devices and networks
• 6. How engineering teams operationalize IoT security
• 7. IoT security architecture and design principles
• 8. Role of AI and machine learning in enhancing IoT security
• 9. IoT security testing and vulnerability assessment methods
• 10. Securing communication protocols specific to IoT
• 11. Regulatory and compliance requirements relevant to IoT security
• 12. Who should own IoT security inside an organization
• How we approach IoT security engineering
• FAQ
• Sources

1. What iot security covers and why it matters

Think of an IoT deployment the way you’d think of a house under construction. The device itself is just one room. The real exposure runs through every wire, pipe, and door connecting it to the rest of the structure. A single smart lock, for instance, is a device, but it’s also a network connection, a cloud account, a mobile app, and a stream of data about when you come and go. Securing the lock without securing the rest is like installing a steel front door and leaving the back window open.

IoT security covers four layers working together:

• Device hardware and firmware, the physical sensor, chip, and software running on it.
• Network connectivity, how the device talks to your router, gateway, or cellular connection.
• Cloud and backend services, where device data gets stored, processed, and analyzed.
• Data and privacy, the information collected, transmitted, and retained about you or your operations.

IoT differs from conventional IT in ways that matter for defense. Devices often run for years without a user interface, making it easy to forget they exist. Many ship with limited or no update mechanism. And because these devices sense and act in the physical world, a breach doesn’t stay digital. A compromised industrial sensor can misreport conditions; a hijacked camera can leak video; a hijacked fleet of devices can be weaponized into a denial-of-service attack that takes down unrelated services entirely.

2. Common iot security risks and vulnerabilities

Most IoT compromises trace back to a short list of preventable weaknesses, not sophisticated zero-day exploits. Attackers go after the easiest door first, and with IoT, that door is usually left wide open at the factory.

1. Default and weak passwords. Devices shipped with “admin/admin” or similar factory credentials remain the single most common entry point for automated attacks.
2. Unpatched firmware and end-of-life devices. Once a manufacturer stops issuing updates, every newly discovered flaw in that device stays open indefinitely.
3. Insecure network configurations. Devices placed directly on a flat home or office network, or routers left with factory settings, give attackers a path to everything else connected.
4. Unencrypted telemetry and weak protocols. Data sent in plain text between a device and its cloud service can be intercepted or altered in transit.
5. Privacy leakage through companion apps and cloud dashboards. Mobile apps and web portals paired with devices often collect more data than users realize, and that data is only as safe as the backend storing it.
6. Botnet recruitment. Compromised devices get conscripted into coordinated attack networks without their owners ever noticing.

That last risk isn’t theoretical. Mirai-based botnets have coerced hundreds of thousands of IoT devices into distributed denial-of-service attacks, with the 2016 attack on Krebs on Security alone involving more than 380,000 compromised devices and traffic exceeding 620 Gbps. That single incident reshaped how the security industry thinks about consumer devices: a camera or router that seems harmless to its owner can become one node in an attack affecting services the owner has never heard of.

3. Real-world examples and notable incidents

The Mirai botnet remains the clearest illustration of what happens when weak-by-default devices meet an attacker with scale. Mirai malware scanned the internet for IoT devices still running factory-default usernames and passwords, logged in, and recruited them into a botnet that launched some of the largest distributed denial-of-service attacks on record. The CISA alert on Mirai and related botnets describes the attack pattern and its scale, and the lesson has not gone stale: default credentials on internet-facing devices are still a primary vector for mass compromise years later.

More recently, CISA has warned about covert networks of compromised small-office and home routers and IoT devices being used by advanced threat actors to mask malicious traffic. These networks are dynamic, meaning the specific devices involved change constantly, which complicates traditional blocklist-based defenses.

A few lessons repeat across these incidents:

• Default credentials left unchanged are still the easiest way in, years after Mirai first proved the point.
• Routers at the network edge deserve the same hardening attention as the devices behind them.
• An up-to-date device inventory is the only way to know what needs patching, monitoring, or retiring.

Large-scale botnet activity isn’t a rare event. CISA’s advisory on covert device networks notes that these compromised fleets are actively used today, which means the defenses below aren’t optional hardening, they’re baseline maintenance.

4. Standards, frameworks, and authoritative guidance to consult

You don’t need to invent IoT security practices from scratch. Several government and standards bodies have already done the work of defining what “secure enough” looks like, and leaning on their guidance saves time during both procurement and engineering.

• NIST IR 8259 outlines foundational cybersecurity activities for IoT device manufacturers, recommending security-by-design practices and risk assessment before a product ever reaches market.
• NIST IR 8228 addresses IoT-specific risk considerations across the device lifecycle, including access control, management, and monitoring.
• CISA’s operational advisories, including the covert network advisory and the Mirai alert, give defenders concrete detection and mitigation steps tied to active threats.
• The FCC’s U.S. Cyber Trust Mark is a voluntary labeling program for consumer wireless IoT products, giving buyers a QR-linked registry showing support periods and update behavior before purchase.

Treat these as the baseline reference set for any IoT procurement or build decision. If a vendor or an internal team can’t map their practices to at least the NIST baselines, that’s a signal to ask harder questions before deployment.

5. Practical best practices to secure IoT devices and networks

Here’s the good news: most of what actually stops IoT attacks is unglamorous, well understood, and within reach of a small team or even a single IT admin. None of it requires buying a Ferrari when what you need is a reliable truck.

1. Change every default credential immediately. Use unique, strong passwords for each device, managed through a password manager rather than memorized or reused.
2. Enroll devices in a patch management process. Subscribe to vendor security advisories and apply firmware updates on a defined schedule rather than waiting for something to break.
3. Segment IoT devices onto a dedicated VLAN or guest SSID. Keeping cameras, sensors, and smart plugs off your main network limits what an attacker can reach if one device is compromised.
4. Use WPA3 for wireless networks and TLS or DTLS for data in transit. Encryption should extend from the device to the cloud, not just across the Wi-Fi hop.
5. Enable device authentication and multifactor authentication wherever it’s offered. A password alone is a single point of failure.
6. Monitor device behavior and collect logs. Establish a baseline for normal traffic so unusual spikes or new connections stand out quickly.
7. Build a procurement checklist before buying anything. Ask about supported update periods, whether firmware updates are cryptographically signed, and who to contact if a vulnerability is discovered.

Pro Tip: Before deploying any new IoT device, write down its expected traffic pattern on day one. That baseline becomes your early warning system the moment something starts behaving differently.

A couple of these deserve extra attention. Network segmentation is often the single highest-leverage control available, because it contains damage rather than trying to prevent every possible compromise. And signed firmware updates matter more than people realize: without cryptographic verification, an attacker who compromises an update channel can push malicious code that looks like a legitimate patch. Industry guidance from bodies like ITU-T treats signed, verified update channels as a baseline control rather than an advanced feature, for good reason.

Procurement discipline closes the loop. A device with no published update cadence and no vulnerability disclosure contact is a device you’ll eventually have to replace under pressure, usually after something has already gone wrong.

6. How engineering teams operationalize IoT security

Security-by-design works best when it’s built into the development process from day one, not bolted on after launch. That means threat modeling during the design phase, signed firmware from the first release, and a CI/CD pipeline for device software that treats every update the way you’d treat a production deploy to a web server, with testing, versioning, and rollback plans.

Operationally, the teams that handle this well share a few habits:

• Maintaining a live asset inventory so no device goes unpatched simply because nobody remembered it existed.
• Running a patch governance process with defined timelines for applying vendor updates.
• Keeping an incident response playbook specific to IoT, since a compromised device fleet behaves differently than a compromised server.

When an in-house team doesn’t have bandwidth for this kind of ongoing discipline, bringing in senior engineers for a scoped engagement or through staff augmentation can close the gap without requiring a full internal hire cycle, as outlined in the Infrastructure as Code security guidance.

7. IoT security architecture and design principles

A flat network where every device trusts every other device is the architecture equivalent of leaving all your house keys on one ring and handing it to a stranger. Two principles solve this: zero trust and defense-in-depth.

Zero trust means no device, user, or service is trusted by default, even if it’s already inside your network perimeter. Every connection gets verified, every time, regardless of where it originates. For IoT specifically, this translates into practical steps: devices authenticate before they can communicate, access is scoped to only what a device needs to function, and nothing gets a free pass just because it’s “internal.”

Defense-in-depth layers multiple independent controls so that one failure doesn’t cascade into a full breach. If a device’s password is somehow compromised, network segmentation should still contain the damage. If segmentation fails, encrypted traffic should still protect the data. If encryption is broken, monitoring should still catch the anomaly. No single control is asked to do all the work alone.

Together, these principles shift the question from “how do we stop every possible attack” to “how do we make sure one failure doesn’t become a catastrophe.” For organizations managing dozens or thousands of devices, that shift in framing changes how budgets and engineering time get allocated, usually toward segmentation and monitoring rather than trying to make every individual device impenetrable.

8. Role of AI and machine learning in enhancing IoT security

Traditional signature-based detection struggles with IoT traffic because the volume and variety of devices make manual rule-writing impractical. Machine learning models trained on normal device behavior can flag anomalies, like a thermostat suddenly sending large data volumes to an unfamiliar server, far faster than a human reviewing logs.

Behavioral baselining is where this adds the most value. Once a model understands what “normal” looks like for a given device type, deviations become easier to catch even when the specific attack pattern has never been seen before. This matters for IoT in particular because device fleets are large, repetitive, and predictable in their normal operation, which makes them good candidates for anomaly detection compared to more variable human-driven network traffic.

That said, machine learning models are only as good as the data and tuning behind them. A poorly tuned model generates alert fatigue; a well-tuned one becomes a genuine force multiplier for a small security team watching thousands of endpoints. For organizations exploring this path, building anomaly detection into the backend from the start, rather than retrofitting it later, tends to produce a cleaner data pipeline and fewer false positives down the line.

9. IoT security testing and vulnerability assessment methods

You can’t secure what you haven’t tested, and IoT devices need testing at multiple layers, not just the network perimeter. A thorough assessment typically covers firmware analysis, network traffic inspection, and the companion app or cloud API that the device talks to.

Firmware analysis involves extracting and examining the device’s software for hardcoded credentials, outdated libraries, or known vulnerabilities. Network-level testing checks whether traffic is encrypted, whether the device accepts unauthenticated commands, and whether it’s reachable from the broader internet when it shouldn’t be. API and app testing looks at the cloud backend and mobile companion app for the same issues you’d check in any web application: authentication flaws, insecure data storage, and overly permissive access controls.

Penetration testing and periodic vulnerability scanning should happen on a recurring schedule, not just once at launch, since new vulnerabilities get discovered in existing hardware and software long after release. For teams without in-house security testing expertise, this is often the point where bringing in outside specialists for a focused assessment makes more sense than trying to build that capability internally for a single product line.

10. Securing communication protocols specific to IoT

IoT devices often rely on lightweight protocols designed for constrained hardware, and two of the most common are MQTT and CoAP. Both were built for efficiency on low-power devices, which means security wasn’t always the first design priority, and both require deliberate configuration to lock down.

MQTT, widely used for device-to-cloud messaging, supports TLS encryption and username and password authentication, but neither is enabled by default on many implementations. Leaving an MQTT broker open without authentication means anyone who finds it can read or inject messages into your device fleet. CoAP, often used in constrained sensor networks, supports DTLS for encryption but similarly requires explicit configuration rather than arriving secure out of the box.

The practical takeaway is the same across both: never assume a protocol is secure just because it supports security features. Enable TLS or DTLS explicitly, require authentication on every broker or endpoint, and avoid exposing these services directly to the public internet when a VPN or gateway can sit in front of them instead. Protocol-level security is a configuration choice, not a given.

11. Regulatory and compliance requirements relevant to IoT security

Compliance obligations for IoT devices depend heavily on what data they collect and who they collect it from. If a device processes personal data from individuals in the European Union, GDPR applies regardless of where your company is based, and that includes obligations around data minimization, consent, and breach notification. Healthcare IoT devices that handle patient information in the United States fall under HIPAA, which requires specific safeguards around how that data is transmitted, stored, and accessed.

These frameworks don’t replace the technical controls described earlier, they sit on top of them. Encryption, access control, and monitoring aren’t just good engineering practice under these rules, they’re often explicit requirements. A healthcare wearable that transmits unencrypted patient data isn’t just a security gap, it’s a compliance failure with legal consequences.

The practical move for any organization building or deploying IoT devices that touch regulated data is to map data flows early: what’s collected, where it’s stored, who can access it, and how long it’s retained. That mapping exercise tends to surface gaps long before an auditor or regulator would, and it’s far cheaper to fix at the design stage than after a device is already in the field.

12. Who should own IoT security inside an organization

Ownership gets murky in IoT because responsibility spans procurement, engineering, and IT operations, and when everyone assumes someone else is covering it, nobody is.

• Procurement should own vendor vetting, including update cadence and support commitments.
• Engineering should own secure-by-design practices and signed firmware pipelines.
• IT or security operations should own ongoing monitoring, patching, and incident response.

When internal teams lack bandwidth for one of these functions, an external engineering partner can fill the gap on a scoped basis. Before signing with any vendor, ask three questions: What’s your update cadence? Is firmware signed? Who do we contact if we find a vulnerability?

How we approach IoT security engineering

We build and secure IoT software platforms with a focus on encryption, network segmentation, and scheduled patching rather than as an afterthought. Our IoT development services pair senior engineers with teams that need firmware-to-cloud integration done right the first time, whether through a scoped project or staff augmentation.

If your team needs help assessing or building a secure IoT platform, our AI and data engineering services can also support anomaly detection and monitoring for device fleets already in the field. Reach out through our IoT services page to scope an evaluation.

“— Usama

FAQ

What is IoT security?

IoT security is the set of practices and technologies used to protect internet-connected devices, their networks, and the data they generate from unauthorized access, misuse, or attack. It spans device hardware, firmware, network connectivity, and the cloud services devices connect to.

What does IoT stand for?

IoT stands for Internet of Things, referring to physical devices connected to the internet that collect, send, or act on data. Examples range from smart thermostats to industrial sensors and medical monitors.

What are 10 examples of IoT devices?

Common IoT devices include smart thermostats, security cameras, smart locks, voice assistants, wearable fitness trackers, connected medical devices, smart TVs, industrial sensors, smart plugs, and connected vehicles. Each one connects to a network and often to a cloud service, which means each carries its own set of security considerations.

Which is better, IoT security or cybersecurity?

IoT security is a specialized subset of cybersecurity, not a competing discipline. General cybersecurity covers networks, servers, and applications broadly, while IoT security addresses the unique challenges of constrained devices, physical-world impact, and limited update channels that traditional IT security practices don’t fully cover.

Sources

• Heightened DDoS threat posed by Mirai and other botnets | CISA
• Foundational Cybersecurity Activities for IoT Device Manufacturers (NIST IR 8259)
• Defending Against China-Nexus Covert Networks of Compromised Devices | CISA
• U.S. Cyber Trust Mark | Federal Communications Commission

Recommended

• IoT Software Development Services & Solutions