NIST SPECIAL PUBLICATION 1800-36E

Trusted Internet of Things (IoT) Device
Network-Layer Onboarding and
Lifecycle Management:
Enhancing Internet Protocol-Based IoT Device and Network
Security
Volume E:
Risk and Compliance Management

Michael Fagan
Jeffrey Marron
Paul Watrobski
Murugiah Souppaya
National Cybersecurity Center of Excellence
Information Technology Laboratory

Karen Scarfone
Scarfone Cybersecurity
Clifton, Virginia

William Barker
Dakota Consulting
Largo, Maryland

Susan Symington
The MITRE Corporation
McLean, Virginia

Dan Harkins
Aruba, a Hewlett Packard Enterprise Company
San Jose, California

October 2023
SECOND PRELIMINARY DRAFT
This publication is available free of charge fromhttps://www.nccoe.nist.gov/projects/trusted-iot-device-network-layer-onboarding-and-lifecycle-management

SECOND PRELIMINARY DRAFT

1

DISCLAIMER

2
3
4
5
6
7

Certain commercial entities, equipment, products, or materials may be identified by name or company
logo or other insignia in order to acknowledge their participation in this collaboration or to describe an
experimental procedure or concept adequately. Such identification is not intended to imply special
status or relationship with NIST or recommendation or endorsement by NIST or NCCoE; neither is it
intended to imply that the entities, equipment, products, or materials are necessarily the best available
for the purpose.

89National Institute of Standards and Technology Special Publication 1800-36E, Natl. Inst. Stand. Technol.
Spec. Publ. 1800-36E, 112 pages, October 2023, CODEN: NSPUE2

10

FEEDBACK

11
12
13
14
15
16
17
18

You can improve this guide by contributing feedback on the mappings included in this volume. Do you
find the mappings that we have provided in this document helpful to you as you try to achieve yourcybersecurity goals? Could the mappings that we have provided be improved, either in terms of theircontent or format? Are there additional standards, best practices, or other guidance documents thatyou would like us to map to and from trusted IoT device network-layer onboarding and lifecycle
management capabilities? Are there additional use cases for these mappings that we should consider inthe future? As you review and adopt this solution for your own organization, we ask you and yourcolleagues to share your experience and advice with us.

19

Comments on this publication may be submitted to: iot-onboarding@nist.gov.

20

Public comment period: October 31, 2023 through December 15, 2023

21

All comments are subject to release under the Freedom of Information Act.

22
23
24
25
26
27

National Cybersecurity Center of Excellence
National Institute of Standards and Technology
100 Bureau Drive
Mailstop 2002
Gaithersburg, MD 20899
Email: nccoe@nist.gov

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementii

SECOND PRELIMINARY DRAFT

28

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

29
30
31
32
33
34
35
36
37
38
39
40
41

The National Cybersecurity Center of Excellence (NCCoE), a part of the National Institute of Standards
and Technology (NIST), is a collaborative hub where industry organizations, government agencies, andacademic institutions work together to address businesses’ most pressing cybersecurity issues. Thispublic-private partnership enables the creation of practical cybersecurity solutions for specificindustries, as well as for broad, cross-sector technology challenges. Through consortia under
Cooperative Research and Development Agreements (CRADAs), including technology partners—from
Fortune 50 market leaders to smaller companies specializing in information technology security—the
NCCoE applies standards and best practices to develop modular, adaptable example cybersecurity
solutions using commercially available technology. The NCCoE documents these example solutions in
the NIST Special Publication 1800 series, which maps capabilities to the NIST Cybersecurity Frameworkand details the steps needed for another entity to re-create the example solution. The NCCoE wasestablished in 2012 by NIST in partnership with the State of Maryland and Montgomery County,
Maryland.

42
43

To learn more about the NCCoE, visit https://www.nccoe.nist.gov/. To learn more about NIST, visit
https://www.nist.gov.

44

NIST CYBERSECURITY PRACTICE GUIDES

45
46
47
48
49
50

NIST Cybersecurity Practice Guides (Special Publication 1800 series) target specific cybersecurity
challenges in the public and private sectors. They are practical, user-friendly guides that facilitate theadoption of standards-based approaches to cybersecurity. They show members of the information
security community how to implement example solutions that help them align with relevant standards
and best practices, and provide users with the materials lists, configuration files, and other information
they need to implement a similar approach.

51
52
53

The documents in this series describe example implementations of cybersecurity practices thatbusinesses and other organizations may voluntarily adopt. These documents do not describe regulations
or mandatory practices, nor do they carry statutory authority.

54

KEYWORDS

55
56

application-layer onboarding; bootstrapping; Internet of Things (IoT); Manufacturer Usage Description(MUD); network-layer onboarding; onboarding; Wi-Fi Easy Connect.

57

ACKNOWLEDGMENTS

58

We are grateful to the following individuals for their generous contributions of expertise and time.
Name

Organization

Amogh Guruprasad Deshmukh

Aruba, a Hewlett Packard Enterprise company

Danny Jump

Aruba, a Hewlett Packard Enterprise company

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementiii

SECOND PRELIMINARY DRAFT

Name

Organization

Andy Dolan

CableLabs

Kyle HaefnerCableLabs

Craig Pratt

CableLabs

Darshak Thakore

CableLabs

Bart Brinkman

Cisco

Eliot Lear

Cisco

Peter Romness

Cisco

Tyler Baker

Foundries.io

George Grey

Foundries.io

David Griego

Foundries.io

Fabien Gremaud

Kudelski IoT

Brecht Wyseur

Kudelski IoT

Faith Ryan

The MITRE Corporation

Nicholas Allot

NquiringMinds

Toby Ealden

NquiringMinds

Alois Klink

NquiringMinds

John Manslow

NquiringMinds

Antony McCaigue

NquiringMinds

Alexandru Mereacre

NquiringMinds

Craig Rafter

NquiringMinds

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementiv

SECOND PRELIMINARY DRAFT

59
60
61
62

Name

Organization

Loic Cavaille

NXP Semiconductors

Mihai Chelalau

NXP Semiconductors

Julien Delplancke

NXP Semiconductors

Anda-Alexandra Dorneanu

NXP Semiconductors

Todd Nuzum

NXP Semiconductors

Nicusor Penisoara

NXP Semiconductors

Laurentiu Tudor

NXP Semiconductors

Michael Richardson

Sandelman Software Works

Pedro Fuentes

SEALSQ, a subsidiary of WISeKey

Gweltas Radenac

SEALSQ, a subsidiary of WISeKey

Kalvin YangSEALSQ, a subsidiary of WISeKey

Mike Dow

Silicon Labs

Steve Egerter

Silicon LabsThe Technology Partners/Collaborators who participated in this build submitted their capabilities in
response to a notice in the Federal Register. Respondents with relevant capabilities or productcomponents were invited to sign a Cooperative Research and Development Agreement (CRADA) with
NIST, allowing them to participate in a consortium to build this example solution. We worked with:

63
64
65
66
67

Technology Collaborators
Aruba, a Hewlett Packard
Enterprise company
CableLabs
Cisco

Foundries.io
Kudelski IoT
NquiringMinds
NXP Semiconductors

Open Connectivity Foundation (OCF)
Sandelman Software WorksSEALSQ, a subsidiary of WISeKey
Silicon LabsNIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementv

SECOND PRELIMINARY DRAFT

68

DOCUMENT CONVENTIONS

69
70
71
72
73
74
75

The terms “shall” and “shall not” indicate requirements to be followed strictly to conform to the
publication and from which no deviation is permitted. The terms “should” and “should not” indicate thatamong several possibilities, one is recommended as particularly suitable without mentioning or
excluding others, or that a certain course of action is preferred but not necessarily required, or that (inthe negative form) a certain possibility or course of action is discouraged but not prohibited. The terms“may” and “need not” indicate a course of action permissible within the limits of the publication. The
terms “can” and “cannot” indicate a possibility and capability, whether material, physical, or causal.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementvi

SECOND PRELIMINARY DRAFT

76

CALL FOR PATENT CLAIMS

77
78
79
80
81
82

This public review includes a call for information on essential patent claims (claims whose use would be
required for compliance with the guidance or requirements in this Information Technology Laboratory(ITL) draft publication). Such guidance and/or requirements may be directly stated in this ITL Publication
or by reference to another publication. This call also includes disclosure, where known, of the existenceof pending U.S. or foreign patent applications relating to this ITL draft publication and of any relevant
unexpired U.S. or foreign patents.

83
84

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, inwritten or electronic form, either:8586a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
currently intend holding any essential patent claim(s); or

87
88
89

b) assurance that a license to such essential patent claim(s) will be made available to applicants desiring
to utilize the license for the purpose of complying with the guidance or requirements in this ITL draft
publication either:

90
91

1. under reasonable terms and conditions that are demonstrably free of any unfair discrimination;
or

92
93

2. without compensation and under reasonable terms and conditions that are demonstrably freeof any unfair discrimination.

94
95
96
97
98

Such assurance shall indicate that the patent holder (or third party authorized to make assurances on its
behalf) will include in any documents transferring ownership of patents subject to the assurance,
provisions sufficient to ensure that the commitments in the assurance are binding on the transferee,and that the transferee will similarly include appropriate provisions in the event of future transfers withthe goal of binding each successor-in-interest.

99
100

The assurance shall also indicate that it is intended to be binding on successors-in-interest regardless ofwhether such provisions are included in the relevant transfer documents.

101

Such statements should be addressed to: iot-onboarding@nist.gov.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementvii

SECOND PRELIMINARY DRAFT

102

Contents

103

1 Introduction ........................................................................................1

104
105
106
107

1.1

How to Use This Guide .................................................................................................. 1

2 Risks Addressed by Trusted Network-Layer Onboarding and Lifecycle
Management .......................................................................................3
2.1

Risks to the Network ..................................................................................................... 3

108

2.1.1

Risks to the Network Due to Device Limitations .......................................................... 3

109

2.1.2

Risks to the Network Due to Use of Shared Network Credentials ............................... 4

110

2.1.3

Risks to the Network Due to Insecure Network Credential Provisioning .................... 4

111

2.1.4

Risks to the Network Due to Supply Chain Attacks ...................................................... 4

112

2.2

Risks to the Device ........................................................................................................ 4

113

2.3

Risks to Secure Lifecycle Management ......................................................................... 4

114

2.4

Limitations and Dependencies of Trusted Onboarding ................................................ 5115

3 Mapping Use Cases, Approach, and Terminology .................................6

116

3.1

Use Cases ....................................................................................................................... 7

117

3.2

Mapping Producers ....................................................................................................... 7

118

3.3

Mapping Approach ........................................................................................................ 8

119

3.3.1

Mapping Terminology .................................................................................................. 8

120

3.3.2

Mapping Process .......................................................................................................... 9

121
122

4 Mappings .............................................................................................9
4.1

NIST CSF Subcategory Mappings ................................................................................. 10

123

4.1.1

Mappings Between Reference Design Functions and NIST CSF Subcategories ......... 10

124

4.1.2

Mappings Between Specific Onboarding Protocols and NIST CSF Subcategories ..... 21

125

4.1.3

Mappings Between Specific Builds and NIST CSF Subcategories ............................... 40

126

4.2

NIST SP 800-53 Control Mappings ............................................................................... 50

127

4.2.1

Mappings Between Reference Design Functions and NIST SP 800-53 Controls ........ 50

128

4.2.2

Mappings Between Specific Onboarding Protocols and NIST SP 800-53 Controls .... 71

129

4.2.3

Mappings Between Specific Builds and NIST SP 800-53 Controls .............................. 88

130

Appendix A References ........................................................................ 103

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementviii

SECOND PRELIMINARY DRAFT

131

List of Tables

132

Table 4-1 Mapping Between Reference Design Logical Components and NIST CSF Subcategories ....... 10133

Table 4-2 Mapping Between Wi-Fi Easy Connect Functionality and NIST CSF Subcategories ................ 21

134

Table 4-3 Mapping Between BRSKI Functionality and NIST CSF Subcategories ....................................32

135

Table 4-4 Mapping Between Functionality of Build 1 Components and NIST CSF Subcategories .......... 40

136

Table 4-5 Mapping Between Reference Design Logical Components and NIST SP 800-53 Controls ......50

137

Table 4-6 Mapping Between Wi-Fi Easy Connect Functionality and NIST SP 800-53 Controls............... 71

138

Table 4-7 Mapping Between BRSKI Functionality and NIST SP 800-53 Controls ...................................79

139

Table 4-8 Mapping Between Functionality of Build 1 Components and NIST SP 800-53 Controls ......... 89

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementix

SECOND PRELIMINARY DRAFT

140

1 Introduction

141
142
143
144
145

In this project, the National Cybersecurity Center of Excellence (NCCoE) applies standards,
recommended practices, and commercially available technology to demonstrate various mechanisms fortrusted network-layer onboarding of IoT devices and lifecycle management of those devices. We show
how to provision network credentials to IoT devices in a trusted manner and maintain a secure posturethroughout the device lifecycle.

146
147
148
149
150
151

This volume of the NIST Cybersecurity Practice Guide discusses risks addressed by the trusted IoT device
network-layer onboarding and lifecycle management reference design. It also maps between
cybersecurity functionality provided by logical components of the reference design and Subcategories in
the NIST Cybersecurity Framework (CSF) and controls in NIST Special Publication (SP) 800-53, Security
and Privacy Controls for Information Systems and Organizations. (Note: The reference design isdescribed in detail in NIST SP 1800-36B, Section 4.)

152
153
154
155
156
157

Mappings are also provided between cybersecurity functionality provided by specific network-layer
onboarding protocols (e.g., Wi-Fi Easy Connect and Bootstrapping Remote Secure Key Infrastructure[BRSKI]) and those same Subcategories and controls, as well as between cybersecurity functionality
provided by builds of the reference design that have been implemented as part of this project and thosesame Subcategories and controls. (Note: the composition of the builds is described in detail in the
appendices of NIST SP 1800-36B.)

158
159
160
161
162
163
164
165

None of the mappings we provide is intended to be exhaustive; the mappings focus on the strongest
relationships involving each reference design cybersecurity function in order to help organizations
prioritize their work. The mappings help users understand how trusted IoT device network-layer
onboarding and lifecycle management can help them achieve their cybersecurity goals in terms of CSF
Subcategories and SP 800-53 controls. The mappings also help users understand how they can
implement trusted onboarding and lifecycle management by identifying how trusted onboarding
functionality is supported by the user’s existing implementations of CSF Subcategories and SP 800-53
controls.

166

1.1 How to Use This Guide

167
168
169
170
171
172
173
174
175

This NIST Cybersecurity Practice Guide demonstrates a standards-based reference design for
implementing trusted IoT device network-layer onboarding and lifecycle management and describes
various example implementations of this reference design. Each of these implementations, which are
known as builds, is standards-based and is designed to help provide assurance that networks are not put
at risk as new IoT devices are added to them and help safeguard IoT devices from being taken over by
unauthorized networks. The reference design described in this practice guide is modular and can be
deployed in whole or in part, enabling organizations to incorporate trusted IoT device network-layer
onboarding and lifecycle management into their legacy environments according to goals that they haveprioritized based on risk, cost, and resources.

176
177

NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
possible rather than delaying release until all volumes are completed. Work continues on implementing

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

1

SECOND PRELIMINARY DRAFT
178
179

the example solutions and developing other parts of the content. As a preliminary draft, we will publish
at least one additional draft for public comment before it is finalized.

180

This guide contains five volumes:

181
182

▪

NIST SP 1800-36A: Executive Summary – why we wrote this guide, the challenge we address,
why it could be important to your organization, and our approach to solving this challenge

183▪

NIST SP 1800-36B: Approach, Architecture, and Security Characteristics – what we built and why

184
185
186

▪

NIST SP 1800-36C: How-To Guides – instructions for building the example implementations,
including all the security-relevant details that would allow you to replicate all or parts of thisproject

187
188
189

▪

NIST SP 1800-36D: Functional Demonstrations – use cases that have been defined to showcase
trusted IoT device network-layer onboarding and lifecycle management security capabilities,
and the results of demonstrating these use cases with each of the example implementations

190
191
192

▪

NIST SP 1800-36E: Risk and Compliance Management – risk analysis and mapping of trusted IoT
device network-layer onboarding and lifecycle management security characteristics tocybersecurity standards and best practices (you are here)

193

Depending on your role in your organization, you might use this guide in different ways:

194
195

Business decision makers, including chief security and technology officers, will be interested in the
Executive Summary, NIST SP 1800-36A, which describes the following topics:

196
197

▪

challenges that enterprises face in migrating to the use of trusted IoT device network-layer
onboarding

198▪

example solutions built at the NCCoE

199▪

benefits of adopting the example solution

200
201

Technology or security program managers who are concerned with how to identify, understand, assess,and mitigate risk will be interested in NIST SP 1800-36B, which describes what we did and why.

202
203
204
205
206
207

Also, Section 4 of NIST SP 1800-36E will be of particular interest. Section 4, Mappings, maps logicalcomponents of the general trusted IoT device network-layer onboarding and lifecycle management
reference design to security characteristics listed in various cybersecurity standards and recommended
practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST
Cybersecurity Framework) and Security and Privacy Controls for Information Systems and Organizations(NIST SP 800-53).

208
209
210

You might share the Executive Summary, NIST SP 1800-36A, with your leadership team members to help
them understand the importance of using standards-based trusted IoT device network-layer onboarding
and lifecycle management implementations.

211
212
213
214
215

IT professionals who want to implement similar solutions will find the whole practice guide useful. You
can use the how-to portion of the guide, NIST SP 1800-36C, to replicate all or parts of the builds createdin our lab. The how-to portion of the guide provides specific product installation, configuration, andintegration instructions for implementing the example solution. We do not re-create the productmanufacturers’ documentation, which is generally widely available. Rather, we show how weNIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

2

SECOND PRELIMINARY DRAFT
216
217
218
219
220
221

incorporated the products together in our environment to create an example solution. Also, you can use
Functional Demonstrations, NIST SP 1800-36D, which provides the use cases that have been defined toshowcase trusted IoT device network-layer onboarding and lifecycle management security capabilities
and the results of demonstrating these use cases with each of the example implementations. Finally,
NIST SP 1800-36E will be helpful in explaining the security functionality that the components of eachbuild provide.

222
223
224
225
226
227
228
229

This guide assumes that IT professionals have experience implementing security products within theenterprise. While we have used a suite of commercial products to address this challenge, this guide does
not endorse these particular products. Your organization can adopt this solution or one that adheres tothese guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
parts of a trusted IoT device network-layer onboarding and lifecycle management solution. Your
organization’s security experts should identify the products that will best integrate with your existing
tools and IT system infrastructure. We hope that you will seek products that are congruent withapplicable standards and recommended practices.

230
231
232
233
234

A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is apreliminary draft guide. As the project progresses, the preliminary draft will be updated. We seek
feedback on the publication’s contents and welcome your input. Comments, suggestions, and successstories will improve subsequent versions of this guide. Please contribute your thoughts to iotonboarding@nist.gov.

235
236

2 Risks Addressed by Trusted Network-Layer Onboarding and
Lifecycle Management

237
238
239

Historically IoT devices have not tended to be onboarded to networks in a trusted manner. This has left
networks open to the threat of having unauthorized devices connect to them. It has also left devices
open to the threat of being onboarded to networks that are not authorized to control them.

240

2.1 Risks to the Network

241
242
243
244
245

Unauthorized devices that are able to connect to a network pose many risks to that network. They may
be able to send and receive data on that network, scan the network for vulnerabilities, eavesdrop on thecommunications of other devices, and attack other connected devices to exfiltrate or modify their dataor to compromise those devices and co-opt them into service to launch distributed denial of service(DDoS) attacks.

246

2.1.1 Risks to the Network Due to Device Limitations

247
248
249
250
251
252
253

Many IoT devices are manufactured to be as inexpensive as possible, which sometimes means that thedevices are not equipped with secure storage, cryptographic modules, unique authoritative birthcredentials, or other features needed to enable the devices to be identified and authenticated. This canmake it impossible for a network to determine if a device attempting to connect to it is the intended
device. Lack of these features can also make it impossible to protect the confidentiality of a device’s
network credentials, both during the provisioning process and after the credentials have been installedon the device.
NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

3

SECOND PRELIMINARY DRAFT

254

2.1.2 Risks to the Network Due to Use of Shared Network Credentials

255
256
257
258
259
260

If a network uses a single network password that is shared among all devices rather than providing eachdevice with a unique network credential, the network will be vulnerable to having unauthorized devices
connect to it if the shared network password falls into the wrong hands, which can happen relatively
easily. It also means that the network will permit devices to connect to it simply because a device
presents the correct shared password, regardless of the device’s type or identity, or whether it has any
legitimate reason to connect to the network.

261

2.1.3 Risks to the Network Due to Insecure Network Credential Provisioning

262
263
264
265
266
267
268
269
270
271

If devices are manually provisioned with their network credentials, the provisioning process is errorprone, cumbersome, and vulnerable to having the device’s network credentials disclosed. If the devices
are provisioned automatically over Wi-Fi or some other interface that does not use an encryptedchannel, the credentials are also vulnerable to unauthorized disclosure. If the network credentials are
not provisioned in a trusted manner, the credentials are vulnerable to disclosure not only the first timethe device is onboarded to the network, but every time it is onboarded, which may occur many times
during the device lifecycle. For example, the device may need to be re-onboarded periodically to change
its credentials in accordance with security policy, or it may need to be re-onboarded due to a security
breach, hardware repair, security update, or other reasons. Any insecure features of the onboarding
process, therefore, will render the device and network vulnerable every time the device is onboarded.

272

2.1.4 Risks to the Network Due to Supply Chain Attacks

273
274
275
276
277
278
279

If a device is compromised while in the supply chain or at some other point prior to being onboarded,
then even though the device may be onboarded in a trusted manner, it may still pose a threat to the
network, its data, and all devices connected to it. If, on the other hand, the trusted network-layer
onboarding mechanism is integrated with a device attestation or supply chain management service thatis capable of evaluating the integrity and provenance of the device and detecting that it has been
compromised or may have been tampered with, the trusted network-layer onboarding mechanism
could prevent such a compromised device from being onboarded and connected to the network.

280

2.2 Risks to the Device

281
282
283
284
285
286

Although it is relatively easy for one network to masquerade as another, IoT devices often do not
authenticate the identity of the networks to which they allow themselves to be onboarded andconnected. Devices may be unwittingly tricked into onboarding and connecting to imposter networks
that are not authorized to onboard them. This makes those devices vulnerable to being taken control ofby those unauthorized networks and thereby prevented from connecting to and providing theirintended function on their authorized network.

287

2.3 Risks to Secure Lifecycle Management

288
289
290
291

Even if a device is authorized to connect to a network and the network is authorized to control thedevice, if the device has not been onboarded in a trusted manner, then other security-related
operations that are performed after the device has connected to the network may not have as secure afoundation as they would if the device had been onboarded in a trusted manner. For example, if device
NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

4

SECOND PRELIMINARY DRAFT
292
293
294
295
296
297
298
299
300
301

intent enforcement is performed but the integrity and confidentiality of the communicated device
intent information was not protected (as it would be by a trusted network-layer onboarding
mechanism), then trust in the device intent enforcement mechanism may not be as robust as it could
have been. Similarly, if application-layer onboarding is performed after the device connects, but the
information needed to bootstrap the application-layer onboarding process did not have its integrity andconfidentiality protected (as it would be by a trusted network-layer onboarding mechanism), then trustin the application-layer onboarding mechanism may not be as robust as it could have been. Lack of trustin the application-layer onboarding mechanism may, in turn, undermine trust in the device lifecycle
management or other application-layer service that is invoked as part of the application-layer
onboarding process.

302

2.4 Limitations and Dependencies of Trusted Onboarding

303
304
305
306
307
308
309
310
311
312
313

While implementing trusted IoT device network-layer onboarding and lifecycle management addresses
many risks, it also has limitations. Use of trusted network-layer onboarding is designed to enable IoT
devices to be provisioned with unique local network credentials in a manner that preserves credential
confidentiality. As part of the trusted network-layer onboarding process, the device and the network
may mutually authenticate one another, thereby protecting the network from having unauthorized
devices connect to it and the device from being taken over by an unauthorized network. However, if the
network also enables devices that do not support the trusted network-layer onboarding solution to beprovisioned with network credentials and connect to it using a different (untrusted) onboarding
solution, the network and all devices on it will still be at risk from IoT devices that have been onboarded
using untrusted mechanisms, and the devices that are onboarded using untrusted mechanisms will still
be at risk of being taken over by networks that are not authorized to control them.

314
315
316
317
318
319
320
321
322
323

The trusted network-layer onboarding solution leverages the device’s unique, authoritative birthcredentials, which are provisioned to the device by the device manufacturer and must consist, at aminimum, of a unique device identity and a secret. The trustworthiness of the network-layer onboarding
process and the network credentials that it provisions to the device depends on the uniqueness,
integrity, and confidentiality of the device’s birth credentials which, in many cases, depend on thedevice’s hardware root of trust. If the manufacturer does not ensure that the device’s credentials are
unique, the identity of the device cannot be definitively authenticated. If the manufacturer is not able tomaintain the confidentiality of the secret that is part of the device credentials, the trustworthiness ofthe device authentication process will be undermined, and the channel over which the device’s
credentials are provisioned will be vulnerable to eavesdropping.

324
325
326
327
328
329

The trusted network-layer onboarding solution depends upon the trustworthiness of the device’s securestorage to ensure the confidentiality of the device and network credentials. If the device’s securestorage is vulnerable, the trustworthiness of the network-layer onboarding process and theconfidentiality of the device’s network credentials will be compromised. If the secure storage in which
the device’s network credentials are stored is vulnerable, the network will be at risk of having
unauthorized devices attach to it.

330
331
332

If the trusted network-layer onboarding mechanism is integrated with additional security capabilities
such as device attestation, device communications intent enforcement, application-layer onboarding,and device lifecycle management, it can further increase trust in both the IoT device and, by extension,
NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

5

SECOND PRELIMINARY DRAFT
333
334
335

the network to which the device connects, assuming that these additional security capabilities
themselves are secure and robust. If these security capabilities are not implemented correctly, thenintegrating with them is of no additional value and in fact may provide a false sense of security.

336

3 Mapping Use Cases, Approach, and Terminology

337
338
339
340

A mapping indicates that one concept is related to another concept. The remainder of this volume
describes the mappings between trusted IoT device network-layer onboarding and lifecycle
management cybersecurity functions and the security characteristics enumerated in relevantcybersecurity documents.

341
342
343

For this mapping, we have used the supportive relationship mapping style as defined in Section 4.2 ofdraft NIST Internal Report (IR) 8477, Mapping Relationships Between Documentary Standards,
Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings [1].

344
345

Each set of mappings involves one of the following types of trusted IoT device network-layer onboarding
and lifecycle management cybersecurity functions:

346
347

▪

Cybersecurity functions performed by the reference design’s logical components (see NIST SP
1800-36B Section 4)

348
349

▪

Cybersecurity functions provided by specific network-layer onboarding protocols (e.g., Wi-Fi
Easy Connect and BRSKI)

350
351

▪

Cybersecurity functions provided by builds of the reference design that have been implemented
as part of this project

352
353

Each of the cybersecurity functions is mapped to the security characteristics concepts found in thefollowing widely used cybersecurity guidance documents:

354
355
356
357
358
359
360
361

▪

Subcategories from the NIST Cybersecurity Framework (CSF) 1.1 [2] (Note: Future versions of
this document are expected to map to The NIST Cybersecurity Framework 2.0 (CSF 2.0).) The CSF
identifies enterprise-level security outcomes. Stakeholders have identified these outcomes as
helpful for managing cybersecurity risk, but organizations adopting the CSF need to determine
how to achieve the outcomes. Executive Order (EO) 13800, Strengthening the Cybersecurity ofFederal Networks and Critical Infrastructure [3], made the CSF mandatory for federal
government agencies, and other government agencies and sectors have also made the CSF
mandatory.

362
363
364
365
366
367
368
369
370

▪

Security controls from NIST SP 800-53r5 (Security and Privacy Controls for Information Systems
and Organizations) [4]. NIST SP 800-53 identifies security controls that apply to systems on
which those enterprises are reliant. Which SP 800-53 controls need to be employed depends on
system functions and a risk assessment of the perceived impact of loss of system functionality or
exposure of information from the system to unauthorized entities. In the case of systems owned
by or operated on behalf of federal government enterprises, the risk assessment and applicable
SP 800-53 controls are mandated under the Federal Information Security Modernization Act(FISMA) [5]. Many other governments and private sector organizations voluntarily employ the
Risk Management Framework [6] and associated SP 800-53 controls.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

6

SECOND PRELIMINARY DRAFT

371

3.1 Use Cases

372
373
374
375

All of the elements in these mappings—the trusted IoT device network-layer onboarding and lifecycle
management cybersecurity functions, cybersecurity functions provided by specific network-layer
onboarding protocols, cybersecurity functions provided by specific builds, CSF Subcategories, and SP
800-53 controls—are concepts involving ways to reduce cybersecurity risk.

376
377
378

There are two primary use cases for this mapping. They are not intended to be comprehensive, butrather to capture the strongest relationships involving the trusted IoT device network-layer onboarding
and lifecycle management cybersecurity functions.

379
380
381
382
383
384
385

1. Why should organizations implement trusted IoT device network-layer onboarding andlifecycle management? This use case identifies how implementing trusted IoT device networklayer onboarding and lifecycle management can support organizations with achieving CSF
Subcategories and SP 800-53 controls. This helps communicate to an organization’s chief
information security officer, security team, and senior management that expending resources toimplement trusted IoT device network-layer onboarding and lifecycle management can also aid
in fulfilling other security requirements.

386
387
388
389
390
391
392
393

2. How can organizations implement trusted IoT device network-layer onboarding and lifecycle
management? This use case identifies how an organization’s existing implementations of CSF
Subcategories and SP 800-53 controls can help support a trusted IoT device network-layer
onboarding and lifecycle management implementation. An organization wanting to implement
trusted IoT device network-layer onboarding and lifecycle management might first assess its
current security capabilities so that it can plan how to add missing capabilities and enhanceexisting capabilities. Organizations can leverage their existing security investments and prioritize
future security technology deployment to address the gaps.

394
395
396

These mappings are intended to be used by any organization that is interested in implementing trusted
IoT device network-layer onboarding and lifecycle management or that has begun or completed an
implementation.

397

3.2 Mapping Producers

398
399
400
401
402
403
404
405
406
407
408

The NCCoE trusted IoT device network-layer onboarding and lifecycle management project teamperformed the mappings between the cybersecurity functions performed by the reference design’s
logical components (see NIST SP 1800 36B Section 4) and the security characteristics in the cybersecurity
documents. They also performed the mappings between the cybersecurity functions performed by the
specific network-layer onboarding protocols (i.e., Wi-Fi Easy Connect and BRSKI) and the security
characteristics in the cybersecurity documents. These mappings were performed with input andfeedback from the collaborators who have contributed technology to the builds of the reference design.
Collaborators for each build, in conjunction with the NCCoE trusted IoT device network-layer onboarding
and lifecycle management project team, performed the mappings between the cybersecurity functions
provided by their contributed technologies in each build and the security characteristics in the
cybersecurity documents.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

7

SECOND PRELIMINARY DRAFT

409

3.3 Mapping Approach

410
411
412
413
414

In addition to performing general mappings between the reference design’s cybersecurity functions andvarious sets of security characteristics, as well as between specific network-layer onboarding protocol
cybersecurity functions and various sets of security characteristics, the NCCoE asked the collaboratorsfor each build to indicate the mapping between the cybersecurity functions their technology
components provide in that build and the sets of security characteristics.

415
416
417
418
419

Using the logical components in the reference design as the organizing principle for the initial mappingof cybersecurity functions to security characteristics and then providing onboarding protocol-specificmappings was intended to make it easier for collaborators to map their build-specific technology
contributions. Using this approach, the build-specific technology mappings are instantiations of the
project’s general reference design and protocol-specific mappings for each document.

420

3.3.1 Mapping Terminology

421
422
423
424

In this publication, we use the following relationship types from NIST IR 8477 [1] to describe how thefunctions in our reference design are related to the NIST reference documents. Note that the Supports
relationship applies only to use case 1 in Section 3.1 and the Is Supported By relationship applies only touse case 2.

425
426
427

▪

Supports: Trusted IoT device network-layer onboarding and lifecycle management function X
supports security control/Subcategory/capability/requirement Y when X can be applied alone orin combination with one or more other functions to achieve Y in whole or in part.

428
429
430
431

▪

Is Supported By: Trusted IoT device network-layer onboarding and lifecycle management
function X is supported by security control/Subcategory/capability/requirement Y when Y can beapplied alone or in combination with one or more other security
controls/Subcategories/capabilities/requirements to achieve X in whole or in part.

432

Each Supports and Is Supported By relationship has one of the following properties assigned to it:

433
434

▪

Example of: The supporting concept X is one way (an example) of achieving the supported
concept Y in whole or in part. However, Y could also be achieved without applying X.

435
436

▪

Integral to: The supporting concept X is integral to and a component of the supported concept
Y. X must be applied as part of achieving Y.

437
438

▪

Precedes: The supporting concept X precedes the supported concept Y when X must be
achieved before applying Y. In other words, X is a prerequisite for Y.

439
440
441
442
443

When determining whether a reference design function’s support for a given CSF Subcategory or SP 80053 control is integral to that support versus an example of that support, we do not consider how thatfunction may in general be used to support the Subcategory, control, capability, or requirement. Rather,
we consider only how that function is intended to support that Subcategory, control, capability, or
requirement within the context of our reference design.

444
445
446

Also, when determining whether a function is supported by a CSF Subcategory, SP 800-53 control,capability, etc. with the relationship property of precedes, we do not consider whether it is possible toapply the function without first achieving the Subcategory, control, capability, or requirement. Rather,

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

8

SECOND PRELIMINARY DRAFT
447
448

we consider whether, according to our reference design, the Subcategory, control, capability, or
requirement is to be achieved prior to applying that function.

449

3.3.2 Mapping Process

450
451

The process that the NCCoE used to create the mapping from the logical components of the reference
design to the security characteristics of a given document was as follows:452

1. Create a table that lists each of the logical components of the reference design in column 1.

453

2. Describe each logical component’s cybersecurity function in column 2.

454
455
456
457
458
459

3. Map each cybersecurity function to each of the security characteristics in the document towhich the function is most strongly related, and list each of these security characteristics on
different sub-rows within column 3. Begin each security characteristic entry with an underlined
keyword that describes the mapping’s relationship type (i.e., Supports, Is Supported By). Afterthe keyword indicating the relationship type, put in parentheses the underlined keyword
describing the relationship’s property (i.e., Example of, Integral to, or Precedes).

460
461

4. In the fourth column, provide a brief explanation of why that relationship type and property
apply to the mapping.

462
463
464
465
466
467
468
469
470

5. After completing the mapping table entries as described above for all the logical components in
the reference design, examine the mapping in the other direction, i.e., starting with the security
characteristics listed in the document and considering whether they have a relationship to thelogical components’ cybersecurity functions in the reference design. In other words, step
through each of the security characteristics in the document and determine if there is somelogical component in the reference design that has a strong relationship to that security
characteristic. If so, add an entry for that security characteristic mapping to that logicalcomponent’s row in the table. By examining the mapping in both directions in this manner,
security characteristic mappings are less likely to be overlooked or omitted.

471
472

6. Once these steps are complete, any rows in the table that don’t have any mappings should bedeleted.

473
474
475
476
477

The NCCoE applied this mapping process separately for each reference document. None of the
mappings is intended to be exhaustive; they all focus on the strongest relationships involving eachcybersecurity function in order to help organizations prioritize their work. Mapping every possible
relationship, no matter how tenuous, would create so many mappings that they would not have any
value in prioritization.

478

4 Mappings

479

The mappings are organized in the remainder of this document as follows:

480
481
482

▪

Section 4.1 – NIST CSF 1.1 [2] mappings. These include:oSection 4.1.1 – Mappings between reference design functions and NIST CSF
Subcategories

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

9

SECOND PRELIMINARY DRAFT
483
484

o

Section 4.1.2 – Mappings between specific onboarding protocol (i.e., Wi-Fi Easy Connect
and BRSKI) functions and NIST CSF Subcategories

485

oSection 4.1.3 – Mappings between specific build functions and NIST CSF Subcategories

486▪

Section 4.2 – NIST SP 800-53r5 [4] mappings. These include:

487
488

o

Section 4.2.1 – Mappings between reference design functions and NIST SP 800-53r5
controls

489
490

o

Section 4.2.2 – Mappings between specific onboarding protocol (i.e., Wi-Fi Easy Connect
and BRSKI) functions and NIST SP 800-53r5 controls

491
492

o

Section 4.2.3 – Mappings between specific build functions and NIST SP 800-53r5
controls

493

4.1 NIST CSF Subcategory Mappings

494
495

This section provides mappings between various elements that provide trusted network-layer
onboarding functionality and NIST CSF Subcategories.

496

4.1.1 Mappings Between Reference Design Functions and NIST CSF Subcategories

497
498
499

Table 4-1 provides mappings between the logical components of the reference design and the NIST CSF
Subcategories. This table indicates how trusted IoT device network-layer onboarding and lifecycle
management functions help support CSF Subcategories and vice versa.

500

Table 4-1 Mapping Between Reference Design Logical Components and NIST CSF Subcategories
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

DeviceManufacture
and Factory
Provisioning

Manufactures the IoT
device. Creates, signs, andinstalls the device’s unique
identity and other birthcredentials into securestorage. Installs info thedevice requires forapplication-layer
onboarding (if applicable).
Creates a record of devices
that it has created.

Supports (example of)
ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Information about thedevices (e.g., device model,
ID, onboarding protocol
supported) that the
manufacturer creates will berecorded by the
manufacturer during thefactory provisioning process.
When the device is sold, theinformation will be provided
to the device owner in thepurchase order or otherdocumentation. The owner
may use this information as
the basis of the owner’s
inventory information
regarding devices obtained
from that manufacturer.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

10

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The device owner’s
expectations regarding thecapabilities that the device
should have (e.g., need for
hardware-based securestorage, onboarding-specificfirmware and software, andnetwork- and applicationlayer onboarding
credentials) must be clear
before the manufacturer
creates and provisions thedevice to ensure that thedevice will be equipped to
run the trusted network- andapplication-layer onboarding
protocols that the ownerintends to use.

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The manufacturer’s factory
provisioning process is
responsible for generating
and providing the device
with a unique identity andcredential (i.e., birthcredential) that can be
securely stored andcryptographicallyauthenticated.

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

If the manufacturer installs
device intent information(e.g., the device’s
Manufacturer Usage
Description [MUD] URL) on
the device, this information
can be used by the network
to configure access control
lists (ACLs) on the router orswitch to constrain
communications to and fromthe device according topolicy.

Supports (integral to)
PR.AC-6: Identities are

During factory provisioning,the device’s unique identifier

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

11

SECOND PRELIMINARY DRAFT
LogicalComponent

Supply Chain
Integration
ServiceComponent’s Function

When devices are sold, thisservice is the mechanism
through which the device
manufacturer transfers
device bootstrapping
information to the device
owner, and it may also be
the mechanism forproviding device
ownership information to
the device itself. Device
bootstrapping information
is information (e.g., apublic key that pairs withthe device’s private key)that the device ownerrequires to perform
trusted network-layer
onboarding.

Function’s
Relationships to CSF
Subcategories
proofed and bound tocredentials andasserted ininteractions

Relationship Explanation

Supports (precedes)
ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Bootstrapping informationfor each of the devices thatthe manufacturer createsmust be provided to thedevice owner and correlatedwith the devices in theowner’s inventory
information so the ownerwill be able to authenticate
the devices. In addition,
information regarding which
entity owns a device must berecorded and available forthe device to consult inorder for the device todetermine whether the
network is authorized toonboard the device.

Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The device owner’s
expectations regarding themechanism for transferring
the device bootstrapping
information from the
manufacturer to the device
owner must be made clear
so the manufacturer will use
the expected mechanism(e.g., enrollment of thedevice’s credential into acertificate authority [CA],direct transfer of thebootstrapping information
into the device owner’s
database, or use of a QR

is bound to its device
credential (e.g., its privatekey) by storing the credential
in hardware-based securestorage. This credential iswhat enables the device tohave its asserted identity
authenticated during
onboarding.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

12

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

code that is imprinted on thedevice or its packaging).

Network-Layer
Onboarding
Component

Runs the onboarding
protocol to interact with
the IoT device to perform
one-way or mutual
authentication, establish asecure channel, andsecurely provide local
network credentials to thedevice. May also securely
convey to the IoT device
application-layerbootstrapping information,
the identifier of the
network to which thedevice should onboard,and device intent
information. May interact
with a certificate authority
to sign the certificate
provided to the device aspart of the device’s
network credentials.

Supports (precedes)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The generation and transfer
of device bootstrapping
information from the
manufacturer to the ownermust occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

Bootstrapping information
for all owned devices must
be correlated with thedevice owner’s inventory sothat the bootstrapping
information for theparticular device being
onboarded can be provided
to the network-layer
onboarding component. In
addition, information
regarding which entity owns
a device must be recorded
and available for the device
to consult in order for thedevice to determine whether
the network is authorized toonboard the device.

Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The network-layer
onboarding component of
the device owner must be inpossession of the device
bootstrapping information inorder to authenticate thedevice. The mechanisms bywhich the device
bootstrapping information isconveyed from the device
manufacturer to the device
owner must be defined,

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

13

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

well-understood, andtrusted by both parties.
Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The network-layer
onboarding service is
responsible for providing
authenticated, authorized
devices with a network-layer
credential.

Supports (integral to)
PR.AC-3: Remote
access is managed

Remote access is managed
by ensuring that only devices
that have network-layer
credentials are permitted toconnect to the network
securely. The network-layer
onboarding component is
the component that is
responsible for ensuring that
only authenticated,authorized devices areprovided with network-layer
credentials, and it provides
those credentials in a trusted
fashion that protects theirconfidentiality and helps
prevent them from being
used by unauthorized
devices.

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

If device intent informationis conveyed to the network
onboarding component
during the network-layer
onboarding protocol
exchange, the network
onboarding component will
forward this information to
the appropriate network
component so that ACLs canbe configured on the routeror switch to constrain
communications to and fromthe device according topolicy.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

14

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

The network-layer
onboarding component
authenticates an IoT device’s
identity by using the device’s
public key to verify that thedevice’s private key is
installed on the device.

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security
and privacy risks andother organizationalrisks)The network-layer
onboarding component
authenticates the IoT device.

Is supported by(example of) PR.AT-2:
Privileged users
understand their roles
and responsibilities

In some network-layer
onboarding protocols,participation of a trusted
onboarder is required. This
individual’s role is to provide
the device with the
network’s bootstrapping
information and/or provide
the network with thedevice’s bootstrapping
information. Before doing
so, this individual is
responsible for ensuring thatthe device is authorized to
be onboarded to the
network and the network is
authorized to onboard thedevice.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The network-layer
onboarding component
establishes an encryptedchannel with the IoT device

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

15

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

to ensure the confidentialityof information theyexchange (e.g., the device’s
network-layer credentials).
Access Point,
Router, orSwitchWireless access point (AP)and/or router or switch.
The router may get
configured with per-device
ACLs and policy whendevices are onboarded.

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

When a device is onboarded,
ACLs and policy for thedevice may be configured on
the router or switch toconstrain communications toand from the device
according to policy.

Supports (example of)
PR.AC-5: Network
integrity is protected(e.g., network
segregation, network
segmentation)

When a device is onboarded,
policy for the device may be
configured on the router toassign the device to aparticular network segment.

Network-Layer
Onboarding
Authorization
Service

The authorization service
provides the network
onboarding component
and router with theinformation needed todetermine if the device isauthorized to beonboarded to the network
and, if so, whether itshould be assigned any
special roles or be subject
to any specific access
controls. The authorization
service may also help
enable the device todetermine if the network is
authorized to onboard it.

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

An inventory of IoT devices
belonging to the network
owner must be available forthe network-layer
onboarding authorization
service to consult in orderfor it to determine whether
or not the device isauthorized to be onboarded
to the network.

IoT Device

The IoT device that is used
to demonstrate trusted
network- and applicationlayer onboarding. It runs
the onboarding protocol
and interacts with the
network onboarding

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

The organization must havean inventory of the devices
that support the particulartrusted network-layer
onboarding protocol to be
used on the network (e.g.,
BRSKI or Wi-Fi Easy Connect)

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

16

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

component to perform
one-way or mutual
authentication, establish asecure channel, andsecurely receive its
network credentials. It
may also have additional
security capabilities, suchas performing a secureboot process, performing
trusted firmware updates,and securely conveying its
device intent information.

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

so the organization knows
which devices may be used.
Is supported by(precedes) ID.AM-2:
Software platforms
and applications
within theorganization are
inventoried

If streamlined applicationlayer onboarding is
supported, the device must
either be provisioned with
its application-layerbootstrapping information
prior to network-layer
onboarding or have theability to generate one-time
application-layerbootstrapping information at
runtime. In either case, theorganization must have an
inventory of the devices withthese capabilities so it knows
which devices to use in cases
in which it wants the device
to perform application-layer
onboarding.

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

When the device is equippedwith device intent
information (e.g., a MUD
URL), the device conveys thisinformation to the network
where it can be used toconfigure ACLs on the routeror switch to constrain
communications to and fromthe device according topolicy.

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security

The IoT device may
authenticate the network
before permitting itself to beonboarded to the network.
The IoT device also permits
itself to be authenticated aspart of the network-layer
onboarding process.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

17

SECOND PRELIMINARY DRAFT
LogicalComponent

Secure Storage

Certificate
Authority (CA)Component’s Function

Storage on the IoT device
that is designed to beprotected fromunauthorized access andcapable of detecting
attempts to tamper with
its contents. Used to store
and process private keys,
credentials, and otherinformation that must be
kept confidential.

Issues and signs
certificates as needed.

Function’s
Relationships to CSF
Subcategories
and privacy risks andother organizationalrisks)

Relationship Explanation

Supports (integral to)
PR.DS-2: Data-intransit is protected

The IoT device establishes an
encrypted channel with the
network-layer onboarding
component to ensure theconfidentiality of all
information they exchange(e.g., the device’s networklayer credentials). If
application-layer onboardingis also supported, the IoT
device establishes an
encrypted channel with theapplication-layer service toensure confidentiality of
information exchanged (e.g.,
the device’s applicationlayer credentials).

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The confidentiality provided
to a device’s private key andcredentials by storing andusing them in secure storageis essential to ensuring thatthe device’s identity can be
uniquely authenticated.

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

The device’s private key,which serves as its birthcredential, is installed insecure storage within thedevice, thereby binding thedevice to its credential. The
device may also be bound toits credential using a signed
X.509 certificate.

Supports (integral to)
PR.DS-1: Data-at-rest
is protected

Information stored in securestorage is protected fromunauthorized access anddisclosure.

Supports (example of)
PR.AC-1: Identities andcredentials are issued,

The fact that a credential issigned by a trusted CA
provides a mechanism that

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

18

SECOND PRELIMINARY DRAFT
LogicalComponent

ApplicationLayer
Onboarding
ServiceComponent’s Function

After the device connects
to the network, thiscomponent interacts withthe device using anapplication-layer
onboarding protocol toauthenticate the device,verify that it is authorized
to be application-layer
onboarded, establish asecure channel with it, andsecurely provisionapplication-layer
credentials to it. The
application-layer
credentials will allow thedevice to authenticate toan application-layer
service. The application
layer service may be alifecycle management
service that can be used tosecurely and automatically
update and patch thedevice on an ongoingbasis.

Function’s
Relationships to CSF
Subcategories
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

Relationship Explanation

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

If the device credential is an
X.509 certificate that issigned by a CA, thiscertificate binds the device’s
credential to the device’s
identity.

Is supported by(precedes) ID.AM-2:
Software platforms
and applications
within theorganization are
inventoried

In some application-layer
onboarding mechanisms, theIoT device must be prepared
for application-layer
onboarding during thefactory provisioning process.
In these cases, themanufacturer will create an
inventory of the devices thathave been provisioned foreach application service.

Supports (example of)
ID.AM-2: Software
platforms andapplications within theorganization are
inventoried

The process of applicationlayer onboarding a device
may serve as an automaticmechanism to inventory andkeep track of which devices
have application-related
software installed and are
therefore capable ofinteroperating with theapplication service.

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The application-layer
onboarding service is
responsible for providing
authenticated, authorized
devices with an applicationlayer credential.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The application-layer
onboarding component
establishes an encryptedchannel with the IoT device
to ensure the confidentiality

may be used for enabling thecredential to be verified andrevoked.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

19

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanationof all information theyexchange (e.g., the device’s
application-layer
credentials).
Continuous
Authorization
Service

Performs a set of ongoing,policy-based assurance
and authorization checks
on the IoT device tosupport device lifecycle
monitoring and control.
For example, it may
perform behavioral
analysis or device
attestation and use theresults to determine
whether the device should
be granted access tocertain high-value
resources, assigned to aparticular network
segment, or other action
taken.

Supports (example of)
ID.RA-3: Threats, bothinternal and external,
are identified anddocumented

The ongoing device
authorization service may
perform activities such asdevice attestation andbehavioral analysis to
identify potential threats.

Supports (example of)
ID.RA-5: Threats,vulnerabilities,
likelihoods, andimpacts are used todetermine risk

The ongoing device
authorization service may
perform policy-based
authorization of devices
based on behavioral
analyses, device attestation,and other mechanisms.

Supports (example of)
ID.RA-6: Risk
responses are
identified andprioritized

The ongoing device
authorization service may
quarantine a device, refuse adevice access to the networkor to certain high-value
resources, or take other predefined actions based onpolicy.

Supports (example of)DE.AE-1: A baseline of
network operations
and expected dataflows for users andsystems is establishedand managed

Behavioral analysis
performed as part ofongoing device authorization
may involve comparing
observed activity against abaseline to detect anomalies
and events.

Supports (example of)DE.AE-3: Event data
are collected andcorrelated frommultiple sources andsensors

The ongoing device
authorization service may
collect and correlate datafrom device attestation
services, behavioral analytics
tools, authentication
services, and other sources
as input to its policy-based
assessment of device
authorization.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

20

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

Supports (example of)DE.AE-5: Incident alertthresholds are
established

If the policy-based
assessment of the device
does not meet certain policy
criteria, the device may not
be authorized to accessspecific resources or the
network itself.

Supports (example of)
RS.MI-1: Incidents arecontained

If the policy-based
assessment of the device
does not meet certain policy
criteria, and, as a result, thedevice is denied access tothe network or otherresources, such restriction
may help contain incidents
that involve the device.

502

4.1.2 Mappings Between Specific Onboarding Protocols and NIST CSF
Subcategories

503
504

This section provides mappings between the functionality provided by two network-layer onboarding
protocols, Wi-Fi Easy Connect and BRSKI, and the NIST CSF Subcategories.

505

4.1.2.1 Mapping Between Wi-Fi Easy Connect and NIST CSF Subcategories

506
507
508

Table 4-2 provides a mapping between the functionality provided by the Wi-Fi Easy Connect protocol
and the NIST CSF Subcategories. This table indicates how Wi-Fi Easy Connect functionality helps support
CSF Subcategories and vice versa.

509

Table 4-2 Mapping Between Wi-Fi Easy Connect Functionality and NIST CSF Subcategories

501

Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

DeviceManufacture
and Factory
Provisioning

Manufactures the IoT
device. Installs the device’s
unique private/public key
pair into secure storage,
either by provisioning
these credentials or having
them autonomously
generated. Creates thedevice’s Device
Provisioning Protocol (DPP)

Supports (example of)
ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Information about thedevices (e.g., device model,
onboarding protocol
supported, DPP URI) that the
manufacturer creates will berecorded by the
manufacturer during thefactory provisioning process.
When the device is sold, theinformation will be provided

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

21

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

URI (i.e., the device’sbootstrapping information,
which includes its publickey) and makes a record ofdevices that it has created
and their associated DPP
URIs.

Relationship Explanation

to the device owner in thepurchase order or otherdocumentation. The owner
may use this information as
the basis of the owner’s
inventory information
regarding devices obtained
from that manufacturer.
Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The requirements that thedevice must meet in order tosupport the Wi-Fi Easy
Connect protocol and meetother trusted network- andapplication-layer onboarding
expectations of its users
must be clear to the
manufacturer before it
creates and provisions thedevice to ensure that thedevice will be equipped to
run the trusted network- andapplication-layer onboarding
protocols that the ownerintends to use. For example,
the device will needhardware-based securestorage, Wi-Fi Easy Connectspecific firmware andsoftware, support for one ormore types of network
credentials (e.g., connector,
passphrase, X.509 certificate)and may need to beprovisioned with or beequipped to generatebootstrapping information it
will need to support
streamlined application-layer
onboarding.

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited

The manufacturer’s factory
provisioning process is
responsible for ensuring thatthe device is provisioned
with or autonomously

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

22

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories
for authorized devices,
users, and processes

Relationship Explanation

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

If the manufacturer installs
the device’s MUD URL on thedevice so that it can beprovided to the configurator
as a DPP configuration
request object attributewithin the Wi-Fi Easy
Connect protocol, thisenables the network to use
the device intent informationthat is in the MUD file toconfigure ACLs on the routeror switch to constrain
communications to and fromgenerates its own uniquedevice credential in the formof a private/public key pairthat is securely stored, as
well as the DPP URI
necessary for a configurator
to cryptographicallyauthenticate this device
credential and then provide
the device with its networklayer credential. Also, if the
manufacturer provisions thedevice with application-layer
onboarding bootstrapping
information or equips thedevice with the capability togenerate one-time
application-layerbootstrapping information at
runtime so that it can beprovided to the configurator
as a DPP configuration
request object attributewithin the Wi-Fi Easy
Connect protocol, thisenables the device to be
securely provisioned withapplication-layer credentials
as well.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

23

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

the device according topolicy.

Supply Chain
Integration
Service

When devices are sold, thisservice is the mechanism
through which the device
manufacturer transfers
device bootstrapping
information (e.g., the DPPURI) to the device owner.
When using Wi-Fi Easy
Connect, the device’s
public key, which is
encoded in the DPP URI, isthe device bootstrapping
information that the device
owner requires in order toauthenticate the device,establish a secureconnection to it, andproceed with theremainder of the trusted
network-layer onboarding
process.

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

The device credential that isprovisioned or autonomously
generated during the device
manufacture andprovisioning process (i.e., thedevice’s unique
private/public key pair) is
stored in hardware-based
secure storage. Possession ofthis unique private key iswhat enables the device tohave its asserted identity
authenticated during
onboarding.

Supports (precedes)
ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Bootstrapping information(e.g., the DPP URI) for eachof the devices that the
manufacturer creates must
be provided to the device
owner and correlated withthe devices in the owner’s
inventory so the owner will
be able to authenticate thedevices.

Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The device owner’s
expectations regarding themechanism for transferring
the device bootstrapping
information (i.e., the DPPURI) from the manufacturer
to the device owner must be
made clear so the
manufacturer will use theexpected mechanism (e.g.,
direct transfer of thebootstrapping information
into the device owner’s
database, use of a QR code
encoding of the DPP URI thatis imprinted on the device or
its packaging, encrypted

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

24

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

email listing device and DPP
URI).

Configurator(NetworkLayer
Onboarding
Component)

Runs the onboarding
protocol to interact with
the IoT device to perform
one-way or mutual
authentication, establish asecure channel, andsecurely provide local
network credentials to thedevice. May also securely
convey to the IoT device
application-layerbootstrapping information,
the identifier of the
network to which thedevice should onboard,and device intent
information. May interact
with a certificate authority
to sign the certificate
provided to the device aspart of the device’s
network credentials.

Supports (precedes)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The generation and transfer
of device bootstrapping
information (i.e., the DPPURI) from the manufacturer
to the owner must occur
before the device’s identity
can be cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

The DPP URI for each of thedevices that the
manufacturer creates must
be provided to the device
owner and correlated withthe devices in the owner’s
inventory so the owner will
be able to authenticate thedevices.

Is supported by(precedes) ID.BE-1:
The organization’s rolein the supply chain is
identified andcommunicated

The configurator of thedevice owner must be inpossession of the device
bootstrapping information(i.e., the DPP URI) in order toauthenticate the device. The
mechanisms by which thedevice bootstrapping
information is conveyedfrom the device
manufacturer to theconfigurator via the device
owner must be defined, wellunderstood, and trusted byboth parties.

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The configurator is
responsible for provisioning
authenticated, authorized
devices with their networklayer credentials. In addition,
when the device uses the
DPP configuration request

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

25

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

object to securely convey its
application-layer onboarding
bootstrapping information in
support of streamlined
application-layer onboarding(e.g., via the OCF Information
configuration attribute orother optional third-party
attributes), the configurator
also supports the secureprovisioning of applicationlayer credentials.
Supports (integral to)
PR.AC-3: Remote
access is managed

Remote access is managed
by ensuring that only devices
that have network-layer
credentials are permitted toconnect to the network
securely. The configurator isthe component that is
responsible for ensuring that
only authenticated,authorized devices areprovided with network-layer
credentials, and it provides
those credentials in a trusted
fashion that protects theirconfidentiality and helps
prevent them from being
used by unauthorized
devices.

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

When the device uses theoptional DPP configuration
request object MUD URL
attribute to securely convey
its MUD URL to theconfigurator, theconfigurator supports use of
the device intent informationthat is in the MUD file toconfigure ACLs on the routeror switch that constrain
communications to and fromthe device according topolicy.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

26

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

The configurator
authenticates an IoT device’s
identity by using the device’s
public key to verify that thecorresponding unique
private key is installed on thedevice.

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security
and privacy risks andother organizationalrisks)

The configurator
authenticates the IoT device.

Is supported by(example of) PR.AT-2:
Privileged users
understand their roles
and responsibilities

When using Wi-Fi Easy
Connect, participation of atrusted onboarder may berequired. This individual’srole is to provide the device
with the network’sbootstrapping information
and/or provide the networkwith the device’sbootstrapping information.
For example, this person may
scan the QR codes for thedevices to be onboarded andupload them to a database.
Before doing so, thisindividual is responsible for
ensuring that the device isauthorized to be onboarded
to the network and the
network is authorized toonboard the device. This
trusted onboarder is notprivy to any private keys held

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

27

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanationby the device or the network,
but this onboarder must be
trusted to ensure that thedevice is being onboarded tothe appropriate, authorizednetwork.

Access Point,
Router, orSwitchWireless access point
and/or router or switch.
The Wi-Fi Easy Connect
protocol supports secure
conveyance of device
intent information (e.g.,
the device’s MUD URL) tothe configurator. This MUD
URL may be used by the
network to configure perdevice ACLs and policy
when devices areonboarded.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The configurator establishes
an encrypted channel with
the IoT device to ensure theconfidentiality of information
they exchange (e.g., thedevice’s network-layer
credentials, device intent
information, applicationlayer bootstrapping
information).

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

Wi-Fi Easy Connect uses
special pre-association action
frames. Until the device isauthenticated andonboarded, the only 802.11
frames that are allowed fromthe device are these action
frames; no other traffic ispermitted. After the device isonboarded, all traffic ispermitted, with the following
caveat: if device intent orother policy information forthe device was securely
conveyed by the Wi-Fi Easy
Connect protocol, thisinformation may be used toconfigure ACLs on the routeror switch to constrain
communications to and fromthe device according topolicy.

Supports (example of)
PR.AC-5: Network
integrity is protected(e.g., network

Wi-Fi Easy Connect uses
special pre-association action
frames. Until the device isauthenticated andonboarded, the only 802.11

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

28

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Enrollee (IoT
Device)Component’s Function

The IoT device that is used
to demonstrate trusted
network- and applicationlayer onboarding. It runs
the Wi-Fi Easy Connect
protocol and interacts withthe configurator toperform one-way ormutual authentication,
establish a secure channel,
and securely receive its
network credentials. It may
also have additional
security capabilities, suchas securely conveying its
device intent information
or its application-layer
onboarding bootstrapping
information (e.g., via the
DPP configuration request
object)Function’s
Relationships to CSF
Subcategories
segregation, network
segmentation)

Relationship Explanation

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

The organization must havean inventory of the devices
that support Wi-Fi Easy
Connect onboarding so it
knows which devices to use
in cases in which it wants to
use this protocol to perform
trusted network-layer
onboarding.

Is supported by(precedes) ID.AM-2:
Software platforms
and applications
within theorganization are
inventoried

If streamlined applicationlayer onboarding is
supported, the device must
either be provisioned with its
application-layerbootstrapping information
prior to network-layer
onboarding or have theability to generate one-time
application-layerbootstrapping information at
runtime. In either case, theorganization must have an
inventory of the devices withthese capabilities so it knows
which ones to use in cases inwhich it wants the device toperform application-layer
onboarding.

frames that are allowed fromthe device are these action
frames; no other traffic ispermitted. When a device isonboarded, device intent orother policy information forthe device that is securely
conveyed by the Wi-Fi Easy
Connect protocol may be
used to configured ACLs on
the router in a way thatessentially assigns the device
to a particular network
segment.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

29

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

Supports (example of)
PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

When the device is equippedwith a MUD URL and uses
the optional DPP
configuration request object
MUD URL attribute tosecurely convey this MUD
URL to the configurator, thedevice intent informationthat is in the MUD file can beused to configure ACLs on
the router or switch that
constrain communications toand from the device
according to policy.

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security
and privacy risks andother organizationalrisks)The IoT device may
authenticate the network
before permitting itself to beonboarded to the network.
The IoT device also permits
itself to be authenticated aspart of the network-layer
onboarding process.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The IoT device establishes an
encrypted channel with theconfigurator to ensure theconfidentiality of all
information they exchange(e.g., the device’s networklayer credentials). If
application-layer onboardingis also supported, the IoT
device establishes an
encrypted channel with theapplication-layer service toensure confidentiality of
information exchanged (e.g.,

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management30

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

the device’s application-layer
credentials).
SecureStorage

Certificate
Authority(CA)

Storage on the IoT device
that is designed to beprotected fromunauthorized access andcapable of detecting
attempts to tamper with its
contents. Used to store
and process private keys,
credentials, and otherinformation that must be
kept confidential.

Issues and signs certificatesas needed.

Supports (integral to)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

The confidentiality provided
to a device’s private key bystoring and using it in securestorage is essential toensuring that the device’s
identity can be uniquely
authenticated. Storing thedevice’s network credentials
in secure storage ensures
their confidentiality.

Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

The device’s private key,which serves as its birthcredential, is installed insecure storage within thedevice, thereby binding thedevice to its credential. The
device may also be bound toits credential using a signed
X.509 certificate.

Supports (integral to)
PR.DS-1: Data-at-rest
is protected

Information stored in securestorage is protected fromunauthorized access anddisclosure.

Supports (example of)
PR.AC-1: Identities andcredentials are issued,
managed, verified,
revoked, and audited
for authorized devices,
users, and processes

Network-layer credentials
provisioned by Wi-Fi Easy
Connect may be signed by atrusted CA, enabling them tobe verified and revoked.
Note that although it is not
an X.509 certificate and not
related to a CA, a Wi-Fi Easy
Connect connector is asigned public key. The signee
is the configurator, which istrusted by all devices thatare onboarded to the
network. When the DPP
configurator issues aconnector, it signs theenrollee's protocol key toconstruct the connector. So,

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

31

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s Function

Function’s
Relationships to CSF
Subcategories

Relationship Explanation

the connector is a public key
signed by a trusted 3rd party(the configurator), but it is
not specific to a CA.
Supports (integral to)
PR.AC-6: Identities are
proofed and bound tocredentials andasserted ininteractions

If the network-layer
credential that is provisioned
is an X.509 certificate, then it
will be signed by a CA, andasserted by the device inorder to gain access to the
network.

510

4.1.2.2 Mapping Between BRSKI and NIST CSF Subcategories

511
512
513

Table 4-3 provides a mapping between the functionality provided by BRSKI and the NIST CSF
Subcategories. This table indicates how BRSKI functionality helps support CSF Subcategories and viceversa.

514

Table 4-3 Mapping Between BRSKI Functionality and NIST CSF Subcategories
BRSKI
Component

Component’s Function

Function’s
Relationships to
BRSKI Subcategories

Relationship Explanation

DeviceManufacture
and Factory
Provisioning

Manufactures the IoT
device. Installs/generates
the device’s unique private
key into secure storage andcreates the associatedsigned 802.1AR certificate(i.e., the device’s IDevID).
Provides the location of thedevice’s manufacturer
authorized signing authority(MASA) in an extension to
the IDevID. Provides thedevice with trust anchors
for the MASA entity thatwill sign the returned
vouchers. Installs info thedevice requires forapplication-layer
onboarding (if applicable).
Create a record of devices
that it has created.

Supports (exampleof) ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Information about thedevices (e.g., device model,
ID, onboarding protocol
supported) that the
manufacturer creates will
be recorded by the
manufacturer during thefactory provisioning
process. When the device
is sold, the information will
be provided to the device
owner in the purchaseorder or otherdocumentation. The owner
may use this information
as the basis of the owner’s
inventory information
regarding devices obtained
from that manufacturer.

Is supported by(precedes) ID.BE-1:

The requirements that thedevice must meet in order

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

32

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
BRSKI Subcategories
The organization’srole in the supply
chain is identified
and communicatedRelationship Explanation

Supports (integral to)
PR.AC-1: Identities
and credentials areissued, managed,
verified, revoked, andaudited forauthorized devices,
users, and processes

The manufacturer’s factory
provisioning process is
responsible for ensuringthat the device isprovisioned with orautonomously generates
its own unique device
credential in the form of an
802.1AR certificate(IDevID) and a
private/public key pair thatare securely stored so thatthe identity of the device
can be cryptographicallyauthenticated and thenprovided with its network-

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

to support the BRSKI
protocol and meet othertrusted network- andapplication-layer
onboarding expectations of
its users must be clear to
the manufacturer before it
creates and provisions thedevice to ensure that thedevice will be equipped to
run the trusted networkand application-layer
onboarding protocols thatthe owner intends to use.
For example, the device
will need hardware-based
secure storage, BRSKIspecific firmware andsoftware, and an 802.1AR
certificate (e.g., connector,
passphrase, X.509
certificate) and may need
to be provisioned with orbe equipped to generatebootstrapping information
it will need to support
streamlined applicationlayer onboarding.

33

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
BRSKI Subcategories

Relationship Explanation

layer credential. Also, if the
manufacturer provisions
the device withapplication-layer
onboarding bootstrapping
information or equips thedevice with the capability
to generate one-time
application-layerbootstrapping information
at runtime, this enables thedevice to be securely
provisioned withapplication-layer
credentials as well.

MASA (Supply
Chain
Integration
Service)

The device manufacturer
stores the device’s serial
number and IDevID in the
MASA’s database. Whenthe device is sold, themanufacturer may also
record the device owner
information in the MASA.
Storing this information in
the MASA serves amechanism whereby thedevice manufacturertransfers device
bootstrapping information(i.e., the device’s publickey) to the device owner, as
well as the mechanism forproviding device ownership

Supports (integral to)
PR.AC-6: Identities
are proofed andbound to credentials
and asserted ininteractions

During factory
provisioning, the device’s
802.1AR certificate(IDevID) is bound to its
private key, which is storedin hardware-based securestorage. This credential iswhat enables the device tohave its asserted identity
authenticated during
onboarding.

Supports (precedes)
ID.AM-1: Physicaldevices and systems
within theorganization are
inventoried

Bootstrapping information(e.g., an 802.1AR
certificate) for each of thedevices that the
manufacturer creates must
be provided to the domain
registrar of the device
owner and correlated withthe devices in the owner’s
inventory information so
the owner will be able toauthenticate the devices.
In addition, information
regarding which entity
owns a device must berecorded in the MASA inorder for the device todetermine whether the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

34

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

information to the device
itself. The MASA consults its
stored information andapplies policy to determine
whether or not to approvea registrar’s claim that it
owns a device. If so, it
creates and signs a voucher
that directs the device toaccept its new owner andsends it back to theregistrar.

DomainRegistrar(Network-Layer
Onboarding
Component andNetwork-Layer
Onboarding
Authorization
Service)

Runs the BRSKI onboarding
protocol to interact with
the IoT device and the
MASA. This involves
performing one-way ormutual authentication,
establishing a securechannel, and securely
providing local network
credentials to the device.
Also provides anauthorization function.
Prior to permitting the

Function’s
Relationships to
BRSKI Subcategories

Relationship Explanation

network is authorized toonboard the device.
Supports (precedes)
PR.AC-1: Identities
and credentials areissued, managed,
verified, revoked, andaudited forauthorized devices,
users, and processes

The generation andtransfer of device
bootstrapping information(e.g., device certificate
information) from thedevice manufacturer to thedevice owner must occur
before the device’s identity
can be cryptographicallyauthenticated during
network-layer onboarding
to the device owner’s
network. Also, the transfer
of device ownership
information from thedevice owner to the device
must occur before thedevice will permit itself tobe onboarded to the
network. The transfer ofthis ownership andbootstrapping informationis achieved by storing thedevice ownership
information in a trusted
MASA and having the
MASA generate a signed
voucher attesting to device
ownership assertions.

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within theorganization are
inventoried

The certificate for each of
the devices that the
manufacturer creates,
along with information
regarding whichorganization owns eachdevice is provided to the
MASA. The domain
registrar relies on the
MASA to approve theregistrar’s claim that it
owns a device. This claim
approval will be based on

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

35

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

device to be onboarded, it
examines the pledge
voucher request provided
by the IoT device anddetermines whether thedevice’s manufacturer isknown to it and whether
devices of that type arewelcome on the network.
As part of its authorization
service, it also helps thedevice to determine
whether the network is
authorized to onboard it (byserving as an intermediaryfor the vouchers exchanged
between the device and theMASA).

Function’s
Relationships to
BRSKI Subcategories

Relationship Explanation

the fact that the MASA has
been provided with a list ofdevices that are owned by
the network. This list ofdevice certificatesconstitutes an inventory of
the organization’s devices
that must be in the MASA
prior to onboarding.
Supports (integral to)
PR.AC-1: Identities
and credentials areissued, managed,
verified, revoked, andaudited forauthorized devices,
users, and processes

The domain registrar is
responsible for providing
authenticated, authorized
devices with a networklayer credential.

Supports (integral to)
PR.AC-3: Remote
access is managed

Remote access is managed
by ensuring that only
devices that have networklayer credentials are
permitted to connect tothe network securely. The
domain registrar is thecomponent that is
responsible for ensuringthat only authenticated,authorized devices areprovided with networklayer credentials, and it
provides those credentials
in a trusted fashion that
protects theirconfidentiality and helps
prevent them from being
used by unauthorized
devices.

Supports (integral to)
PR.AC-6: Identities
are proofed andbound to credentials
and asserted ininteractions

The domain registrar
authenticates an IoT
device’s identity by using
the device’s public key toverify that the device’s

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

36

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
BRSKI Subcategories

Relationship Explanation

private key is installed on
the device.

Access Point,
Router, orSwitchPledge (IoT
Device)Wireless access point
and/or router or switch.
The router may get
configured with per-device
ACLs and policy whendevices are onboarded.

The IoT device that is used
to demonstrate trusted
network- and applicationlayer onboarding. It runs

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security
and privacy risks andother organizationalrisks)The domain registrar
authenticates the IoT
device.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The domain registrar
establishes an encryptedchannel with the IoT device
to ensure theconfidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (exampleof) PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation of duties

When a device isonboarded, ACLs andpolicy for the device may
be configured on therouter or switch toconstrain communications
to and from the device
according to policy.

Supports (exampleof) PR.AC-5: Network
integrity is protected(e.g., network
segregation, network
segmentation)

When a device isonboarded, policy for thedevice may be configuredon the router to assign thedevice to a particular
network segment.

Is supported by(precedes) ID.AM-1:
Physical devices andsystems within the

The organization musthave an inventory of thedevices that support BRSKI
onboarding so it knows

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

37

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

the onboarding protocol
and interacts with the
network onboarding
component to perform oneway or mutual
authentication, establish asecure channel, andsecurely request andreceive its network
credentials. It also interacts
with the MASA via signed
vouchers sent to andreceived from the domain
registrar to ensure that the
network that is trying to
onboard it is authorized to
do so before permitting
itself to be onboarded.

Secure Storage

Storage on the IoT device
that is designed to beprotected fromunauthorized access andcapable of detecting
attempts to tamper with its

Function’s
Relationships to
BRSKI Subcategories
organization are
inventoried

Relationship Explanation

Supports (integral to)
PR.AC-7: Users,
devices, and otherassets areauthenticated (e.g.,single-factor,
multifactor)
commensurate withthe risk of thetransaction (e.g.,
individuals’ security
and privacy risks andother organizationalrisks)The IoT device may
authenticate the network
before permitting itself tobe onboarded to the
network. The IoT device
also permits itself to beauthenticated as part of
the network-layer
onboarding process.

Supports (integral to)
PR.DS-2: Data-intransit is protected

The IoT device establishes
an encrypted channel withthe domain registrar toensure the confidentialityof all information theyexchange (e.g., the device’s
network-layer credentials).
If application-layer
onboarding is also
supported, the IoT device
establishes an encryptedchannel with theapplication-layer service toensure confidentiality of
information exchanged(e.g., the device’s
application-layer
credentials).

Supports (integral to)
PR.AC-1: Identities
and credentials areissued, managed,
verified, revoked, andaudited for

The confidentiality
provided to a device’s
private key and credentials
by storing and using themin secure storage isessential to ensuring that

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

which devices to use incases in which it wants to
use this protocol toperform trusted networklayer onboarding.

38

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

contents. Used to store andprocess the device’s privatekey (IDevID), network
credentials (LDevID), andany other information thatmust be kept confidential.

Certificate
Authority (CA)

Issues and signs certificatesas needed.

Function’s
Relationships to
BRSKI Subcategories
authorized devices,
users, and processes

Relationship Explanation

Supports (integral to)
PR.AC-6: Identities
are proofed andbound to credentials
and asserted ininteractions

The device’s private key,which serves as its birthcredential along with its
802.1AR certificate(IDevID), is installed insecure storage within thedevice, thereby binding thedevice to its credential.

Supports (integral to)
PR.DS-1: Data-at-rest
is protected

Information stored insecure storage is protectedfrom unauthorized accessand disclosure.

Supports (exampleof) PR.AC-1:
Identities andcredentials areissued, managed,
verified, revoked, andaudited forauthorized devices,
users, and processes

Network-layer credentials
provisioned by BRSKI aresigned by a trusted CA,
enabling them to beverified and revoked.

Supports (integral to)
PR.AC-6: Identities
are proofed andbound to credentials
and asserted ininteractions

The device credential is an802.1AR certificate (e.g., an
IDevID) that is signed by a
CA. This certificate binds
the device’s credential tothe device’s identity. Also,
all vouchers exchanged aspart of the protocol are
signed, enabling claims
regarding device
ownership to be verified.
Also, the pledge anddomain registrar createand sign voucher requests
using their certificates,
which in turn were signedby the CA.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

the device’s identity can be
uniquely authenticated.

39

SECOND PRELIMINARY DRAFT

515

4.1.3 Mappings Between Specific Builds and NIST CSF Subcategories

516
517
518

This section provides mappings between the functionality provided by builds of the trusted IoT device
network-layer onboarding and lifecycle management reference design that were implemented as part ofthis project and the NIST CSF Subcategories. Mappings are provided only for Build 1 at this time.

519

4.1.3.1 Mapping Between Build 1 and NIST CSF Subcategories

520
521
522
523

Build 1 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol.
The onboarding infrastructure and related technology components for Build 1 have been provided by
Aruba/HPE. IoT devices that were onboarded using Build 1 were provided by Aruba/HPE and CableLabs.
The technologies used in Build 1 are detailed in Appendix C of SP 1800-36B.

524
525

Table 4-4 details the mapping between the functionality provided by Build 1 components and CSF
Subcategories. It indicates how these components help support CSF Subcategories and vice versa.

526

Table 4-4 Mapping Between Functionality of Build 1 Components and NIST CSF Subcategories
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories

Relationship
Explanation

Supply Chain
Integration
Service

Aruba
CentralWhen devices are
sold, this service isthe mechanism
through which thedevice manufacturertransfers device
bootstrapping
information to thedevice owner. The
manufacturer
provides device
bootstrapping
information to the
HPE Cloud via the
Representational
State Transfer (REST)
application
programming
interface (API) that is
documented in the
DPP specification.
Once the device istransferred to an
owner, the HPE Cloud
provides the device
bootstrapping
information (i.e., theSupports(precedes) ID.AM1: Physical devices
and systems within
the organization
are inventoried

Bootstrapping
information for each of
the devices that the
manufacturer createsmust be provided tothe device owner andcorrelated with thedevices in the owner’s
inventory information
so the owner will beable to authenticate
the devices. In addition,
information regarding
which entity owns adevice must berecorded and available
for the device toconsult in order for thedevice to determine
whether the network is
authorized to onboard
the device.

Is supported by(precedes) ID.BE-1:
The organization’srole in the supply

The device owner’s
expectations regarding
the mechanism fortransferring the device
bootstrapping

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

40

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Functiondevice’s DPP URI) to
the device owner’s
private tenancy
within the HPE Cloud.
Device bootstrapping
information is
information (e.g., apublic key that pairs
with the device’s
private key) that thedevice ownerrequires to perform
trusted network-layer
onboarding.

NetworkLayer
Onboarding
Component

Aruba
AccessPoint withsupportfrom Aruba
Central

Runs the Wi-Fi Easy
Connect networklayer onboarding
protocol to interact
with the IoT device toperform one-way ormutualauthentication,
establish a securechannel, and securely
provide local network
credentials to the

Function’s
Relationships to
CSF Subcategories
chain is identified
and communicatedRelationship
Explanation

Supports(precedes) PR.AC1: Identities andcredentials areissued, managed,
verified, revoked,
and audited forauthorized devices,
users, andprocesses

The generation andtransfer of device
bootstrapping
information from the
manufacturer to theowner must occur
before the device’s
identity can be
cryptographicallyauthenticated during
network-layer
onboarding to thedevice owner’s
network.

Is supported by(precedes) ID.AM1: Physical devices
and systems within
the organization
are inventoried

The DPP URI for each of
the devices must be
provided to the device
owner and correlatedwith the devices in theowner’s inventory so
the owner will be able
to authenticate thedevices.

Is supported by(precedes) ID.BE-1:
The organization’s

The configurator of thedevice owner must be
in possession of the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

information from the
manufacturer to thedevice owner must be
made clear so the
manufacturer will use
the expectedmechanism (e.g.,enrollment of thedevice’s credential intoa CA, direct transfer ofthe bootstrapping
information into thedevice owner’s
database, or use of a
QR code that is
imprinted on the device
or its packaging).

41

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Functiondevice. If the network
credential that isbeing provided to thedevice is a certificate,
the onboarding
component willinteract with acertificate authority
to sign the certificate.
The configurator
deployed in Build 1
supports DPP 2.0, but
it is also backward
compatible with DPP
1.0.

Function’s
Relationships to
CSF Subcategories
role in the supply
chain is identified
and communicatedRelationship
Explanation

Supports (integralto) PR.AC-1:
Identities andcredentials areissued, managed,
verified, revoked,
and audited forauthorized devices,
users, andprocesses

The network-layer
onboarding service is
responsible forprovidingauthenticated,authorized devices witha network-layer
credential.

Supports (integralto) PR.AC-3:
Remote access ismanagedRemote access ismanaged by ensuringthat only devices thathave network-layer
credentials are
permitted to connect
to the network
securely. The
configurator is thecomponent that is
responsible for
ensuring that only
authenticated,authorized devices areprovided with networklayer credentials, and it
provides thosecredentials in a trusted

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

device bootstrapping
information (i.e., the
DPP URI) in order toauthenticate thedevice. The
mechanisms by which
the device
bootstrapping
information isconveyed from thedevice manufacturer tothe configurator via thedevice owner must be
defined, wellunderstood, andtrusted by both parties.

42

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories

Relationship
Explanation
fashion that protects
their confidentiality
and helps prevent themfrom being used byunauthorized devices.

Supports (integralto) PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation ofdutiesThe only traffic the AP
will permit being sent
prior to onboarding is
DPP action frames. Allother traffic is dropped.

Supports (integralto) PR.AC-6:
Identities are
proofed and boundto credentials andasserted ininteractions

The configurator
authenticates an IoT
device’s identity byusing the device’s
public key to verify thatthe device’s private key
is installed on thedevice.

Supports (integralto) PR.AC-7: Users,
devices, and otherassets areauthenticated(e.g., single-factor,
multifactor)
commensuratewith the risk of thetransaction (e.g.,
individuals’
security andprivacy risks andotherorganizationalrisks)

The configurator
authenticates the IoT
device.

Is supported by(example of)
PR.AT-2: Privileged
users understandIn this build,participation of atrusted onboarder is
optional. When

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

43

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Access Point,
Router, orSwitch

Product

Aruba
AccessPoint

Component’s
Function

Wireless access pointthat also serves as arouter. It may get
configured with perdevice ACLs andpolicy when devices
are onboarded.

Function’s
Relationships to
CSF Subcategories
their roles andresponsibilities

Relationship
Explanation

Supports (integralto) PR.DS-2: Datain-transit isprotected

The configurator
establishes an
encrypted channel with
the IoT device toensure theconfidentiality of
information theyexchange (e.g., thedevice’s network-layer
credentials).

Supports (exampleof) PR.AC-4: Accesspermissions andauthorizations aremanaged,incorporating theprinciples of leastprivilege andseparation ofdutiesThe only traffic the AP
will permit being sent
prior to onboarding is
DPP action frames. Allother traffic is dropped.
When a device isonboarded, ACLs andpolicy for the device
may be configured on
the router to constrain
communications to andfrom the device
according to policy.

Supports (exampleof) PR.AC-5:
Network integrity
is protected (e.g.,

Wi-Fi Easy Connect
uses special preassociation action
frames. Until the device

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

present, thisindividual’s role is toprovide the networkwith the device’sbootstrapping
information by
uploading the device’s
DPP URIs to a database.
Before doing so, thisindividual is responsible
for ensuring that thedevice is authorized to
be onboarded to the
network and the
network is authorized
to onboard the device.

44

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories
network
segregation,
network
segmentation)

Relationship
Explanation
is authenticated andonboarded, the only
802.11 frames that areallowed from thedevice are these action
frames; no other traffic
is permitted. When adevice is onboarded,
policy for the device
may be configured on
the router to assign thedevice to a particular
network segment.

NetworkLayer
Onboarding
Authorization
Service

Cloud Auth(on Aruba
Central)The authorization
service provides theconfigurator androuter with theinformation needed
to determine if thedevice is authorized
to be onboarded to
the network and, if
so, whether it should
be assigned any
special roles or be
subject to any specificaccess controls. It
provides device
authorization, rolebased access control,
and policy
enforcement.

Is supported by(precedes) ID.AM1: Physical devices
and systems within
the organization
are inventoried

An inventory of IoT
devices belonging to
the network ownermust be available forthe network-layer
onboarding
authorization service toconsult in order for it todetermine whether or
not the device isauthorized to beonboarded to the
network.

Build-specific
IoT Device

Aruba UXI
SensorThe IoT device that isused to demonstrate
both trusted
network-layer
onboarding andtrusted applicationlayer onboarding. It
runs the Wi-Fi Easy
Connect networklayer onboarding
protocol supported

Is supported by(precedes) ID.AM1: Physical devices
and systems within
the organization
are inventoried

The organization musthave an inventory ofthe devices that
support Wi-Fi Easy
Connect network-layer
onboarding so it knows
which devices to use incases in which it wants
to use this protocol.

Is supported by(precedes) ID.AM-

To support UXIapplication-layer

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

45

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Functionby the build tosecurely receive its
network credentials.
It also has anapplication thatenables it to perform
independent
application-layer
onboarding.

Function’s
Relationships to
CSF Subcategories
2: Software
platforms andapplications within
the organization
are inventoried

Relationship
Explanation

Supports (integralto) PR.AC-7: Users,
devices, and otherassets areauthenticated(e.g., single-factor,
multifactor)
commensuratewith the risk of thetransaction (e.g.,
individuals’
security andprivacy risks andotherorganizationalrisks)The IoT device permits
itself to beauthenticated as partof the network-layer
onboarding process.

Supports (integralto) PR.DS-2: Datain-transit isprotected

The IoT device
establishes an
encrypted channel with
the network-layer
onboarding component
to ensure theconfidentiality of all
information they

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

onboarding, the device
must have been
provisioned with its
application-layerbootstrapping
information andsoftware prior to
network-layer
onboarding. The
organization must havean inventory of thedevices with this UXI
application-layer
onboarding capability
so it knows which
devices to use in cases
in which it wants thedevice to perform
application-layer
onboarding.

46

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories

Relationship
Explanationexchange (e.g., thedevice’s network-layer
credentials). In supportof UXI application-layer
onboarding, the IoT
device establishes an
encrypted channel withthe application-layer
onboarding service toensure confidentialityof informationexchanged (e.g., thedevice’s applicationlayer credentials).

Generic IoT
DeviceRaspberryPi

The IoT device that isused to demonstrate
only trusted networklayer onboarding.

Is supported by(precedes) ID.AM1: Physical devices
and systems within
the organization
are inventoried

The organization musthave an inventory ofthe devices that
support Wi-Fi Easy
Connect network-layer
onboarding so it knows
which devices to use incases in which it wants
to use this protocol.

Supports (integralto) PR.AC-7: Users,
devices, and otherassets areauthenticated(e.g., single-factor,
multifactor)
commensuratewith the risk of thetransaction (e.g.,
individuals’
security andprivacy risks andotherorganizationalrisks)The IoT device permits
itself to beauthenticated as partof the network-layer
onboarding process.

Supports (integralto) PR.DS-2: Datain-transit isprotected

The IoT device
establishes an
encrypted channel with
the network-layer

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

47

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories

Relationship
Explanation
onboarding component
to ensure theconfidentiality of all
information theyexchange (e.g., thedevice’s network-layer
credentials). To support
application-layer
onboarding, the IoT
device establishes an
encrypted channel withthe application-layer
service to ensure
confidentiality of information exchanged(e.g., the device’s
application-layer
credentials).

SecureStorageAruba UXI
SensorTrustedPlatform
Module(TPM)

Private CA

Storage on the IoT
device that isdesigned to beprotected fromunauthorized accessand capable ofdetecting attempts totamper with its
contents. Used tostore and process
private keys,
credentials, and otherinformation thatmust be kept
confidential.

Supports (integralto) PR.AC-1:
Identities andcredentials areissued, managed,
verified, revoked,
and audited forauthorized devices,
users, andprocesses

The confidentiality
provided to a device’s
private key andcredentials by storing
and using them insecure storage isessential to ensuringthat the device’s
identity can be
uniquely authenticated.

Supports (integralto) PR.AC-6:
Identities are
proofed and boundto credentials andasserted ininteractions

The device’s private
key, which serves as its
birth credential, isinstalled in securestorage within thedevice, thereby binding
the device to its
credential.

Supports (integralto) PR.DS-1: Dataat-rest is protected

Information stored insecure storage is
protected fromunauthorized accessand disclosure.

Supports (exampleof) PR.AC-1:

Network-layer
credentials provisioned

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

48

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Certificate
Authority (CA)ApplicationLayer
Onboarding
ServiceComponent’s
FunctionIssues and signs
certificates asneeded.

UXIApplicationand UXI
Cloud

After connecting to
the network, thedevice downloads its
application-layer
credentials from the
UXI cloud and uses
these to authenticate
to the UXI application
with which itinteracts.

Function’s
Relationships to
CSF Subcategories
Identities andcredentials areissued, managed,
verified, revoked,
and audited forauthorized devices,
users, andprocesses

Relationship
Explanation

Supports (integralto) PR.AC-6:
Identities are
proofed and boundto credentials andasserted ininteractions

If the network-layer
credential that isprovisioned is an X.509
certificate, then it will
be signed by a CA andasserted by the device
in order to gain accessto the network.

Is supported by(precedes) ID.AM2: Software
platforms andapplications within
the organization
are inventoried

To support UXIapplication-layer
onboarding, the IoT
device must be
prepared for
application-layer
onboarding during thefactory provisioning
process. In these cases,
the manufacturer will
create an inventory ofthe devices that havebeen provisioned foreach application
service.

Supports (integralto) PR.AC-1:
Identities andcredentials areissued, managed,
verified, revoked,
and audited forauthorized devices,
users, andprocesses

The application-layer
onboarding service is
responsible forprovidingauthenticated,authorized devices with
an application-layer
credential.

Supports (integralto) PR.DS-2: Data-

The application-layer
onboarding component

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Managementby this build may besigned by a trusted CA,
enabling them to beverified and revoked.

49

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to
CSF Subcategories
in-transit isprotected

Relationship
Explanation
establishes an
encrypted channel with
the IoT device toensure theconfidentiality of all
information theyexchange (e.g., thedevice’s applicationlayer credentials).

527

4.2 NIST SP 800-53 Control Mappings

528
529

This section provides mappings between various elements that provide trusted network-layer
onboarding functionality and NIST SP 800-53 controls.

530

4.2.1 Mappings Between Reference Design Functions and NIST SP 800-53 Controls

531
532
533
534
535
536
537
538

Table 4-5 provides a mapping between the logical components of the reference design and NIST SP 80053 security controls. This table indicates how trusted IoT device network-layer onboarding and lifecycle
management functions help support NIST SP 800-53 controls. Because hundreds of NIST SP 800-53
controls can help support these functions, we have limited use case 2 (see Section 3.1) mappings to
those controls on which specified supporting controls directly depend (e.g., dependence of
cryptographic protection on key management). Readers needing to determine how their trusted IoT
device network-layer onboarding and lifecycle management implementations support RMF processes
can refer to the SP 800-53 mappings in Table 4-5.

539

Table 4-5 Mapping Between Reference Design Logical Components and NIST SP 800-53 Controls
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

DeviceManufacture
and Factory
Provisioning

Manufactures the IoT device.
Creates, signs, and installs
the device’s unique identityand other birth credentials
into secure storage. Installs
info the device requires forapplication-layer onboarding(if applicable). Creates arecord of devices that it hascreated.

Supports(example of) AC3: Access
Enforcement

Information about the device’s
requirements for network-layer
onboarding (e.g., onboarding
protocol supported) that the
manufacturer creates will berecorded by the manufacturer
during the factory provisioning
process. During factory
provisioning, the device’s
unique identifier is bound to its
device credential (e.g., its
private key) by storing the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

50

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

credential in hardware-based
secure storage. This credential
is what enables the device tohave its asserted identity
authenticated during
onboarding. When the device issold, the information will be
provided to the device owner.
The owner may use thisinformation as the basis of theowner’s implementation ofconnections to the device. If
the manufacturer installs
device intent information (e.g.,
the device’s MUD URL) on thedevice, this information can beused by the network to
configure ACLs on the router orswitch to constrain
communications to and fromthe device according to policy.
Supports(example of) AC4: Information
Flow
Enforcement

Information about the device’s
requirements for network-layer
onboarding (e.g., onboarding
protocol supported) that the
manufacturer creates will berecorded by the manufacturer
during the factory provisioning
process. When the device issold, the information will be
provided to the device owner.
The owner may use thisinformation as the basis of theowner’s implementation ofconnections enabling
information transmitted by thedevice. If the manufacturer
installs device intent
information (e.g., the device’s
MUD URL) on the device, thisinformation can be used by the
network to configure ACLs on
the router or switch to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

51

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

constrain communications toand from the device according
to policy.
Supports(example of) AC6: Least Privilege

If the manufacturer installs
device intent information (e.g.,
the device’s MUD URL) on thedevice, this information can beused by the network to
configure ACLs on the router orswitch to constrain
communications to and fromthe device according to policy.

Supports(example of) CM8: System
Component
Inventory

Information about the devices(e.g., device model, ID,
onboarding protocol
supported) that the
manufacturer creates will berecorded by the manufacturer
during the factory provisioning
process. When the device issold, the information will be
provided to the device owner inthe purchase order or otherdocumentation. The owner
may use this information as thebasis of the owner’s inventory
information regarding devices
obtained from that
manufacturer.

Supports (integralto) IA-3: Device
Identification andAuthentication

During factory provisioning, thedevice’s unique identifier isbound to its device credential(e.g., its private key) by storing
the credential in hardwarebased secure storage. This
credential is what enables thedevice to have its asserted
identity authenticated during
onboarding.

Supports(precedes) IA-9:
Service

In some application-layer
onboarding mechanisms, theIoT device must be prepared

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

52

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls
Identification andAuthentication

Relationship Explanation

Supports(precedes) PM-5:
System Inventory

The owner uses thisinformation in compiling theowner’s organization-wide
inventories information that
includes devices obtained fromthat manufacturer.

Supports(precedes) SR-4:
Provenance

Creation, signing, andinstallation of the device’s
unique identity and other birthcredentials into secure storage
and creation of records ofdevices that the manufacturer
has created support
documentation andmaintenance of the valid
provenance of systemcomponents. During factory
provisioning, the device’s
unique identifier is bound to its
device credential (e.g., its
private key) by storing thecredential in hardware-based
secure storage. This credential

for application-layer
onboarding during the factory
provisioning process. In thesecases, the manufacturer will
create an inventory of thedevices that have been
provisioned for eachapplication service. Signed
information about the device(e.g., device model, ID,
onboarding protocol
supported) created andprovided by the manufacturer
during the factory provisioning
process is used to uniquely
identify and authenticate
necessary authorized services
before establishingcommunications with thedevices.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

53

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

is what enables the device tohave its asserted identity
authenticated during
onboarding.
Supports(example of) SR5: Acquisition
Strategies, Tools,
and Methods

The signed device identities
and records of manufactured
devices can be required inacquisition and procurement
documents to protect against
and mitigate supply chain risks.

Supports(example of) SR11: Component
Authenticity

During factory provisioning, thedevice’s unique identifier isbound to its device credential(e.g., its private key) by storing
the credential in hardwarebased secure storage. This
credential is what enables thedevice to have its asserted
identity authenticated during
onboarding. Signing andinstalling the device’s unique
identity and other birthcredentials into secure storage
supports implementation ofanti-counterfeiting policies andprocedures by providing means
to detect counterfeit
components and prevent themfrom entering the system.

Is supported by(example of) IA-1:
Identification andAuthentication
Policy andProcedures

Customer policies regarding
device access and information
flows inform the
manufacturer’s decisions
regarding information to beprovided about the device’s
requirements for applicationlayer onboarding (e.g.,
onboarding protocol
supported) and recording by
the manufacturer during thefactory provisioning process.
When the device is sold, this

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

54

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

information may be provided tothe device owner. The owner
may use this information as thebasis for acquisition,
installation, and onboarding
decisions.

Supply Chain
Integration
Service

When devices are sold, thisservice is the mechanism
through which the device
manufacturer transfers
device bootstrapping
information to the device
owner, and it may also be
the mechanism for providing
device ownership
information to the device
itself. Device bootstrapping
information is information(e.g., a public key that pairs
with the device’s private key)that the device owner

Is supported by(precedes) IA-4:
Identifier
Management

Management of device
identifiers communicates to the
manufacturer component
identification information used
to enable a record of devices
that it has created to be used
to support conformance toacquisition policies andnotification agreements.

Is supported by(precedes) SR-8:
Notification
Agreements

The role of the manufacturer as
established in notificationagreements with entities
involved in the supply chain forsystems components must be
made clear before it performs
factory provisioning so the
manufacturer can understandwhat onboarding-specifichardware, firmware, andsoftware it must integrate into
the device.

Supports(precedes) AC-3:
AccessEnforcement

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before the device’s
identity can be
cryptographically authenticatedduring network-layer
onboarding to the device
owner’s network.

Supports(precedes) AC-4:
Information Flow
Enforcement

Information about the device’s
requirements for network-layer
onboarding (e.g., onboarding
protocol supported) that the
manufacturer creates will be

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

55

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

requires to perform trusted
network-layer onboarding.

Relationship Explanation

recorded by the manufacturer
during the factory provisioning
process. Note that thegeneration and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before the device’s
identity can be
cryptographically authenticatedduring network-layer
onboarding to the device
owner’s network.
Supports (integralto) CM-8: System
Component
Inventory

Bootstrapping information foreach of the devices that the
manufacturer creates must be
provided to the device ownerand correlated with the devices
in the owner’s inventory
information so the owner will
be able to authenticate thedevices. In addition,
information regarding which
entity owns a device must berecorded and available for thedevice to consult in order forthe device to determine
whether the network is
authorized to onboard thedevice.

Supports(example of) IA-1:
Identification andAuthentication
Policy andProcedures

Cryptographicallyauthenticating devices during
network-layer onboarding to
the device owner’s network canfacilitate an organization’s
identification andauthentication policies andprocedures regarding network
connections to IoT devices. The
network-layer credentials thatare provisioned are unique tothe device and can be used to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

56

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

identify devices on the network
after onboarding has finished.
Supports (integralto) IA-3: Device
Identification andAuthentication

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before the device’s
identity can be
cryptographically authenticatedduring network-layer
onboarding to the device
owner’s network.

Supports(precedes) IA-9:
Service
Identification andAuthentication

Signed device bootstrapping
information is used to uniquely
identify and authenticate
necessary authorized services
before establishingcommunications with thedevices.

Supports(precedes) PM-5:
System Inventory

The device owner uses thebootstrapping information incompiling the owner’sorganization-wide inventory
information that includes
devices obtained from that
manufacturer.

Supports(precedes) SR-4:
Provenance

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before the device’s
identity can be
cryptographically authenticatedduring network-layer
onboarding to the device
owner’s network. Creation,
signing, and installation of thedevice’s unique identity andother birth credentials into
secure storage and creation ofrecords of devices that the
manufacturer has created

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

57

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

support documentation andmaintenance of the valid
provenance of systemcomponents.
Supports(example of) SR5: Acquisition
Strategies, Tools,
and Methods

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before the device’s
identity can be
cryptographically authenticatedduring network-layer
onboarding to the device
owner’s network. These signed
device identities and records ofmanufactured devices can berequired in acquisition andprocurement documents toprotect against and mitigate
supply chain risks.

Supports(example of) SR11: Component
Authenticity

During factory provisioning, thedevice’s unique identifier isbound to its device credential(e.g., its private key) by storing
the credential in hardwarebased secure storage. This
credential is what enables thedevice to have its asserted
identity authenticated during
onboarding. Signing andinstalling the device’s unique
identity and other birthcredentials into secure storage
may support implementation ofanti-counterfeiting policies andprocedures by providing means
to detect counterfeit
components and prevent themfrom entering the system.

Is supported by(precedes) SR-1:
Supply Chain Risk

The device owner’s
expectations regarding themechanism for transferring the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

58

SECOND PRELIMINARY DRAFT
LogicalComponent

Network-Layer
Onboarding
Component

Component’s Function

Runs the onboarding
protocol to interact with theIoT device to perform oneway or mutual
authentication, establish asecure channel, and securely
provide local network
credentials to the device.
May also securely convey to
the IoT device applicationlayer bootstrapping
information, the identifier ofthe network to which thedevice should onboard, anddevice intent information.
May interact with acertificate authority to sign
the certificate provided tothe device as part of thedevice’s network credentials.

Function’s
Relationships to
SP 800-53
Controls
Management
Policy andProcedures

Relationship Explanation

Supports (integralto) AC-1: AccessControl Policy
and Procedures

The network-layer onboarding
service supports
implementation of access
control policies and proceduresby providing authenticated,authorized devices with a
network-layer credential.

Supports (integralto) AC-3: Access
Enforcement

The network-layer onboarding
component supports accessenforcement by authenticating
a connected IoT device’s
identity by using the device’s
public key to verify that thedevice’s private key is installedon the device.

Supports(example of) AC6: Least Privilege

If device intent information isconveyed to the network
onboarding component during
the network-layer onboarding
protocol exchange, the network
onboarding component will
forward this information to theappropriate network
component so that ACLs can be
configured on the router orswitch to constrain

device bootstrapping
information from the
manufacturer to the device
owner are informed by supply
chain risk management policies
and procedures so that the
manufacturer can use expectedmechanisms to enable policy
enforcement (e.g., enrollmentof the device’s credential into aCA, direct transfer of thebootstrapping information into
the device owner’s database, or
use of a QR code that is
imprinted on the device or its
packaging).

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

59

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

communications to and fromthe device according to policy.
Supports (integralto) AC-17:
Remote Access

Remote access is managed byensuring that only devices thathave network-layer credentials
are permitted to connect to the
network securely. The networklayer onboarding component is
the component that is
responsible for ensuring that
only authenticated, authorized
devices are provided with
network-layer credentials, andit provides those credentials ina trusted fashion that protects
their confidentiality and helps
prevent them from being usedby unauthorized devices. Also,
the provisioned credentials are
unique.

Supports(example of) AC19: AccessControl for
Mobile Devices

Where the IoT device is a
mobile device, remote access ismanaged by ensuring that only
devices that have network-layer
credentials are permitted toconnect to the network
securely.

Supports (integralto) AC-20: Use ofExternal Systems

Access to the network fromexternal systems is managed byensuring that only devices thathave network-layer credentials
are permitted to connect toexternal systems.

Supports (integralto) AC-24: AccessControl Decisions

Access control decisions are
enforced by ensuring that only
devices that have network-layer
credentials are permitted toconnect to the network
securely.

Is supported by(precedes CM-8:
SystemBootstrapping information for
all owned devices must be
correlated with the device

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

60

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls
Component
Inventory

Relationship Explanation

Supports (integralto) IA-1:
Identification andAuthentication
Policy andProcedures

The network-layer onboarding
service provides a networklayer credential forauthentication of authorized
devices.

Supports (integralto) IA-3: Device
Identification andAuthentication

The network-layer onboarding
service provides a networklayer credential forauthentication of authorized
devices. Before provisioning adevice with its network-layer
credentials, the configurator
authenticates the device using
the device’s bootstrapping
information.

Supports(precedes) IA-9:
Service
Identification andAuthentication

Signed information about thedevice (e.g., device model, ID,
onboarding protocol
supported) created andprovided by the manufacturer
during the factory provisioning
process is used to uniquely
identify and authenticate
necessary authorized services
before establishingcommunications with thedevices. The network-layer
onboarding service supports

owner’s inventory so that thebootstrapping information forthe particular device being
onboarded can be provided to
the network-layer onboarding
component. In addition,
information regarding which
entity owns a device must berecorded and available for thedevice to consult in order forthe device to determine
whether the network is
authorized to onboard it.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

61

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

service identification andauthentication by providing a
network-layer credential forauthentication of authorized
devices.
Supports (integralto) SC-8:
Transmission
Confidentiality
and Integrity

The network-layer onboarding
component establishes an
encrypted channel with the IoT
device to ensure theconfidentiality of information
they exchange (e.g., thedevice’s network-layer
credentials).

Supports (integralto) SC-15:
Collaborative
Computing
Devices andApplications

When a device is onboarded,
ACLs and policy for the device
are configured on the router orswitch to constrain
communications to and fromthe device according to policy.

Is supported by(precedes) SR-1:
Supply Chain Risk
Management
Policy andProcedures

The network-layer onboarding
component of the device
owner must be in possession of
the device bootstrapping
information in order toauthenticate the device. The
mechanisms by which thedevice bootstrapping
information is conveyed fromthe device manufacturer to thedevice owner must be
consistent with bothmanufacturer and customer
supply chain risk management
policies and procedures.

Is supported by(example of) AT3: Role-Based
Training

In some network-layer
onboarding protocols,participation of a trusted
onboarder is required. This
individual’s role is to provide
the device with the network’sbootstrapping information
and/or provide the network

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

62

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

with the device’s bootstrapping
information. Before doing so,
this individual is responsible for
ensuring that the device isauthorized to be onboarded to
the network and the network is
authorized to onboard thedevice.

Access Point,
Router, orSwitchWireless access point and/orrouter or switch. The router
may get configured with perdevice ACLs and policy whendevices are onboarded.

Is supported by(integral to) SC12: Cryptographic
Key
Establishment
and Management

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
network-layer onboarding
component’s establishment ofan encrypted channel with theIoT device in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports(example of) AC4: Information
Flow
Enforcement

When a device is onboarded,
policy for the device may be
configured on the router toassign the device to a particular
network segment, thus
enforcing approved
authorizations for controllingthe flow of information within
the system and between
connected systems based onorganization-defined
information flow control
policies.

Supports(example of) AC5: Separation of
DutiesWhen a device is onboarded,
ACLs and policy for the device
may be configured on therouter or switch to constrain
communications to and fromthe device according toseparation of duties policies.

Supports(example of) AC6: Least Privilege

When a device is onboarded,
ACLs and policy for the device
may be configured on the

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

63

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanationrouter or switch to constrain
communications to and fromthe device according to leastprivilege policies.

Network-Layer
Onboarding
Authorization
Service

The authorization service
provides the network
onboarding component androuter with the informationneeded to determine if thedevice is authorized to beonboarded to the network
and, if so, whether it should
be assigned any special roles
or be subject to any specificaccess controls. The
authorization service may
also help enable the device

Supports(example of) AC16: Security andPrivacy Attributes

When a device is onboarded,
ACLs and policy for the device
may be configured on therouter or switch to constrain
communications to and fromthe device consistent with
policies regarding permitted
security and privacy attributes.

Supports (integralto) AC-17:
Remote Access

When a device is onboarded,
ACLs and policy for the device
are configured on the router orswitch to constrain
communications to and fromthe device.

Supports (integralto) AC-24: AccessControl Decisions

When a device is onboarded,
ACLs and policy for the device
are configured on the router orswitch to control decisions
regarding communications toand from the device.

Supports(example of) SC7: Boundary
Protection

When a device is onboarded,
policy for the device may be
configured on the router toassign the device to a particular
network segment.

Is supported by(precedes) CM-8:
SystemComponent
Inventory

An inventory of IoT devices
belonging to the network
owner must be available for the
network-layer onboarding
authorization service to consult
in order for it to determine
whether or not the device isauthorized to be onboarded to
the network.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management64

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

Supports(example of) AC6: Least Privilege

When the device is equippedwith device intent information(e.g., a MUD URL), the device
conveys this information to the
network where it can be used
to configure ACLs on the routeror switch to constrain
communications to and fromthe device according to policy.

Supports (integralto) IA-3: Device
Identification andAuthentication

The IoT device may
authenticate the network
before permitting itself to beonboarded to the network. The
IoT device also permits itself to
be authenticated as part of the
network-layer onboarding
process.

Is supported by(precedes) CM-8:
SystemComponent
Inventory

The organization must have an
inventory of the devices that
support the particular trusted
network-layer onboarding
protocol to be used on the
network (e.g., BRSKI or Wi-Fi
Easy Connect) so theorganization knows which
devices may be used. If
streamlined application-layer
onboarding is supported, thedevice must either be
provisioned with its
application-layer bootstrapping
information prior to networklayer onboarding or have theability to generate one-time
application-layer bootstrapping
information at runtime. In
either case, the organizationmust have an inventory of thedevices with these capabilities
so it knows which devices toto determine if the network
is authorized to onboard it.
IoT Device

The IoT device that is used todemonstrate trusted
network- and applicationlayer onboarding. It runs theonboarding protocol andinteracts with the network
onboarding component toperform one-way or mutual
authentication, establish asecure channel, and securely
receive its network
credentials. It may also haveadditional security
capabilities, such as
performing a secure bootprocess, performing trusted
firmware updates, andsecurely conveying its device
intent information.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

65

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

use in cases in which it wants
the device to perform
application-layer onboarding.

Secure Storage

Storage on the IoT device
that is designed to beprotected from unauthorizedaccess and capable ofdetecting attempts totamper with its contents.
Used to store and process
private keys, credentials, andother information that must
be kept confidential.

Supports (integralto) SC-8:
Transmission
Confidentiality
and Integrity

The IoT device establishes an
encrypted channel with the
network-layer onboarding
component to ensure theconfidentiality of all
information they exchange(e.g., the device’s networklayer credentials). If
application-layer onboarding is
also supported, the IoT device
establishes an encryptedchannel with the applicationlayer service to ensure
confidentiality of informationexchanged (e.g., the device’s
application-layer credentials).

Is supported by(precedes) SC-12:
Cryptographic
Key
Establishment
and Management

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (integralto) AC-1: AccessControl Policy
and Procedures

The confidentiality provided toa device’s private key andcredentials by storing and using
them in secure storage isessential to implementation of
the organization’s access
control policy.

Supports (integralto) IA-1: Policy
and Procedures

The confidentiality provided toa device’s private key andcredentials by storing and using
them in secure storage isessential to the effective

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

66

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

implementation of theorganization’s identification
and authentication policies as
they relate to IoT.

Certificate
Authority (CA)

Issues and signs certificatesas needed.

Supports (integralto) AC-3: Access
Enforcement

The secure storage of thedevice’s private key, which
serves as its birth credential
within the device and binds thedevice to its credential, is an
essential element of the accessenforcement mechanism.

Supports (integralto) IA-3: Device
Identification andAuthentication

The confidentiality provided toa device’s private key andcredentials by storing and using
them in secure storage isessential to the effectivenessand security of device
identification andauthentication processes. The
device may also be bound to its
credential using a signed X.509
certificate.

Supports (integralto) SC-28:
Protection ofInformation at
Rest

Information stored in securestorage is protected fromunauthorized access anddisclosure.

Is supported by(precedes) SC-12:
Cryptographic
Key
Establishment
and Management

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (integralto) IA-3: Device
Identification andAuthentication

If the device credential is an
X.509 certificate that is signed
by a trusted CA, this certificate
binds the device’s credential to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

67

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

the device’s identity. It provides
a mechanism for enabling thecredential to be verified andrevoked that is essential to theintegrity of the authentication
process.

ApplicationLayer
Onboarding
Service

After the device connects tothe network, this component
interacts with the device
using an application-layer
onboarding protocol toauthenticate the device,verify that it is authorized tobe application-layer
onboarded, establish asecure channel with it, andsecurely provisionapplication-layer credentials
to it. The application-layer
credentials will allow thedevice to authenticate to an
application-layer service. The
application layer service may
be a lifecycle management
service that can be used tosecurely and automatically
update and patch the device
on an ongoing basis.

Is supported by(precedes) SC-12:
Cryptographic
Key
Establishment
and Management

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports(example of) AC18: WirelessAccess

The application-layer
onboarding component may
establish a wireless encryptedchannel with the IoT device toensure the confidentiality of all
information they exchange(e.g., the device’s applicationlayer credentials).

Supports (integralto) IA-3: Device
Identification andAuthentication

The application-layer
onboarding service is
responsible for providing
authenticated, authorized
devices with an applicationlayer credential.

Supports (integralto) SC-8:
Transmission
Confidentiality
and Integrity

The application-layer
onboarding component
establishes an encryptedchannel with the IoT device toensure the confidentiality of all
information they exchange(e.g., the device’s applicationlayer credentials).

Is supported by(precedes) CM-8:
SystemIn some application-layer
onboarding mechanisms, theIoT device must be prepared

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

68

SECOND PRELIMINARY DRAFT
LogicalComponent

Continuous
Authorization
ServiceComponent’s Function

Performs a set of ongoing,policy-based assurance andauthorization checks on the
IoT device to support device
lifecycle monitoring andcontrol. For example, it may
perform behavioral analysis
or device attestation and use
the results to determine
whether the device should
be granted access to certain
high-value resources,
assigned to a particular
network segment, or otheraction taken.

Function’s
Relationships to
SP 800-53
Controls
Component
Inventory

Relationship Explanation

Supports(example of) RA2: Security
Categorization

The ongoing device
authorization service may
perform activities such asdevice attestation andbehavioral analysis to identify
the impact of system security
breaches.

Supports(example of) RA3: Risk
Assessment

The ongoing device
authorization service may
perform activities such asdevice attestation andbehavioral analysis to identify
potential threats.

Supports(example of) PM10: Authorization
Process

The ongoing device
authorization service may
quarantine a device, refuse adevice access to the network or
to certain high-value resources,
or take other pre-defined
action based on policy.

Supports(example of) AC4: Information
Flow
Enforcement

Behavioral analysis performed
as part of ongoing device
authorization may involve
comparing observed activity

for application-layer
onboarding during the factory
provisioning process. In thesecases, the manufacturer will
create an inventory of thedevices that have been
provisioned for eachapplication service. The processof application-layer onboarding
a device may also serve as an
automatic mechanism toinventory and keep track ofwhich devices have applicationrelated software installed andare therefore capable ofinteroperating with theapplication service.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

69

SECOND PRELIMINARY DRAFT
LogicalComponent

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

against a baseline to detect
anomalies and events.
Supports(example of) CM2: Baseline
Configuration

Behavioral analysis performed
as part of ongoing device
authorization may involve
comparing observed activity
against a baseline to detect
anomalies and events in orderto maintain a baseline
configuration.

Supports(example of) SI-4:
SystemMonitoring

Device lifecycle monitoring may
be used to detect attacks andindicators of potential attacks
as well as anomalous security
configuration changes.

Supports(example of) CA7: Continuous
Monitoring

The ongoing device
authorization service may
collect and correlate data fromdevice attestation services,behavioral analytics tools,
authentication services, andother sources as input to its
policy-based assessment ofdevice authorization.

Supports(example of) IR-4:
Incident HandlingIf the policy-based assessmentof the device does not meet agiven threshold, the device may
not be authorized to accessspecific resources or the
network itself. If theassessment of the device’s
trustworthiness does not meeta given threshold and, as aresult, the device is denied
access to the network or otherresources, such restriction may
help contain incidents thatinvolve the device.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

70

SECOND PRELIMINARY DRAFT

541

4.2.2 Mappings Between Specific Onboarding Protocols and NIST SP 800-53
Controls

542
543
544

This section provides mappings between the functionality provided by specific network-layer
onboarding protocols and the NIST SP 800-53 controls. Mappings are provided for both the Wi-Fi Easy
Connect protocol and BRSKI.

545

4.2.2.1 Mapping Between Wi-Fi Easy Connect and NIST SP 800-53 Controls

546
547
548

Table 4-6 provides a mapping between the functionality provided by the Wi-Fi Easy Connect protocol
and the NIST SP 800-53 controls. This table indicates how Wi-Fi Easy Connect functions help support
NIST SP 800-53 controls and vice versa.

549

Table 4-6 Mapping Between Wi-Fi Easy Connect Functionality and NIST SP 800-53 Controls

540

Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

DeviceManufacture
and Factory
Provisioning

Manufactures the
IoT device. Installs
the device’s unique
private/public key
pair into securestorage, either by
provisioning these
credentials or
having themautonomously
generated. Creates
the device’s DPP
URI (i.e., thedevice’sbootstrapping
information, which
includes its publickey) and makes arecord of devices
that it has created
and theirassociated DPP
URIs.

Supports (example of)AC-6: Least Privilege

If the manufacturer installs thedevice’s MUD URL on the device sothat it can be provided to theconfigurator as a DPP configuration
request object attribute within the WiFi Easy Connect protocol, this enables
the network to use the device intent
information that is in the MUD file toconfigure ACLs on the router or switch
to constrain communications to andfrom the device according to policy.

Supports (example of)CM-8: System
Component Inventory

Information about the devices (e.g.,
device model, onboarding protocol
supported, DPP URI) that the
manufacturer creates will be recordedby the manufacturer during thefactory provisioning process. Whenthe device is sold, the information will
be provided to the device owner inthe purchase order or otherdocumentation. The owner may use
this information as the basis of theowner’s inventory information
regarding devices obtained from that
manufacturer.

Supports (integral to)
IA-2: Identification andAuthentication(Organizational Users)

The manufacturer’s factory
provisioning process is responsible for
ensuring that the device is provisioned
with or autonomously generates its

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

71

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

own unique device credential in theform of a private/public key pair thatis securely stored, as well as the DPP
URI necessary for a configurator to
cryptographically authenticate thisdevice credential and then provide thedevice with its network-layer
credential. Also, if the manufacturer
provisions the device with applicationlayer onboarding bootstrapping
information or equips the device withthe capability to generate one-time
application-layer bootstrapping
information at runtime so that it canbe provided to the configurator as a
DPP configuration request object
attribute within the Wi-Fi Easy
Connect protocol, this enables thedevice to be securely provisioned withapplication-layer credentials as well.
The device credential that isprovisioned or autonomously
generated during the device
manufacture and provisioning process(i.e., the device’s unique
private/public key pair) is stored in
hardware-based secure storage.
Possession of this unique private key
is what enables the device to have its
asserted identity authenticated during
onboarding.
Is supported by(precedes) SR-3:
Supply Chain Controls
and Processes

The requirements that the device
must meet in order to support the WiFi Easy Connect protocol and meetother trusted network- andapplication-layer onboarding
expectations of its users must be clear
to the manufacturer before it createsand provisions the device to ensurethat the device will be equipped to
run the trusted network- andapplication-layer onboarding
protocols that the owner intends touse. For example, the device will need

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management72

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

hardware-based secure storage, Wi-Fi
Easy Connect-specific firmware andsoftware, and support for one or moretypes of network credentials (e.g.,connector, passphrase, X.509
certificate) and may need to beprovisioned with or be equipped togenerate bootstrapping information it
will need to support streamlined
application-layer onboarding.
Supply Chain
Integration
Service

Configurator(NetworkLayer

When devices are
sold, this service isthe mechanism
through which thedevicemanufacturertransfers device
bootstrapping
information (e.g.,
the DPP URI) to thedevice owner.
When using Wi-Fi
Easy Connect, thedevice’s public key,which is encodedin the DPP URI, isthe device
bootstrapping
information thatthe device ownerrequires in order toauthenticate thedevice, establish asecure connection
to it, and proceedwith the remainderof the trusted
network-layer
onboarding
process.

Supports (precedes)
CM-8: System
Component Inventory

Bootstrapping information (e.g., the
DPP URI) for each of the devices thatthe manufacturer creates must be
provided to the device owner andcorrelated with the devices in theowner’s inventory so the owner will
be able to authenticate the devices.

Supports (integral to)
IA-2: Identification andAuthentication(Organizational Users)

The generation and transfer of device
bootstrapping information (i.e., the
DPP URI) from the manufacturer tothe owner must occur before thedevice’s identity can be
cryptographically authenticatedduring network-layer onboarding to
the device owner’s network.

Is supported by(precedes) SR-3:
Supply Chain Controls
and Processes

The device owner’s expectations
regarding the mechanism fortransferring the device bootstrapping
information (i.e., the DPP URI) fromthe manufacturer to the device ownermust be made clear so the
manufacturer will use the expectedmechanism (e.g., direct transfer of thebootstrapping information into thedevice owner’s database, use of a QR
code encoding of the DPP URI that is
imprinted on the device or its
packaging, encrypted email listing
device and DPP URI).

Runs theonboarding
protocol to interact

Supports (integral to)AC-4: Information
Flow Enforcement

The configurator authenticates the IoT
device.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management73

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component
Onboarding
Component)

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

with the IoT device
to perform oneway or mutual
authentication,
establish a securechannel, andsecurely provide
local network
credentials to thedevice. May also
securely convey to
the IoT device
application-layerbootstrapping
information, theidentifier of the
network to which
the device should
onboard, anddevice intent
information. May
interact with acertificate
authority to sign
the certificate
provided to thedevice as part ofthe device’s
networkcredentials.

Supports (example of)AC-6: Least Privilege

When the device uses the optional
DPP configuration request object
MUD URL attribute to securely convey
its MUD URL to the configurator, theconfigurator supports use of thedevice intent information that is in the
MUD file to configure ACLs on therouter or switch that constrain
communications to and from thedevice according to policy.

Supports (integral to)
AC-17: Remote Access

Remote access is managed byensuring that only devices that have
network-layer credentials are
permitted to connect to the network
securely. The configurator is thecomponent that is responsible for
ensuring that only authenticated,authorized devices are provided with
network-layer credentials, and it
provides those credentials in a trusted
fashion that protects theirconfidentiality and helps prevent
them from being used byunauthorized devices. Also, theprovisioned credentials are unique.

Is supported by(example of) AT-3:
Role-Based Training

When using Wi-Fi Easy Connect,
participation of a trusted onboarder
may be required. This individual’s role
is to provide the device with the
network’s bootstrapping information
and/or provide the network with thedevice’s bootstrapping information.
Before doing so, this individual is
responsible for ensuring that thedevice is authorized to be onboarded
to the network and the network is
authorized to onboard the device. This
trusted onboarder is not privy to any
private keys held by the device or the
network, but must be trusted toensure that the device is being
onboarded to the appropriate,
authorized network.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

74

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

Supports (precedes)
CM-8: System
Component Inventory

The DPP URI for each of the devices
that the manufacturer creates must
be provided to the device owner andcorrelated with the devices in theowner’s inventory so the owner will
be able to authenticate the devices.
Bootstrapping information for all
owned devices must be correlatedwith the device owner’s inventory sothat the bootstrapping information forthe particular device being onboarded
can be provided to the network-layer
onboarding component.

Supports (integral to)
IA-3: Device
Identification andAuthentication

The configurator is responsible forprovisioning authenticated,authorized devices with their networklayer credentials. In addition, when
the device uses the DPP configuration
request object to securely convey its
application-layer onboarding
bootstrapping information in supportof streamlined application-layer
onboarding (e.g., via the OCF
Information configuration attribute orother optional third-party attributes),
the configurator also supports the
secure provisioning of applicationlayer credentials. Before provisioning
a device with its network-layer
credentials, the configurator
authenticates the device using thedevice’s bootstrapping information(i.e., its DPP URI).

Supports (integral to)
IA-4: Identifier
Management

The configurator authenticates an IoT
device’s identity by using the device’s
public key to verify that thecorresponding unique private key is
installed on the device.

Supports (integral to)
SC-8: Transmission
Confidentiality andIntegrity

The configurator establishes an
encrypted channel with the IoT device
to ensure the confidentiality of
information they exchange (e.g., thedevice’s network-layer credentials,

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

75

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

device intent information, applicationlayer bootstrapping information).

AccessPoint,
Router, orSwitchEnrollee (IoT
Device)Is supported by(precedes) SR-3:
Supply Chain Controls
and Processes

The configurator of the device ownermust be in possession of the device
bootstrapping information (i.e., the
DPP URI) in order to authenticate thedevice. The mechanisms by which thedevice bootstrapping information isconveyed from the device
manufacturer to the configurator via
the device owner must be defined,
well-understood, and trusted by bothparties.

Wireless accesspoint and/or routeror switch. The WiFi Easy Connect
protocol supports
secure conveyanceof the device’s
device intent
information (e.g.,
the device’s MUD
URL) to theconfigurator. This
MUD URL may be
used by the
network to
configure perdevice ACLs andpolicy whendevices areonboarded.

Supports (example of)AC-6: Least Privilege

Until a device is authenticated andonboarded, the only 802.11 framesthat are allowed from the device are
the special pre-association action
frames that are used by the Wi-Fi Easy
Connect protocol. All other 802.11
frames are blocked until the device isonboarded. When a device isonboarded, device intent and otherpolicy information for the device thatis securely conveyed by the Wi-Fi Easy
Connect protocol may be used toconfigure ACLs on the router or switch
to constrain communications to andfrom the device according to policy.

Supports (example of)
SC-3: Security Function
Isolation

When a device is onboarded, device
intent or other policy information forthe device that is securely conveyed
by the Wi-Fi Easy Connect protocol
may be used to configure ACLs on therouter in a way that essentially assigns
the device to a particular network
segment.

The IoT device thatis used todemonstrate
trusted networkand applicationlayer onboarding.
It runs the Wi-Fi

Supports (example of)AC-6: Least Privilege

When the device is equipped with a
MUD URL and uses the optional DPP
configuration request object MUD URL
attribute to securely convey this MUD
URL to the configurator, the device
intent information that is in the MUD
file can be used to configure ACLs on

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

76

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function
Easy Connect
protocol andinteracts with theconfigurator toperform one-way
or mutualauthentication,
establish a securechannel, andsecurely receive its
networkcredentials. It may
also haveadditional security
capabilities, suchas securely
conveying its
device intent
information or its
application-layer
onboarding
bootstrapping
information (e.g.,
via the DPP
configuration
request object).

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

the router or switch that constrain
communications to and from thedevice according to policy.
Is supported by(precedes) CM-8:
System Component
Inventory

The organization must have an
inventory of the devices that support
Wi-Fi Easy Connect onboarding so it
knows which devices to use in cases inwhich it wants to use this protocol toperform trusted network-layer
onboarding. If streamlined
application-layer onboarding is
supported, the device must either be
provisioned with its application-layerbootstrapping information prior to
network-layer onboarding or have theability to generate one-time
application-layer bootstrapping
information at runtime. In either case,the organization must have an
inventory of the devices with thesecapabilities so it knows which ones touse in cases in which it wants thedevice to perform application-layer
onboarding.

Supports (integral to)
IA-2: Device
Identification andAuthentication

The IoT device may authenticate the
network before permitting itself to beonboarded to the network. The IoT
device also permits itself to beauthenticated as part of the networklayer onboarding process.

Supports (integral to)
SC-8: Transmission
Confidentiality andIntegrity

The IoT device establishes an
encrypted channel with theconfigurator to ensure theconfidentiality of all information theyexchange (e.g., the device’s networklayer credentials). If application-layer
onboarding is also supported, the IoT
device establishes an encryptedchannel with the application-layer
service to ensure confidentiality of
information exchanged (e.g., thedevice’s application-layer credentials).

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

77

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

SecureStorage

Storage on the IoT
device that isdesigned to beprotected fromunauthorizedaccess and capableof detecting
attempts totamper with its
contents. Used tostore and process
private keys,
credentials, andother informationthat must be kept
confidential.

Supports (integral to)
IA-4: Identifier
Management

The confidentiality provided to a
device’s private key by storing andusing it in secure storage is essential
to ensuring that the device’s identity
can be uniquely authenticated. Storing
the device’s network credentials insecure storage ensures theirconfidentiality. The device’s private
key, which serves as its birthcredential, is installed in securestorage within the device, thereby
binding the device to its credential.
The device may also be bound to its
credential using a signed X.509
certificate.

Supports (integral to)
SC-12: Cryptographic
Key Establishment andManagement

The device’s private key, which serves
as its birth credential, is installed insecure storage within the device,
thereby binding the device to its
credential. The device may also bebound to its credential using a signed
X.509 certificate.

Supports (integral to)
SC-28: Protection ofInformation at Rest

Information stored in secure storage is
protected from unauthorized accessand disclosure.

Supports (example of)
IA-4: Identifier
Management

If the network-layer credential that isprovisioned is an X.509 certificate,then it will be signed by a CA andasserted by the device in order to gain
access to the network. Network-layer
credentials provisioned by Wi-Fi Easy
Connect that are signed by a trusted
CA may be verified and revoked. Notethat although it is not an X.509
certificate and not related to a CA, a
Wi-Fi Easy Connect connector is asigned public key. The signee is theconfigurator, which is trusted by all
devices that are onboarded to the
network. When the DPP configurator
issues a connector, it signs theenrollee's protocol key to construct
the connector. So the connector is a

Certificate
Authority(CA)

Issues and signs
certificates asneeded.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

78

SECOND PRELIMINARY DRAFT
Wi-Fi Easy
Connect
Component

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

public key signed by a trusted 3rdparty (the configurator) but it is not
specific to a CA.
550

4.2.2.2 Mapping Between BRSKI and NIST SP 800-53 Controls

551
552

Table 4-7 provides a mapping between the functionality provided by BRSKI and the NIST SP 800-53
controls. This table indicates how BRSKI functions help support NIST SP 800-53 controls and vice versa.

553

Table 4-7 Mapping Between BRSKI Functionality and NIST SP 800-53 Controls
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

DeviceManufacture andFactory
Provisioning

Manufactures the IoT device.
Installs/generates thedevice’s unique private key
into secure storage andcreates the associated signed
802.1AR certificate (i.e., thedevice’s IDevID). Provides thelocation of the device’s MASA
in an extension to the IDevID.
Provides the device with trust
anchors for the MASA entitythat will sign the returned
vouchers. Installs info thedevice requires forapplication-layer onboarding(if applicable). Creates arecord of devices that it hascreated.

Supports(example of) AC3: Access
Enforcement

When the MUD URL isprovisioned to the device,information relating todevice access connections
can be used to manage
connections.

Supports(example of) AC4: Information
Flow
Enforcement

When the MUD URL isprovisioned to the device,information relating todevice access connections
can be used to manage
connections.

Supports(example of) AC6: Least Privilege

If the manufacturer installs
device intent information(e.g., the device’s MUD URL)
on the device, thisinformation can be used by
the network to configure
ACLs on the router or switch
to constrain communications
to and from the device
according to policy.

Supports(example of) AC17: Remote
AccessWhen the MUD URL isprovisioned to the device,information relating todevice access connections
can be used to manage
connections.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

79

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

Supports(example of) CM8: System
Component
Inventory

Information about thedevices (e.g., device model,
ID, onboarding protocol
supported) that the
manufacturer creates will berecorded by the
manufacturer during thefactory provisioning process.
When the device is sold, theinformation will be provided
to the device owner in thepurchase order or otherdocumentation. The owner
may use this information as
the basis of the owner’s
inventory information
regarding devices obtained
from that manufacturer.

Supports(example of) IA3: Device
Identification
andAuthentication

When the MUD URL isprovisioned to the device,information relating todevice access connections
can be used to identify thedevice to a network.

Supports(integral to) IA-4:
Identifier
Management

The manufacturer’s factory
provisioning process is
responsible for ensuring thatthe device is provisioned
with or autonomously
generates its own uniquedevice credential in the formof an 802.1AR certificate(IDevID) and a private/publickeypair that are securely
stored so that the identity ofthe device can be
cryptographicallyauthenticated, and thenprovided with its networklayer credential. Also, if the
manufacturer provisions thedevice with application-layer
onboarding bootstrapping

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

80

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

information or equips thedevice with the capability togenerate one-time
application-layerbootstrapping information at
runtime, this enables thedevice to be securely
provisioned with applicationlayer credentials as well.
During factory provisioning,the device’s 802.1AR
certificate (IDevID) is boundto its private key, which isstored in hardware-based
secure storage. This
credential is what enables
the device to have its
asserted identity
authenticated during
onboarding.
Is supported by(precedes) SR-3:
Supply ChainControls andProcesses

The requirements that thedevice must meet in order tosupport the BRSKI protocol
and meet other trusted
network- and applicationlayer onboarding
expectations of its users
must be clear to the
manufacturer before it
creates and provisions thedevice to ensure that thedevice will be equipped to
run the trusted network- andapplication-layer onboarding
protocols that the ownerintends to use. For example,
the device will needhardware-based securestorage, BRSKI-specificfirmware and software, andan 802.1AR certificate (e.g.,connector, passphrase, X.509
certificate), and may need to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

81

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

be provisioned with or beequipped to generatebootstrapping information it
will need to support
streamlined application-layer
onboarding.
MASA (Supply
Chain Integration
Service)

The device manufacturer
stores the device’s serial
number and IDevID in the
MASA’s database. When thedevice is sold, themanufacturer may also
record the device owner
information in the MASA.
Storing this information in the
MASA serves a mechanism
whereby the device
manufacturer transfers
device bootstrapping
information (i.e., the device’s
public key) to the device
owner, as well as themechanism for providing
device ownership information
to the device itself.
The MASA consults its stored
information and applies
policy to determine whether
or not to approve a registrar’s
claim that it owns a device. If
so, it creates and signs avoucher that directs thedevice to accept its newowner and sends it back to
the registrar.

Supports(precedes) CM-8:
SystemComponent
Inventory

Bootstrapping information(e.g., an 802.1AR certificate)for each of the devices thatthe manufacturer createsmust be provided to thedomain registrar of thedevice owner and correlatedwith the devices in theowner’s inventory
information so the ownerwill be able to authenticate
the devices. In addition,
information regarding which
entity owns a device must berecorded in the MASA inorder for the device todetermine whether the
network is authorized toonboard the device.

Supports(precedes) IA-3:
DeviceIdentification
andAuthentication

The generation and transfer
of device bootstrapping
information (e.g., device
certificate information) fromthe device manufacturer tothe device owner must occur
before the device’s identity
can be cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.
Also, the transfer of device
ownership information fromthe device owner to thedevice must occur before thedevice will permit itself to beonboarded to the network.
The transfer of this

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

82

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

ownership and bootstrapping
information is achieved bystoring the device ownership
information in a trusted
MASA and having the MASA
generate a signed voucher
attesting to device
ownership assertions.
Is supported by(precedes) SR-3:
Supply ChainControls andProcesses

The requirements that thedevice must meet in order tosupport the BRSKI protocol
and meet other trusted
network- and applicationlayer onboarding
expectations of its users
must be clear to the
manufacturer before it
creates and provisions thedevice to ensure that thedevice will be equipped to
run the trusted network- andapplication-layer onboarding
protocols that the ownerintends to use. For example,
the device will needhardware-based securestorage, BRSKI-specificfirmware and software, andan 802.1AR certificate (e.g.,connector, passphrase, X.509
certificate), and may need to
be provisioned with or beequipped to generatebootstrapping information it
will need to support
streamlined application-layer
onboarding. Also, themanufacturer will need tosend the device ownership
information to the device’s
trusted MASA.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

83

SECOND PRELIMINARY DRAFT
BRSKI
Component

Domain Registrar(Network-Layer
Onboarding
Component andNetwork-Layer
Onboarding
Authorization
Service)Component’s Function

Runs the BRSKI onboarding
protocol to interact with theIoT device and the MASA.
This involves performing oneway or mutual
authentication, establishing asecure channel, and securely
providing local network
credentials to the device. Also
provides an authorization
function. Prior to permitting
the device to be onboarded,
it examines the pledge
voucher request provided by
the IoT device anddetermines whether thedevice’s manufacturer isknown to it and whether
devices of that type arewelcome on the network. As
part of its authorization
service, it also helps thedevice to determine whether
the network is authorized toonboard it (by serving as anintermediary for the vouchers
exchanged between thedevice and the MASA).

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

Supports(example of) SR4: Provenance

The transfer of device
ownership information fromthe device owner to thedevice must occur before thedevice will permit itself to beonboarded to the network.
The transfer of thisownership and bootstrapping
information is achieved bystoring the device ownership
information in a trusted
MASA and having the MASA
generate a signed voucher
attesting to device
ownership assertions.

Supports(integral to) AC17: Remote
AccessRemote access is managed
by ensuring that only devices
that have network-layer
credentials are permitted toconnect to the network
securely. The domain
registrar is the component
that is responsible for
ensuring that only
authenticated, authorized
devices are provided with
network-layer credentials,
and it provides thosecredentials in a trusted
fashion that protects theirconfidentiality and helps
prevent them from being
used by unauthorized
devices.

Is supported by(precedes) CM-8:
SystemComponent
Inventory

The certificate for each of
the devices that the
manufacturer creates, alongwith information regarding
which organization owns
each device is provided to
the MASA. The domain
registrar relies on the MASA
to approve the registrar’s

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

84

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

claim that it owns a device.
This claim approval will bebased on the fact that the
MASA has been provided
with a list of devices that are
owned by the network. This
list of device certificatesconstitutes an inventory of
the organization’s devices
that must be in the MASA
prior to onboarding.
Bootstrapping information
for all owned devices must
be correlated with the device
owner’s inventory so that thebootstrapping information
for the particular device
being onboarded can beprovided to the networklayer onboarding
component. In addition,
information regarding which
entity owns a device must berecorded and available forthe device to consult in orderfor the device to determine
whether the network is
authorized to onboard thedevice.
Supports(integral to) IA-3:
DeviceIdentification
andAuthentication

The domain registrar is
responsible for providing
authenticated, authorized
devices with a network-layer
credential. The domain
registrar authenticates an IoT
device’s identity by using thedevice’s public key to verify
that the device’s private key
is installed on the device.

Supports(integral to) SC8: Transmission

The domain registrar
establishes an encryptedchannel with the IoT device
to ensure the confidentiality

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

85

SECOND PRELIMINARY DRAFT
BRSKI
Component

Access Point,
Router, or Switch

Pledge (IoT
Device)Component’s Function

Wireless access point and/orrouter or switch. The routeror switch may get configured
with per-device ACLs andpolicy when devices areonboarded.

The IoT device that is used todemonstrate trusted
network- and applicationlayer onboarding. It runs theonboarding protocol andinteracts with the network
onboarding component toperform one-way or mutual
authentication, establish asecure channel, and securely
request and receive its
network credentials. It alsointeracts with the MASA via
signed vouchers sent to andreceived from the Domain
Registrar to ensure that the
network that is trying to
onboard it is authorized to doso before permitting itself tobe onboarded.

Function’s
Relationships to
SP 800-53
Controls
Confidentiality
and Integrity

Relationship Explanation

Supports(example of) AC6: Least Privilege

When a device is onboarded,
ACLs and policy for thedevice may be configured on
the router to constrain
communications to and fromthe device according topolicy.

Supports(example of) SC3: Security
Function
Isolation

When a device is onboarded,
policy for the device may be
configured on the router orswitch to assign the device toa particular network
segment.

Is supported by(precedes) CM-8:
SystemComponent
Inventory

The organization must havean inventory of the devices
that support BRSKI
onboarding so it knows
which devices to use in cases
in which it wants to use thisprotocol to perform trusted
network-layer onboarding.

Supports(integral to) IA-3:
DeviceIdentification
andAuthentication

The IoT device may
authenticate the network
before permitting itself to beonboarded to the network.
The IoT device also permits
itself to be authenticated aspart of the network-layer
onboarding process.

Supports(integral to) SC8: Transmission
Confidentiality
and Integrity

The IoT device establishes an
encrypted channel with thedomain registrar to ensure
the confidentiality of all
information they exchange(e.g., the device’s networklayer credentials). If
application-layer onboardingis also supported, the IoT
device establishes anof information they exchange(e.g., the device’s networklayer credentials).

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

86

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

encrypted channel with theapplication-layer service toensure confidentiality of
information exchanged (e.g.,
the device’s application-layer
credentials).
Secure Storage

Certificate
Authority (CA)Storage on the IoT device thatis designed to be protectedfrom unauthorized access andcapable of detecting attempts
to tamper with its contents.
Used to store and process thedevice’s private key (IDevID),
network credentials (LDevID),and any other informationthat must be kept
confidential.

Issues and signs certificates asneeded.

Supports(integral to) IA-4:
Identifier
Management

The confidentiality provided
to a device’s private key andcredentials by storing andusing them in secure storageis essential to ensuring thatthe device’s identity can be
uniquely authenticated.

Supports(integral to) SC12:
Cryptographic
Key
Establishment
andManagement

The device’s private key,which serves as its birthcredential along with its
802.1AR certificate (IDevID),
is installed in secure storage
within the device, thereby
binding the device to its
credential.

Supports(integral to) SC28: Protection ofInformation at
Rest

Information stored in securestorage is protected fromunauthorized access anddisclosure.

Supports(integral to) AC16: Security andPrivacy
Attributes

The device credential is an802.1AR certificate (e.g., an
IDevID) that is signed by a
CA. This certificate binds thedevice’s credential to thedevice’s identity. Also, allvouchers exchanged as partof the protocol are signed,
enabling claims regarding
device ownership to beverified. Also, the pledge anddomain registrar create andsign voucher requests using
their certificates, which inturn were signed by the CA.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

87

SECOND PRELIMINARY DRAFT
BRSKI
Component

Component’s Function

Function’s
Relationships to
SP 800-53
Controls

Relationship Explanation

Supports(integral to) SC12:
Cryptographic
Key
Establishment
andManagement

The device credential is an802.1AR certificate (e.g., an
IDevID) that is signed by a
CA. This certificate binds thedevice’s credential to thedevice’s identity. Also, allvouchers exchanged as partof the protocol are signed,
enabling claims regarding
device ownership to beverified. Also, the pledge anddomain registrar create andsign voucher requests using
their certificates, which inturn were signed by the CA.

Supports(example of) SC17: Public Key
Infrastructure
Certificates

Network-layer credentials
provisioned by BRSKI aresigned by a trusted CA,
enabling them to be verified
and revoked.

554

4.2.3 Mappings Between Specific Builds and NIST SP 800-53 Controls

555
556
557

This section provides mappings between the functionality provided by builds of the trusted IoT device
network-layer onboarding and lifecycle management reference design that were implemented as part ofthis project and the NIST SP 800-53 controls. Mappings are provided only for Build 1 at this time.

558

4.2.3.1 Mapping Between Build 1 and NIST SP 800-53 Controls

559
560
561
562

Build 1 is an implementation of network-layer onboarding that uses the Wi-Fi Easy Connect protocol.
The onboarding infrastructure and related technology components for Build 1 have been provided by
Aruba/HPE. IoT devices that were onboarded using Build 1 were provided by Aruba/HPE and CableLabs.
The technologies used in Build 1 are detailed in Appendix C of SP 1800-36B.

563
564

Table 4-8 details the mapping between the functionality provided by Build 1 components and SP 800-53
controls. It indicates how these components help support SP 800-53 controls and vice versa.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

88

SECOND PRELIMINARY DRAFT
565

Table 4-8 Mapping Between Functionality of Build 1 Components and NIST SP 800-53 Controls
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

Supply Chain
Integration
Service

Aruba
CentralWhen devices
are sold, thisservice is themechanism
through which
the device
manufacturertransfers
devicebootstrapping
information to
the device
owner. The
manufacturer
provides device
bootstrapping
information to
the HPE Cloudvia the REST
API that is
documented in
the DPP
specification.
Once thedevice istransferred toan owner, the
HPE Cloudprovides thedevicebootstrapping
information(i.e., thedevice’s DPP
URI) to thedevice owner’s
private tenancy
within the HPE
Cloud. Device
bootstrapping
information is
information

Supports (precedes)
AC-3: Access
Enforcement

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.

Supports (precedes)
AC-4: Information
Flow Enforcement

Information about thedevice’s requirements for
network-layer onboarding(e.g., onboarding protocol
supported) that the
manufacturer creates will berecorded by the manufacturer
during the factory
provisioning process. Notethat the generation andtransfer of device
bootstrapping informationfrom the manufacturer to theowner must occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.

Supports (integralto) CM-8: System
Component
Inventory

Bootstrapping information foreach of the devices that the
manufacturer creates must be
provided to the device ownerand correlated with thedevices in the owner’s
inventory information so theowner will be able toauthenticate the devices. In
addition, information
regarding which entity owns adevice must be recorded andavailable for the device to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

89

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function(e.g., a public
key that pairs
with thedevice’s privatekey) that thedevice ownerrequires toperform
trustednetwork-layer
onboarding.

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

consult in order for the device
to determine whether the
network is authorized toonboard the device.
Supports (exampleof) IA-1:
Identification andAuthentication
Policy andProcedures

Cryptographicallyauthenticating devices during
network-layer onboarding to
the device owner’s network
can facilitate an organization’s
identification andauthentication policies andprocedures regarding network
connections to IoT devices.
The network-layer credentials
that are provisioned are
unique to the device and canbe used to identify devices on
the network after onboarding
has finished.

Supports (integralto) IA-3: Device
Identification andAuthentication

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.

Supports (precedes)
IA-9: Service
Identification andAuthentication

Device bootstrapping
information is used touniquely identify andauthenticate necessary
authorized services before
establishing communications
with the devices.

Supports (precedes)
PM-5: System
Inventory

The owner of the device uses
the bootstrapping informationin compiling the owner’sorganization-wide inventory
information that includes
devices obtained from that
manufacturer.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

90

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

Supports (precedes)
SR-4: Provenance

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.
Creation, signing, andinstallation of the device’s
unique identity and otherbirth credentials into securestorage and creation ofrecords of devices that the
manufacturer has createdsupport documentation andmaintenance of the valid
provenance of systemcomponents.

Supports (exampleof) SR-5: Acquisition
Strategies, Tools,
and Methods

The generation and transfer ofdevice bootstrapping
information from the
manufacturer to the ownermust occur before thedevice’s identity can be
cryptographicallyauthenticated during
network-layer onboarding to
the device owner’s network.
These signed device identities
and records of manufactured
devices can be required inacquisition and procurement
documents to protect against
and mitigate supply chain
risks.

Supports (exampleof) SR-11:
Component
Authenticity

During factory provisioning,the device’s unique identifier
is bound to its device
credential (e.g., its privatekey) by storing the credential
in hardware-based secure

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

91

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

storage. This credential iswhat enables the device tohave its asserted identity
authenticated during
onboarding. Signing andinstalling the device’s unique
identity and other birthcredentials into securestorage may support
implementation of anticounterfeiting policies andprocedures by providing
means to detect counterfeit
components and prevent
them from entering thesystem.

NetworkLayer
Onboarding
Component

Aruba
AccessPoint withsupportfrom
Aruba
CentralWireless accesspoint that also
serves as arouter. Runs
the Wi-Fi Easy
Connect
network-layer
onboarding

Is supported by(precedes) SR-1:
Supply Chain Risk
Management Policy
and Procedures

The device owner’s
expectations regarding themechanism for transferring
the device bootstrapping
information from the
manufacturer to the device
owner are informed by supply
chain risk management
policies and procedures sothat the manufacturer can use
expected mechanisms toenable policy enforcement(e.g., enrollment of thedevice’s credential into a CA,
direct transfer of thebootstrapping information
into the device owner’s
database, use of a QR codethat is imprinted on the device
or its packaging).

Supports (integralto) AC-1: AccessControl Policy andProcedures

The network-layer onboarding
service supports
implementation of access
control policies andprocedures by providing
authenticated, authorized
devices with a network-layer
credential.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

92

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

protocol tointeract with
the IoT device
to perform
one-way ormutualauthentication,
establish asecure channel,
and securely
provide local
networkcredentials tothe device. If
the network
credential thatis being
provided to thedevice is acertificate, theonboarding
component willinteract with acertificate
authority tosign thecertificate. The
configurator
deployed in
Build 1
supports DPP
2.0, but it isalso backward
compatible
with DPP 1.0.

Supports (integralto) AC-3: Access
Enforcement

The network-layer onboarding
component supports accessenforcement byauthenticating a connected
IoT device’s identity by using
the device’s public key toverify that the device’s private
key is installed on the device.

Supports (integralto) AC-17: Remote
AccessRemote access is managed byensuring that only devices
that have network-layer
credentials are permitted toconnect to the network
securely. The network-layer
onboarding component is thecomponent that is responsible
for ensuring that only
authenticated, authorized
devices are provided with
network-layer credentials, andit provides those credentials ina trusted fashion that protects
their confidentiality and helps
prevent them from being usedby unauthorized devices. Also,
the provisioned credentials
are unique.

Supports (exampleof) AC-19: AccessControl for Mobile
Devices

Where the IoT device is a
mobile device, remote access
is managed by ensuring that
only devices that have
network-layer credentials are
permitted to connect to the
network securely.

Supports (integralto) AC-20: Use ofExternal Systems

Access to the network fromexternal systems is managed
by ensuring that only devices
that have network-layer
credentials are permitted toconnect to external systems.

Supports (integralto) AC-24: AccessControl Decisions

Access control decisions are
enforced by ensuring that only
devices that have network-

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

93

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

layer credentials are
permitted to connect to the
network securely.
Supports (integralto) IA-1:
Identification andAuthentication
Policy andProcedures

The network-layer onboarding
service provides a networklayer credential forauthentication of authorized
devices.

Supports (integralto) IA-3: Device
Identification andAuthentication

The network-layer onboarding
service provides a networklayer credential forauthentication of authorized
devices. Before provisioning adevice with its network-layer
credentials, the configurator
authenticates the device using
the device’s bootstrapping
information.

Supports (precedes)
IA-9: Service
Identification andAuthentication

Information about the device(e.g., device model, ID,
onboarding protocol
supported) created andprovided by the manufacturer
during the factory
provisioning process is used touniquely identify andauthenticate necessary
authorized services before
establishing communications
with the devices. The
network-layer onboarding
service supports service
identification andauthentication by providing a
network-layer credential forauthentication of authorized
devices.

Supports (integralto) SC-8:
Transmission
Confidentiality andIntegrity

The network-layer onboarding
component establishes an
encrypted channel with theIoT device to ensure theconfidentiality of information

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

94

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

they exchange (e.g., thedevice’s network-layer
credentials).
Supports (integralto) SC-15:
Collaborative
Computing Devices
and Applications

When a device is onboarded,
ACLs and policy for the device
are configured on the router
to constrain communications
to and from the device
according to policy.

Is supported by(precedes) CM-8:
System Component
Inventory

Bootstrapping information for
all owned devices must be
correlated with the device
owner’s inventory so that thebootstrapping information forthe particular device being
onboarded can be provided to
the network-layer onboarding
component.

Is supported by(precedes) SR-1:
Supply Chain Risk
Management Policy
and Procedures

The network-layer onboarding
component of the device
owner must be in possessionof the device bootstrapping
information in order toauthenticate the device. The
mechanisms by which thedevice bootstrapping
information is conveyed fromthe device manufacturer tothe device owner must be
consistent with bothmanufacturer and customer
supply chain risk management
policies and procedures.

Is supported by(example of) AT-3:
Role-Based Training

In this build, participation of atrusted onboarder is optional.
When present, thisindividual’s role is to provide
the network with the device’sbootstrapping information by
uploading the device’s DPP
URIs to a database. Before
doing so, this individual is
responsible for ensuring that

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

95

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

the device is authorized to beonboarded to the networkand the network is authorized
to onboard the device.

Access Point,
Router, orSwitchAruba
AccessPoint

Wireless accesspoint that also
serves as arouter. It may
get configured
with per-device
ACLs and policy
when devices
are onboarded.

Is supported by(integral to) SC-12:
Cryptographic Key
Establishment andManagement

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
network-layer onboarding
component’s establishment ofan encrypted channel with theIoT device in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (exampleof) AC-4:
Information Flow
Enforcement

When a device is onboarded,
policy for the device may be
configured on the router toassign the device to aparticular network segment,
thus enforcing approved
authorizations for controllingthe flow of information within
the system and between
connected systems based onorganization-defined
information flow control
policies.

Supports (exampleof) AC-5: Separationof Duties

When a device is onboarded,
ACLs and policy for the device
may be configured on therouter to constrain
communications to and fromthe device according toseparation of duties policies.

Supports (exampleof) AC-6: Least
Privilege

When a device is onboarded,
ACLs and policy for the device
may be configured on therouter to constrain
communications to and fromthe device according to leastprivilege policies.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

96

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

NetworkCloud Auth
Layer
(on Aruba
Onboarding
Central)Authorization
ServiceComponent’s
FunctionTheauthorization
serviceprovides theconfigurator
and router withtheinformationneeded todetermine if
the device isauthorized to
be onboarded
to the network
and, if so,whether itshould be
assigned any

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

Supports (exampleof) AC-16: Security
and Privacy
Attributes

When a device is onboarded,
ACLs and policy for the device
may be configured on therouter to constrain
communications to and fromthe device consistent with
policies regarding permitted
security and privacy
attributes.

Supports (integralto) AC-17: Remote
AccessWhen a device is onboarded,
ACLs and policy for the device
are configured on the router
to constrain communications
to and from the device.

Supports (integralto) AC-24: AccessControl Decisions

When a device is onboarded,
ACLs and policy for the device
are configured on the router
to control decisions regarding
communications to and fromthe device.

Supports (exampleof) SC-7: Boundary
Protection

When a device is onboarded,
policy for the device may be
configured on the router toassign the device to aparticular network segment.

Is supported by(precedes) CM-8:
System Component
Inventory

An inventory of IoT devices
belonging to the network
owner must be available forthe network-layer onboarding
authorization service toconsult in order for it todetermine whether or not thedevice is authorized to beonboarded to the network.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

97

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

Supports (integralto) IA-3: Device
Identification andAuthentication

The IoT device permits itself
to be authenticated as part of
the network-layer onboarding
process.

Supports (integralto) SC-8:
Transmission
Confidentiality andIntegrity

The IoT device establishes an
encrypted channel with the
network-layer onboarding
component to ensure theconfidentiality of all
information they exchange(e.g., the device’s networklayer credentials). If
application-layer onboardingis also supported, the IoT
device establishes an
encrypted channel with theapplication-layer service toensure confidentiality of
information exchanged (e.g.,
the device’s application-layer
credentials).

Is supported by(precedes) CM-8:
System Component
Inventory

To support UXI applicationlayer onboarding, the device
must have been provisioned
with its application-layerbootstrapping informationand software prior to
network-layer onboarding.
The organization must have an
inventory of the devices withthis UXI application-layer
onboarding capability so it

special roles or
be subject toany specificaccess controls.
It provides
deviceauthorization,role-based
access control,
and policy
enforcement.
Build-Specific
IoT Device

Aruba UXI
SensorThe IoT device
that is used todemonstrate
both trusted
network-layer
onboarding
and trusted
applicationlayer
onboarding. It
runs the Wi-Fi
Easy Connect
network-layer
onboarding
protocolsupported by
the build tosecurelyreceive its
networkcredentials. It
also has anapplication thatenables it toperform
independent
applicationlayer
onboarding.

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

98

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation

knows which devices to use incases in which it wants thedevice to perform applicationlayer onboarding

Generic IoT
DeviceSecureStorage

RaspberryPi

Aruba UXI
SensorTrustedPlatform

The IoT device
that is used todemonstrate
only trusted
network-layer
onboarding.

Storage on the
IoT device thatis designed to
be protectedfrom

Is supported by(precedes) SC-12:
Cryptographic Key
Establishment andManagement

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (integralto) IA-3: Device
Identification andAuthentication

The IoT device permits itself
to be authenticated as part of
the network-layer onboarding
process.

Supports (integralto) SC-8:
Transmission
Confidentiality andIntegrity

The IoT device establishes an
encrypted channel with the
network-layer onboarding
component to ensure theconfidentiality of all
information they exchange(e.g., the device’s networklayer credentials).

Is supported by(precedes) SC-12:
Cryptographic Key
Establishment andManagement

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (integralto) AC-1: AccessControl Policy andProcedures

The confidentiality provided
to a device’s private key andcredentials by storing andusing them in secure storageis essential to implementation

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

99

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Module(TPM)

unauthorizedaccess andcapable ofdetectingattempts totamper with its
contents. Usedto store andprocess private
keys,
credentials,
and other
informationthat must be
kept
confidential.

Function’s
Relationships to SP
800-53 Controls

Relationship Explanationof the organization’s access
control policy.
Supports (integralto) IA-1: Policy andProcedures

The confidentiality provided
to a device’s private key andcredentials by storing andusing them in secure storageis essential to the effective
implementation of theorganization’s identification
and authentication policies as
they relate to IoT.

Supports (integralto) AC-3: Access
Enforcement

The secure storage of thedevice’s private key, which
serves as its birth credential
within the device and binds
the device to its credential, isan essential element of theaccess enforcement
mechanism.

Supports (integralto) IA-3: Device
Identification andAuthentication

The confidentiality provided
to a device’s private key andcredentials by storing andusing them in secure storageis essential to theeffectiveness and security ofdevice identification andauthentication processes. The
device may also be bound toits credential using a signed
X.509 certificate.

Supports (integralto) SC-28:
Protection ofInformation at Rest

Information stored in securestorage is protected fromunauthorized access anddisclosure.

Is supported by(precedes) SC-12:
Cryptographic Key
Establishment andManagement

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

100

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls

Relationship Explanation(e.g., the device’s networklayer credentials).
Certificate
Authority(CA)

ApplicationLayer
Onboarding
Service

Private CA

UXIApplicationand UXI
Cloud

Issues andsigns
certificates asneeded.

Afterconnecting to
the network,
the device
downloads its
applicationlayer
credentials
from the UXI
cloud and uses
these toauthenticate to
the UXI
application,with which itinteracts.

Supports (integralto) IA-3: Device
Identification andAuthentication

If the device’s network-layer
credential is an X.509
certificate (e.g., an LDevID)that is signed by a trusted CA,
this certificate binds thedevice’s credential to thedevice’s identity. It provides amechanism for enabling thecredential to be verified andrevoked that is essential tothe integrity of theauthentication process.

Is supported by(precedes) SC-12:
Cryptographic Key
Establishment andManagement

Secure establishment andmanagement of cryptographic
keys is a prerequisite for the
IoT device’s establishment ofan encrypted channel with the
network-layer onboarding
component in order to ensure
the confidentiality of
information they exchange(e.g., the device’s networklayer credentials).

Supports (exampleof) AC-18: WirelessAccess

The application-layer
onboarding component may
establish a wireless encryptedchannel with the IoT device toensure the confidentiality of
all information they exchange(e.g., the device’s applicationlayer credentials).

Supports (integralto) IA-3: Device
Identification andAuthentication

The application-layer
onboarding service is
responsible for providing
authenticated, authorized
devices with an applicationlayer credential.

Supports (integralto) SC-8:
Transmission

The application-layer
onboarding component
establishes an encryptedchannel with the IoT device to

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management101

SECOND PRELIMINARY DRAFT
Build 1
Architecture
Component

Product

Component’s
Function

Function’s
Relationships to SP
800-53 Controls
Confidentiality andIntegrity

Relationship Explanation

Is supported by(precedes) CM-8:
System Component
Inventory

To support UXI applicationlayer onboarding, the IoT
device must be prepared for
application-layer onboarding
during the factory
provisioning process. In thesecases, the manufacturer will
create an inventory of thedevices that have been
provisioned for eachapplication service.

ensure the confidentiality of
all information they exchange(e.g., the device’s applicationlayer credentials).

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management

102

SECOND PRELIMINARY DRAFT

566

Appendix A

References

567
568
569
570
571

[1]

K. Scarfone, M. Souppaya, and M. Fagan, Mapping Relationships Between DocumentaryStandards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy
Content Mappings, National Institute of Standards and Technology (NIST) Internal Report (IR)8477, Gaithersburg, Md., August 2023, 26 pp. Available:
https://doi.org/10.6028/NIST.IR.8477.ipd

572
573
574

[2]

Framework for Improving Critical Infrastructure Cybersecurity Version 1.1, National Institute ofStandards and Technology, Gaithersburg, MD, April 2018, 48 pp. Available:
https://doi.org/10.6028/NIST.CSWP.04162018

575
576
577

[3]

Executive Order 13800 (2017) Strengthening the Cybersecurity of Federal Networks and Critical
Infrastructure. (The White House, Washington, DC), DCPD-201700327, May 11, 2017.
https://www.govinfo.gov/app/details/DCPD-201700327

578
579
580
581

[4]

Joint Task Force, Security and Privacy Controls for Information Systems and Organizations,
National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 5,
Gaithersburg, MD, September 2020, 465 pp. Available: https://doi.org/10.6028/NIST.SP.80053r5

582
583
584

[5]

S.2521 - Federal Information Security Modernization Act of 2014, 113th Congress (2013-2014),
Became Public Law No: 113-283, December 18, 2014. Available:
https://www.congress.gov/bill/113th-congress/senate-bill/2521

585
586

[6]

NIST Risk Management Framework. Available: https://csrc.nist.gov/projects/riskmanagement/about-rmf

NIST SP 1800-36E: Trusted IoT Device Network-Layer Onboarding and Lifecycle Management103