Study guide
14.4 Secure and Monitor Internet of Things
ISC2 Systems Security Certified Practitioner SSCP
Track your progress as you read
Finished sections get a check mark.
1 Introduction and Exam Overview
1.1 Current Exam Facts 1.2 Computerized Adaptive Testing, Scoring, and Retakes 1.3 Eligibility, Associate Pathway, Endorsement, and Maintenance
2 Ethics and Security Concepts
2.1 Comply with Codes of Ethics 2.2 Understand Security Concepts 2.3 Identify and Implement Security Controls
3 Functional Controls, Assets, and Change Management
3.1 Document and Maintain Functional Security Controls 3.2 Support and Implement the Asset Management Lifecycle 3.3 Support and Implement the Change Management Lifecycle
4 Security Awareness and Physical Security Operations
4.1 Support and Implement Security Awareness and Training 4.2 Collaborate with Physical Security Operations
5 Authentication Methods and Trust Architectures
5.1 Implement and Maintain Authentication Methods 5.2 Federated Access with OAuth2, SAML, and OpenID Connect 5.3 Understand and Support Internetwork Trust Architectures
6 Identity Lifecycle and Access Control Models
6.1 Support and Implement the Identity Management Lifecycle 6.2 Mandatory, Discretionary, and Role-Based Access Control 6.3 Rule-Based, Attribute-Based, and Privileged Access Management
7 Risk Management, Visibility, and Legal Concerns
7.1 Risk Management Concepts and Treatment 7.2 Risk Visibility, Reporting, and Threat Intelligence 7.3 Legal and Regulatory Concerns
8 Assessments, Monitoring, and Analysis
8.1 Security Assessments and Vulnerability Management 8.2 Operate and Monitor Security Platforms 8.3 Analyze Monitoring Results
9 Incident Response and Forensic Investigations
9.1 Incident Response: Preparation, Detection, Analysis, and Escalation 9.2 Containment, Eradication, Recovery, and Lessons Learned 9.3 Understand and Support Forensic Investigations
10 Business Continuity and Disaster Recovery
10.1 Business Continuity and Emergency Response 10.2 Disaster Recovery and Restoration Metrics 10.3 Backup, Redundancy, Testing, and Drills
11 Cryptography Foundations
11.1 Reasons and Requirements for Cryptography 11.2 Hashing, Salting, Symmetric, Asymmetric, and ECC 11.3 Digital Signatures, HMAC, Algorithm Strength, and Cryptanalysis
12 Secure Protocols and Public Key Infrastructure
12.1 Understand and Implement Secure Protocols 12.2 Understand Public Key Infrastructure
13 Networking Fundamentals, Attacks, and Access Controls
13.1 Understand and Apply Fundamental Concepts of Networking 13.2 Understand Network Attacks and Countermeasures 13.3 Manage Network Access Controls
14 Network Security Operations, Wireless, and IoT
14.1 Manage Network Security 14.2 Operate and Configure Network-Based Security Appliances and Services 14.3 Secure Wireless Communications 14.4 Secure and Monitor Internet of Things
15 Malware, Malicious Activity, and Endpoint Security
15.1 Identify and Analyze Malicious Code 15.2 Malicious Activity, Social Engineering, and Behavior Analytics 15.3 Implement and Operate Endpoint Device Security
16 Mobile, Cloud, and Virtual Environments
16.1 Administer and Manage Mobile Devices 16.2 Cloud Security: Deployment, Service Models, and Shared Responsibility 16.3 Cloud Legal, Regulatory, and Third-Party Requirements 16.4 Operate and Maintain Secure Virtual Environments
14.4 Secure and Monitor Internet of Things
Key Takeaways Explain This Topic AI
SSCP Knowledge Area 6.7 is secure and monitor Internet of Things (IoT): configuration, network isolation, firmware updates, and End of Life (EOL) management.
Default passwords on cameras, badges, HVAC, and pumps are live credentials. Inventory and unique secrets are day-zero work, not a later hardening project.
Isolation is the control that saves the EHR: IoT/OT VLANs and firewall zones must not initiate sessions to clinical databases. Cameras talk to the video management system, not to the chart.
Firmware updates need a signed source, a change window, and a path that does not require exposing the device to the whole Internet via Universal Plug and Play.
Vendor cloud connectivity and EOL are risk decisions: know what leaves the building, and replace or isolate devices the vendor will no longer patch.
Last updated: August 2026
Secure and monitor Internet of Things
Knowledge Area 6.7 is a single outline sentence with a dense example list: Secure and monitor Internet of Things (IoT) — configuration , network isolation , firmware updates , End of Life (EOL) management . Domain 6 remains 16% of the SSCP. IoT is how a $40 camera becomes a foothold on a network that also runs the electronic health record (EHR) .
IoT here is any networked device that is not a general-purpose, actively managed workstation: cameras, badge readers, HVAC controllers, smart TVs in waiting rooms, printers, time clocks, consumer "smart" plugs a well-meaning staff member bought, and many operational technology (OT) boxes (building management, lab instruments) that share the same failure modes. Medical devices add vendor-change-control and safety constraints; they do not get a pass on default passwords. You are not being asked to design a full Purdue industrial model. You are being asked to keep a camera from talking to an EHR database.
Configuration: defaults, inventory, and the vendor cloud
Unconfigured IoT is an account you published.
Configuration item What to do What goes wrong if you skip it
Inventory Asset tag, owner, VLAN, IP, firmware, data classification, vendor You cannot isolate or patch a device you do not know is on the switch
Default credentials Unique passwords or certificates; vault them; disable anonymous admin/admin , root/pass , printed default on a sticker — internet-wide scanners know these
Unused services Disable Telnet , Universal Plug and Play (UPnP) , unused HTTP, Server Message Block (SMB) file shares, guest Wi-Fi on the camera UPnP punches holes in consumer-grade NAT; SMB on a printer is ransomware adjacency
Management path HTTPS/SSH from a jump host on the IoT management VLAN; no WAN management In-band admin on the clinical VLAN is 6.4's mistake applied to cameras
Time and logs NTP; syslog to a collector the camera cannot wipe After an incident you will not have a timeline
Vendor cloud Know whether the device phones home, what it sends, where the tenant lives, and who has the cloud admin password A camera "in the hallway" is also a stream in a vendor Software as a Service (SaaS) region you never reviewed
Default passwords are the 6.7 item that shows up as a scenario, not a definition. New cameras, a cheap NVR, a networked badge panel — they ship with a published default. Changing it is configuration, not "advanced hardening." So is turning off the feature that lets the device register itself to a consumer cloud with the installer's personal email.
Vendor cloud is a third-party connection (Domain 2 trust architectures) that 6.7 forces you to notice. Many cameras will not record without a vendor account. That account is an identity with a password reset path, often multi-factor authentication (MFA) -optional, that can pan-tilt-zoom a clinic. Data residency, Business Associate Agreement (BAA) for anything that might capture patients, and whether the device still works if you firewall the cloud (it often does not) belong in procurement, not in a panicked ACL after the first breach article. If the vendor requires cloud, isolate so the camera can reach only that vendor and the video management system (VMS) , not the EHR, and put the vendor destination in the firewall log.
Scenario — default admin and a helpful cloud. Facilities hangs eight cameras on the nearest switch "so security can see the loading dock." They leave admin/12345 , enable UPnP, and scan a QR code that attaches the cameras to a consumer vendor cloud. The cameras get DHCP on the same VLAN as EHR workstations. That is a 6.7 configuration failure and a 6.4/6.7 isolation failure. Before anyone talks about AI analytics on the video, change the secrets, inventory the MAC addresses, disable UPnP, and move the ports.
Network isolation: IoT/OT VLANs are not a clinical integration
Network isolation is the control that makes a compromised camera boring. It is 6.4 segmentation applied to a class of devices that cannot run your endpoint detection and response (EDR) agent.
Isolation pattern Allowed flows Explicitly denied
IoT VLAN + firewall zone Camera → VMS (for example RTSP/TCP 554 or the vendor's ports); jump host → camera HTTPS Camera → EHR, camera → domain controller, camera → Internet except the vendor update/cloud destinations you named
OT VLAN Building system → its server; historian as designed OT → EHR, OT → guest Wi-Fi, unrestricted OT → Internet
Printer VLAN Workstations → print; print → syslog Printer → file servers with SMB write, printer → Internet firmware "phone home" unless you allow a proxy
Medical device VLAN Device → its approved clinical server Device → general workstation VLAN, device → email
Air-gap / physically separate switch Only when the risk and the workflow truly require it Fake air-gap: two VLANs on one core with permit ip any any
Micro-segmentation still helps: two cameras should not Secure Shell (SSH) to each other. Network Access Control (NAC) (6.5) can fingerprint a camera and dump it into the IoT VLAN automatically — if you built that policy. If NAC is "allow if it has an agent," the camera has no agent and lands on guest or, worse, on voice.
Scenario — camera VLAN talking to the EHR. A week after install, firewall logs show 10.70.12.0/24 (cameras) SYN -scanning 10.30.8.40:1433 (EHR database). That is not HL7. That is not "the VMS needs SQL." That is a segmentation failure: the IoT zone has a route and a permit to a PHI database. Containment is an ACL/zone change today : cameras may speak only to the VMS and, if required, a patch proxy. Investigation is 6.7 plus Domain 4: was a camera already owned (default password, old firmware), and what else did it scan? Do not open 1433 "to complete the clinical workflow." Do not assume the vendor cloud NAT will drop scans that never left the hospital.
Isolation is also how you monitor. A zone that should be quiet (cameras to one VMS subnet) makes security information and event management (SIEM) detections cheap: any camera-to-EHR, camera-to-DNS-Internet, or camera-to-SMB is an event of interest (Domain 3). A flat network makes those events indistinguishable from "Tuesday."
Firmware updates and End of Life management
IoT fails on a different patch clock than Windows.
Firmware updates are how you close the CVE that default-password scanners did not already use. The operations bar:
Know the version. Inventory is the prerequisite. "The cameras are fine" is not a version.
Get it from the vendor, signed if they offer signing. Random firmware from a forum is how you brick a fleet or install a backdoor.
Test on one device in a window that does not take down every hallway at once.
Use a controlled path. A jump host or update proxy pulls the file; the camera does not need general Internet. UPnP port-forward "so the vendor can push" is not a patch program.
Change-control medical and safety devices. A pump firmware update is a clinical change, not only an IT change. The SSCP still owns the network isolation while that process runs; you do not skip isolation because the FDA-cleared device is "validated" on an old stack.
If a device cannot be patched (no vendor path, no window, no signing), it is already in the EOL conversation even if marketing still sells it.
End of Life (EOL) management is the last outline example and the one organizations skip because the camera still produces video. EOL means the vendor will not ship security firmware. Every new CVE in that chipset is now yours forever.
EOL decision When it is acceptable When it is not
Replace Default for anything that can reach PHI, payment, or identity, or that is Internet-facing "Next fiscal year" with no isolation in the meantime
Isolate and compensate Temporary: no route off the IoT zone except VMS, extra monitoring, disabled unused services, unique creds, maybe a bump-in-the-wire firewall Leaving the EOL camera on the EHR VLAN because "it still works"
Accept Only with a named risk owner, a date, and a scope that cannot touch PHI Informal acceptance in a facilities Slack channel
Ignore Never The video is up, so security must be up
EOL is the same lifecycle idea as Domain 1 asset management, applied to devices that outlive their vendor. A compensating control is time-boxed. "We will micro-segment later" is not a control.
Scenario — vendor declared EOL. The camera vendor's letter says support and firmware end in ninety days. The loading-dock views still work. Facilities wants to keep them through next winter. The SSCP answer is not "they still work." Treat EOL as replace or isolate : pull them off any path to EHR and identity, monitor the zone, and put replacement on a dated plan. Disabling logs so the unpatched cameras generate fewer tickets is concealment, not risk treatment. Moving them to a public DMZ with default passwords so the vendor cloud can still reach them is the opposite of isolation.
Monitor what you isolated
6.7 says secure and monitor . After isolation, watch:
New MAC addresses on the IoT switch (rogue consumer plugs).
Flows that violate the zone (camera → 1433, camera → 445, camera → unexpected countries).
Vendor-cloud volume spikes (exfiltration disguised as "cloud backup").
Authentication failures on the VMS and on the cameras themselves.
Firmware version drift against the inventory.
NAC, firewall logs, and a lightweight network detector on the IoT SPAN are the 6.5 tools reused here. Do not put a full inline IPS in fail-closed on a safety-critical OT segment without an availability decision — 6.4 placement still applies. Do put something that will tell you when a camera scans the EHR.
Exam traps for 6.7
"Cameras do not store PHI" as a reason to skip isolation (they sit on a path to PHI, and video of patients can be PHI).
UPnP and Internet port-forwards as a firmware strategy.
VLAN ID without an ACL as isolation.
Treating vendor cloud as out of scope because the camera is "on prem."
EOL devices as acceptable because the picture still moves.
When you sit the item, ask: did we change the default, can this thing route to the EHR, how does firmware get here, and who owns the day the vendor quits?