Withdrawn Draft
Warning Notice
The attached draft document has been withdrawn, and is provided solely for historical purposes.
It has been superseded by the document identified below.
Withdrawal Date August 11, 2020
Original Release Date February 13, 2020

Superseding Document
Status Final
Series/Number NIST Special Publication 800-207
Title Zero Trust Architecture
Publication Date August 2020
DOI https://doi.org/10.6028/NIST.SP.800-207
CSRC URL https://csrc.nist.gov/publications/detail/sp/800-207/final
Additional Information

1

Draft (2nd) NIST Special Publication 800-207

23

Zero Trust Architecture

4
5

Scott Rose
Oliver Borchert
Stu Mitchell
Sean Connelly

6
7
8
9
10
11
12
13
14
15
16

This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-207-draft2

17

18
19

C O M P U T E R

S E C U R I T Y

20

Draft (2nd) NIST Special Publication 800-207

21
22
23

Zero Trust Architecture

24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

45
46
47
48
49
50
51
52

Scott Rose
Oliver Borchert
Advanced Network Technologies Division
Information Technology Laboratory
Stu Mitchell
Stu2Labs
Stafford, VA
Sean Connelly
Cybersecurity & Infrastructure Security Agency
Department of Homeland Security
This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-207-draft2
February 2020

U.S. Department of Commerce
Wilbur L. Ross, Jr., Secretary

National Institute of Standards and Technology
Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology

53

Authority

54
55
56
57
58
59
60

This publication has been developed by NIST in accordance with its statutory responsibilities under theFederal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law(P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including
minimum requirements for federal information systems, but such standards and guidelines shall not apply
to national security systems without the express approval of appropriate federal officials exercising policy
authority over such systems. This guideline is consistent with the requirements of the Office of Management
and Budget (OMB) Circular A-130.

61
62
63
64
65
66

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory andbinding on federal agencies by the Secretary of Commerce under statutory authority. Nor should theseguidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce,
Director of the OMB, or any other federal official. This publication may be used by nongovernmentalorganizations on a voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.

67
68
69

National Institute of Standards and Technology Special Publication 800-2077071This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-207-draft2

72
73
74
75
76
77
78
79
80
81
82
83
84

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an
experimental procedure or concept adequately. Such identification is not intended to imply recommendation or
endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best
available for the purpose.

Natl. Inst. Stand. Technol. Spec. Publ. 800-207, 58 pages (February 2020)
CODEN: NSPUE2

There may be references in this publication to other publications currently under development by NIST in accordancewith its assigned statutory responsibilities. The information in this publication, including concepts and methodologies,
may be used by federal agencies even before the completion of such companion publications. Thus, until eachpublication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For
planning and transition purposes, federal agencies may wish to closely follow the development of these new
publications by NIST.
Organizations are encouraged to review all draft publications during public comment periods and provide feedback to
NIST. Many NIST cybersecurity publications, other than the ones noted above, are available athttps://csrc.nist.gov/publications.

85
86
87
88
89
90

National Institute of Standards and Technology
Attn: Advanced Network Technologies Division, Information Technology Laboratory
100 Bureau Drive (Mail Stop 8920) Gaithersburg, MD 20899-8920
Email: zerotrust-arch@nist.gov

91

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

Public comment period: February 13, 2020 through March 13, 2020

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

92

Reports on Computer Systems Technology

93
94
95
96
97
98
99
100
101
102

The Information Technology Laboratory (ITL) at the National Institute of Standards andTechnology (NIST) promotes the U.S. economy and public welfare by providing technicalleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test
methods, reference data, proof of concept implementations, and technical analyses to advance thedevelopment and productive use of information technology. ITL’s responsibilities include thedevelopment of management, administrative, technical, and physical standards and guidelines forthe cost-effective security and privacy of other than national security-related information in federal
information systems. The Special Publication 800-series reports on ITL’s research, guidelines, andoutreach efforts in information system security, and its collaborative activities with industry,
government, and academic organizations.

103

Abstract

104
105
106
107
108
109
110
111
112
113
114
115
116

Zero trust (ZT) is the term for an evolving set of cybersecurity paradigms that move network
defenses from static, network-based perimeters to focus on users, assets, and resources. A zerotrust architecture (ZTA) uses zero trust principles to plan enterprise infrastructure andworkflows. Zero trust assumes there is no implicit trust granted to assets or user accounts based
solely on their physical or network location (i.e., local area networks versus the internet).
Authentication and authorization (both user and device) are discrete functions performed before
a session to an enterprise resource is established. Zero trust is a response to enterprise network
trends that include remote users and cloud-based assets that are not located within an enterpriseowned network boundary. Zero trust focus on protecting resources, not network segments, as the
network location is no longer seen as the prime component to the security posture of theresource. This document contains an abstract definition of zero trust architecture (ZTA) andgives general deployment models and use cases where zero trust could improve an enterprise’s
overall information technology security posture.

117

Keywords

118

architecture; cybersecurity; enterprise; network security; zero trust.

119

ii

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

120

Acknowledgments

121
122
123
124
125
126

This document is the product of a collaboration between multiple federal agencies and isoverseen by the Federal CIO Council. The architecture subgroup is responsible for developmentof this document, but there are specific individuals who deserve recognition. These include Greg
Holden, project manager of the Federal CIO Council ZTA project; Alper Kerman, project
manager for the NIST/National Cybersecurity Center of Excellence ZTA effort; and Douglas
Montgomery.

127

Audience

128
129
130
131
132
133
134
135

This document is intended to describe zero trust for enterprise security architects. It is meant toaid understanding of zero trust for civilian unclassified systems and provide a road map tomigrate and deploy zero trust security concepts to an enterprise environment. Agency
cybersecurity managers, network administrators, and managers may also gain insight into zerotrust and ZTA from this document. It is not intended to be a single deployment plan for ZTA asan enterprise will have unique business use cases and data assets that require protection. Startingwith a solid understanding of the organization’s business and data will result in a strong
approach to zero trust.

136

Note to Reviewers

137
138
139
140
141

The purpose of this Special Publication is to develop a technology-neutral set of terms,
definitions, and logical architectural components to develop and support a ZTA. This document
does not give specific guidance or recommendations on how to deploy zero trust components inan enterprise. Reviewers are asked to tailor their comments based on the stated purpose of the
document.

142

Trademark Information

143
144

All registered trademarks or trademarks belong to their respective organizations.

iii

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

145

Call for Patent Claims

146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180

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 bedirectly stated in this ITL Publication or by reference to another publication. This call also
includes disclosure, where known, of the existence of pending U.S. or foreign patent applications
relating to this ITL draft publication and of any relevant unexpired U.S. or foreign patents.
ITL may require from the patent holder, or a party authorized to make assurances on its behalf,in written or electronic form, either:a) assurance in the form of a general disclaimer to the effect that such party does not hold anddoes not currently intend holding any essential patent claim(s); orb) 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 requirementsin this ITL draft publication either:i.

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

without compensation and under reasonable terms and conditions that aredemonstrably free of any unfair discrimination.

Such assurance shall indicate that the patent holder (or third party authorized to make assuranceson its behalf) will include in any documents transferring ownership of patents subject to theassurance, 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 with the goal of binding each successor-in-interest.
The assurance shall also indicate that it is intended to be binding on successors-in-interest
regardless of whether such provisions are included in the relevant transfer documents.
Such statements should be addressed to: zerotrust-arch@nist.gov

iv

NIST SP 800-207 (SECOND DRAFT)

Table of Contents

181
182

ZERO TRUST ARCHITECTURE

1Introduction ............................................................................................................ 1183

1.1 History of Zero Trust Efforts Related to Federal Agencies .............................. 2184

1.2 Structure of This Document ............................................................................ 2

185

2

Zero Trust Basics ................................................................................................... 4186

2.1 Tenets of Zero Trust ....................................................................................... 6

187

2.2 A Zero Trust View of a Network ...................................................................... 7

188

2.2.1 Assumptions for Enterprise-Owned Network Infrastructure .................. 8

189

2.2.2 Assumptions for Nonenterprise-Owned Network Infrastructure............ 8

190

3

Logical Components of Zero Trust Architecture................................................. 9191

3.1 Variations of Zero Trust Architecture Approaches ........................................ 11192

3.1.1 ZTA Using Enhanced Identity Governance ........................................ 11193

3.1.2 ZTA Using Micro-Segmentation ......................................................... 12194

3.1.3 ZTA Using Network Infrastructure and Software Defined Perimeters . 12

195

3.2 Deployed Variations of the Abstract Architecture .......................................... 12196

3.2.1 Device Agent/Gateway-Based Deployment........................................ 13

197

3.2.2 Enclave-Based Deployment ............................................................... 14198

3.2.3 Resource Portal-Based Deployment .................................................. 14199

3.2.4 Device Application Sandboxing .......................................................... 15200

3.3 Trust Algorithm.............................................................................................. 16

201

3.3.1 Trust Algorithm Variations .................................................................. 18202

3.4 Network/Environment Components .............................................................. 20203

3.4.1 Network Requirements to Support ZTA .............................................. 20

204

4

Deployment Scenarios/Use Cases ..................................................................... 22205

4.1 Enterprise with Satellite Facilities.................................................................. 22206

4.2 Multicloud Enterprise .................................................................................... 23207

4.3 Enterprise with Contracted Services and/or Nonemployee Access .............. 24

208

4.4 Collaboration Across Enterprise Boundaries ................................................ 25

209

4.5 Enterprise with Public- or Customer-Facing Services ................................... 26

210

5

Threats Associated with Zero Trust Architecture ............................................. 27

211

5.1 Subversion of ZTA Decision Process............................................................ 27212

5.2 Denial-of-Service or Network Disruption ....................................................... 27v

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

213

5.3 Stolen Credentials/Insider Threat.................................................................. 28

214

5.4 Visibility on the Network ................................................................................ 28215

5.5 Storage of Network Information .................................................................... 29216

5.6 Reliance on Proprietary Data Formats .......................................................... 29217

5.7 Use of Nonperson Entities (NPE) in ZTA Administration .............................. 29

218
219

6 Zero Trust Architecture and Possible Interactions with Existing Federal
Guidance ...................................................................................................................... 31

220

6.1 ZTA and NIST Risk Management Framework .............................................. 31

221

6.2 ZT and NIST Privacy Framework .................................................................. 31

222
223

6.3 ZTA and Federal Identity, Credential, and Access Management Architecture
32224

6.4 ZTA and Trusted Internet Connections 3.0 ................................................... 32

225

6.5 ZTA and EINSTEIN (NCPS – National Cybersecurity Protection System) ... 33

226

6.6 ZTA and DHS Continuous Diagnostics and Mitigations (CDM) Program ...... 33

227

6.7 ZTA, Cloud Smart, and the Federal Data Strategy ....................................... 34228

7

Migrating to a Zero Trust Architecture ............................................................... 35229

7.1 Pure Zero Trust Architecture ......................................................................... 35230

7.2 Hybrid ZTA and Perimeter-Based Architecture ............................................. 35231

7.3 Steps to Introducing ZTA to a Perimeter-Based Architected Network........... 36232

7.3.1 Identify Actors on the Enterprise ........................................................ 37233

7.3.2 Identify Assets Owned by the Enterprise ............................................ 37

234
235

7.3.3 Identify Key Processes and Evaluate Risks Associated with Executing
Process ......................................................................................................... 38

236

7.3.4 Formulating Policies for the ZTA Candidate ....................................... 38237

7.3.5 Identifying Candidate Solutions .......................................................... 38238

7.3.6 Initial Deployment and Monitoring ...................................................... 39239

7.3.7 Expanding the ZTA ............................................................................. 39

240

References ................................................................................................................... 41

241
242

List of Appendices243

Appendix A— Acronyms ............................................................................................ 44244

Appendix B— Identified Gaps in the Current State-of-the-Art in ZTA .................... 45245

B.1 Technology Survey ....................................................................................... 45246

B.2 Gaps that Prevent Immediate Move to ZTA .................................................. 46vi

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

247

B.2.1 Lack of Common Terms for ZTA Design, Planning, and Procurement46

248
249

B.2.2 Perception that ZTA Conflicts with Existing Federal Cybersecurity
Policies .......................................................................................................... 46250

B.3 Systemic Gaps that Impact ZTA ................................................................... 46251

B.3.3 Standardization of Interfaces Between Components .......................... 46

252

B.3.4 Emerging Standards that Address Overreliance on Proprietary APIs 47

253

B.4 Knowledge Gaps in ZTA and Future Areas of Research .............................. 47

254

B.4.5 Attacker Response to ZTA ................................................................. 48

255

B.4.6 User Experience in a ZTA Environment ............................................. 48

256

B.4.7 Resilience of ZTA to Enterprise and Network Disruption .................... 48

257

B.5 ZTA Test Environment .................................................................................. 49

258

B.6 References ................................................................................................... 49

259
260

List of Figures

261

Figure 1: Zero Trust Access ............................................................................................ 5

262

Figure 2: Core Zero Trust Logical Components .............................................................. 9263

Figure 3: Device Agent/Gateway Model ........................................................................ 13

264

Figure 4: Enclave Gateway Model ................................................................................ 14

265

Figure 5: Resource Portal Model................................................................................... 15

266

Figure 6: Application Sandboxes................................................................................... 16

267

Figure 7: Trust Algorithm Input ...................................................................................... 17

268

Figure 8: Enterprise with Remote Employees ............................................................... 23

269

Figure 9: Multicloud Use Case ...................................................................................... 23

270

Figure 10: Enterprise with Nonemployee Access .......................................................... 24

271

Figure 11: Cross-Enterprise Collaboration .................................................................... 25

272

Figure 12: ZTA Deployment Cycle ................................................................................ 36

273
274

List of Tables

275

Table B-1: Summary of Identified Deployment Gaps .................................................... 45

276

vii

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

277

1Introduction

278
279
280
281
282
283

A typical enterprise’s infrastructure has grown increasingly complex. A single enterprise may
operate several internal networks, remote offices with their own local infrastructure, remote
and/or mobile individuals, and cloud services. This complexity has outstripped traditional
methods of perimeter-based network security as there is no single, easily identified perimeter forthe enterprise. Perimeter-based network security has also been shown to be insufficient since
once attackers breach the perimeter, further lateral movement is unhindered.

284
285
286
287
288
289
290
291
292
293
294

This complex enterprise has led to the development of a new model for cybersecurity principles
and network security known as “zero trust” (ZT). A ZT approach is primarily focused on dataprotection but can be expanded to include all enterprise assets, such as devices, infrastructure,and users. Zero trust security models assume that an attacker is present on the network and thatan enterprise-owned network infrastructure is no different—or no more trustworthy—than any
nonenterprise-owned network. In this new paradigm, an enterprise must continually analyze andevaluate the risks to its internal assets and business functions and then enact protections to
mitigate these risks. In zero trust, these protections usually involve minimizing access toresources (such as data and compute resources and applications) to only those users and assets
identified as needing access as well as continually authenticating and authorizing the identity andsecurity posture of each access request.

295
296
297
298
299
300

A zero trust architecture (ZTA) is an enterprise cybersecurity strategy that is based on zero trust
principles and designed to prevent data breaches and limit internal lateral movement. Thispublication discusses ZTA, its logical components, possible deployment scenarios, and threats. It
also presents a general road map for organizations wishing to migrate to a zero trust design
approach to network infrastructure and discusses relevant federal policies that may impact or
influence a zero trust architecture strategy.

301
302
303
304
305
306
307
308
309
310

ZT is not a single-network architecture but a set of guiding principles in network infrastructureand system design and operation that can be used to improve the security posture of any
classification or sensitivity level [FIPS199]. Transitioning to ZTA is a journey concerning how
an organization evaluates risk in its mission and cannot simply be accomplished with a wholesale
replacement of technology. That said, many organizations already have elements of a ZTA intheir enterprise infrastructure today. Organizations should seek to incrementally implement zerotrust principles, process changes, and technology solutions that protect their data assets andbusiness functions by use case. Most enterprise infrastructures will operate in a hybrid zerotrust/perimeter-based mode while continuing to invest in IT modernization initiatives andimprove organization business processes.

311
312
313
314
315

Organizations need to implement comprehensive information security and resiliency practices
for zero trust to be effective. When balanced with existing cybersecurity policies and guidance,
identity and access management, continuous monitoring, and best practices, a ZTA strategy canprotect against common threats and improve an organization’s security posture by using amanaged risk approach.

1

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

316

1.1

317
318
319
320
321
322
323
324
325
326
327
328
329

The concept of zero trust has been present in cybersecurity since before the term “zero trust” wascoined. The Defense Information Systems Agency (DISA) and the Department of Defense
published their work on a more secure enterprise strategy dubbed “black core” [BCORE]. Black
core involved moving from a perimeter-based security model to one that focused on the securityof individual transactions. The work of the Jericho Forum in 1994 publicized the idea of deperimeterization—limiting implicit trust based on network location and the limitations of relying
on single, static defenses over a large network segment [JERICHO]. The concepts of deperimeterization evolved and improved into the larger concept of zero trust, which was latercoined by John Kindervag 1 while at Forrester. 2 Zero trust then became the term used to describe
various cybersecurity solutions that moved security away from implied trust based on network
location and instead focused on evaluating trust on a per-transaction basis. Both private industry
and higher education have also undergone this evolution from perimeter-based security to asecurity strategy based on zero trust principles.

330
331
332
333
334
335
336
337
338
339
340

Federal agencies have been urged to move to security based on zero trust principles for morethan a decade, building capabilities and policies such as the Federal Information Security
Modernization Act (FISMA) followed by the Risk Management Framework (RMF); Federal
Identity, Credential, and Access Management (FICAM); Trusted Internet Connections (TIC);
and Continuous Diagnostics and Mitigation (CDM) programs. All of these programs aim to
restrict data and resource access to authorized parties. When these programs were started, they
were limited by the technical capabilities of information systems. Security policies were largely
static and were enforced at large “choke points” that an enterprise could control to get the largest
effect for the effort. As technology matures, it is becoming possible to continually analyze andevaluate access requests in a dynamic and granular fashion to a “need to access” basis to mitigate
data exposure due to compromised accounts, attackers monitoring a network, and other threats.

341

1.2

342

The rest of the document is organized as follows:

343
344
345
346
347
348
349
350

History of Zero Trust Efforts Related to Federal Agencies

Structure of This Document•••

Section 2 defines ZT and ZTA and lists some assumptions when designing a ZTA for an
enterprise. This section also includes a list of the tenets of ZT design.
Section 3 documents the logical components, or building blocks, of ZT. It is possible thatunique implementations make up ZTA components differently yet serve the same logical
functionality.
Section 4 lists some possible use cases where a ZTA may make enterprise environments
more secure and less prone to successful exploitation. These include enterprises withremote employees, cloud services, and guest networks.

1 https://go.forrester.com/blogs/next-generation-access-and-zero-trust/

2 Any mention of commercial products or services within NIST documents is for information only; it does not imply arecommendation or endorsement by NIST.

2NIST SP 800-207 (SECOND DRAFT)

351
352
353
354
355
356
357
358

•
•
•

ZERO TRUST ARCHITECTURE

Section 5 discusses threats to an enterprise using a ZTA. Many of these threats are
similar to more traditionally architected networks but may require different mitigation
techniques.
Section 6 discusses how ZTA tenets fit into and/or complement existing guidance forfederal agencies.
Section 7 presents the starting point for transitioning an enterprise (such as a federal
agency) to a ZTA. This includes a description of the general steps needed to plan anddeploy applications and enterprise infrastructure that are guided by ZT tenets.

359

3

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

360

2Zero Trust Basics

361
362
363
364
365
366
367
368
369
370

Zero trust is a cybersecurity paradigm focused on resource protection and the premise that trustis never granted implicitly but must be continually evaluated. Zero trust architecture is an end-toend approach to enterprise resource and data security that encompasses identity (person and nonperson entities), credentials, access management, operations, endpoints, hosting environments,
and the interconnecting infrastructure. The initial focus should be on restricting resources tothose with a need to access and grant only the minimum privileges (e.g., read, write, delete)needed to perform the mission. Traditionally, agencies (and enterprise networks in general) havefocused on perimeter defense, and authenticated users are given authorized access to a broadcollection of resources. As a result, unauthorized lateral movement within a network has been
one of the biggest challenges for federal agencies.

371
372
373
374

The TIC and agency perimeter firewalls provide strong internet gateways. This helps blockattackers from the internet, but the TICs and perimeter firewalls are less useful for detecting andblocking attacks from inside the network and cannot protect users outside of the perimeter (e.g.,
remote workers, cloud-based services).

375

An operative definition of zero trust and zero trust architecture is as follows:

376
377
378
379
380
381
382
383

Zero trust (ZT) provides a collection of concepts and ideas designed to reduce theuncertainty in enforcing accurate, per-request access decisions in information systems
and services in the face of a network viewed as compromised. Zero trust architecture(ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts andencompasses component relationships, workflow planning, and access policies.
Therefore, a zero trust enterprise is the network infrastructure (physical and virtual) andoperational policies that are in place for an enterprise as a product of a zero trustarchitecture plan.

384
385
386

An enterprise decides to adopt zero trust as its cybersecurity foundation and generate a zero trustarchitecture as a plan developed with zero trust principles in mind. This plan is then deployed to
produce a zero trust environment for use in the enterprise.

387
388
389
390
391
392
393

This definition focuses on the crux of the issue, which is the goal to prevent unauthorized accessto data and services coupled with making the access control enforcement as granular as
possible. That is, authorized and approved subjects (combination of user, application, anddevice) can access the data to the exclusion of all other subjects (i.e., attackers). To take this one
step further, the word “resource” can be substituted for “data” so that ZT and ZTA are about
resource access (e.g., printers, compute resources, Internet of Things [IoT] actuators) and not justdata access.

394
395
396
397

To lessen uncertainties (as they cannot be eliminated), the focus is on authentication,authorization, and shrinking implicit trust zones while minimizing temporal delays inauthentication mechanisms. Access rules are restricted to least privilege and made as granular as
possible.

4

NIST SP 800-207 (SECOND DRAFT)

398
399
400

ZERO TRUST ARCHITECTURE

In the abstract model of access shown in Figure 1, a user or machine needs access to an
enterprise resource. Access is granted through a policy decision point (PDP) and corresponding
policy enforcement point (PEP). 3

401
402

Figure 1: Zero Trust Access

403
404
405
406
407
408
409
410
411
412
413

The system must ensure that the user is authentic and the request is valid. The PDP/PEP passes
proper judgment to allow the subject to access the resource. This implies that zero trust applies totwo basic areas: authentication and authorization. What is the level of confidence about theuser’s identity for this unique request? Is access to the resource allowable given the level ofconfidence in the user’s identity? Does the device used for the request have the proper security
posture? Are there other factors that should be considered and that change the confidence level(e.g., time, location of subject, subject’s security posture)? Overall, enterprises need to develop
and maintain dynamic risk-based policies for resource access and set up a system to ensure thatthese policies are enforced correctly and consistently. This means that an enterprise should not
rely on implied trustworthiness wherein if the user has met a base authentication level (e.g.,
logging into an asset), all resource requests are assumed to be equally valid.

414
415
416
417
418

The “implicit trust zone” represents an area where all the entities are trusted to at least the levelof the last PDP/PEP gateway. For example, consider the passenger screening model in an airport.
All passengers pass through the airport security checkpoint (PDP/PEP) to access the boarding
gates. The passengers mill about in the terminal area, and all the cleared passengers are
considered trusted. In this model, the implicit trust zone is the boarding area.

419
420
421
422

The PDP/PEP applies a set of controls so that all traffic beyond the PEP has a common level oftrust. The PDP/PEP cannot apply additional policies beyond its location in the flow of traffic. To
allow the PDP/PEP to be as specific as possible, the implicit trust zone must be as small as
possible.

423
424
425

Zero trust provides a set of principles and concepts around moving the PDP/PEPs closer to theresource. The idea is to explicitly authenticate and authorize all users, devices, applications, andworkflows that make up the enterprise.

3 Part of the concepts defined in OASIS XACML 2.0 https://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf5

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

426

2.1

427
428
429
430
431
432
433

Many definitions and discussions of ZT stress the concept of removing wide-area perimeter
defenses (e.g., enterprise firewalls) as a factor. However, most of these definitions continue todefine themselves in relation to perimeters in some way (such as micro-segmentation or microperimeters; see Section 3.1) as part of the functional capabilities of a ZTA. The following is anattempt to define ZT and ZTA in terms of basic tenets that should be involved rather than what is
excluded. These tenets are the ideal goal, though it must be acknowledged that not all tenets may
be fully implemented in their purest form for a given strategy.

434
435

A zero trust architecture is designed and deployed with adherence to the following zero trust
basic tenets:

Tenets of Zero Trust

436
437
438
439
440
441

1. All data sources and computing services are considered resources. A network may becomposed of several different classes of devices. A network may also have small
footprint devices that send data to aggregators/storage, software as a service (SaaS),
systems sending instructions to actuators, and other functions. Also, an enterprise may
decide to classify personally owned devices as resources if they can access enterpriseowned resources.

442
443
444
445
446
447
448
449

2. All communication is secured regardless of network location. Network location does
not imply trust. Access requests from assets located on enterprise-owned network
infrastructure (e.g., inside a traditional network perimeter) must meet the same security
requirements as access requests and communication from any other nonenterprise-owned
network. In other words, trust should not be automatically granted based on the device
being on enterprise network infrastructure. All communication should be done in themost secure manner available, protect confidentiality and integrity, and provide source
authentication.

450
451
452
453
454

3. Access to individual enterprise resources is granted on a per-session basis. Trust in
the requester is evaluated before the access is granted. This could mean only “sometime
previously” for this particular transaction and may not occur directly before initiating asession or performing a transaction with a resource. However, authentication andauthorization to one resource will not automatically grant access to a different resource.

455
456
457
458
459
460
461
462
463
464
465
466
467

4. Access to resources is determined by dynamic policy—including the observable stateof client identity, application, and the requesting asset—and may include otherbehavioral attributes. An organization protects resources by defining what resources it
has, who its members are (or ability to authenticate users from a federated community),
and what access to resources those members need. For zero trust, client identity includes
the user account and any associated attributes assigned by the enterprise to that accountor artifacts to authenticate automated tasks. Requesting asset state includes device
characteristics such as software versions installed, network location, time/date of request,
previously observed behavior, and installed credentials. Behavioral attributes include
automated user analytics, device analytics, and measured deviations from observed usage
patterns. Policy is the set of access rules based on attributes that an organization assigns
to a user, data asset, or application. These rules and attributes are based on the needs ofthe business process and acceptable level of risk. Resource access and action permission
6

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

468
469

policies can vary based on the sensitivity of the resource/data. Least privilege principles
are applied to restrict both visibility and accessibility.

470
471
472
473
474
475
476
477
478
479
480
481
482

5. The enterprise ensures that all owned and associated devices are in the most securestate possible and monitors assets to ensure that they remain in the most secure state
possible. No device is inherently trusted. Here, “most secure state possible” means thatthe device is in the most practicable secure state and still performs the actions required
for the mission. An enterprise implementing a ZTA should establish a CDM or similarsystem to monitor the state of devices and applications and should apply patches/fixes asneeded. Devices that are discovered to be subverted, have known vulnerabilities, and/or
are not managed by the enterprise may be treated differently (including denial of allconnections to enterprise resources) than devices owned by or associated with theenterprise that are deemed to be in their most secure state. This may also apply to
associated devices (e.g., personally owned devices) that may be allowed to access someresources but not others. This, too, requires a robust monitoring and reporting system inplace to provide actionable data about the current state of enterprise resources.

483
484
485
486
487
488
489
490
491
492

6. All resource authentication and authorization are dynamic and strictly enforced
before access is allowed. This is a constant cycle of obtaining access, scanning andassessing threats, adapting, and continually reevaluating trust in ongoing communication.
An enterprise implementing a ZTA would be expected to have Identity, Credential, andAccess Management (ICAM) and asset management systems in place. This includes theuse of multifactor authentication (MFA) for access to some or all enterprise resources.
Continuous monitoring with possible reauthentication and reauthorization occurs
throughout user interaction, as defined and enforced by policy (e.g., time-based, newresource requested, resource modification, anomalous user activity detected) that strives
to achieve a balance of security, availability, usability, and cost-efficiency.

493
494
495
496
497
498
499
500
501
502
503

7. The enterprise collects as much information as possible about the current state of
network infrastructure and communications and uses it to improve its security
posture. An enterprise should collect data about network traffic and access requests,
which is then used to improve policy creation and enforcement. This data can also be
used to provide context for access requests from subjects (see Section 3.3.1).
The above tenets attempt to be technology agnostic. For example, “user identification (ID)”
could include several factors such as username/password, certificates, and onetime password.
These tenets apply to work done within an organization or in collaboration with one or morepartner organizations and not to public or consumer-facing business processes. An organization
cannot impose internal policies on external actors (e.g., customers or general internet users).

504

2.2

505
506
507
508
509
510

There are some basic assumptions for network connectivity for any organization that utilizes
ZTA in network planning and deployment. Some of these assumptions apply to enterprise-owned
network infrastructure, and some apply to enterprise-owned resources used on nonenterpriseowned network infrastructure (e.g., public Wi-Fi). The network in an enterprise implementing a
ZTA should be developed with the ZTA tenets outlined above and with the following
assumptions.

A Zero Trust View of a Network

7

NIST SP 800-207 (SECOND DRAFT)

511

2.2.1

ZERO TRUST ARCHITECTURE

Assumptions for Enterprise-Owned Network Infrastructure

512
513
514
515

1. The entire enterprise private network is not considered an implicit trust zone. Assets
should always act as if an attacker is present on the enterprise network, andcommunication should be done in the most secure manner available (see tenet 2 above).
This entails actions such as authenticating all connections and encrypting all traffic.

516
517
518
519

2. Devices on the network may not be owned or configurable by the enterprise. Visitors
and/or contracted services may include nonenterprise-owned assets that need network
access to perform their role. This includes bring-your-own-device (BYOD) policies thatallow enterprise users to use nonenterprise-owned devices to access enterprise resources.

520
521
522
523
524
525

3. No resource is inherently trusted. Every asset must have its security posture evaluated
via a PEP before connecting to an enterprise-owned resource (similar to tenet 6 above forassets as well as users). Enterprise-owned devices may have artifacts that enable
authentication and provide a confidence level higher than the same request coming from
nonenterprise-owned devices. User credentials alone are insufficient for device
authentication to an enterprise resource.

526

2.2.2

Assumptions for Nonenterprise-Owned Network Infrastructure

527
528
529
530

1. Not all enterprise resources are on enterprise-owned infrastructure. Resources
include remote enterprise users as well as cloud services. Enterprise-owned or -managed
assets may need to utilize the local (i.e., nonenterprise) network for basic connectivity
and network services (e.g., DNS resolution).

531
532
533
534
535
536

2. Remote enterprise users cannot fully trust the local network connection. Remoteusers should assume that the local (i.e., nonenterprise-owned) network is hostile. Assets
should assume that all traffic is being monitored and potentially modified. All connection
requests should be authenticated and authorized, and all communications should be donein the most secure manner possible (i.e., provide confidentiality, integrity protection, andsource authentication). See the tenets of ZTA above.

537

8

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

538

3

Logical Components of Zero Trust Architecture

539
540
541
542
543
544
545
546

There are numerous logical components that make up a ZTA deployment in an enterprise. These
components may be operated as an on-premises service or through a cloud-based service. The
conceptual framework model in Figure 2 shows the basic relationship between the components
and their interactions. Note that this is an ideal model showing logical components and theirinteractions. From Figure 1, the policy decision point (PDP) is broken down into two logicalcomponents: the policy engine and policy administrator (defined below). The ZTA logicalcomponents use a separate control plane to communicate, while application data iscommunicated on a data plane (see Section 3.4).

547

548
549
550

Figure 2: Core Zero Trust Logical Components

The component descriptions:

551
552
553
554
555
556
557

•

Policy engine (PE): This component is responsible for the ultimate decision to grant
access to a resource for a given subject. The PE uses enterprise policy as well as input
from external sources (e.g., CDM systems, threat intelligence services described below)
as input to a trust algorithm (see Section 3.3 for more details) to grant, deny, or revoke
access to the resource. The PE is paired with the policy administrator component. The
policy engine makes and logs the decision, and the policy administrator executes thedecision.

558
559
560
561
562
563
564
565

•

Policy administrator (PA): This component is responsible for establishing and/or
shutting down the communication path between a subject and a resource. It would
generate any authentication and authentication token or credential used by a client toaccess an enterprise resource. It is closely tied to the PE and relies on its decision toultimately allow or deny a session. Some implementations may treat the PE and PA as asingle service; here, it is divided into its two logical components. The PA communicateswith the PEP when creating the communication path. This communication is done via thecontrol plane.

566
567

•

Policy enforcement point (PEP): This system is responsible for enabling, monitoring,and eventually terminating connections between a subject and an enterprise resource.
9

NIST SP 800-207 (SECOND DRAFT)

568
569
570
571
572
573
574
575
576

ZERO TRUST ARCHITECTURE

This is a single logical component in ZTA but may be broken into two different
components: the client (e.g., agent on user’s laptop) and resource side (e.g., gateway
component in front of resource that controls access) or a single portal component that acts
as a gatekeeper for communication paths. Beyond the PEP is the implicit trust zone (seeSection 2) hosting the enterprise resource.
In addition to the core components in an enterprise implementing a ZTA, several data sources
provide input and policy rules used by the policy engine when making access decisions. These
include local data sources as well as external (i.e., nonenterprise-controlled or -created) data
sources. These include:

577
578
579
580
581
582

•

Continuous diagnostics and mitigation (CDM) system: This gathers information about
the enterprise asset’s current state and applies updates to configuration and software
components. An enterprise CDM system provides the policy engine with the information
about the asset making an access request, such as whether it is running the appropriate
patched operating system (OS) and applications or whether the asset has any known
vulnerabilities.

583
584
585
586

•

Industry compliance system: This ensures that the enterprise remains compliant withany regulatory regime that it may fall under (e.g., FISMA, healthcare or financial
industry information security requirements). This includes all the policy rules that anenterprise develops to ensure compliance.

587
588
589
590
591
592

•

Threat intelligence feed(s): This provides information from internal or external sourcesthat help the policy engine make access decisions. These could be multiple services thattake data from internal and/or multiple external sources and provide information about
newly discovered attacks or vulnerabilities. This also includes blacklists, newly identified
malware, and reported attacks to other assets that the policy engine will want to denyaccess to from enterprise assets.

593
594
595
596
597
598

•

Data access policies: These are the attributes, rules, and policies about access toenterprise resources. This set of rules could be encoded in or dynamically generated by
the policy engine. These policies are the starting point for authorizing access to a
resource as they provide the basic access privileges for accounts and applications in theenterprise. These policies should be based on the defined mission roles and needs of theorganization.

599
600
601
602
603

•

Enterprise public key infrastructure (PKI): This system is responsible for generating
and logging certificates issued by the enterprise to resources, subjects, and applications.
This also includes the global certificate authority ecosystem and the Federal PKI, 4 which
may or may not be integrated with the enterprise PKI. This could also be a PKI that is not
built upon X.509 certificates.

604
605

•

ID management system: This is responsible for creating, storing, and managing
enterprise user accounts and identity records (e.g., lightweight directory access protocol

4 https://www.idmanagement.gov/topics/fpki/

10

NIST SP 800-207 (SECOND DRAFT)

606
607
608
609
610
611

ZERO TRUST ARCHITECTURE(LDAP) server). This system contains the necessary user information (e.g., name, email
address, certificates) and other enterprise characteristics such as role, access attributes,
and assigned assets. This system often utilizes other systems (such as a PKI) for artifacts
associated with user accounts. This system may be part of a larger federated community
and may include nonenterprise employees or links to nonenterprise assets forcollaboration.

612
613
614

•

Network and system activity logs: This is the enterprise system that aggregates asset
logs, network traffic, resource access actions, and other events that provide real-time (ornear-real-time) feedback on the security posture of enterprise information systems.

615
616
617

•

Security information and event management (SIEM) system: This collects securitycentric information for later analysis. This data is then used to refine policies and warn ofpossible attacks against enterprise assets.

618

3.1

619
620
621
622
623
624

There are several ways that an enterprise can enact a ZTA for workflows. These approaches varyin the components used and in the main source of policy rules for an organization. Eachapproach implements all the tenets of ZT (see Section 2.1) but may use one or two (or one
component) as the main driver of policies. The approaches include enhanced identity
governance–driven, logical micro-segmentation via next-generation firewalls (NGFWs), andnetwork-based segmentation.

625
626
627
628
629

Certain approaches lend themselves to some use cases more than others. An organization looking
to develop a ZTA for its enterprise may find that its chosen use case and existing policies point
to one approach over others. That does not mean the other approaches would not work but rather
that other approaches may be more difficult to implement and may require more fundamental
changes to how the enterprise currently conducts business flows.

630

3.1.1

631
632
633
634
635
636
637
638
639
640

The enhanced identity governance approach to developing a ZTA uses the identity of actors as
the key component of policy creation. If it were not for subjects requesting access to enterprise
resources, there would be no need to create access polices. For this approach, enterprise resource
access policies are based on identity and assigned attributes. The primary requirement forresource access is based on the access privileges granted to the given subject. Other factors suchas device used, asset status, and environmental factors may alter the final confidence levelcalculation (and ultimate access authorization) or tailor the result in some way, such as granting
only partial access to a given data source based on network location. Individual resources or PEP
components protecting the resource must have a way to forward requests to a policy engine
service or authenticate the subject and approve the request before granting access.

641
642
643
644
645

Enhanced identity governance-based approaches for enterprises are often found using an open
network model or an enterprise network with visitor access or frequent nonenterprise devices on
the network (such as with the use case in Section 4.3 below). Network access is initially granted
to all assets with access to resources that are restricted to identities with the appropriate accessprivileges. The identity-driven approach works well with the resource portal model since device

Variations of Zero Trust Architecture Approaches

ZTA Using Enhanced Identity Governance

11

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

646
647

identity and status provide secondary support data to access decisions. Other models work as
well, depending on policies in place.

648

3.1.2

649
650
651
652
653
654
655

An enterprise may choose to implement a ZTA based on placing individual or groups ofresources on its own network segment protected by a gateway security component. In thisapproach, the enterprise places NGFWs or gateway devices to act as PEPs protecting eachresource or group of resources. These gateway devices dynamically grant access to individual
requests from a client asset. Depending on the model, the gateway may be the sole PEP
component or part of a multipart PEP consisting of the gateway and client-side agent (seeSection 3.2.1).

656
657
658
659

This approach applies to a variety of use cases and deployment models as the protecting device
acts as the PEP, with management of said devices acting as the PE/PA component. Thisapproach requires an identity governance program to fully function but relies on the gateway
components to act as the PEP that shields resources from unauthorized access and/or discovery.

660
661
662
663
664

The key necessity to this approach is that the PEP components are managed and should be able
to react and reconfigure as needed to respond to threats or change in the workflow. It is possible
to implement some features of a micro-segmented enterprise by using less advanced gateway
devices and even stateless firewalls, but the administration cost and difficulty to quickly adapt tochanges make this a very poor choice.

665

3.1.3

666
667
668
669
670
671
672

The third approach uses the network infrastructure to implement a ZTA. The ZT implementation
could be achieved by using an overlay network (i.e., layer 7 but also could be set up lower of the
ISO network stack). These approaches are sometimes referred to as software defined perimeter(SDP) approaches and frequently include concepts from SDN [SDNBOOK] and intent-based
networking (IBN) [IBNVN]. In this approach, the PA acts as the network controller that sets up
and reconfigures the network based on the decisions made by the PE. The clients continue torequest access via PEPs, which are managed by the PA component.

673
674
675
676

When the approach is implemented at the application network layer (i.e., layer 7), the mostcommon deployment model is the agent/gateway (see Section 3.2.1). In this implementation, theagent and resource gateway (acting as the single PEP and configured by the PA) establish asecure channel used for communication between the client and resource.

677

3.2

678
679
680
681
682
683
684

All of the above components are logical components. They do not necessarily need to be uniquesystems. A single asset may perform the duties of multiple logical components, and likewise, alogical component may consist of multiple hardware or software elements to perform the tasks.
For example, an enterprise-managed PKI may consist of one component responsible for issuingcertificates for devices and another used for issuing certificates to end users, but both use
intermediate certificates issued from the same enterprise root certificate authority. In some ZT
product offerings currently available on the market, the PE and PA components are combined in

ZTA Using Micro-Segmentation

ZTA Using Network Infrastructure and Software Defined Perimeters

Deployed Variations of the Abstract Architecture

12

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

685

a single service.

686
687
688

There are several variations on deployment of selected components of the architecture that are
outlined in the sections below. Depending on how an enterprise network is set up, multiple ZTA
deployment models may be in use for different business processes in one enterprise.

689

3.2.1

690
691
692
693
694
695
696

In this deployment model, the PEP is divided into two components that reside on the resource or
as a component directly in front of a resource. For example, each enterprise-issued asset has an
installed device agent that coordinates connections, and each resource has a component (i.e.,
gateway) that is placed directly in front so that the resource communicates only with thegateway, essentially serving as a proxy for the resource. The gateway is responsible forconnecting to the policy administrator and allows only approved communication paths
configured by the policy administrator (see Figure 3).

Device Agent/Gateway-Based Deployment

697
698

Figure 3: Device Agent/Gateway Model

699
700
701
702
703
704
705
706
707
708
709

In a typical scenario, a user with an enterprise-issued laptop wishes to connect to an enterprise
resource (e.g., human resources application/database). The access request is taken by the local
agent, and the request is sent to the policy administrator. The policy administrator and policy
engine could be an enterprise local asset or a cloud-hosted service. The policy administrator
forwards the request to the policy engine for evaluation. If the request is authorized, the policy
administrator configures a communication channel between the device agent and the relevant
resource gateway via the control plane. This may include an internet protocol (IP) address, port
information, session key, or similar security artifacts. The device agent and gateway thenconnect, and encrypted application data flows begin. The connection between the device agent
and resource gateway is terminated when the workflow is completed or when triggered by thepolicy administrator due to a security event (e.g., session time-out, failure to reauthenticate).

710
711
712
713

This model is best utilized for enterprises that have a robust device management program inplace as well as discrete resources that can communicate with the gateway. For enterprises thatheavily utilize cloud services, this is a client-server implementation of the Cloud Security
Alliance (CSA) Software Defined Perimeter (SDP) [CSA-SDP]. This model is also appropriate
13

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

714
715

for enterprises that do not want a BYOD policy in place. Access is possible only via the device
agent, which can be placed on enterprise-owned assets.

716

3.2.2

717
718
719
720
721
722
723
724
725

This deployment model is a variation of the device agent/gateway model above. In this model,
the gateway components may not reside on assets or in front of individual resources but instead
reside at the boundary of a resource enclave (e.g., on-location data center) as shown in Figure 4.
Usually, these resources serve a single business function or may not be able to communicate
directly to a gateway (e.g., legacy database system that does not have an application
programming interface [API] that can be used to communicate with a gateway). This deployment
model may also be useful for enterprises that use cloud-based micro-services for businessprocesses (e.g., user notification, database lookup, salary disbursement). In this model, the entire
private cloud is located behind a gateway.

Enclave-Based Deployment

726
727

Figure 4: Enclave Gateway Model

728
729
730

It is possible for this model to be a hybrid with the device agent/gateway model. In this model,
enterprise assets have a device agent that is used to connect to enclave gateways, but theseconnections are created using the same process as the basic device agent/gateway model.

731
732
733
734
735
736

This model is useful for enterprises that have legacy applications or on-premises data centers thatcannot have individual gateways in place. The enterprise needs a robust asset and configuration
management program in place to install/configure the device agents. The downside is that the
gateway protects a collection of resources and may not be able to protect each resource
individually. This may also allow for subjects to see resources which they do not have privileges
to access.

737

3.2.3

738
739
740

In this deployment model, the PEP is a single component that acts as a gateway for user requests.
The gateway portal can be for an individual resource or a secure enclave for a collection of
resources used for a single business function. One example would be a gateway portal into a

Resource Portal-Based Deployment

14

NIST SP 800-207 (SECOND DRAFT)

741

ZERO TRUST ARCHITECTURE

private cloud or data center containing legacy applications as shown in Figure 5.

742
743

Figure 5: Resource Portal Model

744
745
746
747
748
749
750

The primary benefit of this model over the others is that a software component does not need to
be installed on all client devices. This model is also more flexible for BYOD policies and interorganizational collaboration projects. Enterprise administrators do not need to ensure that eachdevice has the appropriate device agent before use. However, limited information can be inferredfrom devices requesting access. This model can only scan and analyze assets and devices once
they connect to the PEP portal and may not be able to continuously monitor them for malware
and appropriate configuration.

751
752
753
754
755
756
757

The main difference with this model is that there is no local agent that handles requests, and so
the enterprise may not have full visibility or arbitrary control over assets as it can only see/scanthem when they connect to a portal. The enterprise may be able to employ measures such asbrowser isolation to mitigate or compensate. These assets may be invisible to the enterprise
between these sessions. This model also allows attackers to discover and attempt to access theportal or attempt a denial-of-service (DoS) attack against the portal. The portal systems should
be well-provisioned to provide availability against a DoS attack or network disruption.

758

3.2.4

759
760
761
762
763

Another variation of the agent/gateway deployment model is having vetted applications orprocesses run compartmentalized on assets. These compartments could be virtual machines,
containers, or some other implementation, but the goal is the same: to protect the application or
instances of applications from a possibly compromised host or other applications running on theasset.

Device Application Sandboxing

15

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

764
765

Figure 6: Application Sandboxes

766
767
768
769

In Figure 6, the user device runs approved, vetted applications in a sandbox. The applications cancommunicate with the PEP to request access to resources, but the PEP will refuse requests fromother applications on the asset. The PEP could be an enterprise local service or a cloud service inthis model.

770
771
772
773
774
775
776

The main advantage of this model variant is that individual applications are segmented from therest of the asset. If the asset cannot be scanned for vulnerabilities, these individual, sandboxed
applications may be protected from a potential malware infection on the host asset. One of thedisadvantages of this model is that enterprises must maintain these sandboxed applications for all
assets and may not have full visibility into client assets. The enterprise also needs to make sureeach sandboxed application is secure, which may require more effort than simply monitoring
devices.

777

3.3

778
779
780
781
782
783

For an enterprise with a ZTA deployment, the policy engine can be thought of as the brain and
the PE’s trust algorithm (TA) as its primary thought process. The TA is the process used by thepolicy engine to ultimately grant or deny access to a resource. The policy engine takes input
from multiple sources: the policy database with information about users, user attributes androles, historical user behavior patterns, threat intelligence sources, and other metadata sources.
The process can be visualized in Figure 7.

Trust Algorithm

784

16

NIST SP 800-207 (SECOND DRAFT)

785
786
787
788

ZERO TRUST ARCHITECTURE

Figure 7: Trust Algorithm Input

In the figure, the inputs can be broken into categories based on what they provide to the trustalgorithm.

789
790
791
792

•

Access request: This is the actual request from the subject. The resource requested is theprimary information used, but information about the requester is also used. This can
include OS version, application used, and patch level. Depending on these factors and theasset security posture, access to assets might be restricted or denied.

793
794
795
796
797
798
799
800
801
802
803
804

•

User identification, attributes, and privileges: This is the “who” that is requesting
access to a resource [SP800-63-3]. This is the set of users (human and processes) of theenterprise or collaborators and a collection of user attributes/privileges assigned. Theseusers and attributes form the basis of policies for resource access [SP800-162] [NISTIR7987]. User identities can include a mix of logical identity (e.g., account ID) and resultsof authentication checks performed by PEPs. Attributes of identity that can be factored
into deriving the confidence level include time and geolocation. A collection of privileges
given to multiple users could be thought of as a role, but privileges should be assigned toa user on an individual basis and not simply because they may fit into a particular role.
This collection should be encoded and stored in an ID management system and policy
database. This may also include data about past observed user behavior in some (TA)variants (see Section 3.3.1).

805
806
807
808

•

Asset database and observable status: This is the database that contains the known
status of each enterprise-owned asset (physical and virtual, to some extent). This iscompared to the observable status of the asset making the request and can include OS
version, application used, location (network location and geolocation), and patch level.

17

NIST SP 800-207 (SECOND DRAFT)

809
810

ZERO TRUST ARCHITECTURE

Depending on the asset state compared with this database, access to assets might be
restricted or denied.

811
812
813
814
815
816
817
818

•

Resource access requirements: This set of policies complements the user ID andattributes database [SP800-63-3] and defines the minimal requirements for access to theresource. Requirements may include authenticator assurance levels, such as MFA
network location (e.g., deny access from overseas IP addresses), data sensitivity(sometimes referred to as “data toxicity”), and requests for asset configuration. These
requirements should be developed by both the data custodian (i.e., those responsible forthe data) and those responsible for the business processes that utilize the data (i.e., those
responsible for the mission).

819
820
821
822
823

•

Threat intelligence: This is an information feed or feeds about general threats and active
malware operating on the internet. These feeds can be external services or internal scansand discoveries and can include attack signatures and mitigations. This is the only
component that will most likely be under the control of a service rather than theenterprise.

824
825
826

The weight of importance for each data source may be a proprietary algorithm or may be
configured by the enterprise. These weight values can be used to reflect the importance of thedata source to an enterprise.

827
828
829
830
831
832
833
834

The final determination is then passed to the PA for execution. The PA’s job is to configure thenecessary PEPs to enable authorized communication. Depending on how the ZTA is deployed,
this may involve sending authentication results and connection configuration information to
gateways and agents or resource portals. PAs may also place a hold or pause on acommunication session to reauthenticate and reauthorize the connection in accordance with
policy requirements. The PA is also responsible for issuing the command to terminate theconnection based on policy (e.g., after a time-out, when the workflow has been completed, due toa security alert).

835

3.3.1

836
837
838
839
840
841

There are different ways to implement a TA. Different implementers may wish to weigh theabove factors differently according to the factors’ perceived importance. There are two othermajor characteristics that can be used to differentiate TAs. The first is how the factors areevaluated, whether as binary decisions or weighted parts of a whole “score” or confidence level.
The second is how requests are evaluated in relation to other requests by the same subject,application, or device.

842
843
844
845
846
847
848

•

Trust Algorithm Variations

Criteria- versus score-based: A criteria-based TA assumes a set of qualified attributes
that must be met before access is granted to a resource or an action (e.g., read/write) isallowed. These criteria are configured by the enterprise and should be independently
configured for every resource. Access is granted or an action applied to a resource only if
all the criteria are met. A score-based TA computes a confidence level based on values
for every data source and enterprise-configured weights. If the score is greater than theconfigured threshold value for the resource, access is granted, or the action is performed.
18

NIST SP 800-207 (SECOND DRAFT)

849
850
851
852
853
854
855
856
857
858
859
860

ZERO TRUST ARCHITECTURE

Otherwise, the request is denied, or access privileges are reduced (e.g., read access isgranted but not write access for a file).
•

Singular versus contextual: A singular TA treats each request individually and does nottake the user/application history into consideration when making its evaluation. This canallow faster evaluations, but there is a risk that an attack can go undetected if it stays
within a user’s allowed role. A contextual TA takes a user or network agent’s recent
history into consideration when evaluating access requests. This means the PE must
maintain some state information on all users and applications but may be more likely todetect an attacker using subverted credentials to access information in a pattern that is
atypical of what the PE sees for the given subject. Analysis of user behavior can be used
to provide a model of acceptable use, and deviations from this behavior could trigger
additional authentication checks or resource request denials.

861
862
863
864

The two factors are not always dependent on each other. It is possible to have a TA that assigns a
confidence level to every user and/or device and still considers every access request
independently (i.e., singular). However, contextual, score-based TAs work best, since the scoreprovides a current confidence level for the requesting account.

865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881

Ideally, a ZTA trust algorithm should be contextual, but this may not always be possible with theinfrastructure components available to the enterprise. A contextual TA can mitigate threats
where an attacker stays close to a “normal” set of access requests for a compromised user
account or insider attack. It is important to balance security, usability, and cost-effectivenesswhen defining and implementing trust algorithms. Continually prompting a user forreauthentication against behavior that is consistent with historical trends and norms for their
mission function and role within the organization can lead to usability issues. For example, if an
employee in the HR department of an agency normally accesses 20 to 30 employee records in a
typical workday, a contextual TA may send an alert if the access requests suddenly exceed 100
records in a day. A contextual TA may also send an alert if someone is making access requests
after normal business hours as this could be an attacker exfiltrating records by using acompromised HR account. These are examples where a contextual TA can detect an attack
whereas a singular TA may fail to detect the new behavior. In another example, an accountant
who typically accesses the financial system during normal business hours is now trying to accessthe system in the middle of the night from an unrecognizable location. A contextual TA maytrigger an alert and require the user to satisfy a more stringent confidence level or other criteria
as outlined in NIST Special Publication 800-63A [SP800-63A].

882
883
884
885
886
887
888
889

Developing a set of criteria or weights/threshold values for each resource requires planning andtesting. Enterprise administrators may encounter issues during the initial implementation of ZTA
where access requests that should be approved are denied due to misconfiguration. This will
result in an initial “tuning” phase of deployment. Criteria or scoring weights may need to be
adjusted to ensure that the policies are enforced while still allowing the enterprise’s businessprocesses to function. How long this tuning phase lasts depends on the enterprise-defined metrics
for progress and tolerance for incorrect access denials/approvals for the resources used in theworkflow.

19

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

890

3.4

891
892
893
894
895

In a ZT environment, there should be a separation (logical or possibly physical) of thecommunication flows used to control and configure the network and application communication
flows used to perform the actual work of the organization. This is often broken down to a control
plane for network control communication and a data plane for application communication flows[Gilman].

896
897
898
899
900
901
902
903

The control plane is used by various infrastructure components (both enterprise-owned and fromservice providers) to maintain assets; judge, grant, or deny access to resources; and perform any
necessary operations to set up communication paths between resources. The data plane is used
for actual communication between applications. This communication channel may not be
possible before the path has been established via the control plane. For example, the control
plane could be used by the PA and PEP to set up the communication path between the user andthe enterprise resource. The application workload would then use the data plane path that wasestablished.

904

3.4.1

Network/Environment Components

Network Requirements to Support ZTA

905
906
907

1. Enterprise assets have basic network connectivity. The local area network (LAN),
enterprise controlled or not, provides basic routing and infrastructure (e.g., DNS). The
remote enterprise asset may not necessarily use all infrastructure services.

908
909
910
911

2. The enterprise must be able to distinguish between what assets are owned or
managed by the enterprise and their current security posture. This is determined byenterprise-issued credentials and not unauthenticated information (e.g., network MAC
addresses that can be spoofed).

912
913
914
915
916

3. The enterprise can capture all network traffic. The enterprise can record packets seenon the data plane but may not be able to perform application layer inspection (i.e., ISOlayer 7) on all packets. The enterprise can filter out metadata about the connection (e.g.,
destination, time, device identity) to dynamically update policies and inform the PE in
evaluating access requests.

917
918
919
920
921
922
923
924

4. Enterprise resources should not be reachable without accessing a PEP. Enterprise
resources do not accept arbitrary incoming connections from the internet. Resources
accept custom-configured connections only after a client has been authenticated andauthorized. These communication paths are set up by the PEP. Resources may not evenbe discoverable without accessing a PEP. This prevents attackers from identifying targets
via scanning and launching DoS attacks against resources located behind PEPs. Note that
not all resources should be hidden this way; some network infrastructure components(e.g., DNS servers) must be accessible.

925
926
927
928

5. The data plane and control plane are logically separate. The policy engine, policy
administrator, and PEPs communicate on a network that is logically separate and not
directly accessible by enterprise assets and resources. The data plane is used for
application data traffic. The policy engine, policy administrator, and PEPs use the control

20

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

929
930

plane to communicate and manage communication paths between assets. The PEPs must
be able to send and receive messages from both the data and control planes.

931
932
933
934

6. Enterprise assets can reach the PEP component. Enterprise users must be able toaccess the PEP component to gain access to resources. This could take the form of a web
portal, network device, or software agent on the enterprise asset that enables theconnection.

935
936
937
938

7. The PEP is the only component that accesses the policy administrator as part of abusiness flow. Each PEP operating on the enterprise network has a connection to thepolicy administrator to establish communication paths from clients to resources. Allenterprise business process traffic passes through one or more PEPs.

939
940
941
942
943

8. Remote enterprise assets should be able to access enterprise resources without
needing to traverse enterprise network infrastructure first. For example, a remoteuser should not be required to use a link back to the enterprise network (i.e., virtualprivate network [VPN]) to access services utilized by the enterprise and hosted by apublic cloud provider (e.g., email).

944
945
946
947
948
949
950

9. The infrastructure used to support the ZTA access decision process should be madescalable to account for changes in process load. The PE(s), PA(s), and PEPs used in a
ZTA become the key components in any business process. Delay or inability to reach a
PEP (or inability of the PEPs to reach the PA/PE) negatively impacts the ability toperform the workflow. An enterprise implementing a ZTA needs to provision thecomponents for the expected workload or be able to rapidly scale the infrastructure tohandle increased usage when needed.

951
952
953
954
955

10. Enterprise assets may not be able to reach certain PEPs due to observable factors.
For example, there may be a policy stating that mobile assets may not be able to reachcertain resources if the requesting asset is located outside of the enterprise’s homecountry. These factors could be based on location (geolocation or network location),device type, or other criteria.

21

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

956

4

Deployment Scenarios/Use Cases

957
958
959
960
961
962

Any enterprise environment can be designed with zero trust tenets in mind. Most organizations
already have some elements of zero trust in their enterprise infrastructure or are on their way
through implementation of information security and resiliency policies and best practices.
Several deployment scenarios and use cases lend themselves readily to a zero trust architecture.
For instance, ZTA has its roots in organizations that are geographically distributed and/or have ahighly mobile workforce. That said, any organization can benefit from a zero trust architecture.

963
964
965
966

In the use cases below, ZTA is not explicitly indicated since the enterprise likely has both
perimeter-based and possibly ZTA infrastructures. As discussed in Section 7.2, there will likely
be a period when ZTA components and perimeter-based network infrastructure are concurrently
in operation in an enterprise.

967

4.1

968
969
970
971
972
973
974
975

The most common scenario involves an enterprise with a single headquarters and one or moregeographically dispersed locations that are not joined by an enterprise-owned physical network
connection (see Figure 8). Employees at the remote location may not have a full enterpriseowned local network but still need to access enterprise resources to perform their tasks.
Likewise, employees may be teleworking or in a remote location and using enterprise-owned or
personally-owned devices. In such cases, an enterprise may wish to grant access to someresources (e.g., employee calendar, email) but deny access or restrict actions to more sensitive
resources (e.g., HR database).

976
977
978
979
980
981

In this use case, the PE/PA(s) is often hosted as a cloud service (which usually provides superior
availability and would not require remote workers to rely on enterprise infrastructure to accesscloud resources) with end assets having an installed agent (see Section 3.2.1) or accessing a
resource portal (see Section 3.2.3). It may not be most responsive to have the PE/PA(s) hosted on
the enterprise local network as remote offices and workers must send all traffic back to theenterprise network to reach applications hosted by cloud services.

Enterprise with Satellite Facilities

22

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

982
983

Figure 8: Enterprise with Remote Employees

984

4.2

985
986
987
988
989
990
991

One increasingly common use case for deploying a ZTA is an enterprise utilizing multiple cloudproviders (see Figure 9). In this use case, the enterprise has a local network but uses two or more
cloud service providers to host applications and data. Sometimes, the application is hosted on a
cloud service that is separate from the data source. For performance and ease of management, theapplication hosted in Cloud Provider A should be able to connect directly to the data source
hosted in Cloud Provider B rather than force the application to tunnel back through the enterprisenetwork.

992
993

Figure 9: Multi-cloud Use Case

994
995
996
997
998
999

This use case is the server-server implementation of the CSA’s SDP specification [CSA-SDP].
As enterprises move to more cloud-hosted applications and services, it becomes apparent thatrelying on the enterprise perimeter for security becomes a liability. As discussed in Section 2.2,
ZT principles take the view that there should be no difference between enterprise-owned and operated network infrastructure and infrastructure owned and operated by any other service
provider. The zero trust approach to multi-cloud use is to place PEPs at the access points of each

Multi-cloud Enterprise

23

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1000
1001
1002
1003

application and data source. The PE and PA may be services located in either cloud or even on athird cloud provider. The client (via a portal or local installed agent) then accesses the PEPs
directly. That way, the enterprise can still manage access to resources even when hosted outside
the enterprise.

1004

4.3

1005
1006
1007
1008
1009
1010
1011
1012

Another common scenario is an enterprise that includes on-site visitors and/or contracted service
providers that require limited access to enterprise resources to do their work (see Figure 10). For
example, an enterprise has its own internal applications, databases, and assets. These include
services contracted out to providers who may occasionally be on-site to provide maintenance(e.g., smart heating and lighting systems that are owned and managed by external providers).
These visitors and service providers will need network connectivity to perform their tasks. A
zero trust enterprise could facilitate this by allowing these devices and any visiting service
technician access to the internet while obscuring enterprise resources.

Enterprise with Contracted Services and/or Nonemployee Access

1013
1014

Figure 10: Enterprise with Nonemployee Access

1015
1016
1017
1018
1019
1020

In this example, the organization also has a conference center where visitors interact with
employees. Again, with a ZTA approach of SDPs, employee devices and users are differentiatedand may be able to access appropriate enterprise resources. Visitors to the campus can haveinternet access but cannot access enterprise resources. They may not even be able to discoverenterprise services via network scans (i.e., prevent active network reconnaissance/east-west
movement).
24

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1021
1022
1023
1024
1025

In this use case, the PE(s) and PA(s) could be hosted as a cloud service or on the LAN (assuming
little or no use of cloud-hosted services). The enterprise assets could have an installed agent (seeSection 3.2.1) or access resources via a portal (see Section 3.2.3). The PA(s) ensures that all
nonenterprise assets (those that do not have installed agents or cannot connect to a portal) cannot
access local resources but may access the internet.

1026

4.4

1027
1028
1029
1030
1031
1032
1033
1034
1035

A fourth use case is cross-enterprise collaboration. For example, there is a project involving
employees from Enterprise A and Enterprise B (see Figure 11). The two enterprises may beseparate federal agencies (G2G) or even a federal agency and a private enterprise (G2B).
Enterprise A operates the database used for the project but must allow access to the data forcertain members of Enterprise B. Enterprise A can set up specialized accounts for the employeesof Enterprise B to access the required data and deny access to all other resources, but this canquickly become difficult to manage. Having both organizations enrolled in a federated ID
management system would allow quicker establishment of these relationships provided that bothorganizations’ PEPs can authenticate subjects in a federated ID community.

Collaboration Across Enterprise Boundaries

1036
1037

Figure 11: Cross-Enterprise Collaboration

1038
1039
1040
1041
1042
1043
1044
1045
1046

This scenario can be similar to Use Case 1 (Section 4.1) as employees of both enterprises may
not be located on their organizations’ network infrastructures, and the resource they need toaccess may be within one enterprise environment or hosted in the cloud. This means that there do
not need to be complex firewall rules or enterprise-wide access control lists (ACLs) allowing
certain IP addresses belonging to Enterprise B to access resources in Enterprise A. How thisaccess is accomplished depends on the technology in use. Similar to Use Case 1, a PE and PA
hosted as a cloud service may provide availability to all parties without having to establish a
VPN or similar. The employees of Enterprise B may be asked to install a software agent on theirasset or access the necessary data resources through a web gateway (see Section 3.2.3).

25

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1047

4.5

1048
1049
1050
1051
1052
1053

A common feature in many enterprises is a public-facing service that may or may not include
user registration (i.e., users must create or have been issued a set of login credentials). Suchservices could be for the general public, a set of customers with an existing business relationship,
or a special set of nonenterprise users such as employee dependents. In all cases, it is likely thatrequesting assets are not enterprise-owned, and the enterprise is constrained as to what internalcybersecurity polices can be enforced.

1054
1055
1056

For a general, public-facing resource that does not require login credentials to access (e.g., public
web page), the tenets of ZTA do not directly apply. The enterprise cannot strictly control thestate of requesting assets, and public resources do not require credentials in order to be accessed.

1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068

Enterprises may establish policies for registered public users such as customers (i.e., those with abusiness relationship) and special users (e.g., employee dependents). If the users are required to
produce or are issued credentials, the enterprise may institute policies regarding password length,
life cycle, and other details and may provide MFA as an option or requirement. However,enterprises are limited in the policies they can implement for this class of user. Information about
incoming requests may be useful in determining the state of the public service and detecting
possible attacks masquerading as legitimate users. For example, a registered user portal is known
to be accessed by registered customers using one of a set of common web browsers. A sudden
increase in access requests from unknown browser types or known outdated versions could
indicate an automated attack of some kind, and the enterprise could take steps to limit requests
from these identified clients. The enterprise should also be aware of any statutes or regulations
regarding what information can be collected and recorded about the requesting users and assets.

Enterprise with Public- or Customer-Facing Services

26

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1069

5

1070
1071
1072
1073

No enterprise can eliminate cybersecurity risk. When complemented with existing cybersecurity
policies and guidance, identity and access management, continuous monitoring, and generalcyber hygiene, ZTA can reduce overall risk exposure and protect against common threats.
However, some threats have unique features when implementing a ZTA.

1074

5.1

1075
1076
1077
1078
1079
1080
1081
1082
1083

In ZTA, the policy engine and policy administrator are the key components of the entire
enterprise. No communication between enterprise resources occurs unless it is approved andpossibly configured by the PE and PA. This means that these components must be properly
configured and maintained. Any enterprise administrator with configuration access to the PE’s
rules may be able to perform unapproved changes or make mistakes that can disrupt enterprise
operations. Likewise, a compromised PA could allow access to resources that would otherwise
not be approved (e.g., to a subverted, personally-owned device). Mitigating associated risks
means that the PE and PA components must be properly configured and monitored, and any
configuration changes must be logged and subject to audit.

1084

5.2

1085
1086
1087
1088
1089
1090

In ZTA, the PA is the key component for resource access. Enterprise resources cannot connect toeach other without the PA’s permission and, possibly, configuration action. If an attacker
disrupts or denies access to the PEP(s) or PA (i.e., DoS attack or route hijack), it can adversely
impact enterprise operations. Enterprises can mitigate this threat by having the policy
enforcement reside in a cloud or be replicated in several locations following guidance on cyber
resiliency [SP 800-160].

1091
1092
1093
1094
1095
1096

This mitigates the risk but does not eliminate it. Botnets such as Mirai produce massive DoS
attacks against key internet service providers and disrupt service to millions of internet users. 5 It
is also possible that an attacker could intercept and block traffic to a PEP or PA from a portion or
all of the user accounts within an enterprise (e.g., a branch office or even a single remote
employee). In such cases, only a portion of enterprise users is affected. This is also possible intraditional VPN-based access and is not unique to ZTA.

1097
1098
1099
1100

A hosting provider may also accidentally take a cloud-based PE or PA offline. Cloud services
have experienced disruptions in the past, both infrastructure as a service 6 and SaaS. 7 An
operational error could prevent an entire enterprise from functioning if the policy engine orpolicy administrator component becomes inaccessible from the network.

1101

There is also the risk that enterprise resources may not be reachable from the PA, so even if

5

Threats Associated with Zero Trust Architecture

Subversion of ZTA Decision Process

Denial-of-Service or Network Disruption

https://blog.cloudflare.com/inside-mirai-the-infamous-iot-botnet-a-retrospective-analysis/

6 https://aws.amazon.com/message/41926/

7 https://www.nzherald.co.nz/business/news/article.cfm?c_id=3&objectid=12286870

27

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1102
1103
1104
1105

access is granted to a user, the PA cannot configure the communication path from the network.
This could happen due to an attack or simply due to unexpected heavy usage. This is similar toany other network disruption in that some or all enterprise users cannot access a particular
resource due to that resource not being available for some reason.

1106

5.3

1107
1108
1109
1110
1111
1112
1113

Properly implemented ZT, information security and resiliency policies, and best practices reduce
the risk of an attacker gaining broad access via stolen credentials or insider attack. The ZT
principle of no implicit trust based on network location means attackers need to compromise an
existing account or device to gain a foothold in an enterprise. A properly implemented ZTA
should prevent a compromised account or asset from accessing resources outside its normal
purview or access patterns. This means that accounts with access policies around resources thatan attacker is interested in would be the primary targets for attackers.

1114
1115
1116
1117
1118
1119
1120
1121
1122
1123

Attackers may use phishing, social engineering, or a combination of attacks to obtain credentials
of valuable accounts. “Valuable” may mean different things based on the attacker’s motivation.
For instance, enterprise administrator accounts may be valuable, but attackers interested infinancial gain may consider accounts that have access to financial or payment resources of equalvalue. Implementation of MFA for network access may reduce the risk of access from acompromised account. However, just like traditional enterprises, an attacker with valid
credentials (or a malicious insider) may still be able to access resources for which the accounthas been granted access. For example, an attacker or compromised employee who has thecredentials and enterprise-owned asset of a valid human resources employee may still be able toaccess an employee database.

1124
1125
1126
1127
1128
1129
1130

ZTA increases resistance to this attack and prevents any compromised accounts or assets frommoving laterally throughout the network. If the compromised credentials are not authorized toaccess a particular resource, they will continue to be denied access to that resource. In addition, acontextual trust algorithm (see Section 3.3.1) is more likely to detect and respond quickly to this
attack than when occurring in a traditional, perimeter-based network. The contextual TA candetect access patterns that are out of normal behavior and deny the compromised account or
insider threat access to sensitive resources.

1131

5.4

1132
1133
1134
1135
1136
1137
1138
1139

As mentioned in Section 3.4.1, all traffic is inspected and logged on the network and analyzed to
identify and react to potential attacks against the enterprise. However, as also mentioned, some(possibly the majority) of the traffic on the enterprise network may be opaque to traditional layer
3 network analysis tools. This traffic may originate from nonenterprise-owned assets (e.g.,contracted services that use the enterprise infrastructure to access the internet) or applications
that are resistant to passive monitoring. The enterprise cannot perform deep packet inspection or
examine the encrypted traffic and must use other methods to assess a possible attacker on the
network.

1140
1141

That does not mean that the enterprise is unable to analyze encrypted traffic that it sees on the
network. The enterprise can collect metadata about the encrypted traffic and use that to detect an

Stolen Credentials/Insider Threat

Visibility on the Network

28

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1142
1143
1144
1145
1146
1147

active attacker or possible malware communicating on the network. Machine learning techniques[Anderson] can be used to analyze traffic that cannot be decrypted and examined. Employing
this type of machine learning would allow the enterprise to categorize traffic as valid or possibly
malicious and subject to remediation. In a ZTA deployment, only the traffic from nonenterpriseowned assets would need to be examined in this way as all enterprise traffic is subject to analysis
by the policy administrator via the PEPs.

1148

5.5

1149
1150
1151
1152
1153
1154

A related threat to enterprise analysis of network traffic is the analysis component itself. If
network traffic and metadata are being stored for building contextual policies, forensics, or later
analysis, that data becomes a target for attackers. Just like network diagrams, configuration files,
and other assorted network architecture documents, these resources should be protected. If an
attacker can successfully gain access to stored traffic information, they may be able to gain
insight into the network architecture and identify assets for further reconnaissance and attack.

1155
1156
1157
1158

Another source of reconnaissance information for an attacker in a ZT enterprise is the
management tool used to encode access policies. Like stored traffic, this component contains
access policies to resources and can give an attacker information on which accounts are mostvaluable to compromise (e.g., the ones that have access to the desired data resources).

1159
1160
1161
1162

As for all valuable enterprise data, adequate protections should be in place to prevent
unauthorized access and access attempts. As these resources are vital to security, they shouldhave the most restrictive access policies and be accessible only from designated or dedicatedadministrator accounts.

1163

5.6

1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176

ZTA relies on several different data sources to make access decisions, including information
about the requesting user, asset used, enterprise and external intelligence, and threat analysis.
Often, the assets used to store and process this information do not have a common, open standard
on how to interact and exchange information. This can lead to instances where an enterprise islocked into a subset of providers due to interoperability issues. If one provider has a security
issue or disruption, an enterprise may not be able to migrate to a new provider without extreme
cost (e.g., replacing several assets) or going through a long transition program (e.g., translating
policy rules from one proprietary format to another). Like DoS attacks, this risk is not unique toZTA, but because ZTA is heavily dependent on the dynamic access of information (bothenterprise and service providers), disruption can affect the core business functions of anenterprise. To mitigate associated risks, enterprises should evaluate service providers on aholistic basis by considering factors such as vendor security controls, enterprise switching costs,
and supply chain risk management.

1177

5.7

1178
1179
1180
1181

Artificial intelligence and other software-based agents are being deployed to manage security
issues on enterprise networks. These components need to interact with the management
components of ZTA (e.g., policy engine, policy administrator), sometimes in lieu of a humanadministrator. How these components authenticate themselves in an enterprise implementing a

Storage of Network Information

Reliance on Proprietary Data Formats

Use of Non-person Entities (NPE) in ZTA Administration

29

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1182
1183

ZTA is an open issue. It is assumed that most automated technology systems will use somemeans to authenticate when using an API to resource components.

1184
1185
1186
1187

The biggest risk when using automated technology for configuration and policy enforcement is
the possibility of false positives (innocuous actions mistaken for attacks) and false negatives(attacks mistaken for normal activity). This can be reduced with regular retuning analysis tocorrect mistaken decisions and improve the decision process.

1188
1189
1190
1191
1192
1193
1194

The associated risk is that an attacker will be able to induce or coerce an NPE to perform sometask that the attacker is not privileged to perform. The software agent may have a lower bar forauthentication (e.g., API key versus MFA) to perform administrative or security-related tasks
compared with a human user. If an attacker can interact with the agent, they could theoreticallytrick the agent into allowing the attacker greater access or into performing some task on behalf of
the attacker. There is also a risk that an attacker could gain access to a software agent’s
credentials and impersonate the agent when performing tasks.

30

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1195
1196

6

Zero Trust Architecture and Possible Interactions with Existing Federal
Guidance

1197
1198
1199
1200
1201
1202

Several existing federal policies and guidance intersect with the planning, deployment, andoperation of a ZTA. These policies do not prohibit an enterprise from moving to a more zerotrust-oriented architecture but can influence development of a zero trust strategy for an agency.
When complemented with existing cybersecurity policies and guidance, ICAM, continuous
monitoring, and general cyber hygiene, ZTA may reinforce an organization’s security postureand protect against common threats.

1203

6.1

1204
1205
1206
1207
1208
1209
1210

A ZTA deployment involves developing access polices around acceptable risk to the designatedmission or business process (see Section 7.3.3). It is possible to deny all network access to a
resource and allow access only via a connected terminal, but this is disproportionately restrictivein the majority of cases and inhibits work from being accomplished. For a federal agency toperform its mission, there is an acceptable level of risk. The risks associated with performing the
given mission must be identified, evaluated, and mitigated. To assist in this, the NIST Risk
Management Framework (RMF) was developed.

1211
1212
1213
1214

ZTA planning and implementation may change the authorization boundaries defined by theenterprise. This is due to the addition of new components (e.g., policy engine, policy
administrator, and PEPs) and a reduction of reliance on network perimeter defenses. The overall
process described in the RMF will not change in a ZTA.

1215

6.2

1216
1217
1218
1219
1220
1221
1222
1223
1224

Protecting the privacy of users and private information (e.g., personally identifiable information)
is a prime concern for organizations. Privacy and data protections are included in complianceprograms such as FISMA and the Heath Insurance Portability and Accountability Act (HIPAA).
In response, NIST produced a Privacy Framework for use by organizations [NISTPRIV]. This
document provides a framework to describe privacy risks and mitigation strategies, as well as aprocess for an enterprise to identify, measure, and mitigate risks to user privacy and private
information stored and processed by an organization. This includes personal information used by
the enterprise to support ZTA operations and any biometric attributes used in access request
evaluations.

1225
1226
1227
1228
1229
1230
1231
1232

Part of the core requirements for ZTA is that an enterprise should inspect and log traffic (ormetadata when dealing with encrypted traffic) in its environment. Some of this traffic may
contain private information or have associated privacy risks. Organizations will need to identify
any possible risks associated with intercepting, scanning, and logging network traffic [NISTIR8062]. This may include actions such as informing users, obtaining consent (via a login page,banner, or similar), and educating enterprise users. The NIST Privacy Framework could help indeveloping a formal process to identify and mitigate any privacy-related risks to an enterprisedeveloping a zero trust architecture.

ZTA and NIST Risk Management Framework

ZT and NIST Privacy Framework

31

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1233

6.3

1234
1235
1236
1237
1238

User provisioning is a key component of ZTA. The policy engine cannot determine if attempted
connections are authorized to connect to a resource if the PE has insufficient information to
identify associated users and resources. Strong user provision and authentication policies need to
be in place before moving to a more zero trust–aligned deployment. Enterprises need a clear setof user attributes and policies that can be used by a PE to evaluate access requests.

1239
1240
1241
1242
1243
1244
1245
1246

The Office of Management and Budget (OMB) issued M-19-17 on improving identity
management for the Federal Government. The goal of the policy is to develop “…a common
vision for identity as an enabler of mission delivery, trust, and safety of the Nation” [M-19-17].
The memo calls on all federal agencies to form an ICAM office to govern efforts related to
identity issuance and management. Many of these management policies should use therecommendations in NIST SP 800-63-3, Digital Identity Guidelines [SP800-63]. As ZTA is
heavily dependent on precise identity management, any ZTA effort will need to integrate theagency’s ICAM policy.

1247

6.4

1248
1249
1250
1251
1252
1253
1254
1255
1256
1257

Trusted Internet Connections (TIC) is a federal cybersecurity initiative jointly managed by the
Office of Management and Budget (OMB), the Department of Homeland Security Cybersecurity& Infrastructure Security Agency (DHS CISA), and the General Services Administration toestablish a network security baseline across the Federal Government. Historically, TIC was aperimeter-based cybersecurity strategy that required agencies to consolidate and monitor theirexternal network connections. Inherent in TIC 1.0 and TIC 2.0 is the assumption that the insideof the perimeter is trusted, whereas ZTA assumes that network location does not infer trust (i.e.,there is no trust on an agency’s internal network). TIC 2.0 provides a list of network-based
security capabilities (e.g., content filtering, monitoring, authentication) to be deployed at the TIC
access point at the agency’s perimeter; many of these capabilities are aligned with ZTA.

1258
1259
1260
1261
1262
1263
1264
1265
1266
1267

TIC 3.0 will be updated to accommodate cloud services and mobile devices [M-19-26]. In TIC
3.0, agencies can define trust zones as low trust, moderate trust, and high trust based on the levelof control, transparency, and verification that an agency has over a particular computing
environment as well as the sensitivity of data associated with that environment. In addition, TIC
3.0 has updated the network-based security capabilities to be applied to multiple PEPs, which arelocated at the boundary of a trust zone and not at a single PEP at the agency perimeter. Many ofthese TIC 3.0 security capabilities directly support ZTA (e.g., encrypted traffic, default/deny,virtualization security, network and asset inventory). TIC 3.0 defines specific use cases that
describe the implementation of trust zones and security capabilities across specific applications,services, and environments.

1268
1269
1270
1271

TIC 3.0 is focused on network-based security protections, whereas ZTA is a more inclusivearchitecture that addresses application, user, and data protections. As TIC 3.0 evolves its use
cases, it is likely that a ZTA TIC use case will be developed to define the network protections to
be deployed at ZTA enforcement points.

ZTA and Federal Identity, Credential, and Access Management Architecture

ZTA and Trusted Internet Connections 3.0

32

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1272

6.5

1273
1274
1275
1276
1277
1278
1279

NCPS (also known as EINSTEIN) is an integrated system-of-systems that delivers intrusion
detection, advanced analytics, information sharing, and intrusion prevention capabilities todefend the Federal Government from cyber threats. The goals of NCPS, which align with theoverarching goals of zero trust, are to manage cyber risk, improve cyber protection, andempower partners to secure cyber space. EINSTEIN sensors enable CISA’s National
Cybersecurity and Communications Integration Center to defend federal networks and respondto significant incidents at federal agencies.

1280
1281
1282
1283
1284
1285
1286
1287
1288

The placement of NCPS sensors is based on a perimeter network defense in the Federal
Government, while zero trust architectures move protections closer to the data and resources. If
ZTA is adopted across the Federal Government, the NCPS implementation would need to
evolve, or new capabilities would need to be deployed to fulfill NCPS objectives. Incident
responders could potentially leverage information from authentication, traffic inspection, andlogging of agency traffic available to federal agencies that have implemented a zero trustarchitecture. Information generated in a ZTA may better inform event impact quantification.
Machine learning tools could use ZTA data to improve detection, and additional logs from ZTA
may be saved for after-the-fact analyses by incident responders.

1289

6.6

1290
1291
1292
1293

The DHS CDM program is an effort to improve federal agency information technology (IT).
Vital to that posture is an agency’s insight into the assets, configuration, and users within itself.
To protect a system, agencies need to set up processes to discover and understand the basic
components and actors in their infrastructure:

1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312

ZTA and EINSTEIN (NCPS – National Cybersecurity Protection System)

ZTA and DHS Continuous Diagnostics and Mitigations (CDM) Program

•
•
•
•

What is connected? What devices, applications, and services are used by theorganization? This includes observing and improving the security posture of these
artifacts as vulnerabilities and threats are discovered.
Who is using the network? What users are part of the organization or are external andallowed to access enterprise resources? These include NPEs that may be performing
autonomous actions.
What is happening on the network? An enterprise needs insight into traffic patterns
and messages between systems.
How is data protected? The enterprise needs a set policy on how information isprotected at rest, in transit, and in use.

Having a strong CDM program implementation is key to the success of ZTA. For example, tomove to ZTA, an enterprise must have a system to discover and record physical and virtual
assets to create a usable inventory. The DHS CDM program has initiated several efforts to build
the capabilities needed within federal agencies to move to a ZTA. For example, the DHS
Hardware Asset Management (HWAM) [HWAM] program is an effort to help agencies identify
devices on their network infrastructure to deploy a secure configuration. This is similar to thefirst steps in developing a road map to ZTA. Agencies must have visibility into the assets activeon the network (or those accessing resources remotely) to categorize, configure, and monitor the
network’s activity.
33

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1313

6.7

1314
1315
1316
1317

The Cloud Smart 8 strategy, updated Data Center Optimization Initiative [M-19-19] policy, andFederal Data Strategy 9 all influence some requirements for agencies planning a ZTA. These
policies require agencies to inventory and assess how they collect, store, and access data, both onpremises and in the cloud.

1318
1319
1320
1321
1322

This inventory is critical to determining what business processes and resources would benefit
from implementing a ZTA. Data resources and applications that are primarily cloud-based or
primarily used by remote workers are good candidates for a ZTA approach (see Section 7.3.3)
because the users and resources are located outside of the enterprise network perimeter and arelikely to see the most benefit in use, scalability, and security.

1323
1324
1325
1326

One additional consideration with the Federal Data Strategy is how to make agency data assets
accessible to other agencies or the public. This corresponds with the cross-enterprisecollaboration ZTA use case (see Section 4.4). Agencies using a ZTA for these assets may need totake collaboration or publication requirements into account when developing the strategy.

ZTA, Cloud Smart, and the Federal Data Strategy

1327

8 Federal Cloud Computing Strategy: https://cloud.cio.gov/strategy/
9 Federal Data Strategy: https://strategy.data.gov/

34

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1328

7

Migrating to a Zero Trust Architecture

1329
1330
1331
1332
1333

Implementing a ZTA is a journey rather than a wholesale replacement of infrastructure orprocesses. An organization should seek to incrementally implement zero trust principles, processchanges, and technology solutions that protect its highest value data assets. Most enterprises willcontinue to operate in a hybrid zero-trust/perimeter-based mode for an indefinite period while
continuing to invest in ongoing IT modernization initiatives.

1334
1335
1336
1337
1338
1339

How an enterprise migrates to a strategy depends on its current cybersecurity posture andoperations. An enterprise should reach a baseline of competence before it becomes possible todeploy a significant ZT-focused environment [ACT-IAC]. This baseline includes having assets,
users, and business processes identified and cataloged for the enterprise. The enterprise needs
this information before it can develop a list of candidate business processes and the users/assets
involved in this process.

1340

7.1

1341
1342
1343
1344
1345
1346
1347
1348

In a greenfield approach, it would be possible to build a zero trust architecture from the ground
up. Assuming the enterprise knows the applications and workflows that it wants to use for its
operations, it can produce an architecture based on zero trust tenets for those workflows. Once
the workflows are identified, the enterprise can narrow down the components needed and begin
to map how the individual components interact. From that point, it is an engineering andorganizational exercise in building the infrastructure and configuring the components. This may
include additional organizational changes depending on how the enterprise is currently set up
and operating.

1349
1350
1351
1352
1353
1354
1355
1356
1357

In practice, this is rarely a viable option for federal agencies or any organization with an existing
network. However, there may be times when an organization is asked to fulfill a new
responsibility that would require building its own infrastructure. In these cases, it might bepossible to introduce ZT concepts to some degree. For example, an agency may be given a new
responsibility that entails building a new application and database. The agency could design the
newly needed infrastructure around ZT principles, such as having users’ trust evaluated before
access is granted and having micro-perimeters around new resources. The degree of successdepends on how dependent this new infrastructure is on existing resources (e.g., ID management
systems).

1358

7.2

1359
1360
1361
1362
1363
1364
1365

It is unlikely that any significant enterprise can migrate to zero trust in a single technology
refresh cycle. There may be an indefinite period when ZTA workflows coexist in a traditional
enterprise. Migration to a ZTA approach to the enterprise may take place one business process at
a time. The enterprise needs to make sure that the common elements (e.g., ID management,
device management, event logging) are flexible enough to operate in a ZTA and perimeter-based
hybrid security architecture. Enterprise architects may also want to restrict ZTA candidate
solutions to those that can interface with existing components.

Pure Zero Trust Architecture

Hybrid ZTA and Perimeter-Based Architecture

35

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1366

7.3

1367
1368
1369
1370
1371
1372

Migrating to ZTA requires an organization to have detailed knowledge of its assets (physical andvirtual), users (including user privileges), and business processes. This knowledge is accessed by
the PE when evaluating resource requests. Incomplete knowledge will most often lead to abusiness process failure where the PE denies requests due to insufficient information. This isespecially an issue if there are unknown “shadow IT” deployments operating within an
organization.

1373
1374
1375
1376
1377
1378

Before undertaking an effort to bring ZTA to an enterprise, there should be a survey of assets,
users, data flows, and workflows. This is the foundation state that must be reached before a ZTA
deployment is possible. These surveys can be conducted in parallel, but both are tied to
examination of the business processes of the organization. These steps can be mapped to thesteps in the RMF [SP800-37] as any adoption of a ZTA is a process to reduce risk to an agency’s
business functions. The pathway to implementing a ZTA can be visualized in Figure 12.

Steps to Introducing ZTA to a Perimeter-Based Architected Network

1379
1380

Figure 12: ZTA Deployment Cycle

1381
1382
1383
1384
1385

After the initial inventory is created, there is a regular cycle of maintenance and updating. Thisupdating may either change business processes or not have any impact, but an evaluation ofbusiness processes should be conducted. For example, a change in digital certificate providers
may not appear to have a significant impact but may involve certificate root store management,
Certificate Transparency log monitoring, and other factors that are not apparent at first.
36

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1386

7.3.1

1387
1388
1389

For a zero trust enterprise to operate, the PE must have knowledge of enterprise subjects.
Subjects could encompass both human and possible NPEs, such as service accounts that interact
with resources.

1390
1391
1392
1393
1394
1395
1396

Users with special privileges, such as developers or system administrators, require additional
scrutiny when being assigned attributes or roles. In a traditional security architecture, theseaccounts may have blanket permission to access all enterprise resources. ZTA should allow
developers and administrators to have sufficient flexibility to satisfy their business requirements
while using logs and audit actions to identify access behavior patterns. ZTA deployments may
require administrators to satisfy a more stringent confidence level or criteria as outlined in NIST
SP 800-63A, Section 5 [SP800-63A].

1397

7.3.2

1398
1399
1400
1401
1402
1403
1404
1405
1406

As mentioned in Section 2.1, one of the key requirements of ZTA is the ability to identify andmanage devices. ZTA also requires the ability to identify and monitor nonenterprise-owned
devices that may be on enterprise-owned network infrastructure or that access enterprise
resources. The ability to manage enterprise assets is key to the successful deployment of ZTA.
This includes hardware components (e.g., laptops, phones, IoT devices) and digital artifacts (e.g.,user accounts, applications, digital certificates). It may not be possible to conduct a complete
census on all enterprise-owned assets, so an enterprise should consider building the capability toquickly identify, categorize, and assess newly discovered assets that are on enterprise-owned
infrastructure.

1407
1408
1409
1410
1411
1412

This goes beyond simply cataloging and maintaining a database of enterprise assets. This also
includes configuration management and monitoring. The ability to observe the current state of anasset is part of the process of evaluating access requests (see Section 2.1). This means that theenterprise must be able to configure, survey, and update enterprise assets, such as virtual assets
and containers. This also includes both its physical (as best estimated) and network location. This
information should inform the PE when making resource access decisions.

1413
1414
1415
1416
1417
1418
1419
1420

Nonenterprise-owned assets and enterprise-owned “shadow IT” should also be cataloged as wellas possible. This may include whatever is visible by the enterprise (e.g., MAC address, network
location) and augmented by administrator data entry. This information is not only used for accessdecisions (as collaborator and BYOD assets may need to contact PEPs) but also for monitoring
and forensics logging by the enterprise. Shadow IT presents a special problem in that theseresources are enterprise-owned but not managed like other resources. Certain ZTA approaches(mainly network-based) may even cause shadow IT components to become unusable as they may
not be known and included in network access policies.

1421
1422
1423
1424
1425

Many federal agencies have already begun identifying enterprise assets. Agencies that haveestablished CDM program capabilities, such as HWAM [HWAM] and Software AssetManagement (SWAM) [SWAM], have a rich set of data to draw from when enacting a ZTA.
Agencies may also have a list of ZTA candidate processes that involve High Value Assets(HVA) [M-19-03] that have been identified as key to the agency mission. This work would need

Identify Actors on the Enterprise

Identify Assets Owned by the Enterprise37

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1426
1427
1428
1429

to exist enterprise- or agency-wide before any business process could be (re)designed with aZTA. These programs must be designed to be expandable and adaptable to changes in theenterprise, not only when migrating to ZTA but also when accounting for new assets, services,and business processes that become part of the enterprise.

1430

7.3.3

1431
1432
1433
1434
1435
1436

The third inventory that an agency should undertake is to identify and rank the businessprocesses, data flows, and their relation in the missions of the agency. Business processes should
inform the circumstances under which resource access requests are granted and denied. An
enterprise may wish to start with a low-risk business process for the first transition to ZTA as
disruptions will likely not negatively impact the entire organization. Once enough experience isgained, more critical business processes can become candidates.

1437
1438
1439
1440
1441

Business processes that utilize cloud-based resources or are used by remote workers are often
good candidates for ZTA and would likely see improvements to availability and security. Rather
than project the enterprise perimeter into the cloud or bring clients into the enterprise network
via a VPN, enterprise clients can request cloud services directly. The enterprise’s PEPs ensurethat enterprise policies are followed before resource access is granted to a client.

1442

7.3.4

1443
1444
1445
1446
1447

The process of identifying a candidate application or business workflow depends on several
factors: the importance of the process to the organization, the group of users affected, and thecurrent state of resources used for the workflow. The value of the asset or workflow based onrisk to the asset or workflow can be evaluated using the NIST Risk Management Framework[SP800-37].

1448
1449
1450
1451
1452
1453

After the asset or workflow is identified, identify all upstream resources (e.g., ID management
systems, databases, micro-services), downstream resources (e.g., logging, security monitoring),
and entities (e.g., users, service accounts) that are used or affected by the workflow. This may
influence the candidate choice as a first migration to ZTA. An application used by an identified
subset of enterprise users (e.g., a purchasing system) may be preferred over one that is vital tothe entire user base of the enterprise (e.g., email).

1454
1455
1456
1457
1458

The enterprise administrators then need to determine the set of criteria (if using a criteria-basedTA) or confidence level weights (if using a score-based TA) for the resources used in thecandidate business process (see Section 3.3.1). Administrators may need to adjust these criteria
or values during the tuning phase. These adjustments are necessary to ensure that policies are
effective but do not hinder access to resources.

1459

7.3.5

1460
1461
1462
1463

Once a list of candidate business processes has been developed, enterprise architects cancompose a list of candidate solutions. Some deployment models (see Section 3.1) are better
suited to particular workflows and current enterprise ecosystems. Likewise, some vendor
solutions are better suited to some use cases than others. These are some factors to consider:

Identify Key Processes and Evaluate Risks Associated with Executing Process

Formulating Policies for the ZTA Candidate

Identifying Candidate Solutions

38

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1464
1465
1466

•

Does the solution require that components be installed on the client asset? This may
limit business processes where nonenterprise-owned assets are used or desired, such as
BYOD or cross-agency collaborations.

1467
1468
1469
1470
1471

•

Does the solution work where the business process resources exist entirely on
enterprise premises? Some solutions assume that requested resources will reside in thecloud (so-called north-south traffic) and not within an enterprise perimeter (east-west
traffic). The location of candidate business process resources will influence candidate
solutions as well as the ZTA for the process.

1472
1473
1474

•

Does the solution provide a means to log interactions for analysis? A key componentof ZT is the collection and use of data related to the process flow that feeds back into thePE when making access decisions.

1475
1476
1477
1478

One solution is to model an existing business process as a pilot program rather than just a
replacement. This pilot program could be made general to apply to several business processes or
be made specific to one use case. The pilot can be used as a “proving ground” for ZTA before
transitioning users to the ZTA deployment and away from the traditional process infrastructure.

1479

7.3.6

1480
1481
1482
1483
1484
1485

Once the candidate workflow and ZTA components are chosen, the initial deployment can start.
Enterprise administrators must implement the developed policies by using the selectedcomponents but may wish to operate in an observation and monitoring mode at first. Few
enterprise policy sets are complete in their first iterations: important user accounts (e.g.,administrator accounts) may be denied access to resources they need or may not need all theaccess privileges they have been assigned.

1486
1487
1488
1489
1490
1491
1492
1493

The new ZT business workflow could be operated in reporting-only mode for some time to makesure the policies are effective and workable. Reporting-only means that access should be granted
for most requests, and logs and traces of connections should be compared with the initialdeveloped policy. Basic policies such as denying requests that fail MFA or appear from known,
blacklisted IP addresses should be enforced and logged, but after initial deployment, accesspolices should be more lenient to collect data from actual interactions of the ZT workflow. If it is
not possible to operate in a more lenient nature, enterprise network operators should monitor logs
closely and be prepared to modify access policies based on operational experience.

1494

7.3.7

1495
1496
1497
1498
1499
1500
1501

When enough confidence is gained and the workflow policy set is refined, the enterprise enters
the steady operational phase. The network and assets are still monitored, and traffic is logged(see Section 2.2.1), but responses and policy modifications are done at a lower tempo as theyshould not be severe. The users and stakeholders of the resources and processes involved should
also provide feedback to improve operations. At this stage, the enterprise administrators canbegin planning the next phase of ZT deployment. Like the previous rollout, a candidate
workflow and solution set need to be identified and initial policies developed.

1502

However, if a change occurs to the workflow, the operating ZT architecture needs to beInitial Deployment and Monitoring

Expanding the ZTA

39

NIST SP 800-207 (SECOND DRAFT)

1503
1504
1505
1506
1507
1508

ZERO TRUST ARCHITECTURE

reevaluated. Significate changes to the system—such as new devices, major updates to software(especially ZT logical components), and shifts in organizational structure—may result in changes
to the workflow or policies. In effect, the entire process should be reconsidered with theassumption that some of the work has already been done. For example, new devices have beenpurchased, but no new user accounts have been created, so only the device inventory needs to be
updated.

40

NIST SP 800-207 (SECOND DRAFT)

1509

ZERO TRUST ARCHITECTURE

References[ACT-IAC]

American Council for Technology and Industry Advisory Council (2019)
Zero Trust Cybersecurity Current Trends. Available athttps://www.actiac.org/zero-trust-cybersecurity-current-trends[Anderson]

Anderson B, McGrew D (2017) Machine Learning for Encrypted
Malware Traffic Classification: Accounting for Noisy Labels and NonStationarity. Proceedings of the 23rd ACM SIGKDD International
Conference on Knowledge Discovery and Data Mining (ACM, Halifax,
Nova Scotia, Canada), pp 1723-1732.
https://doi.org/10.1145/3097983.3098163[BCORE]

Department of Defense CIO (2007). Department of Defense Global
Information Grid Architecture Vision Version 1.0 June 2007.
http://www.acqnotes.com/Attachments/DoD%20GIG%20Architectural%
20Vision,%20June%2007.pdf[CSA-SDP]

Cloud Security Alliance (2015) SDP Specification 1.0. April 2015.
https://cloudsecurityalliance.org/artifacts/sdp-specification-v1-0/[FIPS199]

National Institute of Standards and Technology (2004) Standards for
Security Categorization of Federal Information and Information Systems.
(U.S. Department of Commerce, Washington, DC), Federal Information
Processing Standards Publication (FIPS) 199.
https://doi.org/10.6028/NIST.FIPS.199[Gilman]Gilman E, Barth D (2017) Zero Trust Networks: Building Secure Systems
in Untrusted Networks (O’Reilly Media, Inc., Sebastopol, CA), 1st Ed.

[HWAM]

Department of Homeland Security (2015) Hardware Asset Management(HWAM) Capability Description. Available at https://www.uscert.gov/sites/default/files/cdm_files/HWAM_CapabilityDescription.pdf[IBNVN]R. Cohen, K. Barabash, B. Rochwerger, L. Schour, D. Crisan, R. Birke,
C. Minkenberg, M. Gusat, R. Recio and V. Jain. An Intent-based
Approach for Network Virtualization. 2013 IFIP/IEEE International
Symposium on Integrated Network Management (IM 2013), pp 42-50.
https://ieeexplore.ieee.org/xpl/conhome/6560458/proceeding[JERICHO]

The Jericho Forum (2007) Jericho Forum Commandments, version 1.2.
Available athttps://collaboration.opengroup.org/jericho/commandments_v1.2.pdf[M-19-03]

Office of Management and Budget (2018) Strengthening the
Cybersecurity of Federal Agencies by Enhancing the High Value Asset
Program. (The White House, Washington, DC), OMB Memorandum M41

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

19-03, December 10, 2018. Available at https://www.whitehouse.gov/wpcontent/uploads/2018/12/M-19-03.pdf[M-19-17]

Office of Management and Budget (2019) Enabling Mission Delivery
through Improved Identity, Credential, and Access Management. (TheWhite House, Washington, DC), OMB Memorandum M-19-17, May 21,
2019. Available at https://www.whitehouse.gov/wpcontent/uploads/2019/05/M-19-17.pdf[M-19-19]

Office of Management and Budget (2019) Update on Data Center
Optimization Initiative (DCOI). (The White House, Washington, DC),OMB Memorandum M-19-19, June 25, 2019. Available athttps://datacenters.cio.gov/assets/files/m_19_19.pdf[M-19-26]

Office of Management and Budget (2019) Update to the Trusted Internet
Connections (TIC) Initiative. (The White House, Washington, DC), OMB
Memorandum M-19-26, September 12, 2019. Available athttps://www.whitehouse.gov/wp-content/uploads/2019/09/M-19-26.pdf[NISTIR 7987]

Ferraiolo DF, Gavrila S, Jansen W (2015) Policy Machine: Features,Architecture, and Specification. (National Institute of Standards andTechnology, Gaithersburg, MD), NIST Interagency or Internal Report(IR) 7987, Rev. 1. https://doi.org/10.6028/NIST.IR.7987r1[NISTIR 8062]

Brooks SW, Garcia ME, Lefkovitz NB, Lightman S, Nadeau EM (2017)
An Introduction to Privacy Engineering and Risk Management in Federal
Systems. (National Institute of Standards and Technology, Gaithersburg,
MD), NIST Interagency or Internal Report (IR) 8062.
https://doi.org/10.6028/NIST.IR.8062[NISTPRIV]

National Institute of Standards and Technology (2020) Privacy
Framework: A Tool for Improving Privacy Through Enterprise Risk
Management. Version 1.0 January 16, 2020.
https://www.nist.gov/privacy-framework/privacy-framework[SDNBOOK]T. Nadeau and K. Gray (2013) SDN: Software Defined Networks: An
Authoritative Review of Network Programmability Technologies.
(O’Reilly) 1st Ed.

[SP800-37]

Joint Task Force (2018) Risk Management Framework for Information
Systems and Organizations: A System Life Cycle Approach for Security
and Privacy. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-37, Rev. 2.
https://doi.org/10.6028/NIST.SP.800-37r2[SP800-63]

Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines.
(National Institute of Standards and Technology, Gaithersburg, MD),
42

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

NIST Special Publication (SP) 800-63-3, Includes updates as ofDecember 1, 2017. https://doi.org/10.6028/NIST.SP.800-63-3[SP800-63A]

Grassi PA, Fenton JL, Lefkovitz NB, Danker JM, Choong Y-Y, Greene
KK, Theofanos MF (2017) Digital Identity Guidelines: Enrollment and
Identity Proofing. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-63A, Includes
updates as of December 1, 2017. https://doi.org/10.6028/NIST.SP.80063A[SP800-63-3]

Grassi PA, Garcia ME, Fenton JL (2017) Digital Identity Guidelines.
(National Institute of Standards and Technology, Gaithersburg, MD),NIST Special Publication (SP) 800-63-3, Includes updates as ofDecember 1, 2017. https://doi.org/10.6028/NIST.SP.800-63-3[SP800-160]

Ross R, Pillitteri V, Graubart R, Bodeau D, and McQuaid R (2019)
Developing Cyber Resilient Systems: A Systems Security Engineering
Approach. (National Institute of Standards and Technology, Gaithersburg,
MD), Final Public Draft NIST Special Publication (SP) 800-160, Vol. 2.
Available at https://csrc.nist.gov/publications/detail/sp/800-160/vol2/draft[SP800-162]

Hu VC, Ferraiolo DF, Kuhn R, Schnitzer A, Sandlin K, Miller R,
Scarfone KA (2014) Guide to Attribute Based Access Control (ABAC)
Definition and Considerations. (National Institute of Standards andTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-162,
Includes updates as of February 25, 2019.
https://doi.org/10.6028/NIST.SP.800-162[SWAM]

Department of Homeland Security (2015) Software Asset Management(SWAM) Capability Description. Available at https://www.uscert.gov/sites/default/files/cdm_files/SWAM_CapabilityDescription.pdf

1510
1511

43

NIST SP 800-207 (SECOND DRAFT)

1512

ZERO TRUST ARCHITECTURE

Appendix A—Acronyms

CDM

Continuous Diagnostics and Mitigation

DHS

Department of Homeland Security

NIST

National Institute of Standards and Technology

PA

Policy Administrator

PE

Policy Engine

PEP

Policy Enforcement Point

RMF

NIST Risk Management Framework

SIEM

Security Information and Event Monitoring

ZTA

Zero Trust Architecture

1513

44

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1514

Appendix B—Identified Gaps in the Current State-of-the-Art in ZTA

1515
1516
1517
1518
1519
1520

The current maturity of zero trust components and solutions was surveyed during the research
conducted in the development of this document. This survey concluded that the current state of
the ZTA ecosystem is not mature enough for widespread adoption. While it is possible to use
ZTA strategies to plan and deploy an enterprise environment, there is no single solution thatprovides all the necessary components. Also, few ZTA components available today can be used
for all of the various workflows present in an enterprise.

1521
1522
1523
1524

The following is a summary of identified gaps in the ZTA ecosystem and areas that need further
investigation. Some of these areas have some foundation of work, but how ZTA tenets changethese areas is not well-known as there is not enough experience with diverse ZTA-focusedenterprise environments.

1525

B.1

1526
1527
1528
1529
1530
1531

Multiple vendors were invited to present their products and views on zero trust. The goal of thissurvey was to identify missing pieces that prevent agencies from moving to a zero trust based
enterprise infrastructure now or maintaining an existing ZTA implementation. These gaps can be
categorized into immediate deployment (immediate or short term), systemic gaps that affectmaintenance or operations (short or midterm), and missing knowledge (areas for future research).
They are summarized in Table B-1.

1532

Table B-1: Summary of Identified Deployment Gaps

Technology Survey

Category
Immediate
deployment

Systemic

Areas needing
more research

Example Questions•

How should procurement
requirements be written?

•

How does a ZTA plan work with
TIC, FISMA, and otherrequirements?

•

How can vendor lock-in be
prevented?

•

How do different ZTA environmentsinteract?

•

How will threats evolve in the face of
ZTA?

•

How will business processes change
in the face of ZTA?

45

Identified Gaps•

Lack of a common
framework and vocabularyfor ZTA•

Perception that ZTA
conflicts with existing
policy•Too much reliance onvendor APIs•

What a successful
compromise looks like inan enterprise with a ZTA•

Documented end user
experience in an enterprisewith a ZTA

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1533

B.2

1534
1535
1536
1537
1538

These are the issues that are slowing adoption of a ZTA at present. These were classified as
immediate issues, and no thought of future maintenance or migration was considered for thiscategory. A forward-thinking enterprise may also consider the maintenance category to be of
immediate concern in preventing the initial deployment of ZTA components, but these issues are
considered a separate category for this analysis.

1539

B.2.1

1540
1541
1542
1543
1544

Zero trust as a strategy for the design and deployment of enterprise infrastructure is still aforming concept. Industry has not yet coalesced around a single set of terms or concepts todescribe ZTA components and operations. This makes it difficult for organizations (e.g., federal
agencies) to develop coherent requirements and policies for designing zero trust enterpriseinfrastructure and procuring components.

1545
1546
1547
1548
1549
1550
1551

The driver for Sections 2.1 and 3.1 is an initial attempt to form a neutral base of terms andconcepts to describe ZTA. The abstract ZTA components and deployment models weredeveloped to serve as basic terms and ways to think about ZTA. The goal is to provide acommon way to view, model, and discuss ZTA solutions when developing enterpriserequirements and performing market surveys. The above sections may prove to be incomplete as
more experience is gained with ZTA in federal agencies, but they currently serve as a base for acommon conceptual framework.

1552

B.2.2

1553
1554
1555
1556
1557
1558
1559
1560

There is a misconception that ZTA is a single framework with a set of solutions that areincompatible with the existing view of cybersecurity. Zero trust should instead be viewed as anevolution of current cybersecurity strategies as many of the concepts and ideas have been
circulating for a long time. Federal agencies have been encouraged to take a more zero trust
approach to cybersecurity through existing guidance (see Section 6). If an agency has a mature
ID management system and robust CDM capabilities in place, it is on the road to a ZTA (seeSection 7.3). This gap is based on a misconception of ZTA and how it has evolved from previous
cybersecurity paradigms.

1561

B.3

1562
1563
1564
1565
1566

These are the gaps that affect initial implementation and deployment of ZTA and continued
operation/maturity. These gaps could slow the adoption of ZTA in agencies or result infragmentation of the ZTA component industry. Systemic gaps are areas where open standards(produced either by a standards development organization [SDO] or industry consortium) can
help.

1567

B.3.3

1568
1569

During the technology survey, it became apparent that no one vendor offers a single solution thatwill provide zero trust. Furthermore, it might not be desirable to use a single-vendor solution to

Gaps that Prevent an Immediate Move to ZTA

Lack of Common Terms for ZTA Design, Planning, and Procurement

Perception that ZTA Conflicts with Existing Federal Cybersecurity Policies

Systemic Gaps that Impact ZTA

Standardization of Interfaces Between Components

46

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1570
1571

achieve zero trust and thereby risk vendor lock-in. This leads to interoperability withincomponents not only at the time of purchase but also over time.

1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586

The spectrum of components within the wider enterprise is vast, with many products focusing ona single niche within zero trust and relying on other products to provide either data or some
service to another component (e.g., integration of MFA for resource access). Vendors too often
rely on proprietary APIs provided by partner companies rather than standardized, vendorindependent APIs to achieve this integration. The problem with this approach is that these APIs
are proprietary and single-vendor controlled. The controlling vendor can change the API
behavior, and integrators are required to update their products in response. This requires close
partnerships between communities of vendors to ensure early notification of modifications
within APIs, which may affect compatibility between products. This adds an additional burden
on vendors and consumers: vendors need to expend resources to change their products, andconsumers need to apply updates to multiple products when one vendor makes a change to its
proprietary API. Additionally, vendors are required to implement and maintain wrappers for eachpartner component to allow maximum compatibility and interoperability. For example, many
MFA product vendors are required to create a different wrapper for each cloud provider or
identity management system to be usable in different kinds of client combinations.

1587
1588
1589
1590

On the customer side, this generates additional problems when developing requirements forpurchasing products. There are no standards that purchasers can rely on to identify compatibility
between products. Hence, it is very difficult to create a multiyear road map for moving into ZTA
because it is impossible to identify a minimum set of compatibility requirements for components.

1591

B.3.4

1592
1593
1594
1595

As there is no single solution to developing a ZTA, there is no single set of tools or services for azero trust enterprise. Thus, it is impossible to have a single protocol or framework that enables anenterprise to move to a ZTA. Currently, there is a wide variety of models and solutions seeking
to become the leading authority of ZTA.

1596
1597
1598
1599
1600
1601
1602
1603

This indicates that there is an opportunity for a set of open, standardized protocols or frameworks
to be developed to aid organizations in migrating to a ZTA. SDOs like the Internet Engineering
Task Force (IETF) have specified protocols that may be useful in exchanging threat information(called XMPP-Grid [1]). The Cloud Security Alliance (CSA) has produced a framework for
Software Defined Perimeter (SDP) [2] that may also be useful in ZTA. Efforts should be directed
toward surveying the current state of ZTA-related frameworks or the protocols necessary for a
useful ZTA and toward identifying places where work is needed to produce or improve these
specifications.

1604

B.4

1605
1606
1607
1608

The gaps listed here do not hinder an organization from adopting a ZTA for its enterprise. These
are gray areas in knowledge about operational ZTA environments, and most arise from a lack oftime and experience with mature zero trust deployments. These are areas of future work forresearchers.

Emerging Standards that Address Overreliance on Proprietary APIs

Knowledge Gaps in ZTA and Future Areas of Research

47

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1609

B.4.5

1610
1611
1612
1613

A properly implemented ZTA for an enterprise will improve the enterprise’s cybersecurity
posture over traditional network perimeter-based security. The tenets of ZTA aim to reduce theexposure of resources to attackers and minimize or prevent lateral movement within anenterprise should a host asset be compromised.

1614
1615
1616
1617
1618
1619
1620

However, determined attackers will not sit idle but will instead change behavior in the face ofZTA. The open issue is how the attacks will change. One possibility is that attacks aimed atstealing credentials will be expanded to target MFA (e.g., phishing, social engineering). Anotherpossibility is that in a hybrid ZTA/perimeter-based enterprise, attackers will focus on thebusiness processes that have not had ZTA tenets applied (i.e., follow traditional network
perimeter-based security)—in effect, targeting the low-hanging fruit in an attempt to gain somefoothold in the ZTA business process.

1621
1622
1623

As ZTA matures, more deployments are seen, and experience is gained, the effectiveness of ZTA
in shrinking the attack surface of resources may become apparent. The metrics of success of
ZTA over older cybersecurity strategies will also need to be developed.

1624

B.4.6

1625
1626
1627
1628
1629

There has not been a rigorous examination of how end users act in an enterprise that is using aZTA. This is mainly due to the lack of large ZTA use cases available for analysis. There have,
however, been studies on how users react to MFA and other security operations that are part of a
ZTA enterprise, and this work could form the basis of predicting end user experience andbehavior when using ZTA workflows in an enterprise.

1630
1631
1632
1633
1634
1635
1636
1637

One set of studies that can predict how ZTA affects end user experience is the work done on theuse of MFA in enterprises and security fatigue. Security fatigue [3] is the phenomenon wherein
end users are confronted with so many security policies and challenges that it begins to impact
their productivity in a negative way. Other studies show that MFA may alter user behavior, but
the overall change is mixed [4] [5]. Some users readily accept MFA if the process is streamlined
and involves devices they are used to using or having with them (e.g., applications on asmartphone). However, some users resent having to use personally-owned devices for businessprocesses or feel that they are being constantly monitored for possible violations of IT policies.

1638

B.4.7

1639
1640
1641
1642
1643
1644

The survey of the ZTA vendor ecosystem displayed the wide range of infrastructure that anenterprise deploying a ZTA would need to consider. As previously noted, there is no single
provider of a full zero trust solution at this time. As a result, enterprises will purchase several
different services and products, which can lead to a web of dependencies for components. If one
vital component is disrupted or unreachable, there could be a cascade of failures that impact one
or multiple business processes.

1645
1646
1647

Most products and services surveyed relied on a cloud presence to provide robustness, but evencloud services have been known to become unreachable through either an attack or simple error.
When this happens, key components used to make access decisions may be unreachable or may

Attacker Response to ZTA

User Experience in a ZTA Environment

Resilience of ZTA to Enterprise and Network Disruption

48

NIST SP 800-207 (SECOND DRAFT)

ZERO TRUST ARCHITECTURE

1648
1649
1650
1651
1652

not be able to communicate with other components. For example, PE and PA components
located in a cloud may be reachable during a distributed denial-of-service (DDoS) attack but may
not be able to reach all PEPs located with resources. Research is needed on discovering thepossible choke points of ZTA deployment models and the impact on network operations when a
ZTA component is unreachable or has limited reachability.

1653
1654
1655
1656
1657
1658

The continuity of operations (COOP) plans for an enterprise will likely need revision when
adopting a ZTA. A ZTA makes many COOP factors easier as remote workers may have thesame access to resources that they had on-premises. However, policies like MFA may also havea negative impact if users are not properly trained or lack experience. Users may forget or nothave access to tokens and enterprise devices during an emergency, and that will impact the speed
and effectiveness of enterprise business processes.

1659

B.5

1660

TBD – describe NCCoE test lab and tests to be performed

1661

B.6

References[1]

Cam-Winget N (ed.), Appala S, Pope S, Saint-Andre P (2019) Using
Extensible Messaging and Presence Protocol (XMPP) for Security Information
Exchange. (Internet Engineering Task Force (IETF)), IETF Request forComments (RFC) 8600. https://doi.org/10.17487/RFC8600[2]Software Defined Perimeter Working Group “SDP Specification 1.0” Cloud
Security Alliance. April 2014.

[3]

Stanton B, Theofanos MF, Spickard Prettyman S, Furman S (2016) Security
Fatigue. IT Professional 18(5):26-32. https://doi.org/10.1109/MITP.2016.84[4]Strouble D, Shechtman GM, Alsop AS (2009) Productivity and Usability
Effects of Using a Two-Factor Security System. SAIS 2009 Proceedings (AIS,Charleston, SC), p 37. Available at http://aisel.aisnet.org/sais2009/37[5]

Weidman J, Grossklags J (2017) I Like It but I Hate It: Employee Perceptions
Towards an Institutional Transition to BYOD Second-Factor Authentication.
Proceedings of the 33rd Annual Computer Security Applications Conference(ACSAC 2017) (ACM, Orlando, FL), pp 212-224.
https://doi.org/10.1145/3134600.3134629

ZTA Test Environment

1662

49