1 Draft NISTIR 8200

Interagency Report on Status of 2

International Cybersecurity 3

Standardization for the 4

5 Internet of Things (IoT)

6

7 Prepared by the Interagency International Cybersecurity Standardization Working 

8 Group.

9

10

11

12

13

14 The Interagency International Cybersecurity Standardization Working Group (IICS WG) has developed 

15 this draft report based upon the information available to the participating agencies. Comments are 

16 being solicited in order to augment that information, especially on the information about the state of 

17 cybersecurity standardization for IoT that is found in Sections 8, 9, 10, and Annex D. 

18

19 Reviewers are requested to submit comments to NISTIR-8200@nist.gov using the comment template 

20 at https://csrc.nist.gov/publications/detail/nistir/8200/draft. Comments will be posted at

21 https://www.nist.gov/itl/comments-draft-nistir-8200 as they are received.
22 Draft NISTIR 8200

Interagency Report on Status of 23

International Cybersecurity 24

Standardization for the 25

26 Internet of Things (IoT)

27

28 Prepared by the Interagency International Cybersecurity Standardization Working 

29 Group.

30

31 NIST Editors:

32 Mike Hogan

33 Ben Piccarreta

34 Information Technology Laboratory

35

36

37

38

39

40 February 2018

41

42

43

44

45

46 U.S. Department of Commerce

47 Wilbur L. Ross, Jr., Secretary

48

49 National Institute of Standards and Technology 

50 Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology
51 National Institute of Standards and Technology Interagency Report 8200

52 187 pages (February 2018)

53 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an 

54 experimental procedure or concept adequately. Such identification is not intended to imply recommendation or 

55 endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best 

56 available for the purpose. 

57 There may be references in this publication to other publications currently under development by NIST in accordance 

58 with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, 

59 may be used by federal agencies even before the completion of such companion publications. Thus, until each 

60 publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For 

61 planning and transition purposes, federal agencies may wish to closely follow the development of these new 

62 publications by NIST. 

63 Organizations are encouraged to review all draft publications during public comment periods and provide feedback to 

64 NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at 

65 https://csrc.nist.gov/publications.

66

67 Public comment period: February 14, 2018 through April 18, 2018

68 National Institute of Standards and Technology

69 Attn: Information Technology Laboratory

70 100 Bureau Drive (Mail Stop 8900) Gaithersburg, MD 20899-8900

71 Email: NISTIR-8200@nist.gov

72 All comments are subject to release under the Freedom of Information Act (FOIA).

73 Reviewers are encouraged to use the comment template available at 

74 https://csrc.nist.gov/publications/detail/nistir/8200/draft. Comments will be posted at 

75 https://www.nist.gov/itl/comments-draft-nistir-8200 as they are received.

76
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

ii

77 Reports on Computer Systems Technology

78 The Information Technology Laboratory (ITL) at the National Institute of Standards and 

79 Technology (NIST) promotes the U.S. economy and public welfare by providing technical 

80 leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test 

81 methods, reference data, proof of concept implementations, and technical analyses to advance the 

82 development and productive use of information technology. ITL’s responsibilities include the

83 development of management, administrative, technical, and physical standards and guidelines for 

84 the cost-effective security and privacy of other than national security-related information in federal 

85 information systems.

86 Abstract

87 The Interagency International Cybersecurity Standardization Working Group (IICS WG) was 

88 established in December 2015 by the National Security Council’s Cyber Interagency Policy 

89 Committee (NSC Cyber IPC). Its purpose is to coordinate on major issues in international 

90 cybersecurity standardization and thereby enhance U.S. federal agency participation in 

91 international cybersecurity standardization.

92

93 Effective U.S. government participation involves coordinating across the U.S. government and

94 working with the U.S. private sector. There is a much greater reliance in the U.S. on the private 

95 sector for standards development than in many other countries. Companies and industry groups, 

96 academic institutions, professional societies, consumer groups, and other interested parties are 

97 major contributors. Further, the many Standards Developing Organizations (SDOs) who provide 

98 the infrastructure for the standards development are overwhelmingly private sector organizations.

99

100 On April 25, 2107, the IICS WG established an Internet of Things (IoT) Task Group to determine 

101 the current state of international cybersecurity standards development for IoT. This Report is 

102 intended for use by the IICS WG member agencies to assist them in their standards planning and 

103 to help to coordinate U.S. government participation in international cybersecurity standardization 

104 for IoT. Other organizations may also find this useful in their planning.

105

106 Keywords

107 cybersecurity; cybersecurity objectives; cybersecurity risks; cybersecurity threats; IT; information 

108 technology; IoT; Internet of Things; IoT components; IoT systems; SDO; standards developing 

109 organizations; standards; standards gaps

110
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

iii

111 Executive Summary

112 The Interagency International Cyber Security Working Group (IICS WG) was created in 

113 response to recommendations from NISTIR 8074 Volume 1 [1]. The IICS WG coordinates on 

114 major issues in international cybersecurity standardization. The IICS WG established an Internet 

115 of Things (IoT) Task Group to develop this Report on the status of international cybersecurity 

116 standards that are relevant to IoT.

117 The Internet of Things (IoT) consists of network connected devices, systems, and resulting 

118 services. The adoption of IoT and its applications is rapidly growing and the ensuing 

119 opportunities and benefits are significant. However, to reap the substantial benefits and to 

120 minimize the potentially significant risks, IoT security and resiliency are critical. 

121 The timely availability of international cybersecurity standards is a dynamic and critical 

122 component for the cybersecurity and resilience of all information and communications systems 

123 and supporting infrastructures. The intended audience is both the government and public. The 

124 purpose is to inform and enable policymakers, managers, and standards participants as they seek 

125 timely development of and use of such standards in IoT components, systems, and services.

126 The Report relies upon terms and definitions that are defined in Annex A – Terms and 

127 Definitions of NISTIR 8074 Volume 2 [2], and rather than attempting to define “IoT,” employs a

128 functional description to establish a common understanding of IoT components, systems and 

129 applications for which the standards could be relevant. This analysis starts with a functional 

130 description of IoT components, which are the basic building blocks of IoT systems.

131 To gain insight on the present state of IoT cybersecurity standardization, five IoT technology 

132 application areas are described. These application areas are not exhaustive but are sufficiently 

133 representative to use in an analysis of the present state of IoT cybersecurity standardization. 

134 Connected vehicle (CV) IoT enables vehicles, roads, and other infrastructure to communicate 

135 and share vital transportation information. Consumer IoT consists of IoT applications in the 

136 residence as well as wearable and mobile devices. Health IoT processes data derived from 

137 sources such as electronic health records and patient generated health data. Smart building IoT 

138 includes energy usage monitoring systems, physical access control security systems and lighting 

139 control systems. Smart manufacturing IoT enables enterprise-wide integration of data, 

140 technology, advanced manufacturing capabilities, and cloud and other services.

141 Building upon NISTIR 8074 Volume 2, this Report describes eleven cybersecurity core areas 

142 and provides examples of relevant standards. IoT cybersecurity objectives, risks, and threats are 

143 then analyzed for IoT applications in general and for each of the five IoT technology application 

144 areas. Cybersecurity objectives for traditional IT systems generally prioritize Confidentiality, 

145 then Integrity, and lastly Availability. IoT systems cross multiple sectors as well as use cases 

146 within those sectors. As such, the priority of the individual’s cybersecurity objectives may be 

147 prioritized very differently, depending on the application. The proliferation and increased 

148 ubiquity of IoT components and systems are likely to heighten the risks they present. Standards149 based cybersecurity risk management will continue to be a major factor in the trustworthiness of 

150 IoT applications. Through analysis of the application areas, cybersecurity for IoT is unique and 

151 will require tailoring of existing standards, as well as, creation of new standards to address pop152 up network connections, shared system components, the ability to change physical aspects of the 

153 environment, and related connections to safety.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

iv

154 With this foundational basis, this Report provides an analysis of the standards landscape for IoT 

155 cybersecurity. The basis for this analysis is the information in Annex D, which maps IoT 

156 relevant cybersecurity standards to the eleven cybersecurity core areas. The annotated listings in 

157 Annex D are not exhaustive but do represent an extensive effort to identify presently relevant 

158 IoT cybersecurity standards. The market impacts of existing standards are noted and possible 

159 gaps in standards identified. While the Annex D listing is a onetime snapshot, Annex D should 

160 prove useful as a point of departure for maintaining awareness of the evolving standards 

161 landscape. A summary on the status of cybersecurity standardization for the five specific 

162 examples of IoT applications is provided in Table 4: Status of Cybersecurity Standardization for

163 Several IoT Applications. 

164 The Report’s conclusions focus upon the issue of standards gaps and the effective use of existing 

165 standards. For identified priorities, agencies should work with industry to initiate new standards 

166 projects in Standards Developing Organizations (SDOs) to close such gaps. In accordance with 

167 USG policy [3], agencies should participate in the development of IoT cybersecurity standards 

168 and, based upon each agency’s mission, agencies should cite appropriate standards in their 

169 procurements. Also, in accordance with USG policy, agencies should work with industry to 

170 support the development of appropriate conformity assessment schemes to the requirements in 

171 such standards.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

v

172 Table of Contents

173 Executive Summary ..................................................................................................... iii

174 1 Introduction ............................................................................................................ 1

175 2 Scope ...................................................................................................................... 2

176 3 Methodology........................................................................................................... 3

177 4 The Internet of Things (IoT)................................................................................... 4

178 5 Examples of IoT Applications ............................................................................... 9

179 5.1 Connected Vehicles (CV)................................................................................ 9

180 5.2 Consumer IoT ............................................................................................... 10

181 5.3 Health IoT and Medical Devices ................................................................... 13

182 5.4 Smart Buildings............................................................................................. 16

183 5.5 Smart Manufacturing..................................................................................... 19

184 6 Cybersecurity Areas and IoT............................................................................... 22

185 6.1 Cryptographic Techniques ............................................................................ 22

186 6.2 Cyber Incident Management......................................................................... 23

187 6.3 Hardware Assurance .................................................................................... 24

188 6.4 Identity and Access Management................................................................. 25

189 6.5 Information Security Management Systems (ISMS) ..................................... 26

190 6.6 IT System Security Evaluation ...................................................................... 27

191 6.7 Network Security........................................................................................... 28

192 6.8 Security Automation and Continuous Monitoring (SACM) ............................ 29

193 6.9 Software Assurance...................................................................................... 29

194 6.10 Supply Chain Risk Management (SCRM)..................................................... 30

195 6.11 System Security Engineering........................................................................ 31

196 7 IoT Cybersecurity Objectives, Risks, and Threats............................................ 33

197 7.1 Overview....................................................................................................... 33

198 7.2 Connected Vehicles ...................................................................................... 37

199 7.3 Consumer IoT ............................................................................................... 39

200 7.4 Health IoT and Medical Devices ................................................................... 41

201 7.5 Smart Buildings............................................................................................. 43

202 7.6 Smart Manufacturing..................................................................................... 44

203 8 Standards Landscape for IoT Cybersecurity..................................................... 46

204 8.1 Cryptographic Techniques ............................................................................ 47
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

vi

205 8.2 Cyber Incident Management......................................................................... 48

206 8.3 Hardware Assurance .................................................................................... 48

207 8.4 Identity and Access Management................................................................. 49

208 8.5 Information Security Management Systems (ISMS) ..................................... 49

209 8.6 IT System Security Evaluation ...................................................................... 50

210 8.7 Network Security........................................................................................... 50

211 8.8 Security Automation and Continuous Monitoring (SACM) ............................ 51

212 8.9 Software Assurance...................................................................................... 51

213 8.10 Supply Chain Risk Management (SCRM)..................................................... 52

214 8.11 System Security Engineering........................................................................ 52

215 9 Status of International Cybersecurity Standards for Selected IoT Applications

216 53

217 10 Conclusions.......................................................................................................... 55

218

219 List of Annexes

220 Annex A— Some IoT Definitions and Descriptions.................................................. 57

221 Annex B— An IoT Capabilities Table......................................................................... 59

222 Annex C— An IT Standards Maturity Model ............................................................. 61

223 Annex D— IoT Standards Mapping to Core Areas of Cybersecurity...................... 63

224 Annex E— NIST Federal Information Processing Standards (FIPS) and NIST 

225 Special Publication 800 Series Relevant to IoT ...................................................... 166

226 Annex F— Acronyms................................................................................................ 171

227 Annex G— References.............................................................................................. 174

228

229 List of Figures

230 Figure 1 – Relationship Between Information Security and Privacy ................................ 2

231 Figure 2 – Capabilities of an IoT Component. ................................................................. 6

232 Figure 3 – Vehicle-to-Vehicle Communications .............................................................. 9

233 Figure 4 – V2X Public Key Infrastructure Overview ...................................................... 10

234 Figure 5 – Home Lighting Application............................................................................ 12

235 Figure 6 – Precision Medicine Research Case ............................................................. 15

236 Figure 7 – Diabetes Treatment/Allergen Identification .................................................. 16

237 Figure 8 – IoT for the GSA Smart Building.................................................................... 18
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

vii

238 Figure 9 – Smart Manufacturing Environment............................................................... 19

239 Figure 10 – Security Management Plan ........................................................................ 20

240 Figure 11 – Beecham Research IoT Security Threat Map ........................................... 34

241

242 List of Tables

243 Table 1 – Characteristics of the Health IoT Environment .............................................. 14

244 Table 2 – IoT Components for Intelligent Buildings....................................................... 17

245 Table 3 – Examples of Cybersecurity Risks to Networked Medical Devices and 

246 Connected ID Networks ......................................................................................... 42

247 Table 4 – Status of Cybersecurity Standardization for Several IoT Applications........... 53

248 Table 5 – IoT Primary Capabilities Table ...................................................................... 59

249 Table 6 – IT Standards Maturity Model ......................................................................... 61

250
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

1

251 1 Introduction 

252 The Internet of Things (IoT) has already changed the world for individual consumers and 

253 citizens, as well as for governments and industry. It is expected to be even more revolutionary 

254 and ubiquitous in the future. Yet, the adoption of IoT brings cybersecurity risks that pose a 

255 significant threat to the Nation.

256

257 The President’s National Security Telecommunications Advisory Committee (NSTAC) has 

258 examined the cybersecurity implications of IoT within the context of national security and 

259 emergency preparedness (NS/EP). This examination “found that IoT adoption will increase in 

260 both speed and scope, and that it will impact virtually all sectors of our society. Additionally, the 

261 NSTAC determined that there is a small—and rapidly closing—window to ensure that IoT is 

262 adopted in a way that maximizes security and minimizes risk. If the country fails to do so, it will 

263 be coping with the consequences for generations [4].”

264

265 The President’s Commission on Enhancing National Cybersecurity reached a similar conclusion: 

266 “The IoT facilitates linking an incredible range of devices and products to each other and the 

267 world. Although this connectivity has the potential to revolutionize most industries and many 

268 facets of everyday life, the possible harm that malicious actors could cause by exploiting these 

269 technologies to gain access to parts of our critical infrastructure, given the current state of 

270 cybersecurity, is immense [5].”

271

272 Our economy is increasingly global, complex, and interconnected. It is characterized by rapid 

273 advances in information technology (IT). IT products and services need to provide sufficient 

274 levels of cybersecurity and resilience. The timely availability of international cybersecurity 

275 standards is a dynamic and critical component for the cybersecurity and resilience of all 

276 information and communications systems and supporting infrastructures [6].

277

278 The growth of network-connected devices, systems, and services comprising the Internet of

279 Things creates immense opportunities and benefits for our society [7]. However, to reap the great 

280 benefits of IoT and to minimize the potentially significant risks, these networked connected 

281 devices need to be secure and resilient. This depends in large part upon the timely availability 

282 and widespread adoption of clear and effective international cybersecurity standards.

283
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

2

284 2 Scope

285 This Report examines the current state of international cybersecurity standards development by 

286 voluntary consensus standards bodies for IoT [8].

287

288 This Report distills IoT down to the simplest concepts and describes the nuances associated with 

289 these concepts. It acknowledges but does not focus on specific technologies or concerns 

290 associated with IoT such as societal impact, safety, or privacy.

291

292 This Report recognizes that cybersecurity—and cybersecurity standards— can support 

293 individuals’ safety and privacy. For example, cybersecurity standards when applied to the 

294 confidentiality, integrity, or availability of personally identifiable information (PII) are an 

295 important component of protecting individuals’ privacy. However, privacy cannot be achieved 

296 solely by securing individuals’ PII (see Figure 1). As noted in NIST Internal Report 8062, 

297 privacy concerns can arise from intentional or authorized processing of information about 

298 individuals, and in certain contexts, even measures used to secure PII can result in privacy issues

299 [9].

300

Figure 1 – Relationship Between Information Security and Privacy 301 1

 

1 Id. at 8.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

3

302 3 Methodology

303 This Report uses terms and definitions as they are defined in Annex A – Terms and Definitions 

304 of NISTIR 8074 Volume 2, Supplemental Information for the Interagency Report on Strategic 

305 U.S. Government Engagement in International Standardization to Achieve U.S. Objectives for 

306 Cybersecurity, December 2015.

307

308 This Report: 

309  provides a functional description for IoT;

310  describes several IoT applications that are representative examples of IoT;

311  summarizes the cybersecurity core areas and provides examples of relevant standards;

312  describes IoT cybersecurity objectives, risks, and threats;

313  provides an analysis of the standards landscape for IoT cybersecurity; and

314  maps IoT relevant cybersecurity standards to cybersecurity core areas (Annex D).

315
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

4

316 4 The Internet of Things (IoT)

317 IoT is a concept based on creating systems that interact with the physical world using networked 

318 entities (e.g., sensors, actuators, information resources, people).

319

320 There can be confusion around the meaning of the term “Internet of Things” for a variety of 

321 reasons. They include: the cross-cutting aspect of IoT (specifically with respect to application 

322 domains); the multitude of stakeholders involved in IoT and their specific use cases; the 

323 complexity of IoT; and the rapidly changing technology supporting IoT. 

324

325 While there is no universal definition of IoT, common elements exist among the many high-level 

326 definitions and descriptions for IoT. A few IoT definitions and descriptions from other sources 

327 are listed in Annex A.

328

329 The Internet of Things consists of two foundational concepts:

330  IoT components are connected by a network providing the potential for a many-to-many 

331 relationship between components (this network capability may or may not be TCP/IP 

332 based); and

333  some of the IoT components have sensors and actuators that allow the components to 

334 interact with the physical world.

335

336 For the purposes of this Report, the following definitions apply:

337

338 Component: an entity that can interact with other entities to form systems that can achieve 

339 goals(s).

340

341 IoT component: a type of component that provides a network interface and therefore may be 

342 composed into IoT systems.

343

344 NOTE 1: IoT components are the basic building blocks of IoT systems.

345

NOTE 2: An IoT component has some combination of the following capabilities: 2 346

347 actuating, data storing, human user interface (UI), networking, network interface, 

348 processing, sensing, and supporting. 

349

350 NOTE 3: Other publications use “IoT device” as a synonym for “IoT component” or define 

351 “device” as an actuator or sensor.

352

353 NOTE 4: An entire IT system can be an IoT component.

354

355 System: a set of components that interact together to achieve some goal. 

356

357 IoT system: a system composed of IoT components or other, integrated IoT systems that 

 

2 A basic definition of a capability is the quality of being able to perform a given activity.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

5

358 interacts with a physical entity of interest through sensors and actuators.

359

360 NOTE: IoT systems may also be IoT components if the IoT system provides a network 

361 interface. 

362

363 IoT environment: a set of IoT components and supporting technologies that are networked 

364 together and can be built into IoT systems, which are also part of the IoT environment.

365

366 NOTE: An IoT environment is not a type of cyber-physical system. 

367

368 As shown in Figure 2 below, the basic element of an IoT system is the IoT component. IoT 

369 components exhibit some combination of the five primary capabilities and three secondary 

370 capabilities shown. The five primary capabilities focus on the functionality the IoT component 

371 provides to the IoT system. The three secondary capabilities focus on how the IoT components 

372 work together. Some examples of capability functions are:

373  Aggregation is part of a primary capability (i.e., processing) that provides the ability to 

374 combine and process some data of interest within a given IoT system. 

375  An Ethernet card is a part of a secondary capability (i.e., network interface) that provides 

376 the ability to connect different IoT components together within a given IoT system.

377 • Orchestration is part of a secondary capability (i.e., supporting) that allows the individual 

378 IoT components to interact together forming a system.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

6

379

380 Figure 2 – Capabilities of an IoT Component. 

381 An IoT system builder combines IoT components to create an IoT system that can meet a set of 

382 requirements. By understanding each IoT component as a set of capabilities, an IoT system 

383 builder can match those capabilities to the IoT system requirements. Using this capabilities 

384 viewpoint, an IoT component can be understood by the set of capabilities it provides. These 

385 capabilities are described below.

386

Primary Capabilities3 387 of an IoT Component (which may also be an IoT system)

388 Actuating 

389 The actuation capability provides the ability to make a change in the physical world. A black box 

390 control system that accepts a desired outcome as an input and uses internal sensors, actuators, 

391 and processors to make the physical changes to achieve the desired outcome would be 

 

3 See Appendix B Table 5: IoT Primary Capabilities Table.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

7

392 considered an actuator in this model (since the model focuses on black box IoT components and 

393 their data inputs and outputs). Some other examples of actuation capability include: heating coil 

394 (heating capability), electric shock delivery (cardiac pacing), electronic door lock (lock/unlock 

395 capability), UAV operation (remote control), servo motors (motion/movement capability), and 

396 robotic arm (complex motion/movement capability). 

397 Data Storing 

398 The data storing capability provides the ability to store data and information over time. Some 

399 examples of data storing capability include storage of component input as well as the storage of 

400 component generated data. Electronic patient records are an example of this.

401 Networking 

402 The networking capability provides the ability to move data from one physical or logical location 

403 to another. A component’s network capability impacts the latency of information flow as well as 

404 the rate at which that information can flow. Some examples of networking capability include: 

405 Ethernet, Institute of Electrical and Electronics Engineers (IEEE) 802.11, and RS-422. Complex 

406 human operated surgical robots which incorporate haptic feedback and optical guidance are an 

407 example of sophisticated multi-mode networking.

408 Processing 

409 The processing capability provides the ability to transform data based on an algorithm. The 

410 transformation may be very simple, with a single input variable and a single output, or it may be 

411 complex with multiple inputs and outputs. Control algorithms are an important type of 

412 processing that take the output of sensor(s) and actuator(s) or pre-processor(s) and provide an 

413 output that can be fed into an actuator or post-processor. These control algorithms often are used 

414 within negative feedback loops, but not always. A proportional-integral- derivative (PID) control 

415 algorithm is an example of such a control algorithm. Another example might be an algorithm 

416 which models the human insulin response in a real-time system that manages the function of an 

417 artificial pancreas.

418 Some additional examples of processing include: data aggregation capability and binary 

419 (Yes/No) analysis.

420 Sensing 

421 The sensing capability provides the ability to sense an aspect of the physical or logical world.

422 IoT components with sensing capability may acquire data in both analogue (e.g., a light sensor) 

423 or digital (e.g., a switch) form. Information about sensor observations may be provided to other 

424 IoT components through a networking capability for processing and storage or those capabilities 

425 may be native to the component. Examples include: temperature sensing (temperature 

measurement capability), CT scans4 426 (radiographic imaging), optical sensing, and audio sensing.

427 Secondary Capabilities of an IoT Component (which may also be an IoT system)

428 Human User Interface (UI)

 

4 This illustrates the nature of complex sensing systems which can apply potentially harmful energy through actuators.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

8

429 The human UI capability provides the ability for the component to interact directly with people. 

430 Not all IoT components will have a human UI capability (i.e., a dedicated processing 

431 component). These components will pass information to other system components in order to 

432 support the UI capability. Some examples of human UI capabilities include: optical and tactile 

433 display, and audio input and output. 

434 Network Interface

435 The network interface capability provides the interface between communication network 

436 components necessary for communicating data between them. Every IoT component must have 

437 at least one network interface capability and may have more than one. While the network 

438 interface capability allows for a component to be connected to a communication network, it does 

439 not provide the communication (networking) capability. Some examples of network interface 

440 capability include: Ethernet adapter interface capability, long-term evolution (LTE) radio 

441 interface capability, and ZigBee radio interface capability. 

442 Supporting 

443 The supporting capability provides nonfunctional capabilities that support the main capabilities 

444 of IoT. Some examples of supporting capability include: encryption capability and authentication 

445 capability. IoT components performing sensing and/or actuating capabilities do not normally 

446 incorporate cryptographic controls (i.e. supporting capability) built-in so risk-adjacent447 authentication is difficult unless additional engineering is implemented.

448

449 An IoT Component as a Black Box

450 From an IoT perspective, a “black box” viewpoint of each component is useful, because an IoT 

451 system builder may not have access to any details of the internal workings of an IoT component. 

452 In fact, the internal workings of a component may change over time. This is especially relevant 

453 for IoT systems of systems, in which components are comprised of other IoT components. When 

454 interfaces, capabilities, and limitations of a component are accurately and completely 

455 documented, including any details necessary for the system builder to map the component 

456 against capabilities to system requirements, the details of the inner workings may not be 

457 important. An IoT component that is documented in this manner provides the described 

458 capabilities within the described limitations, and can be easily integrated into systems, regardless 

459 of internal implementations. There are use cases where the internal workings of an IoT 

460 component may need to be completely documented and understood, including National Security 

461 Systems (NSS), and systems that carry a risk of injury or harm to an individual.

462
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

9

463 5 Examples of IoT Applications

464 For this Report, several significant IoT applications have been selected. They are considered to 

465 be sufficiently representative to use in the analysis of the present state of IoT cybersecurity 

466 standardization.

467

468 5.1 Connected Vehicles (CV)

469 Connected vehicle (CV) technology is expected to enable vehicles, roads, and other 

470 infrastructure to communicate and share vital transportation information. One proposed method 

471 for connecting vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) is dedicated short472 range communications (DSRC), which is currently being studied by the Intelligent 

473 Transportations Systems Joint Program Office (ITS-JPO) at the U.S. Department of 

474 Transportation (DOT). 

475

476

477 Figure 3 – Vehicle-to-Vehicle Communications [10]

478 DSRC is currently part of a CV pilot run by DOT. The expectation is that a vehicle will use 

479 DSRC to transmit its position, direction, and speed, as well as other information, to vehicles 

480 sharing the road. DSRC will also “talk” to equipment installed in the road itself and other 

481 infrastructure, such as traffic signals, stop signs, toll booths, work or school zones, and railroad 

482 crossings [11]. One concept implementation of DSRC has vehicles exchange Basic Safety 

483 Messages (BSM), which will be included with security credentials (see Figure 3, above). A 

484 possible alternative to DSRC is a technology concept called Visible Light Communication 

485 (VLC). LED lights are increasing being added to vehicles, and VLC can utilize these LED lights 

486 to communicate in the V2V and V2I scenarios.

487
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

10

488 The Security Credential Management System (SCMS) Proof-of-Concept (POC) is under 

489 development by the U.S. DOT. One of the objectives of this system is to support a subset of 

490 security needs for the CV Pilots Program. Therefore, each Pilot site must interface with and use 

491 the SCMS as part of its approach to address at least a subset of the Pilot’s security requirements

492 [12]. The goal of the SCMS POC design is to provide security services to support Vehicle-to493 Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) communications at current passenger-vehicle 

494 production levels (up to 17 million annually) for the first year of deployment. 

495

496

497 Figure 4 – V2X Public Key Infrastructure Overview [13]

498 An additional important goal of the SCMS POC system is to provide a flexible architecture that 

499 is capable of scaling to support larger numbers of V2V and V2I devices in the years following 

500 initial deployment [14]. The messages transmitted by vehicles are digitally signed to guarantee 

501 their integrity and authenticity. See Figure 4, above, for a vehicle-to-vehicle (V2V) and vehicle502 to-infrastructure communication (V2I) (consolidated as V2X) Public Key Infrastructure 

503 overview.

504

505 Significant privacy and security challenges associated with both of these projects, including 

506 policies and laws governing the use of the information within BSM, as well as the 

507 implementation and governance of a central Certificate Authority, remain. 

508

509 5.2 Consumer IoT

510 The consumer IoT includes all IoT applications for consumer products. In the residence, 

511 connected objects might include: thermostats, alarm systems, smoke detectors, doorbells, smart 

512 appliances (e.g., washers, dryers, refrigerators, ovens, televisions), door locks, door openers, and 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

11

513 smart lightbulbs. Wearables for consumer use, such as smart wristwear and smart fabrics, as well 

514 as implants, for applications such as consumer health or identification, are also part of the 

515 consumer IoT. Smart phones are often serving as the human user interface for these components, 

516 as are smart home assistants. 

517

518 Home assistants are increasingly common. They can provide information, perform tasks, and 

519 control other IoT components. Home assistants often use conversational interfaces, but can also 

520 use text and images as input. These voice enabled user interface devices can be placed 

521 throughout a house. The ability to control these home assistants is included with every major 

522 smartphone operating system available today. The smart home assistant may connect and control 

523 some or all of the IoT components in the home.

524

525 Smart appliances can provide sensing and actuating capabilities, as well as a network interface. 

526 Examples include sous vide machines that can be remotely programmed and monitored, and 

527 refrigerators that alert the occupants when the milk is running low or the steak is going bad. A 

528 smart home security system may alert the home occupant to a burglary, high carbon dioxide 

529 levels, or a fire event, even if the occupant is not within the sounding alarm’s range (likely done 

530 through text, email, or dedicated app). Smart homes may include systems for fire detection, 

531 monitoring and communication for fire suppression, and alerting first responders. Chore 

532 automation is a growing trend for IoT devices in the home. This is where autonomous home 

533 appliances and devices learn about users’ behaviors and identify the best time to perform tasks 

534 autonomously. For example, a thermostat could be linked to the owner opening the garage door, 

535 adjusting the temperature to the person’s liking. A refrigerator or kitchen cabinet may 

536 communicate with the smart phone to inform the owner of items that need to be purchased at the 

537 grocery store. 

538

539 While the idea of converting a home’s control over to smart devices could be attractive, 

540 consumers may be hesitant to embrace IoT-based systems if they feel that their privacy and data 

541 are at risk. The proper implementation of security within consumer IoT software, firmware, and 

542 hardware is often a neglected and overlooked priority. Securing IoT devices is a major challenge, 

543 and manufacturers tend to focus on functionality, compatibility requirements, and time-to-market 

544 rather than security. The adoption of consumer IoT devices is expected to explode in the near 

545 future. However, the increased popularity and acceptance by the consumer must be weighed 

546 against the security risks inherent to every device attached to a network.

547
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

12

548

549 Figure 5 – Home Lighting Application

550 Consumers may not be aware of the far-reaching security vulnerabilities introduced by 

551 something as innocuous as connecting a smart LED bulb to the home network. A representative 

552 diagram for connecting a smart LED bulb to a home network is shown in Figure 5, above. 

553 Connecting a smart LED bulb illustrates typical network connectivity for a consumer IoT device. 

554 The smart LED bulb allows the homeowner, via either a smartphone or remote control device, to 

555 turn the bulb on or off as well as schedule its activation and deactivation. The homeowner can 

556 access web services to store configurations of color, illumination intensity, and 

557 activation/deactivation schedules. These web-stored configurations can be used to seamlessly 

558 restore operation after a power outage. 

559 If a consumer IoT device becomes compromised, it can be a gateway into the broader network. 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

13

560 IoT threats could spread through networks and the Internet. By infecting a device and infiltrating 

561 one network, the threat can spread to an entirely separate network just by being in wireless range 

of another IoT device. In the particular case of a smart LED bulb, hackers in Wi-FiTM 562 range can 

learn Wi-FiTM 563 credentials sent in plain text and gain access to other systems and devices on the 

564 network and Internet. Possible attacks can range from spoofing connections to enabling 

565 malicious command and control of an IoT device by planting backdoors to create and launch an 

566 IoT distributed denial-of-service (DDoS) attack. 

567 Consumers can gain many benefits from IoT devices, but it is misguided to implicitly trust these 

568 devices because they are connected to the home network. Securing IoT devices so that consumer 

569 privacy and data remains protected is a continuing challenge. 

570

571 5.3 Health IoT and Medical Devices

572 IoT has recently gained traction by its spread from manufacturing to the electrical grid and other 

573 new sectors such as healthcare [15]. In the healthcare sector, health IoT gathers, transmits and 

574 analyzes data derived from sources such as electronic health records (EHR) containing 

575 personally identifiable information (PII), personal health records (PHR), patient generated health 

576 data, and other machine-generated healthcare data. Health IoT will support services like such as 

577 real-time monitoring, medication compliance, and imaging.

578

579 Characteristics of the Health IoT Environment

580

581 Health IoT is characterized by its objects, information resources, people, systems, and intelligent 

582 services. Table 1 illustrates some of the principal characteristics of the healthcare domain.

583
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

14

584 Table 1 – Characteristics of the Health IoT Environment

Objects Information 

Resources

Systems Intelligent Computing Services

• Home 

telehealth

• Medical 

devices

• Health 

and 

wellness 

products

• HL7 Fast 

Healthcare 

Interoperabilit

y Resource 

(FHIR)

• Structural and 

semantic 

standards 

(vocabularies, 

code and value 

sets)

• Actuators that 

receive 

commands

• Personally 

worn 

physiological 

sensors

• Operations

• Payment

• Research (system 

of systems)

• Personal health 

records

• Treatment

o Electronic 

health records

o Monitoring

o Treatment

• Learning Health System

o Big data

o High performance 

computing

o Knowledge access

o Natural language 

processing

o Transformation

o Longitudinal monitoring 

of patients progress

o Adverse event monitoring

o Translation

People

• Patients

o Patient 

representatives

o Relatives

o Health 

conscious 

individuals

• Licensed Healthcare Providers:

o Audiologists, 

o Dentists

o Dietitians

o Optometrists

o Physicians

o Nurses

o Technicians/ Technologists

o Therapists

 Non-Licensed Healthcare 

Providers:

o Administrative personnel 

o Aides

o Emergency services

o Interpreters

 Transport personnel

 Insurance payers

585

586 Use Cases

587 Wireless telecommunications companies have developed smart sensors that support wearable 

588 and implantable, injectable, and ingestible medical devices used in the healthcare industry, and 

589 vendors have incorporated them into products such as insulin pumps, cochlear implants, and 

590 pacemakers. Health IoT components talk to the Internet via a smart interactive interface 

591 connected to the device’s firmware [16]. The following use cases are representative of services 

592 that can be provided by the emerging health Internet of Things.

593
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

15

594

595 Figure 6 – Precision Medicine Research Case

596 Precision Medicine (See Figure 6)

597 Precision Medicine and the Internet of things is driving market growth in healthcare [17]. 

598 According to the National Institutes of Health (NIH), precision medicine is "an emerging 

599 approach for disease treatment and prevention that takes into account individual variability in 

600 genes, environment, and lifestyle for each person [18]."

601

602 Alice is a disabled veteran who has been determined to have Hepatitis C [HCV] brought on by 

603 drug use related to combat induced stress. As normal treatments have failed, the VA wants her to 

604 participate in a large-scale hepatitis research program involving clinical trials of DNA matched 

605 treatments in an environment containing data from hundreds of thousands of other patients.

606 Emerging standards for information sharing, such as Health Level 7’s (HL7) Fast Healthcare 

607 Interoperability Resource (FHIR), provide Internet addressable information flow. Sequenced 

608 DNA from participant blood samples will be analyzed for efficacy of alternative Hepatitis 

609 treatments. Alice consents to participate in the clinical trial. She receives medicine reminders via 

610 cellphone or via an IoT enabled pillbox offering a wireless link to the patient, doctor, family 

611 members, and monitoring center. The pillbox helps to ensure Alice complies with the strict 

612 medication regimen times and sequences that are essential for the trial. 

613

614 Diabetes Treatment (See Figure 7)

615 Alice has decided to travel outside of the United States but is diabetic and wants to monitor her 

616 blood glucose levels and receive updates on her condition from her primary care provider. 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

16

617

618

619 Alice has a wireless-enabled wearable 

620 glucose monitor and injection device. 

621 Advanced diabetes treatments being 

622 evaluated will be able to publish her blood 

623 sugar data for receipt by subscribing 

624 clinicians and intelligent computing 

625 technologies. Her clinicians, with 

626 assistance from intelligent computing 

627 technologies, will proactively evaluate and 

628 personalize her treatment, sending

629 predictive alerts for hypoglycemia and 

630 insulin dosage updates.

631

632

633

634 Figure 7 – Diabetes Treatment/Allergen Identification

635 Nutrition control

636 While still on travel Alice needs assistance on the nutrition aspects of the local food. She 

637 downloads an App which can recognize the typical ingredients of many menu choices available 

638 to her and when presented at table can estimate the calorific and nutritional values from the 

639 photo image of her plate. This allows her to make more appropriate choices later in the day when 

640 she has her next meal. The App annotates what she consumes into her diabetes management app 

641 for the physician to monitor and study later. 

642 The physician can see in near real-time how the consumed food selected affects the existing 

643 insulin response model algorithm stability and can suggest any necessary behavior changes by 

644 email.

645

646 5.4 Smart Buildings

647 The following GSA Smart Building Use Case is illustrative of the requirements for smart 

648 buildings in general.

649 The GSA Headquarters Building located at 1800 F Street NW, Washington, D.C., includes over 

650 750,000 square feet of space, two-thirds of which has been modernized, and incorporates a 

651 variety of smart building technologies to help its occupants work comfortably, while improving 

652 energy efficiency and achieving various sustainability goals as mandated by the government. The 

653 various technology components, as implemented, form an integrated automated environment (see

654 Table 2), that help building and facilities managers achieve their goals of occupant satisfaction, 

655 energy use intensity, maintenance costs, water usage, and CO2 emissions.

Notify Patient of 

Food Allergents

Notify patient of 

Alerts

Allergy APP

Diabetes 

App

Mobile Device

Blood Sugar levels 

from Glucose 

Monitor 

Food Images from 

Camera
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

17

656 Table 2 – IoT Components for Intelligent Buildings

IoT Components for Intelligent Buildings

Infrastructure People Combined Systems

• Plumbing

• Windows

• Building wrap

• Solar panels

• Back-up power

• HVAC

• Waste control

• Parking facilities

• Elevators

• Communication facilities

• Rooms

• Tenants provide feedback 

on lighting and temp 

conditions via mobile app

• Property managers share 

practices/know-how

• Managers

• Security guards

• Maintenance/custodial 

crews

 Energy usage 

monitoring system

 Hoteling book-it 

system

 Card access and 

security system

 Weather station

 Occupant interface 

dashboard

 Lighting control system

 Universal control and 

monitoring system

Sensing Actuating Computing

• CCTV

• IP video

• Air quality 

• Water flow

• Air temp

• Humidity

• Light

• Door 

• Smoke/fire

• Door access

• Elevator

• Heater/AC

• Fire alarms

• Irrigation system

• Window blinds 

Processors/data stores

• Databases

• Servers

• Cloud services

• Edge devices

Network

• Ethernet

• Fiber optics

• Wi-FiTM

• Low power networks

• Cellular

657

658 Scenario (illustrated in Figure 8): Before GSA staff begin arriving Tuesday morning, a Universal 

659 Control system reviews its business rules and informs the HVAC system controller that a 20% 

660 higher occupancy rate is expected. The system also checks the Hoteling Book-It system to 

661 estimate power and ventilation demands of all pre-scheduled meetings. The HVAC system 

662 initiates its cooling routines to compensate for the increased demand. As GSA staff and guests 

663 arrive, the Card Access & Security System sends data wirelessly to the Universal Control system 

664 that verifies that the rate of occupancy is within the projected arrival rate and no additional BTUs 

665 are needed. 

666
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

18

667

668

669 Figure 8 – IoT for the GSA Smart Building

670 At around 2pm, a significant cold front moves into the area. The building’s Weather Station

671 system, which is tied to the NOAA Internet Weather Service, detects the drop in the outside 

672 temperature and feeds that data to the Occupant Interface Dashboard, which controls the 

673 Window Switch Report and Shade Control system within each zone floor plan. As the outside 

674 cloud cover increases, the window shades are raised automatically and the interior lights are 

675 increased by the Lutron Lighting Control System. After a while, several users begin to complain 

676 that it is too cold. Individually, they open the building control app and submits their request to 

677 lower the temp in their area and increase the lighting. The system receives this feedback and 

678 averages the input from other users to make current adjustments, as well as record it for future 

679 adjustments.

680 By now, the meeting in GSA’s largest conference room, reserved until 3pm, has ended. The 

681 Hoteling Book-It system notifies the Universal Control system, which verifies that lack of 

682 occupants. To conserve energy, the air conditioning is placed into standby state and lights are 

683 turned off until the space is occupied again. At the end of the day, the facility manager reviews 

684 the energy consumption for the day and checks tomorrow’s meeting calendar. The dashboard 

685 alerts the manager of a large conference, with over 200 attendees, planned for tomorrow, starting 

686 with a 7am breakfast. The manager verifies that AC and ventilation will begin one hour earlier 

687 and adjusts the power metering to ensure plug loads are adequate for the A/V equipment and 

688 number of devices.

689
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

19

5.5 Smart Manufacturing5 690

691 Smart manufacturing environments will leverage enterprise-wide integration of data, technology, 

692 advanced manufacturing capabilities, and cloud and other services with new business models as 

693 shown in Figure 9. These technological developments are enabling product innovation, process 

694 efficiencies, customization, collaborative and/or distributed production, and other new modes 

695 and business models. However, strategies are still needed to comprehensively address security 

696 challenges brought about by this new industrial revolution, as these opportunities are 

697 revolutionizing attack capabilities as well. 

698

699 Figure 9 – Smart Manufacturing Environment

700 Securing smart manufacturing assets requires a comprehensive security model based on a well701 defined set of security policies. Given the human-to-machine and machine-to-machine interfaces, 

702 a robust Security Management Plan must address technology, processes, and people (Figure 10). 

703 As security of organizations could be compromised at many layers, it is important to create a 

704 single point of contact (individual or office) to coordinate security matters and report incidents. 

705 Solutions are emerging that allow unified reporting to detect any threat to the application, 

706 process, or network, providing granular visibility of traffic and alerts to deviations from baseline 

 

5 content courtesy of NDIA CFAM effort – final paper under development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

20

707 operations and facilitating attack forensics. 

708

709

710 Figure 10 – Security Management Plan

711 Currently, smart manufacturing environments are custom solutions that are complicated, 

712 expensive, and built on proprietary communications. To achieve affordable plug-and-play 

713 capabilities, next generation hardware and software technologies need to work together through 

714 common security and communication standards. Standardization would lower the cost of entry to 

715 smart manufacturing for small and medium-sized businesses. In addition, as more cloud 

716 technology and Internet connectivity is leveraged toward the Industrial Internet of Things, it 

717 becomes imperative to assure the identity of the “things” in order to have secure exchanges of 

718 information. The IT to OT (Information Technology to Operations Technology) integration issue 

719 is solvable but needs standards of secure communication to leverage the Internet as the main 

720 gateway. 

721 A distributed global manufacturing ecosystem increases the challenge of intellectual property

722 protection. Engineers and operators are no longer under one roof but in different physical 

723 locations or countries. The process of black-boxing intellectual property could be the norm, so 

724 that no single entity has total exposure to the full process intellectual property. As some vendors 

725 start to shift from providing physical parts to providing digital code that the end-user purchases 

726 to make parts themselves, new business models and rules for protecting intellectual property will 

727 also emerge out of necessity. For example, a 3D printer file may need not only to be encrypted 

728 for security, but also may require provisions to restrict the number of allowable uses.

729 Smart manufacturing includes software and sensors that allow for precise predictions of 

730 maintenance needs, material demand, overtime, and other factors, based on data captured 

731 through all points of production. However, the volume of unstructured data that could be 

732 consumed in big-data projects creates new kinds of security challenges and requires a new 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

21

733 mindset toward data-centric security measures. Big data is too new for security personnel to 

734 understand what constitutes normal behavior. Security professionals need to comprehend the 

735 analytics and automation being applied to determine how best to protect a big-data enterprise, 

736 because there is currently no practical way to fully maintain situational awareness of the data at 

737 the accelerated rates of acquisition and change. With that level of understanding, organizations 

738 and vendors working in big data will continue to evolve their tools, techniques, and best 

739 practices, which will benefit smart manufacturing security.

740 Combining the advantages of big data and mobile devices, augmented reality (AR) is being used 

741 with increasing frequency on the shop floor in a number of ways, including as a training aid, 

742 maintenance aid, and operational dashboard. While the virtual overlay of information provides 

743 many benefits, it also opens up another vulnerable interface. For example, a hacker could 

744 compromise the output of an AR system, tricking users into thinking computer-generated objects 

745 are real. AR applications require access to a variety of sensor data such as video and audio feeds 

746 and geolocation; a malicious application could leak a user’s field of view or location. AR 

747 solution vendors must address head-on the potential privacy and security risks that this 

748 technology can introduce. Some existing security controls and practices—such as encrypting 

749 wireless data transmissions—can serve to protect AR system inputs and outputs. Organizations 

750 need to have clear visions about how to overlay their existing security regimes onto the AR field.

751 A Cybersecurity Framework Manufacturing Profile, NISTIR 8183 [19], may help address some 

752 of the cybersecurity challenges associated with implementing IoT technologies in manufacturing 

753 environments. The CSF Manufacturing Profile has been developed for reducing cybersecurity 

754 risk for manufacturers in a way that is aligned with manufacturing sector goals and industry best 

755 practices. This Manufacturing “Target” Profile focuses on desired cybersecurity outcomes and 

756 can be used to identify opportunities for improving the current cybersecurity posture of a 

757 manufacturing system. This Manufacturing Profile provides a voluntary, risk-based approach for 

758 managing cybersecurity activities and reducing cyber risk to manufacturing systems. The 

759 Manufacturing Profile is meant to enhance but not replace current cybersecurity standards and 

760 industry guidelines that the manufacturer is embracing.

761
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

22

762 6 Cybersecurity Areas and IoT

763 6.1 Cryptographic Techniques

764 Cryptographic techniques are indispensable in securing IoT data and transactions. Cryptographic 

765 techniques and mechanisms and their associated standards provide: confidentiality, entity 

766 authentication, non-repudiation, key management, data integrity, trust-worthy data platforms,

767 message authentication, and digital signatures.

768

769 Implementation of cryptographic techniques provide information assurance, which is built upon 

770 the following five pillars of data security:

771  Authentication: Verifying the identity of a user, process, or device, often as a prerequisite 

772 to allowing access to resources in an information system;

773  Availability: Ensuring timely and reliable access to and use of information;

774  Confidentiality: Preserving authorized restrictions on information access and disclosure, 

775 including means for protecting personal privacy and proprietary information;

776  Integrity: Guarding against improper information modification or destruction, and 

777 includes ensuring information non-repudiation and authenticity; and

778  Non-repudiation: Assurance that the sender of information is provided with proof of 

779 delivery and the recipient is provided with proof of the sender’s identity, so neither can 

780 later deny having processed the information.

781

782 Of these five pillars of information assurance, four (authentication, confidentiality, integrity, and 

783 non-repudiation) are provided by cryptographic techniques that include encryption, digital 

784 signatures, and message authentication codes (MACs), which are a digital signatures that use the 

785 same key to generate the MAC as to verify it. Encryption provides confidentiality to data at rest 

786 and in transmission. A digital signature provides authentication, integrity, and non-repudiation,

787 while MACs are used for integrity and data-origin authentication. 

788

789 Cryptographic techniques do not directly provide availability; on the other hand, poor 

790 implementations of cryptographic techniques can significantly decrease availability of 

791 communication networks.

792

793 Encryption

794 Cryptographic algorithm standards have been widely available for some time. For example, the 

795 Advanced Encryption Standard (AES) block cipher, included in International Organization for 

796 Standardization (ISO)/International Electrotechnical Commission (IEC) 18033-3:2010, is the 

797 preferred block cipher for Institute of Electrical and Electronics Engineers (IEEE) 802.11 to 

798 secure wireless networks, and is required to implement in version 1.2 of the Internet Engineering 

799 Task Force’s (IETF) Transport Layer Security (TLS) protocol.

800

801 Public key cryptography standards have also been widely available. The Internet Engineering 

802 Task Force has been developing public key cryptography standards for Internet applications. The 

803 IEEE 1363 working group has been publishing standards for public key cryptography including: 

804 IEEE 1363-2000, IEEE 1363a-2004, IEEE 1363.1-2008, IEEE 1362.2-2008, IEEE 1363.3-2013,

805 and IEEE 1363-2013 Cor.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

23

806 Lightweight cryptography standards are needed for emerging areas in which highly constrained 

807 devices are interconnected, typically communicating wirelessly with one another, working in 

808 concert to accomplish some task. Examples of these areas include: sensor networks, healthcare, 

809 distributed control systems, IoT, cyber-physical systems, and the smart grid. Security and 

810 privacy can be very important in these areas. Because most modern cryptographic algorithms 

811 were designed for desktop/server environments, many of these algorithms cannot be 

812 implemented in the devices used by these applications [20] .

813

814 Approved lightweight cryptography standards include:

815  ISO/IEC 29192-1: 2012, Information technology – Security techniques – Lightweight 

816 cryptography – Part 1: General;

817  ISO/IEC 29192-2: 2012, Information technology – Security techniques – Lightweight 

818 cryptography – Part 2: Block ciphers;

819  ISO/IEC 29192-3: 2012, Information technology – Security techniques – Lightweight 

820 cryptography – Part 3: Stream ciphers;

821  ISO/IEC 29192-4: 2013, Information technology – Security techniques – Lightweight 

822 cryptography – Part 4: Mechanisms using asymmetric techniques;

823  ISO/IEC 29192-4:2013/Amd.1: (2016), Information technology – Security techniques –

824 Lightweight cryptography – Part 4: Mechanisms using asymmetric techniques; and

825  ISO/IEC 29192-5:2016, Information technology – Security techniques – Lightweight 

826 cryptography – Part 5: Hash-functions 

827

828 Digital Signatures 

829 A digital signature is an electronic analogue of a written signature and provides assurance that 

830 the claimed signatory signed the information and that the information was not modified after 

831 signature generation. Digital signatures are used in in technologies including Connected Vehicle 

832 Systems and in cryptographic-enabled protocols such as IPSEC, S/MIME, and TLS. Example 

833 implementations include using digital signatures to authenticate from one machine to another, 

834 sign software/firmware to verify source and integrity, and sign PKI public key certificates. 

835 Common digital signature algorithms include:

836  RSA with Public-Key Cryptography Standards (PKCS) 1 or probabilistic signature 

837 scheme (PSS) padding schemes;

838  DSA (digital signature algorithm) (FIPS 180-4); and

839  Elliptic curve DSA (ESDSA) (FIPS 186-4).

840

841 6.2 Cyber Incident Management

842 Cyber incident management standards support information sharing processes, products, and 

843 technology implementations for cyber incident identification, handling, and remediation. Such 

844 standards enable organizations to identify when a cyber incident has occurred, to properly 

845 respond to that incident, and recover from any losses as a result of the incident. Such standards 

846 are one method to enable jurisdictions to exchange information about incidents, vulnerabilities, 

847 threats and attacks, the system(s) that were exploited, security configurations and weaknesses 

848 that could be exploited, etc.

849
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

24

850 While higher-level standards for cyber incident management are available, emerging low-level 

851 standards and implementations are under development that will facilitate the automated 

852 exchange of incident-related data such as indicators of compromise; tactics, techniques, and 

853 procedures (TTPs); threat actors; and courses of action. Existing standards include: 

854  ISO/IEC 27035:2016, Information technology – Security techniques – Information 

855 security incident management – Part 1;

856  ISO/IEC 27035-2:2016, Information technology – Security techniques – Information 

857 security incident management – Part 2;

858  ITU-T X.1056, Security incident management guidelines for telecommunications 

859 organizations;

860  Payment Card Industry (PCI) Data Security Standard (DSS) v3;

861  ISO/IEC 29147: 2014, Information technology – Security techniques – Vulnerability 

862 disclosure; 

863  ISO/IEC 30111: 2013, Information technology – Security techniques – Vulnerability 

864 handling process;

865  IETF Request for Comments (RFC) 4765, Intrusion Detection Message Exchange 

866 Format (IDMEF);

867  IETF RFC 5070, Incident Object Description Exchange Format (IODEF);

868  IETF RFC 5901, Extensions to the IODEF for Reporting Phishing;

869  IETF RFC 6545, Real-time Inter-network Defense (RID);

870  OASIS Structured Threat Information Expression (STIX) Version 2.0; and

871  OASIS Trusted Automated Exchange of Indicator Information (TAXII) Version 2.0.

872

873 IT cyber incident management procedures are relatively well understood. For industrial control 

874 systems (ICS), the procedures are not so well understood, specifically related to what critical 

875 infrastructure organizations should do in the event of a cyber incident. Shutting down a 

876 continuously operating plant has its own risks—commercial and safety—and careful 

877 consideration and consensus are required to identify scenarios and recommended courses of 

878 action.

879

880 6.3 Hardware Assurance 

881 Hardware assurance is an activity to ensure a level of confidence that microelectronics (also 

882 known as microcircuits, semiconductors, and integrated circuits, including embedded software 

883 and/or intellectual property) function as intended and are free of known vulnerabilities, either 

884 intentionally or unintentionally designed or inserted as part of the system’s hardware and/or its 

885 embedded software and/or intellectual property, throughout the life cycle.

886

887 Existing standards include:

888  ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for 

889 IT security (three parts);

890  ISO/IEC 20243:2015 Information technology – Open Trusted Technology ProviderTM 

891 Standard (O-TTPS) – Mitigating maliciously tainted and counterfeit products identifies 

892 secure engineering best practices, including secure management of the IT products, 

893 components, and their supply chains;
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

25

894  ISO/IEC 27036 Information technology – Security techniques – Information security for 

895 supplier relationships (three parts);

896  SAE International AS5553B-2016 Fraudulent/Counterfeit Electronic Parts; Avoidance, 

897 Detection, Mitigation, and Disposition Verification Criteria; and

898  SAE International AS6081-2012 Counterfeit Electronic Parts; Avoidance Protocol, 

899 Distributors.

900

901 6.4 Identity and Access Management

902 Identity and access management and related standards enable the use of secure, interoperable 

903 digital identities and attributes of entities to be used across security domains and organizational 

904 boundaries. Examples of entities include people, places, organizations, hardware devices, 

905 software applications, information artifacts, and physical items. Standards for identity and access 

906 management support identification, authentication, authorization, privilege assignment, and audit 

907 to ensure that entities have appropriate access to information, services, and assets. In addition, 

908 many identity and access management standards include privacy features to maintain anonymity, 

909 unlinkability, untraceability, ensure data minimization, and require explicit user consent when 

910 attribute information may be shared among entities.

911

912 Significant identity and access management standards are included in risk management 

913 techniques and specifications to assert identity and authentication, as well as enforce access 

914 policy on a range of platforms. Mature enterprise standards such as Lightweight Directory 

915 Access Protocol (LDAP), Security Assertion Markup Language (SAML) and the family of 

916 Public Key Infrastructure (PKI) cryptographic techniques to authenticate users and devices are 

917 widely deployed and in use in the cloud-computing key IT application. Emerging standards are 

918 being developed to abstract authentication form factors away from applications, allowing a rich 

919 set of strong credentials to be interoperable online.

920

921 Risk-based approaches to determine assurance levels required to protect online transactions, and 

922 the associated technical and procedural controls, have been adopted at the federal level and 

923 similar standards ratified within international standards organizations. However, international 

924 government identity programs are developing their own standards and guidelines rather than 

925 adopting a smaller set of existing standards. In the private sector, industry has developed profiles 

926 to meet the needs of their business model and partners, as well as their risk tolerance, but there is 

927 not agreement among organizations as to which identity assurance standard is the most holistic 

928 and therefore capable of being adopted cross-industry. 

929

930 Standards to enforce access policies, share attributes, preserve anonymity, minimize data release, 

931 and consent are still immature, difficult to deploy, and not available by a large majority of 

932 software-as-a-service providers and traditional enterprise product vendors, additionally 

933 hampering adoption.

934

935 Health information technology (health IT) [21] is standardizing authentication, consent, and 

936 authorization to medical records across patients, providers, insurers, and research entities to 

937 secure use and sharing of health information. 

938

939 With the increase of commercial and enterprise Internet-connected devices (such as IoT 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

26

940 components), standards for device identity, outside of traditional PKI, are just being researched, 

941 but the market has yet to determine what, if any that exist, will be leveraged.

942

943 PKI architecture for privacy: PKI is traditionally implemented to provide a trusted identity to 

944 either an individual or device. However, the ability to remain anonymous and to not be tracked 

945 while operating in network and RF environments is becoming more and more important. 

946

947 6.5 Information Security Management Systems (ISMS)

948 Information security management system (ISMS) standards provide a set of processes and 

949 corresponding security controls to establish a governance, risk, and compliance structure for 

950 information security for an organization, an organizational unit, or a set of processes controlled 

951 by a single organizational entity. An ISMS requires a risk-based approach to security that 

952 involves selecting specific security controls based on the desired risk posture of the organization 

953 and requires measuring effectiveness of security processes and controls. An ISMS requires a 

954 cycle of continual improvement for an organization to continue assessing security risks, 

955 assessing controls, and improving security to remain within risk tolerance levels by balancing 

956 security and risk tolerances.

957

958 The ISO/IEC 27000 series provides best practice recommendations on information security 

959 management, risks, and controls within the context of an overall information security 

960 management system. The fundamental parts of this series are broadly applicable to IT systems 

961 and applications.

962

963 Because of some distinctive attributes of cloud computing, several standards have been approved 

964 or are under development for cloud computing applications. These include:

965  ISO/IEC 27017:2105, Code of practice for information security controls based on 

966 ISO/IEC 27002 for cloud services;

967  ISO/IEC 27036-4;2016, Information technology – Information security for supplier 

968 relationships – Part 4: Guidelines for security of Cloud services;

969  ISO/IEC 27018:2014, Code of practice for protection of personally identifiable 

970 information (PII) in public clouds acting as PII processors;

971  ISO/IEC DIS 19941 Information technology – Cloud computing – Interoperability and 

972 portability; and

973  ISO/IEC FDIS 19944 Information technology – Cloud computing – Cloud services and 

974 devices: Data flow, data categories and data use.

975

976 There is a sector-specific technical report (TR) for smart grid:

 ISO/IEC TR 27019:2013 (1st 977 edition), Information security management guidelines based 

978 on ISO/IEC27002 for process control systems specific to the energy industry.

979 There is one standard for business continuity that is relevant to emergency management:

 ISO/IEC 27031:2011 (1st 980 edition), Guidelines for information and communications 

981 technology (ICT) readiness for business continuity.

982
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

27

983 The ISA/IEC 62443 series of Industrial Automation and Control Systems (IACS) standards and 

984 technical reports includes security management requirements. 

985  ISO/IEC 20243:2015 Information Technology – Open Trusted Technology ProviderTM 

986 Standard (O-TTPS) – Mitigating maliciously tainted and counterfeit products identifies 

987 secure engineering best practices, including secure management of the IT products, 

988 components, and their supply chains.

989

990 More specific standards have been and are being developed to augment existing portfolios, such 

991 as the 27000-series.

992

993 6.6 IT System Security Evaluation

994 IT system security evaluation and assurance standards are used to provide: security assessment 

995 of systems, security requirements for cryptographic modules, security tests for cryptographic 

996 modules, automated security checklists, and security metrics.

997

998 There is a growing portfolio of standards for testing and validation of cryptographic modules that 

999 are being widely applied. Approved standards include:

1000  ISO/IEC 19790:2015, Security requirements for cryptographic modules;

1001  ISO/IEC 24759:2014, Test requirements for cryptographic modules;

1002  ISO/IEC 17825:2016, Information technology – Security techniques – Testing methods 

1003 for the mitigation of non-invasive attack classes against cryptographic modules; and

1004  ISO/IEC 18367:2016, Information technology – Security techniques – Cryptographic 

1005 algorithms and security mechanisms conformance testing.

1006

1007 A technical report is also published: ISO/IEC TR 30104:2015, Physical security attacks, 

1008 mitigation techniques and security requirements.

1009

1010 Standards under development include:

1011  ISO/IEC CD 20085-1, Test tool requirements and test tool calibration methods for use in 

1012 testing noninvasive attack mitigation techniques in cryptographic modules – Part 1: Test 

1013 tools and techniques;

1014  ISO/IEC CD 20085-2, Test tool requirements and test tool calibration methods for use in 

1015 testing noninvasive attack mitigation techniques in cryptographic modules – Part 2: Test 

1016 calibration methods and apparatus;

1017  ISO/IEC DIS 19896-1, Information technology – IT Security techniques – Competence 

1018 requirements for information security testers and evaluators – Part 1: Introduction, 

1019 concepts and general requirements; and

1020  ISO/IEC CD 19896-2, Information technology – Security techniques – Competence 

1021 requirements for information security testers and evaluators – Part 2: Knowledge, skills 

1022 and effectiveness requirements for ISO/IEC 19790 testers.

1023

1024 Standards for the security assessment of systems have been revised several times. These include 

1025 the three-part standard ISO/IEC 15408, Information technology – Security techniques –

1026 Evaluation criteria for IT security.

1027
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

28

1028 In addition, certain process evaluation programs should be considered. One program for 

1029 mitigating the risk of maliciously tainted and counterfeit parts in IT products, to help assure 

1030 security and integrity in these products, is ISO/IEC 20243-2:2018 Information technology --

Open Trusted Technology ProviderTM 1031 Standard (O-TTPS) -- Mitigating maliciously tainted and 

1032 counterfeit products -- Part 2: Assessment procedures for the O-TTPS and ISO/IEC 20243-

1033 1:2018. As noted under the ISMS core area above, this standard identifies secure engineering 

1034 best practices, including secure management of the IT products, components, and their supply 

1035 chains. While it does not cover product evaluations, it does provide for process evaluation. Such 

1036 evaluations determine if a technology provider, component supplier, or distributor meets all the 

1037 process requirements in the standard throughout a product’s life-cycle (design through disposal).

1038 This would include the product development and secure engineering methods they use and the 

1039 supply chain security they provide. 

1040

1041 These above standards are broadly applicable to the evaluation of security properties of IT 

1042 products.

1043

1044 6.7 Network Security

1045 Network security standards provide security requirements and guidelines on processes and 

1046 methods for the secure management, operation and use of information, information networks, 

1047 and their inter-connections. Such standards-based technologies can help to assure the 

1048 confidentiality and integrity of data in motion, assure electronic commerce, and provide for a 

1049 robust, secure and stable network and Internet.

1050

1051 IoT networks are deployed over a multitude of protocols and physical links. Selecting the 

1052 appropriate messaging and communication protocols depends on the use case and security 

1053 requirements for each system. 

1054

1055 One characteristic of IoT is the potential for spontaneous connections (due to the networking) 

1056 without a system view. Viewed in this way the IoT could not be ‘planned’ nor secured well using 

1057 traditional approaches to security since system compositional or emergent properties would 

1058 never be seen by a risk manager. The network interfaces in these loosely coupled systems

1059 represent attack surfaces. Therefore, without a system asset definition and subsequent threat 

1060 analysis the security design is very unlikely to be useful.

1061

1062 Annex D lists the standards of the common protocols that support IoT communications and 

1063 establish the security of the underlying network connections. These protocols extend over the 

1064 Open Systems Interconnection (OSI) layers, i.e., physical, link, network, transport, and 

1065 application layers.

1066

1067 Many standards developers have developed and are developing network security standards. The 

1068 IETF developed RFC 2196 provides a general and broad overview of information security 

1069 including network security, incident response, or security policies. IETF Security Area Working 

1070 Groups include: IP Security Maintenance and Extensions, Kitten (GSS-API Next Generation), 

1071 Managed Incident Lightweight Exchange, Network Endpoint Assessment, Open Authentication, 

1072 and Transport Layer Security.

1073
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

29

1074 ISA/IEC-62443 standards series define procedures for implementing electronically secure 

1075 industrial automation and control systems.

1076

The IEEE standard, 802.11i-2004, implemented as Wi-FiTM 1077 Protected Access II (WPA2). This 

1078 amendment to IEEE 802.11 defined TKIP and CCMP, which provided more robust data 

1079 protection mechanisms than WEP affords. The current version of IEEE 802.11 is IEEE 

1080 802.11TM-2016 : IEEE Standard for Information technology – Telecommunications and 

1081 information exchange between systems Local and metropolitan area networks – Specific 

1082 requirements – Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer 

1083 (PHY) Specifications.

1084

1085 6.8 Security Automation and Continuous Monitoring (SACM)

1086 Security Automation and Continuous Monitoring (SACM) standards describe protocols and data 

1087 formats that enable the ongoing, automated collection, monitoring, verification, and maintenance 

1088 of software, system, and network security configurations, and provide greater awareness of 

1089 vulnerabilities and threats to support organizational risk management decisions. Automation 

1090 protocols also include standards for machine-readable vulnerability identification and metrics, 

1091 platform and asset identification, actionable threat information and policy triggers for actions to 

1092 respond to threats and policy violations. Automated activities would include a security operation 

1093 center (SOC) to ensure autonomous and continuing monitoring and evolution of the security 

1094 state of assets based upon prescribed events.

1095

1096 While higher level standards for security automation and continuous monitoring are available 

1097 and low-level specifications and implementations are in use, they require maturation and 

1098 shepherding through international standards developing organizations.

1099

1100 Existing standards include a large body of work under ISO/IEC, IETF, and industry-led efforts 

1101 (e.g., Cloud Security Alliance, Health Information Trust Alliance [HITRUST], North American 

1102 Electric Reliability Corporation [NERC] Critical Infrastructure Protection [CIP]) related to asset, 

1103 configuration, and vulnerability management—the underpinning of a continuous monitoring 

1104 capability. Other standards include those being developed by the IETF Security Automation and 

1105 Continuous Monitoring (SACM) Working Group.

1106

1107 As with incident management, IT security automation and monitoring is relatively well 

1108 developed. Security automation and continuous monitoring is much more difficult to implement 

1109 in ICS. Disruption of finely balanced network communications timing and the lack of in-depth 

1110 understanding of industrial communications protocols are two major limiting factors that will 

1111 need to be addressed before this security barrier is more widely used.

1112

1113 6.9 Software Assurance

1114 Software assurance standards describe requirements and guidance for significantly decreasing 

1115 the likelihood of software having vulnerabilities, either intentionally designed into the software 

1116 or accidentally inserted at any time during its life cycle, and that the software functions in the 

1117 intended manner. This includes custom software, commercial off-the-shelf software, firmware, 

1118 operating systems, utilities, databases, applications and applets for the Web, 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

30

1119 software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, 

1120 etc.

1121

1122 It is important to have in place software assurance standards that provide assurance over the full 

1123 lifecycle of software. Software assurance across the life cycle includes threat modeling, 

1124 use/misuse cases, secure design, defensive design, and secure coding expectations that can be 

1125 validated using source code and binary analysis techniques. The integrity of the code is also 

1126 considered an aspect of software assurance. ISO/IEC 19770-2:2015, Information technology –

1127 Software asset management – Part 2: Software identification tag, can be used to identify 

1128 software, measure the integrity of software distributions and installations, and to detect and 

1129 manage missing software patches for deployed software. Further work is needed to either apply 

1130 this existing standard to cloud deployments or to identify additional approaches that address 

1131 software and service deployments in cloud scenarios. Other relevant standards include:

1132  ISO/IEC 27034-1:2011 Information technology -- Security techniques – Application 

1133 security

1134  ISO/ IEC 27036-1:2014, Information technology – Security techniques – Information 

1135 security for supplier relationships (Part 1: Overview and concepts); 

1136  ISO/ IEC 27036-2:2014, Information technology – Security techniques – Information 

1137 security for supplier relationships (Part 2: Common requirements);

1138  ISO/ IEC 27036-3: 2013, Information technology – Security techniques – Information 

1139 security for supplier relationships (Part 3: Guidelines for ICT supply chain security);

1140  ISO/IEC 20243:2015 Information Technology – Open Trusted Technology ProviderTM 

1141 Standard (O-TTPS) – Mitigating maliciously tainted and counterfeit products; 

1142  SAE International AS5553, Counterfeit Electronic Parts; Avoidance, Detection, 

1143 Mitigation, and Disposition; 

1144  SAE International AS6462A - AS5553A, Fraudulent/Counterfeit Electronic Parts; 

1145 Avoidance, Detection, Mitigation, and Disposition Verification Criteria; 

1146  ISO/ IEC 27035, Information technology – Security techniques – Information security 

1147 incident management; 

1148  ISO 3011, Information technology – Security techniques – Vulnerability handling 

1149 processes; and

1150  ISO/IEC 29147:2014, Information technology – Security techniques – Vulnerability 

1151 disclosure.

1152

1153 6.10 Supply Chain Risk Management (SCRM)

1154 Supply chain risk management (SCRM) standards provide the confidence that organizations will 

1155 produce and deliver information technology products or services that perform as required and 

1156 mitigate supply chain-related risks, such as the insertion of counterfeits and malicious software, 

1157 unauthorized production, tampering, theft, and poor quality products and services. IT SCRM 

1158 standardization requirements include methodologies and processes that enable an organization’s 

1159 increased visibility into, and understanding of, how technology that they acquire and manage is 

1160 developed, integrated, and deployed, as well as the processes, procedures, and practices used to 

1161 assure the integrity, security, resilience, and quality of the products and services. IT SCRM 

1162 standardization lies at the intersection of cybersecurity and supply chain management and 

1163 provides a mix of mitigation strategies from both disciplines for a targeted approach to managing 

1164 IT supply chain risks.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

31

1165

1166 There are two high-level SCRM standards available: The Open Group standard is focused on IT 

1167 providers (not the acquirer), and the multipart standard, ISO/IEC 27036, covers information 

1168 security for supplier relationships. 

1169

1170 The Open Group standard has been approved as ISO/IEC 20243:2015 Information Technology –

1171 Open Trusted Technology ProviderTM Standard (O-TTPS) – Mitigating maliciously tainted and 

1172 counterfeit products). The requirements cover best practices for product development, secure 

1173 methodologies, and supply chain security—from design through disposal. The Open Group O1174 TTPS conformance assessment program is for providers, component suppliers, integrators, and 

1175 distributors of IT. It is not applicable to acquirers.

1176

1177 ISO/IEC 27036 has four parts:

1178  ISO/IEC 27036-1:2014 Information technology – Security techniques – Information 

1179 security for supplier relationships – Part 1: Overview and concepts;

1180  ISO/IEC 27036-2:2014 Information technology – Security techniques – Information 

1181 security for supplier relationships – Part 2: Requirements;

1182  ISO/IEC 27036-3:2013 Information technology – Security techniques – Information 

1183 security for supplier relationships – Part 3: Guidelines for information and 

1184 communication technology supply chain security; and

1185  ISO/IEC 27036-4:2016 Information technology – Security techniques – Information 

1186 security for supplier relationships – Part 4: Guidelines for security of cloud services.

1187

1188 In a couple of cases, standards developers are focused on SCRM for specific applications, such 

1189 as ISO/IEC JTC1 for cloud computing and IEC TC 65 for industrial-process measurement, 

1190 control and automation for industrial control systems (ICS). While any organization and any 

1191 application would benefit from implementing those broad-based standards immediately, there is 

1192 still a need for defining additional application specific requirements, which could be achieved 

1193 either by evolving these standards, or by developing more specific standards to supplement or 

1194 overlay these.

1195

1196 6.11 System Security Engineering

1197 System security engineering standards describe planning and design activities to meet security 

1198 specifications or requirements for the purpose of reducing system susceptibility to threats, 

1199 increasing system resilience, and enforcing organizational security policy. A comprehensive 

1200 system security engineering effort: 

1201  Includes a combination of technical and nontechnical activities; 

1202  Ensures all relevant stakeholders are included in security requirements definition 

1203 activities; 

1204  Ensures that security requirements are planned, designed, and implemented into a system 

1205 during all phases of its lifecycle; 

1206  Assesses and understands susceptibility to threats in the projected or actual environment 

1207 of operation; 

1208  Identifies and assesses vulnerabilities in the system and its environment of operation;
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

32

1209  Identifies, specifies, designs, and develops protective measures to address system 

1210 vulnerabilities;

1211  Evaluates/assesses protective measures to ascertain their suitability, effectiveness, and 

1212 degree to which they can be expected to reduce mission/business risk; 

1213  Provides assurance evidence to substantiate the trustworthiness of protective measures; 

1214  Identifies, quantifies, and evaluates the costs and benefits of protective measures to 

1215 inform engineering trade-off and risk response decisions; and 

1216  Leverages multiple security focus areas to ensure that protective measures are 

1217 appropriate, effective in combination, and interact properly with other system 

1218 capabilities.

1219

1220 Relevant international standards include:

1221  The ISA/IEC-62443 standards series define procedures for implementing electronically 

1222 secure industrial automation and control systems (IACS);

1223  ISO/IEC 15026-2:2011, Systems and software engineering – Systems and software 

1224 assurance – Part 2: Assurance case 

1225 ISO/IEC 15026-4:2012, Systems and software engineering – Systems and software 

1226 assurance – Part 4: Assurance in the life cycle; 

1227  NDIA SA Guide Book/NATO AEP-67, Engineering for System Assurance in NATO 

1228 Programs; and

1229  ISO/IEC 20243:2015 Information Technology – Open Trusted Technology ProviderTM 

1230 Standard (O-TTPS) – Mitigating maliciously tainted and counterfeit products.

1231
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

33

1232 7 IoT Cybersecurity Objectives, Risks, and Threats

1233 7.1 Overview 

1234 Trustworthiness is the degree of confidence one has that the system performs as expected with 

1235 characteristics including safety, security, privacy, reliability and resilience in the face of 

1236 environmental disruptions, human errors, system faults and attacks [22].” Cybersecurity is 

1237 defined as the prevention of damage to, unauthorized use of, exploitation of, and—if needed—

1238 the restoration of electronic information and communications systems, and the information they 

1239 contain, in order to strengthen the confidentiality, integrity and availability of these systems [23].

1240 Trustworthiness of IoT systems will require active management of risks for privacy, safety, 

1241 security, etc. Cybersecurity risk management for IoT systems will continue to be a major factor 

1242 in the trustworthiness of IoT applications.

1243

1244 Cybersecurity Objectives

1245 Confidentiality: Preserving authorized restrictions on information access and disclosure, 

1246 including means for protecting personal privacy and proprietary information;

1247 Integrity: Guarding against improper information modification or destruction, and includes 

1248 ensuring information non-repudiation and authenticity; and

1249 Availability: Ensuring timely and reliable access to and use of information.

1250

1251 Given how the pace of IT innovation is magnitudes faster than the pace of development of 

1252 supporting standards, it is critical to be forward thinking about cybersecurity needs in the future 

1253 operational environment. Physical implications are already a reality of cyber-attacks on one or 

1254 more IoT components. Traditional IT security focuses on confidentiality, integrity, and availably.

1255 Due to the nature of many IoT components, which interact with the physical world through 

1256 sensors and actuators, IoT security also addresses threats to people, their objects, and their 

1257 environment.

1258

1259 IoT components have the capability to connect to the Internet, being Internet Protocol (IP) based, 

1260 but may also be deployed in stand-alone IP networks that are not connected to the Internet. In 

1261 addition, IoT includes the facilities that allow users and organizations to analyze and understand 

1262 the data gathered and actions taken by the things. 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

34

1263

1264 Figure 11 – Beecham Research IoT Security Threat Map [24]

1265 Inexpensive, pervasive, highly capable edge devices create a new attack surface

1266

1267 According to the DoD CIO: “IoT brings together primary characteristics of traditional Internet 

1268 and mobile capabilities and those of industrial control systems. The major difference between 

1269 IoT and previous Internet and mobile capabilities is the control and sensing capabilities of 

1270 Things. The major differences between IoT and previous industrial control system capabilities 

1271 are the connectivity of Things to the Internet and their wider scope of application. Still, IoT and 

1272 industrial control systems do share three quality dimensions of systems: Integrity, Availability, 

1273 and Confidentiality. While traditional information systems generally prioritize Confidentiality, 

1274 then Integrity, and lastly Availability, control systems and IoT usually prioritize Availability 

1275 first, then Integrity and lastly Confidentiality. This does not mean that focus should be 

1276 exclusively on Availability. We need to ensure that we maintain sufficient focus on Integrity and 

1277 Confidentiality to address safety, privacy, and mission requirements [25].” Medical devices 

1278 prioritize integrity over the others since it relates most strongly to patient safety.

1279

1280 With the changing threat environment, the cybersecurity needs of the future—including the data 

1281 that informs, reports, and controls functionality of the IoT—should be considered. Although not 

1282 specific to IT security, privacy, safety, authentication, and resilience provide contributions to IT 

1283 and cybersecurity. Evolutions in system security engineering approaches can aid in the reduction 

1284 of susceptibility of systems to a variety of simple, complex, and hybrid threats including physical 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

35

1285 and cyber-attacks, structural failures, natural disasters, and errors of omission and commission.

1286 One ongoing challenge is to reduce the susceptibility of systems to a variety of simple, complex, 

1287 and hybrid threats including physical and cyber-attacks, structural failures, natural disasters, and 

1288 errors of omission and commission. This reduction is accomplished by fundamentally 

1289 understanding stakeholder protection needs and subsequently employing sound security design 

1290 principles and concepts throughout the system life cycle processes.

1291

1292 The specific security objectives for industrial control systems in NIST SP 800-82 [26] can be 

1293 adapted for IoT systems in general as follows: 

1294  Restricting logical access to the network and network activity. This may include 

1295 using unidirectional gateways, a demilitarized zone network architecture with firewalls to 

1296 prevent network traffic from passing directly between the corporate and IoT networks, 

1297 and having separate authentication mechanisms and credentials for users of the corporate 

1298 and IoT networks. An IoT system should also use a network topology that has multiple 

1299 layers, with the most critical communications occurring in the most secure and reliable 

1300 layer. 

1301  Restricting physical access to IoT network and components. Unauthorized physical 

1302 access to components could cause serious disruption of IoT system’s functionality. A 

1303 combination of physical access controls should be used, such as locks, card readers, 

1304 and/or guards. 

1305  Protecting individual IoT components from exploitation. This includes deploying 

1306 security patches in as expeditious a manner as possible, after testing them under field 

1307 conditions; disabling all unused ports and services and assuring that they remain disabled; 

1308 restricting IoT user privileges to only those that are required for each person’s role; 

1309 tracking and monitoring audit trails; and using security controls such as antivirus 

1310 software and file integrity checking software where technically feasible to prevent, deter, 

1311 detect, and mitigate malware. 

1312  Preventing unauthorized modification of data. This includes data that is in transit (at 

1313 least across the network boundaries) and at rest. 

1314  Detecting security events and incidents. Detecting security events, which have not yet 

1315 escalated into incidents, can help defenders break the attack chain before attackers attain 

1316 their objectives. This includes the capability to detect failed IoT components, unavailable 

1317 services, and exhausted resources that are important to provide proper and safe 

1318 functioning of an IoT system. 

1319  Maintaining functionality during adverse conditions. This involves designing IoT 

1320 system so that each critical component has a redundant counterpart. Additionally, if a 

1321 component fails, it should fail in a manner that does not generate unnecessary traffic on 

1322 IoT or other networks, or does not cause another problem elsewhere, such as a cascading 

1323 event. IoT system should also allow for graceful degradation such as moving from 

1324 “normal operation” with full automation to “emergency operation” with operators more 

1325 involved and less automation to “manual operation” with no automation.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

36

1326  Restoring the system after an incident. Incidents are inevitable and an incident 

1327 response plan is essential. A major characteristic of a good security program is how 

1328 quickly IoT system can be recovered after an incident has occurred. 

1329 Risks

1330 For the purposes of this Report, risk is a measure of the extent to which an entity is threatened by 

1331 a potential circumstance or event, and is typically a function of: (i) the adverse impacts (both 

1332 inherent and residual) that would arise if the circumstance or event occurs; and (ii) the likelihood 

1333 of occurrence. For example, information security risks are those risks that arise from the loss of 

1334 confidentiality, integrity, or availability of information or information systems and reflect the 

1335 potential adverse impacts to organizational operations (i.e., mission, functions, image, or 

1336 reputation), organizational assets, individuals, other organizations, and the Nation. Risk 

1337 assessment is the process of identifying, estimating, and prioritizing risks. Assessing risk 

1338 requires the careful analysis of threat and vulnerability information to determine the extent to 

1339 which circumstances or events could adversely impact an organization and the likelihood that 

1340 such circumstances or events will occur [27].

1341

1342 The proliferation and increased ubiquity of IoT components are likely to heighten the risks they 

1343 present; particularly as cyber criminals work to develop new generations of malware dedicated to 

1344 exploiting them. For instance, Dyn, a company that monitors and routes Internet traffic, was a 

1345 victim of a DDoS attack in October 2016 that was launched from thousands of IoT components

1346 infected with the “Mirai” malware. The torrent of traffic unleashed by the Mirai-infected IoT 

1347 components overwhelmed Dyn’s systems and, in turn, rendered unavailable many high-traffic 

1348 websites (e.g., PayPal, Twitter, Netflix, and CNN) that used Dyn’s Internet services for 

1349 substantial periods of the day. The disruption of Dyn and associated Internet services 

1350 underscores the significant, systemic harm that may be caused by malware dedicated to 

1351 exploiting the security vulnerabilities of IoT components.

1352

1353 As the market for IoT components expands, it is critical that manufacturers design components

1354 with security in mind and system designers pay attention to new attack surfaces revealed with 

1355 unforeseen emergent properties of these systems.

1356

1357 Overall, there is a multiplicity of risks associated with IoT. To minimize impact, these risks 

1358 should not be assessed and monitored in a vacuum, but take into consideration the broader 

1359 perspective of risk to ensure all aspects of threat and vulnerability are addressed.

1360

1361 Threats 

1362 A threat is any circumstance or event with the potential to adversely impact organizational 

1363 operations (including mission, functions, image, or reputation), organizational assets, 

1364 individuals, other organizations, or the Nation through an information system via unauthorized 

1365 access, destruction, disclosure, or modification of information, and/or denial of service [28].

1366

1367 Threats exist both to and from the Internet of Things. Data storage and communication must be 

1368 protected as the increasing quantity of components will bring an increasing amount of data 

1369 requiring protection. Threats to people, their property, and their interactions with society are 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

37

1370 becoming more abundant as a result of the growing attack surface. 

1371

1372 NIST SP 800-30 Revision 1 provides an extensive list of threats [29]. Categories of adversarial 

1373 threats include:

1374  Perform reconnaissance and gather information;

1375  Craft or create attack tools;

1376  Deliver/insert/install malicious capabilities;

1377  Exploit and compromise;

1378  Conduct an attack (i.e., direct/coordinate attack tools or activities);

1379  Achieve results (i.e., cause adverse impacts, obtain information); and

1380  Maintain a presence or set of capabilities.

1381 Other types of non-adversarial threats include mistakes by authorized privileged users and severe 

1382 natural events such as earthquakes, floods, hurricanes, and tornados.

1383

1384 7.2 Connected Vehicles

1385 Cybersecurity Objectives

Confidentiality V2V, V2I, and V2X communications require secure cryptographic 

authentication.

Integrity The contents of messages (e.g., BSM) require protection from 

modification of the authentic information.

Availability The real-time nature of V2V, V2I, and V2X communications require 

resilient and secure networks.

1386

1387 Vehicle manufacturers have already been focused on driver and passenger safety. Greater 

1388 emphasis may be required due to the increased attack surface from V2V, V2I, and V2X 

1389 communications. Beyond physical safety, there are privacy concerns. Users may connect and 

1390 have access to their vehicles through their smartphones, thus personal information on these 

1391 components need to be protected from unauthorized access through the vehicle. Similarly, the 

1392 vehicle must be protected from threats that may come through the mobile device. 

1393

1394 Risks

1395 Connected vehicles face many of the same risks as other IoT systems and cyber systems in 

1396 general. Severe safety consequences to vehicles and people require risk assessments to be 

1397 developed. Potential safety-critical risks include [30]:

1398  Driver distractions (volume, wipers, etc.) ;

1399  Engine shutoff or degradation; and

1400  Steering changes (in drive-by-wire vehicles).

1401

1402 There are other, less safety-critical risks, some of which are fairly unique to vehicles:
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

38

1403  Theft of the car or its contents;

1404  Enabling physical crimes against the occupants;

1405  Insurance or lease fraud;

1406  Eavesdropping on the occupants;

1407  Theft of information (e.g., phone list);

1408  Vector for attacking mobile devices in the car;

1409  Theft of personally identifiable information (PII); and

1410  Tracking the vehicle’s location.

1411

1412 Threats

1413 The addition of Internet connectivity to infotainment consoles has already introduced threats to 

1414 driver and passenger safety as a result of intercommunications between vehicle controls and 

1415 entertainment. Vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to1416 everything (V2X) communications introduce new attack vectors. The addition of these 

1417 communication channels brings an increased threat of spoofed, manipulated, damaged, and 

1418 missing sensors and actuators, which could cause vehicles to behave unpredictably.

1419 Appropriate security measures must be taken within each subsystem as well as any 

1420 communications or interactions between them. Protections must be made against user error, 

1421 device malfunction, and device damage in addition to deliberate attacks by malicious actors (e.g., 

1422 disgruntled employees, agents of industrial espionage, and terrorists).

1423 Additional threats:

1424  Increased complexity of these dynamic networks may introduce vulnerabilities and 

1425 increase exposure to potential attackers and unintentional errors.

1426  Set-and-forget sensors will provide ample opportunities for capture and compromise 

1427 attacks to cause unexpected and unsafe behavior of vehicles.

1428  Threats to sensors and actuators risk harm to passengers and passersby in addition to 

1429 damage to vehicles and objects on and along the road.

1430  Location of the vehicle could be exposed through vulnerabilities in the vehicles 

1431 information system as well as those in mobile devices that may be used to interface.

1432  The heavy push towards automated, or “self-driving,” vehicles must also be a heavy push 

1433 towards fault-tolerances and fail-safes to adapt to the dynamic networks.

1434

1435 The Tampa Hillsborough Expressway Authority (THEA) CV Pilot Team [31] has assembled the 

1436 following lists of V2X threats:

1437

1438  An attacker learns restricted information on the device/system, such as private keys, 

1439 certificates, etc., using a non- invasive attack such as a side channel attack and/or 

1440 cryptanalysis of algorithms and signed messages.

1441  An attacker learns restricted information on the device/system, such as private keys, 

1442 certificates, etc., using an invasive software attack such as malware (available on Internet 

1443 for example) that exploits vulnerabilities in algorithms and software.

1444  An attacker learns physically protected restricted information on the device, such as 

1445 private keys, using a physical attack.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

39

1446  An attacker replays a BSM or other system message at a different (than original) time 

1447 and/or location.

1448  An attacker modifies the sensor inputs on a single device before the device uses them to 

1449 generate and send a BSM or other system message.

1450  An attacker modifies the sensor inputs to multiple devices before the device uses them to 

1451 generate and send a BSM or other system message (for example, by GPS spoofing).

1452  An attacker is able to use restricted information on the device/system to create a false 

1453 BSM or other system message without actually extracting the information from the 

1454 device/system (e.g., use private key to sign a message without completing one of the 

1455 T.Extract attacks).

1456  An attacker who knows about the misbehavior detection algorithms (and associated 

1457 parameters) manipulates the content of the BSM to evade detection.

1458  An attacker who has been reported sending invalid messages denies that those messages 

1459 came from the attacker’s device, thwarting the misbehavior detection process.

1460  An attacker who knows about the misbehavior detection algorithms (and associated 

1461 parameters) manipulates misbehavior reports to implicate innocent devices/systems and 

1462 evade detection.

1463  An attacker uses the change pattern(s) of certificates and other BSM-relevant information 

1464 to track a vehicle or other device.

1465  An attacker uses BSM data to track a vehicle/device.

1466  An attacker installs malware on a device/system that prevents receiving, or making use 

1467 of, or providing user interaction based on BSMs or other system messages.

1468  An attacker uses the device as an attack vector on the rest of the vehicle/system.

1469  An attacker transmits noise and energy on the same frequency as the DSRC safety 

1470 channel.

1471  An attacker transmits messages to jam or distract. These messages may contain incorrect 

1472 info but are validly signed or may appear valid but have a bad cert or signature.

1473

1474 7.3 Consumer IoT 

1475 Cybersecurity Objectives

1476

Confidentiality Consumer IoT systems require preserving authorized restrictions on 

access and disclosure to consumer data and services.

Integrity Consumer IoT systems require the protection of data integrity and the 

operation of other electronic components on the network.

Availability Consumer IoT systems require continuity of operations for consumer 

IoT components that are connected to the physical world.

1477

1478 The main cybersecurity objectives for Internet-connected consumer electronic components are 

1479 confidentiality, integrity, availability of consumer data and services. These objectives can 

1480 intersect with consumer safety and privacy. The cybersecurity of an Internet-connected consumer 

1481 device is also important to depriving hackers of a conduit through which they may compromise 

1482 the data integrity and operation of other electronic components on the same network. In addition, 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

40

1483 the burgeoning popularity of connected consumer components also makes them ripe targets for 

1484 criminals who seek to execute coordinated, widespread cyber attacks that cause significant, 

1485 systemic harm across the Internet. To achieve these security objectives, consumer components 

1486 should use strong and readily updatable firmware and robust authentication practices, such as 

1487 strong password requirements. In some instances, using encryption or a virtual private network 

1488 (VPN) connection to your local network may protect against unauthorized eavesdropping and 

1489 protect the login credentials of your IoT consumer components.

1490

1491 Risks

1492 Consumer IoT components are challenged by many of the same cybersecurity risks as 

1493 computers, smartphones, and other categories of IoT components. For instance, to attack IoT 

1494 components, cyber criminals often probe the components for security vulnerabilities and then 

1495 install malicious software (“malware”) to surreptitiously control the device, damage the device, 

1496 gain unauthorized access to the data on the device, and/or otherwise affect the device’s operation 

1497 without permission. The risks posed by malware-infected IoT components, however, may be 

1498 more pronounced because their low costs and energy constraints often constrain the resources 

1499 that are invested in their cybersecurity and, therefore, make them ripe targets for hackers intent 

1500 on causing widespread harm. Indeed, given their growing volume, consumer IoT components are 

1501 increasingly targeted as a means for penetrating other electronic components on the same 

1502 network, or assembling an army of machines capable of transmitting Internet traffic without the 

1503 device owners’ knowledge as part of a DDoS attack.

1504

1505 Additional risks created by consumer IoT components include:

1506  Risks to physical safety by small consumer IoT components that are connected to the 

1507 physical world and may be accessed or controlled remotely, such as smart ovens, stoves, 

1508 toasters, etc.;

1509  Risks to property that may be caused by interrupting the operation of certain consumer 

1510 IoT components that are connected to the physical world, such as refrigerators, 

1511 thermostats, or washing machines; 

1512  Risks to privacy that may be caused by accessing and remotely controlling components 

1513 that are capable of collecting information about their surroundings, such as digital web 

1514 cameras, autonomous robotic vacuum cleaners, connected toys, etc.;

1515  Risks to data security and privacy from consumer IoT components that collect a 

1516 substantial amount of personal information. While consumers stand to reap the greatest 

1517 benefits from the IoT, they will have to balance potential benefits with privacy concerns. 

1518 Consumers will have to be discerning about how they engage with that information and 

1519 with whom they share it;

1520  Risks to other components on the network by creating a variety of new interconnection 

1521 between components and drastically expanding the attack surface of consumer/home 

1522 networks;

1523  Risks to privacy by exposing login information for various consumer accounts that are 

1524 stored on consumer IoT components; and

1525  Risks of side-channel attacks that could lead to physical intrusions of consumer premises 

1526 and loss of property.

1527
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

41

1528 Threats

1529 Without adequate cybersecurity safeguards, even inexpensive, consumer IoT components with 

1530 limited functionalities may be exploited to threaten confidentiality, integrity, availability of 

1531 consumer data and services, consumer privacy and safety, and other systems on the Internet. For 

1532 instance, as detailed above, the disruption of Dyn and associated Internet services in October 

1533 2016 by a DDoS attack underscores the significant, systemic harm that insecure IoT components 

1534 may cause. Further, as connected IoT technologies progressively extend their reach to consumer 

1535 components critical to basic home functions (e.g., the connected thermostat), cyber criminals 

1536 may increasingly target them in ransomware attacks or other traditional cyber attacks directed to 

1537 collecting highly-sensitive personal information. Personal privacy and safety may also be 

1538 compromised by the interruption of certain consumer IoT components (e.g., the connected oven) 

1539 or certain side-channel attacks, such as a prospective burglar monitoring communications 

1540 between and operations of components to determine the whereabouts of a homeowner.

1541

1542 7.4 Health IoT and Medical Devices

1543 Cybersecurity Objectives 

1544

Confidentiality Health IoT requires the protection of patient information from 

unauthorized disclosure and access.

Integrity Health IoT requires the protection of patient safety from unauthorized

modification of the intended use of the medical device.

Availability

Health IoT requires that patient information is available to authorized 

entities when it is needed and that the medical device’s functionality 

continues to be available when needed.

1545 The security objectives of health information technology (HIT) revolve around the 

1546 implementation of security controls that provide for the confidentiality, integrity, and availability 

1547 of patient information and for the systems supporting the use and exchange of that information. 

1548 The security objectives of medical devices are concentrated around patient safety aspects and 

1549 concentrate more on Integrity and Availability.

1550

1551 Major security objectives for this application area include the following: 

1552  Protect patient safety from network originated inauthentic commands to actuators;

1553  Protect patient sensor data from tampering to allow correct algorithmic response;

1554  Protect medical device processing capability;

1555  Protect patient data where the data forms part of a treatment and monitoring regime;

1556  Protect patient information from unauthorized disclosure or modification; 

1557  Ensure patient information is available to authorized entities when it is needed; 

1558  Ensure prompt and secure patch delivery to medical devices;

1559  Ensure continuous security risk management throughout the device lifecycle; 

1560  Explore and promote, where appropriate, existing and emerging technologies to enhance 

1561 security and confidentiality of health information; and 

1562  Educate HIT consumers on security and privacy issues related to the uses of HIT and 

1563 protected health information. 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

42

1564

1565 Risks [32]

1566 Cybersecurity threats and vulnerabilities can impact the safety of IT networks and the medical 

1567 devices and other systems connected to these networks. However, medical devices and the IT 

1568 networks they connect to are unique. In addition to data security and privacy impacts, patients 

1569 may be physically affected (i.e., illness, injury, death) by cybersecurity threats and vulnerabilities 

1570 of medical devices. This harm may stem from the performance of the device itself, impeded 

1571 hospital operations, or the inability to deliver care. As a result, addressing the patient privacy and 

1572 safety risks posed by cyber threats are of paramount importance.

1573

1574 Table 3 below provides examples of cybersecurity risks that may relate to networked medical 

1575 devices. In Table 3: C = Confidentiality, I = Integrity, A = Availability, and PS = Patient Safety. 1576

1577 Table 3 – Examples of Cybersecurity Risks to Networked Medical Devices and Connected ID Networks

Risk Description C A I PS

Failure to provide timely security software updates and patches to 

medical devices and networks and to address related 

vulnerabilities in older medical device models (legacy devices).

x x x x

Failure to place authentication between a remote command and a 

risk. x x x x

Malware which alters data on a diagnostic device. x x

Device reprogramming which alters device function 

(by unauthorized users, malware, etc.). x x x x

Denial of service attacks which make a device unavailable. x x

Exfiltration of patient data or PHI from the network. x

Unauthorized access to the healthcare network, which 

allows access to other devices. x x x x

Uncontrolled distribution of passwords, disabled passwords, hardcoded passwords for software intended for privileged device 

access (e.g., to administrative, technical, and maintenance 

personnel).

x x x x

Security vulnerabilities in off-the-shelf software due to 

poorly designed software security features. x x x x

Improper disposal of patient data or information, including 

test results or health records. x
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

43

Risk Description C A I PS

Misconfigured networks or poor network security practices. x x x x

Open, unused communication ports on a device which allow 

for unauthorized, remote firmware downloads. x x x x

1578

1579 Threats

1580 Challenges include:

1581  The economic penalty incurred by manufacturers for ongoing cyberthreat management 

1582 during the product’s lifetime;

1583  The delivery of prompt secure and authenticated firmware and software updates to 

1584 fielded systems;

1585  The incorrect deployment of a device system which does not optimally utilize the 

1586 features available in device systems;

1587  Funding shortages which permit unsupported devices to remain in service; and

1588  The unauthorized access and modification of patient identifiable information including 

1589 protected health information. 

1590

1591 7.5 Smart Buildings

1592 Cybersecurity Objectives

1593

Authentication Smart buildings require identity verification to prevent unauthorized 

access to any building control system.

Integrity Smart buildings require the protection of building control system 

information from unauthorized modification.

Availability Smart buildings require that building control system information is 

available to authorized entities when it is needed.

1594

1595 Preventing unauthorized access to any building control system is paramount to securing smart 

1596 buildings. Thus, the main objective must be to protect the interfaces to and between each system, 

1597 even when they may be overlaid on top of one another. A domino effect caused by the 

1598 compromise of one system leading to the compromise of another, cannot be allowed happen. It is 

1599 also important for fail-safes and backup systems to be in place in the event of a malfunction of 

1600 any one of the systems. Since some of these systems may be dynamic and impossible to model in 

1601 each-and-every scenario, robust modeling and testing must be done to handle foreseeable 

1602 situations. Occupant safety is also a vital objective.

1603

1604
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

44

1605 Risks 

1606 Smart buildings may contain several sets of IoT components that each have their own security 

1607 objectives, risks, and threats. The sets include infrastructure, networked, people, digital 

1608 transducers, computing resources, and combined systems. A challenge with securing smart 

1609 buildings is this heterogeneity. Interoperability between systems and components from different 

1610 vendors may introduce weaknesses for an attacker to exploit. The interfaces between these 

1611 different components may present vulnerabilities, which, once one system becomes 

1612 compromised, may be an avenue for an attacker to traverse laterally into another. The dynamic 

1613 nature of these networks presents additional difficulties. As employees and visitors move around 

1614 inside and around the building, the components they carry may be interacting with various 

1615 networks. Vulnerabilities from edge-cases may be missed since every scenario cannot be tested.

1616

1617 Threats

1618 In addition to threats arising from the many IoT systems in a smart building, additional threats 

1619 include:

1620  Smart building controlled data centers and information systems are subject to traditional 

1621 cybersecurity threats including corporate espionage;

1622  Threats to power management risk outages, surges, and inefficient operation;

1623  Threats to alarm systems could raise false alarms which may be used as distractions for 

1624 other attacks;

1625  Compromise of security systems could allow unauthorized access/entry; and

1626  An attack on automated HVAC systems could result in uncomfortable work conditions 

1627 that make it difficult to continue day-to-day operations.

1628  A physical attack could be combined with a cyber one—for instance, arson could be 

1629 combined with the cyber compromise of a sprinkler system.

1630

1631 7.6 Smart Manufacturing

1632 Cybersecurity Objectives

1633

Confidentiality Smart Manufacturing requires the protection of manufacturing 

information from unauthorized disclosure and access.

Integrity Smart Manufacturing requires the protection of manufacturing 

information from unauthorized modification.

Availability

Smart Manufacturing requires that manufacturing information is 

available to authorized entities when it is needed. This includes 

processed within milliseconds so that it is available virtually 

immediately.

1634

1635 Today’s manufacturing environment poses unique cybersecurity challenges beyond the 

1636 considerable technical complexities of cyber-physical systems. These challenges stem from 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

45

1637 fundamental differences between IT and OT. Too often, organizational stovepipes separate 

1638 engineering, management and decision-making processes for enterprise business operations and 

1639 the production environment, a problem exacerbated by the inherently change- and risk-averse 

1640 culture on the shop floor. In the past thirty years, adaptation has meant integrating advanced 

1641 technologies involving computer-based systems into the manufacturing processes. Today the line 

1642 from design to production to distribution to employment of American-manufactured goods may 

1643 begin in one part of the country (or the globe) and extend across the nation (or across continents).

1644

1645 Risks

1646 The emerging digital manufacturing environment, often referred to as Industry 4.0, is a system 

1647 built on automation, cyber-physical systems, cloud computing, and the Industrial Internet of 

1648 Things (IIoT). New technologies allow manufacturers to produce reliable products efficiently 

1649 and adapt to changing requirements from both civilian and military customers. But with this 

1650 integration and flexibility comes the potential for malicious actors to infiltrate key systems by 

1651 gaining access to manufacturing networks. When successful, these actors may extort ransom 

1652 from a company to release the system from their control, copy sensitive proprietary information 

1653 that can be sold to other companies or other governments, or install software that can affect a 

1654 product’s performance. The potential consequences for national security are compelling.

1655 Evidence already exists that state-sponsored efforts to infiltrate and steal information from 

1656 companies involved in defense manufacturing have led to the development of military equipment 

1657 remarkably like U.S. systems; it is no coincidence that several of the planes, drones, and vehicles 

1658 deployed by China and Russia bear striking resemblances to ones in the U.S. inventory. 

1659 Equally troubling is the fact that adversaries who penetrate the security systems in processes 

1660 used to produce arms and equipment for the U.S. military may have the capability to alter or halt 

1661 production processes to affect these items’ reliability, safety, or security, putting the lives of 

1662 service personnel at risk and materially degrading the ability of the nation’s fighting forces to 

1663 succeed on the battlefield.

1664

1665 Threats

1666 Managing a modern manufacturing enterprise exposes the data exchanged by designers, the 

1667 production team, and those involved in the supply chain to attacks by individuals or state actors, 

1668 intent on stealing intellectual property, damaging the United States’ competitive advantage, or 

1669 sabotaging mission-critical components. Similar to emerging cybersecurity concerns related to 

1670 the rapid expansion of the commercial IoT, as the number of factory floor device connections 

1671 grows, the cyber-attack surface expands and requires new cybersecurity protections for 

1672 confidentiality, integrity, and availability, as well as, prevention distributed denial of service 

1673 (DDoS) and other attacks that require the use of distributed devices.

1674
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

46

1675 8 Standards Landscape for IoT Cybersecurity 

1676 IoT systems include a diverse set of new applications across consumer and industrial sectors. IoT 

1677 cybersecurity considerations include but are not limited to:

1678  Some IoT systems have direct connections to owner networks, while others directly 

1679 connect to non-owner networks. Some IoT systems have direct connections to both 

1680 owner and non-owner networks.

1681  IoT systems may comprise highly distributed IoT components that have a variety of 

1682 owners or may effectively have no defined owner.

1683  Some IoT systems are intended for use by or association with a particular person or group 

1684 of people, while others are autonomous.

1685  Some IoT components are low cost, often because they use low-capability computing 

1686 hardware (minimal processing, storage, etc.) and have low power consumption.

1687  Some IoT components are largely static (e.g., software cannot be updated, configuration 

1688 cannot be changed as needed).

1689  Some IoT components process data locally, some IoT components have their data 

1690 processed remotely, and some do both.

1691  A single IoT sensor may collect massive volumes of data.

1692  IoT components are highly heterogeneous (operating systems, network 

1693 interfaces/protocols, functions, etc.)

1694  Many IoT systems rely on proprietary protocols for data communication.

1695  IoT systems are often deployed as part of highly dynamic systems and system 

1696 environments.

1697  Many IoT systems do not provide centralized management capabilities for the owner.

1698  Many IoT systems can be remotely controlled by first parties (e.g., manufacturers).

1699  Some IoT components are deployed in physically unrestricted locations. This may mean 

1700 the inability to provide physical security or a requirement for a very small form factor or 

1701 low power consumption that limits computational capacity and capability.

1702  IoT components may encounter statistical errors when sensing and acting on physical 

1703 objects.

1704  IoT systems may affect the safety, reliability, resiliency, performance, and other aspects 

1705 of an owner’s computing infrastructure and physical presence. . If a failure occurs, the 

1706 IoT system should fail in a secure manner. That is, if a failure occurs, security should still 

1707 be enforced. It is better to lose functionality than lose security.

1708  IoT systems may collect, store, and use data that the owner’s personnel are not aware of 

1709 or cannot manage.

1710  Some IoT systems have the ability to manage, update, and patch IoT components at scale.

1711  Some IoT systems support impromptu architectural changes.

1712  Some IoT systems are created through novel combinations of existing IoT systems and 

1713 data streams that are re-purposed for an application not envisioned by the original 

1714 designers. Further, such IoT systems may evolve as additional sensors or data streams 

1715 become available or accessible.

1716  Some IoT systems include IoT components designed for decades-long use, such as smart 

1717 meters in smart grid applications. 

1718

1719 Annex C — An IT Standards Maturity Model, provides a classification system for characterizing 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

47

1720 the present state of market impact of a standard or draft standard. The standards listed in Annex 

1721 D – IoT Standards Mapping to Core Areas of Cybersecurity, have been collected by the IoT Task 

1722 Group. They are the basis for the following observations on the present state of standards 

1723 availability and standards use for IoT systems.

1724

1725 8.1 Cryptographic Techniques

1726 There are many cryptographic standards. These standards are being used to protect data in transit 

1727 and at rest and to provide for strong authentication. 

1728

1729 Many of these standards can support IoT systems. For instance, many IoT components can 

1730 support the Advanced Encryption Standard (AES) block cipher, included in ISO/IEC 18033-

1731 3:2010. The AES standard has widespread market acceptance. 

1732

1733 Other standards have been developed to specifically support IoT systems. For example, the 

1734 multipart ISO/IEC 29167 standard provides cryptographic options for the air interface of RFID 

1735 components and the multipart ISO/IEC 29192 standard for lightweight cryptography provides 

1736 cryptographic options for IoT components with constrained processing capabilities. Market 

1737 acceptance for parts of these standards has not yet occurred.

1738

1739 Cryptographic techniques will need adjustments and innovations to accommodate the IoT. 

1740 Scalability, performance, memory- and power-limited devices, and constrained communication 

1741 channels all contribute to the cryptographic challenges associated with the IoT. Public-key 

1742 cryptography, ubiquitous on the Web, may appear as a natural choice since the inconvenience and 

1743 restrictions of shared secrets are eliminated. However, the computational demands of public-key 

1744 cryptography, which may not be feasible for tiny IoT devices, must be weighed against the key 

1745 management and protocol limitations that come with symmetric key cryptography. As an example,

1746 and given the immense scale envisioned for IoT applications, certificate revocation, which include 

1747 resource-hungry activities such as the processing and storage associated with certificate revocation 

1748 lists (CRLs) or the bandwidth associated with Online Certificate Status Protocol (OSCP), would 

1749 have to be compared to the manual process and vulnerability of symmetric key distribution and 

1750 update.

1751 Fortunately, existing standards and standards in development address these concerns. Elliptic 

1752 curve cryptography (ECC), defined in accepted standards such as ISO/IEC 29192-4:2013, is a 

1753 public-key approach that provides well understood levels of security with smaller keys and 

1754 signatures than, for example, RSA. ECC has also become entrenched as a "must implement" 

1755 mechanism in many Internet protocols, such as TLS (RFC 5246), DTLS (RFC 6347), and the 

1756 Internet Key Exchange for IPsec (RFC 7296). For symmetric key applications (either alone or in 

1757 conjunction with PKC), light-weight algorithms are defined in ISO/IEC 29192-2. These symmetric 

1758 ciphers are tuned for limited power devices. Key management guidance is available in publications 

1759 such as NIST Special Publication 800-57.

1760 Market Impact?

1761 The AES standard has widespread market acceptance including testing and validation of 

1762 thousands of implementations. 

1763 Some of the recently approved RFID and lightweight cryptographic standards have no 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

48

1764 commercial implementations or only one commercial implementation.

1765

1766 Possible Standards Gaps? 

1767 Blockchain is an evolving technology that could revolutionize IoT security. The blockchain model 

1768 favors peer-to-peer interactions between devices and thus de-centralizes security. Because 

1769 blockchain is still under development and its applicability to security mechanisms is still not well 

1770 understood, no standards exist for using blockchain in a regular interoperable fashion. However, 

1771 the potential is significant enough that standards development organizations should be taking note.

1772

1773 8.2 Cyber Incident Management 

1774 There are many standards for cyber incident management that cover cyber incident 

1775 identification, handling, and remediation. Many of these standards are applicable to IoT systems. 

1776 Examples include: HITRUST CSF v9 for reporting information security incidents and 

1777 weaknesses; IETF RFC 5070 – 2007 for sharing information about computer security incidents; 

1778 ISO/IEC 29147: 2014 and ISO/IEC 30111: 2013 for vulnerability disclosure and handling 

1779 process; OASIS OpenC2 (draft) for machine to machine exchange of commands to achieve 

1780 investigative, remediation and/or mitigation effects; and OpenFog RA (February 2017) for 

1781 tamper response. Some of these standards have widespread market acceptance. 

1782

1783 Market Impact? 

1784 Market implementations are lagging for IoT systems.

1785

1786 Possible Standards Gaps? 

1787 Some IoT systems are not able to use software patches to fix cybersecurity flaws. In such cases, 

1788 cyber incident management is important for identifying incidents but remediation may require 

1789 replacing IoT components. Replacement could be time consuming and expensive. An area for 

1790 new standards development could be remediation (compensating controls) when software 

1791 patches are not feasible.

1792

1793 8.3 Hardware Assurance 

1794 ISO/IEC JTC 1 has developed several standards relevant to hardware assurance such as: 

1795 ISO/IEC 27036, a multipart information security management system standard for supplier 

1796 relationships; and ISO/IEC 20243:2015, for secure engineering best practices, including secure 

1797 management of the IT products, components, and their supply chains. SAE International has over 

1798 ten approved or draft standards dealing with counterfeit electronic parts, such as AS5553B 

1799 (2016), Fraudulent/Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, and 

1800 Disposition Verification Criteria.

1801

1802 Market Impact? 

1803 Unknown

1804

1805 Possible Standards Gaps?

1806 Detecting malware in software is technically challenging. This challenge would apply to 

1807 firmware. Developing best practices for avoiding malware in firmware could be an area for new 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

49

1808 standards development.

1809

1810 8.4 Identity and Access Management

1811 There are many identity and access management standards with guidance available. Many of 

1812 these standards have been developed to specifically support IoT systems or specific IoT 

1813 applications. As in the case of the other core areas of cybersecurity, standards are being 

1814 developed by many SDOs. Examples include: the FIDO Universal Authentication Framework 

1815 (UAF) v1.1 Specifications; HITRUST CSF v9; IEEE 802.1X-2004 for port based network access 

1816 control; OCF SPEC 1.0 for access control; the IETF RFC 7925 to authenticate and to negotiate 

1817 cryptographic algorithms and keys; and the Thread Specifications for home and building IoT 

1818 applications.

1819

1820 Market Impact? 

1821 Unknown

1822

1823 Possible Standards Gaps? 

1824 Existing standards should be reviewed to determine if they are sufficient or require revision for 

1825 IoT systems.

1826

1827 8.5 Information Security Management Systems (ISMS)

1828 There are several ISMS standards with market acceptance that are generally applicable to IoT 

1829 systems or specific IoT applications. The ISA/IEC 62443 series includes security management 

1830 requirements for Industrial Automation and Control Systems (IACS). ISO 13485:2016

1831 Provides management requirements for medical devices and related services. ISO 27799:2016 

1832 covers information security management in health using ISO/IEC 27002. ISO/IEC 20243:2015 

1833 identifies secure engineering best practices, including secure management of the IT products, 

1834 components, and their supply chains. And, ISO/IEC 27002:2013 is being widely used as a 

1835 reference for selecting security controls when implementing an Information Security 

1836 Management System (ISMS). 

1837

1838 Market Impact? 

1839 Existing standards are being implemented. 

1840

1841 Possible Standards Gaps? 

1842 While there are specific management system standards for some IoT applications, there are other 

1843 IoT applications that could possibly benefit from a management system standard based upon 

1844 ISO/IEC 27002.

1845

1846 A new area of work could be to develop IoT security controls overlay where they would not only 

1847 specify the security controls, but also could stipulate specific implementation requirements for 

1848 the controls. For example, NIST SP 800-82 includes a security controls overlay for industrial 

1849 control systems; and NIST SP 800-161 includes a security controls overlay for supply chain.

1850
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

50

1851 8.6 IT System Security Evaluation 

1852 There are many IT system security evaluation standards with market acceptance that should be

1853 relevant to IoT systems. Standards for security requirements for cryptographic modules (e.g., 

1854 ISO/IEC 19790:2015) and security test requirements for cryptographic modules (e.g., ISO/IEC 

1855 24759:2014) are relevant for many types of IoT components. Other examples include: the three1856 part ISO/IEC 15408 for IT security evaluation; ISO/IEC TR 30104:2015 for guidance on 

1857 physical security attacks, mitigation techniques and security requirements; and UL 2900 for 

1858 testable cybersecurity criteria for network-connectable products and systems.

1859

1860 Market Impact? 

1861 Although standards exist, practical application to IoT systems has not been consistently 

1862 demonstrated.

1863

1864 Possible Standards Gaps?

1865 Existing standards are not specific to IoT and should be reviewed to determine if they are 

1866 sufficient or require revision for IoT systems.

1867

1868 8.7 Network Security

1869 There are many network security standards for various types of networks that are relevant to IoT 

1870 systems. Examples include: the 3GPP Long-Term Evolution (LTE) for high-speed wireless 

1871 communication for mobile phones; the Bluetooth wireless standard for exchanging data over 

1872 short distances from fixed and mobile devices, and building personal area networks; the IETF 

1873 RFC 7252 for a generic web protocol for the special requirements of the constrained 

1874 environment of machine-to-machine (M2M) applications; IEC 62591:2016 for industrial 

1875 wireless sensor networks; the IEEE 1609 family of standards for Wireless Access in Vehicular 

Environments (WAVE); IEEE 802.11-2016 for Wi-FiTM 1876 ; the OMA Lightweight Machine to 

1877 Machine Technical Specification, a device management protocol designed for sensor networks 

1878 and the demands of a machine-to-machine (M2M) environment; and the ZigBee 3.0 specification 

1879 that enables IoT components from separate IoT systems/applications to communicate.

1880

1881 Market Impact? 

1882 Many of these existing standards have widespread market acceptance with numerous commercial 

1883 implementations. However, updates and/or new standards may be needed to deal with the IoT 

1884 cybersecurity considerations listed at the beginning of Section 8.

1885

1886 Possible Standards Gaps? 

1887 Many existing standards may require updates and/or new standards will be needed to address IoT 

1888 networks that have the potential for spontaneous connections (due to the networking) without a 

1889 system view. Such IoT systems cannot be planned or secured well using traditional approaches 

1890 to security since system compositional or emergent properties would never be seen by a risk 

1891 manager.

1892

1893 IEEE 802.15.7 is a physical layer specification for visible light communication. Standards from 

1894 the viewpoint of application service function development have yet to be developed.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

51

1895

1896 8.8 Security Automation and Continuous Monitoring (SACM)

1897 There are several approved and draft SACM standards. Most are specifically relevant to IoT 

1898 systems. Approved standards include: IEC TR 62443-2-3:2015 for requirements for asset owners 

1899 and industrial automation and control system (IACS) product suppliers that have established and 

1900 are now maintaining an IACS patch management program; and the IETF RFC 7632 with use 

1901 cases for securely aggregating configuration and operational data and evaluating that data to 

1902 determine an organization's security posture. IETF Active Internet Drafts include: the Resource1903 Oriented Lightweight Information Exchange (ROLIE) Definition of the ROLIE Software 

1904 Descriptor Extension; Concise Software Identifiers; Endpoint Compliance Profile; Software 

1905 Inventory Message and Attributes (SWIMA) for PA-TNC; and Security Automation and 

1906 Continuous Monitoring (SACM) Terminology.

1907

1908 Market Impact? 

1909 The resource limitations of IoT devices (memory, processor, power) can make it difficult to 

1910 implement agent-based approaches to continuous monitoring. Device manufacturers will need to 

1911 consider price and performance as more advanced capabilities are developed. The IoT ecosystem 

1912 is heterogeneous and until standards are in place and broadly adopted, device manufacturers and 

1913 security vendors will need to make investments in developing device-specific agents and 

1914 interfaces for monitoring.

1915

1916 Possible Standards Gaps?

1917 Adoption of standard protocols, interfaces, and data models will help achieve the interoperability 

1918 needed to automate security operations.

1919

1920 8.9 Software Assurance

1921 There are many approved software assurance standards. Many are specifically relevant to IoT 

1922 systems. Examples include: IEC 82304-1:2016 for the safety and security of health software 

1923 products; ISO/IEC 20243:2015 for secure engineering best practices, including secure 

1924 management of the products, components, and their supply chains; the multi-part ISO/IEC 27036 

1925 for the information security for supplier relationships; and the UL 2900 criteria to assess 

1926 software vulnerabilities and weaknesses, minimize exploitation, address known malware, review 

1927 security controls and increase security awareness.

1928

1929 Market Impact? 

1930 Despite known impacts of insecure software, the pace of adoption is slow. 

1931

1932 Possible Standards Gaps? 

1933 The integration of best practices for software development into standards for IoT contributing 

1934 disciplines is slow.

1935

1936 Detecting malware in software is technically challenging. Developing best practices for avoiding 

1937 malware in software could be an area for new standards development.

1938
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

52

1939 8.10 Supply Chain Risk Management (SCRM)

1940 There are three approved SCRM standards. They are relevant to IoT systems or specific IoT 

1941 systems (i.e., medical IoT components). They are the multi-part ISO/IEC 27036; ISO/IEC 

1942 20243:2015; and UL 2900, which are also included above for software assurance.

1943

1944 Market Impact?

1945 The market has been slow to implement. 

1946

1947 Possible Standards Gaps?

1948 The generic standards (e.g., ISO/IEC 27036) are not specific to IoT and they need to be reviewed 

1949 to determine if they are sufficient or require revision for IoT systems.

1950

1951 8.11 System Security Engineering

1952 There are many approved or draft system security engineering standards. Some are relevant to 

1953 IoT systems or specific IoT systems (e.g., healthcare). Examples include: ISO/IEC/IEEE 

1954 15288:2015 for a set of systems engineering processes and associated terminology; the ISA/IEC 

1955 62443 series for Industrial Automation and Control Systems (IACS) that includes security 

1956 management requirements. 

1957

1958 The generic, multipart ISO/IEC 15026 for systems and software engineering assurance may be 

1959 relevant to IoT systems.

1960

1961 Market Impact? 

1962 It is unclear if system security engineers apply systems engineering practices to IoT systems.

1963

1964 Possible Standards Gaps?

1965 It is unclear if the generic system engineering standards (e.g., ISO/IEC 15026) consider IoT 

1966 systems as part of the IT system.

1967
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

53

1968 9 Status of International Cybersecurity Standards for Selected IoT 

1969 Applications

1970 Based upon the preceding information and analysis, Table 4 provides a snapshot of the present 

1971 status of cybersecurity standards development and their implementation by the marketplace.

1972  “Standards Available” indicates that SDO approved cybersecurity standards are for the 

1973 most part available. “Some Standards” indicates that some SDO approved cybersecurity 

1974 standards exist but there may be a need for additional standards and/or revisions to 

1975 existing standards in this area. “Being Developed” indicates that needed SDO approved 

1976 cybersecurity standards are still under development. “Standards Needed” indicates that 

1977 new cybersecurity standards development projects are starting to be considered by 

1978 various SDOs. 

1979  “Implemented” indicates that two or more standards-based implementations are available 

1980 for most of these SDO approved cybersecurity standards. “Slow Uptake” indicates 

1981 market implementations are lagging for many SDO approved cybersecurity standards.

1982 “Not Implemented” indicates that SDO cybersecurity standards are still under 

1983 development or new standards project will be needed before the market can implement. 

1984

1985 Where there are existing standards that are being implemented, it should be noted that these 

1986 standards require continuous maintenance and updating. This is based upon feedback from 

1987 testing and deployments of standards-based products, processes, and services, as well as 

1988 improvements in technology.

1989 Table 4 – Status of Cybersecurity Standardization for Several IoT Applications 

Core Areas of 

Cybersecurity

Standardization

Examples of 

Relevant 

SDOs

Connected 

Vehicles

Consumer

IoT

Health IoT 

& Medical 

Devices

Smart

Buildings

Smart 

Manufacturing

Cryptographic 

Techniques

ETSI; IEEE; 

ISO/IEC JTC 1; 

ISO TC 68; ISO 

TC 307; W3C

Standards

Available

Slow 

Uptake

Standards

Available

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Standards

Available

Slow 

Uptake

Some Standards

Slow 

Uptake

Cyber Incident 

Management

ETSI ; ISO/IEC 

JTC 1; 

ITU-T; PCI

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some Standards

Slow 

Uptake

Identity and Access 

Management

ETSI; FIDO 

Alliance; IETF; 

OASIS; OIDF; 

ISO/IEC JTC 1; 

ITU-T; W3C

Standards

Available

Slow 

Uptake

Standards

Available

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Standards

Available

Slow 

Uptake

Standards

Available

Slow 

Uptake
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

54

Core Areas of 

Cybersecurity

Standardization

Examples of 

Relevant 

SDOs

Connected 

Vehicles

Consumer

IoT

Health IoT 

& Medical 

Devices

Smart

Buildings

Smart 

Manufacturing

Information Security 

Management Systems

ATIS; IEC; ISA; 

ISO/IEC JTC 1; 

ISO TC 223; 

OASIS; 

The Open Group

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Some Standards

Slow 

Uptake

IT System Security 

Evaluation

ISO/IEC JTC 1; 

The Open Group; 

UL

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not

Implemented

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Hardware Assurance ISO/IEC JTC 1; 

SAE International

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Not 

Implemented

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Not 

Implemented

Some Standards 

Not 

Implemented

Network Security 3GPP; 3GPP2; 

IEC; IETF; IEEE; 

ISO/IEC JTC 1; 

ITU-T; The Open 

Group; WiMAX 

Forum

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Standards 

Needed

Not 

Implemented

Security Automation & 

Continuous Monitoring 

IEEE; IETF; 

ISO/IEC JTC 1; 

TCG; 

The Open Group

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some Standards 

Slow 

Uptake

Software Assurance IEEE; ISO/IEC 

JTC 1; OMG; 

TCG; 

The Open Group; 

UL

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some Standards 

Slow 

Uptake

Supply Chain Risk 

Management

IEEE; ISO/IEC 

JTC 1; 

IEC TC 65; 

The Open Group; 

UL

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some 

Standards 

Slow 

Uptake

Some Standards 

Slow 

Uptake

System Security 

Engineering

IEC; IEEE; ISA; 

ISO/IEC JTC 1; 

SAE International; 

The Open Group

Some 

Standards

Slow 

Uptake

Standards 

Needed

Slow 

Uptake

Some 

Standards

Slow 

Uptake

Standards 

Needed

Slow 

Uptake

Standards 

Needed

Slow 

Uptake

1990
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

55

1991 10 Conclusions

1992 This Report includes a functional description of IoT (Section 4). This provides a starting point 

1993 for the assessment of the current state of international cybersecurity standards development for 

1994 IoT. It may also serve as a basis for future understanding and communications among agencies 

1995 about IoT.

1996 Several IoT applications have been reviewed to better understand IoT cybersecurity objectives, 

1997 risks, and threats. From this review, it appears that many IoT systems, which have been 

1998 developed for diverse agency missions, share many common cybersecurity threats. Additionally, 

1999 specific IoT applications may face additional classes of threats. Risk assessments need to be 

2000 based upon an IoT application’s priorities for confidentiality, integrity, and availability of 

2001 information. 

2002 With the continuing, rapid innovation of IT, the inventory of IoT relevant cybersecurity 

2003 standards will remain dynamic. Annex D of this Report contains a listing of international 

2004 cybersecurity standards that the IoT Task Group has identified to be IoT relevant. The listing is 

2005 substantial but it is not being represented as complete. It is also a one-time, static listing. The 

2006 standards have been organized by the eleven core areas of cybersecurity described in this report 

2007 (Section 6). The substantial number of standards for some of the core cybersecurity areas are the 

2008 result of IT innovation as well as competitive solutions for various technologies. Based upon the 

2009 information in Annex D, a high-level summary has been developed of IoT relevant cybersecurity 

2010 standards including market impact and possible standards gaps (Section 8). 

2011 The identified possible standards gaps are:

2012  Cryptographic Techniques: applying blockchain technology for IoT security 

2013 mechanisms;

2014  Cyber Incident Management: best practices for remediation when software patches are 

2015 not feasible;

2016  Hardware Assurance: best practices for avoiding malware in firmware;

2017  Information Security Management Systems (ISMS): management system standards 

2018 based upon ISO/IEC 27002 for IoT applications not already covered by the 27000 series;

2019 IoT security controls overlay where they would not only specify the security controls, but 

2020 also could stipulate specific implementation requirements for the controls;

2021  Network Security: existing standards may require updates and/or new standards will be 

2022 needed to address IoT networks that have the potential for spontaneous connections (due 

2023 to the networking) without a system view; standards for application service function 

2024 development in support of IEEE 802.15.7 (a physical layer specification for visible light 

2025 communication);

2026  Software Assurance: best practices for avoiding malware in software;

2027  Software Assurance: integration of best practices for software development into 

2028 standards for IoT contributing disciplines;

2029  Security Automation & Continuous Monitoring: since the IoT ecosystem is 

2030 heterogeneous, IoT device manufacturers and security vendors may need to develop 

2031 device-specific agents and interfaces for monitoring until the standards are tailored for 

2032 the various IoT use cases and implemented in products;
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

56

2033  Supply Chain Risk Management (SCRM): generic standards (e.g., ISO/IEC 27036) are 

2034 not specific to IoT and need to be reviewed to determine if they are sufficient or require 

2035 revision for IoT systems;

2036  System Security Engineering: need to determine if generic system security engineering 

2037 standards (e.g., ISO/IEC 15026) consider IoT systems.

2038

2039 Agencies should further review these possible standards gaps with respect to their respective 

2040 missions. For identified priorities, agencies should work with industry to initiate new standards 

2041 projects in SDOs to close such gaps.

2042

2043 Based upon all of this information, Table 4 provides a summary of the Task Group’s views on 

2044 the status of cybersecurity standardization for the five IoT applications described in Sections 5 

2045 and 7. 

2046

2047 The availability and use of international cybersecurity standards are major factors for ensuring 

2048 the secure and resilient operation of the expanding number of agency mission critical IoT 

2049 systems. In accordance with USG policy, agencies should participate in the development of these 

2050 standards in many SDOs and, based upon each agency’s mission, cite appropriate standards in 

2051 agency procurements. 

2052

2053 Also, in accordance with USG policy, agencies should support the development of appropriate 

2054 conformity assessment schemes to the requirements in such standards. US industry has a rich 

2055 history of developing conformity assessment (CA) programs to meet our society’s needs. In the 

IT sector for example, the Wi-FiTM 2056 logo appearing on wireless network devices show that the 

product has been tested and certified by the Wi-FiTM 2057 Alliance, a non-profit member association, 

whose goal is to ensure that any device carrying the logo connect seamlessly to any Wi-FiTM 2058

network. Many consumers may not understand the technical details of Wi-FiTM 2059 , but they have 

2060 confidence that the logo ensures that the device will connect to their home networks. 

2061

2062 The decision on the type, independence and technical rigor of conformity assessment should be 

2063 risk-based. The need for confidence in conformity must be balanced with the cost to the public 

2064 and private sectors, including their international operations and legal obligations. Successful 

2065 conformity assessment provides the needed level of confidence, is efficient, and has a sustainable 

2066 and scalable business model.

2067
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

57

2068 Annex A—Some IoT Definitions and Descriptions

2069

2070 Internet of Things (IoT) [33]

2071 Systems underpin every facet of American society—from transportation to utilities to 

2072 communications—and are accessible and often controllable from around the world. More 

2073 devices are connected to networks, and those networks are connected to each other, a concept 

2074 known as IoT; however, there is no universal definition of IoT, just as there is no agreement in 

2075 the use of that name to describe this trend. Whether it is called IoT, the Industrial Internet, or 

2076 cyber-physical systems (CPS), the term describes a decentralized network of objects (or devices), 

2077 applications, and services that can sense, log, interpret, communicate, process, and act on a 

2078 variety of information or control devices in the physical environment. These devices range from 

2079 small sensors on consumer devices to sophisticated computers in industrial control systems 

2080 (ICS). Ultimately, the devices have some type of kinetic impact on the physical world, whether 

2081 directly or through a mechanical device to which they are connected.

2082

2083 Internet of Things (IoT) [34]

2084 an infrastructure of interconnected objects, people, systems and information resources together 

2085 with intelligent services to allow them to process information of the physical and the virtual 

2086 world and react 

2087

2088 Internet of Things (IoT) [35]

2089 It is important to understand what the Internet of Things is and what the difference is between 

2090 IoT ecosystem and an IoT system. A simple definition of an Internet of Things system is “a 

2091 system of entities (including cyber-physical devices, information resources, and people) that 

2092 exchange information and interact with the physical world by sensing, processing information, 

2093 and actuating.” An IoT ecosystem may be defined as “an infrastructure of networked objects 

2094 (cyber-physical devices, information resources, and people) that can be combined to create 

2095 systems that interact with the physical world.

2096

2097 Internet of Things (IoT) [36]

2098 In this context, the term IoT refers to the connection of systems and devices with primarily 

2099 physical purposes (e.g., sensing, heating/cooling, lighting, motor actuation, transportation) to

2100 information networks (including the Internet) via interoperable protocols, often built into 

2101 embedded systems.

2102

2103 Internet of Things (IoT) [37]

2104 This green paper will continue to use the term Internet of Things as an umbrella term to

2105 reference the technological development in which a greatly increasing number of devices are

2106 connected to one another and/or to the Internet. This acknowledges the widespread use and

2107 general popular acceptance of the term. The term itself is, as pointed out by some commenters, a 

2108 misnomer, as many of the devices included in the Internet of Things do not use Internet Protocol 

2109 or in any event may not connect directly to the Internet. At times, IoT term is more descriptive of 

2110 the system or network than an actual thing. IoT has become the commonly used term for the 

2111 technologies and related issues discussed here, and for the sake of simplicity it will be used 

2112 throughout this paper.

2113
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

58

2114 Internet of Things (IoT) [38]

2115 There is no formal, analytic, or even descriptive set of the building blocks that govern the 

2116 operation, trustworthiness, and lifecycle of IoT. A composability model and vocabulary that 

2117 defines principles common to most, if not all networks of things, is needed to address the 

2118 question: “what is the science, if any, underlying IoT?” This document offers an underlying and 

2119 foundational science to IoT based on a belief that IoT involves sensing, computing, 

2120 communication, and actuation.

2121

2122 Internet of Things (IoT) [39]

2123 A global infrastructure for the information society, enabling advanced services by 

2124 interconnecting (physical and virtual) things based on existing and evolving interoperable 

2125 information and communication technologies.

2126
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

59

2127 Annex B—An IoT Capabilities Table

2128

2129 This table provides some details about the types of functions that each capability type can perform and the type of inputs and outputs 

2130 for the function. These functions are the primary capabilities provided by the component. The three capability types not included in 

2131 the table (supporting, network interface, and human UI) provide secondary capabilities that are used to connect the components to 

2132 other components and support the primary functions.

2133 Table 5 – IoT Primary Capabilities Table 

Atomic Capability Type Input Type Transform Output 

Type

Assumptions

Actuating Digital data Desired 

change in 

representation 

of aspect of 

physical state

Physical 

energy

Intent is to effect change of state in the physical world. 

Errors may be introduced in the digital logic, the D/A 

converter, the analog electrical circuit and the actuator 

transducer. There is a time delay between the input data 

arriving at the component and the change being made to 

the environment.

Data Storing Digital data Set of 

Information 

set or subset 

of information 

available over 

time

Digital 

data

Intent is to store data for later use. Data is persistent. Data 

may be pushed out by the component or provided based on 

an external request. There is a time delay between the 

input and output and between a response to a data request 

and the initial request.

Networking Digital data Set of 

information 

same set of 

information 

available over 

distance

Digital 

data

Intent is to move data from one location to another. 

Location is understood in a logical sense rather than purely 

physical.

There is a time delay between the input and output.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

60

Atomic Capability Type Input Type Transform Output 

Type

Assumptions

Processing Digital data Set of 

information 

new set of 

information 

Digital 

data

Intent is to transform digital data. There is no fundamental 

“lossiness” in digital processing. There is a time delay 

between the input and output.

Sensing Physical energy Aspect of 

physical 

system state 

Representation 

of aspect of 

physical state

Digital 

data

Intent is to observe a property of the physical world. Is 

“read only” – any change to the physical state is an 

undesired side effect.

Measurement errors are introduced by the physical 

environment between the physical system and the sensor 

transducer, in the sensor transducer itself, in the analog 

electrical circuit, in the A/D converter, and in the digital 

logic of the sensor. There is also a time delay between the 

sensing and the data becoming available at the component 

output.

2134
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

61

2135 Annex C—An IT Standards Maturity Model

2136

2137 Table 6 provides a proposed classification system for characterizing the present state of market 

2138 impact of a standard. The present state may consist of several maturity levels. For instance, it’s 

2139 possible for Under Development, Reference Implementation, Testing, Commercial Availability 

2140 and Market Acceptance levels to occur concurrently. 

2141

2142 Table 6 – IT Standards Maturity Model

Maturity Level Definition

No Standard SDOs have not initiated any standard development projects.

Under Development SDOs have initiated standard development projects.

Open source projects have been initiated.

Guidance Available

A company, government agency, or industry group document is 

available, indicating there may be sufficient understanding and 

content to use the document as a basis for a standard.

Approved Standard

SDO-approved standard is available to public.

Some SDOs require multiple implementations before final 

designation as a “standard.”

Under Revision Revisions or amendments are in progress that may affect 

backward compatibility with the original standard.

Technically Stable

The standard is stable and its technical content is mature. No 

major revisions or amendments are in progress that will affect 

backward compatibility with the original standard.

Reference 

Implementation Reference implementation is available.

Testing Test tools are available.

Testing and test reports are available.

Conformity 

Assessment

First, second, or third party (e.g., certification) assessment 

programs are available.

Commercial 

Availability

Several products/services from different vendors exist on the 

market to implement this standard.

Market Acceptance Widespread use of technology within an industry. De facto or de 

jure market acceptance of standards-based products/services.

Sunset Newer standards (revisions or replacements) are under 

development.

2143

2144 Some SDOs require two or more implementations before final approval of a standard. Such 

2145 implementations may or may not be commercial products or services. In other cases, an SDO 

2146 may be developing a standard while conforming commercial products or services are already 

2147 being sold. Innovation in IT means that IT standards are constantly being developed, approved, 

2148 and maintained. Revisions to previous editions of standards may or may not be backward-
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

62

2149 compatible. An SDO approved standard does not necessarily equate with success. Widespread 

2150 market acceptance of an approved standard is the goal.

2151
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

63

2152 Annex D—IoT Standards Mapping to Core Areas of Cybersecurity

2153

2154 This annex represents a snapshot in time. It has been developed by the IoT Task Group to help understand the present state of 

2155 international cybersecurity standards development for IoT.

2156

2157 The following annotated listing of standards is not exhaustive but does represent an extensive effort to identify relevant IoT 

2158 cybersecurity standards. Some standards may be listed for more than one core area of cybersecurity. 

2159

2160 The state of market acceptance for standards (i.e., Maturity Level) can be relatively easy or difficult to ascertain. The Maturity Levels 

2161 are described in Table 6. The Maturity Level and other information below is subject to change based upon further review and 

2162 comments on this draft Report.

2163

2164 The listing is sorted by Core Area of Cybersecurity, then by SDO, and last by Documents.

2165

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Bluetooth LE Bluetooth SIG

Bluetooth Low Energy (BLE)

Key Generation: When using Bluetooth LE Secure Connections, the 

following keys are exchanged between master and slave:

• Connection Signature Resolving Key (CSRK) for Authentication 

of unencrypted data

• Identity Resolving Key (IRK) for Device Identity and Privacy

Encryption: BLE uses AES-CCM cryptography. Like BR/EDR, the LE 

controller will perform the encryption function. This function generates 

128-bit encrypted data from a 128-bit key and 128-bit plaintext data 

using the AES-128-bit cypher defined in FIPS-1971.

Guidance 

Available

Commercial 

Availability

Market 

Acceptance

Reference 

Implementation

What is BLE?

A BLE beacon is a 

small device –

usually powered by 

battery or USB –

that emits a 

Bluetooth Low 

Energy signal.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

64

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Signed Data: BLE supports the ability to send authenticated data over an 

unencrypted transport between two devices with a trusted relationship. 

This is accomplished by signing the data with a CSRK.

ETSI GR 

QSC 004 

V1.1.1 (2017-

03):

ETSI

Quantum-Safe Cryptography; Quantum-Safe threat assessment

The present document presents the results of a simplified threat 

assessment following the guidelines of ETSI TS 102 165-1 [i.3] for a 

number of use cases. The method and key results of the analysis is 

described in clause 4. 

The present document makes a number of assumptions regarding the 

timescale for the deployment of viable quantum computers, however the 

overriding assertion is that quantum computing will become viable in 

due course. This is examined in more detail in clause 5. 

The impact of quantum computing attacks on the cryptographic 

deployments used in a number of existing industrial deployment 

scenarios are considered in clause 7. 

Approved 

Standard

ETSI GR 

QSC 001 

V1.1.1 (2016-

07)

ETSI

Quantum-Safe Cryptography (QSC); Quantum-safe algorithmic 

framework 

The present document gives an overview of the current understanding 

and best practice in academia and industry about quantum-safe 

cryptography (QSC). It focuses on identifying and assessing 

cryptographic primitives that have been proposed for efficient key 

establishment and authentication applications, and which may be 

suitable for standardization by ETSI and subsequent use by industry to 

develop quantum-safe solutions for real-world applications. 

QSC is a rapidly growing area of research. There are already academic 

conference series such as PQC and workshops have been established by 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

65

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

ETSI/IQC [i.1] and NIST. The European Commission has recently 

granted funding to two QSC projects under the Horizon 2020 

framework: SAFEcrypto [i.2] and PQCrypto [i.3] and [i.4]. The present 

document draws on all these research efforts. 

The present document will cover three main areas. Clauses 4 and 5 

discuss the types of primitives being considered and describe an 

assessment framework; clauses 6 to 10 discuss some representative 

cryptographic primitives; and clause 11 gives a preliminary discussion 

of key sizes. 

ETSI GR 

QSC 003 

V1.1.1 (2017-

02)

ETSI

Quantum Safe Cryptography; Case Studies and Deployment Scenarios

The present document examines a number of real-world uses cases for 

the deployment of quantum-safe cryptography (QSC). Specifically, it 

examines some typical applications where cryptographic primitives are 

deployed today and discusses some points for consideration by 

developers, highlighting features that may need change to accommodate 

quantum-safe cryptography. The main focus of the document is on 

options for upgrading public-key primitives for key establishment and 

authentication, although several alternative, non-public-key options are 

also discussed. 

The present document gives an overview of different technology areas; 

identify where the security and cryptography currently resides; and 

indicate how things may have to evolve to support quantum-safe 

cryptographic primitives. Clauses five and six discuss network security 

protocols, using TLS and S/MIME as typical examples. These are 

contrasted in clauses seven and eight by an examination of security 

options for IoT and Satellite use cases, which have very different 

requirements and constraints than traditional Internet-type services. 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

66

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Some alternatives to public key protocols are reviewed in clause nine. 

Authentication requirements are discussed in clause ten and some 

forward-looking examples providing advanced functionality are 

examined in clause eleven.

ETSI GS 

QKD 002 

V1.1.1 (2010-

06)

ETSI

Quantum Key Distribution; Use Cases

The Use Cases Document shall provide an overview of possible 

application scenarios in which Quantum Key Distribution (QKD) 

systems ([i.1]) can be used as building blocks for high security 

Information and communication technology (ICT) systems. 

QKD

Approved 

Standard

Trusted 

Execution 

Environment 

(TEE)

GlobalPlatfor

m

The TEE's ability to offer isolated safe execution of authorized security 

software, known as 'trusted applications', enables it to provide end-toend security by enforcing protected execution of authenticated code, 

confidentiality, authenticity, privacy, system integrity and data access 

rights.

Under Section “What is a TEE?”

Approved 

Standards

Guidance 

Available 

What is a TEE?

The TEE is a secure 

area of the main 

processor in any 

connected device 

that ensures that 

sensitive area is 

stored, process and 

protected.

HITRUST 

CSF v9

10 September 

2017

HITRUST 

Alliance

Message Integrity:

Specification: Requirements for ensuring authenticity and protecting 

message integrity in applications shall be identified and controls 

implemented.

Implementation: The information system provides mechanisms to 

protect the authenticity of communications sessions.

The system shall implement one (1) of the following integrity protection 

algorithms

Approved 

Standard

Under 

Revision

Guidance 

Available
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

67

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

• HMAC-SHA-1

• HMAC-MD5

Output Data Validation:

Specification: Data output from an application shall be validated to 

ensure that the processing of stored information is correct and 

appropriate to the circumstances.

Implementation: Output validation shall include:

• Plausibility checks to test whether the output data is reasonable

• Reconciliation control counts to ensure processing of all data

• Providing sufficient information for a reader

• Procedures for responding to output validation tests

• Defining the responsibilities of all personnel involved in the data 

output process

• Creating an automated log of activities in the data output 

validation process

Cryptographic Controls:

Objective: to protect the confidentiality, authenticity and integrity of 

information by cryptographic means.

A policy shall be developed on the use of cryptographic controls. Key 

management should be in place to support the use of cryptographic 

techniques.

Key Management:

Specification: key management shall be in place to support the 

organization’s use of cryptographic techniques.

Implementation: all cryptographic keys shall be protected against 

modification, loss, and destruction. Keys shall not be stored in the 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

68

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Cloud, but maintained by the cloud consumer or trusted key 

management provider. Key management and key usage are separated 

duties. 

Page 462, Sections under category 10

IEEE 1363-

2000

and

IEEE 1363a2004

IEEE

traditional public-key cryptography Approved 

Standard

IEEE 1619-

2007 IEEE

cryptographic protection of data on block-oriented storage devices Approved 

Standard

Some activity 

regarding 

revisions

IEEE 802.1X2010 IEEE

An IEEE Standard for port-based Network Access Control (PNAC).

It provides authentication mechanisms to devices wishing to attach to an 

LAN or WLAN.

802.1X authentication involves three parties: a supplicant, an 

authenticator, and an authentication server.

Supplicant: a client device that wishes to attach to the LAN/WLAN. 

Authenticator: a network device, such as an Ethernet switch or wireless 

access point. It acts like a security guard to a protected network.

Authentication server: typically, a host running software supporting the 

RADIUS and EAP protocols.

Approved 

Standard

Under 

Revision?
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

69

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Typical authentication progression:

1. Initialization: on detection of a new supplicant, the port on the 

switch is enabled and set to the unauthorized state.

2. Initiation: to initiate authentication the authenticator will 

periodically transmit EAP-Request Identity frames to a special 

Layer 2 address on the local network segment. 

3. Negotiation: The authentication server sends a reply to the 

authenticator, containing an EAP Request specifying the EAP 

Method. The authenticator encapsulates the EAP Request in an 

EAPOL frame and transmits it to the supplicant. At this point the 

supplicant can start using the requested EAP Method, or do an 

NAK ("Negative Acknowledgement") and respond with the EAP 

Methods it is willing to perform.

4. Authentication: If the authentication server and supplicant agree 

on an EAP Method, EAP Requests and Responses are sent 

between the supplicant and the authentication server (translated 

by the authenticator) until the authentication server responds 

with either an EAP-Success message (encapsulated in a 

RADIUS Access-Accept packet), or an EAP-Failure message 

(encapsulated in a RADIUS Access-Reject packet). If 

authentication is successful, the authenticator sets the port to the 

"authorized" state and normal traffic is allowed, if it is 

unsuccessful the port remains in the "unauthorized" state. When 

the supplicant logs off, it sends an EAPOL-logoff message to the 

authenticator, the authenticator then sets the port to the 

"unauthorized" state, once again blocking all non-EAP traffic.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

70

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

IEEE P1363.3 IEEE identity-based public-key cryptography using pairings Under 

Development

IEEE 1619.1-

2007 IEEE

authenticated encryption with length expansion for storage devices

Cryptographic unit: a cryptographic unit is any combination of software, 

firmware, or hardware that is capable of handling plaintext and 

ciphertext using at least one of the cryptographic modes.

The cryptographic unit shall contain the following subcomponents:

• Plaintext record formatter and/or plaintext record de-formatter

• Encryption routine and/or decryption routine

• Cryptographic parameters

The cryptographic unit may contain the following subcomponents:

• Random bit generator

• Key wrapping routine

• Key unwrapping routine

Page 10, Section 4.2.4

Cryptographic modes:

• Counter with cipher block chaining-message authentication code 

(CCM)

• Galois/Counter Mode (GCM)

• Cipher block chaining with keyed-hash message authentication 

code (CBC-HMAC)

• Xor-encrypt-xor with tweakable clock-cipher with keyed-hash 

message authentication code (XTS-HMAC)

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

71

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Page 13, Section 5

IEEE 1363.2-

2008 IEEE

Variations of the network password problem: This standard describes 

three classes of password-based methods that solve three variations of 

the password-only network login problem. These methods can provide 

mutual zero knowledge password proof and remote passwordauthenticated establishment of cryptographic keys.

1. Balanced password-authenticated key agreement – two parties 

share a common password and they want to prove to each other 

that they know the password, and only then engage in secure 

communications, without revealing the password to others.

2. Augmented password-authenticated key agreement methods –

similar to the first except that one of the parties, the Server, has 

password verification data derived using a one-way function of 

the password.

3. Password- authenticated key retrieval – addresses the scenario 

where one desires to further decrease the sensitivity of stored 

password-derived data.

All these methods require one or more parties to use specific passwordrelated data to make the method succeed.

Primitives: The following types of primitives are defined in this 

standard:

• Random element derivation primitives (REDP), components of 

password-authenticated key agreement schemes (PKAS) and 

password-authenticated key retrieval schemes (PKRS).

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

72

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

• Password-entangled public-key generation primitives 

(PEPKGP); components of PKASs and PKRSs

• Secret value derivation primitives (SVDP), components of 

augmented password-authenticated key agreement and PKRSs

• Password verification data generation primitives (PVDGP), 

components of augmented password-authenticated key 

agreement schemes (APKAS)

• Key retrieval blinding primitives (KRBP), key retrieval 

unblinding primitives (KRUP), and key retrieval permutation 

primitives (KRPP), components of key retrieval schemes.

IEEE 1619.2-

2010 IEEE

wide-block encryption for shared storage media

This document specifies two different EAD algorithms: EME2-AES and 

XCB-AES. Both implement a tweakable pseudorandom permutation 

with substantially similar security properties and have similar bounds 

with respect to the amount of data that is able to be safely be encrypted 

with a single key.

Nevertheless, upon choosing an algorithm, implementers might need to 

consider other factors than security level such as software performance 

or hardware implementation size

Approved 

Standard

IEEE 802.11-

2016 IEEE

Classes of security algorithm: This standard defines two classes of 

security algorithms for IEEE802.11 networks: Algorithms for creating 

and using an RSNA, called RSNA algorithms, and Pre-RSNA 

algorithms.

Security methods:

Approved 

Standard

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

73

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Pre-RSNA security comprises the following algorithms and procedures:

• WEP

• IEEE 802.11 entity authentication

RSNA security comprises the following algorithms and procedures:

• TKIP

• CCMP

• GCMP

• BIP

• RSNA establishment and termination procedures, including use 

of IEEE 802.1X authentication and SAE authentication

• Key management procedures

Page 1923, Section 12

IEEE 

802.15.4-2015 IEEE

Security: The MAC sublayer is responsible for providing security 

services on specified incoming and outgoing frames when requested to 

do so by the higher layers. This standard supports the following security 

services:

• Data confidentiality

• Data authenticity

• Replay protection (when not using TSCH mode)

Outgoing frame security procedure: The inputs to this procedure are the 

frame to be secured and the SecurityLevel, KeyIdMode, KeySource, 

and KeyIndex parameters.

Approved 

Standard

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

74

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

Page 360, Section 9

Internet Draft IETF

End-to-end Security:

Regarding end-to-end security in the context of the confidentiality and 

integrity protection, the packets are processed applying message

authentication codes or encryption. The five approaches to handle such 

end-to end confidentiality and integrity protection while letting 

middleboxes access/modify data for different purposes:

• Sharing credentials with middleboxes enables middleboxes to 

transform packets and re-apply the security measures after 

transformation

• Reusing the Internet wire format in the IoT makes conversion 

between IoT and Internet protocols unnecessary. However, it 

can lead to poor performance in some use cases because IoT 

specific optimizations are not possible.

• Selectively protecting vital and immutable packet parts with a 

MAC or with encryption requires a careful balance between 

performance and security. Otherwise, this approach will either 

result in poor performance or poor security.

• Message authentication codes that sustain transformation can be 

realized by considering the order of transformation and 

protection.

• Object security based mechanisms can bridge the protocol 

worlds, but still requires that the two worlds use the same object 

security formats.

Page 35 section 7.1.3

Under 

Development

IETF “State of the 

Art and Challenges 

for the Internet of 

Things” draft-irtft2trg-iot-seccons-02

RFC 5280 - IETF Internet X.509 Public Key Infrastructure Certificate and Certificate Approved 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

75

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

2015 Revocation List (CRL) Profile (Updated) Standard

RFC 7925 IETF

TLS and DTLS:

The TLS protocol provides authenticated, confidentiality and integrity 

protected communication between two endpoints. The protocol is 

composed of two layers: The Record Protocol and the handshaking 

protocols. At the lowest level, layered on top of a reliable transport 

protocol (e.g., TSP), is the Record Protocol. It provides connection 

security by using symmetric cryptography for confidentiality, data 

origin authentication, and integrity protection.

Page 5, Section 3.1

Approved 

Standard

Commercial 

Availability

Conformity 

Assessment

Market 

Acceptance

RFC 8105 IETF

Security Considerations:

The secure transmission of circuit more services in DECT (Digital 

Enhanced Cordless Telecommunications) is based on the DSAA2 

(DECT Standard Authentication Algorithm #2) and DSC/DSC2 (DECT 

Standard Cipher/DECT Standard Cipher #2) specifications developed 

by ETSI Technical Committee (TC) DECT and the ETSI Security 

Algorithms Group of Experts (SAGE).

DECT ULE communications are secured at the link layer (DLC) by 

encryption and per-message authentication through CCM (Counter with 

Cipher Block Chaining Message Authentication Code (CBC-MAC)) 

mode. The underlying algorithm for providing encryption and 

authentication is AES128.

The DECT ULE (Digital Enhances Cordless Telecommunications Ultra 

Low Energy) pairing procedure generates a master User Authentication 

Key (UAK). During the location registration procedure, or when the 

permanent virtual circuits are established, the session security keys are 

generated. Both the master authentication key and session security keys 

Under 

Development

Guidance Available

Currently in the 

IETF Standard 

Track
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

76

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

are generated by use of the DSAA2 algorithm, which uses AES127 as 

the underlying algorithm.

Page 17, Section 5

ISO/IEC 

29167-1:2014 ISO/IEC

security services for RFID air interfaces

Defines the architecture for security services for the ISO/IEC 18000 air 

interfaces standards for radio frequency identification (RFID) devices. 

Approved 

Standard

ISO/IEC 

29167-

10:2017

ISO/IEC

Part 10: Crypto Suite AES-128 Security Services for Air Interface 

Communications

Approved 

Standard

Commercial 

Availability

ISO/IEC 

29167-

11:2014

ISO/IEC

Part 11: Crypto Suite PRESENT-80 Security Services for Air Interface 

Communications

Approved 

Standard

ISO/IEC 

29167-

12:2015

ISO/IEC

Part 12: Crypto Suite ECC-DH Security Services for Air Interface 

Communications

Approved 

Standard

ISO/IEC 

29167-

13:2015

ISO/IEC

Part 13: Crypto Suite Grain-128A Security Services for Air Interface 

Communications

Approved 

Standard

Commercial 

Availability

ISO/IEC 

29167-

14:2015

ISO/IEC

Part 14: Crypto Suite AES OFB Security Services for Air Interface 

Communications

Approved 

Standard

ISO/IEC 

29167-

16:2015

ISO/IEC

Part 16: Crypto Suite ECDSA-ECDH Security Services for Air Interface 

Communications

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

77

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

ISO/IEC 

29167-

17:2015

ISO/IEC

Part 17: Crypto Suite CryptoGPS Security Services for Air Interface 

Communications

Approved 

Standard

ISO/IEC 

29167-

19:2016

ISO/IEC

Part 19: Crypto suite RAMON security services for air interface 

communications

Approved 

Standard

ISO/IEC TR 

29181-9:2017 ISO/IEC

Data Encryption: IPv4 can only utilize data encryption (IPV6-IPSec), 

but its addresses cannot be encrypted. It cannot provide address 

confidentiality.

This technical report is Part 2 of the Technical report on Future Network 

– Problem Statement and Requirements developed by ISO/IEC JTC1 

SC6. Part 2 focuses on the issue of naming and addressing.

New Communications Rules to Supplement New NAS:

In order to protect the addressing security, Future Network may 

consider adopting a new communication rule requiring verification of 

source address and destination address before sending message to the 

networks. The new rules should design and utilize better and newer 

authentication and verification systems to achieve system wide security.

• To construct a true identity authentication, verification and 

certification system.

• To change from passive and defensive network security into 

proactively managed cybersecurity.

• To prove communicator true identity, verify network (Internet) 

address and routing path authenticity, and prevent unauthorized 

access, and realize trusted connection.

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

78

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

• To certify the authenticity of software and the consistency of 

software identity and software data, achieving trusted 

computing.

• Trusted connection which is the key for trusted systems. Trusted 

routing is the key for realizing trusted connection.

Page 23, Section 6.2.4.3

This technical report is Part 2 of the Technical report on Future Network 

– Problem Statement and Requirements developed by ISO/IEC JTC1 

SC6. Part 2 focuses on the issue of naming and addressing.

ISO/IEC 

29192-1:2012 ISO/IEC

Lightweight Cryptography – includes general information such as 

security, classification and implementation requirements

Approved 

Standard

Market 

Acceptance

Under 

revision

ISO/IEC 

29192-2:2012 ISO/IEC

specifies two block ciphers suitable for lightweight cryptography:

a) PRESENT: a lightweight block cipher with a block size of 64 bits and 

a key size of 80 or 128 bits;

b) CLEFIA: a lightweight block cipher with a block size of 128 bits and 

a key size of 128, 192 or 256 bits.

Approved 

Standard

Market 

Acceptance

ISO/IEC 

29192-2:2012

PDAM 1

ISO/IEC

The SIMON and SPECK families of lightweight block ciphers were 

developed as an aid for securing applications in very constrained 

environments where AES may not be suitable.

Under 

Development

ISO/IEC 

29192-2:2012

NP Amd 2

ISO/IEC

LEA is a lightweight block cipher that is being developed within 

ISO/IEC JTC 1 SC 27 WG 2 as an aid for securing application in very 

constrained environments.

Under 

Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

79

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

ISO/IEC 

29192-3:2012 ISO/IEC

specifies two dedicated keystream generators for lightweight stream 

ciphers:

•Enocoro: a lightweight keystream generator with a key size of 80 or 

128 bits;

•Trivium: a lightweight keystream generator with a key size of 80 bits.

Approved 

Standard

Market 

Acceptance

ISO/IEC 

29192-4:2013

Amd.1: 

(2016)

ISO/IEC

specifies three lightweight mechanisms using asymmetric techniques:

a) a unilateral authentication mechanism based on discrete logarithms 

on elliptic curves;

b) an authenticated lightweight key exchange (ALIKE) mechanism for 

unilateral authentication and establishment of a session key;

c) an identity-based signature mechanism.

Approved 

Standard

Market 

Acceptance

ISO/IEC 

29192-5:2016 ISO/IEC

specifies three hash-functions suitable for applications requiring 

lightweight cryptographic implementations.

- PHOTON: a lightweight hash-function with permutation sizes of 100, 

144, 196, 256 and 288 bits computing hash-codes of length 80, 128, 

160, 224, and 256 bits, respectively.

- SPONGENT: a lightweight hash-function with permutation sizes of 

88, 136, 176, 240 and 272 bits computing hash-codes of length 88, 128, 

160, 224, and 256 bits, respectively.

- Lesamnta-LW: a lightweight hash-function with permutation size 384 

bits computing a hash-code of length 256 bits.

Approved 

Standard

Market 

Acceptance

ISO/IEC 

9594-8:2017 ISO/IEC X.509 Certificate definition Approved Standard

ISO/IEC CD 

29192-6 ISO/IEC message authentication codes (MACs) Under Development

ISO/IEC WD 

29192-7 ISO/IEC broadcast authentication protocols Under Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

80

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

KMIP 1.1 and 

KMIP 

Profiles 1.1 -

2013

OASIS

key management interoperability protocol Approved 

Standard

OCF SPEC 

1.0

June 28, 2017

OCF

Message Integrity and Confidentiality: 

Secured communications between OCF Clients and OCF Servers are 

protected against eavesdropping, tampering, or message replay, using 

security mechanisms that provide message confidentiality and integrity.

Page 75, Section 11

The goal for the OCF security architecture is to protect OCF resources 

and all aspects of Hardware and Software that are used to support the 

protection of OCF resource.

Guidance

Available

Reference 

Implementation

The Open 

Interconnect 

Consortium (OIC) 

has been relaunched in early 

2016 as the Open 

Connectivity 

Foundation (OCF)

OMA-TSLightweightM

2M-V1_0-

20170208-A

OMA 

The LwM2M protocol utilizes DTLS with these channel bindings to 

implement authentication, confidentiality, and data integrity features of 

the protocol between communicating LwM2M entities.

LwM2M supports three different types of credentials, namely:

• Certificates

• Raw public keys

o TLS_PSK_WITH_128_CCM_8

o TLS_PSK_WITH_AES_128_CBC_SHA256

• Pre-shared secrets

o TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8

o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA25

6

Page 58 Section 7

Guidance 

Available

Open Mobile 

Alliance (OMA)

What is OMA 

M2M?

OMA’s 

LightweightM2M is 

a device 

management 

protocol designed 

for sensor networks 

and the demands of 

a machine-tomachine (M2M) 

environment.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

81

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

OpenFog RA OpenFog 

Consortium

There are three cornerstones of the fog security perspective: 

Confidentiality, Integrity and availability

Threat model is also displayed.

Page 49, Section 5.4.2.3

Cryptographic Functions: Initial base list of required standard 

cryptographic algorithms that must be available on all OpenFog nodes:

• Symmetric (or Secret-key) Ciphers for confidentiality protection

• Cryptographic Hash Functions for integrity protection and 

authentication of communicating parties

• Asymmetric (or Public-Key) Ciphers for generating secret keys, 

establishing long-term security credentials and providing nonrepudiation services.

The OpenFog cryptographic module must support the following FIPS 

approved cryptographic functions at a minimum:

• Symmetric Key Ciphers

o AES (with at least 128-bit keys)

o Triple-DES

• Asymmetric Key Ciphers

Page 122, Section 10.1.1

Guidance 

Available

(has a few use 

cases)

What is Fog?

A system-level 

horizontal 

architecture that 

distributes 

resources and 

services of 

computing, storage, 

control and 

networking 

anywhere along the 

continuum from 

Cloud to Things.

TPM

1 March 2011 TCG

Trusted Platform Module (TPM)

Cryptographic Co-Processor:

The TPM employs conventional cryptographic operations in 

conventional ways:

• Asymmetric key generation (RSA)

Guidance 

Available

Commercial 

Availability

Market 

What is TPM?

An industry 

specification that 

enables trust in 

computing 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

82

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

• Asymmetric encryption/decryption (RSA)

• Hashing (SHA-1)

• Random number generation (RNG)

The TPM uses these capabilities to perform generation of random data, 

generation of asymmetric keys, signing and confidentiality of stored 

data.

Page 30, Section 4.2.2

Remote Attestation: allows changes to the user’s computer to be 

detected by authorized parties. Remote attestation is usually combined 

with public-key encryption do that the information sent can only be read 

by the programs that presented and requested the attestation, and not by 

an eavesdropper.

Link

Acceptance

Reference 

Implement

platforms in 

general.

Thread Spec 

1.1

Feb 13 2017

Thread Group

J-PAKE/EC J-PAKE:

The fundamental security used during the joining of authentication and 

key agreement is an elliptic curve variant of J-PAKE (Password 

Authenticated Key Exchange with juggling), using the NIST P-256 

elliptic curve.

Key agreement: Diffie-Hellmann

Authentication: Schnorr signatures

Doc 2, Page 28, Section 1.3.3.1

Key Generation:

Each Thread node receives the Master Key when joining and assigns it 

to the thrMasterKey attribute, which is used in conjunction with a 

sequence counter. 

The use of Hashed Message Authentication Mode with the SHA-256 

algorithm (HMAC-SHA256) as the keyed hash function produces an 

Approved 

Standard

Guidance 

Available

Commercial 

Availability

Conformity 

Assessment

Market 

Acceptance

Reference 

Implementation

What is Thread?

Securely and 

reliably connects 

products around the 

home using a robust 

mesh network and 

an open IPv6 based 

protocol.

What is IEEE 

802.15.4?

Thread leverages 

IEEE 802.15.4

The IEEE 802.15.4
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

83

Cryptographic Techniques:

Techniques and mechanisms and their associated standards are used to provide: confidentiality; entity authentication; non-repudiation; key 

management; data integrity; trust worthy data platforms; message authentication; and digital signatures.

Documents SDO Description

Maturity Level

(Table 6) Notes

output of 32 bytes. Therefore, this is sufficient for the two separate keys 

required for the MAC sublayer and MLE.

Doc 2, Page 162, Section 7.1.4

standard targets

low-power personal 

area networks.

2166

2167
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

84

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

ETSI GS NGP 005 

V1.1.1 (2017-04) ETSI

Next Generation Protocols (NGP); Next Generation Protocol 

Requirements

The scope of the present document is to specify the minimum set 

of key requirements for the Next Generation Protocols (NGP), 

Industry Specific Group (ISG).

The present document addresses requirements in the following 

areas: • Business Case and Techno-Economics • Migration • 

General Technical Requirements • Addressing • Security • 

Mobility • Multi-Access Support (including FMC) • Context 

Awareness • Performance (including Content Enablement) • 

Network Virtualisation • IoT Support • Energy Efficiency • eCommerce • MEC • Mission Critical Services • Drones and 

Autonomous Vehicles and Connected Vehicles • Ultra Reliable 

Low Latency Communications

Approved 

Standard

ETSI TR 103 118 

V1.1.1 (2015-08) ETSI

Machine-to-Machine communications (M2M); Smart Energy 

Infrastructures security; Review of existing security measures 

and convergence investigations

The present document reviews security methods provided by 

deployed standards used in the Smart Energy industry (e.g., IEC 

62351 [i.7], IEC 62443 [i.8]) or mandated by regulation (e.g., 

Requirements from the German BSI for Smart Meter Gateways 

and Secure Element) as well as gaps identified by the Smart Grid 

Information Security group for the M/490 mandate, in order to 

identify areas where ETSI may bring additional value, e.g., by 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

85

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

extending or harmonising security solutions where possible

ETSI TR 103 375 

V1.1.1 (2016-10) ETSI

SmartM2M; IoT Standards landscape and future evolutions:

The scope of the present document is to provide an overview of 

the IoT standards landscape: requirements, architecture, 

protocols, tests, etc. to provide the roadmaps of the IoT 

standards, when they are available.

The essential objectives are: • To analyse the status of current 

IoT standardisation. • To assess the degree of industry and 

vertical market fragmentation. • To point towards actions that 

can increase the effectiveness of IoT standardisation, to improve 

interoperability, and to allow for the building of IoT ecosystems

Approved 

Standard

ETSI TR 118 518 

V2.0.0 (2016-09) ETSI

oneM2M; Industrial Domain Enablement (oneM2M TR-0018 

version 2.0.0 Release 2)

The present document collects the use cases of the industrial 

domain and the requirements needed to support the use cases 

collectively. In addition, it identifies the necessary technical 

work needed to be addressed while enhancing future oneM2M 

specifications.

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

86

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

HITRUST CSF v9 

10 September 2017

HITRUST

Alliance

Access Control:

Control objective: to control access to information, information 

assets, and business processes based on business and security 

requirements.

Authorized Access to Information Systems:

Control Objective: to ensure authorized user accounts are 

registered, tracked and periodically validated to prevent 

unauthorized access to information systems.

Network Access Control:

Control Objective: to prevent unauthorized access to networking 

services that they have been specifically authorized to use. 

Authentication and authorization mechanisms shall be applied 

for users and equipment.

Operating System Access Control:

Objective: to prevent unauthorized access to operating systems.

User identification and Authentication:

Specification: All users shall have a unique identifier for their 

personal use only, and an authentication technique shall be 

implemented to substantiate the claimed identity of a user.

Approved 

Standard

Under 

Revision

Guidance 

Available

Internet Draft 

SACM Information 

Model

IETF

Secure Automation and Continuous Monitoring (SACM) 

Information Model Under 

Development

RFC 5070 – 2007 IETF

Incident Object Description Exchange Format (IODEF) for 

sharing information commonly exchanged by Computer Security Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

87

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

Incident Response Teams (CSIRTs) about computer security 

incidents

RFC 5901 -2010 IETF

extensions to the IODEF for reporting phishing Approved 

Standard

RFC 6545 - 2012 IETF

real-time inter-network defense Approved 

Standard

ISO/IEC 27035-

1:2016 ISO/IEC

guidance on information security incident management for large 

and medium-sized organizations Approved 

Standard

ISO/IEC 29147: 

2014 ISO/IEC

vulnerability disclosure Approved 

Standard

ISO/IEC 30111: 

2013 ISO/IEC

vulnerability handling process Approved 

Standard

X.1056 - 2009 ITU-T

security incident management guidelines for telecommunications 

organizations Approved 

Standard

OpenC2 OASIS

Enables the machine to machine exchange of commands to 

achieve investigative, remediation and/or mitigation effects.

Enables real-time automated and active cyber defense through 

Under 

Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

88

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

the use of standardized commands.

Provides the action to be taken.

Trusted Automated 

Exchange of 

Indicator 

Information (TAXII) 

Version 2.0 October 

– 2017

OASIS

OASIS Trusted Automated Exchange of Indicator Information 

(TAXII) Version 2.0

application layer protocol for the communication of cyber threat 

information

Approved 

Specification

Structured Threat 

Information 

Expression (STIX) 

Version 2.0 –

October 2017

OASIS

OASIS Structured Threat Information Expression (STIX) Version 

2.0

defines a framework that enables cyber threat information 

sharing and cyber threat analysis

Approved 

Specification

OpenFog RA

February 2017

OpenFog 

Consortium

Tamper Response:

Soft Fail: Sensitive data is cleared and a second interrupt signal 

is sent to the security monitor to confirm this has been done so 

that it can restart the processor and continue execution.

Hard Fail: The actions for a Soft Fail are performed, plus the 

Guidance 

Available

(has a few use 

cases)

What is Fog?

A system-level 

horizontal 

architecture that 

distributes 

resources and 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

89

Cyber Incident Management:

Standards that support information sharing processes, products, and technology implementations for cyber incident identification, handling, and 

remediation. Such standards enable organizations to identify when a cyber incident has occurred, to properly respond to that incident and recover 

from any losses as a result of the incident. Such standards are one method to enable jurisdictions to exchange information about incidents, 

vulnerabilities, threats and attacks, the system(s) that were exploited, security configurations and weaknesses that could be exploited, etc.

Documents SDO Description Maturity Level

(Table 6) Notes

caches and memory are zeroed and the system is reset. Both 

lower and higher consequences may be available. The lowest 

consequence would be to do nothing, or the event can be logged 

for later analysis.

Page 71, Section 5.5.6.5

services of 

computing, 

storage, control 

and networking 

anywhere along 

the continuum 

from Cloud to 

Things.

DSS 3.2 – 2016 PCI

security controls around cardholder data to reduce credit card 

fraud Approved 

Standard

2168

2169
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

90

2170

Hardware Assurance:

Hardware assurance describe requirements and guidance to ensure a level of confidence that microelectronics (also known as microcircuits, 

semiconductors, and integrated circuits, including its embedded software and/or intellectual property) function as intended and are free of known 

vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system's hardware and/or its embedded software and/or 

intellectual property, throughout the life cycle.

Documents SDO Description Maturity Level

(Table 6) Notes

15408-1

:2009 ISO/IEC

Information technology – Security techniques – Evaluation criteria for IT 

security (Part 1: Introduction and general model)

Approved 

Standard

Technically 

Stable

Conformity 

Assessment

Commercial 

Availability

Market 

Acceptance

15408-2

:2008 ISO/IEC

Information technology – Security techniques – Evaluation criteria for IT 

security – Part 2: Security functional components

Approved 

Standard

Technically 

Stable

Conformity 

Assessment

Commercial 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

91

Hardware Assurance:

Hardware assurance describe requirements and guidance to ensure a level of confidence that microelectronics (also known as microcircuits, 

semiconductors, and integrated circuits, including its embedded software and/or intellectual property) function as intended and are free of known 

vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system's hardware and/or its embedded software and/or 

intellectual property, throughout the life cycle.

Documents SDO Description Maturity Level

(Table 6) Notes

Availability

Market 

Acceptance

15408-3

:2008 ISO/IEC

Information technology – Security techniques – Evaluation criteria for IT 

security – Part 3: Security assurance components

Approved 

Standard

Technically 

Stable

Conformity 

Assessment

Commercial 

Availability

Market 

Acceptance

20243:2015 ISO/IEC

Open Trusted Technology Provider Standard (O-TTPS) – Mitigating 

maliciously tainted and counterfeit products Approved 

Standard

Under 

Revision

Will be replaced by

ISO/IEC FDIS 

20243-1

and

ISO/IEC CD 

20243-2

27036-1

2014 ISO/IEC Information technology – Security techniques – Information security for supplier relationships (Part 1: Overview and concepts)

Approved 

Standard

This standard can 

be freely 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

92

Hardware Assurance:

Hardware assurance describe requirements and guidance to ensure a level of confidence that microelectronics (also known as microcircuits, 

semiconductors, and integrated circuits, including its embedded software and/or intellectual property) function as intended and are free of known 

vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system's hardware and/or its embedded software and/or 

intellectual property, throughout the life cycle.

Documents SDO Description Maturity Level

(Table 6) Notes

downloaded.

27036-2

2014 ISO/IEC Information technology – Security techniques – Information security for supplier relationships (Part 2: Common requirements)

Approved 

Standard

27036-3 

2013 ISO/IEC Information technology – Security techniques – Information security for supplier relationships – Part 3: Guidelines for ICT supply chain security

Approved 

Standard

ARP6178

2011

SAE 

International

Counterfeit Electronic Parts: Tool for Risk Assessment of Distributors Approved 

Standard

AS5553B

2016

SAE

International

Fraudulent/Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, 

and Disposition Verification Criteria

Approved 

Standard

AS6081

2012

SAE

International

Counterfeit Electronic Parts; Avoidance Protocol, Distributors Approved 

Standard

AS6171

2015

SAE

International

Test Method Standard; Counterfeit Electronic Parts Approved 

Standard

AS6171/11

2016

SAE

International

Techniques for Suspect/Counterfeit EEE Parts Detection by Design 

Recovery Test Methods.

Approved 

Standard

AS6171/5 SAE

International

Techniques for Suspect/Counterfeit EEE Parts Detection by Radiological 

Test Methods.

Under 

Development

AS6171/7 SAE

International

Techniques for Suspect/Counterfeit EEE Parts Detection by Electrical Test 

Methods 

Under 

Development

AS6171/8

2016

SAE

International

Techniques for Suspect/Counterfeit EEE Parts Detection by Raman 

Spectroscopy Test Methods.

Approved 

Standard

AS6174A

2014

SAE

International

Compliance Verification Matrix (VM) Slash Sheet for SAE AS6174A, 

Counterfeit Materiel; Assuring Acquisition of Authentic and Conforming 

Materiel. 

Approved 

Standard

AS6462A SAE Fraudulent/Counterfeit Electronic Parts; Avoidance, Detection, Mitigation, Approved 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

93

Hardware Assurance:

Hardware assurance describe requirements and guidance to ensure a level of confidence that microelectronics (also known as microcircuits, 

semiconductors, and integrated circuits, including its embedded software and/or intellectual property) function as intended and are free of known 

vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system's hardware and/or its embedded software and/or 

intellectual property, throughout the life cycle.

Documents SDO Description Maturity Level

(Table 6) Notes

2014 International and Disposition Verification Criteria (2014) Standard

2171

2172
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

94

2173

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

ETSI TR 118 512 

V2.0.0 (2016-09) ETSI

The present document provides options and 

analyses for the security features and 

mechanisms providing end-to-end security and 

group authentication for oneM2M. The scope of 

this technical report includes use cases, threat 

analyses, high level architecture, generic 

requirements, available options, evaluation of 

options, and detailed procedures for executing 

end-to-end security and group authentication.

Approved 

Standard

Universal 

Authentication 

Framework (UAF) 

v1.1 

Specifications

FIDO

The UAF is designed around passwordless and 

multifactor authentication flows. This 

architecture lends itself to authentication of 

users connecting to devices and M2M 

authentication.

Approved 

Standard

https://fidoalliance.org

CLP.14 v1.1 GSMA

Secure Identification:

When appropriate for the IoT Service, Network 

Operators recommend the use of UICC based 

mechanisms to securely identify Endpoint 

devices. “Single sign-on” services could also be 

provided by Network Operators to allow 

Endpoint devices to establish and prove their 

identity once, and then connect to several IoT 

Service Platforms without further 

Guidance 

Available

The GSMA IoT Security 

Guidelines are backed by an IoT 

Security Assessment scheme that 

enables companies to build secure 

IoT devices and solutions.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

95

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

inconvenience.

Page 11. Section 3.1

DS4P

Release 1, May 

2014

HL7

Implementation Guide: Data Segmentation for 

Privacy (DS4P), Release 1, May 2014 Approved 

Standard

FHIR Release 3 HL7

Fast Healthcare Interoperability Resources 

Specification (FHIR), Release 3

Under 

Development

(Trial Use)

HCS 

Release 1, August 

2014

HL7

HL7 Healthcare Privacy and Security 

Classification System (HCS), Release 1, August 

2014

Approved 

Standard

PASS;SLS

Release 1

June 2014

HL7

Privacy, Access and Security Services (PASS); 

Security Labeling Service (SLS)

describes the conceptual-level viewpoints 

associated with the business requirements that 

relate to the content, structure, and functional 

behavior of information important to the Access 

Control area of the Privacy, Access, and 

Security domains within the healthcare 

environment. 

Approved 

Standard

802.1AE-2006

802.1AEbw-2013

IEEE connectionless data confidentiality and integrity 

for media access independent protocols

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

96

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

Security Services:

The guarantees provided by MACsec support 

the following security services for stations 

participating in MACsec:

• Connectionless data integrity

• Data origin authenticity

• Confidentiality

• Replay protection

• Bounded receive delay

• And can be used to limit the nature and 

extent of denial of service attacks

Page 19, Section 6.9

802.1X-2004 IEEE

port based network access control Approved 

Standard

Under 

Revision?

Open Trust 

Protocol IETF

protocol to install, update, and delete 

applications and to manage security

configuration in a Trusted Execution 

Environment

Under 

Development

RFC 7925

July 2016 IETF

The handshaking protocol consist of three 

subprotocols, namely the handshake protocol, 

the change cipher spec protocol. And the alert 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

97

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

protocol. The handshake protocol allows the 

server and client to authenticate each other and 

to negotiate an encryption algorithm and 

cryptographic key before the application 

protocol transmits or received data.

Page 5, Section 3.1

ISO 19731:

2017 ISO

Digital analytics and web analyses for purposes 

of market, opinion and social research

Confidentiality of information:

All information supplied to the service provider 

by the client to conduct a research project shall 

be treated in the strictest confidence. It shall 

only be used in this context and shall not be 

made available to third parties without the 

client’s authorization. Confidential information 

shall be stored securely.

Page 16, Section 4.2

Data Security:

Service providers shall provide personnel with 

adequate access technology controls and 

protocols for data centers, processing and 

reporting servers, and general system access, as 

well as encryption and password policies. 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

98

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

Service providers shall ensure that security 

arrangements are sufficient to ensure that only 

those authorized can access systems and data.

Page 24, Section 6.7

OCF SPEC 1.0

June 28, 2017

OCF

Access Control: 

The OIC framework assumes that resources are 

hosted by an OIC server and are made available 

to OIC clients subject to access control and 

authorization mechanisms. The resources at the 

end point are protected through implementation 

of access control, authentication and 

confidentiality protection.

Page 15, Section 5.1

ACL Evaluation and Enforcement: The OIC 

server enforces access control over application 

resources before exposing them to the requestor. 

The security manager in the OIC sever 

authenticates the requestor if access is received 

via the secure port. If the request arrives over 

the unsecured port, the only ACL policies 

allowed are for anonymous requestors. If the 

anonymous ACL policy doesn’t name the 

requested resource access is denied. 

Guidance

Available

Reference 

Implementation

The Open Interconnect Consortium 

(OIC) has been re-launched in early 

2016 as the Open Connectivity 

Foundation (OCF)

The goal for the OCF security 

architecture is to protect OCF 

resources and all aspects of 

Hardware and Software that are 

used to support the protection of O 

resource.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

99

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

Page 77, Section 12.2

Device Authentication:

Asymmetric Keys Credentials: When using 

symmetric keys to authenticate, the server shall 

include the ServerKeyExchange message and set 

psk_identity_hint to the server’s device ID. The 

client shall validate that it has a credential with 

the Subject ID set to the server’s device ID, and 

a credential type of PSK. If it does not, the client 

shall respond with an unknown_psk_identity 

error or other suitable error.

Raw Asymmetric Key Credentials: When using 

raw asymmetric keys to authenticate, the client 

and the server shall include a suitable public key 

from a credential that is bound to their device.

Certifications: When using certificates to 

authenticate, the client and server shall each 

include their certificate chain, as stored in the 

appropriate credential, as part of the selected 

authentication cipher suite.

Page 74, Section 10
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

100

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

M2M Link

08 Feb 2017 OMA

Access Control: In the particular case where a 

single LwM2M Server Account exists in the 

LwM2M Client, the Server must have full 

access right on all the Objects and Object 

Instances in the LwM2M Client.

Access Control Object: In the presence of 

several LwM2M Servers, there is a need to 

determine if a certain LwM2M Server is 

authorized to instantiate a supported Object in 

the LwM2M Client. This kind of authorization 

can only be managed during a Bootstrap Phase. 

Furthermore, the LwM2M Client needs to 

determine – per Object Instance – who the 

“Access Control Owner” of the Object Instance 

is

DTLS-based Security: For authentication of 

communicating LwM2M entities, the LwM2M 

protocol required that all communication 

between LwM2M Clients and LwM2M Servers 

as well as LwM2M Clients and LwM2M 

Bootstrap-Servers are authenticated using 

mutual authentication.

Approved 

Standard

Guidance 

Available

Open Mobile Alliance (OMA)

What is OMA M2M?

OMA’s LightweightM2M is a 

device management protocol 

designed for sensor networks and 

the demands of a machine-tomachine (M2M) environment.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

101

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

Page 68, Section 7.3.1

DDS-Security 

specification –

2016

OMG

Data Distribution Service (DDS) Approved 

Standard

OpenFog RA Link OpenFog 

RA

Identity and Identity Protection:

Public-key ciphers can be used to establishing a 

longer-term cyber identity, e.g., for 

authentication. In public-key cryptography, keys 

come in matched pairs (public key and private 

key) for each user, entity, computer, or subject. 

The private key must be accessible only to the 

subject and represents the subject’s digital 

identity in cyberspace.

Hashes can be used to verify the integrity of 

code modules by taking the hash of the good 

known code module and using that to identify 

the module (like a unique global name). 

The private key of someone’s key pair is like 

their digital identity. Private keys must be kept 

confidential in order to protect someone’s digital 

Guidance 

Available

(has a few use 

cases)

What is Fog?

A system-level horizontal 

architecture that distributes 

resources and services of 

computing, storage, control and 

networking anywhere along the 

continuum from Cloud to Things.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

102

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

identity.

Page 50, Section 5.4.2.6

Trust Framework 

v2.5 - Updated 

June 22, 2017

OTA

strategic principles to help secure IOT devices 

and their data when shipped and throughout 

their entire life-cycle

Approved 

Standard

Online Trust Alliance (OTA) 

is now an initiative within the 

Internet Society (ISOC)

TPM Main

Part 1 

Version 1.2

1 March 2011

TCG

Authentication and Authorized Data:

Each TPM object that does not allow “public” 

access contains a 160-bit shared secret. This 

shared secret is enveloped within the object 

itself. The TPM grants use of TPM objects 

based on the presentation of the matching 160-

bits using protocols designed to provide 

protection of the shared secret. This shared 

secret is called the AuthData.

From the perspective of the TPM looking out, 

this AuthData is its sole mechanism for 

authenticating the owner of its objects, thus 

from its perspective it is authentication data.

AuthData is a 160-bit shared-secret plus highentropy random number. The assumption is the 

shared-secret and random number are mixed 

Approved 

Standard

Guidance 

Available

What is TPM?

An industry specification by the 

Trusted Computing Group (TCG) 

that enables trust in computing 

platforms in general.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

103

Identity and Access Management:

Standards that enable the use of secure, interoperable digital identities and attributes of entities to be used across security domains and 

organizational boundaries. Examples of entities include people, places, organizations, hardware devices, software applications, information 

artifacts, and physical items. Standards for identity and access management support identification, authentication, authorization, privilege 

assignment, and audit to ensure that entities have appropriate access to information, services, and assets. In addition, many identity and 

access management standards include privacy features to maintain anonymity, unlinkability, untraceability, ensure data minimization, and 

require explicit user consent when attribute information may be shared among entities.

Documents SDO Description Maturity Level

(Table 6) Notes

using SHA-1 digesting.

Page 47, Section 8

Authorization Session Setup:

The TPM provides two protocols for authorizing 

the use of entities without revealing the 

AuthData on the network on the connection to 

the TPM. First protocol is the ObjectIndependent Authorization Protocol (OIAP), the 

second is the Object Specific Authorization 

Protocol (OSAP).

Page 78, Section 13.1

Thread Specs

Feb 13 2017

Thread 

Group

Network-wide Key:

To verify the joining device and limit the effect 

of rogue devices attempting to join the Thread 

Network, the network requires the joining 

device to identify a trusted device and 

communicate solely in a point-to-point fashion 

with this trusted device. The trusted device 

policies any traffic from the joining device and 

forwards it to the commissioning device to allow 

the authentication protocol (DTLS handshake) 

to execute.

Page 29, Section 1.3.3.2

Guidance 

Available

Commercial 

Availability

Conformity 

Assessment

Market 

Acceptance

What is Thread?

Securely and reliably connects 

products around the home using a 

robust mesh network and an open 

IPv6 based protocol.

2174

2175
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

104

2176

Information Security Management Systems:

Standards provide a set of processes and corresponding security controls to establish a governance, risk, and compliance structure for information 

security for an organization, an organizational unit, or a set of processes controlled by a single organizational entity. An ISMS requires a risk-based 

approach to security that involves selecting specific security controls based on the desired risk posture of the organization and requires measuring 

effectiveness of security processes and controls. An ISMS requires a cycle of continual improvement for an organization to continue assessing 

security risks, assessing controls, and improving security to remain within risk tolerance levels by balancing security and risk tolerances.

Documents SDO Description Maturity Level

(Table 6) Notes

TR 80001-2-2

2012

AAMI

IEC

Application of risk management for IT-networks incorporating 

medical devices -- Part 2-2: Guidance for the communication of 

medical device security needs, risks and controls

Provides a framework for the disclosure of security-related 

capabilities and risks necessary for managing the risk in connecting 

medical devices to IT-networks and for the security dialog that 

surrounds the IEC 80001-1 risk management of IT-network 

connection.

AUTO11-A2

October 31, 2014 CLSI

Provides a framework for communication of information 

technology security issues between the in vitro diagnostic system 

vendor and the health care organization.

Approved 

Standard

COSO Enterprise Risk 

Management (ERM) 

Framework

COSO

Addresses the evolution of enterprise risk management and the need 

for organizations to improve their approach to managing risk to 

meet the demands of an evolving business environment.

Approved 

Standard

62443 series ISA/IEC

Industrial Automation and Control Systems (IACS) standards and 

technical reports includes security management requirements

Status for Each 

Part

13485:2016 ISO

requirements for a quality management system where an 

organization needs to demonstrate its ability to provide medical 

devices and related services that consistently meet customer and 

applicable regulatory requirements

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

105

Information Security Management Systems:

Standards provide a set of processes and corresponding security controls to establish a governance, risk, and compliance structure for information 

security for an organization, an organizational unit, or a set of processes controlled by a single organizational entity. An ISMS requires a risk-based 

approach to security that involves selecting specific security controls based on the desired risk posture of the organization and requires measuring 

effectiveness of security processes and controls. An ISMS requires a cycle of continual improvement for an organization to continue assessing 

security risks, assessing controls, and improving security to remain within risk tolerance levels by balancing security and risk tolerances.

Documents SDO Description Maturity Level

(Table 6) Notes

27799:2016 ISO

information security management in health using ISO/IEC 27002 Approved 

Standard

ISO 31000:2009 ISO

A family of standards relating to risk management codified by the 

International Organization for Standardization. The purpose of ISO 

31000 is to provide principles and generic guidelines on risk 

management.

Approved 

Standard

20243:2015 ISO/IEC

identifies secure engineering best practices, including secure 

management of the IT products, components, and their supply 

chains

Approved 

Standard

Conformance 

Testing

27001:2013 ISO/IEC

This International Standard has been prepared to provide 

requirements for establishing, implementing, maintaining and 

continually improving an information security management system. 

The information security management system preserves the 

confidentiality, integrity, and availability of information by 

applying a risk management process and gives confidence to 

interested parties that risks are adequately managed.

Approved 

Standard

Market 

Acceptance

27002:2013 ISO/IEC

This International Standard is designed for organizations to use as a 

reference for selecting controls within the process of implementing 

an Information Security Management System (ISMS) based on 

Approved 

Standard

Market 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

106

Information Security Management Systems:

Standards provide a set of processes and corresponding security controls to establish a governance, risk, and compliance structure for information 

security for an organization, an organizational unit, or a set of processes controlled by a single organizational entity. An ISMS requires a risk-based 

approach to security that involves selecting specific security controls based on the desired risk posture of the organization and requires measuring 

effectiveness of security processes and controls. An ISMS requires a cycle of continual improvement for an organization to continue assessing 

security risks, assessing controls, and improving security to remain within risk tolerance levels by balancing security and risk tolerances.

Documents SDO Description Maturity Level

(Table 6) Notes

ISO/IEC 27001 or as a guidance document for organizations 

implementing commonly accepted information security controls. 

This standard is also intended for use in developing industry- and 

organization-specific information security management guidelines, 

taking into consideration their specific information security risk 

environments(s).

Acceptance

27031:2011 ISO/IEC

guidelines for ICT readiness for business continuity Approved 

Standard

ISO/IEC TR 

27019:2013 ISO/IEC

information security management guidelines based on ISO/IEC 

27002 for process control systems specific to the energy industry Approved 

Standard

Y.4408

2015 ITU

This Recommendation specifies the capability framework for 

support of the requirements of e-health monitoring (EHM) services 

[ITU-T Y.2065]. 

The scope of this Recommendation includes: 

– EHM conceptual framework 

– EHM capability framework 

An overview of the EHM capabilities in the various EHM 

components is provided in Annex A. 

Two EHM service deployment technical scenarios are described in 

Appendix I.

Approved 

Standard

Former ITU-T 

Y.2075 

renumbered as 

ITU-T Y.4408 on 

2016-02-05 

without further 

modification and 

without being 

republished.

2177

2178
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

107

2179

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

TR 80001-2-2 

2012

AAMI

IEC

Application of risk management for IT-networks 

incorporating medical devices -- Part 2-2: 

Guidance for the communication of medical device 

security needs, risks and controls

Approved 

Standard

80001-1:2010 AAMI

IEC

Application of risk management for IT-networks 

incorporating medical devices -- Part 1: Roles, 

responsibilities and activities

Approved 

Standard

Common 

Criteria

April 2017

Common 

Criteria

Class FIA: Identification and Authentication:

Families in this class address the requirements for 

functions to establish and verify a claimed user 

identity.

Authentication Failures: this family contains 

requirements for defining values for some number 

of unsuccessful authentication attempts and TSF 

actions in cases of authentication attempt failures.

User Attribute Definition: this family defines the 

requirements for associating user security attributes 

with users as needed to support the TSF in making 

security decisions.

Specification of Secrets: this family defines 

requirements for mechanisms that enforce defined 

quality metrics on provided secrets and generate 

secrets to satisfy the defined metric.

Guidance 

Available

What is Common Criteria?

Provides a common set of 

requirements for the security 

functionality of IT products and for 

assurance measures applied to these 

IT products during a security 

evaluation.

Definitions:

TOE: a set of software, firmware 

and/or hardware possibly 

accompanied by user and 

administrator guidance 

documentation.

TSF: consists of all hardware, 

software and firmware of a TOE that 

is either directly or indirectly relied 

upon for security enforcements.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

108

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

User Authentication: this family defines the types 

of user authentication mechanisms supported by 

the TSF.

User Identification: defines the conditions under 

which users shall be required to identify 

themselves before performing any other actions 

that are to be mediated by the TSF and which 

require user identification.

Page 87, Section 12

Class FCS: Cryptographic Support:

The TSF (TOE Security Functionality) may 

employ cryptographic functionality to help satisfy 

several high-level security objectives. These 

include (but are not limited to): identification and 

authentication, non-repudiation, trusted path, 

trusted channel, and data separation. 

This class is composed of two families: FCS_CKM 

and FCS_COP.

Cryptographic Key Management (FCS_CKM):

intended to support the lifecycle of cryptographic 

keys and defines requirements for: cryptographic 

key generation, cryptographic key distribution, 

cryptographic key access and cryptographic key 

destruction.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

109

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Cryptographic Operation (FCS_COP): concerned 

with the operational use of those cryptographic 

keys. Typical cryptographic operations include 

data encryption and/or decryption, digital signature 

generation and/or verification, cryptographic 

checksum generation for integrity and/or 

verification of checksum, secure hash (message 

digest), cryptographic key encryption and/or 

decryption, and cryptographic key agreement.

Page 48, Section 10

DTSec 

Standard 

Version 1.0

May 23, 2016

DTS

Following the general framework of establishing 

security standards for information and electronic 

systems (ISO/IEC 15408), the DTSec program 

calls for the specification of security requirements 

for wireless diabetes devices. These requirements 

have the following objectives:

• To establish the general requirements for 

connected devices that meet the balanced 

needs for security and clinical application.

• To identify possible and potential threats 

related to the various components and 

interfaces of the connected devices, such as

network, storage, software, connected peer 

devices, and cryptography.

Approved 

Standard

Diabetes Technology Society (DTS)
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

110

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

• To define a set of generalized requirements 

that apply to families of similar devices

• To define a set of specific mandatory 

requirements, derived from the generalized 

requirements, corresponding to specific 

connected-diabetes device products and 

components.

• To outline additional optional functional 

requirements for manufacturers to consider 

adding to their toolbox for future 

development.

Identification of assets, threats and vulnerabilities:

DTSec leverages ISO 15408 to help developers 

identify and document, using the ISO 15408 

standardized framework, the threats applicable to 

medical device products and components.

The DTSec assurance-through-evaluation program 

helps developers identify vulnerabilities by 

augmenting the developer secure development 

lifecycle with independent vulnerability 

assessment by qualified cybersecurity test labs.

Assessment of the impact of threats and 

vulnerabilities on the device functionality and end 

user/patients:
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

111

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

DTSec helps to assess the impact of threats and 

vulnerabilities on device functionality and end 

users/patients by requiring developers to consider 

relevant threats and how they might impact safe 

clinical use.

DTSec also helps assess the impact of 

vulnerabilities discovered during the security 

evaluation program

DTSec also helps stakeholders balance the need for 

security with essential clinical performance.

Assessment of the likelihood of a threat and of a 

vulnerability being exploited:

DTSec helps to assess the likelihood of a 

vulnerability being exploited. As part of the 

vulnerability assessment requirement included in 

the Protection Profiles and Security Targets, the 

security evaluator will attempt to understand not 

only whether a vulnerability is exploitable but also 

what level of attack potential is required to exploit.

Determination of risk levels and suitable mitigation 

strategies:

DTSec helps to determine suitable mitigation 

strategies; as part of the protection profile and 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

112

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Security Target authoring process, the DWG, 

evaluators, and developers work together to ensure 

that the security threats while balancing overall 

safe clinical use.

Assessment of residual risk and risk acceptance 

criteria:

The is a central focus of the DTSec assurance 

program. During a security evaluation, the 

evaluator must determine whether residual risk are 

acceptable relative to the assurance requirements 

specified in the Security Target.

Page 6, Sections 1 to 5

HITRUST 

CSF v9

10 September 

2017

HITRUST

Alliance

Information Security Policy

Objective: To provide management direction in 

line with business objectives and relevant laws and 

regulations, demonstrate support for, and 

commitment to information security through the 

issue and maintenance of information security 

policies across the organization.

Specification: The Information Security policy 

documents shall be supported by a strategic plan 

and a security program with well-defined roles and 

responsibilities for leadership and officer roles.

Security Requirements of Information Systems:

Approved 

Standard

Under 

Revision

Guidance 

Available
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

113

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Objective: To ensure that security is an integral 

part of information systems

Specification: Statements of business requirements 

for new information systems, or enhancements to 

existing information systems shall specify the 

requirements for security controls

Implementation: The organization shall develop, 

disseminate and review/update annually:

• A formal, documented system and 

information integrity policy that addresses 

purpose, score, roles, responsibilities, 

management commitment, coordination 

among organizational entities and 

compliance

• Formal, documented procedures to 

facilitate the implementation of the system 

and information integrity policy and 

associated system and information integrity 

controls

Page 160, Category 4

RFC 7400

6LoWPANGHC

November 

IETF

Security Considerations: As usual in protocols with 

packet parsing/construction, care must be taken in 

implementations to avoid buffers overflows and 

out-of-area references during decompression.

Proposed 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

114

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

2014 In a 6LoWPAN stack, sensitive information will 

normally be protected by transport- or applicationlayer (or even IP-layer) security, which are all 

above the adaptation layer, leaving no sensitive 

information to compress at the GHC level. 

However, a 6LoWPAN deployment that entirely 

depends on Media Access Control (MAC) layer 

security may be vulnerable to attacks that exploit 

redundancy information disclosed by compression 

to recover information about secret values. This 

attack is fully mitigated by not exposing secret 

values to the adaptation layer or by not using GHC 

in deployments where this is done.

Page 10, Section 5

RFC 7959

August 2016 IETF

Block-Wise Transfer in CoAP

Security Considerations: Where access to a 

resource is only granted to clients making use of 

specific security associations, all blocks of that 

resource must be subject to the same security 

checks; it must not be possible for unprotected 

exchanges to influence blocks of an otherwise 

protected resource.

Mitigating Resource Exhaustion Attacks:

Wherever possible, severs should minimize the 

opportunities to create state for untrusted sources 

Approved

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

115

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

by using stateless approaches.

Mitigating Amplification Attacks: A CoAP server 

can reduce the amount of amplification it provides 

to an attacker by offering large resource 

representations only in relatively small blocks.

Page 33, Section 7

15408-1:2009 ISO/IEC 

general concepts and principles of IT security 

evaluation

Approved 

Standard

Conformity 

Assessment

15408-2:2008 ISO/IEC 

defines the content and presentation of the security 

functional requirements to be assessed in a security 

evaluation

Approved 

Standard

Conformity 

Assessment

15408-3:2008 ISO/IEC 

defines the assurance requirements of the 

evaluation criteria

Approved 

Standard

Conformity 

Assessment

17825:2016 ISO/IEC 

specifies the non-invasive attack mitigation test 

metrics for determining conformance to the 

requirements specified in ISO/IEC 19790 for 

Security Levels 3 and 4

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

116

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

18367:2016 ISO/IEC guidelines for cryptographic algorithms and 

security mechanisms conformance testing methods

Approved 

Standard

19790:2006 ISO/IEC 

specifies the security requirements for a 

cryptographic module utilized within a security 

system protecting sensitive information in 

computer and telecommunication systems

Approved 

Standard

19790:2015 ISO/IEC 

security requirements for cryptographic modules Approved 

Standard

Testing

Conformity 

Assessment

Market 

Acceptance

20243:2015 ISO/IEC 

identifies secure engineering best practices, 

including secure management of the IT products, 

components, and their supply chains

Approved 

Standard

Conformity 

Assessment

24759:2014 ISO/IEC 

test requirements for cryptographic modules Approved 

Standard

Testing

Conformity 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

117

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Assessment

Market 

Acceptance

CD 19896-2 ISO/IEC 

competence requirements for information security 

testers and evaluators – Part 2 Knowledge, skills, 

and effectiveness requirements for ISO/IEC 19790 

testers

Under 

Development

CD 20085-1 ISO/IEC 

test tool requirements and test tool calibration 

methods for use in testing noninvasive attack 

mitigation techniques in cryptographic modules –

Part 1: Test tools and techniques

Under 

Development

CD 20085-2 ISO/IEC 

test tool requirements and test tool calibration 

methods for use in testing noninvasive attack 

mitigation techniques in cryptographic modules –

Part 2: Test calibration methods and apparatus

Under 

Development

DIS 19896-1 ISO/IEC 

competence requirements for information security 

testers and evaluators – Part 1 Introduction, 

concepts and general requirements

Under 

Development

TR 

30104:2015 ISO/IEC guidance on physical security attacks, mitigationtechniques and security requirements

Approved 

Standard

F.748.1 ITU

Describes the requirements and common 

characteristics of the Internet of things (IoT) 

identifier for the IoT service.

Approved 

Standard

2900-1

2900-2-2 UL

Access Control, User Authentication and User 

Authorization:

Guidance 

Available

UL 2900 outlines offer testable 

cybersecurity criteria for networkconnectable products and systems to 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

118

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Feb 2016 • Product operation or management services 

which may affect or alter the security of 

the product shall require user 

authentication prior to access

• User authentication services to the product 

shall implement a session time-out or other 

appropriate mechanism to prevent 

perpetual authorization

• Services that are accessible over a remote 

interface shall require user authentication 

prior to access

• Services that are accessible over a remote 

interface shall require user authentication 

prior to access.

• Once a user is authenticated and granted 

remote access to the product, the product

shall reject and record any attempt to setup 

another remote connection using the same 

user identity.

• The storage of the authentication credential 

on the product shall not be in plaintext and 

shall be protected from unauthorized 

disclosure or modification

Doc 1, Page 8, Section 8 & Doc 2, Page 6, Section 

8

assess software vulnerabilities and 

weaknesses, minimize exploitation, 

address known malware, review 

security controls and increase 

security awareness.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

119

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

Risk Management:

When designing the product, the vendor shall 

establish and document a security risk analysis for 

the product, containing:

• An identification of all product 

functionalities and all data stored, 

processed or used by the product

• A list of all threats for the product, its 

functionalities and data

• An assessment of the impact of each 

identified threat, should it become a reality

• An assessment of the likelihood of each 

identified threat

• A determination of the resulting risk level 

of each threat, considering its impact and 

likelihood

• Risk acceptance criteria, i.e., clear criteria 

to determine whether or not a given risk 

level is acceptable.

• A determination of suitable risk controls to 

mitigate each threat with an unacceptable 

risk level

• An assessment of the residual risk level for 

each threat after application of these risk 

controls.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

120

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

• The vendor shall document a risk 

evaluation method for the possible 

presence of known (types of) 

vulnerabilities in the product

• If the vendor has allowed for the presence 

of any known vulnerabilities in the 

product, the vendor’s security risk analysis 

for the product shall contain a description 

of each accepted known vulnerability.

Doc 1, Page 12, Section 12

Cryptography:

Symmetric Algorithms: Block and Stream Ciphers

Asymmetric Algorithms and Techniques: 

• Integer Factorization Based Mechanisms 

(ISO/IEC 9796-2)

• Discrete Logarithm Based Mechanisms 

(ISO/IEC 9796-3)

• Digital Signatures with Appendix (ISO/IEC 

14888 all parts)

• Cryptographic Techniques Based on 

Elliptic Curves (ISO/IED 15946 all parts)

• Encryption Algorithms – Asymmetric 

Ciphers (ISO/IEC 18033-2)

Message authentication codes:
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

121

IT System Security Evaluation

Standards that are used to provide: security assessment of operational systems; security requirements for cryptographic modules; security 

tests for cryptographic modules; automated security checklists; and security metrics.

Documents SDO Description Maturity Level

(Table 6) Notes

• Message Authentication Codes (MACs) 

(ISO/IEC 9797-2)

• Hash Functions (ISO/IEC 10118-2/10118-

3/10118-4)

Authentication Encryption: Authenticated 

Encryption (ISO/IEC 19772 all parts)

Page 8, Section 10

2180

2181
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

122

2182

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

3GPP 5G 3GPP 5th generation mobile networks/wireless systems Under 

Development

GPRS 3GPP Link layer/Physical Layer

General Packet Radio Service

Approved 

Standard

Long-Term 

Evolution 

(LTE)

3GPP 

standard for high-speed wireless communication for mobile phones and 

data terminals

Approved 

Standard

Market 

Acceptance

80001-2-3 

2012

AAMI 

IEC

Application of risk management for IT-networks incorporating medical 

devices — Part 2-3: Guidance for wireless networks

Offers practical techniques to address the unique risk management 

requirements of operating wirelessly enabled medical devices in a safe, 

secure and effective manner.

Approved 

Standard

LIS09-A

2003 CLSI

Standard Guide for Coordination of Clinical Laboratory Services Within 

the Electronic Health Record Environment and Networked Architectures, 

LIS9AE

Approved 

Standard

Security 

Guidance 

for Early 

Adopters of 

IoT - 2015

CSA 

security guidance for the secure implementation of IoT-based systems

Approved 

Standard

Protocol 

Specificatio

n v1.1

DASH7 

Alliance 

Wireless Sensor and Actuator Network Protocol Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

123

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

24 January 

2017

Market 

Acceptance

Postmarket 

Managemen

t of

Cybersecuri

ty in 

Medical 

Devices

FDA 

security guidance for medical devices that contain software

Approved 

Standard

CLP.14 v1.1 GSMA

Network Security Principles:

The most fundamental security mechanisms provided by a 

communication network are:

• Identification and authentication of the entities involved in the 

IoT Service

• Access control to the different entities that need to be connected 

to create the IoT Service

• Data protection in order to guarantee the security (confidentiality, 

integrity, availability, authenticity) and privacy of the information 

carried by the network for the IoT Service.

Processes and mechanisms to guarantee availability of network resources 

and protect them against attack

Page 11, Section 3

Guidance 

Available

The GSMA IoT 

Security 

Guidelines are 

backed by an IoT 

Security 

Assessment 

scheme that 

enables 

companies to 

build secure IoT 

devices and 

solutions.

62591:2016 IEC Wireless Highway Addressable Remote Transducer Protocol (HART);

industrial wireless sensor networks)

Approved 

Standard

1609 IEEE Link layer/Physical Layer

Approved 

Standards

See Existing 

Standards Created 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

124

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

The IEEE 1609 Family of Standards for Wireless Access in Vehicular 

Environments (WAVE) define an architecture and a complementary, 

standardized set of services and interfaces that collectively enable secure 

vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless 

communications.

by this Working 

Group

2600.1-2009 IEEE 

a protection profile in operational Environment A Approved 

Standard

Conformity 

Assessment

2600.2-2009 IEEE 

a protection profile for hardcopy devices operational Environment B Approved 

Standard

Conformity 

Assessment

2600.3-2009 IEEE 

a protection profile for hardcopy devices in operational Environment C Approved 

Standard

Conformity 

Assessment

2600.4-2010 IEEE 

a profile for hardcopy devices operational Environment D Approved 

Standard

Conformity 

Assessment

2600-2008 IEEE hardcopy device and system security Approved 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

125

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

Standard

802.11-2016 IEEE 

(Wi-Fi)

Link Layer/Physical Layer

Overview of the services:

There are many services specified by IEEE Std 802.11.

Six of the services are used to support medium access control (MAC) 

service data unit (MSDU) delivery between STAs.

Three of the services are used to control IEEE 802.11 LAN access and 

confidentiality.

Two of the services are used to provide spectrum management

One of the services provides support for LAN applications with QoS 

requirements.

Another of the services provides support for higher layer timer 

synchronization.

One of the services is used for radio measurement.

Page 217 Section 4.5

Approved 

Standard

Market 

Acceptance

802.11ah2016 IEEE 

Link Layer/Physical Layer

uses sub-1 GHz license-exempt bands; provide extended range Wi-Fi 

networks, compared to conventional Wi-Fi networks operating in the 2.4 

GHz and 5 GHz bands.

Approved 

Standard

Market 

Acceptance

802.11ai2016 IEEE 

Link Layer/Physical Layer

This amendment defines mechanisms that provide IEEE 802.11 networks 

with fast initial link setup methods that do not degrade the security 

offered by Robust Security Network Association (RSNA) already 

Approved 

Standard

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

126

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

defined in IEEE 802.11.

802.15.4-

2015 IEEE 

Link Layer/Physical Layer

Low-Rate Wireless Personal Area Networks (LR-WPANs)

Security Overview:

The MAC sublayer is responsible for providing security services on 

specified incoming and outgoing frames when requested to do so by the 

higher layers. This standard supports the following security services:

• Data confidentiality

• Data authenticity

• Replay protection (when not using TSCH mode)

Approved 

Standard

Market 

Acceptance

802.15.6-

2012 IEEE 

Link Layer/Physical Layer

Wireless Body Area Network (WBAN)

Security Services: the security association protocols shall be based on the 

Diffie-Hellman key exchange employing the elliptic curve public key 

cryptography.

• Master key pre-shared association – a node and a hub shall each

have a secret pre-shared MK prior to running the MK pre-shared 

association protocol to activate their pre-shared MK as their 

shared MK for their creation.

Approved 

Standard

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

127

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

• Unauthenticated association – a node and a hub shall each require 

no authentication credentials such as a shared secret or human 

intervention prior to running the unauthenticated association 

protocol to generate their shared MK for their PTK creation.

• Public key hidden association – a node and a hub shall have a 

secured, secret transfer of the node’s public key to the hub, 

typically through an out-of-band channel, prior to running the 

public key hidden association protocol to generate their shared 

MK for their PTK creation.

• Password authenticated association – a node and a hub shall each 

have a secret shared password prior to running the password 

authenticated association protocol to generate their shared MK 

for their PTK creation.

• Display authenticated association – a node and a hub shall each 

have a display of a 5-digit decimal number prior to running the 

display authenticated association protocol to generate their shared 

MK for their PTK creation.

802.15.7-

2011 IEEE 

Link Layer/Physical Layer

IEEE standard for local and metropolitan area networks – part 15.7: 

Short-range wireless optical communication visible light, 2011. 

The purpose of this standard is to provide a global standard for shortrange optical wireless communication using visible light. The standard 

provides 

(i) access to several hundred THz of unlicensed spectrum;

(ii) immunity to electromagnetic interference and noninterference 

with Radio Frequency (RF) systems; 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

128

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

(iii) additional security by allowing the user to see the 

communication channel; and 

(iv) Communication augmenting and complementing existing 

services (such as illumination, display, indication, decoration, 

etc.) from visible-light infrastructures.

6LoWPAN IETF 

(IPv6 over Low-power Wireless Personal Area Networks)

A set of standards defined by the IETF and based on IEEE 802.15.4. The 

base standard is IETF RFC4944.

6LoWPan standards enable the efficient use of IPv6 over low-power, 

low-rate wireless networks on simple embedded devices through an 

adaptation layer and the optimization of related protocols.

Approved 

Standard

 

draft-ietftls-tls13-22 IETF 

Transport Layer Security (TLS) Protocol Version 1.3

Under 

Development

RFC 2460-

1998 IETF Network Layer core specification that enhancements IPv4. Approved Standard

RFC 4347-

2006 IETF Datagram Transport Layer Security (TLS) Protocol Version 1.2 Approved Standard

RFC 6347

January 

2012

IETF

Specifies version 1.2 of the Datagram Transport Layer Security (DTLS) 

protocol.

Security Considerations: The primary additional security considerations 

raised by DTLS is that of denial of service. DTLS includes a cookie 

exchange designed to protect against denial of service. However, 

Approved 

Standard

Guidance 

Available
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

129

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

implementation which do not use this cookie exchange are still 

vulnerable to DoS. In particular, DTLS servers which do not use this 

cookie exchange may be used as attack amplifiers even if they 

themselves are not experiencing DoS. Therefore, DTLS servers should 

use the cookie exchange unless there is good reason to believe that 

amplification is not a threat in their environment. Clients must be 

prepared to do a cookie exchange with every handshake.

Commercial 

Availability

Market 

Acceptance

RFC 7252

June 2014 IETF

Constrained Application Protocol (CoAP)

Parsing the Protocol and Processing URIs: CoAP attempts to narrow the 

opportunities for introducing network-facing application vulnerabilities 

by: reducing parser complexity, giving the entire range of encodable 

values a meaning where possible, and by aggressively reducing 

complexity that is often cause by unnecessary choice between multiple 

representations that mean the same thing.

Risk of Amplification: An attacker might use CoAP nodes to turn a small 

attack packet into a larger attack packet, an approach known as 

amplification. There is therefore a danger that CoAP nodes could become 

implicated in denial-of-service attacks by using the amplifying properties 

of the protocol. As a mitigating factor, many constrained networks will 

only be able to generate a small amount of traffic, which may make 

CoAP nodes less attractive for this attack. Therefore, large amplification 

factors should not be provided in the response if the request is not 

authenticated.

IP Address Spoofing Attacks: Due to the lack of handshake in UDP, a 

Approved 

Standard

Guidance 

Available

Commercial 

Availability

What is CoAP?

CoAP is a 

specialized web 

transfer protocol 

for use with 

constrained nodes 

and constrained 

networks in the 

Internet of 

Things.

The protocol is 

designed for 

machine-tomachine (M2M) 

applications such 

as smart energy 

and building 

automation.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

130

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

rogue endpoint that is free to read and write messages carried by the 

constrained network may easily attack a single endpoint, a group of 

endpoints, as well as a whole network. Response spoofing by off-path 

attackers can be detected and mitigated even without transport later 

security by choosing a nontrivial, randomized token in the request. 

Page 80, Section 11

Note: Like MQTT, CoAP does not provide these services but rather 

recommends another standard D-TLS.

Securing CoAP: The device will be in one of the four security modes:

NoSec: There is no protocol-level security (DTLS is disabled)

PreSharedKey: DTLS is enabled, there is a list of pre-shared keys, and 

each key includes a list of which nodes it can be used to communicate 

with.

RawPublicKey: DTLS is enabled and the device has an asymmetric key 

pair without a certificate (a raw public key) that is validated using an outof-band mechanism.

Certificate: DTLS is enabled and the device has an asymmetric key pair 

with an X.509 certificate that binds it to its subject and is signed by some 

common trust root.

Page 71, Section 9.1.3.1
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

131

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

State of the 

Art and 

Challenges 

for the 

Internet of 

Things

draft-irtft2trg-iotseccons-02

March 31,

2017

IETF 

Network Security:

SecProf_1: 

• Network key creating an industry security domain at L2 ensuring 

authentication and freshness of exchanged data

• Inter-domain authentication/secure handoff

• Secure routing needed at L3

• Secure multicast requires origin authentication

• 6LBR (HTTP-CoAP proxy) requires verification of forwarded 

messages and messages leaving or entering the 6LoWPAN/CoAP 

network.

Sec_Prof_3:

• Network key creating an industry security domain at L2 ensuring 

authentication and freshness of exchanged data

• Secure routing needed (integrity & availability) at L3 within 

6LoWPAN/CoAP

• Secure multicast requires origin authentication

SecProf_4:

• Network key creating an industry security domain at L2 ensuring 

authentication and freshness of exchanged data

• Inter-domain authentication/secure handoff

• Secure routing needed at L3

• Secure multicast requires origin authentication

• 6LBR (HTTP-CoAP proxy) requires verification of forwarded 

messages and messages leaving or entering the 6LoWPAN/CoAP 

network.

Page 31 Section 6.5

Under 

Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

132

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

Insteon low-cost devices to be networked together using the powerline, radio 

frequency (RF), or both

19079:2016 ISO 

6LoWPAN/IPv6 Security module:

Communication security must ensure confidentiality, integrity and 

authentication between two peers interconnected through the Internet.

The IT-S security module shall carry out the following actions:

• Communicates with the security entity through the SN-SAP 

interface

• Communicates with other modules in the IoT MSE functional 

block

• Enables the security protocols for the required security services

• Reports available 6LoWPAN security capabilities to the security 

entity through the SN-SAP

Approved 

Standard

180003:

2010 ISO/IEC Defines the RFID communication used by Near Field Communication (NFC) devices.

Approved 

Standard

X.1362 ITU

Recommendation ITU-T X.1362 : Simple encryption procedure for 

Internet of things (IoT) environments

Specifies encryption with associated mask data (EAMD) for the Internet 

of things devices. It describes EAMD and how it provides a set of 

security services for traffic using EADM.

Approved 

Standard

LoRaWAN LoRa 

Alliance

Link layer/Physical Layer

LoRaWAN is a wireless protocol for IoT applications that is available in 

integrated circuits. The protocol specification is built on top of the LoRa 

technology developed by the LoRa Alliance. It uses unlicensed radio 

Approved 

Standard

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

133

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

spectrum in the Industrial, Scientific and Medical (ISM) bands to enable 

low power, wide area, bi-directionally secure communication between 

remote sensors and gateways connected to the network. 

MQTT Link

Dec 2015 MQTT

Note: References to other protocols. 

Authentication of Clients by the Server: Implementations can choose 

how to make use of the content of these fields. They may provide their 

own authentication mechanism, use an external authentication such as 

LDAP or OAuth tokens, or leverage operating system authentication 

mechanisms.

When TLS is used: SSL Certificates sent from the Client can be used by 

the Server to authenticate the Client.

When VPN is used: between the Clients and Servers, VPN can provide 

confidence that data is only being received from authorized Clients.

Authentication of the Server by the Client: The MQTT protocol is not 

trust symmetrical; it provides no mechanism for the Client to 

authenticate the Server,

When TLS is used: SSL Certificates sent from the Server can be used by 

the Client to authenticate the Server.

When VPN is used: between Clients and Servers, VPN can provide 

confidence that Clients are connecting to the intended Server.

Page 61, Sections 5.4.1 & 5.4.3

Guidance 

Available

Approved 

Standard

What is MQTT?

MQTT is a 

machine-tomachine (M2M)/” 

Internet of 

Things” 

connectivity 

protocol.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

134

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

Note: MQTT does not provide any of these services. The standard 

recommends that other standards be applied, e.g., TLS.

Integrity of Application Messages and Control Packets:

Application Messages: applications can independently include hash 

values in the messages. This can provide integrity of the contents of 

Publish Control Packets across the network and at rest.

When TLS is used: provides hash algorithms to verify the integrity of 

data sent over the network. 

When VPN is used: VPNs connecting Clients and Servers can provide 

integrity of data across the section of the network covered by a VPN.

Privacy of Application Messages and Control Packets: 

Application Messages: an application might independently encrypt the 

contents of its messages. This could provide privacy of the Application 

Message both over the network and at rest. 

When TLS is used: can provide encryption of data sent over the network. 

When VPN is used: to connect Clients and Servers, VPNs can provide 

privacy of data across the section of the network covered by a VPN.

Non-repudiation of message transmission: Application designers might 

need to consider appropriate strategies to achieve to end non-repudiation.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

135

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

Page 62 Section 5.4.4, 5.4.5. & 5.4.6

OCF 1.1.1 

Security 

Specificatio

n – 2017

OCF

defines security objectives, philosophy, resources and mechanism that 

impacts base layers of the Core specification Approved

Standard

OCF SPEC 

1.0

June 28, 

2017

OCF

Security Theory of Operation:

1. The OIC Client establishes a network connection to the OIC Server. 

The connectivity abstraction layer ensures the devices are able to connect 

despite differences in connectivity options.

2. The OIC Client and OIC Server establishes a secure end-to-end 

channel that protects the exchange of OIC messages and resources 

passed between OIC devices. Encryption keys are stored securely in the 

local platform.

3. ACL permission is applied to the requested resource where the 

decision to allow or deny access is enforced by the OIC Server’s Secure 

Resource manager.

OIC resource protection includes protection of data both while at rest and 

during transit

Page 14, Section 5

Approved 

Standard

Guidance

Available

Reference 

Implementation

The Open 

Interconnect 

Consortium 

(OIC) has been 

re-launched in 

early 2016 as the 

Open 

Connectivity 

Foundation 

(OCF)

The goal for the 

OCF security 

architecture is to 

protect OCF 

resources and all 

aspects of 

Hardware and 

Software that are 

used to support 

the protection of 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

136

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

OCF resource.

OMA 

Device 

Managemen

t Security –

May 2016

OMA

Open Mobile Alliance (OMA) 

specifies protocols and mechanisms to achieve the management of 

mobile devices, services access and software on connected devices for 

mobile networks and the Internet of Things (IoT).

describes requirements in general; provides description of transport layer 

security

application layer security, etc.; and describes security mechanisms for 

integrity, confidentiality and authentication

Approved 

Standard

OMA M2M OMA 

Lightweight Machine to Machine Technical Specification

Approved Version 1.0 – 08 Feb 2017

DTLS: CoAP is secured using the DTLS protocol which is based on 

TLS. DTLS is a communication security solution for datagram based 

protocols (such as UDP). It provides a secure handshake with session key 

generation, mutual authentication, data integrity and confidentiality.

Page 58, Section 7.1.2

Approved 

Stanard

Guidance 

Available

What is OMA 

M2M?

OMA’s 

LightweightM2M 

is a device 

management 

protocol designed 

for sensor 

networks and the 

demands of a 

machine-tomachine (M2M) 

environment.

OpenFog 

RA 

OpenFog 

Consortium

Network Based Security Threats and Mitigation:

The fog node needs to be protected from various network-based security 

threats, which may include:

Guidance 

Available

(has a few use 

What is Fog?

A system-level 

horizontal 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

137

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

• Denial of Service attacks

• Intrusion

• DNS spoofing

• ARP spoofing or poisoning

• Buffer overflows

Page 64, Section 5.5.1.4

cases) architecture that 

distributes 

resources and 

services of 

computing, 

storage, control 

and networking 

anywhere along 

the continuum 

from Cloud to 

Things.

SigFox

Link Layer/Physical Layer 

Dedicated low-power, low-bandwidth proprietary cellular network 

optimized for short data transmissions common with IoT devices. 

Specializing in industrial networking, e.g., home security systems.

Doc 1: RFC 

4919

August 

2007

Doc 2:

Thread 

Specs

Feb 13 2017

Thread 

Group

TLS:

A TLS (Transport Layer Security) handshake is used for EC-JPAKE, 

which can be used in both TLS and DTLS.

Doc 2, Page 28, Section 1.3.3.1

6LoWPAN:

IPv6 over LoWPAN (6LoWPAN) applications often require 

confidentiality and integrity protection. This can be provided at the 

application, transport, network, and/or at the link layer (i.e., within the 

6LoWPAN set of specifications).

Guidance 

Available

Commercial 

Availability

Conformity 

Assessment

Market 

Acceptance

What is Thread?

Securely and 

reliably connects 

products around 

the home using a 

robust mesh 

network and an 

open IPv6 based 

protocol.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

138

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

IEEE 802.15.4:

Link layer security is used because most IEEE 802.15.4 devices already 

have support for AES link-layer security. ECB, CBC, OFB, and CFB 

provide only confidentiality for encrypting longer messages, CCM* 

mode is designed to ensure both confidentiality and message integrity.

Doc 1, Page 9, Section 6

TIA/EIA95-B

(March 

1999)

TIA/EIA

code division multiple access modulation for digital radio voice and data

Approved 

Standard

XMPP

XSF

Extensible Messaging and Presence Protocol (XMPP)

XMPP Standards Foundation

XMPP is designed for real-time instantaneous messaging applications 

and uses a federated network of XMPP servers as message brokers to 

allow communication between clients. Servers provide each client with 

an authenticated identity and clients are authenticated by the servers 

when they connect. 

The XMPP Standards Foundation (XSF) publishes a set of extensions 

which are openly reviewed and discussed within the forum and free for 

anybody to use. These extensions are called XMPP Extension Protocols 

(XEPS). There are several XEPs to support XMPP’s role in IoT, e.g., 

XMPP-IoT.

Approved 

Standards

Under 

Development

The core 

specifications for 

XMPP are 

developed at the 

Internet 

Engineering Task 

Force (IETF) -

see RFC 

6120, RFC 6121, 

and RFC 

7622 (along with 

a WebSocket 

binding defined 

in RFC 7395).

ISO/IEC/IEEE 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

139

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

P21451-1-4 

XMPP INFC WG

is the IEEE 

initiative tying the 

XMPP-IoT 

initiative into the 

IEEE standards 

structure.

ZigBee Pro 

Link

March 2014

ZigBee IP 

Link

Zigbee 

Alliance

ZigBee Pro:

Security Architecture: the ZigBee security architecture includes security 

mechanisms at two layers of the protocol stack. The NWK and APS 

layers are responsible for the secure transport of their respective frames. 

Furthermore, the APS sublayer provides services for the establishment 

and maintenance of security relationships. The ZigBee Device Object 

(ZDO) manages the security policies and the security configuration of a 

device.

Page 401, Section 4.2.1.4

ZigBee IP:

ZigBee IP offers extensive security features, including PANA/EAP based 

network authentication and admission control, network re-keying, AES128-CCM based layer 2 encryption, and TLS application layer 

authentication and encryption.

ZigBee IP is the first open standards-based IPv6 specification for 

wireless sensor networks. The ZigBee alliance made a significant 

investment to bring IPv6 network protocols to IEEE 802.15.4 wireless 

Approved 

Standard

Guidance 

Available

Commercial 

Availability

Market 

Acceptance
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

140

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

mesh networks. 

The ZigBee IP specification offers a scalable architecture with end-toend IPv6 networking based on standard Internet protocols, such as 

6LowPAN, IPv6, PANA, RPL, TCP, TLS and UDP to a create costeffective and energy-efficient wireless mesh network.

The ZigBee specification enhances the IEEE 802.15.4 standard by 

adding network and security layers and an application framework. From 

this foundation, Alliance developed standards can be used to create a 

multi-vendor interoperable solutions. For custom application where 

ZigBee 

Application 

Standards 

Link

Zigbee 

Alliance

Building Automation:

Secures Building Automation networks by the use of AES 128 

encryption, keys, and device authentication. 

Encryption secures access to critical building management information 

from eavesdropping.

Health Care:

AES 128 encryption secures personal information.

Regional regulatory compliance simplifies implementation.

Home Automation:

Easily add devices to create an integrated smart home security system.

Built-in security ensures integrity of smart home.

Input Light Link:

AES 128 encryption used to protect lighting network against 

Guidance 

Available

Commercial 

Availability

What is ZigBee?

A specification 

for a suite of 

high-level 

communication 

protocols used to 

create personal 

area networks 

built from small, 

low-power digital 

radios
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

141

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

unauthorized use.

Device authentications secures networks from neighboring networks.

Uses selected Zigbee channels to maximize performance and coexistence 

with other wireless devices in homes.

Conformance guaranteed with Zigbee Certified testing conducted by 

independent test facilities.

Retail Services:

Integrated security.

AES 128 encryption secures personal information.

Server-driven – no personal data on handheld employee or consumer 

devices.

Smart Energy:

Support for consumer-only, utility-only or shared networks.

Automatic, secure network registration using either pre-installed keys or 

standard public-key cryptography methods.

Support for ECC public key infrastructure for authentication and 

mobility.

Data encryption.

Z-Wave 

Link

August 

2016

Z-Wave

Tier Z-Wave security:

Z-WaveSec. – Z-Wave Security Command Class v2:

Target: nodes exchanging non-personal data

By employing the AES128 block cipher technology, Z-Wave is protected 

against modification, fabrication, and replay attacks.

Authentication: 128-bit authentication key with a 64-bit MAC.

Guidance 

Available

Commercial 

Availability

What is Z-wave?

A wireless 

communications 

protocol used 

primarily for 

home automation.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

142

Network Security:

Standards that provide security requirements and guidelines on processes and methods for the secure management, operation and use of information, 

information networks, and their inter-connections. Such standards-based technologies can help to assure the confidentiality and integrity of data in 

motion, assure electronic commerce, and provide for a robust, secure and stable network and Internet.

Documents SDO Description Maturity Level

(Table 6) Notes

Confidentiality: encryption with a 128-bit encryption key.

Single Network Key, In-band initial symmetrical key exchange

Z-WaveSecIP – Hybrid Security Command Class v1 and Security Link 

Key Extension:

Target: nodes exchanging personal data

Confidentiality, Authentication, Fabrication robust – AES128 based.

Asymmetric key exchange, Network + Link Keys

Certifications installed in nodes.

Z-WaveSecSmartCard – Prepayment Encapsulation Command Class

Target: nodes exchanging payment data

Allows Smartcard payment & Security information to be exchanged via 

Z-Wave

Page 181, Section 7.2.3

2183

2184
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

143

2185

Security Automation and Continuous Monitoring (SACM): 

Standards that describe protocols and data formats that enable the ongoing, automated collection, monitoring, verification, and maintenance 

of software, system, and network security configurations, and provide greater awareness of vulnerabilities and threats to support 

organizational risk management decisions. Automation protocols also include standards for machine-readable vulnerability identification and 

metrics, platform and asset identification, actionable threat information and policy triggers for actions to respond to threats and policy 

violations. Automated activities would include a Security Operation Center (SOC) to ensure autonomous and continuing monitoring and 

evolution of the security state of assets based upon prescribed events 

Documents SDO Description Maturity Level

(Table 6) Notes

Remote Provisioning 

Architecture for 

Embedded UICC 

Technical Specification –

2016

GSMA 

provides a technical description of the GSMA’s ‘Remote 

Provisioning Architecture for Embedded Universal Integrated 

Circuit Card’ Approved 

Standard

Remote Provisioning 

Architecture for 

Embedded UICC Test 

Specification - 2015

GSMA

provides a technical description of the ‘over the air’ remote 

provisioning mechanism for machine-to-machine devices Approved 

Standard

HITRUST CSF v9 

10 September 2017

HITRUST 

Alliance

Monitoring:

Objective: ensure information security events are monitored 

and recorded to detect unauthorized information processing 

activities in compliance with relevant legal requirements.

Audit Logging:

Specification: Audit logs recording user activities, exceptions, 

and information security events shall be produced and kept for 

an agreed period to assist in future investigations and access 

control monitoring.

Implementation: audit logs shall include:

• A unique user identifier

• A unique data subject identifier

Approved 

Standard

Under 

Revision

Guidance 

Available
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

144

Security Automation and Continuous Monitoring (SACM): 

Standards that describe protocols and data formats that enable the ongoing, automated collection, monitoring, verification, and maintenance 

of software, system, and network security configurations, and provide greater awareness of vulnerabilities and threats to support 

organizational risk management decisions. Automation protocols also include standards for machine-readable vulnerability identification and 

metrics, platform and asset identification, actionable threat information and policy triggers for actions to respond to threats and policy 

violations. Automated activities would include a Security Operation Center (SOC) to ensure autonomous and continuing monitoring and 

evolution of the security state of assets based upon prescribed events 

Documents SDO Description Maturity Level

(Table 6) Notes

• The function performed by the user

• The time and date that the function was performed.

Monitoring System Use:

Specifications: procedures for monitoring use of information 

processing systems and facilities shall be established to check 

for use and effectiveness of implemented controls. The results 

of the monitoring activities shall be reviewed regularly.

Implementation: items that shall be monitored include:

• Authorized access

• Unauthorized access attempts

Administrator and Operator Logs:

Specification: System administrator and system operator 

activities shall be logged and regularly reviewed.

Clock Synchronization:

Specification: The clocks of all relevant information 

processing systems within the organization or security domain 

shall be synchronized with an agreed accurate time source to 

support tracing and reconstitution of activity timelines.

Page 414, Section 9.10

TR 62443-2-3:2015 IEC describes requirements for asset owners and industrial Approved 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

145

Security Automation and Continuous Monitoring (SACM): 

Standards that describe protocols and data formats that enable the ongoing, automated collection, monitoring, verification, and maintenance 

of software, system, and network security configurations, and provide greater awareness of vulnerabilities and threats to support 

organizational risk management decisions. Automation protocols also include standards for machine-readable vulnerability identification and 

metrics, platform and asset identification, actionable threat information and policy triggers for actions to respond to threats and policy 

violations. Automated activities would include a Security Operation Center (SOC) to ensure autonomous and continuing monitoring and 

evolution of the security state of assets based upon prescribed events 

Documents SDO Description Maturity Level

(Table 6) Notes

automation and control system (IACS) product suppliers that 

have established and are now maintaining an IACS patch 

management program

Standard

Definition of the ROLIE 

Software Descriptor 

Extension

IETF 

This document extends the Resource-Oriented Lightweight 

Information Exchange (ROLIE) core to add the information 

type category and related requirements needed to support 

Software Record and Software Inventory use cases. The 

’software-descriptor’ information type is defined as a ROLIE 

extension. Additional supporting requirements are also defined 

that describe the use of specific formats and link relations 

pertaining to the new information type.

Under 

Development

IETF RFC 7632 IETF

Endpoint Security Posture Assessment: Enterprise Use Cases

his memo documents a sampling of use cases for securely 

aggregating configuration and operational data and evaluating 

that data to determine an organization’s security posture. From 

these operational use cases, we can derive common functional 

capabilities and requirements to guide development of vendorneutral, interoperable standards for aggregating and evaluating 

data relevant to security posture.

Under 

Development

Submitted to 

IESG for 

Publication

Security Automation and 

Continuous Monitoring 

(SACM) Documents

IETF 

A set of standards to enable assessment of endpoint posture.

A set of standards for interacting with repositories of content 

related to assessment of endpoint posture.

Under 

Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

146

Security Automation and Continuous Monitoring (SACM): 

Standards that describe protocols and data formats that enable the ongoing, automated collection, monitoring, verification, and maintenance 

of software, system, and network security configurations, and provide greater awareness of vulnerabilities and threats to support 

organizational risk management decisions. Automation protocols also include standards for machine-readable vulnerability identification and 

metrics, platform and asset identification, actionable threat information and policy triggers for actions to respond to threats and policy 

violations. Automated activities would include a Security Operation Center (SOC) to ensure autonomous and continuing monitoring and 

evolution of the security state of assets based upon prescribed events 

Documents SDO Description Maturity Level

(Table 6) Notes

Includes:

RFC 7632, Endpoint Security Posture Assessment: Enterprise 

Use Cases 2015-09

RFC 8248 Security Automation and Continuous Monitoring 

(SACM) Requirements 2017-09 

Approved 

Standard

IIC Industrial Internet of 

Things, Volume G4: 

Security Framework -

2016

IIC 

security framework identifies and explains how risks 

associated with security and privacy

threats may be identified, evaluated and mitigated using 

technologies and processes

Approved 

Standard

Dependability Assurance 

Framework for SafetySensitive Consumer 

Devices Specification 

Version 1.0

February 2016

OMG

Defines a metamodel for representing structured assurance 

cases. An Assurance Case is a set of auditable claims, 

arguments, and evidence created to support the claim that a 

defined system/service will satisfy the particular requirements. 

An Assurance Case is a document that facilitates information 

exchange between various system stakeholder such as 

suppliers and acquirers, and between the operator and 

regulator, where the knowledge related to the safety and 

security of the system is communicated in a clear and 

defendable way. Each assurance case should communicate the 

scope of the system, the operational context, the claims, the 

safety and/or security arguments, along with the corresponding 

evidence.

Approved 

Standard

2186

2187
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

147

2188

Software Assurance:

Standards that describe requirements and guidance for significantly decreasing the likelihood of software having vulnerabilities, either intentionally 

designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner. This 

includes custom software, commercial off-the-shelf software, firmware, operating systems, utilities, databases, applications and applets for the Web, 

software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, etc. 

Documents SDO Description Maturity Level

(Table 6) Notes

TIR 80001-2-4 

2012

AAMI 

IEC

Application of risk management for IT-networks incorporating 

medical devices -- Part 2-4: General implementation guidance for 

Healthcare Delivery Organizations

Approved 

Standard

TIR36:2007 AAMI

Validation of software for regulated processes

Applies to any software used to automate device design, testing, 

component acceptance, manufacturing, labeling, packaging, 

distribution, and complaint handling or to automate any other aspect 

of the quality system as defined by the Quality System Regulation (21 

CFR 820). In addition, it applies to software used to create, modify, 

and maintain electronic records and to manage electronic signatures 

that are subject to the validation requirements (21 CFR 11).

Approved 

Standard

TIR45:2012 AAMI

Guidance on the use of agile practices in the development of medical 

device software

Provides recommendations for complying with international standards 

and U.S. Food and Drug Administration (FDA) guidance documents 

when using agile practices to develop medical device software.

Approved 

Standard

TIR80001-2-5 

2014

AAMI 

IEC

Application of risk management for IT-networks incorporating 

medical devices - Part 2-5: Application guidance - Guidance on 

distributed alarm systems

Approved 

Standard

TR 80001-2-6

2014

AAMI

ISO

Application of risk management for IT-networks incorporating 

medical devices -- Part 2-6: Application guidance -- Guidance for 

responsibility agreements

Provides guidance on implementing RESPONSIBILITY 

AGREEMENTS, which are described in IEC 80001-1 as used to 

establish the roles and responsibilities among the stakeholders 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

148

Software Assurance:

Standards that describe requirements and guidance for significantly decreasing the likelihood of software having vulnerabilities, either intentionally 

designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner. This 

includes custom software, commercial off-the-shelf software, firmware, operating systems, utilities, databases, applications and applets for the Web, 

software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, etc. 

Documents SDO Description Maturity Level

(Table 6) Notes

engaged in the incorporation of a MEDICAL DEVICE into an ITNETWORK in order to support compliance to IEC 80001-1.

AUTO13

February 18, 

2003

CLSI

Identifies important factors that designers and laboratory managers 

should consider when developing new software-driven systems and 

selecting software user interfaces. Also included are simple rules to 

help prepare validation protocols for assessing the functionality and 

dependability of software.

Approved 

Standard

62304: 2006 IEC 

medical device software – software life cycle process, including 

Software Risk Management Process

This standard defines the life cycle requirements for medical device 

software. The set of processes, activities, and tasks described in this 

standard establishes a common framework for medical device 

software life cycle processes

Section 1.1

Approved 

Standard

82304-1:2016 IEC 

the safety and security of health software products designed to operate 

on general computing platforms and intended to be placed on the 

market without dedicated hardware

Uses the life cycle of IEC 62304 while giving eases in verification 

activities. 

This standard is for health software that runs on general purpose 

hardware that may be acquired and controlled by the customer

Approved 

Standard

TR 80002-

1:2009 IEC

Guidance on the application of ISO 14971 to medical device software

Aimed at risk management practitioners who need to perform risk 

management when software is included in the medical device/system, 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

149

Software Assurance:

Standards that describe requirements and guidance for significantly decreasing the likelihood of software having vulnerabilities, either intentionally 

designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner. This 

includes custom software, commercial off-the-shelf software, firmware, operating systems, utilities, databases, applications and applets for the Web, 

software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, etc. 

Documents SDO Description Maturity Level

(Table 6) Notes

and at software engineers who need to understand how to fulfil the 

requirements for risk management addressed in ISO 14971.

27036-1:2014 ISO/ IEC information security for supplier relationships (Part 1: Overview and 

concepts)

Approved 

Standard

27036-2:2014 ISO/ IEC information security for supplier relationships (Part 2: Common 

requirements);

Approved 

Standard

27036-3: 2013 ISO/ IEC information security for supplier relationships (Part 3: Guidelines for 

ICT supply chain security)

Approved 

Standard

19770-2:2015 ISO/IEC software identification (SWID) tagging Approved 

Standard

20243:2015 ISO/IEC 

identifies secure engineering best practices, including secure 

management of the IT products, components, and their supply chains

Approved 

Standard

Conformity 

Assessment

27035-1:2016 ISO/IEC guidance on information security incident management for large and 

medium-sized organizations

Approved 

Standard

29147:2014 ISO/IEC Information technology – Security techniques – Vulnerability 

disclosure.

Approved 

Standard

30111:2013 ISO/IEC guidelines for how to process and resolve potential vulnerability 

information in a product or online service

Approved 

Standard

90003:2014 ISO/IEC 

Provides guidance for organizations in the application of ISO 

9001:2008 to the acquisition, supply, development, operation and 

maintenance of computer software and related support services.

Approved 

Standard

Dependability 

Assurance OMG Provides a new system assurance methodology for the dependability argumentation for consumer devices, which is achieved by integrating 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

150

Software Assurance:

Standards that describe requirements and guidance for significantly decreasing the likelihood of software having vulnerabilities, either intentionally 

designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner. This 

includes custom software, commercial off-the-shelf software, firmware, operating systems, utilities, databases, applications and applets for the Web, 

software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, etc. 

Documents SDO Description Maturity Level

(Table 6) Notes

Framework for 

Safety-Sensitive 

Consumer 

Devices 

Specification 

Version 1.0

February 2016

conventional system assurance approaches such as risk analysis and 

assessments with a new way of approaching unique characteristics of 

consumer devices. The scope of this specification supports the 

objectives of the integration, and includes the dependability case for 

argumentation, as well as the dependability

development process to be newly defined. The focus is to include the 

dependability argumentation particularly for consumer devices. In the 

future, it may be desirable to introduce additional argumentation 

methodology for other systems such as avionics or railways. However, 

they are outside of the scope for the current effort as the authors are 

not experts in other systems rather than consumer devices.

AS5553B -

2016

SAE 

International

counterfeit electrical, electronic, and electromechanical (EEE) parts; 

avoidance, detection, mitigation, and disposition

Approved 

Standard

AS6462A -

2014

SAE 

International

verification criteria for fraudulent/counterfeit electronic parts; 

avoidance, detection, mitigation, and disposition

Approved 

Standard

UL 2900-1

2017-07-05

UL

Product Management: The product shall be designed and implemented 

such that it is possible to perform an update of the product’s software, 

and to roll back an update

Page 11, Section 11

Guidance 

Available

UL 2900 outlines 

offer testable 

cybersecurity 

criteria for 

networkconnectable 

products and 

systems to assess 

software 

vulnerabilities 

and weaknesses, 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

151

Software Assurance:

Standards that describe requirements and guidance for significantly decreasing the likelihood of software having vulnerabilities, either intentionally 

designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner. This 

includes custom software, commercial off-the-shelf software, firmware, operating systems, utilities, databases, applications and applets for the Web, 

software/platform/infrastructure as a service (SaaS, PaaS, IaaS), mobile and consumer devices, etc. 

Documents SDO Description Maturity Level

(Table 6) Notes

minimize 

exploitation, 

address known 

malware, review 

security controls 

and increase 

security 

awareness.

UL 2900-2-1 UL

Security evaluation standard applies to the testing of network 

connected components of healthcare systems. It applies to, but is not 

limited to, the following key components:

a) Medical devices;

b) Accessories to medical devices;

c) Medical device data systems;

d) In vitro diagnostic devices;

e) Health information technology; and

f) Wellness devices.

2189

2190
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

152

2191

Supply Chain Risk Management (SCRM):

Standards that provide the confidence that organizations will produce and deliver information technology products or services that perform 

as required and mitigate supply chain-related risks, such as the insertion of counterfeits and malicious software, unauthorized production, 

tampering, theft, and poor quality products and services. IT SCRM standardization requirements include methodologies and processes that 

enable an organization’s increased visibility into, and understanding of, how technology that they acquire and manage is developed, integrated, 

and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products 

and services. IT SCRM standardization lies at the intersection of cybersecurity and supply chain management and provides a mix of mitigation 

strategies from both disciplines for a targeted approach to managing IT supply chain risks. 

Documents SDO Description

Maturity 

Level

(Table 6)

Notes

TIR57:2016 AAMI 

Association for the Advancement of Medical 

Instrumentation (AAMI)

This TIR provides guidance for addressing information 

security within the risk management framework 

defined by ANSI/AAMI/ISO 14971.

This guidance is intended to assist manufacturers and 

other users of the standard in the following:

• Identifying threats, vulnerabilities, and assets 

associated with medical devices

• Estimating and evaluating associated security 

risks

• Controlling security risks

• Monitoring effectiveness of the risk controls

Approved 

Standard

28000:2007 ISO

Specification for security management systems for the 

supply chain

Specifies the requirements for a security management 

system, including those aspects critical to security 

assurance of the supply chain. Security management is 

linked to many other aspects of business management. 

Aspects include all activities controlled or influenced 

by organizations that affect supply chain security. 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

153

Supply Chain Risk Management (SCRM):

Standards that provide the confidence that organizations will produce and deliver information technology products or services that perform 

as required and mitigate supply chain-related risks, such as the insertion of counterfeits and malicious software, unauthorized production, 

tampering, theft, and poor quality products and services. IT SCRM standardization requirements include methodologies and processes that 

enable an organization’s increased visibility into, and understanding of, how technology that they acquire and manage is developed, integrated, 

and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products 

and services. IT SCRM standardization lies at the intersection of cybersecurity and supply chain management and provides a mix of mitigation 

strategies from both disciplines for a targeted approach to managing IT supply chain risks. 

Documents SDO Description

Maturity 

Level

(Table 6)

Notes

These other aspects should be considered directly, 

where and when they have an impact on security 

management, including transporting these goods along 

the supply chain.

20243:2015 ISO/IEC 

Information Technology -- Open Trusted Technology 

Provider Standard (O-TTPS)

Identifies secure engineering best practices, including 

secure management of the IT products, components, 

and their supply chains

Approved 

Standard

Conformity 

Assessment

27036-

1:2014 ISO/IEC

Information technology – Security techniques –

Information security for supplier relationships – Part 

1: Overview and concepts

Provides an overview of the guidance intended to 

assist organizations in securing their information and 

information systems within the context of supplier 

relationships. It also introduces concepts that are 

described in detail in the other parts of ISO/IEC 27036. 

ISO/IEC 27036-1:2014 addresses perspectives of both 

acquirers and suppliers

Approved 

Standard

27036-

2:2014 ISO/IEC

Information technology – Security techniques –

Information security for supplier relationships – Part 

2: Requirements

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

154

Supply Chain Risk Management (SCRM):

Standards that provide the confidence that organizations will produce and deliver information technology products or services that perform 

as required and mitigate supply chain-related risks, such as the insertion of counterfeits and malicious software, unauthorized production, 

tampering, theft, and poor quality products and services. IT SCRM standardization requirements include methodologies and processes that 

enable an organization’s increased visibility into, and understanding of, how technology that they acquire and manage is developed, integrated, 

and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products 

and services. IT SCRM standardization lies at the intersection of cybersecurity and supply chain management and provides a mix of mitigation 

strategies from both disciplines for a targeted approach to managing IT supply chain risks. 

Documents SDO Description

Maturity 

Level

(Table 6)

Notes

Specifies fundamental information security 

requirements for defining, implementing, operating, 

monitoring, reviewing, maintaining and improving 

supplier and acquirer relationships.

27036-

3:2013 ISO/IEC

Information technology – Security techniques –

Information security for supplier relationships – Part 

3: Guidelines for information and communication 

technology supply chain security

Provides product and service acquirers and suppliers in 

the information and communication technology (ICT) 

supply chain with guidance.

Approved 

Standard

27036-

4:2016 ISO/IEC

Information technology – Security techniques –

Information security for supplier relationships – Part 

4: Guidelines for security of cloud services

Provides cloud service customers and cloud service 

providers with guidance.

Approved 

Standard

UL 2900-1

Feb 2016 UL

Prior to its initial operation in production, the product 

shall require changes of any system defaults that play a 

role in product security, such as passwords and keys. 

The product shall have an indicator when still 

operating with any system default of passwords, keys, 

Guidance 

Available

UL 2900 outlines offer testable 

cybersecurity criteria for networkconnectable products and systems to 

assess software vulnerabilities and 

weaknesses, minimize exploitation, 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

155

Supply Chain Risk Management (SCRM):

Standards that provide the confidence that organizations will produce and deliver information technology products or services that perform 

as required and mitigate supply chain-related risks, such as the insertion of counterfeits and malicious software, unauthorized production, 

tampering, theft, and poor quality products and services. IT SCRM standardization requirements include methodologies and processes that 

enable an organization’s increased visibility into, and understanding of, how technology that they acquire and manage is developed, integrated, 

and deployed, as well as the processes, procedures, and practices used to assure the integrity, security, resilience, and quality of the products 

and services. IT SCRM standardization lies at the intersection of cybersecurity and supply chain management and provides a mix of mitigation 

strategies from both disciplines for a targeted approach to managing IT supply chain risks. 

Documents SDO Description

Maturity 

Level

(Table 6)

Notes

certifications, etc., that would be considered sensitive 

security parameters. 

Page 11, Section 11

address known malware, review 

security controls and increase security 

awareness.

2192

2193
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

156

2194

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

Common 

Criteria Link

April 2017

Common 

Criteria

Class FDP: User Data Protection: User data protection is split into 

four groups of families that address user data within a TOE, during 

import, export, and storage as well as security attributes directly 

related to user data.

User Data Protection security function policies: Access control policy 

and Information flow control policy

Forms of user data protection: Access control functions, Informational 

flow control functions, Internal TOE transfer, Residual information 

protection, Rollback and Stored data integrity.

Off-line storage, import and export: Data authentication, Export from 

the TOE, Import from outside of the TOE

Inter-TSF communication: Inter-TSF user data confidentiality transfer 

protection and Inter-TSF user data integrity transfer protection.

Page 54, Section 11

Definitions:

Guidance 

Available

What is Common 

Criteria?

Provides a common set 

of requirements for the 

security functionality 

of IT products and for 

assurance measures 

applied to these IT 

products during a 

security evaluation.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

157

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

TOE: a set of software, firmware and/or hardware possibly 

accompanied by user and administrator guidance documentation.

TSF: consists of all hardware, software and firmware of a TOE that is 

either directly or indirectly relied upon for security enforcements.

HITRUST 

CSF v9 

10 September 

2017

HITRUS

T 

Alliance

security framework in the U.S. healthcare industry Approved 

Standard

Under Revision

Guidance 

Available

15288:2015 IEEE

ISO/IEC

Defines a set of processes and associated terminology from an 

engineering viewpoint. These processes can be applied at any level in 

the hierarchy of a system's structure.

Approved 

Standard

There are hooks to 

cybersecurity in the 

processes.

P2413 IEEE an Architectural Framework for the IoT Under 

Development

P360 IEEE 

Provides an overview and architecture for a series of standards that 

define technical requirements and testing methods for wearable 

devices and their functions. Gives overview, terminology and 

categorization for Wearable Consumer Electronic Devices (or 

Wearables in short). It further outlines an architecture for a series of 

Under 

Development
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

158

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

standard specifications that define technical requirements and testing 

methods for different aspects of Wearables, from basic security and 

suitableness of wear, to various functional areas like health, fitness 

and infotainment etc. 

RFC 7641 IETF

Observing resources can dramatically increase the negative effects of 

amplification attacks. That is, not only can notifications messages be 

much larger than the request message, but the nature of the protocol 

can cause a significant number of notifications to be generated. 

Without client authentication, a server therefore MUST strictly limit 

the number of notifications that it sends between receiving 

acknowledgements that confirm the actual interest of the client in the 

data; i.e., any notifications sent in non-confirmable messages MUST 

be interspersed with confirmable messages. Note that an attacker may 

still spoof the acknowledgements if the confirmable messages are 

sufficiently predictable.

Page 21, Section 7

Proposed 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

159

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

State of the 

Art and 

Challenges 

for the 

Internet of 

Things

IETF 

Reviews security building blocks available for securing the different 

layers of the Internet protocol suite; documents IoT security threats 

and the challenges to protect against these threats; and discuss the next 

steps needed to ensure roll out of secure IoT services

Under 

Development

62443 ISA/IEC 

Industrial Automation and Control Systems (IACS) standards and 

technical reports includes security management requirements Status for Each 

Part

See: The 62443 series 

of standards

Industrial Automation 

and Control Systems 

Security

13485:2016 ISO 

requirements for a quality management system where an organization 

needs to demonstrate its ability to provide medical devices and related 

services that consistently meet customer and applicable regulatory 

requirements

Approved 

Standard

12207:2008 ISO/IEC

Systems and software engineering – Software life cycle processes

Contains processes, activities, and tasks that are to be applied during 

the acquisition of a software product or service and during the supply, 

development, operation, maintenance and disposal of software 

products. Software includes the software portion of firmware.

Approved 

Standard 

Under Revision

There are hooks to 

cybersecurity in the 

processes and the 

current FDIS has a 

SwA Process View.
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

160

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

15026-1:2013 ISO/IEC

defines assurance-related terms and establishes an organized set of 

concepts and their relationships, thereby establishing a basis for shared 

understanding of the concepts and principles central to all parts of 

ISO/IEC 15026 across its user communities.

Approved 

Standard

15026-2:2011 ISO/IEC systems and software engineering – systems and software assurance 

(Part 2: Assurance Case)

Approved 

Standard

15026-4:2012 ISO/IEC systems and software assurance (Part 4: Assurance in the life cycle) Approved 

Standard

20243:2015 ISO/IEC 

identifies secure engineering best practices, including secure 

management of the IT products, components, and their supply chains

Approved 

Standard

Conformity 

Assessment

20243:2015 ISO/IEC 

Information Technology -- Open Trusted Technology Provider 

Standard (O-TTPS) -- Mitigating maliciously tainted and counterfeit 

products

identifies secure engineering best practices, including secure 

management of the IT products, components, and their supply chains

Approved 

Standard

Conformity 

Assessment

27036-1:2014 ISO/IEC Information technology – Security techniques – Information security 

for supplier relationships – Part 1: Overview and concepts

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

161

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

Provides an overview of the guidance intended to assist organizations 

in securing their information and information systems within the 

context of supplier relationships. It also introduces concepts that are 

described in detail in the other parts of ISO/IEC 27036. ISO/IEC 

27036-1:2014 addresses perspectives of both acquirers and suppliers

27036-1:2014 ISO/IEC

Information technology – Security techniques – Information security 

for supplier relationships – Part 1: Overview and concepts

Provides an overview of the guidance intended to assist organizations 

in securing their information and information systems within the 

context of supplier relationships. It also introduces concepts that are 

described in detail in the other parts of ISO/IEC 27036. ISO/IEC 

27036-1:2014 addresses perspectives of both acquirers and suppliers

Approved 

Standard

27036-2:2014 ISO/IEC

Information technology – Security techniques – Information security 

for supplier relationships – Part 2: Requirements

Specifies fundamental information security requirements for defining, 

implementing, operating, monitoring, reviewing, maintaining and 

improving supplier and acquirer relationships.

Approved 

Standard

27036-2:2014 ISO/IEC Information technology – Security techniques – Information security Approved 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

162

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

for supplier relationships – Part 2: Requirements

Specifies fundamental information security requirements for defining, 

implementing, operating, monitoring, reviewing, maintaining and 

improving supplier and acquirer relationships.

Standard

27036-3:2013 ISO/IEC

Information technology – Security techniques – Information security 

for supplier relationships – Part 3: Guidelines for information and 

communication technology supply chain security

Provides product and service acquirers and suppliers in the 

information and communication technology (ICT) supply chain with 

guidance.

Approved 

Standard

27036-3:2013 ISO/IEC

Information technology – Security techniques – Information security 

for supplier relationships – Part 3: Guidelines for information and 

communication technology supply chain security

Provides product and service acquirers and suppliers in the 

information and communication technology (ICT) supply chain with 

guidance.

Approved 

Standard

27036-4:2016 ISO/IEC Information technology – Security techniques – Information security 

for supplier relationships – Part 4: Guidelines for security of cloud 

Approved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

163

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

services

Provides cloud service customers and cloud service providers with 

guidance.

27036-4:2016 ISO/IEC

Information technology – Security techniques – Information security 

for supplier relationships – Part 4: Guidelines for security of cloud 

services

Provides cloud service customers and cloud service providers with 

guidance.

Approved 

Standard

oneM2M 

Specifications M2M

oneM2M is a worldwide standards initiative that covers requirements, 

architecture, API specifications, security solutions, and 

interoperability for Machine-to-Machine and IoT technologies. 

oneM2M aims to define a comprehensive IoT service layer solution to 

enable scalable and economic IoT solutions. The oneM2M 

consolidates its IoT service layer platform into a three layer model. 

The oneM2M horizontal platform architecture has a middleware layer 

where capabilities such as security are common across all verticals and 

is designed to support resource sharing and interoperability.

oneM2M was formed in 2012. The main partners include eight of the 

world’s preeminent standards development organizations (ARIBApproved 

Standard
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

164

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

Japan, ATIS-N. America, CCSA-China, ETSI-Europe, TIA-America, 

TSDSI-India, TTA-Korea, TTC-Japan.

AEP-67

2010-02-04 NATO engineering for system assurance in NATO programs; guidance in how to build assurance into a system throughout its life cycle

Approved 

Standard

Structured 

Assurance 

Case 

Metamodel

OMG

Documents Associated with Dependability Assurance Framework for 

Safety-Sensitive Consumer Devices (DAF), version 1.0

Defines a metamodel for representing structured assurance cases. An 

Assurance Case is a set of auditable claims, arguments, and evidence 

created to support the claim that a defined system/service will satisfy 

the particular requirements.

Approved 

Standard

UL 2900-1

Feb 2016

UL Prior to its initial operation in production, the product shall require 

changes of any system defaults that play a role in product security, 

such as passwords and keys. The product shall have an indicator when 

still operating with any system default of passwords, keys, 

certifications, etc., that would be considered sensitive security 

parameters. 

Page 11, Section 11

Guidance 

Available

UL 2900 outlines 

testable cybersecurity 

criteria for networkconnectable products 

and systems to assess 

software vulnerabilities 

and weaknesses, 

minimize exploitation, 

address known 

malware, review 

security controls and 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

165

System Security Engineering: 

Standards that describe planning and design activities to meet security specifications or requirements for the purpose of reducing system 

susceptibility to threats, increasing system resilience, and enforcing organizational security policy. A comprehensive system security engineering 

effort: includes a combination of technical and nontechnical activities; ensures all relevant stakeholders are included in security requirements 

definition activities; ensures that security requirements are planned, designed, and implemented into a system during all phases of its lifecycle; 

assesses and understands susceptibility to threats in the projected or actual environment of operation; identifies and assesses vulnerabilities in the 

system and its environment of operation; identifies, specifies, designs, and develops protective measures to address system vulnerabilities; 

evaluates/assesses protective measures to ascertain their suitability, effectiveness and degree to which they can be expected to reduce 

mission/business risk; provides assurance evidence to substantiate the trustworthiness of protective measures; identifies quantifies, and evaluates 

the costs and benefits of protective measures to inform engineering trade-off and risk response decisions; and leverages multiple security focus areas 

to ensure that protective measures are appropriate, effective in combination, and interact properly with other system capabilities. 

Documents SDO Description Maturity Level

(Table 6) Notes

increase security 

awareness.

UL 2900-2-1 UL This security evaluation standard applies to the testing of network 

connected components of healthcare systems. It applies to, but is not 

limited to, the following key components:

a) Medical devices;

b) Accessories to medical devices;

c) Medical device data systems;

d) In vitro diagnostic devices;

e) Health information technology; and

f) Wellness devices.

2195
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

166

2196 Annex E—NIST Federal Information Processing Standards (FIPS) and NIST Special 

2197 Publication 800 Series Relevant to IoT

2198

2199 The applicability sections of each FIPS publication should be reviewed to determine if the 

2200 publication is mandatory for federal agency use. FIPS publications do not apply to national 

2201 security systems (as defined in Title III, Information Security, of FISMA).

2202 Federal government statutes (e.g., FISMA 2014), regulations, and policies (e.g., Office of 

2203 Management and Budget [OMB] Circular A-130) may specify whether federal agencies are 

2204 required, or encouraged, to comply with NIST’s SP 800-series publications. NIST’s SP 800 

2205 series publications shall not apply to national security systems without the express approval of 

2206 appropriate federal officials exercising policy authority over such systems.

2207 Federal Information Processing Standards Publication (FIPS) 202, SHA-3 Standard: 

2208 Permutation-Based Hash and Extendable-Output Functions

2209 Federal Information Processing Standards Publication (FIPS) 200, Minimum Security 

2210 Requirements for Federal Information and Information Systems 

2211 Federal Information Process Standards Publication (FIPS) 199, Standards for Security 

2212 Categorization of Federal Information and Information Systems

2213 Federal Information Process Standards Publication (FIPS) 186-4, Digital Signature Standard 

2214 (DSS)

2215 Federal Information Process Standards Publication (FIPS) 180-4, Secure Hash Standard (SHS)

2216 Federal Information Process Standards Publication (FIPS) 140-2, Security Requirements for 

2217 Cryptographic Modules

2218 NIST Special Publication 800-184, Guide for Cybersecurity Event Recovery

2219 NIST Special Publication 800-183, Networks of ‘Things’ 

2220 NIST Special Publication 800-177, Trustworthy Email 

2221 NIST Special Publication 800-175A, Guideline for Using Cryptographic Standards in the Federal 

2222 Government: Directives, Mandates and Policies

2223 NIST Special Publication 800-175B, Guideline for Using Cryptographic Standards in the Federal 

2224 Government: Cryptographic Mechanisms 

2225 NIST Special Publication 800-171, Protecting Controlled Unclassified Information in Nonfederal 

2226 Information Systems and Organizations 

2227 NIST Special Publication 800-163, Vetting the Security of Mobile Applications 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

167

2228 NIST Special Publication 800-161, Supply Chain Risk Management Practices for Federal 

2229 Information Systems and Organizations 

2230 NIST Special Publication 800-160, Systems Security Engineering, Considerations for a 

2231 Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems

2232 NIST Special Publication 800-153, Guidelines for Securing Wireless Local Networks (WLANs) 

2233 NIST Special Publication 800-152, A Profile for U.S. Federal Cryptographic Key Management 

2234 Systems (CKMS) 

2235 NIST Special Publication 800-150, Guide to Cyber Threat Information Sharing 

2236 NIST Special Publication 800-146, Cloud Computing Synopsis and Recommendations

2237 NIST Special Publication 800-145, The NIST Definition of Cloud Computing

2238 NIST Special Publication 800-144, Guidelines on Security and Privacy in Public Cloud 

2239 Computing

2240 NIST Special Publication 800-137, Information Security Continuous Monitoring (ISCM) for 

2241 Federal Information Systems and Organizations 

2242 NIST Special Publication 800-128, Guide for Security-Focused Configuration Management of 

2243 Information Systems

2244 NIST Special Publication 800-125, Guide to Security for Full Virtualization Technologies 

2245 NIST Special Publication 800-124 Rev. 1, Guidelines for Managing the Security of Mobile 

2246 Devices in the Enterprise 

2247 NIST Special Publication 800-123, Guide to General Server Security 

2248 NIST Special Publication 800-121 Rev. 2, Guide to Bluetooth Security 

2249 NIST Special Publication 800-119, Guidelines for the Secure Deployment of IPv6

2250 NIST Special Publication 800-115, Technical Guide to Information Security Testing and 

2251 Assessment

2252 NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User 

2253 Devices 

2254 NIST Special Publication 800-101 Rev. 1, Guidelines on Mobile Device Forensics

2255 NIST Special Publication 800-98, Guidelines for Securing Radio Frequency Identification 

2256 (RFID) Systems 

2257 NIST Special Publication 800-97, Establishing Wireless Robust Security Networks: A Guide to 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

168

2258 IEEE 802.11i

2259 NIST Special Publication 800-95, Guide to Secure Web Services

2260 NIST Special Publication 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)

2261 NIST Special Publication 800-92, Guide to Computer Security Log Management

2262 NIST Special Publication 800-83 Rev.1, Guide to Malware Incident Prevention and Handling for 

2263 Desktops and Laptops

2264 NIST Special Publication 800-82 Rev. 2, Guide to Industrial Control Systems (ICS) Security

2265 NIST Special Publication 800-81-2, Secure Domain Name System (DNS) Deployment Guide

2266 NIST Special Publication 800-77, Guide to IPsec VPNs

2267 NIST Special Publication 800-70 Rev. 3, National Checklist Program for IT Products: 

2268 Guidelines for Checklist Users and Developers 

2269 NIST Special Publication 800-64 Rev. 2, Security Considerations in the System Development 

2270 Life Cycle

2271 NIST Special Publication 800-63A, Digital Identity Guideline: Enrollment and Identity Proofing

2272 NIST Special Publication 800-63B, Digital Identity Guideline: Authentication and Lifecycle 

2273 Management

2274 NIST Special Publication 800-63C, Digital Identity Guideline: Federation and Assertions

2275 NIST Special Publication 800-63-3, Digital Identity Guidelines

2276 NIST Special Publication 800-61 Rev. 2, Computer Security Incident Handling Guide

2277 NIST Special Publication 800-58, Security Considerations for Voice Over IP Systems

2278 NIST Special Publication 800-57 Part 1 Rev. 4, Recommendation for Key Management, Part 1: 

2279 General

2280 NIST Special Publication 800-57 Part 2, Recommendation for Key Management, Part 2: Best 

2281 Practices for Key Management Organization

2282 NIST Special Publication 800-57 Part 3 Rev. 1, Recommendation for Key Management, Part 3: 

2283 Application-Specific Key Management Guidance

2284 NIST Special Publication 800-54, Border Gateway Protocol Security 

2285 NIST Special Publication 800-53 Rev. 4, Security and Privacy Controls for Federal Information 

2286 Systems and Organizations 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

169

2287 NIST Special Publication 800-52 Rev. 1, Guidelines for the Selection, Configuration, and Use of 

2288 Transport Layer Security (TLS) Implementations

2289 NIST Special Publication 800-48 Rev. 1, Guide to Securing Legacy IEEE 802.11 Wireless 

2290 Networks

2291 NIST Special Publication 800-47, Security Guide for Interconnecting Information Technology 

2292 Systems

2293 NIST Special Publication 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and 

2294 Bring Your Own Device (BYOD) Security

2295 NIST Special Publication 800-45 Version 2, Guidelines on Electronic Mail Security

2296 NIST Special Publication 800-44 Version 2, Guidelines on Securing Public Web Servers 

2297 NIST Special Publication 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy 

2298 NIST Special Publication 800-40 Rev. 3, Guide to Enterprise Patch Management Technologies 

2299 NIST Special Publication 800-39, Managing Information Security Risk: Organization, Mission, 

2300 and Information System View 

2301 NIST Special Publication 800-37 Rev. 1, Guide for applying the Risk Management Framework 

2302 to Federal Information Systems: a Security Life Cycle Approach 

2303 NIST Special Publication 800-36, Guide to Selecting Information Technology Security Products 

2304 NIST Special Publication 800-35, Guide to Information Technology Security Services 

2305 NIST Special Publication 800-34 Rev. 1, Contingency Planning Guide for Federal Information 

2306 Systems 

2307 NIST Special Publication 800-33, Underlying Technical Models for Information Technology 

2308 Security

2309 NIST Special Publication 800-32, Introduction to Public Key Technology and the Federal PKI 

2310 Infrastructure 

2311 NIST Special Publication 800-30 Rev. 1, Guide for Conducting Risk Assessments

2312 NIST Special Publication 800-29, A Comparison of the Security Requirements for 

2313 Cryptographic modules in FIPS 140-1 and FIPS 140-2

2314 NIST Special Publication 800-28 Version 2, Guidelines on Active Content and Mobile Code

2315 NIST Special Publication 800-27 Rev. A, Engineering Principles for Information Technology 

2316 Security (A Baseline for Achieving Security), Revision A
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

170

2317 NIST Special Publication 800-18, Guide for Developing Security Plans for Federal Information 

2318 Systems

2319 NIST Special Publication 800-12, An Introduction to Information Security 

2320
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

171

2321 Annex F—Acronyms

3GPP 3rd Generation Partnership Project

AAMI Association for the Advancement of Medical Instrumentation

AES Advanced Encryption Standard

CD Committee Draft

CIP Critical Infrastructure Protection

CLSI Clinical and Laboratory Standards Institute 

COSO Committee of Sponsoring Organizations

CPS Cyber Physical Systems 

CSA Canadian Standards Association

DASH7 Developers Alliance for Standards Harmonization

DDoS Distributed Denial of Service

DIS Draft International Standard

DOT Department of Transportation 

DSA Digital Signature Algorithm

DSS Data Security Standard

DTS Diabetes Technology Social 

ESDSA Elliptic Curve Digital Signature Algorithm

ETSI European Telecommunications Standards Institute 

FDA U.S. Food and Drug Administration

FDIS Final Draft International Standard

FIDO Fast Identity Online

FIPS Federal Information Processing Standard

GSMA Groupe Speciale Mobile Association

EHR Electronic Health Records

HL7 Health Level 7

HIPAA Health Insurance Portability and Accountability Act of 1996

HIT Health Information Technology 

HITRUST Health Information Trust Alliance

IACS Industrial Automation and Control Systems

ICS Industrial Control Systems

ICT Information and Communications Technology

IDMEF Intrusion Detection Message Exchange Format

IEC International Electrotechnical Commission

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IICSWG Interagency International Cybersecurity Standardization 

Working Group

IIC Industrial Internet Consortium

IODEF Incident Object Description Exchange Format

IoT Internet of Things

IPv6 Internet Protocol version 6
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

172

ISA International Society of Automation

ISMS Information Security Management Systems

ISO International Organization for Standardization 

IT Information Technology

ITS JPO Intelligent Transportation System Joint Program Office 

ITU International Telecommunication Union

ITU-T International Telecommunication Union - Telecommunication

LDAP Lightweight Directory Access Protocol

LoRa Alliance Long Range Alliance

LTE Long Term Evolution 

M2M Machine to Machine

MAC Message Authentication Code

MQTT MQ Telemetry Transport

NATO North Atlantic Treaty Organization

NERC North American Electric Reliability Corporation

NHTSA National Highway Traffic Safety Administration 

NS/EP National Security and Emergency Preparedness

NSC’s Cyber 

IPC 

National Security Council’s Cyber Interagency Policy 

Committee

NSTAC President’s National Security Telecommunications Advisory 

Committee

OASIS Organization for the Advancement of Structured Information 

Standards

OCF Open Connectivity Foundation

OMA Open Mobile Alliance

OMG Object Management Group

OpenFog RA OpenFog Reference Architecture

OTA Open Travel Alliance

O-TTPS Open Trusted Technology Provider Standard

PCI Payment Card Industry

PHR Personal Health Records

PID Proportional Integral Derivative 

PII Personally Identifiable Information

PKCS Public-Key Cryptography Standards

PKI Public Key Infrastructure

PSS Probabilistic Signature Scheme

RFC Request for Comments

RID Real-time Inter-network Defense

SACM Security Automation and Continuous Monitoring

SAE SAE International

SAML Security Assertion Markup Language

SCMS Security Credential Management System

SCRM Supply Chain Risk Management
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

173

SDO Standards Developing Organizations

STIX OASIS Structured Threat Information Expression

SWID Software Identification

TAXII OASIS Trusted Automated Exchange of Indicator Information

TCG Trusted Computing Group

TIA/EIA Telecommunications Industry Association. Electronic Industries 

Alliance 

TLS Transport Layer Security

TR Technical Report

TTP Tactics, Techniques, and Procedures

UI User Interface

UL Underwriters Laboratories 

WD Working Draft

XSF XMPP Standards Foundation

2322
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

174

2323 Annex G—References

[1] NIST Interagency Report (NISTIR) 8074 Volume 1, Interagency Report on 

Strategic U.S. Government Engagement in International Standardization to 

Achieve U.S. Objectives for Cybersecurity, National Institute of Standards 

and Technology, Gaithersburg, Maryland, December 2015, 22 pp.

https://doi.org/10.6028/NIST.IR.8074v1.

[2] NIST Interagency Report (NISTIR) 8074 Volume 2, Supplemental 

Information for the Interagency Report on Strategic U.S. Government 

Engagement in International Standardization to Achieve U.S. Objectives for 

Cybersecurity, National Institute of Standards and Technology, 

Gaithersburg, Maryland, Dec 2015, 72 pp.

https://doi.org/10.6028/NIST.IR.8074v2

[3] Office of Management and Budget (OMB), Federal Participation in the 

Development and Use of Voluntary Consensus Standards and in Conformity 

Assessment Activities, Circular A-119, Office of Management and Budget, 

Executive Office of the President. Washington, DC, January 2016, 28 pp. 

https://www.federalregister.gov/documents/2016/01/27/2016-

01606/revision-of-omb-circular-no-a-119-federal-participation-in-thedevelopment-and-use-of-voluntary

[4] The President’s National Security Telecommunications Advisory 

Committee, NSTAC Report to the President on the Internet of Things,

Washington, DC, November 2014, 24 pp. 

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/

revised_circular_a-119_as_of_1_22.pdf

[5] Commission on Enhancing National Cybersecurity, Report on Securing and 

Growing the Digital Economy, December 2016, 90 pp. 

https://www.nist.gov/sites/default/files/documents/2016/12/02/cybersecuritycommission-report-final-post.pdf

[6] NIST Interagency Report (NISTIR) 8074 Volume 1, Interagency Report on 

Strategic U.S. Government Engagement in International Standardization to

Achieve U.S. Objectives for Cybersecurity, National Institute of Standards 

and Technology, Gaithersburg, Maryland, December 2015, 28 pp.

https://doi.org/10.6028/NIST.IR.8074v1.

[7] Strategic Principles for Securing the Internet of Things (IoT), U.S. 

Department of Homeland Security, November 2016, 17 pp. 

https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for

_Securing_the_Internet_of_Things-2016-1115-FINAL....pdf
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

175

[8] OMB Circular A-119, Federal Participation in the Development and Use of 

Voluntary Consensus Standards and in Conformity Assessment Activities, 

Office of Management and Budget, Executive Office of the President. 

Washington, DC, January 2016, 28 pp. 

https://www.federalregister.gov/documents/2016/01/27/2016-

01606/revision-of-omb-circular-no-a-119-federal-participation-in-thedevelopment-and-use-of-voluntary

[9] S. Brooks, M. Garcia, N. Lefkovitz, S. Lightman, and E. Nadeau, NISTIR 

8062: An Introduction to Privacy Engineering and Risk Management in 

Federal Systems, National Institute of Standards and Technology, 

Gaithersburg Maryland, January 2017, 41 pp. 

https://doi.org/10.6028/NIST.IR.8062 

[10] Kevin Gay, Security Credential Management System – Operations and 

Management, U.S. Department of Transportation, 15 pp. 

https://www.its.dot.gov/pilots/pdf/ITSA2016_security_Gay.pdf

[11] Connected Vehicle Basics, How Does Connected Vehicle Technology 

Work?, U.S. Department of Transportation, Washington DC, 1 pp. 

https://www.its.dot.gov/cv_basics/cv_basics_how.htm

[12] Guidance Summary for Connected Vehicle Deployments, Security 

Operational Concept, Final Report, U.S. Department of Transportation, 

Washington DC, July 2016, 20 pp.

https://rosap.ntl.bts.gov/view/dot/3599/dot_3599_DS1.pdf

[13] K. Gay, Security Credential Management System – Operations and 

Management, U.S. Department of Transportation, 15 pp. 

https://www.its.dot.gov/pilots/pdf/ITSA2016_security_Gay.pdf

[14] Security Credential Management System Proof-of-Concept Implementation, 

EE Requirements and Specifications Supporting SCMS Software Release 1.1, 

U.S. Department of Transportation, May 2016, 553 pp. 

https://www.its.dot.gov/pilots/pdf/SCMS_POC_EE_Requirements.pdf

[15] D. Fred, A Brief History of the Internet of Things, FireceMobileIT, July 

2014. http://www.fiercemobileit.com/story/brief-history-internetthings/2014-07-23

[16] S. Gupta, Implantable Medical Devices – Cyber Risks and Mitigation 

Approaches, NIST Cyber Physical Systems Workshop April 23-24, 2012, 

https://csrc.nist.gov/presentations/2012/implantable-medical-devices-cyberrisks-and-miti

[17] J. Bresnick, Internet of Things, Precision Medicine, NLP Drive Market 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

176

Growth, Precision Medicine News, October 2015, 1 pp. 

https://healthitanalytics.com/news/internet-of-things-precision-medicine-nlpdrive-market-growth

[18] What is Precision Medicine?, National Institute of Health, U.S. National 

Library of Medicine, April 2015, 1 pp. 

https://ghr.nlm.nih.gov/primer/precisionmedicine/definition

[19] K. Stouffer, T. Zimmerman, C. Tang, J. Lubell, J. Cichonski, J. McCarthy, 

NISTIR 8183: Cybersecurity Framework Manufacturing Profile, National 

Institute of Standards and Technology, Gaithersburg Maryland, January 

2017, 50 pp. https://doi.org/10.6028/NIST.IR.8183

[20] K. McKay, L. Bassham, M. Turan, N. Mouha, NISTIR 8114: Report on 

Lightweight Cryptography, National Institute of Standards and Technology, 

Gaithersburg, Maryland, March 2017, 21 pp. 

https://doi.org/10.6028/NIST.IR.8114

[21] Health Information Technology, https://www.healthit.gov/

[22] The Industrial Internet of Things, Volume G8: Vocabulary Industrial Internet 

Consortium, 2017, 32 pp. 

http://www.iiconsortium.org/pdf/IIC_Vocab_Technical_Report_2.0.pdf

[23] NIST Interagency Report (NISTIR) 8074 Volume 2, Supplemental 

Information for the Interagency Report on Strategic U.S. Government 

Engagement in International Standardization to Achieve U.S. Objectives for 

Cybersecurity, National Institute of Standards and Technology, 

Gaithersburg, Maryland, Dec 2015, 72 pp. 

https://doi.org/10.6028/NIST.IR.8074v2

[24] IoT Security Threat Map, Beecham Research, London, Maryland, March 

2015, 1 pp. http://www.beechamresearch.com/download.aspx?id=43

[25] DoD CIO, Policy Recommendations for the Internet of Things, U.S. 

Department of Defense, December 2016, 6 pp. 

https://www.hsdl.org/?view&did=799676

[26] K. Stouffer, V. Pillitteri, S. Lightman, M. Abrams, A. Hahn, NIST Special 

Publication 800-82 Revision 2, Guide to Industrial Control Systems (ICS) 

Security, Natonal Institute of Standards and Technology, Gaithersburg, 

Maryland, May 2015, 41 pp. 

https://doi.org/10.6028/NIST.SP.800-82r2

[27] NIST Special Publication 800-30 Revision 1, Joint Task Force 

Transformation Initiative Interagency Working Group, Guide for Conducting 
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

177

Risk Assessments, National Institute of Standards and Technology, 

Gaithersburg, Maryland, September 2012, 95 pp.

https://doi.org/10.6028/NIST.SP.800-30r1

[28] Committee on National Security Systems Glossary Working Group, 

Committee On National Security Systems (CNSS) Glossary, April 2010, 160 

pp. https://cryptosmith.files.wordpress.com/2015/08/glossary-2015-cnss.pdf

[29] NIST Special Publication 800-30 Revision 1, Joint Task Force 

Transformation Initiative Interagency Working Group, Guide for Conducting 

Risk Assessments, National Institute of Standards and Technology, 

Gaithersburg, Maryland, September 2012, 95 pp.

https://doi.org/10.6028/NIST.SP.800-30r1

[30] D. Klinedinst and C. King, On Board Diagnostics: Risks and Vulnerabilities 

of the Connected Vehicle, Software Engineering Institute, Carnegie Mellon 

University, March 2016, 20 pp. 

https://resources.sei.cmu.edu/asset_files/WhitePaper/2016_019_001_453877

.pdf

[31] Connected Vehicle Pilot Deployment Program Phase I Security Management 

Operational Concept, Federal Highway Administration, Mary 2016. 

https://ntl.bts.gov/lib/59000/59200/59264/FHWA-JPO-16-312.pdf

[32] Health Care Industry Cybersecurity Task Force, Report on Improving 

Cybersecurity in the Healthcare Industry, Public Health Emergency, June 

2017, 88 pp. 

https://www.phe.gov/Preparedness/planning/CyberTF/Documents/report201

7.pdf

[33] The President’s National Security Telecommunications Advisory 

Committee, NSTAC Report to the President on the Internet of Things, 

Washington, DC, November 2014, 24 pp. 

https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/

revised_circular_a-119_as_of_1_22.pdf

[34] ISO/IEC CD 20924, Information technology – Internet of Things –

Definition and Vocabulary. https://www.iso.org/standard/69470.html

[35] IEEE P2413, Standard for an Architectural Framework for the Internet of 

Things (IoT). https://standards.ieee.org/develop/project/2413.html

[36] Strategic Principles for Securing the Internet of Things (IoT), U.S. 

Department of Homeland Security, November 2016, 17 pp. 

https://www.dhs.gov/sites/default/files/publications/Strategic_Principles_for

_Securing_the_Internet_of_Things-2016-1115-FINAL....pdf
NISTIR 8200 (DRAFT) STATUS OF INTERNATIONAL CYBERSECURITY

STANDARDIZATION FOR IOT

178

[37] Fostering the Advancement of the Internet of Things, The Department of 

Commerce Internet Policy Task Force & Digital Economy Leadership Team,

National Telecommunications and Information Administration, Washington 

DC, January 2017, 65 pp. 

https://www.ntia.doc.gov/files/ntia/publications/iot_green_paper_01122017.

pdf

[38] J. Voss, NIST Special Publication 800-183 Revision 1, Network of ‘Things’, 

National Institute of Standards and Technology, Gaithersburg, Maryland, 

July 2016, 25 pp.

https://doi.org/10.6028/NIST.SP.800-183

[39] Overview of the Internet of Things, International Telecommunication Union, 

Next Generation Networks – Frameworks and functional architecture 

models, 2013, 15 pp. http://handle.itu.int/11.1002/1000/11559-

en?locatt=format:pdf&auth

2324