GSMA IoT Security Guidelines (CLP.11/FS.60), explained
The GSMA IoT Security Guidelines are a set of non-binding, freely downloadable guideline documents published by the GSM Association (GSMA), the trade body representing mobile network operators, aimed at helping the IoT industry build secure connected products and services. The overview document — CLP.11, "IoT Security Guidelines Overview Document," read for this guide at Version 2.0, dated 31 October 2017 — states its own role in its first section: "This document is the first part of a set of GSMA security guideline documents that are intended to help the nascent 'Internet of Things' industry establish a common understanding of IoT security issues." Each PDF is marked "This is a Non-binding Permanent Reference Document of the GSMA," Security Classification "Non-confidential," Copyright © 2017 GSM Association — freely downloadable, but not an open licence, so treat direct quotes here as brief excerpts rather than a substitute for reading the source PDFs.
A four-document set, plus a self-assessment checklist
CLP.11 §1.2 lays out the document structure and is explicit about reading order: "It is recommended that this document, (i.e. the overview document) is read as a primer before reading the supporting documents." The set comprises:
| Document | Covers |
|---|---|
| CLP.11 | IoT Security Guidelines Overview Document — the primer, read here |
| CLP.12 | IoT Security Guidelines for IoT Service Ecosystem — back-end servers, APIs, cloud infrastructure |
| CLP.13 | IoT Security Guidelines for IoT Endpoint Ecosystem — physical connected devices and gateways |
| CLP.14 | IoT Security Guidelines for Network Operators — top-level guidance for operators serving IoT Service Providers |
| CLP.17 | GSMA IoT Security Assessment Checklist — lets suppliers "self-assess the conformance of their products, services and components to the GSMA IoT Security Guidelines," with "Assessment declarations... made by submitting a completed declaration to the GSMA" |
CLP.11 itself names three audiences in §1.4: IoT Service Providers ("enterprises or organisations who are looking to develop new and innovative connected products and services"), IoT Device Manufacturers ("providers of IoT Devices to IoT Service Providers to enable IoT Services"), and IoT Developers ("build IoT Services on behalf of IoT Service Providers"), plus Network Operators acting in either of the first two roles.
Two ecosystems, split at the network
CLP.11 §4 (illustrated in its own "Example IoT Model" figure) divides any IoT deployment into two halves connected by a communications network, each covered by its own recommendation document:
- Service Ecosystem (§4.1, → CLP.12): "the set of services, platforms, protocols, and other technologies required to provide capabilities and collect data from Endpoints deployed in the field" — servers, databases, and the APIs (CLP.11 cites oneM2M as an example) that let IoT Service Providers monetise collected data.
- Endpoint Ecosystem (§4.2, → CLP.13): "low complexity devices, rich devices and gateways that connect the physical world to the digital world," with CLP.11 naming "motion sensors, digital door-locks, automotive telematics systems, sensor-driven industrial control systems, and more" as examples.
Splitting the two matters because they face genuinely different threat models — a cloud back-end's risks (container compromise, API abuse) are not a sensor's risks (physical tampering, side-channel attacks) — and CLP.11 leaves the network link itself to a fourth document, CLP.14, aimed at the operators carrying traffic between the two ecosystems.
No new risk methodology — deliberately
Where many standards invent their own risk-scoring scheme, CLP.11 §5.2 ("Risk Model References") explicitly declines to: "Rather than attempt to define a risk assessment and threat modelling process here, please review the following references for an adequate depiction and walk-through of the risk assessment process: National Institute of Standards and Technology (NIST)'s Risk Management Framework [5]; Computer Emergency Response Team (CERT)'s OCTAVE model [6]." What CLP.11 §5.1 does define is the goal any such process should serve — producing "a set of policies, procedures, and controls that remediate, monitor, and respond to gaps in security," with stated benefits of "Informing personnel, Enhancing processes, Defining (or updating) policies, Executing remediation, Monitoring for new gaps, Enhancing the product or service."
CLP.12's four-tier Service Ecosystem recommendations
CLP.12, "IoT Security Guidelines for IoT Service Ecosystem" (same Version 2.0 / 31 October 2017 publication line as CLP.11), organises its substantive guidance into four priority tiers, per its own table of contents:
| Tier | Section | Example recommendations |
|---|---|---|
| Critical | §5 | 5.1 Implement a Service Trusted Computing Base; 5.2 Define an Organizational Root of Trust; 5.8 Define an Incident Response Model; 5.9 Define a Recovery Model |
| High-Priority | §6 | 6.1 Define a Clear Authorization Model; 6.2 Manage the Cryptographic Architecture; 6.9 Implement Input Validation; 6.11 Enforce Strong Password Policy |
| Medium-Priority | §7 | 7.1 Define an Application Execution Environment; 7.3 Use a Private APN for Cellular Connectivity |
| Low-Priority | §8 | 8.1 Rowhammer and Similar Attacks; 8.2 Virtual Machine Compromises |
CLP.13 mirrors this structure for the Endpoint Ecosystem; this guide fetched and quotes CLP.11 and CLP.12 directly but has not independently re-fetched CLP.13's own text, so its specific clause numbers are not reproduced here — treat CLP.13 as covering equivalent endpoint-side ground (secure boot, update validation, tamper resistance) until independently verified.
Numbering has moved on; the guideline documents' substance, as far as verified, has not
CLP.11's own Document History (Annex C) shows three revisions: v1.0 on 08-Feb-2016 (editors Ian Smith of GSMA and Don A. Bailey of Lab Mouse Security), v1.1 on 07-Nov-2016 (added references to the GSMA IoT Security Assessment scheme), and v2.0 on 29-Sep-2017/31-Oct-2017 (added LPWA — NB-IoT/LTE-M — network information; editor Rob Childs, GSMA). GSMA's current website has since renumbered the overview document to FS.60, moving the CLP-numbered PDFs to an archive page. This guide fetched and quotes only the archived CLP.11/CLP.12 v2.0 PDFs directly; it has not independently fetched FS.60's current full text, so any substantive 2024-era updates should be confirmed against GSMA's own site before being relied on for a specific claim.
A workable starting point
- Read CLP.11 first, as GSMA itself recommends, before going to CLP.12/CLP.13/CLP.14 — it sets the Service/Endpoint Ecosystem model the other documents assume.
- Route back-end and device-side work to the matching document. A cloud/API team should work from CLP.12's four priority tiers; a firmware/hardware team should work from CLP.13 (verify its current text directly before citing specific clause numbers).
- Bring your own risk methodology. CLP.11 explicitly defers to NIST's Risk Management Framework or CERT's OCTAVE rather than prescribing one — pick one and apply it consistently rather than searching CLP.11 for a scoring rubric it doesn't contain.
- Use CLP.17's self-assessment checklist to demonstrate conformance if a customer or partner asks for evidence against these guidelines specifically.
- Check GSMA's current site for FS.60 before citing a specific 2026 clause. This guide's citations are anchored to the verified 2017 CLP.11/CLP.12 PDF text; GSMA's renumbering suggests the document set has moved since, and this guide has not independently verified what, if anything, changed substantively.
SoftWSP's device and firmware security assessments can map a connected product's authentication, cryptographic architecture and update mechanism against GSMA's Service/Endpoint Ecosystem recommendations alongside NIST and ETSI device baselines: see Device & Firmware Security.
This guide summarises text read directly from the GSMA CLP.11 v2.0 and CLP.12 v2.0 PDFs (31 October 2017) plus GSMA's current public document-set and archive pages; it is not a substitute for the full guideline documents and does not constitute compliance or legal advice.
More guides
Frequently asked questions
What is the GSMA IoT Security Guidelines document set?
It is a set of non-binding guideline documents published by the GSM Association (GSMA), the trade body representing mobile network operators, aimed at the IoT industry. Per the overview document's own text: "This document is the first part of a set of GSMA security guideline documents that are intended to help the nascent 'Internet of Things' industry establish a common understanding of IoT security issues. The set of guideline documents promotes a methodology for developing secure IoT Services to ensure security best practices are implemented throughout the life cycle of the service." The version of the set read for this guide — CLP.11 "IoT Security Guidelines Overview Document," Version 2.0, dated 31 October 2017 — is marked "This is a Non-binding Permanent Reference Document of the GSMA," Security Classification "Non-confidential," Copyright © 2017 GSM Association.
How is the document set structured, and which document do you read first?
Per CLP.11 §1.2 and its Figure 1 ("GSMA IoT Security Guidelines Document Structure"), the set has four core documents plus a checklist: **CLP.11** (IoT Security Guidelines Overview Document — this document), **CLP.12** (IoT Security Guidelines for IoT Service Ecosystem), **CLP.13** (IoT Security Guidelines for IoT Endpoint Ecosystem), **CLP.14** (IoT Security Guidelines for Network Operators), plus **CLP.17** (GSMA IoT Security Assessment Checklist), which "enables the suppliers of IoT products, services and components to self-assess the conformance of their products, services and components to the GSMA IoT Security Guidelines." CLP.11 §1.2 states directly: "It is recommended that this document, (i.e. the overview document) is read as a primer before reading the supporting documents."
What is the Service Ecosystem vs. Endpoint Ecosystem split, and why does it matter?
CLP.11 §4 splits every IoT deployment into two halves joined by a communications network. §4.1 defines the **Service Ecosystem** as "the set of services, platforms, protocols, and other technologies required to provide capabilities and collect data from Endpoints deployed in the field" — servers, APIs, and back-end infrastructure, covered in detail by CLP.12. §4.2 defines the **Endpoint Ecosystem** as "low complexity devices, rich devices and gateways that connect the physical world to the digital world," with examples including "motion sensors, digital door-locks, automotive telematics systems, sensor-driven industrial control systems, and more" — covered by CLP.13. The split matters because the two halves face different threat models and get their own dedicated recommendation documents rather than one combined list.
What risk-assessment method does CLP.11 prescribe?
None of its own — CLP.11 §5.2 ("Risk Model References") is explicit that it defers rather than invents: "Rather than attempt to define a risk assessment and threat modelling process here, please review the following references for an adequate depiction and walk-through of the risk assessment process: National Institute of Standards and Technology (NIST)'s Risk Management Framework [5]; Computer Emergency Response Team (CERT)'s OCTAVE model [6]." §5.1 does define the goal of whatever process is used: "to create (or update) a set of policies, procedures, and controls that remediate, monitor, and respond to gaps in security found in the technical part of the organization," listing core benefits as "Informing personnel, Enhancing processes, Defining (or updating) policies, Executing remediation, Monitoring for new gaps, Enhancing the product or service."
How does CLP.12 prioritise its Service Ecosystem recommendations?
CLP.12 ("IoT Security Guidelines for IoT Service Ecosystem," Version 2.0, 31 October 2017 — the same publication date and version line as CLP.11) organises its recommendations into four priority tiers, per its own table of contents: **§5 Critical Recommendations** (e.g. 5.1 Implement a Service Trusted Computing Base, 5.2 Define an Organizational Root of Trust, 5.8 Define an Incident Response Model), **§6 High-Priority Recommendations** (e.g. 6.1 Define a Clear Authorization Model, 6.2 Manage the Cryptographic Architecture, 6.9 Implement Input Validation), **§7 Medium-Priority Recommendations**, and **§8 Low-Priority Recommendations** (e.g. 8.1 Rowhammer and Similar Attacks). CLP.13 covers the equivalent ground for the Endpoint Ecosystem; this guide has not independently re-fetched CLP.13's own text and does not reproduce its specific clause numbers.
Is CLP.11/CLP.12 still the current version, and does GSMA charge for these documents?
Partially superseded in numbering, not in substance, as far as this guide can confirm. The CLP.11/CLP.12/CLP.13/CLP.14/CLP.17 numbering dates to 2016–2017 (CLP.11's own Document History shows v1.0 on 08-Feb-2016, v1.1 on 07-Nov-2016, and the v2.0 read for this guide on 29-Sep-2017/31-Oct-2017). GSMA's current website now lists the overview document under a new code, **FS.60** ("GSMA IoT Security Guidelines Overview"), with the CLP-numbered PDFs moved to an archive page — this guide fetched and quotes only the archived CLP.11/CLP.12 v2.0 PDFs directly and has **not** independently fetched FS.60's current full text, so treat any 2024-era content changes under FS.60 as **to be confirmed** against GSMA's own site. On cost: unlike many formal standards bodies, GSMA publishes these PDFs for free public download from gsma.com; they are **not open-licensed**, however — each page carries "This document is confidential to the Association and is subject to copyright protection... to be used only for the purposes for which it has been supplied," so quote briefly rather than republish wholesale.
Sources
- GSMA: CLP.11 — IoT Security Guidelines Overview Document, Version 2.0, 31 October 2017 (PDF, fetched directly)
- GSMA: CLP.12 — IoT Security Guidelines for IoT Service Ecosystem, Version 2.0, 31 October 2017 (PDF, fetched directly)
- GSMA: IoT Security Guidelines Overview — FS.60 (current document landing page)
- GSMA: IoT Security Guidelines (current landing page, document set and assessment scheme)
- GSMA: IoT Security Guidelines Document Archive (CLP.11–CLP.17 PDFs)