- ClassificationCategoryCybersecurityDomainCybersecurityFramework FamilyOther
- Regulatory ContextTypeStandardLegal InstrumentFrameworkSectorCross-SectorIndustryCross-Industry
- Region / PublisherRegionGlobalRegion DetailInternational (published in the United States)PublisherCloud Security Alliance (CSA)
- VersioningVersionv2 (superseded by the CSA IoT Controls Matrix v3, April 25, 2022)Effective DateVoluntary; no enforcement date. Version 2 published January 28, 2021Issue DateJanuary 28, 2021
- AdoptionAdoption ModelVoluntaryImplementation ComplexityHigh
- Official ReferenceOpen Link in New TabSource
License included / downloadable: Yes
The Cloud Security Alliance publishes the framework workbook and its guide for free download on its site, with or without an account. The guide carries a CSA copyright notice that allows personal, informational and non-commercial use, without modification or redistribution, and SmartSuite does not include the workbook in the platform.
Framework text is licensed by its publisher and is included only where stated above.
- The CSA IoT Security Controls Framework v2 is a workbook of security controls for enterprise IoT systems, released January 28, 2021.
- It has been superseded by the CSA IoT Controls Matrix v3, published April 25, 2022, which CSA lists at 198 controls.
- The framework is voluntary, free of charge, and has no certification scheme or regulator behind it.
- Teams classify a system as low, moderate, or high impact, filter the controls, and allocate each to the device, network, gateway, or cloud layer.
- SmartSuite Cyber & IT Risk holds the control library by domain, each system's impact level, and the layer that owns each control.
Overview
The CSA IoT Security Controls Framework version 2 is a workbook of security controls for enterprise Internet of Things systems, released on January 28, 2021 by the Cloud Security Alliance (CSA) IoT Working Group. It has been superseded by the CSA IoT Controls Matrix version 3, published on April 25, 2022, which CSA lists at 198 controls, up from 155 in the first version. This page describes version 2 only.
CSA publishes the framework free of charge, with a companion guide. Aaron Guzman, Michael Roza and Brian Russell led the initiative. The framework is voluntary, has no certification scheme and no regulator behind it. Its stated users are system architects, developers and security engineers designing IoT systems, and auditors and penetration testers who validate controls and their implementations.
Teams implement it by classifying their system as low, moderate or high impact for confidentiality, integrity and availability, filtering the controls to those levels, then allocating each control to the device, network, gateway or cloud layer. They choose how to run each control (manual, automatic or semi-automatic) and how often, and record the residual risk where a component cannot meet a control.
Why does it matter?
IoT systems join constrained devices, local networks, gateways and cloud services, and a control that fits one layer may be meaningless on another. Version 2 organizes 21 control domains so that an architect can filter by impact level and assign each control to the layer that must implement it, while noting where a component cannot comply.
Key benefits include:
- Controls sized to impact
Impact levels follow FIPS 199 and FIPS 200. When an impact level is high, all available controls apply, including those for low and moderate levels.
- Controls assigned to architecture layers
Four columns let users filter for controls that apply to the device, the network that hosts it, a gateway or the cloud service.
- Implementation guidance in the sheet
Each control is typed as preventive, detective or corrective, marked manual, automatic or semi-automatic, and given a frequency from annually to continuously.
- A legal domain
Version 2 introduced a Legal domain covering legal assessment, terms and conditions and privacy policy, contracts, disclaimers, notifications, liability and data transfer.
- A security testing domain
Version 2 added Security Testing, with sub-domains for assessment scoping, penetration testing, red teaming, third-party assessments and bug bounty.
How does it work?
The framework is a spreadsheet with columns A to R, and the Guide to the IoT Security Controls Framework Version 2 explains each column. Columns A to C give the domain and sub-domain, column D the control ID such as RSM-01, column E the related CSA Cloud Controls Matrix IDs, and column F the control specification, written as a mitigation for an IoT risk. Version 1 had 155 base-level controls; version 2 reorganized them into a new domain structure and consolidated device types into one.
Version 2 has 21 control domains, each with a three-letter code: Asset Management (ASM), Configuration Management (CCM), Secure Communications (COM), Secure Data (DAT), Governance (GVN), Identity and Access Management (IAM), Incident Management (IMT), IoT Device Security (IOT), Legal (LGL), Monitoring and Logging (MON), Operational Availability (OPA), Physical Security (PHY), Policy (POL), Risk Management (RSM), Secure Applications (SAP), Secure System Development Lifecycle (SDV), Secure Networks (SNT), Secure Wireless (SWS), Training (TRN), Vulnerability Management (VLN) and Security Testing (SET).
Users first set the confidentiality, integrity and availability impact levels, then review the resulting controls in column F and the additional guidance in column J. Columns L to N set the control type, whether it is manual, automatic or semi-automatic, and how often it runs. Columns O to R allocate each control to the device, network, gateway and cloud layers. Allocated controls represent best-case postures, so the system security architect identifies components that cannot comply and plans alternative measures for the residual risk.
Key Elements
- Twenty-one control domains
Domains run from Asset Management to Security Testing, each with sub-domains for filtering. Sub-domains include Firmware Updates, MQTT Security, Trust Anchor Management, RF Monitoring, Zigbee Security and Zero Trust.
- Control IDs and CCM cross-reference
Every control has an ID made of its domain code and a number. Column E links a control to the related CSA Cloud Controls Matrix IDs, covering partial to full coverage of the CCM specification.
- Impact levels
Columns G to I take the low, moderate or high ratings for confidentiality, integrity and availability defined in FIPS 199, so users apply only the controls that match their system.
- Supplemental guidance
Column J gives additional direction such as special requirements and explanations of terms. Column K lists references, such as government publications and regulatory sources, needed to implement a control.
- Control type, method and frequency
Controls are preventive, detective or corrective. Each is manual, automatic or semi-automatic. Recommended frequencies are annually, quarterly, monthly, weekly, daily, on an event or continuously.
- Architectural allocation
Columns O to R show whether a control applies at the device, network, gateway or cloud service layer. The gateway is described as a high potential entry point for threat actors that may need controls beyond those on devices.
- Legal and Security Testing domains
These are the two domains new in version 2. Legal covers measures such as contracts, liability and data transfer; Security Testing covers penetration testing, red teaming, third-party assessments and bug bounty programs.
What does it cover?
The framework is relevant for enterprise IoT systems that include several kinds of connected devices, cloud services and networking technologies. It applies from systems that process only low-value data with limited impact to highly sensitive systems that support critical services, and the system owner assigns the classification based on the value of the data and the potential impact of physical security threats. It is a resource for system architects, developers and security engineers, and for auditors and penetration testers who validate controls.
What are its objectives?
The framework gives a tool for evaluating an IoT implementation's security as it moves through the development lifecycle.
Identify the security controls appropriate to an IoT system's impact level.
Allocate those controls to devices, networks, gateways and cloud services.
Give implementers the control type, method and frequency for each control.
Add legal and security testing controls to the technical ones.
Make residual risk visible where a component cannot meet a recommended control.
Help auditors and testers validate that controls are in place in the deployed system.
Framework in Context
Version 2 was released on January 28, 2021 and complements the CSA Cloud Controls Matrix through its CCM ID column. It relies on FIPS 199 and FIPS 200 for impact levels and lists, among other additional resources, NIST IR 8259 and 8259A, NIST IR 8228, two ENISA IoT guides and the ISO/IEC JTC 1/SC 41 IoT reference architecture. The version 2 guide named safety-specific controls, indicators of compromise and mappings to ENISA guidelines, NIST CSF and NIST SP 800-53 as planned improvements for version 3. The current release is the renamed IoT Controls Matrix version 3 (April 25, 2022).
Common Framework Mappings
The guide describes one mapping column, to CSA Cloud Controls Matrix IDs (column E). It lists mappings to the NIST Cybersecurity Framework and NIST SP 800-53 as planned for version 3, so none are claimed for version 2 here.
Mapped frameworks include:
CSA CCM v4
How SmartSuite Supports CSA IoT SCF v2
SmartSuite provides the system for managing controls, evidence, mappings, assessments, and reporting.
Use Cyber & IT Risk to hold the IoT control library by domain, the impact level of each system and the layer that owns each control, and Third Party Risk Management for device and platform suppliers.
Control Library by Domain
Hold the controls under the 21 domain codes and their control IDs, such as RSM-01, with an owner and review date for each.
Impact Level Tailoring
Record the confidentiality, integrity and availability impact level for each IoT system and show the controls that apply at that level.
Layer Allocation and Residual Risk
Assign each control to the device, network, gateway or cloud layer, and log residual risk and compensating measures where a component cannot comply.
Control Type and Frequency
Capture whether each control is preventive, detective or corrective, manual or automated, and schedule its review at the stated frequency.
Security Testing and Vulnerability Evidence
Attach penetration test, red team and third-party assessment results and vulnerability scan evidence to the controls in the Security Testing and Vulnerability Management domains.
Device Supplier Risk and Reporting
Link device makers and cloud platform suppliers to vendor assessments, and report control status by system and layer.
Related frameworks
CIS Controls v8.1 is a prioritized set of 18 Controls and 153 Safeguards, in three Implementation Groups, with a new Govern function.
IEC 62443-4-2:2019 sets technical security requirements for IACS components, with seven foundational requirements and security levels 1 to 4.
ISO/IEC 27001:2022 specifies requirements for an information security management system: Clauses 4 to 10, risk treatment, the Statement of Applicability and 93 Annex A controls.
ISO/IEC 27017:2026 gives cloud security control guidance for customers and providers, built on ISO/IEC 27002:2022, with four cloud-specific controls; it replaced the 2015 edition.
Frequently Asked Questions For CSA IoT Security Controls Framework v2 (IoT SCF)
No. CSA released the IoT Controls Matrix version 3, the renamed successor, on April 25, 2022. CSA's version 3 page lists 198 controls, up from 155 in the first version, and says technical clarity and references improved. Version 2, released on January 28, 2021, remains available on CSA's site.
The workbook has 21 control domains, such as Asset Management, Secure Communications, Governance, Legal and Security Testing, each with sub-domains. Each control has an ID like RSM-01, a related CSA Cloud Controls Matrix ID in column E and a control specification in column F (Guide to the IoT Security Controls Framework Version 2).
You rate the system's confidentiality, integrity and availability impact as low, moderate or high, using FIPS 199, and filter columns G to I accordingly. If an impact level is high, all available controls apply, including those for low and moderate levels. If it is moderate, the moderate and low controls apply (guide, page 10).
Columns O to R let you filter controls by the architectural layer that implements them. The framework treats these layers as trust boundaries. Because the allocations are best-case postures, the guide tells the security architect to identify components that cannot comply and plan alternative measures for the residual risk.
CSA's IoT Working Group wrote it and CSA publishes it for free download, with or without an account. The guide carries a copyright notice that limits use to personal, informational and non-commercial purposes, without modification or redistribution. CSA's current release is the IoT Controls Matrix version 3.
Put this framework to work in SmartSuite
Manage controls, risks, evidence, and audits in one platform designed for modern governance, risk, and compliance.