10  Common Pitfalls

Mistakes That Kill IoT Projects – and How to Avoid Them

10.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Diagnose common IoT pitfalls across consumer, enterprise, and industrial deployments
  • Prevent vendor lock-in by choosing interoperable devices and open standards
  • Calculate Total Cost of Ownership (TCO) for IoT projects using a 5-year framework
  • Secure IoT deployments using defense-in-depth strategies across all layers
  • Design for failure with graceful degradation, watchdog timers, and plausibility checks
  • Apply the IoT Redesign Framework when adding connectivity to everyday objects

Key Concepts

  • Vendor Lock-in: Dependency on a single vendor’s proprietary platform, protocol, or API that makes switching providers expensive.
  • Security Neglect: Failure to implement authentication, encryption, and firmware signing in IoT deployments, creating entry points for attackers.
  • Alert Fatigue: User desensitisation caused by excessive notifications, leading to critical alerts being ignored or all alerts being disabled.
  • Cloud Dependency: IoT design flaw where core device functions cease during internet outages due to lack of local processing fallback.
  • Integration Failure: Inability of an IoT system to connect with existing enterprise software, causing duplicate data entry and workflow disruption.
  • Privacy Overreach: Collection of more personal data than necessary for the stated purpose, violating user trust and regulatory requirements.
  • Scalability Gap: Architecture that works for a pilot deployment but fails under production load due to under-designed backend infrastructure.

Most IoT projects fail not because the technology is bad, but because of avoidable mistakes – like underestimating ongoing costs, forgetting about security, or assuming the internet connection will always work. Think of it like planning a road trip: buying the car is just the start – you also need fuel, insurance, maintenance, and a backup plan if a road is closed. This chapter teaches you the most common mistakes so you can avoid them before they become expensive problems.

Minimum Viable Understanding (MVU)

If you only have 10 minutes, focus on these three essentials:

  1. The #1 budget mistake: Hardware is only ~25% of the 5-year cost. Connectivity, cloud, and maintenance dominate – see the TCO table for the math.
  2. The #1 security mistake: Every IoT device is a potential network entry point. Always segment IoT devices onto a separate VLAN, change default credentials, and keep firmware updated.
  3. The #1 architecture mistake: Designing only for the happy path. Your system WILL lose connectivity, sensors WILL fail, and batteries WILL die. Design for graceful degradation from day one.

IoT Overview Series:

Security Deep Dives:

10.2 The IoT Pitfall Landscape

Before diving into specific pitfalls, it helps to see the full landscape of where IoT projects go wrong. Research consistently shows that 60-75% of IoT projects fail to move beyond the pilot stage, and the root causes fall into predictable categories.

Overview map of six IoT failure categories connected to a central project-risk hub. The categories are Smart Home, Enterprise and Industrial, Security, Architecture, Data and Privacy, and Scalability. Each category includes two short example pitfalls such as vendor lock-in, cloud-only design, privacy overreach, and pilot systems that do not scale.

10.3 Smart Home Pitfalls

Common Pitfall: Vendor Lock-in

The mistake: Choosing smart home devices and platforms based on features alone, without considering interoperability, resulting in a fragmented ecosystem where devices cannot communicate across brands.

Symptoms:

  • Unable to add devices from different manufacturers to existing automations
  • Migration costs exceeding the original investment when switching platforms
  • Duplicate hubs and apps for different device categories (one for lights, another for locks, another for cameras)
  • Smart home breaks when vendor discontinues cloud service or goes out of business

Why it happens: Vendors benefit from lock-in through recurring subscriptions and accessory sales. Early smart home adopters prioritized features over standards. Proprietary protocols (early Zigbee implementations, vendor-specific Wi-Fi) created incompatible ecosystems.

The fix: Prioritize devices that support open standards like Matter, Thread, and local API access. Choose platforms with strong third-party integrations (Home Assistant, Apple HomeKit, Google Home with Matter). Verify that devices can function without vendor cloud services (local control capability).

Prevention: Before purchasing, check if the device supports Matter or has documented local APIs. Prefer devices that store automations locally rather than requiring cloud connectivity. Maintain an inventory of device protocols and ensure new purchases are compatible with existing infrastructure.

Vertical decision flow for buying a smart device. It starts with open-standard support such as Matter or Thread, then checks for local control, cloud independence, and multi-platform compatibility. The outcomes are Safe to Purchase, Medium Risk that needs more integration checks, or High Lock-in Risk to avoid.

Common Pitfall: Network Security Neglect

The mistake: Connecting dozens of IoT devices to the home network without proper segmentation, using default passwords, and never updating firmware, creating multiple entry points for attackers.

Symptoms:

  • Devices still using factory-default credentials (admin/admin)
  • IoT devices on the same network segment as computers with sensitive data
  • No visibility into which devices are communicating with unknown servers
  • Firmware versions years out of date with known vulnerabilities

Why it happens: Consumers focus on convenience over security. Many IoT devices lack automatic update mechanisms. Home routers often do not support network segmentation by default. Users assume “it’s just a light bulb, what could go wrong?”

Real-world example: In 2016, the Mirai botnet compromised over 600,000 IoT devices – primarily cameras and routers with default passwords – and launched a DDoS attack that took down major websites including Twitter, Netflix, and Reddit. The attack exploited exactly this pitfall: devices deployed with factory credentials and never updated.

The fix: Create a separate VLAN or guest network for IoT devices. Change default passwords on all devices immediately after setup. Enable automatic firmware updates where available; schedule monthly manual checks for devices without auto-update. Use a router or firewall that can monitor IoT traffic for anomalies.

Prevention: Research device security before purchase (Does it support HTTPS? Does the vendor have a security disclosure policy? How long will they provide updates?). Block IoT devices from initiating connections to the internet unless required for core functionality. Consider a dedicated IoT security gateway that monitors for botnet activity and unauthorized communication.

Question 1: A homeowner has 15 smart devices from 5 different manufacturers, all connected to the main home Wi-Fi network alongside laptops and phones with banking apps. Which action provides the MOST immediate security improvement?

  1. Update firmware on all devices
  2. Create a separate VLAN or guest network for IoT devices
  3. Change the Wi-Fi password
  4. Install a new smart home hub

Answer: b) Creating a separate VLAN or guest network isolates IoT devices from computers with sensitive data. Even if an IoT device is compromised, the attacker cannot pivot to banking laptops. While firmware updates (a) are important, network segmentation provides immediate isolation of the entire attack surface. Changing the Wi-Fi password (c) does not address segmentation, and a new hub (d) does not solve the network architecture problem.

Question 2: You are shopping for a smart thermostat. Which combination of features BEST protects against vendor lock-in?

  1. Voice assistant support + smartphone app + nice design
  2. Matter support + local API + works without cloud
  3. Lowest price + good reviews + energy star rating
  4. Cloud dashboard + remote access + subscription analytics

Answer: b) Matter support ensures cross-platform compatibility, a local API enables third-party integration (e.g., Home Assistant), and cloud-independent operation means the thermostat continues working even if the vendor shuts down. Option (a) focuses on UX features that do not prevent lock-in. Option (c) ignores interoperability entirely. Option (d) actually increases lock-in by tying functionality to the vendor’s cloud service.

10.4 Enterprise and Industrial IoT Pitfalls

Common Pitfall: Underestimating Total Cost of Ownership

The mistake: Budgeting only for device acquisition costs while ignoring connectivity, maintenance, security updates, cloud services, and eventual device replacement.

Symptoms:

  • Project runs out of budget before deployment completes
  • Devices deployed but no budget for ongoing monitoring
  • Security vulnerabilities discovered but no budget for patches
  • Devices reaching end-of-life with no replacement plan

Why it happens: Hardware costs are visible and easy to quote. Software, connectivity, and maintenance costs are often hidden or underestimated. Vendors quote device prices without including ecosystem costs. Projects focus on deployment rather than long-term operations.

The fix: Use the 5-year Total Cost of Ownership (TCO) framework:

  • CapEx: Devices + installation + integration + platform setup
  • OpEx: Connectivity + cloud services + maintenance + security updates + staff
  • Replacement: End-of-life planning (typically 5-7 years for IoT devices)

Example calculation for 1,000 sensors:

Category Year 1 Years 2-5 Total 5-Year
Devices $50,000 $0 $50,000
Installation $25,000 $0 $25,000
Connectivity $12,000 $48,000 $60,000
Cloud Services $8,000 $32,000 $40,000
Maintenance $5,000 $20,000 $25,000
Total $100,000 $100,000 $200,000

The ongoing OpEx equals the initial CapEx over 5 years – a common pattern that surprises many organizations. Notice that device hardware represents only 25% of the total 5-year cost.

Prevention: Always calculate 5-year TCO before project approval. Include connectivity costs at $10-30/device/year. Budget for 15-20% annual maintenance. Plan for device replacement at year 5-7.

10.5 Interactive TCO Calculator

Calculate the 5-year Total Cost of Ownership for your IoT deployment by adjusting the parameters below.

Stacked cost breakdown for a 5-year 1,000-sensor deployment. Connectivity is the largest share at 30 percent or $60,000, followed by devices at 25 percent or $50,000, cloud services at 20 percent or $40,000, and installation and maintenance at 12.5 percent each or $25,000. The figure emphasizes that hardware is only one quarter of total cost.

Common Pitfall: Ignoring Edge Cases and Failure Modes

The mistake: Testing IoT systems only under ideal conditions, ignoring network outages, sensor failures, extreme weather, and adversarial inputs.

Symptoms:

  • System fails silently when connectivity is lost
  • No alerting when sensors report impossible values
  • Actuators left in dangerous states after partial failures
  • Security breaches through unexpected input handling

Why it happens: Development environments have reliable connectivity. Testing schedules are rushed. Edge cases are “rare” and deprioritized. Security testing requires specialized skills often absent from development teams.

The fix: Implement the following resilience patterns:

  • Graceful degradation: System continues core functions when cloud is unreachable
  • Watchdog timers: Devices reset to safe state if no heartbeat received
  • Plausibility checks: Reject sensor values outside physical limits (e.g., temperature > 200C from an indoor sensor)
  • Secure defaults: Fail closed (deny) rather than fail open (allow)

Prevention: Create a failure mode and effects analysis (FMEA) for every IoT component. Test network failure scenarios explicitly. Include security testing in every sprint. Conduct chaos engineering exercises (randomly kill components) in staging environments.

Resilience decision flow for IoT failures. An IoT system event first checks whether a failure was detected. If connectivity is lost, the system switches to edge processing and local cache. If sensor data is implausible, it triggers plausibility checks and alerts. If a component crashes, it uses watchdog reset and safe-state defaults. All recovery paths converge on event logging and operator notification before the system returns to degraded or recovered service.

Common Pitfall: Prototype-to-Production Gap

The mistake: Assuming that a working prototype on a lab bench with 5 devices will scale directly to a production deployment with 5,000 devices, without addressing connectivity contention, certificate management, data pipeline throughput, and operational monitoring.

Symptoms:

  • Prototype works flawlessly; production deployment has intermittent failures
  • Network congestion increases as devices are added (Wi-Fi channel saturation)
  • Cloud ingestion service cannot handle the volume of messages
  • No way to remotely diagnose or update devices after deployment
  • Manual provisioning that worked for 5 devices is impossible for 5,000

Why it happens: Prototypes are built for functionality, not scale. Lab networks have minimal congestion. Developers test in sequence, but production devices transmit concurrently. Provisioning, monitoring, and update infrastructure are afterthoughts.

The fix:

  • Capacity plan: Calculate messages per second at full deployment. Stress-test the pipeline at 2x expected load.
  • Automate provisioning: Use zero-touch provisioning with certificate-based authentication. Manual setup does not scale.
  • Design for observability: Every device must report health metrics (battery, signal strength, uptime, error counts).
  • Staged rollout: Deploy in waves of 10%, 30%, 60%, 100%. Validate each stage before expanding.

Prevention: Include scalability testing as a gate in the project plan. Budget for a device management platform from day one. Use load-testing tools that simulate thousands of concurrent MQTT/HTTP connections.

Question 3: A factory deploys 1,000 temperature sensors with a Year 1 budget of $100,000 covering devices and installation. Using the TCO framework, what is the approximate 5-year total cost?

  1. $100,000
  2. $125,000
  3. $200,000
  4. $500,000

Answer: c) $200,000. As shown in the TCO table, the Year 1 cost of $100,000 (devices + installation + first-year connectivity/cloud/maintenance) is matched by Years 2-5 operational costs of approximately $100,000 (ongoing connectivity at $48K + cloud at $32K + maintenance at $20K). Hardware alone is only 25% of total 5-year cost. Organizations that budget only the $100K initial investment will run out of funding.

Given: 1,000 sensors, $50K devices + $50K install = $100K Year 1

\[\text{Annual operational} = \$12K\,\text{(connect)} + \$8K\,\text{(cloud)} + \$5K\,\text{(maint)} = \$25K\] \[\text{5-year TCO} = \$100K\,\text{(Year 1)} + (\$25K \times 4) = \$200K\] \[\text{Hardware percentage} = \frac{\$50K}{\$200K} = 25\%\]

Key insight: Organizations budgeting only upfront hardware costs run out of funding in Year 2. The “invisible” 75% (connectivity $48K, cloud $32K, maintenance $20K over 4 years) explains why 60-75% of IoT projects fail to move beyond pilots.

Question 4: An IoT weather station reports a temperature of 847 degrees Celsius. What is the CORRECT system response?

  1. Log the value and forward it to the cloud dashboard
  2. Ignore the reading and wait for the next one
  3. Reject the value, use last known good reading, and alert operations
  4. Shut down the sensor immediately

Answer: c) Reject the value, use last known good reading, and alert operations. A plausibility check recognizes that 847C is physically impossible for a weather station (outside the range of -60C to +60C for typical deployments). The system should reject the impossible value to prevent downstream analytics from being corrupted, substitute the last known good reading to maintain data continuity, and alert operations because the sensor may be malfunctioning. Simply ignoring (b) leaves a data gap, logging the bad value (a) corrupts analytics, and shutting down (d) is an overreaction.

Question 5: A startup builds an IoT prototype with 10 devices that works perfectly in the lab. When deploying 2,000 devices in production, they experience frequent message drops and timeouts. What is the MOST LIKELY root cause?

  1. The cloud platform has a bug
  2. The devices have manufacturing defects
  3. Network contention and insufficient capacity planning for concurrent connections
  4. The lab prototype used different firmware

Answer: c) Network contention and insufficient capacity planning. This is the classic prototype-to-production gap. 10 devices transmitting in sequence rarely collide, but 2,000 devices transmitting concurrently overwhelm Wi-Fi channels, gateway buffers, and cloud ingestion endpoints. The solution involves capacity planning at 2x expected load, staged rollouts, and proper message queuing.

10.6 Security Best Practices: Defense-in-Depth

IoT deployments require defense-in-depth security – multiple overlapping layers so that no single point of failure compromises the entire system.

Five stacked layers of IoT defense in depth. From outermost to innermost the layers are Network Segmentation, Encryption, Authentication and RBAC, Device Security, and Data Privacy. Each layer includes a short implementation cue such as separate VLANs, TLS and AES, certificates, signed firmware, and data minimization.

10.6.1 Security Layer Details

Layer Measure Protects Against Implementation
1. Network VLAN segmentation Lateral movement after breach Separate IoT subnet with firewall rules
2. Encryption TLS 1.3 + AES-256 Eavesdropping, data theft Device certificates, encrypted storage
3. Authentication Mutual TLS, RBAC Impersonation, unauthorized access Certificate authority, role definitions
4. Device Secure boot, OTA updates Malware installation, known CVEs Signed bootloader, update server
5. Privacy PII removal, aggregation Privacy violations, regulatory fines Data pipeline anonymization

10.6.2 Case Study: Smart City Streetlights

A city deploys 100,000 IoT streetlights with remote monitoring and adaptive brightness. What risk-mitigation strategy addresses BOTH security and privacy concerns?

Answer: Implement defense-in-depth across all five layers. Specifically:

  • Network: Dedicated streetlight management network, isolated from city IT
  • Encryption: TLS for all command-and-control traffic; no plaintext
  • Authentication: Each lamp has a unique device certificate; revocation for compromised units
  • Device security: Secure boot to prevent malicious firmware; signed OTA updates
  • Privacy: Presence detection data (which could reveal pedestrian patterns) is aggregated to 15-minute windows before leaving the edge gateway
In 60 Seconds

This chapter covers common pitfalls, explaining the core concepts, practical design decisions, and common pitfalls that IoT practitioners need to build effective, reliable connected systems.

No single measure is sufficient: physical devices in public spaces face tampering, 100K devices create 100K potential entry points, and presence data reveals behavioral patterns.

10.7 Redesigning Everyday Objects for IoT

When transforming ordinary objects into IoT devices, the most common pitfall is focusing exclusively on “what cool things can this do?” rather than systematically evaluating the six dimensions of IoT product design.

Six redesign dimensions connected to a central IoT product redesign hub. The surrounding dimensions are Sensors, Connectivity, Processing, Power, User Interface, and Security. Each dimension includes a guiding design question such as what to measure, how to communicate, and how to keep the system safe.

10.7.1 Worked Example: Smart Water Bottle

Consider redesigning a simple water bottle as an IoT device:

Dimension Decision Rationale
Sensors Capacitive water level + temperature + IMU (tilt) Track hydration, detect drinking events
Connectivity BLE to smartphone Low power; phone relays to cloud
Processing Basic: count sips, calculate daily intake Minimal on-device; analytics in app
Power CR2032 coin cell (1 year life) User will not charge a water bottle daily
UI LED ring on cap + smartphone app Glanceable reminder; detailed data in app
Security BLE pairing + encrypted health data sync Health data is PII; GDPR implications

Common mistakes for this product: Using Wi-Fi (battery dies in days), requiring daily charging (users abandon it), collecting GPS data (unnecessary PII), no offline mode (bottle is useless without phone).

Connectivity choice cost impact for this product:

Option BOM Cost Battery Life Annual Cloud Cost User Friction
BLE (chosen) $1.50 (nRF52810) 12-18 months (CR2032) $0 (phone relays) Pair once, forget
Wi-Fi $2.80 (ESP32-C3) 3-5 days (500mAh LiPo) $0.50/device/year Daily charging required
NB-IoT $8.00 (BC66) + SIM 6-12 months (AA cells) $12/device/year SIM activation, subscription management

The BLE option costs $7.50 less per unit than NB-IoT at the BOM level. For a production run of 100,000 units, that is $750,000 saved on hardware alone, plus $1.2M/year in avoided cellular subscriptions. This analysis illustrates why connectivity selection is one of the highest-leverage decisions in IoT product design.

10.8 Interactive Connectivity Comparison

Compare the total cost of different connectivity technologies for your IoT product over its lifetime.

Question 6: You are designing a smart plant pot that monitors soil moisture and reminds users to water their plants. Which connectivity choice is MOST appropriate?

  1. Wi-Fi (802.11n)
  2. Bluetooth Low Energy (BLE)
  3. 4G LTE cellular
  4. LoRaWAN

Answer: b) Bluetooth Low Energy (BLE). A plant pot sits in a home near the user’s smartphone, making BLE’s short range acceptable. BLE’s ultra-low power consumption allows the pot to run for months or years on a coin cell battery. Wi-Fi (a) would drain the battery in days. Cellular (c) adds unnecessary subscription cost and power drain for a device that communicates infrequently with a nearby phone. LoRaWAN (d) is designed for long-range outdoor applications and is overkill for an indoor consumer product.

Question 7: A team is adding IoT capability to a commercial dishwasher for restaurants. They plan to use a smartphone app as the only user interface. What is the PRIMARY concern with this approach?

  1. Smartphones are expensive
  2. Restaurant staff may not have personal phones, and shared devices create hygiene and security issues in kitchen environments
  3. Smartphone apps are difficult to build
  4. The dishwasher does not need a user interface

Answer: b) In commercial kitchen environments, staff often share devices, wear gloves, and work in wet conditions. A smartphone-only interface creates practical barriers. The dishwasher should include a physical status display (LEDs or a small screen) for at-a-glance monitoring, with the app providing detailed analytics for managers. Context of use matters – what works for a home thermostat may fail in a commercial kitchen.

10.9 Pitfall Prevention Checklist

10.10 Interactive Security Checklist Scorer

Assess your IoT deployment against the 18-point pitfall prevention checklist. Check each item that applies to your project to see your readiness score.

Use this checklist before finalizing any IoT project plan. Each “No” answer represents a risk that should be addressed before proceeding.

Category Check Yes/No
Lock-in Devices support Matter, Thread, or open APIs?
Lock-in System works without vendor cloud?
Lock-in Data is exportable in standard formats?
Security Default credentials changed at provisioning?
Security IoT devices on separate network segment?
Security Firmware update mechanism in place?
Security Encryption for data in transit AND at rest?
Cost 5-year TCO calculated (not just hardware)?
Cost Connectivity costs included per device/year?
Cost Maintenance budget at 15-20% annually?
Resilience System degrades gracefully without cloud?
Resilience Plausibility checks on sensor values?
Resilience Watchdog timers and safe-state defaults?
Resilience FMEA completed for critical components?
Scale Load-tested at 2x expected device count?
Scale Zero-touch device provisioning automated?
Privacy PII removed or anonymized in telemetry?
Privacy Data retention policy defined and enforced?

Hey Sensor Squad! Let’s learn about mistakes people make with smart devices!

Sammy the Sensor says: “Imagine you buy a toy robot that only works with one brand of batteries. Then the company stops making those batteries. Your robot is useless! That’s called vendor lock-in – it’s like being stuck with one brand forever.”

Lila the Light Sensor explains: “Here’s another mistake – imagine leaving all the doors in your house unlocked because ‘nobody would break in.’ That’s what happens when people don’t change the default passwords on their smart devices. Every smart camera and doorbell should get a new, strong password right away!”

Max the Motion Detector warns: “The biggest surprise? Buying a smart device is like getting a pet. The pet food (electricity, internet, cloud service) costs WAY more over time than the pet itself! A $50 sensor might cost $200 over five years when you add everything up.”

Bella the Barometer adds: “And always have a backup plan! What happens to your smart thermostat when the internet goes down? A good smart device should keep working even without the internet – maybe not all features, but the basics should still work. That’s called graceful degradation.”

Remember: The best IoT engineers plan for things going WRONG, not just things going right!

10.11 Summary

Key Takeaways

  1. Vendor lock-in is the most common consumer pitfall. Prioritize Matter/Thread devices, local API access, and cloud-independent operation. Use the purchase decision flowchart before every buy.

  2. Network security neglect turns every IoT device into a potential entry point. Always segment IoT devices onto a separate VLAN, change default credentials at setup, and keep firmware updated. The Mirai botnet proved this lesson at internet scale.

  3. TCO underestimation is the most common enterprise pitfall. Hardware is only ~25% of the 5-year cost. Connectivity ($60K), cloud services ($40K), and maintenance ($25K) dominate – calculate the full 5-year TCO before project approval.

  4. Failure mode neglect causes silent production failures. Implement graceful degradation, watchdog timers, plausibility checks, and secure defaults. Test failure scenarios as rigorously as happy paths.

  5. The prototype-to-production gap catches teams that tested at 10 devices and deployed at 10,000. Load-test at 2x capacity, automate provisioning, design for observability, and roll out in stages.

  6. Defense-in-depth requires five security layers: network segmentation, encryption, authentication, device security, and data privacy. No single layer is sufficient on its own.

  7. IoT product redesign must address all six dimensions: sensors, connectivity, processing, power, user interface, and security. Neglecting any dimension leads to product failure.

10.12 Knowledge Check

10.13 Try It Yourself: Pitfall Audit Exercise

Challenge: Audit an existing IoT deployment (real or hypothetical) using the Pitfall Prevention Checklist from this chapter. Document at least three risks and propose mitigations.

Setup:

  1. Choose a scenario: smart home (20 devices), factory (500 sensors), or smart agriculture (100 field sensors)
  2. Download the checklist (18 checkpoints across Lock-in, Security, Cost, Resilience, Scale, Privacy)
  3. Interview stakeholders or research the deployment architecture

What to observe:

  • For each “No” answer on the checklist, estimate the risk severity (Low/Medium/High/Critical)
  • Prioritize the top 3 risks by potential business impact
  • For each risk, propose a mitigation with cost estimate

Example solution (Smart Factory - 500 Sensors): 1. Risk: Default credentials not changed (Security checkpoint) → Critical severity - Impact: Mirai-style botnet could compromise all 500 sensors → factory shutdown - Mitigation: Implement zero-touch provisioning with unique device certificates → $15K (gateway + CA infrastructure)

  1. Risk: No 5-year TCO calculated (Cost checkpoint) → High severity
    • Impact: $100K budget may run out after Year 2 when connectivity fees ($60K) + cloud ($40K) + maintenance ($25K) exceed hardware cost
    • Mitigation: Calculate full TCO ($200K over 5 years) and secure multi-year budget approval → $0 (planning exercise)
  2. Risk: No graceful degradation for connectivity loss (Resilience checkpoint) → Medium severity
    • Impact: Factory halts when cloud link fails (happens 2-3 times/year for 15-minute periods)
    • Mitigation: Add edge gateway ($2K) with local control loop for critical machines → maintains operation during outages

Extension: Present findings to stakeholders with a prioritized remediation roadmap and budget justification.

10.14 Concept Relationships

This Chapter’s Pitfalls Related Chapters How They Connect
Vendor Lock-in Device Evolution Matter and Thread standards prevent proprietary protocol lock-in
TCO Underestimation IoT Requirements The “Growing” and “Low Maintenance” characteristics directly impact 5-year costs
Security Neglect Security Fundamentals Defense-in-depth layers map to the five security checkpoints
Failure Mode Neglect Edge Computing Local processing enables graceful degradation when cloud fails
IoT Redesign Framework Design Methodology Six dimensions prevent single-perspective thinking in product design

10.15 See Also

Related Fundamentals:

  • IoT Introduction - Understanding the Three Ingredients Test prevents “smart” marketing pitfalls
  • IoT Perspectives - Cross-functional collaboration prevents single-perspective failures

Security Deep Dives:

Architecture and Design:

Cost Analysis:

10.16 What’s Next

Direction Chapter Description
Previous Worked Examples ROI calculations that complement these pitfall warnings
Related Application Domains Industry-specific IoT implementations
Related IoT Requirements Minimum requirements every IoT system must satisfy
Deep Dive Security Fundamentals Defense-in-depth strategies for IoT
Overview IoT Overview Index Summary and navigation for all chapters in this series