Connected Device Compliance FAQ for IoT and OT

Compliance teams responsible for connected devices tend to arrive at the same set of questions. Most frameworks were written with servers and laptops in mind, and auditors now ask about the cameras, controllers, building systems, and industrial equipment that cannot run agents or produce their own logs. Teams want to know what each framework actually requires for those devices, and what evidence will satisfy an auditor.

The answers below address each of those questions. Every answer is written to stand on its own, so compliance, security, and OT teams can go directly to the question in front of them.

Framework Requirements

How Does NIST CSF 2.0 Apply to Connected Devices?

NIST CSF 2.0 is a globally recognized cybersecurity framework developed in the United States for critical infrastructure sectors and enterprise environments. It covers connected devices through the same outcomes it sets for every asset: know what you have, protect it, detect abnormal activity, and govern the program around it. This and other recent frameworks do not separate Internet of Things (IoT) and operational technology (OT) devices from IT, so cameras, controllers, and building systems fall under the same subcategories as servers and laptops. This alignment is reflected internationally across frameworks like the UK NCSC Cyber Assessment Framework (CAF) and IEC 62443.

Function	Subcategory	Requirement description
Identify	ID.AM-01	Inventories of hardware managed by the organization.
Identify	ID.AM-03	Representations of authorized network communication and data flows.
Identify	ID.RA-01	Identifying, validating, and recording vulnerabilities in assets.
Protect	PR.PS-01	Configuration management practices.
Protect	PR.IR-01	Protecting networks from unauthorized logical access, where segmentation fits.
Detect	DE.CM-01	Monitoring networks for potentially adverse events.

CSF 2.0 also added the Govern function, which asks organizations to set risk strategy, roles, and oversight. For connected devices, that usually starts with deciding who owns the devices that facilities teams, engineering, or vendors installed.

Asimily supports adherence to NIST frameworks across IoT, OT, Internet of Medical Things (IoMT), and IT assets, supplying the inventory, data-flow mapping, vulnerability prioritization, configuration monitoring, and enforced segmentation these subcategories describe.

[Related: NIST CSF 2.0 Compliance]

What Does NIS2 Require for Connected Device Security?

NIS2 is a European Union directive that applies to essential and important entities across key sectors including energy, transport, banking, health, and digital infrastructure. It requires these entities to take appropriate and proportionate technical, operational, and organizational measures to manage risk to their network and information systems. Connected devices are part of those systems, so the Article 21 measures apply to them as they do to any other asset.

Article 21 focuses on cybersecurity, including non-technical components such as training. It sets ten minimum measures that bear directly on connected devices, as detailed below. Each depends on knowing which devices exist, what they connect to, and which vulnerabilities they carry. Complementary guidance from the UK NCSC CAF (Objective B: Protecting Against Cyber Attack) and IEC 62443-3-3 provides additional structured controls for managing these asset inventories and OT device vulnerabilities.

NIS2 Measure	Description
Policies & Risk Analysis	Policies on risk analysis and information system security.
Incident Handling	Processes for detecting, handling, and responding to incidents.
Business Continuity	Business continuity management, backups, and disaster recovery.
Supply Chain Security	Security across the supply chain and relationships with suppliers/vendors.
System & Vulnerability Management	Security in acquisition, development, maintenance, and vulnerability handling.
Effectiveness Assessment	Policies and procedures to assess the effectiveness of risk management measures.
Cyber Hygiene & Training	Basic cyber hygiene practices and cybersecurity training.
Cryptography & Encryption	Policies and procedures regarding the use of cryptography and encryption.
Human Resources & Access Control	Human resources security, access control policies, and asset management.
Authentication & Communication	Multi-factor authentication, secured voice/video, and secured emergency communication.

NIS2 obligations apply through each member state’s national law, so registration, audit cycles, and supervision vary by country. Management bodies must approve and oversee the measures and can be held accountable for failures. Sectors with large OT and IoT footprints, including energy, transport, water, and manufacturing, fall within scope.

Asimily aids NIS2 adherence starting with a full inventory of IoT, OT, IoMT, and IT assets, then adds the exploitability-based vulnerability assessment and prioritization, segmentation, and incident response data the Article 21 measures depend on.

[Related: NIS2 Directive]

How Do CMMC Requirements Apply to IoT and OT Devices?

CMMC (Cybersecurity Maturity Model Certification) is a United States Department of Defense framework designed for contractors and suppliers within the defense industrial base. It treats IoT and OT devices as Specialized Assets when they can process, store, or transmit controlled unclassified information (CUI) but cannot be fully secured. At Level 2, Specialized Assets are part of the assessment scope. They must be documented in the asset inventory and the system security plan (SSP) and shown as managed under the contractor’s risk-based security policies, procedures, and practices, though they are not assessed against the full set of NIST SP 800-171 requirements.

The CMMC rule in 32 CFR Part 170 names five Specialized Asset types: IoT and Industrial IoT devices, OT, government-furnished equipment, restricted information systems, and test equipment. In practice, that covers CNC machines, building management systems, physical access control, HVAC controls, and shop-floor equipment that receives CUI drawings.

Two mistakes come up often. Labeling OT as out of scope instead of as a Specialized Asset leaves the SSP incomplete, and a vague SSP description of how those devices are protected gives the assessor little to review. Level 3 tightens the requirement further, since its selected NIST SP 800-172 requirements expect specialized assets to be included in the scope of security protections. Level 3 scoping is complex and calls for careful review rather than blanket assumptions.

Asimily helps map IoT, OT, IoMT, and IT assets to CMMC requirements, produces the device-level inventory that Specialized Asset documentation depends on, and supplies the segmentation and monitoring evidence that shows how those devices are managed.

[Related: CMMC Compliance]

What Does NERC CIP Require for OT Asset Inventory and Segmentation?

NERC CIP is a set of mandatory cybersecurity standards enforced across the bulk power system in North America. It requires responsible entities to identify and categorize BES Cyber Systems, protect them inside defined electronic security perimeters, control their network ports and services, maintain configuration baselines, and, under the newer CIP-015, monitor network traffic inside those perimeters. Inventory and segmentation run through all of it.

Standard	Focus Area	Requirement Description
CIP-002	Asset Categorization	Identify and categorize BES Cyber Systems by impact rating (High, Medium, Low).
CIP-005	Electronic Security Perimeters	Establish Electronic Security Perimeters (ESP) with monitored access points and permission controls.
CIP-007	System Management	Enable only necessary logical network ports and services; manage patch security and authentication.
CIP-010	Configuration Management	Document baseline configurations, monitor for unauthorized changes, and perform vulnerability assessments.
CIP-015-1	Network Monitoring	Implement internal network security monitoring (INSM) for network traffic inside the ESP.

Asimily supports NERC CIP programs across IoT, OT, IoMT, and IT assets with agentless inventory, communication mapping that documents what crosses the ESP, Configuration Control for baseline drift, and monitoring of internal traffic for anomalous behavior.

[Related: NERC CIP]

How Does PCI DSS Apply to IoT Devices Near the Cardholder Data Environment?

PCI DSS is a global security standard applicable to any organization worldwide that processes, stores, or transmits cardholder data. It treats any IoT device that connects to the cardholder data environment (CDE), or that could affect its security, as in scope unless segmentation isolates it. On a flat network, cameras, badge readers, building controllers, and networked point-of-sale peripherals near the CDE can pull large parts of the environment into scope.

PCI DSS v4.0.1 requires an inventory of in-scope system components (Requirement 12.5.1) and documented confirmation of scope at least once every 12 months and after significant change (Requirement 12.5.2). When segmentation is used to reduce scope, Requirement 11.4.5 requires penetration testing of segmentation controls at least once every 12 months and after any change to those controls, and Requirement 11.4.6 raises that to every six months for service providers.

IoT devices complicate scoping because they are often installed by facilities teams, sit on networks shared with payment systems, and rarely appear in the CMDB. A device nobody has inventoried cannot be shown to be out of scope.

Asimily inventories IoT, OT, IoMT, and IT assets agentlessly, maps which devices communicate with CDE systems, and enforces segmentation policy that keeps out-of-scope devices out, with an auditable record of what is allowed and blocked. This also provides evidence that systems holding payment card data are segregated from the rest of the network, an essential part of PCI DSS.

[Related: PCI-DSS Compliance]

What Does DORA Mean for Connected Devices at Financial Institutions?

DORA (Digital Operational Resilience Act) is a European Union regulation that applies specifically to financial entities, including banks, insurance companies, and investment firms operating in the EU. It requires financial entities in the EU to identify, classify, and document the ICT assets that support their business functions, and the connected devices on their networks are ICT assets. Building systems, physical access controls, cameras, and branch equipment at banks and insurers fall under the same ICT risk management framework as servers and trading systems.

Article 8 sets the inventory requirement. Financial entities must identify all information and ICT assets, including those at remote sites, network resources, and hardware equipment, map their configuration and interdependencies, and keep inventories current. Article 8 also requires a dedicated risk assessment of legacy ICT systems at least yearly, which applies to the end-of-life controllers and appliances common in facilities. DORA’s ICT risk management requirements, detailed further in Commission Delegated Regulation (EU) 2024/1774, also call for network segmentation where appropriate and mechanisms to detect anomalous activity.

DORA has applied since January 17, 2025, and for in-scope financial entities it takes precedence over NIS2 for ICT risk management and incident reporting.

Asimily gives financial institutions an inventory of IoT, OT, IoMT, and IT assets that reaches remote branches, maps device dependencies, prioritizes exploitable vulnerabilities, and enforces segmentation. A global financial institution, for example, used Asimily to bring building management systems and corporate IoT devices under one program.

[Related: DORA Compliance]

How Do ISA/IEC 62443 Zones and Conduits Apply to Segmentation?

ISA/IEC 62443 is an international series of standards for industrial automation and control systems (IACS) and operational technology (OT) environments. It addresses segmentation through zones and conduits. A zone is a group of assets that share security requirements, and a conduit is a defined communication path between zones. Segmentation is how those zones and conduits are enforced on the network, fulfilling key risk management mandates under EU NIS2 Article 21 and the network security principles outlined in the UK NCSC CAF.

IEC 62443-3-2 describes how to partition a system into zones and conduits based on risk and assign each a target security level. IEC 62443-3-3 defines the system security requirements for each level, including the foundational requirement for restricted data flow, which covers network segmentation, zone boundary protection, and limits on communication between zones.

The model works best when it reflects how devices actually communicate. Zones drawn from documentation alone miss the remote access tools, vendor connections, historian links, and IIoT sensors that create unplanned conduits. Mapping observed flows first shows which conduits exist today, which are intended, and which need to be closed.

Asimily assists with mapping communication across IoT, OT, IoMT, and IT assets, helps teams define zones from observed device behavior, and enforces conduit policy through existing NAC and firewall infrastructure. Policy Simulation shows the impact before anything changes, revealing needed policy changes or exemptions before enforcement begins.

[Related: What the Mackay Sugar Shutdown Reveals About OT Segmentation Readiness]

How Do CIS Controls Apply to Unmanaged Devices?

The Center for Internet Security (CIS) Critical Security Controls are a widely used set of cybersecurity best practices for IT and connected device environments across all industries. They cover unmanaged devices from the first control onward. Control 1, Inventory and Control of Enterprise Assets, explicitly covers IoT and other non-computing devices alongside servers and workstations, and its safeguards call for a detailed asset inventory, a process to address unauthorized assets, and active and passive discovery tools that keep the inventory current.

Some of the most relevant controls include:

Control	Focus Area	Description
Control 1	Inventory and Control of Enterprise Assets	Actively manage all enterprise assets (connected devices including IoT) to ensure only authorized devices are given access.
Control 4	Secure Configuration of Enterprise Assets	Establish and maintain secure configurations of enterprise assets, including network and IoT devices.
Control 7	Continuous Vulnerability Management	Continuously assess and track vulnerabilities on all enterprise assets to remediate or mitigate vulnerabilities.
Control 12	Network Infrastructure Management	Establish, implement, and actively manage network devices to prevent unauthorized access, including secure network architecture with segmentation.
Control 13	Network Monitoring and Defense	Operate processes and tooling to establish central monitoring and defense of network traffic, including filtering between network segments.

Unmanaged devices are where many organizations fall short of Control 1, because endpoint agents and credentialed scans do not reach them. Discovery from network traffic and integrations is usually the only practical way to meet the inventory and unauthorized-asset safeguards for those devices.

Asimily helps map IoT, OT, IoMT, and IT assets to the CIS Controls and provides the discovery, unauthorized device detection, configuration monitoring, vulnerability prioritization, and segmentation enforcement these safeguards call for.

[Related: Unified Inventory and Visibility FAQ: Discovering, Classifying, and Tracking Every Connected Device]

How Do Connected Devices Factor Into CyberScope Reporting?

CyberScope is the platform federal civilian agencies in the United States use to submit required FISMA reporting. Connected devices factor in through the annual CIO FISMA metrics agencies submit there. The FY 2026 and FY 2027 CIO FISMA metrics ask agencies to quantify OT and IoT devices in their systems: how many systems include OT or IoT devices, how many include IoT, how many include OT, and how many include both.

The FISMA metrics submitted through CyberScope evaluate both asset inventory counts and key protective security controls across agency environments:

Metric Area	Reporting Expectation
Device Asset Counts	Quantify systems containing OT devices, IoT devices, or both across hardware inventories.
Access Control & MFA	Report the proportion of systems with OT/IoT enforcing phishing-resistant multifactor authentication.
Discovery & Visibility	Track average number of unknown devices discovered using Continuous Diagnostics and Mitigation (CDM).
Vulnerability Scanning	Report the percentage of discovered OT and IoT devices scanned for vulnerabilities within required intervals.

Accurate answers depend on device-level visibility. CISA’s Binding Operational Directive 23-01 already requires agencies to perform automated asset discovery every seven days and vulnerability enumeration across discovered assets every 14 days, and agencies without visibility into IoT and OT devices will struggle to meet either the directive or the FISMA metrics.

Asimily inventories IoT, OT, IoMT, and IT assets agentlessly and continuously, classifies each device so it can be counted by type, and identifies unknown devices as they appear on the network.

[Related: CyberScope Compliance]

Audit Evidence

What Evidence Do Auditors Expect for Connected Device Security?

Auditors expect evidence that connected devices are known, assessed, protected, and monitored, and that the organization can show how its decisions were made. For most frameworks, that means a current asset inventory, documented risk assessments and dispositions, records of vulnerability handling, proof that segmentation and access controls are enforced, configuration baselines with change records, and incident detection and response records. A well-documented change management process also helps, because it gives auditors confidence in the organization’s processes as well as its technical controls.

The inventory is usually the first request, and it has to be credible. Auditors look for completeness across device types, evidence that the inventory is maintained continuously, and a clear process for unknown or unauthorized devices. A spreadsheet exported last quarter rarely meets that bar.

Risk decisions need a documented rationale. When a vulnerability cannot be patched, auditors want to see why, which compensating control was applied, and how its effectiveness is verified. Enforcement evidence matters as much as design: a segmentation diagram shows intent, while policy records and traffic data show what the network actually does.

Asimily provides each layer of that evidence for IoT, OT, IoMT, and IT assets: a continuously updated inventory, a documented reason for every risk ranking, records of the mitigations applied, Configuration Control for configuration drift, and an auditable record of segmentation enforcement from Asimily’s Segmentation Orchestration.

[Related: Governance, Risk, and Compliance]

How Do I Prove Segmentation Is Enforced During an Audit?

Prove segmentation is enforced by showing auditors three things: the policy that defines what each device or zone may reach, the record of that policy applied at the enforcement point, and evidence from real traffic or testing that blocked flows stay blocked. A network diagram shows the design, and many auditors now ask for proof of operation as well.

Policy evidence includes the rules themselves, the device groups they apply to, and their change history. Enforcement evidence shows that the NAC or firewall carries those rules and that devices are assigned to them. Effectiveness evidence comes from traffic analysis or testing, such as PCI DSS segmentation penetration tests, showing that devices outside a zone cannot reach the systems inside it.

Continuity matters too. Auditors may ask what happened between tests: whether new devices received the right policy, whether moved devices kept their restrictions, and whether exceptions were reviewed.

Asimily’s Segmentation Orchestration provides an auditable record of enforcement effectiveness for audits and regulatory inquiries. Policy Simulation documents the expected impact of each policy before deployment, and Continuous Segmentation keeps enforcement aligned with network changes between audits.

[Related: Asimily Segmentation Orchestration]

How Do I Keep Devices Compliant as Configurations Drift?

Keep devices compliant as configurations drift by defining a secure baseline for each device type, monitoring devices against that baseline continuously, restoring the secure state when unauthorized changes appear, and keeping a record of each change for auditors. Taking a snapshot of a known-good configuration is the gold standard. Methods that rely only on traffic analysis catch a change only when it shows up on the wire, such as a new firmware version, so they miss more drift.

Most frameworks expect this: NIST CSF 2.0 calls for configuration management practices, CIS Control 4 covers secure configuration, NERC CIP-010 requires documented baselines and change monitoring, and IEC 62443 expects systems to stay at their target security level.

Connected devices drift through normal work. Vendor technicians change settings during service visits, factory resets restore default credentials, firmware updates reset security options, and integrators enable services that never get disabled. Each change can reopen a finding that was closed in the last audit.

Monitoring should cover the settings that matter for compliance, such as enabled services, credentials, remote access, and firmware version, and distinguish approved maintenance from unexpected change.

Asimily Configuration Control detects insecure configuration drift on IoT, OT, IoMT, and IT assets and restores the secure state, so teams can show auditors when drift occurred and how it was resolved.

[Related: Configuration Control]