Further Reading: Mobile and IoT Security

Curated, annotated resources for going deeper. Each entry has a bold title, a citation, a one-to-two sentence note on why it matters, and a learning-path tag — 🏗️ Engineer, 📋 GRC, 🛡️ SOC, 📜 Cert — for whom it serves best. Tier-1 (verified canonical) and Tier-2 (attributed) sources only; nothing fabricated. Some documents evolve across editions — cite the current version when you use them.

Standards and primary docs (Tier 1)

OWASP IoT Top 10. OWASP Foundation — Internet of Things Project. The canonical, defender-facing list of the most critical IoT security weaknesses; "weak, guessable, or hardcoded passwords" sits at the top — the exact lesson of this chapter and of the Mirai case. Start here for IoT. 🏗️ 📜 🛡️

OWASP Mobile Top 10 and the OWASP MASVS (Mobile Application Security Verification Standard). OWASP Foundation — Mobile Security Project. The mobile counterpart: the top mobile application risks plus a testable verification standard. The MASVS is what you point developers and vendors at for "what secure looks like" on mobile. 🏗️ 📜

NIST IoT device cybersecurity guidance — the SP 800-213 and NISTIR 8259 family. National Institute of Standards and Technology. The authoritative U.S. guidance on baseline IoT device cybersecurity capabilities — device identification, configuration, data protection, and updatability — and how organizations should set device requirements. The clearest articulation of "what a device should be capable of before you buy it." 📋 🏗️

NIST SP 800-124, Guidelines for Managing the Security of Mobile Devices in the Enterprise. NIST. The reference for enterprise mobile-device security architecture and policy, including MDM/EMM and BYOD considerations. The document to ground a mobile standard on. 🏗️ 📋 📜

NIST Cybersecurity Framework (CSF) 2.0. NIST, 2024. Maps cleanly onto this chapter: Identify drives device inventory, Protect covers segmentation and device management, Detect covers monitoring. Use it to place your mobile/IoT controls in a program. 📋 📜

CIS Controls v8 — especially Control 1 (Inventory and Control of Enterprise Assets) and Control 12 (Network Infrastructure Management). Center for Internet Security. Control 1 is this chapter's first move — you cannot secure what you have not inventoried — and Control 12 is the segmentation discipline. The CIS Benchmarks also cover hardening for the manageable devices. 🏗️ 📜

PCI-DSS v4.0. PCI Security Standards Council. Directly governs Meridian's ATMs and POS: it mandates network segmentation of the cardholder data environment and addresses the security of devices that handle card data. Required reading if your fleet touches payments. 📋 🏗️

Free online and reports (Tier 1 / Tier 2)

CISA guidance and alerts on IoT and securing network devices. Cybersecurity and Infrastructure Security Agency. Practical, regularly updated advisories — including guidance on changing default credentials, segmenting devices, and securing remote-management interfaces. Good for current, actionable defender steps. 🛡️ 🏗️

The Verizon Data Breach Investigations Report (DBIR). Verizon, published annually. For the data behind the threat: how stolen/weak credentials and edge devices show up in real breach patterns year over year. Use it to ground risk arguments in evidence rather than anecdote (Tier 2 for any specific figure — cite the year and read the methodology). 📋 🛡️

Public analyses of the Mirai botnet. Multiple security researchers and CERTs; the original "Understanding the Mirai Botnet" academic measurement study is widely cited. The best way to internalize how default-credential compromise scales to an internet-level weapon, and why owner-side egress filtering is decisive. Treat specific numbers as Tier 2 and prefer the primary measurement study. 🛡️ 🏗️

Manufacturer-default-credential reality. Vendor manuals and community-maintained default-credential references. Skim a few device manuals' "default login" sections to feel viscerally why "the credentials are not secret" is literally true — they are published. (Use only to understand the exposure; never to access a device you don't own.) 🛡️ 📜

Books

Practical IoT Hacking. Fotios Chantzis, Ioannis Stais, et al., No Starch Press. Despite the offensive title, the value for a defender is understanding exactly how IoT and embedded devices fail — firmware, interfaces, protocols — so you can prioritize the right controls. Read it as a defender's threat model. 🏗️

Security Engineering. Ross Anderson, 3rd ed., Wiley. The chapters on the economics of security and on embedded/device security explain why IoT insecurity persists — the externality argument at the heart of this chapter and the Mirai case. The deepest "why," not just "how." 📋 🏗️

CompTIA Security+ Study Guide and CISSP All-in-One Exam Guide. Chapple & Seidl, Sybex; Harris & Maymí, McGraw-Hill. For exam framing of mobile (MDM, BYOD/COPE/CYOD/COBO, containerization), IoT/embedded/ OT, and segmentation. Map your reading to the domains listed in key-takeaways.md. 📜

Security Engineering (device and economics chapters, read closely). Ross Anderson, Wiley. Worth a second listing for a second purpose: beyond "why IoT is insecure," its treatment of how to reason about assurance on devices you did not build is the intellectual backbone of the contain-and-watch posture this chapter teaches. 🏗️ 📋

Vendor and platform documentation (Tier 1)

Your mobile platform's enterprise-management documentation. Apple Platform Deployment / Android Enterprise documentation. The authoritative source for how work profiles, supervised modes, conditional access, and selective wipe actually behave on the devices you manage — read the doc for the platform your fleet runs before writing a standard. Capabilities and constraints differ by platform and OS version. 🏗️

Your identity provider's conditional-access / device-compliance documentation. (e.g., Microsoft Entra conditional access; equivalent in your IdP.) Conditional access is the keystone control of §14.2; the exact signals you can gate on (encryption, OS version, jailbreak/root, enrollment state) are defined here, and they change over time. 🏗️ 🛡️

Cloud-provider IoT and device-defender services documentation. (AWS/Azure/GCP IoT and device-security offerings.) If your IoT connects through a cloud platform, its native device-identity, fleet-inventory, and anomaly-detection features are the cheapest place to get inventory and monitoring — read them before buying a third-party tool. (Ties to Chapter 15.) 🏗️

Talks and labs

Conference talks on IoT and embedded device security (defensive framing). DEF CON / Black Hat / BSides archives; many talks are freely posted. Watch a few device-teardown and botnet-analysis talks to build intuition for how these devices fail — then translate each failure into the control that contains it. Choose defensively framed talks and treat any technique as something to defend against. 🏗️ 🛡️

A hands-on home lab: build the contained IoT segment. In a lab you own, put a single IoT device (or a virtual stand-in) on its own VLAN/segment, write a default-deny rule allowing only its one server, deny its internet egress, and confirm with a capture that it can reach nothing else; then write and test the "off-allow-list" alert. This single lab makes §14.5 and Figure 14.2 permanent. 🏗️ 🧩

Tools and labs (for the manageable side)

A UEM/MDM trial or your platform's built-in management (e.g., Apple Business Manager / Android Enterprise work profiles, or your IdP's conditional access). Stand up a test enrollment, push a passcode and encryption policy, simulate a non-compliant device, and watch conditional access block it. Seeing the work-profile boundary and a selective wipe makes §14.2–14.3 concrete. 🏗️ 🧩

Passive network discovery in your own lab. Use a passive discovery/asset-inventory tool (or even careful traffic inspection) on a network you own to enumerate and fingerprint devices, then practice writing an allow-list and an "off-allow-list" alert. This is the inventory-and-monitor loop of §14.5, hands-on. 🏗️ 🛡️ 🧩

⚖️ Authorization note: every hands-on item above is for devices and networks you own or are explicitly authorized to test. Default-credential references and IoT-hacking material are for understanding exposure and building defenses — never for accessing a device you do not control. The same rule as everywhere in this book: your own lab, or written permission, and nothing else.

Supplementary guidance worth knowing

ENISA guidance on IoT and smart-infrastructure security. European Union Agency for Cybersecurity (ENISA). A solid, vendor-neutral European counterpart to the NIST IoT material, with baseline recommendations and threat taxonomies for connected devices; useful for cross-referencing and for programs with an EU footprint. 📋 🏗️

Cloud Security Alliance (CSA) IoT guidance. Cloud Security Alliance. Practical guidance on securing IoT in conjunction with cloud back-ends — the "phone-home to a vendor cloud" dependency this chapter flags — bridging the device and cloud (Chapter 15) perspectives. 🏗️ 📋

FDA / sector guidance on medical-device cybersecurity (if your sector applies). U.S. Food and Drug Administration premarket/postmarket medical-device cybersecurity guidance, and equivalent sector regulators. For healthcare and other regulated-device sectors, the device-security expectations are increasingly written into sector regulation; know the rules that bind your devices. 📋

Manufacturer security advisories and end-of-support notices for your deployed devices. (Per-vendor.) The least glamorous and most important ongoing source: subscribe to advisories and EOL notices for every device class in your inventory, because "the firmware is now unsupported" is a risk event you must catch and feed into the contain-or-replace decision. 🏗️ 🛡️