COMP 6660 · Enterprise Cybersecurity Mobile and IoT Security

00 Introduction

Lesson 5.6 examined container and virtualisation security — the platforms on which modern workloads are delivered. This lesson examines the devices through which those workloads are accessed and the devices that increasingly generate the data those workloads process: mobile devices and the Internet of Things.

The device estate has changed the shape of the enterprise boundary. Employees work from smartphones and tablets, frequently using personal devices for corporate work. Enterprises deploy sensors, cameras, building-management systems, industrial controllers, medical devices, and a long tail of connected equipment that were purchased for operational reasons and connected for convenience. Each of these devices is an endpoint — and each expands the enterprise's attack surface into places it did not previously reach.

Mobile and IoT security are frequently treated together because they share a common characteristic: both are populations of devices that the security team does not fully control. Mobile devices are frequently personally owned, are replaced on the consumer refresh cycle rather than the enterprise one, and run operating systems the enterprise does not configure. IoT devices are frequently purchased by business units without security involvement, run firmware the enterprise did not write, cannot accept a security agent, and are supported for a decade by vendors the enterprise has no relationship with.

This lesson examines mobile and IoT security in detail. It establishes why the topic matters and how the device estate has changed the enterprise perimeter. It examines the composition of the device estate — corporate, personal, and operational devices. It examines the security models of the dominant mobile platforms — sandboxing, code signing, and hardware-backed trust. It examines the mobile threat landscape. It examines enterprise mobility management — enrolment, policy, application containment, and conditional access. It examines IoT architecture and the IoT attack surface. It examines documented IoT threats and incidents. It examines the controls that address IoT risk — device identity, secure boot, firmware signing, credential management, and network segmentation. It examines governance of the device estate. It examines monitoring and incident response for devices that cannot host an agent. And it closes with the pitfalls that recur across mobile and IoT programmes.

The material here builds directly on Lesson 5.2 (endpoint security) — mobile and IoT devices are endpoints, and the endpoint principles apply with additional constraints. It builds on Lesson 2.5 (identity and access management) and Lesson 2.7 (Zero Trust) — device identity and device posture are central to both. It prepares for Lesson 5.8 (critical infrastructure security), which examines operational technology in depth, and for Unit 6, where device governance becomes part of the enterprise's broader governance and risk framework.

01 Learning objectives

By the end of this lesson you should be able to:

These objectives contribute to Unit 5 outcome U5.3 (emerging infrastructure threats) and to Module 2 outcomes M2.9 and M2.10. See the Unit 5 learning outcomes page for the full mapping.

02 Why mobile and IoT security matters

The device estate is now the largest and least controlled part of most enterprise attack surfaces. Understanding why its security matters clarifies the priorities that inform the rest of this lesson.

The consequence of mobile and IoT security failures

Mobile and IoT security failures appear across documented incidents:

• Mobile malware and malicious apps. Malicious applications distributed through official and third-party stores — harvesting credentials, exfiltrating data, or enrolling the device in fraud.
• Compromised corporate credentials. Credentials harvested from mobile devices through phishing, malicious applications, or insecure storage — providing access to enterprise systems.
• Lost and stolen devices. Devices lost or stolen with unencrypted corporate data, cached credentials, or active sessions.
• IoT botnets. Large populations of compromised IoT devices — cameras, routers, recorders — used for distributed denial-of-service attacks and for criminal infrastructure.
• IoT as a network foothold. Compromised IoT devices used as a pivot into enterprise networks — exploiting flat network architectures and trust relationships.
• Building and facility compromises. Compromised building-management systems, HVAC controllers, and physical security systems — affecting physical operations and safety.
• Safety-critical device compromise. Compromised medical, industrial, or safety systems — where security failure becomes a safety failure.

The pattern is consistent: mobile and IoT security failures exploit the specific characteristics of these devices — consumer lifecycles, personal ownership, constrained hardware, long support horizons, and physical accessibility. Securing the device estate requires controls that address these characteristics, in addition to the endpoint and application controls examined in previous lessons.

03 The device estate

The device estate is the collection of devices through which the enterprise is accessed and in which the enterprise has an interest. It is not homogeneous — different classes of device have different ownership, different lifecycles, different capabilities, and different security implications.

Classes of device

What makes the device estate hard

• Ownership is mixed. The enterprise does not own the device in the BYOD case, and therefore cannot apply the same controls it applies to corporate assets. Privacy law and employee relations constrain what can be monitored and what can be wiped.
• Lifecycles are mismatched. Mobile devices are replaced on a two-to-four-year consumer cycle; IoT devices are frequently deployed for ten years or more. Security controls must remain effective across both.
• Capabilities are constrained. IoT devices have limited CPU, memory, power, and bandwidth. They cannot run an EDR agent, cannot perform full-disk encryption comfortably, and cannot always perform a firmware update safely.
• Visibility is partial. A large proportion of devices are unmanaged, unregistered, or unknown. Security teams work with incomplete inventories.
• Procurement is decentralised. IoT devices are frequently purchased by facilities, operations, research, or clinical teams — with no security review, no standard, and no requirement to register the device.
• The devices are physical. Devices can be stolen, opened, probed with hardware interfaces, or substituted. Physical access defeats many purely software controls.

Why device identity matters

Because the device estate is mixed, uncontrolled, and partially invisible, device identity becomes the organising principle for its security. A device that can be identified can be assessed, authorised, segmented, monitored, and revoked. A device that cannot be identified cannot be governed at all.

Device identity connects directly to Lesson 2.5 (identity and access management) and Lesson 2.7 (Zero Trust). In a Zero Trust model, access decisions depend on the identity and posture of the requesting entity — and for the device estate, that means being able to answer: what is this device, who owns it, what state is it in, and what should it be allowed to reach?

04 Mobile platform security models

Modern mobile platforms — iOS and Android — incorporate substantial security architecture. Understanding these models is necessary because the enterprise's mobile controls operate on top of them, and because many mobile threats consist of circumventing them.

Common architectural elements

Despite their differences, iOS and Android share a common security architecture:

• Application sandboxing. Each application runs in its own sandbox — with its own filesystem area, its own process space, and restricted access to system resources and to other applications' data.
• Code signing and integrity. Applications must be signed by a recognised developer identity, and the signature is verified before execution. Unsigned or modified code is refused.
• Permission model. Applications must request access to sensitive resources — camera, microphone, location, contacts, files — and the user (and in managed contexts, the enterprise) grants or denies that access.
• Secure boot chain. Each stage of the boot process verifies the next — from hardware root of trust through bootloader to operating system — so that a modified system does not start.
• Hardware-backed key storage. Cryptographic keys can be stored in a hardware-backed keystore or secure element — where they cannot be extracted even if the operating system is compromised.
• Full-device encryption. Device storage is encrypted by default, keyed to the device passcode and to hardware-backed keys.
• Biometric authentication. Fingerprint and facial recognition provide convenient strong authentication, backed by hardware.
• Managed device APIs. Both platforms expose management APIs — Apple's Device Management framework and Android Enterprise — through which enterprises can configure and control devices.

Platform-specific characteristics

Why platform protections are not sufficient

Mobile platform security is genuinely strong — stronger, in many respects, than traditional desktop operating systems. But it is not sufficient on its own for enterprise purposes:

• The user can be attacked, not just the platform. The most common mobile compromise is not a platform exploit — it is the user being persuaded to disclose credentials, approve a malicious permission, or install an application from an untrusted source.
• Platform protections can be removed. Jailbreaking and rooting disable the platform's protections — and a jailbroken or rooted device should be treated as untrusted, regardless of what its security architecture claims.
• Applications are the risk surface. An application that the user legitimately grants permissions to can exfiltrate data within the permissions it holds — sandboxing does not prevent an application from misusing access it was granted.
• The platform does not know enterprise context. The platform cannot know that a device is accessing regulated data, that a device is out of patch compliance, or that a particular application is prohibited by enterprise policy. That requires management.
• Data crosses platform boundaries. Corporate data on a mobile device can be copied, shared, screenshotted, backed up to personal cloud storage, or synchronised to a personal account — platform sandboxing does not prevent data from leaving through legitimate channels.

05 The mobile threat landscape

Mobile threats differ from traditional endpoint threats. The platform is harder to compromise, so attackers focus on the user, the application ecosystem, the network, and the data flows around the device.

Categories of mobile threat

Managing mobility risks in practice

The practical consequence of the mobile threat landscape is that the enterprise must protect against threats it cannot see:

• Assume the device may be compromised. Design access so that a compromised device does not provide broad enterprise access — through least privilege, through short-lived credentials, and through conditional access.
• Assume the user may be deceived. Design authentication so that a deceived user does not hand over durable access — through phishing-resistant MFA, through device binding, and through anomaly detection.
• Assume the network is hostile. Design access so that traffic on untrusted networks is protected — through application-layer encryption, through certificate pinning, and through managed network profiles.
• Assume data will leave. Design data protection so that corporate data is contained and controlled even after it reaches the device — through application-level containment, through encryption, and through data-loss prevention.

06 Enterprise mobility management

Enterprise mobility management (EMM) is the set of technologies, policies, and processes through which enterprises manage mobile devices and protect corporate data on them. It spans device management, application management, and identity-based access control.

The EMM capability stack

Ownership models and their implications

Key EMM controls

• Enrolment and compliance policy. Devices must meet defined requirements — OS version, encryption, passcode strength, jailbreak/root status — to be considered compliant.
• Configuration profiles. Enterprise configuration — Wi-Fi, VPN, certificates, email, and restrictions — pushed to devices and enforced.
• Application management. A defined catalogue of approved applications; blocking or restricting installation from unknown sources; managed application configuration and per-application VPN or tunnel.
• Data containment. Restricting corporate data to managed applications — preventing copy to personal applications, restricting sharing, and disabling screenshots for sensitive content.
• Conditional access. Access to enterprise services granted only when the device meets compliance requirements — the integration point with Zero Trust.
• Selective wipe. Removing corporate data and applications without removing personal data — the essential control that makes BYOD acceptable.
• Certificate-based authentication. Device certificates issued at enrolment and used for Wi-Fi, VPN, and application authentication — stronger than passwords and bound to the device.
• Jailbreak and root detection. Detecting and acting on compromised platform integrity — typically by blocking access.
• Mobile threat defence. On-device detection of malicious applications, network attacks, and phishing.

Limitations and tensions

EMM is powerful but not unlimited. The enterprise should understand its limits:

• Privacy tension. BYOD management creates a tension between enterprise security and employee privacy. Monitoring device activity or wiping a personal device may be legally constrained and is frequently resisted. The resolution is to manage the corporate data and applications, not the whole personal device.
• Enrolment evasion. Users may avoid enrolment, may use unmanaged devices and shadow applications, or may remove management where the platform permits it. Access controls must therefore work for unmanaged as well as managed devices.
• Platform limitation. Some controls are unavailable on unmanaged devices — full-device wipe, some configuration restrictions, and some application-blocking capabilities.
• Operating system fragmentation. Enterprises cannot force OS updates on personally owned devices. Compliance policy must therefore define a minimum supported version and block access below it.
• User experience. Aggressive EMM policy reduces adoption and drives workarounds. Controls must be proportionate, or users will route around them.
• Coverage gaps. EMM covers enrolled devices. Devices that are not enrolled — contractor devices, unmanaged personal devices accessing browser-based services — require separate controls.

07 IoT architecture and the IoT attack surface

The Internet of Things is not a single technology — it is a broad category of devices that sense, actuate, or communicate, connected to networks and frequently to cloud services. Understanding IoT architecture clarifies where the security problems arise.

IoT architecture layers

08 IoT threats and incidents

IoT threats are not theoretical. Documented incidents demonstrate the patterns that recur across consumer, enterprise, and industrial deployments.

Categories of IoT threat

Documented incident patterns

Publicly documented IoT incidents illustrate the recurring patterns:

• Mirai and its descendants. The Mirai botnet (2016) recruited hundreds of thousands of IoT devices — cameras and routers — using a list of default credentials, and used them for record-scale distributed denial-of-service attacks. Mirai's source code was released, producing a durable family of variants that continue to operate.
• Default credential exploitation. A substantial proportion of IoT compromises begin with default or shared credentials — the single most exploited weakness in the IoT estate.
• Building management system compromise. Documented intrusions into building-management and HVAC systems — used for network access, and occasionally for physical disruption.
• Camera and video system compromise. Large-scale compromise of IP cameras and video recorders — used for botnets, for surveillance, and for extortion.
• Clinical and medical device compromise. Vulnerabilities and incidents in connected medical devices — leading to recalls, regulatory action, and clinical risk assessments.
• Botnet-driven DDoS against critical services. Attacks on DNS providers, hosting providers, and communications services using large IoT botnets — with consequences for unrelated organisations.
• Smart-home and consumer device compromise. Home routers, cameras, and assistants compromised at scale — with consequences for remote workers connecting to enterprise services from those networks.

Why these patterns persist

• Default credentials are never changed. Devices are deployed without a password change, frequently because there is no interface through which to change it conveniently.
• Devices are never patched. Either because no update mechanism exists, or because updating thousands of devices is operationally impractical, or because nobody owns the responsibility.
• Devices are not monitored. IoT networks frequently have no monitoring, so compromise is not detected.
• Devices are on the wrong network. IoT devices placed on the corporate network — providing a foothold where segmentation would have contained the impact.
• Nobody owns IoT security. Devices are purchased by operations, installed by facilities, connected by IT, and monitored by nobody.

09 IoT security controls

IoT security controls fall into two groups: controls built into the device, and controls applied to the device's environment. Because many deployed devices cannot be changed, environment controls frequently carry more of the security burden than device controls.

Device-level controls

Environment-level controls

Because many deployed IoT devices cannot be changed, the environment controls carry much of the burden:

• Network segmentation. IoT devices should be placed on dedicated network segments, separate from corporate user and server networks. Segmentation limits the consequence of device compromise — a compromised device can reach only the services its segment permits.
• Micro-segmentation and egress control. Within the IoT segment, restrict which devices can reach which services, and restrict outbound traffic to known destinations — preventing command-and-control communication and data exfiltration.
• No inbound access. IoT devices should not be reachable from the internet or from general corporate networks — administrative access should be through controlled channels.
• Network access control. 802.1X or equivalent to authenticate devices onto the network; profiling to identify device types; automatic placement of unknown devices into quarantine.
• Gateway mediation. Where devices cannot be secured, a gateway can terminate device protocols, authenticate devices, enforce policy, and provide a single controlled egress point.
• Monitoring at the network layer. Because devices cannot host an agent, network-based monitoring is the primary detection mechanism — traffic baselines, anomaly detection, and known-bad destination detection.
• Procurement requirements. Security requirements written into procurement — no default credentials, signed firmware, supported update path, documented lifecycle — so that new devices enter the estate with the required capabilities.
• Lifecycle management. Inventory of devices; tracking of vendor support status; planned replacement of devices that are no longer supported; secure decommissioning.

Standards, guidance, and regulation

IoT security is increasingly shaped by published standards and by regulation:

Applying the controls to an existing estate

Most enterprises face an existing IoT estate that was deployed without security requirements. The practical sequence is:

1. Discover. Find the devices — network scanning, traffic analysis, procurement records, and physical inspection.
2. Inventory. Record what each device is, who owns it, what it does, and what it connects to.
3. Classify. Determine the consequence of compromise for each device or device class.
4. Segment. Move devices onto appropriate network segments — the highest-value action for an existing estate.
5. Restrict. Apply egress and inter-segment restrictions — limiting what each device can reach.
6. Harden. Change default credentials, disable unused services, and apply vendor guidance where the device supports it.
7. Monitor. Establish network-based monitoring and behaviour baselines for the device population.
8. Plan replacement. Identify devices that cannot be secured and plan their replacement on a defined schedule.

10 Governing the device estate

Technical controls are necessary but insufficient without governance. The device estate is large, distributed, and frequently outside the security team's direct control — so the enterprise needs policy, ownership, inventory, and procurement discipline to make the technical controls effective.

Elements of device estate governance

Shadow devices and the discovery problem

Shadow devices — devices connected to enterprise networks or accessing enterprise services without the security team's knowledge — are one of the most persistent problems in device estate governance:

• Shadow IoT. Devices purchased by business units, facilities, research, or clinical teams and connected without security involvement — cameras, sensors, environmental monitoring, lab equipment.
• Shadow mobile. Personal devices accessing corporate services through browsers without enrolment — invisible to EMM.
• Shadow connectivity. Devices connected through personal hotspots, through unmanaged network segments, or through cellular connections that bypass enterprise network controls.

Discovery is the mitigation — through network monitoring, through integration with procurement and accounts-payable records, through physical inspection of facilities, and through the network access control system placing unknown devices into quarantine. Beyond discovery, the sustainable solution is making registration easy and making unregistered connectivity ineffective.

Device governance and Zero Trust

Device governance is the practical expression of Zero Trust principles in the device estate:

• Explicit verification. Every device presents an identity; every access request is evaluated on device identity, device posture, and user identity together.
• Least privilege. Devices reach only the services their class requires — enforced by network architecture rather than by relying on the device to behave.
• Assume breach. Segmentation and egress control limit the consequence of device compromise — so that a compromised device does not provide a path to higher-value systems.

11 Device monitoring and incident response

Monitoring and incident response for the device estate must work under a constraint that does not apply to managed endpoints: many devices cannot host an agent, cannot produce detailed logs, and cannot be accessed for investigation. Detection and response must therefore rely on the environment as much as on the device.

Telemetry sources for the device estate

Detection patterns

Because device-level detection is limited, detection focuses on behavioural patterns observable from the environment:

• New devices appearing on the network — unknown MAC addresses, new device fingerprints, or devices appearing in unexpected segments.
• Devices contacting unusual destinations — DNS or network connections to destinations not previously observed for that device class, indicating command-and-control or exfiltration.
• Devices communicating at unusual volumes or times — a sensor transmitting far more than its baseline, or a device active outside its operational hours.
• Authentication anomalies — a device authenticating from an unexpected location, or repeated authentication failures.
• Compliance drift — devices falling out of compliance with policy, losing encryption, or failing integrity checks.
• Jailbreak and root detection — managed mobile devices reporting compromised platform integrity.
• Certificate and credential anomalies — expired or revoked certificates in use, or credentials used from unexpected devices.
• Firmware version anomalies — devices running firmware versions that were never deployed by the enterprise.

Mobile incident response

Mobile incidents require specific response considerations:

• Contain the account, not only the device. Mobile compromise frequently involves credential compromise — so response must include session revocation, credential reset, and review of account activity, not only device action.
• Selective wipe before full wipe. On personally owned devices, remove corporate applications and data — preserving personal data and the employee relationship.
• Device isolation. Where the platform supports it, block the device from enterprise access immediately — through conditional access, through network access control, and through certificate revocation.
• Evidence collection. Capture EMM records, authentication logs, and — where feasible and lawful — device state before wiping.
• User communication. Engage the user early and clearly — they are frequently both a source of information and a participant in remediation.
• Re-enrolment. Return the device to service only after remediation — a device reset and re-enrolment, or a replacement device.

IoT incident response

IoT incidents present different constraints:

• Containment by network. Because the device cannot be cleaned or easily accessed, containment is typically achieved by isolating the device's network segment or by blocking its traffic.
• Evidence collection is difficult. Devices may have no accessible filesystem, no usable logs, and no capability to run forensic tools. Evidence frequently comes from network capture rather than from the device.
• Remediation by replacement. Where a device cannot be cleaned, remediation is replacement or re-flashing — and where re-flashing is not possible, permanent removal from the network.
• Population-level response. A single vulnerable device usually implies a vulnerable model — so response should address the whole population, not just the device where the incident was detected.
• Credential rotation. Because IoT credentials are frequently shared across a device model, response should include rotation of credentials for the affected population.
• Physical coordination. Response frequently requires physical access — to power-cycle, to remove, or to replace the device — requiring coordination with facilities, operations, or clinical staff.
• Safety considerations. Where devices affect physical operations or safety, containment decisions must involve the operational owners — an isolated controller may halt a production line or affect patient care.
• Vendor engagement. Remediation frequently depends on the vendor — for firmware, for guidance, or for replacement. Vendor contact details and support status should be recorded in the inventory.

Integrating device response into the SOC

Device incidents should be handled within the enterprise's incident response capability, not in a separate silo:

• Detection sources integrated into the SIEM. EMM, identity, network, and IoT platform telemetry all feed the same detection and correlation platform.
• Playbooks for device classes. Defined response playbooks for lost devices, compromised mobile credentials, compromised IoT devices, and IoT botnet participation.
• Roles and authority. Clear authority to isolate devices and segments — including the authority to interrupt operational systems where necessary.
• Notification obligations. Device incidents may carry regulatory notification obligations — particularly where personal data or clinical systems are involved.
• Post-incident improvement. Feedback into procurement requirements, into segmentation architecture, and into monitoring coverage.

12 Common pitfalls

Enterprise mobile and IoT security programmes fail in predictable ways. Recognising the pitfalls accelerates improvement.

Pitfall 1 — Treating mobile devices as small laptops

Applying desktop endpoint practices to mobile — expecting full device management, agent-based detection, and enterprise-controlled patching — producing controls that are unusable on personally owned devices and inappropriate for mobile platforms.

Mitigation: Adopt mobile-appropriate controls — application containment, conditional access, and device compliance signalling. Manage the data, not the whole device.

Pitfall 2 — BYOD without governance

Permitting personal devices to access corporate services without policy, without management, and without any ability to revoke access — creating unmanaged access to enterprise data.

Mitigation: Define a BYOD policy. Require enrolment for corporate application access. Apply conditional access based on device compliance. Provide a documented selective-wipe commitment.

Pitfall 3 — Relying on MDM alone

Treating device enrolment as the whole mobility security programme — with no conditional access, no application containment, no mobile threat defence, and no protection for unmanaged devices.

Mitigation: Build a layered mobility programme — enrolment, application management, conditional access, threat defence, and identity integration.

Pitfall 4 — Ignoring unmanaged and shadow devices

Focusing entirely on enrolled devices while unmanaged personal devices, contractor devices, and shadow IoT continue to access enterprise networks and services.

Mitigation: Discover unmanaged devices through network monitoring and NAC. Apply controls that work without enrolment — browser-based access controls, network-level restrictions, and quarantine for unknown devices.

Pitfall 5 — IoT purchased outside security

IoT devices purchased and deployed by business units without security review, without registration, and without the security team's knowledge — producing a growing unmanaged estate.

Mitigation: Establish a procurement policy requiring security review. Provide an easy registration process. Integrate with procurement and accounts-payable. Monitor for unregistered devices.

Pitfall 6 — Default credentials left in place

Devices deployed with vendor default credentials — the single most exploited weakness in the IoT estate.

Mitigation: Require credential change at deployment. Prefer devices with unique per-device credentials. Where defaults cannot be changed, isolate the device and compensate with network controls.

Pitfall 7 — No firmware update path

Devices deployed with no mechanism for applying security updates — permanently vulnerable from the day of installation.

Mitigation: Include a supported update path in procurement requirements. Where devices have no update path, isolate and plan replacement. Track vendor support status in the inventory.

Pitfall 8 — IoT on the corporate network

IoT devices connected directly to corporate user or server networks — providing a foothold from which to reach higher-value systems.

Mitigation: Segment IoT onto dedicated networks with restricted inter-segment traffic and controlled egress. Apply network access control to place devices correctly.

Pitfall 9 — Procurement without security requirements

Purchasing devices on price and features alone — with no security requirements — and then attempting to secure them after deployment.

Mitigation: Define minimum security requirements for device classes. Assess vendors. Make security a purchasing criterion. Align with recognised baselines (ETSI EN 303 645, NISTIR 8259).

Pitfall 10 — Device security treated separately from the enterprise programme

Mobile and IoT security managed by separate teams with separate tools and separate processes — disconnected from the enterprise's identity, network, monitoring, and incident response capabilities.

Mitigation: Integrate device security with the enterprise security programme. Feed device telemetry into the SIEM. Include devices in Zero Trust policy. Apply the same governance, risk, and incident response processes.

13 Key concepts

The terms below are used throughout Unit 5. Capture them in your own words as you work through the lesson.

Device estate

The full population of devices through which the enterprise is accessed or in which it has an interest — corporate and personal mobile devices, laptops, IoT devices, and operational technology.

Application sandbox

The isolation mechanism of a mobile platform — restricting each application to its own filesystem area, process space, and system resource access.

Code signing (mobile)

The requirement that mobile applications be signed by a recognised developer identity, with the signature verified before execution.

Secure boot

A boot process in which each stage cryptographically verifies the next, from hardware root of trust through to the operating system — ensuring that only authorised code executes.

Hardware root of trust

An immutable cryptographic anchor in hardware, used to verify the boot chain and to protect device identity keys from extraction.

Jailbreaking / rooting

Removing mobile platform restrictions to permit unsigned code — disabling the sandbox, the code-signing requirement, and the secure boot chain. A jailbroken or rooted device should be treated as untrusted.

Sideloading

Installing applications from sources other than the official platform store — bypassing store review and, on some platforms, weakening platform protections.

MDM (Mobile Device Management)

Management of mobile devices at the device level — enrolment, configuration profiles, compliance policy, and remote lock and wipe.

MAM (Mobile Application Management)

Management of corporate applications independently of device enrolment — application configuration, per-application encryption, data-sharing restrictions, and selective wipe.

UEM (Unified Endpoint Management)

A consolidated management platform spanning mobile, desktop, and increasingly IoT devices — providing consistent policy across device classes.

BYOD

Bring Your Own Device — employee-owned devices used for corporate work, typically managed at the application level rather than the device level.

COPE

Corporate-Owned, Personally Enabled — enterprise-owned devices that employees may also use personally, fully managed by the enterprise.

Selective wipe

Removal of corporate applications and data from a device without removing personal data — the essential control that makes BYOD acceptable.

Conditional access

Granting access to enterprise services only when the requesting device and user meet defined policy requirements — the integration point between mobility management and Zero Trust.

Mobile threat defence (MTD)

On-device detection of mobile threats — malicious applications, network attacks, and phishing — complementing platform protections and EMM policy.

Device attestation

Cryptographic evidence that a device is genuine and its platform integrity is intact — Apple's DeviceCheck and App Attest, Android's Play Integrity API.

Internet of Things (IoT)

The broad category of connected devices that sense, actuate, or communicate — spanning consumer, enterprise, and industrial deployments.

Operational technology (OT)

Industrial control systems, SCADA, and safety systems — distinguished from IoT by safety consequence, determinism requirements, and very long lifecycles. Examined in Lesson 5.8.

IoT gateway

A device that aggregates IoT device traffic, translates protocols, and provides a boundary between device networks and enterprise or cloud networks.

Firmware

The software embedded in an IoT device — frequently the entire operating environment, and frequently not updatable in deployed devices.

Firmware signing

Cryptographic signatures on firmware images, verified by the device before installation — preventing installation of unauthorised or modified firmware.

Secure update (OTA)

An over-the-air firmware update mechanism that is authenticated, encrypted in transit, signature-verified on the device, and resistant to rollback to vulnerable versions.

Device identity (IoT)

A unique cryptographic identity per device — typically an X.509 certificate — enabling authentication, authorization, and revocation of individual devices.

MQTT / CoAP

Lightweight messaging protocols widely used in IoT — MQTT over TLS and CoAP over DTLS provide transport security; without these, device traffic is unprotected.

Shadow IoT

IoT devices connected to enterprise networks or cloud services without the security team's knowledge — typically purchased and deployed by business units outside any security process.

Network access control (NAC)

The control that authenticates and profiles devices onto the network, placing them into appropriate segments and quarantining unknown devices.

Micro-segmentation

Fine-grained network segmentation restricting which devices can reach which services — limiting lateral movement within a device network.

ETSI EN 303 645

European baseline security requirements for consumer IoT devices — including prohibition of universal default passwords and requirements for vulnerability disclosure and software updates.

IEC 62443

International standard for industrial automation and control systems security — widely applied to industrial IoT and OT environments.

OWASP IoT Top 10

Community guidance on the most significant IoT security risks — weak passwords, insecure network services, insecure ecosystem interfaces, lack of secure update, and others.

14 Activities

The activities below help you test your understanding and prepare for the unit discussion and Assignment 2. They are not graded, but completing them will substantially improve your preparation.

15 Self-check

Answer the questions below before moving to Lesson 5.8. If you cannot answer a question confidently, revisit the corresponding section.

16 Summary

This lesson has examined mobile and IoT security — the device estate through which the enterprise is accessed and the connected devices that increasingly generate and act on enterprise data. The essential points are:

• The perimeter has moved to the device. The network no longer bounds the enterprise — device identity and device posture determine access, and the device estate is now the largest and least controlled part of the enterprise attack surface.
• The device estate is heterogeneous. Corporate-owned mobile, BYOD, laptops, enterprise IoT, consumer IoT, and operational technology each have different ownership, lifecycles, capabilities, and security implications — and require different control models.
• Mobile platforms provide strong architecture. Sandboxing, code signing, permission models, secure boot, hardware-backed keys, and device attestation — but platform security protects the device, not the enterprise's data and access.
• The mobile threat landscape targets the user and the data. Malicious applications, sideloading, jailbreaking and rooting, network attacks, social engineering, MFA fatigue, and data leakage through legitimate channels — with credential compromise through social engineering as the most consequential.
• Enterprise mobility management protects the data. MDM, MAM, UEM, selective wipe, conditional access, and mobile threat defence — with the control model matched to the ownership model, and with application containment preferred over full device management for personal devices.
• IoT architecture spans five layers. Device, gateway and edge, connectivity, cloud and platform, and application — with the weakest layer determining the security of the deployment.
• IoT constraints drive the security problem. Limited compute, no user interface, long lifecycles, physical accessibility, cost pressure, deployment at scale, and no management plane — producing an estate that cannot be secured device by device.
• IoT controls split into device and environment. Device identity, secure boot, firmware signing, secure update, and credential management on the device; segmentation, egress control, network access control, gateway mediation, and network monitoring in the environment.
• Governance makes the technical controls effective. Inventory, policy, ownership, procurement requirements, device identity, network architecture, and lifecycle management — with the absence of a defined IoT owner as the most consequential gap.
• Device monitoring and response rely on the environment. Network telemetry, EMM and identity signals, and IoT platform logs — with containment at the network, investigation from environment telemetry, and remediation by replacement.
• Common pitfalls recur. Treating mobile as small laptops; BYOD without governance; relying on MDM alone; ignoring unmanaged and shadow devices; IoT purchased outside security; default credentials; no firmware update path; IoT on the corporate network; procurement without security requirements; device security treated separately from the enterprise programme.

These ideas prepare for Lesson 5.8, which examines critical infrastructure security — extending the discussion to operational technology, where safety consequence, deterministic operation, and very long lifecycles impose constraints that go beyond those of the general IoT estate.