CIS Controls IoT Companion Guide explained

What the CIS Controls IoT Companion Guide asks of an enterprise with IoT devices

The CIS IoT Companion Guide for CIS Controls v8 is a free CIS guide that explains how the Controls apply to enterprise IoT devices, such as smart speakers, security cameras, door locks, window sensors, thermostats, headsets and watches. It does not transfer ownership of your controls or evidence: your organization still decides what runs on its network, configures it, and proves it. When a customer, contract or internal audit asks how IoT fits the CIS Controls, the first task is to work out which device classes you actually operate and which Safeguards the guide treats as hard to apply to them. The guide evaluates each Control and Safeguard for IoT applicability, names the implementation challenges, and notes that some devices lack the functions that advanced measures require. Your result will differ from another organization's because the device mix, the vendors, and the functions each device can support all vary.

Two Safeguards set the baseline for every device class. Safeguard 1.1 asks for an accurate, current inventory of every enterprise asset that stores or processes data, including IoT devices, whether on premises, virtual, remote or in the cloud, and including assets that regularly connect but are not enterprise controlled. Safeguard 4.1 asks for a written process for configuring enterprise assets securely, covering IoT devices as well as servers, operating systems and applications, reviewed once a year or after significant enterprise changes. For each device class, confirm three things: whether you can see the device in your inventory at all, whether its default credentials and services can be changed, and whether the vendor provides firmware updates you can verify. If a class fails any of these, record it as a documented exception with a compensating measure, such as network segmentation, rather than leaving it unexamined. The assessor will look for that record.

Independent assessors test whether these Safeguards operate, and they issue any report or attestation. DeployOpen prepares systems, inventories, configuration baselines and evidence for that assessment, but it does not issue audit reports or certificates. In practice, the assessor will ask for the inventory export, the secure configuration process, and proof that the process was reviewed on schedule. Ask any implementation partner to state in writing which device classes are in scope, which Safeguards you have judged not applicable and why, and what evidence each in-scope device class will produce. Confirm the IoT Companion Guide version you are working from directly with CIS at CIS Controls v8.1, because the guide's wording and mappings may differ from the core Safeguard text.

Which IoT devices the companion guide treats as in scope

The IoT Companion Guide for CIS Controls v8 is built around the connected devices enterprises already run, not around a formal definition of IoT. CIS names the device groups below and describes what they share, so the cards help you decide which of your own asset classes fall under the guide's focus.

Smart speakers and voice assistants

CIS names smart speakers as a commonly found enterprise IoT device. They usually perform one core function, such as playing audio or answering voice commands, and they connect to cloud services and other devices to do it. Check whether speakers in meeting rooms or open offices can join your network, whether they hold account credentials or calendar access, and who owns the vendor account that manages them. These details decide which Safeguards 1.1 and 4.1 need to cover them.

Security cameras

Security cameras are on CIS's list of enterprise IoT devices and carry sensitive data in the form of video. They often ship with default credentials, run firmware that the owner updates rarely, and send streams to vendor-hosted services. Confirm that each camera appears in your asset inventory with its firmware version, that it sits on a segment separate from user workstations, and that the vendor's management portal is controlled by named administrators.

Door locks and access controllers

Networked door locks are IoT devices with a single physical function that matters for safety and access control. They may connect through a gateway, a hub or a cloud service, which adds dependencies you must inventory. Ask who can grant or revoke credentials, how the lock behaves when the network drops, and whether the device can be reconfigured without a vendor technician. Each answer shapes how you document its secure configuration under Safeguard 4.1.

Window sensors and environmental sensors

Window sensors and similar environmental sensors are simple devices with limited processing, which CIS treats as the defining trait of IoT. They often report to a hub over a low-power radio protocol rather than standard IP networking, so they can be missed by network scans. Check whether your discovery process reaches these hubs and whether sensor data feeds any decision that affects building operations or safety.

Thermostats and building controls

Thermostats are connected devices that communicate with other systems and act on inputs such as occupancy or temperature readings. They frequently run vendor firmware that cannot host a security agent, so you cannot rely on endpoint tooling to see them. Identify which thermostats are managed by facilities staff, which by IT, and whether any are reachable from the internet, since ownership gaps are where unmanaged devices tend to persist.

Headsets and wearables

Headsets and smart watches are personal devices that often pair with corporate laptops or phones and can store call recordings, messages or health data. They usually lack a full desktop or mobile operating system, so the controls available on them differ from those on managed endpoints. Establish whether company-issued or personal devices are in use, which devices pair with corporate assets, and whether pairing is permitted under your data handling rules.

Why IoT devices are harder to secure than laptops and servers

IoT devices are harder to secure than laptops and servers because CIS names three challenges that compound each other: ubiquity, uniqueness and ecosystem complexity. Ubiquity means a single enterprise may run hundreds of cameras, door locks, thermostats, sensors and headsets spread across offices, warehouses and remote sites, so each device adds to the inventory and patching burden. Uniqueness means those devices come from many manufacturers and run many firmware versions, so a configuration step that works on one model may not exist on the next. Ecosystem complexity means a single device can depend on several vendors for hardware, firmware, companion apps and cloud services, and the enterprise often controls only part of that chain.

The practical result is that many IoT devices cannot run the endpoint agents, host firewalls or local logging that the Controls assume on general-purpose systems. CIS notes that these devices usually have a core function with limited extras and enough processing to act on inputs, but not enough to run a full desktop or mobile operating system. Several advanced measures therefore do not apply directly, and the Companion Guide evaluates each Safeguard for how applicable it is to IoT and what extra guidance is needed. Before you accept any exception, confirm which Safeguards your device types can meet natively and which need a compensating control, such as network segmentation or a managed gateway, that you can evidence.

Before you buy or approve a device class, ask each vendor four specific questions: how firmware updates are delivered and signed, how long the vendor commits to issue security fixes, whether default administrator accounts can be removed or changed, and which security settings (such as encryption, logging, remote access and certificate handling) are supported in the configuration. Record the answers in the asset inventory and the secure configuration process. Where a vendor cannot answer in writing, treat that gap as a documented risk with an owner and a review date rather than assuming the device is covered.

How the companion guide rates whether each Safeguard applies to IoT

Some Safeguards carry over to IoT with their standard wording because an IoT device can meet the requirement in the same way any enterprise asset can. The guide's reading for these Safeguards is that the requirement holds and the usual approach works, with little added guidance. The work lies in showing that the device class is covered and that the record stays current.

Ownership and location: each device needs an owner, a location and a stated purpose in the asset inventory, which any networked device can provide.
Configuration process: a written secure configuration process still applies, even where the vendor fixes most settings.
Vendor-controlled settings: record which settings you can change, which are locked and which the vendor manages through firmware.
Dated evidence: keep inventory exports and configuration baselines with dates, reviewed on the cycle your own policy sets.

Check the exact rating and wording for each Safeguard in the guide itself, then write down why each device class falls in this group and keep that rationale with your inventory.

Which inventory and configuration Safeguards still apply to IoT devices

Safeguard 1.1 and Safeguard 4.1 apply to IoT devices in full, even where a device cannot run the advanced measures in the rest of the Controls. Safeguard 1.1 asks for an accurate, current inventory of every enterprise asset able to store or process data, and the IoT Companion Guide's point is that smart speakers, cameras, door locks, thermostats and sensors all fall inside that wording. The inventory must cover assets on premises, virtual, remote or in the cloud, and must include devices that regularly connect to the network without being enterprise controlled, such as a visitor's device or a contractor's sensor. The Safeguard is reviewed at least twice a year. Because many IoT devices cannot host an endpoint agent, the inventory usually has to be built from network discovery, DHCP and switch or wireless controller records, and from procurement and facilities data, then reconciled by hand.

An assessor testing Safeguard 1.1 will ask for an inventory export and check that each record carries, at minimum, an owner, a physical or logical location and a status such as active, retired or unauthorized. For IoT, add fields for the device type, the firmware version and whether the device is able to receive updates. Expect the assessor to pick a sample of devices from the network, such as a camera on a segment, and trace it back to the inventory. Confirm with your security team which of these fields your inventory tooling can hold before you commit to a design, because some discovery products report only addresses and vendor names. Keep dated versions of the export so the review cadence is provable.

Safeguard 4.1 asks for a written, documented process for configuring enterprise assets securely, and it names IoT devices alongside end-user devices, servers, operating systems and applications. The process must be reviewed once a year or after significant changes to the enterprise. For IoT, the document should set out device-specific steps: changing default credentials, disabling unused radios and services, placing devices on a dedicated segment, setting update routes and recording who approves a new device type. Where a device offers no configuration options at all, the process should say so and record the compensating control, such as network isolation, so the gap is visible to the assessor rather than hidden. Confirm the review date and the approver with your change board, since an undated or unsigned process is a common finding.

Options when an IoT device cannot meet a Safeguard as written

This table compares the four routes an organization can take when a device lacks the function a Safeguard assumes, such as native logging, patching or unique credentials. Each row shows when the option fits, what evidence it produces and what an assessor will ask, so you can judge the trade-offs before choosing. The organization makes the final decision and should walk through its reasoning with the independent assessor before the assessment begins.

Option	When it fits	Evidence it produces	What the assessor will ask
Replace the device	The vendor offers a model that supports the Safeguard's function and the replacement cost is justified by the risk	Updated asset inventory entries, procurement records, configuration baselines for the new model	Why the original device was selected, when the replacement was completed, and whether old devices were removed or decommissioned
Add compensating controls at the network or segment level	The device must stay in service and the gap can be covered by monitoring, filtering or access restrictions outside the device	Firewall or access control rules, network flow logs, alert rules and review records showing the controls operate	How the compensating control addresses the specific risk of the unmet Safeguard, and proof it is tested and reviewed
Isolate on a dedicated segment with documented restrictions	The device cannot be patched, authenticated or hardened, but it can be separated from business-critical systems and internet access	Segment diagrams, allowlists for permitted traffic, restriction standards, and logs of blocked connections	Whether the device is inventoried under Safeguard 1.1, how segment boundaries are enforced, and who can change the rules
Record a risk decision signed by an accountable owner	No technical option is practical or proportionate, and the organization accepts the residual risk with defined review conditions	Signed risk acceptance, the rationale, the residual risk rating, review dates and any agreed exit plan	Who has authority to accept the risk, whether the owner understood the exposure, and when the decision will be revisited
Confirm the vendor's support position	Before choosing any option, to establish whether a firmware or configuration change is possible at all	Vendor support statements, end-of-life notices and firmware release records	Whether the vendor documentation was checked, and whether the conclusion that a Safeguard cannot be met is supported by evidence
Discuss the reasoning with the independent assessor early	Any time an option other than full conformance is proposed for a device	Written summary of the proposed option, the Safeguard affected and the evidence planned	Whether the assessor agrees the approach is acceptable for the assessment scope, before work is relied upon

Who does what for IoT controls: your team, the implementation partner and the assessor

Your organization owns the controls. That means deciding which IoT device types are in scope, accepting the residual risk of devices that cannot meet a Safeguard, and making sure the people who own each device (facilities, clinical engineering, operations, business units) keep the inventory accurate. No outside party can accept risk on your behalf or decide that a device is out of scope for the business.

Scope and risk decisions: Set the IoT boundary, choose which Safeguards apply to which device classes, and record exceptions with a named owner and review date.
Device ownership: Assign an accountable owner to every IoT device, including cameras, door locks, thermostats and sensors that business units may buy without involving IT.
Inventory upkeep: Keep the asset inventory current under Safeguard 1.1 and review it at least twice a year, since devices change faster than office hardware.
Configuration approval: Own the written secure configuration process under Safeguard 4.1 and approve changes after significant enterprise changes.
Evidence custody: Retain records, change tickets and review minutes so an assessor can sample them later.

Before engaging anyone, confirm that each of these items has a named internal owner and that your team can explain them without a consultant in the room.

What usually delays IoT work under the CIS Controls and how to avoid it

Most IoT delays under the CIS Controls start with the inventory, because every later Safeguard depends on knowing which devices exist, who owns them and how they are configured. The cards below cover the problems that tend to stall projects and one check for each that shows whether the gap is closed.

Inventory from one discovery method

A single scan, usually an active network sweep, misses devices on guest Wi-Fi, building management segments and devices that only connect intermittently. Safeguard 1.1 asks for an accurate, current inventory that includes assets that regularly connect but are not enterprise controlled, and it must be reviewed at least twice a year. Check the inventory against a second source such as DHCP logs, switch MAC tables or the cloud and wireless controller records. Evidence: a reconciliation report showing which devices each method found and the dated sign-off of the review.

IoT excluded without a rationale

Teams often declare cameras, sensors and thermostats out of scope because they cannot run an agent or be patched in the usual way. CIS does not offer that exemption on its own: the IoT Companion Guide evaluates each Safeguard for applicability and notes where IoT devices lack functions that advanced measures need. Record for each device class which Safeguards apply, which do not, and why, then compensate with segmentation or monitoring where a Safeguard cannot be met directly. Evidence: a signed applicability decision per Safeguard, with the compensating control named and assigned an owner.

Device owners unknown

An inventory entry with no accountable owner cannot be reviewed, patched or retired. IoT devices often arrive through facilities, building contractors or individual departments, so the purchasing team may never record who answers for them. Sample ten devices from the inventory and ask the named owner to confirm the purpose, location and the person who approves changes. Devices without an owner should be quarantined or assigned before the next review cycle. Evidence: an inventory with an owner field populated for every entry and a log of reassignments.

Default credentials never changed

Many IoT devices ship with vendor default usernames and passwords that are rarely changed and seldom written down. Attackers test these first, so an unchanged default is one of the most common routes into a device. Check each device class for a default login by consulting the vendor documentation, then confirm that the credential was replaced and stored in the approved password manager. Evidence: a configuration record for each device showing the credential was changed, the storage location of the new credential and the date of the change.

Configuration process written for laptops

Safeguard 4.1 asks for a written process that covers IoT devices and servers as well as end-user devices, operating systems and applications. Many organizations write a hardening standard for Windows and Linux hosts and assume it applies to cameras and door locks, which often expose different settings and offer no local shell. Add a section for each IoT device class that lists its configurable settings, the approved values and the method for applying them. Review the process once a year or after significant changes. Evidence: the approved configuration process with an IoT section, its review record and the configuration baseline for each device class.

Evidence gathered once

Teams often complete the inventory and configuration work for an assessment, then let the records age. Safeguard 1.1 requires review at least twice a year, and Safeguard 4.1 requires an annual review of the configuration process or a review after significant enterprise changes. Set calendar reminders tied to these cycles and keep dated versions of each record. A quick test is to ask for the most recent review date of each artifact and confirm it falls within the required window. Evidence: dated review records and version history for the inventory and configuration process, with the reviewer named on each.

Questions buyers ask about the IoT Companion Guide

Is the CIS IoT Companion Guide free, and where do I get it?

Yes. CIS offers its IoT and Mobile Companion Guides as free downloads, and they were developed by the CIS IoT Community with volunteer subject matter experts. The guide is written for the CIS Controls v8 family, so read it alongside the current CIS Controls v8.1 text on the CIS website. The starting point is the CIS blog post that introduces the companion guides, which links to the download. Note that CIS Controls content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, so using it commercially, for example in client deliverables, requires CIS's prior approval. Confirm the licensing terms with CIS before reproducing any of the text in a client document.

Do IoT devices have to be in scope for a CIS Controls assessment?

Whether IoT devices are in scope depends on what your organization has defined as its enterprise, but the Controls do not exempt them. Safeguard 1.1 asks for an inventory of every enterprise asset that can store or process data, and it names IoT devices explicitly, along with end-user, network and server devices. It also covers assets that regularly connect to the network but are not enterprise controlled. In practice, a smart camera, door lock or thermostat on your network is an asset the inventory must account for. Ask your assessor to confirm how they will treat devices your organization does not manage, and document that decision in your scope statement.

How do we decide which Safeguards apply to a device class?

Start with the device class, then check each Safeguard against what that class can actually do. The companion guide evaluates every Control and Safeguard for how applicable it is to IoT, the challenges of implementing it and any extra guidance needed. It also notes that some IoT devices lack the functions advanced measures require, such as local logging, agent installation or granular account management. For each class, such as cameras or badge readers, record which Safeguards apply directly, which apply through a compensating control on the network, and which cannot be met on the device and need a documented exception. Your assessor will expect that reasoning to be written down, not assumed.

What drives the effort of an IoT inventory and configuration review?

Four factors drive most of the effort: device count, vendor count, legacy devices and locations. CIS names ubiquity, uniqueness and ecosystem complexity as the core IoT challenges, so more device models and more manufacturers mean more firmware versions, more configuration interfaces and more vendor documents to review. Legacy devices that cannot be patched or reconfigured add compensating-control work at the network layer. Multiple sites, remote offices and cloud-managed devices each require their own discovery method and access path. Ask any partner to base the quote on a device list broken down by class, vendor, firmware status, location and management method, because those fields determine the work.

Can our internal team build the IoT inventory alone?

Often yes, if the team has network visibility and time to reconcile the data. Safeguard 1.1 expects an accurate, current inventory reviewed at least twice a year, so the work is partly a one-time build and partly a recurring process. The one-time effort is discovery across the network, including passive and DHCP-based methods, plus manual research for devices that do not appear in any tool. The recurring effort is review and change control. Teams without OT or building-systems experience often struggle with devices that do not respond to standard scans, so they may need outside help for those segments. Decide which parts you will own, such as the owner register and review cadence, and which parts you may hand to a partner.

What must our organization provide to an implementation partner?

The partner needs access to information only your organization holds. Provide a current device list or network access for discovery, network diagrams showing the segments where IoT devices sit, vendor and firmware records, and the owner of each device class. Also provide the existing configuration baseline, any written secure configuration process under Safeguard 4.1, and the systems that manage IoT devices, such as cloud consoles or building management platforms. Ownership stays with your organization: the partner prepares systems and evidence, but your team approves risk decisions and exceptions. Agree on these inputs in the written scope before work starts, since most engagements are fixed-scope.

Does the IoT Companion Guide replace a compliance framework?

No. CIS states that the CIS Controls do not replace any regulatory, compliance or authorization scheme, and the companion guide is an application of the Controls, not a standalone compliance program. If a regulator, customer contract or certification body requires a specific framework, the companion guide helps you apply the relevant Controls to IoT, but it does not establish compliance on its own. CIS maintains mappings to frameworks such as NIST CSF 2.0, ISO/IEC 27001:2022 and NIS2 through its Navigator, which can help you show how the Controls relate to a requirement. Confirm with your auditor which framework and version they will assess against, and whether they accept the Navigator mappings as supporting evidence.

What will an assessor check first for IoT devices?

Expect the assessor to start with the inventory, because every other Safeguard depends on knowing what devices exist. They will likely compare your IoT asset list against network discovery results to look for gaps, then check whether each device has an owner, a class, a location and a documented configuration. Next they typically review the written secure configuration process under Safeguard 4.1, which must cover IoT devices, and sample a few device classes to see whether the stated configuration matches what is installed. They will also check whether exceptions for devices that cannot meet a Safeguard are documented and approved. Prepare by running a reconciliation report before the assessment and recording the reasoning behind each exception.

How DeployOpen scopes IoT systems and prepares evidence for the CIS Controls

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and prepares systems and evidence for CIS Controls assessments. The organization owns its controls, and an independent assessor issues any report, so DeployOpen's role is to make the IoT inventory, configuration and evidence ready for review.

How we scope

Agree a written, fixed scope listing the IoT device types, locations and networks in the engagement.
Map each Safeguard to in-scope IoT assets and record which applicability ratings the client accepts.
Confirm which Safeguards depend on device capabilities, such as agents or logging, that some IoT devices lack.

How we build

Deploy self-hosted discovery and inventory tooling within the client's network, cloud accounts or air-gapped environment.
Document secure configuration baselines for IoT device classes, including compensating controls where hardening is limited.
Test the inventory and configuration controls against the assessment specification measures before handover.

How we hand over

Deliver the written inventory and configuration process, with owners, review dates and change records.
Provide evidence packages showing how each in-scope Safeguard is implemented, mapped to the client's assessor's requests.
Document open items and residual risks for the client to accept, remediate or take to its independent assessor.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work ends.
Review the inventory at the twice-yearly cadence and configuration process after significant enterprise changes.
Confirm with the client which support responsibilities sit with its own staff and which sit with DeployOpen.

CIS Controls IoT Companion Guide