NIST SPECIAL PUBLICATION 1800-35

Implementing a Zero Trust Architecture:
High-Level Document
Oliver Borchert
Gema Howell
Alper Kerman
Scott Rose
Murugiah Souppaya

Brian Butler
Mike Delaguardia
Matthew Hyatt
Randy MartinPeter Romness

National Institute ofStandards and Technology

Cisco

Jason Ajmo
Yemi Fashina
Parisa Grayeli
Joseph Hunt
Jason Hurlburt
Nedu Irrechukwu
Joshua Klosterman
Oksana Slivina
Susan Symington
Allen Tan
The MITRE Corporation

Karen Scarfone
Scarfone Cybersecurity

William Barker
Dakota ConsultingPeter Gallagher
Aaron Palermo
AppgateMadhu Balaji
Adam Cerini
Rajarshi Das
AWS (Amazon Web Services)

Jacob BarosinPeter Bjork
Hans Drolshagen
Keith Luck
Jerry Haskins
Dale McKay
Broadcom (VMware)

Corey Bonnell
Dean Coclin
DigiCert

Ryan Johnson
Dung Lam
Darwin Tolbert
F5

Tim Jones
Tom May
Forescout

Christopher Altman
Alex Bauer
Marco Genovese
Google Cloud

Andrew Campagna
John Dombroski
Adam Frank
Nalini Kannan
Priti Patil
Harmeet Singh
Mike Spisak
Krishna Yellepeddy
IBM

Nicholas Herrmann
Corey Lund
Farhan Saifudin

Madhu Dodda
Tim LeMaster
Lookout

Ken Durbin
James Elliott
Earl Matthews
David Pricer
Mandiant

Joey Cruz
Tarek Dawoud
Carmichael Patton
Alex Pavlovsky
BrandonStephenson
Clay Taylor

Don Coltrain
Wade Ellery
Deborah McGinn
Radiant Logic

Frank Briguglio
Ryan Tighe
SailPoint

Kyle Black
Scott Gordon
Sunjeet Randhawa
Symantec by Broadcom

Chris Jensen
Joshua Moll

Microsoft

TenableBob LyonsVinu Panicker

Jason White

Okta

Imran Bashir
Ali Haider
Nishit Kothari
Sean Morgan
Seetal Patel
Norman Wong
Palo Alto Networks

Trellix, Public Sector

Joe Brown
Gary Bradt
Zimperium

Jeffrey Adorno
Syed Ali
Bob SmithZscaler

Zack Austin
Shawn Higgins
Rob Woodworth
PC Matic

Mitchell Lewars
Bryan Rosensteel
Ping Identity

IvantiJuly 2024
FOURTH PRELIMINARY DRAFT
This publication is available free of charge from https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture

FOURTH PRELIMINARY DRAFT

1

DISCLAIMER

2
3
4
5
6
7

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

8910National Institute of Standards and Technology Special Publication 1800-35, Natl. Inst. Stand. Technol.
Spec. Publ. 1800-35, 52 pages, (July 2024), CODEN: NSPUE2

11
12

FEEDBACK

13
14
15
16
17
18

You can view or download the fourth preliminary draft guide at the NCCoE ZTA project page. NIST isusing an agile process to publish this content. As work continues on implementing additional example
solutions, documentation is being made available as soon as possible rather than delaying release until
all builds are completed. You can improve this guide by contributing feedback. As you review and adopt
this solution for your own organization, we ask you and your colleagues to share your experience andadvice with us.

19

Comments on this publication may be submitted to: nccoe-zta-project@list.nist.gov.

20

Public comment period: July 31, 2024 through September 30, 2024

21

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

22

NIST is particularly interested in your feedback on the following questions:

23
24
25

1. How well do the practices in this guide relate to existing practices leveraged by yourorganization? Are there significant gaps between the sets of practices that this guide should
address?

26

2. How do you expect this guide to influence your future practices and processes?

27
28

3. How do you envision using this guide? What changes would you like to see to increase/improvethat use?

29

4. What suggestions do you have on changing the format of the provided information?

30
31
32
33
34
35

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

NIST SP 1800-35: Implementing a Zero Trust Architectureii

FOURTH PRELIMINARY DRAFT

36

NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

37
38
39
40
41
42
43
44
45
46
47
48
49

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

50
51

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

52

NIST CYBERSECURITY PRACTICE GUIDES

53
54
55
56
57
58

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

59
60
61

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

62

ABSTRACT

63
64
65
66
67
68
69
70
71
72
73
74

A zero trust architecture (ZTA) enables secure authorized access to enterprise resources that are
distributed across on-premises and multiple cloud environments, while enabling a hybrid workforce andpartners to access resources from anywhere, at any time, from any device in support of theorganization’s mission. This NIST Cybersecurity Practice Guide explains how organizations canimplement ZTA consistent with the concepts and principles outlined in NIST Special Publication (SP) 800207, Zero Trust Architecture. The NCCoE worked with 24 collaborators under Cooperative Research
Development Agreements (CRADAs) to integrate commercially available technology to build 17 ZTA
example implementations and demonstrate a number of common use cases. Detailed technicalinformation on each build can serve as a valuable resource for your technology implementers byproviding models they can emulate. The lessons learned from the implementations and integrations canbenefit your organization by saving time and resources. This guide also includes mappings of ZTA
principles to commonly used security standards and guidance.

NIST SP 1800-35: Implementing a Zero Trust Architectureiii

FOURTH PRELIMINARY DRAFT75

KEYWORDS

76
77
78

enhanced identity governance (EIG); identity, credential, and access management (ICAM);
microsegmentation; secure access service edge (SASE); software-defined perimeter (SDP); zero trust; zerotrust architecture (ZTA).

79

ACKNOWLEDGMENTS

80

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

81▪

Appgate: Jason Garbis, Adam Rose, Jonathan Roy

82▪

AWS (Amazon Web Services): Conrad Fernandes*, Harrison Holstein, Quint Van Deman

83
84

▪

Broadcom (VMware): Andrew Babakian*, Genc Domi*, Paul Mancuso, Dennis Moreau*, Wayne
Pauley*, Jacob Rapp*

85
86

▪

Cisco: Ken Andrews, Robert Bui, Leo Lebel, Tom Oast, Aaron Rodriguez, Kelly Sennett, Steve
Vetter, Micah Wilson

87▪

F5: Daniel Cayer, David Clark, Jay Kelley, Darrell Pierson

88▪

Forescout: Yejin Jang*, Neal Lucier*89▪

Google Cloud: Tim Knudson*

90
91

▪

IBM: Nilesh Atal, Himanshu Gupta, Lakshmeesh Hegde, Sharath Math, Naveen Murthy, Nikhil
Shah, Deepa Shetty, Harishkumar Somashekaraiah

92▪

IT Coalition: Aaron Cook, Vahid Esfahani*, Jeff Laclair, Ebadullah Siddiqui*, Musumani Woods*

93▪

Ivanti: Patty Arcano, Jeffery Burton, Jay Dineshkumar

94▪

Lookout: Tyler Croak, Jeff Gilhool, Hashim Khan*

95
96

▪

Microsoft: Thomas Detzner, Ehud Itshaki, Janet Jones, Hemma Prafullchandra*, Enrique
Saggese, Sarah Young

97
98

▪

MITRE: Eileen Division*, Spike E. Dog, Sallie Edwards, Ayayidjin Gabiam, Jolene Loveless*, Karri
Meldorf, Kenneth Sandlin, Lauren Swan, Jessica Walton

99▪

NIST: Mike Bartock, Douglas Montgomery, Cherilyn Pascoe, Kevin Stine100▪

Okta: Brian Dack, Sean Frazier, Naveed Mirza, Kelsey Nelson, Ron Wilson

101▪

PC Matic: Andy Tuch

102▪

Ping Identity: Ivan Anderson, Aubrey Turner

103▪

Radiant Logic: Bill Baz, Rusty Deaton, John Petrutiu, Lauren Selby

104▪

SailPoint: Peter Amaral, Jim Russell, Esteban Soto

105▪

Symantec by Broadcom: Eric Michael

106▪

Tenable: Jeremiah Stallcup

107▪

Zimperium: Dan Butzer, Jim Kovach*, Kern Smith108▪

Zscaler: Jeremy James, Lisa Lorenzin*, Matt Moulton, Patrick Perry

109* Former employee; all work for this publication was done while at that organization

110

Special thanks to all who reviewed and provided feedback on this document.

NIST SP 1800-35: Implementing a Zero Trust Architectureiv

FOURTH PRELIMINARY DRAFT
111
112
113
114

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

115

Technology Collaborators

116
117
118
119
120
121
122
123

AppgateAWSBroadcom (VMware)
Cisco
DigiCert
F5
Forescout
Google CloudIBM
IvantiLookout
Mandiant
Microsoft
Okta
Palo Alto Networks
PC Matic

124
125

Note that after the VMware products were implemented at NCCoE, VMware was acquired by
Broadcom.

126

DOCUMENT CONVENTIONS

127
128
129
130
131
132
133

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

NIST SP 1800-35: Implementing a Zero Trust Architecture

Ping Identity
Radiant Logic
SailPoint
Symantec by Broadcom
TenableTrellix
Zimperium
Zscalarv

FOURTH PRELIMINARY DRAFT134

CALL FOR PATENT CLAIMS

135
136
137
138
139
140

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

141
142

ITL may require from the patent holder, or a party authorized to make assurances on its behalf, inwritten or electronic form, either:

143
144

a) assurance in the form of a general disclaimer to the effect that such party does not hold and does not
currently intend holding any essential patent claim(s); or

145
146
147

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

148
149

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

150
151

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

152
153
154
155
156

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

157
158

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

159

Such statements should be addressed to: nccoe-zta-project@list.nist.gov

NIST SP 1800-35: Implementing a Zero Trust ArchitectureviFOURTH PRELIMINARY DRAFT

160

Contents

161
162

1 Introduction to the Guide ....................................................................2

163

1.1

Audience ........................................................................................................................ 2

164

1.2

Scope ............................................................................................................................. 2

165

1.3

How to Use This Guide .................................................................................................. 3166

2 Project Overview .................................................................................4

167

2.1

Motivation for the Project............................................................................................. 4

168

2.2

Challenges in Implementing ZTA ................................................................................... 5

169

2.3

Project Approach ........................................................................................................... 6

170

2.4

Collaborators and Their Contributions .......................................................................... 7

171

3 Architecture and Builds........................................................................7

172

3.1

General ZTA Reference Architecture ............................................................................ 7

173

3.2

EIG Crawl Phase Reference Architecture ...................................................................... 9

174

3.3

EIG Run Phase Reference Architecture ....................................................................... 10

175

3.4

SDP, Microsegmentation, and SASE Reference Architecture ..................................... 10

176

3.5

ZTA Laboratory Physical Architecture ......................................................................... 11

177

3.6

Builds Implemented .................................................................................................... 12178

4 Build Implementation Instructions ..................................................... 16179

5 General Findings ................................................................................ 18

180

5.1

EIG Crawl Phase Findings ............................................................................................ 19

181

5.2

EIG Run Phase Findings ............................................................................................... 20

182

5.3

SDP, Microsegmentation, and SASE Phase Findings ................................................... 21183

6 Functional Demonstrations ................................................................ 22

184

6.1

Demonstration Methodology ...................................................................................... 22

185

6.2

Demonstration Use Cases ........................................................................................... 23

186

6.2.1

Use Case A: Discovery and Identification ................................................................... 23

187

6.2.2

Use Case B: Enterprise-ID Access ............................................................................... 24

188

6.2.3

Use Case C: Collaboration: Federated-ID Access........................................................ 24

189

6.2.4

Use Case D: Other-ID Access ...................................................................................... 25

190

6.2.5

Use Case E: Guest: No-ID Access ................................................................................ 25

NIST SP 1800-35: Implementing a Zero Trust Architecturevii

FOURTH PRELIMINARY DRAFT
191

6.2.6

Use Case F: Confidence Level ..................................................................................... 26

192

6.2.7

Use Case G: Service-Service Interaction ..................................................................... 27

193

6.2.8

Use Case H: Data Level Security Scenarios ................................................................. 27

194

6.3

Functional Demonstration Results .............................................................................. 28

195

6.3.1

Demonstration Result Summaries .............................................................................. 28

196

6.3.2

Demonstration Results in Full .................................................................................... 30

197

7 Risk and Compliance Management .................................................... 32

198

7.1

Risks Addressed by the ZTA Reference Architecture .................................................. 32

199

7.2

ZTA Security Mappings ................................................................................................ 33

200

8 Zero Trust Journey Takeaways ........................................................... 35

201

8.1

Discover and Inventory the Existing Environment ...................................................... 35

202

8.2

Formulate Access Policy to Support the Mission and Business Use Cases ................. 36

203

8.3

Identify Existing Security Capabilities and Technology ............................................... 37

204
205

8.4

Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based Approach
Based on the Value of Data ......................................................................................... 37

206
207

8.5

Implement ZTA Components (People, Process, and Technology) and Incrementally
Leverage Deployed Security Solutions ........................................................................ 38

208

8.6

Verify the Implementation to Support Zero Trust Outcomes..................................... 38

209
210

8.7

Continuously Improve and Evolve Due to Changes in Threat Landscape, Mission,
Technology, and Regulations ...................................................................................... 39

211

Appendix A List of Acronyms ................................................................. 40

212

Appendix B References .......................................................................... 42

213

Appendix C Change Log ......................................................................... 43

214

List of Figures

215

Figure 3-1 General ZTA Reference Architecture ...................................................................................8216

Figure 3-2 EIG Crawl Phase Reference Architecture ........................................................................... 10

217

Figure 3-3 Physical Architecture of ZTA Lab ....................................................................................... 11

NIST SP 1800-35: Implementing a Zero Trust ArchitectureviiiFOURTH PRELIMINARY DRAFT

218

List of Tables

219
220

Table 4-1 Mapping of Builds to Online Details Regarding Architecture Descriptions and
Implementation Instructions ............................................................................................................ 16

221
222

Table 6-1 Mapping of Builds to Online Details Regarding Architecture Descriptions and Functional
Demonstration Results ..................................................................................................................... 30

NIST SP 1800-35: Implementing a Zero Trust Architectureix

FOURTH PRELIMINARY DRAFT

223

Executive Summary

224
225
226
227
228
229
230
231

A zero trust architecture (ZTA) can help your organization protect its data and resources no matter
where they are located. A ZTA can also enable your workforce, contractors, partners, and otherauthorized parties to securely access the data and resources they need from anywhere at any time. ZTAs
implement a risk-based approach to cybersecurity — continuously evaluating and verifying conditions
and requests to decide which access requests should be permitted, then ensuring that each access isproperly safeguarded commensurate with risk. Because of their effectiveness against both internal andexternal threats, ZTAs are increasingly being implemented, and some organizations are already requiredby legislation or regulation to use ZTAs.

232
233
234
235
236
237
238
239

This guide is intended to help your organization plan how to gradually evolve its existing environments
and technologies to a ZTA over time. The insights in this guide are based on a project being led by the
National Cybersecurity Center of Excellence (NCCoE) in collaboration with 24 ZTA technology providers.
Together they have built 17 example ZTA solutions in lab environments and demonstrated each build’s
ability to meet the principles of ZTA. Detailed technical information on each build can also serve as avaluable resource for your technology implementers by providing models they can emulate. The lessons
they have learned from the implementations and integrations can benefit your organization by saving
time and resources.

240
241

By utilizing this guide, your organization can be better positioned to implement a ZTA that achieves thefollowing:

242
243

▪

Supports user access to resources regardless of user location or device (managed or
unmanaged)

244
245

▪

Protects sensitive information and other business assets and processes regardless of theirlocation (on-premises or cloud-based)

246
247

▪

Limits breaches by making it harder for attackers to move through an environment and byaddressing the insider threat (insiders are not automatically trusted)

248
249

▪

Performs continuous, real-time monitoring, logging, and risk-based assessment andenforcement of corporate policy

NIST SP 1800-35: Implementing a Zero Trust Architecture1

FOURTH PRELIMINARY DRAFT

250

1 Introduction to the Guide

251
252
253
254
255
256
257
258
259
260

This guide outlines best practices for the implementation of zero trust architectures (ZTAs). These bestpractices were identified through a collaborative project at the National Cybersecurity Center of
Excellence (NCCoE). The NCCoE and its collaborators are using commercially available technology in lab
environments to build interoperable, open standards-based ZTA implementations that align to theconcepts and principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture [1]. The
implementations include ZTA approaches for enhanced identity governance (EIG), software-defined
perimeter (SDP), microsegmentation, and secure access service edge (SASE). This project is developing,demonstrating, and documenting example ZTA solutions to help inform organizations as they develop
plans to integrate ZTA into their enterprise environments. As the project progresses, this preliminary
draft will be updated.

261

1.1 Audience

262
263
264
265
266
267
268
269

The primary audience for this guide is medium and large enterprises. These enterprises are assumed tohave trained operators and network administrators with the skills to deploy ZTA components andsupporting components for data security, endpoint security, identity and access management, andsecurity analytics. The enterprises are also assumed to have critical resources that require protection,some of which are located on-premises and others of which are in the cloud; and a requirement toprovide partners, contractors, guests, and employees, both local and remote, with secure access tothese critical resources. For a full list of assumptions for this project, see our supplemental Assumptions
documentation.

270
271
272

While this guide supports Executive Order 14028, Improving the Nation’s Cybersecurity [2], which
requires all federal agencies to develop plans to implement ZTA, it is not specific to federal agency
audiences.

273
274

Readers of this guide should already be familiar with ZTA basics and the topics covered in NIST SP 800207, Zero Trust Architecture [1].

275

1.2 Scope

276
277
278
279
280
281
282
283

The scope of this guide is implementing a ZTA for a conventional, general-purpose enterprise IT
infrastructure with support for traditional IT resources such as laptops, desktops, servers, mobile
devices, and other systems with credentials. Discovery of resources, assets, communication flows, andother elements is also within scope. The focus is on using the ZTA to protect access to enterprise data,
regardless of who initiates the access request (e.g., enterprise employees, partners, contractors, or
corporate network guests), from where the access request is initiated (e.g., from the corporate network,a branch office, or the public internet), or where the resources are located, (e.g., on-premises or in thecloud).

284
285
286
287
288

ZTAs for industrial control systems, operational technology (OT) environments, and Internet of Things(IoT) devices are explicitly out of scope for this project. Application of ZTA principles to theseenvironments would be part of a separate project. For information on other related NCCoE projects, see
Ref. [3][4]. Addressing the risk and policy requirements of discovering and classifying data is also out of
scope.

NIST SP 1800-35: Implementing a Zero Trust Architecture2

FOURTH PRELIMINARY DRAFT

289

1.3 How to Use This Guide

290
291
292

This guide provides technical details for 17 example ZTA implementations that were rigorously built in a
lab at NCCoE. They were constructed according to the principles of zero trust and various zero trustarchitecture deployment approaches outlined in NIST SP 800-207, Zero Trust Architecture.

293
294
295
296
297
298
299
300
301

This version of the guide introduces a new manner of content delivery in two formats, one we refer toas the “High-Level Document in PDF Format” and the other as the “Full Document in Web Format.” Thedocument in PDF format is meant to serve as an introductory reading with respect to insight into theproject effort, as it provides a high-level summary of project goals, reference architecture, various ZTA
implementations, and findings. The document in the web format provides in-depth details in terms oftechnologies leveraged, their specific integrations and configurations, and the use cases and scenarios
demonstrated. The web format document also contains information on the implemented security
capabilities and their mappings to the NIST Cybersecurity Framework (CSF) versions 1.1 and 2.0, NIST SP
800-53r5, and security measures outlined in “EO-Critical Software” under Executive Order (EO) 14028.

302
303
304
305

Readers are encouraged to begin by reading the document in PDF format (this document) to perceive ahigh-level insight into the project. Then readers may drill down from this document into the deeper
sections of the linked online document in web format to access in-depth information as needed.
Therefore, this document is organized as follows:

306
307
308
309

▪

Section 2 provides an overview about the NCCoE’s “Implementing a Zero Trust Architecture”
project from the viewpoints of motivation for the project, challenges in implementing ZTAs,
project execution and implementation approach, as well as collaborating organizations and theircontributions on the project.

310
311
312
313
314

▪

Section 3 discusses the reference architectures considered for demonstrating various types of
ZTA deployment approaches used across 17 implementations built. It also lists the technology
products, along with out-of-the-box capabilities used in each build. Furthermore, this section
provides information regarding the NCCoE lab’s physical architecture platform used in
implementing the builds.

315
316
317
318
319

▪

Section 4 lists 17 example implementations in a table format with relevant columns that identify
technology products and capabilities used as “Policy Engines,” as well as ZTA deployment
approaches used in each implementation. Also, additional table columns provide links to details
available in web format with respect to build architecture, technologies used, and flow
diagrams, including instructions for each implementation.

320
321

▪

Section 5 explores the noteworthy findings and conclusions recorded throughout thedemonstration of each ZTA deployment approach across 17 unique lab implementations.

322
323
324

▪

Section 6 discusses the essence of functional demonstrations scoped for the project from theviewpoints of demonstration methodology, use cases, and scenarios. It also lists the functional
demonstration results for each implementation, both in summary and fully detailed formats.

325
326
327

▪

Section 7 provides information regarding each build’s implemented security capabilities andtheir mappings to the NIST CSF versions 1.1 and 2.0, NIST SP 800-53r5, and security measures
outlined in “EO-Critical Software” under EO 14028.

NIST SP 1800-35: Implementing a Zero Trust Architecture3

FOURTH PRELIMINARY DRAFT
328
329
330

▪

Section 8 concludes this document by sharing a list of takeaways as recommended steps for azero trust journey, intended for organizations that are considering ZTA adoption for theirenvironments.

331
332
333

ZTA implementers and others seeking detailed information on designing and deploying ZTA solutions areencouraged to read all sections of the guide, as well as utilize the wealth of additional resources linked
to throughout those sections.

334
335
336

Cybersecurity professionals, compliance professionals, and others who are primarily concerned with
how ZTA solutions relate to the CSF, NIST SP 800-53, and EO 14028 should focus on Section 7 and theresources it links to.

337
338

Anyone interested primarily in the lessons learned from the project should focus on the takeaways
provided in Section 8.

339

2 Project Overview

340

2.1 Motivation for the Project

341
342
343
344
345
346

Protecting enterprise data and resources has become increasingly challenging. Many users need accessfrom anywhere, at any time, from any device to support the organization’s mission. Data is created,
stored, transmitted, and processed across different organizations’ environments, which are distributed
across on-premises and multiple clouds to meet ever-evolving business use cases. It is no longer feasible
to simply protect data and resources at the perimeter of the enterprise environment or to assume thatall users, devices, applications, and services within it can be trusted.

347
348
349
350
351
352
353
354
355
356
357
358
359

A zero-trust architecture (ZTA) enables secure authorized access to assets—machines, applications andservices running on them, and associated data and resources—whether located on-premises or in thecloud, for a hybrid workforce and partners based on an organization’s defined access policy. For eachaccess request, ZTA explicitly verifies the context available at access time—this includes both static user
profile information or non-person entity information such as the requester’s identity and role; anddynamic information such as geolocation, the requesting device’s health and credentials, the sensitivityof the resource, access pattern anomalies, and whether the request is warranted and in accordance withthe organization’s business process logic. If the defined policy is met, a secure session is created toprotect all information transferred to and from the resource. A real-time, risk-based assessment of
resource access and access pattern anomaly detection with continuous policy evaluation are performed
to establish and maintain the access. A ZTA can also protect organizations from non-organizational
resources that their users and applications may connect to, helping to stop threats originating fromoutside of the organization’s control.

360
361
362
363
364
365
366

The goal of this project is to develop and demonstrate various ZTA implementations. NCCoE iscollaborating with ZTA technology providers to build numerous example ZTA solutions and demonstrate
their ability to meet the tenets of ZTA described in NIST SP 800-207. The goal of the solutions is toenforce corporate security policy dynamically and in near-real-time to restrict access to authenticated,authorized users, devices, and non-person entities while flexibly supporting a complex set of diverse
business outcomes involving both remote and on-premises workforces, use of the cloud, partner
collaboration, and support for contractors. The example solutions are designed to demonstrate the

NIST SP 1800-35: Implementing a Zero Trust Architecture

4

FOURTH PRELIMINARY DRAFT
367
368
369

ability to protect against and detect attacks and malicious insiders. They showcase the ability of ZTA
products to interoperate with existing enterprise and cloud technologies while trying to minimize impact
on end-user experience.

370
371
372
373
374
375

The project can help organizations plan how to evolve their existing enterprise environments to ZTA,
starting with an assessment of their current resources, strengths, and weaknesses, and setting
milestones along a path of continuous improvement, gradually bringing them closer to achieving the ZTA
goals they have prioritized based on risk, cost, resources, and their unique mission. The goal is to enableorganizations to thoughtfully apply ZTA controls that best protect their business while enabling them tooperate as they need to.

376

2.2 Challenges in Implementing ZTA

377
378

Throughout this project, numerous challenges organizations may face in implementing ZTA have been
identified, including the following:

379▪

Organization buy-in and support, such as:

380
381
382

o

Perception that ZTA is suited only for large organizations and requires significant
investment rather than understanding that ZTA is a set of guiding principles suitable fororganizations of any size

383
384

o

Concern that ZTA might negatively impact the operation of the environment or end-user
experience

385
386

o

Lack of resources to develop necessary policies and a pilot or proof-of-concept
implementation needed to inform a transition plan

387
388

o

Leveraging existing investments and balancing priorities while making progress toward a
ZTA via modernization initiatives

389
390

o

Lack of understanding regarding what additional skills and training administrators,
security personnel, operators, end users, and policy decision makers may require

391▪

Missing foundational pieces, such as:

392
393
394

o

Lack of adequate asset inventory and management needed to fully understand thebusiness applications, assets, and processes that need to be protected, with no clear
understanding of the criticality of these resources

395
396
397

o

Lack of adequate digital definition, management, and tracking of user roles across theorganization needed to enforce fine-grained, need-to-know access policy for specificapplications and services

398
399
400
401

o

Lack of visibility of the organization’s communications and usage patterns—limited
understanding of the transactions that occur between an organization’s subjects, assets,
applications, and services, and absence of the data necessary to identify thesecommunications and their specific flows

402
403
404
405

o

Lack of information regarding everything that encompasses the organization’s attack
surface. Organizations can usually address threats with traditional security tools in thelayers that they currently manage and maintain such as networks and applications, butelements of a ZTA may extend beyond their normal purview. False assumptions are

NIST SP 1800-35: Implementing a Zero Trust Architecture

5

FOURTH PRELIMINARY DRAFT
406
407
408

often made in understanding the health of a device as well as its exposure to supply
chain risks.
▪

Technical challenges, such as:

409
410

o

Integrating various types of commercially available technologies of varying maturities,
assessing capabilities, and identifying technology gaps to build a complete ZTA

411
412
413

o

Lack of a standardized policy to distribute, manage, and enforce security policy, causingorganizations to face either a fragmentary policy environment or non-interoperable
components

414
415
416

o

Lack of common understanding and language of ZTA across the community and within
the organization, gauging the organization’s ZTA maturity, determining which ZTA
approach is most suitable for the business, and developing an implementation plan

417
418
419

o

There is not a single ZTA that fits all. ZTAs need to be designed and integrated for eachorganization based on the organization’s requirements and risk tolerance, as well as its
existing invested technologies and environments.

420

2.3 Project Approach

421
422
423
424

This project began with a clean laboratory environment that we populated with various applications andservices that would be expected in a typical enterprise to create several baseline enterprisearchitectures. Examples include SIEMs, vulnerability scanning and assessment tools, security validation
tools, and discovery tools.

425
426
427
428
429
430
431

Next, we used a phased approach to develop example ZTA solutions. This approach was designed torepresent how we believe most enterprises will evolve their enterprise architecture toward ZTA, i.e., bystarting with their already-existing enterprise environment and gradually adding or adapting capabilities.
Our first implementations with minimum viable solution were EIG deployments because the identitybased controls provided by EIG are foundational components of ZTA. We called this phase of the project
the EIG crawl phase, which did not include cloud capabilities, and followed by the EIG run phase, which
we added cloud capabilities.

432
433

We gradually deployed additional functional components and capabilities to address an increasing
number of ZTA requirements and deployed microsegmentation, SDP, and SASE approaches.

434
435
436
437
438
439
440

Given the importance of discovery to the successful implementation of a ZTA, we initially deployed it tocontinuously observe the environment and use those observations to audit and validate thedocumented baseline map on an ongoing basis. Because we had instantiated the baseline environment
ourselves, we already had a good initial understanding of it. However, we were able to use the discovery
tools to audit and validate what we deployed and provisioned, correlate known data with information
reported by the tools, and use the tool outputs to formulate initial zero trust policy, ultimately ensuringthat observed network flows correlate to static policies.

441
442
443
444
445

As we continue to develop additional ZTA builds, we do so with the understanding that there is no single
approach for migrating to ZTA that is best for all enterprises and the recognition that ZTA is a set ofconcepts and principles, not a set of technical specifications that can be complied with. The objective,
instead, is continuous improvement of access control processes and policies in accordance with theprinciples of ZTA.

NIST SP 1800-35: Implementing a Zero Trust Architecture

6

FOURTH PRELIMINARY DRAFT

446

2.4 Collaborators and Their Contributions

447
448
449
450
451
452
453

The NCCoE prepared a Federal Register Notice [5] inviting technology providers to provide products
and/or expertise to compose prototype ZTAs. Cooperative Research and Development Agreements(CRADAs) were established with qualified respondents. Collaborators’ components have been composed
into numerous example implementations (i.e., builds). With 24 collaborators participating in the project,
the build teams that were assembled sometimes included vendors that offer overlapping capabilities.
We made an effort to showcase capabilities from each vendor when possible. In other cases, weconsulted with the collaborators to have them work out a solution.

454
455
456

Each of the technology partners and collaborators participating in the project has provided descriptionsof the relevant products and capabilities they bring to this ZTA effort. The descriptions can be found in
our supplemental documentation of Collaborators and Their Contributions.

457
458
459
460
461

The NCCoE does not certify, validate, or endorse products or services. We demonstrate the capabilities
that can be achieved by using participants’ contributed technology. Your organization’s information
security experts should identify the products that will best integrate with your existing tools and IT
system infrastructure. Your organization can adopt this solution or one that adheres to these guidelines
in whole, or you can use this guide as a starting point for tailoring and implementing parts of a solution.

462

3 Architecture and Builds

463
464

This section provides additional information on the project’s ZTA builds and the underlying architectures
they implemented.

465

3.1 General ZTA Reference Architecture

466
467
468
469
470
471
472
473
474
475
476
477
478
479

Figure 3-1 depicts the high-level logical architecture of a general ZTA reference design. This architecture
is intentionally general and is not meant to describe any particular ZTA deployment approach. It consistsof three types of core components: PEs, PAs, and PEPs, as well as several supporting components thatassist the policy engine in making its decisions by providing data and policy rules related to areas such as
ICAM, endpoint security, security analytics, data security, and resource protection. Specific capabilities
that fall into each of these supporting component categories are discussed in more detail in our
supplemental documentation for General ZTA Reference Architecture. The various sets of information
either generated via policy or collected by the supporting components and used as input to ZTA policy
decisions are referred to as policy information points (PIPs). Although the simplicity of the architecture
may seem to imply that the supporting components are simple plug-ins that respond in real-time to the
PDP, in many cases the ICAM, EDR/EPP, security analytics, and data security PIPs will each represent
complex infrastructures. Some ZTA logical component functions may be performed by multiple
hardware or software components, or a single software component may perform multiple logical
functions.

480
481
482
483

Subjects (human users, devices, applications, servers, and other non-human entities that request
information from resources) request and receive access to enterprise resources via the ZTA. Humansubjects are authenticated. Non-human subjects are both authenticated and protected by endpoint
security. Enterprise resources may be located on-premises or in the cloud.

NIST SP 1800-35: Implementing a Zero Trust Architecture

7

FOURTH PRELIMINARY DRAFT
484

Figure 3-1 General ZTA Reference Architecture
Policy Information
Points (PIPs)
Policy Decision
Point (PDP)
I(N): Initial Connection
S(X): Session Management
R(X): Resource Management

I(2). Info needed
to verify subject
and its endpoint

Policy Engine(s) (PEs)
Policy Administrator(s)
(PAs)
I(4).
S(A)/R(A).
Allow/
Accessdeny requests; info
accessneeded toperiodicallyverify subject,resource, andendpoints

Supporting Components
I(3). Information needed toapprove/deny access request
S(B)/R(B). Information needed
to continually evaluate access

S(C). Continue/revoke/limit
session access
R(C). Revoke/limit resource
accessICAM

Endpoint Security

Security Analytics

Data Security

Control Plane

Data Plane

Policy Enforcement
Point(s) (PEPs)

R(1). Authenticate and validate resource

I(5). Session

User
Endpoint

485
486
487
488

S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification

R(D). Periodic resource reauthentication
challenge/response and endpoint hygieneverification

Resource
Cloud On-Prem

Subject

I(1). Initial access request(identity and credentials)

An enterprise ZTA may have numerous PEPs and PDPs. For simplicity, however, Figure 3-1 limits its focus
to the interactions involving a single PDP, a single PEP, a single subject, and a single resource. The
labeled arrows in Figure 3-1 depict the high-level steps performed in support of the ZTA referencearchitecture. These steps can be understood in terms of three separate processes:

489
490
491
492
493
494
495
496
497
498
499
500
501
502

▪

Resource Management—R(): Resource management steps ensure that the resource isauthenticated and that its endpoint conforms to enterprise policy. Upon first being brought
online, a resource’s identity is authenticated and its endpoint hygiene (i.e., health) is verified.
The resource is then connected to the PEP. Once connected to the PEP, access to the resource isgranted only through that PEP at the discretion of the PDP. For as long as the resource continues
to be online, resource management steps are performed to periodically reauthenticate theresource and verify its endpoint hygiene, thereby continually monitoring its health. These steps
are labeled R(1) and R(A) through R(D). Step R(1) occurs first, but the other steps do notnecessarily occur in any specific order with respect to each other, which is why they are labeledwith letters instead of numbers. Their invocation is determined by enterprise policy. For
example, enterprise policy determines how frequently the resource is reauthenticated, what
resource-related information the PDP needs to evaluate each access request and when it needs
it, and what resource-related changes (environmental, security analytics, etc.) would cause the
PDP to decide to revoke or limit access to a particular resource.

503
504
505

▪

Session Initiation Steps—I(): Session initiation steps are a sequence of actions that culminate in
the establishment of the initial session between a subject and the resource to which it hasrequested access. These steps are labeled I(1) through I(5) and they occur in sequential order.

506
507

▪

Session Management Steps—S(): Session management steps describe the actions that enable
the PDP to continually evaluate the session once it has been established. These steps begin to

NIST SP 1800-35: Implementing a Zero Trust Architecture

8

FOURTH PRELIMINARY DRAFT
508
509
510
511
512
513
514
515
516
517

be performed after the session has been established, i.e., after Step I(5), and they continue tobe invoked periodically for as long as the session remains active. These steps are labeled S(A)through S(D) so that they can be distinguished from each other. However, the letters A throughD in the labels are not meant to imply an ordering. The session management steps do notnecessarily occur in any specific order with respect to each other. Their invocation is determinedby the access requests that are made by the subject in combination with enterprise policy. For
example, enterprise policy determines how frequently the subject is reauthenticated, what
information the PDP needs to evaluate each access request and when it needs it, and whatchanges (environmental, security analytics, etc.) would cause the PDP to decide to deny aparticular access request or terminate an established session altogether.

518
519

Details describing each of the steps in these three processes can be found in our supplemental
documentation for ZTA In Operation.

520

3.2 EIG Crawl Phase Reference Architecture

521
522
523
524
525
526
527
528
529

To support the builds in the EIG crawl phase, a constrained version of the general ZTA referencearchitecture depicted in Figure 3-1, called the EIG Crawl Phase Reference Architecture, was used. The
EIG Crawl Phase Reference Architecture is depicted in Figure 3-2. This architecture included only ICAM,
endpoint security, and security analytics components and it focused only on protecting resources thatwere located on premises. It relied on its ICAM components to provide its PDP functionality, and theonly security analytics functionality that it includes is a SIEM. These limitations were intentionally placedon the architecture with the goal of demonstrating the ZTA functionality that an enterprise with legacy
ICAM and endpoint protection solutions deployed on premises will be able to support without having to
add ZTA-specific capabilities.

NIST SP 1800-35: Implementing a Zero Trust Architecture

9FOURTH PRELIMINARY DRAFT
530

Figure 3-2 EIG Crawl Phase Reference Architecture
Policy Information Points(PIPs)
Supporting Components
Identity Management

Policy Decision
Point (PDP)
I(N): Initial Connection
S(X): Session Management
R(X): Resource Management

I(2). Info needed
to verify subject
and its endpoint

ICAM System’s PE
ICAM System’s PA
I(4).
S(A)/R(A).
Allow/
Accessdeny requests; info
accessneeded toperiodicallyverify subject,resource, andendpoints

I(3). Information needed toapprove/deny access request
S(B)/R(B). Information needed
to continually evaluate access

Access and Credential
Management
Multi-Factor
Authentication (MFA)
Federated Identity

S(C). Continue/revoke/limit
session access

Identity Governance

R(C). Revoke/limit resource
accessEndpoint Security
Security Analytics

Control Plane

Data Plane

Policy Enforcement
Point(s) (PEPs)
ICAM System’s PEPs
Other PEPs

User
Endpoint

R(1). Authenticate and validate resource

S(D). Periodic reauthentication
challenge/response and endpoint
hygiene verification

I(5). Session
R(D). Periodic resource reauthentication
challenge/response and endpoint hygieneverification

Resource
Cloud On-Prem

Subject

I(1). Initial access request(identity and credentials)

531

3.3 EIG Run Phase Reference Architecture

532
533
534
535
536
537
538
539
540

The EIG run phase, as its name suggests, built upon the EIG crawl phase architecture. To support thebuilds in the EIG run phase, some constraints on the EIG crawl phase architecture were lifted. The PDP
functionality was no longer required to be provided by the ICAM products used in the build. In addition
to protecting access to resources that are located on-premises, the run phase architecture also protects
access to some resources that are hosted in the cloud. The EIG run phase also includes a device
discovery capability. In addition to monitoring and alerting when new devices are detected,
enforcement can be enabled to deny access to devices that are not compliant. The run phase also
includes the capability to establish a tunnel between the requesting endpoint and the resource being
accessed over which access to the resource can be brokered.

541

3.4 SDP, Microsegmentation, and SASE Reference Architecture

542
543
544
545
546
547
548

Unlike the EIG crawl and run phase builds, there are no constraints on the ZTA reference architecture
when it is used as the underlying design for a build using the SDP, microsegmentation, or SASE
deployment approaches, or some combination of these. The SDP and microsegmentation deployment
approaches are described in NIST SP 800-207. The microsegmentation approach places one or moreresources on unique network segments protected by gateway security components and/or places
software agents or firewalls on endpoint assets to implement host-based microsegmentation. The SDP
approach involves reconfiguring the network based on policy access decisions. When implemented at

NIST SP 1800-35: Implementing a Zero Trust Architecture

10FOURTH PRELIMINARY DRAFT
549
550

the application layer, this may be accomplished by establishing a secure channel between a software
agent on the endpoint requesting access to the resource and the resource gateway.

551
552
553
554
555
556

SASE delivers converged network and security as a service capability, including Software-Defined WideArea Network (SD-WAN), Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Next
Generation Firewall (NGFW) and Zero Trust Network Access (ZTNA). SASE supports branch office,remote worker, and on-premises secure access use cases. SASE is primarily delivered as a service andenables zero trust access based on the identity of the device or entity, combined with real-time context
and security and compliance policies.

557
558
559
560

The example solutions implemented as part of the SDP, microsegmentation, and SASE phase also
integrated additional supporting components and features to provide an increasingly rich set of ZTA
functionalities. The general ZTA reference architecture shown in Figure 3-1, without constraint, is used
to support all builds from the SDP, microsegmentation, and SASE phase of this project.

561

3.5 ZTA Laboratory Physical Architecture

562
563
564
565
566
567
568
569

The NCCoE provides virtual machine resources and physical infrastructure for the ZTA laboratoryenvironment. Figure 3-3 depicts the NCCoE ZTA lab. This environment includes four separate
enterprise environments, each capable of hosting its own distinct implementation of a ZTA
architecture. The enterprises may interoperate as needed by a given use case, and the baseline
enterprise environments have the flexibility to support enhancements. The laboratory environment
also includes a management virtual local area network (VLAN) on which the following components are
installed: Ansible, Terraform, MSV Director, and MSV Protected Theater. These management
components support infrastructure as code (IaC) automation and orchestration.

570

Figure 3-3 Physical Architecture of ZTA Lab

571
572
573

The NCCoE hosts all the collaborators’ ZTA-related software for Enterprises 1, 2, 3, and 4. It also
provides connectivity from the ZTA lab to the NIST Data Center, which provides connectivity to theinternet and public IP spaces (both IPv4 and IPv6).

NIST SP 1800-35: Implementing a Zero Trust Architecture

11

FOURTH PRELIMINARY DRAFT
574
575
576
577
578
579
580
581
582
583
584
585

Access to and from the ZTA lab from within ITOps is protected by a Palo Alto Networks Next Generation
Firewall (PA-5250). (The brick box icons in Figure 3-3 represent firewalls.) In addition to the four
independent enterprises (Enterprises 1, 2, 3, and 4) and the management and orchestration domain, theZTA lab also includes a branch office used only by Enterprise 1, a coffee shop that all enterprises can use,
and an emulated WAN/internet service provider. The emulated WAN service provider provides
connectivity among all the ZTA laboratory networks, i.e., among all the enterprises, the coffee shop, thebranch office, and the management and orchestration domain. Another Palo Alto Networks PA-5250
firewall that is split into separate virtual systems protects the network perimeters of each of theenterprises and the branch office. The emulated WAN service provider also connects the ZTA laboratory
network to ITOps. The ZTA laboratory network has access to cloud services provided by AWS, Azure, IBM
Cloud, and Google Cloud as well as connectivity to SaaS services provided by various collaborators, all ofwhich are available via the internet.

586
587
588
589

Each enterprise within the NCCoE laboratory environment is protected by a firewall and has both IPv4
and IPv6 (dual stack) configured. Each of the enterprises is equipped with a baseline architecture that is
intended to represent the typical environment of an enterprise before a zero trust deployment model isinstantiated.

590
591
592
593

The details of the baseline physical architecture of enterprise 1, enterprise 1 branch office, enterprises
2, 3, and 4, the management and orchestration domain, the coffee shop, and all cloud services, as wellas the baseline software and security capabilities running on this physical architecture, are described inour supplemental ZTA Laboratory Physical Architecture documentation.

594

3.6 Builds Implemented

595
596
597
598
599

The following is a list of the builds that have been implemented in the project, organized by build type.
Each of these builds instantiates the ZTA architecture in a unique way, depending on the equipmentused and the capabilities supported. The products used in each build were based on having out-of-box
integration. Note that after the VMware products were implemented at NCCoE, VMware was acquiredby Broadcom.

600

EIG Crawl Builds:

601
602
603

▪

604
605
606
607
608
609
610
611
612
613

Enterprise 1 Build 1 (E1B1) (EIG Crawl, Okta and Ivanti as PEs) uses products from Amazon Web
Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zimperium.
Certificates from DigiCert are used.
E1B1 components consist of DigiCert CertCentral, IBM Cloud Pak for Security (CP4S), IBM
Security QRadar XDR, Ivanti Access Zero Sign-On (ZSO), Ivanti Neurons for Unified Endpoint
Management (UEM), Ivanti Sentry, Ivanti Tunnel, Mandiant Security Validation (MSV), Okta
Identity Cloud, Okta Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform,
SailPoint IdentityIQ, Tenable.ad, Tenable.io, and Zimperium Mobile Threat Defense (MTD).

▪

Enterprise 2 Build 1 (E2B1) (EIG Crawl, Ping Identity as PE) uses products from Cisco Systems,
IBM, Mandiant, Palo Alto Networks, Ping Identity, Radiant Logic, SailPoint, and Tenable.
Certificates from DigiCert are also used.
E2B1 components consist of Cisco Duo, DigiCert CertCentral, IBM Security QRadar XDR,
Mandiant MSV, Palo Alto Networks Next Generation Firewall (NGFW), PingFederate, which is a

NIST SP 1800-35: Implementing a Zero Trust Architecture

12FOURTH PRELIMINARY DRAFT
614
615
616
617
618
619

service in the Ping Identity Software as a Service (SaaS) offering of PingOne, Radiant Logic
RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Tenable.ad, Tenable.io, andTenable Nessus Network Monitor (NNM).
▪

620
621
622
623
624
625
626
627

E3B1 components consist of DigiCert CertCentral, F5 BIG-IP, Forescout eyeSight, Lookout Mobile
Endpoint Security (MES), Mandiant MSV, Microsoft Azure Active Directory (AD), Microsoft
Defender for Endpoint, Microsoft Endpoint Manager, Microsoft Sentinel, Palo Alto Networks
NGFW, PC Matic Pro, Tenable.ad, and Tenable.io.
EIG Run Builds:
▪

628
629
630
631
632
633
634
635
636

▪

650
651
652
653
654
655

Enterprise 3 Build 2 (E3B2) (EIG Run, Microsoft and Forescout as PEs) uses products from F5,
Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and Tenable. Certificates from
DigiCert are also used.
E3B2 components consist of DigiCert CertCentral, F5 BIG-IP, Forescout eyeControl, Forescout
eyeExtend, Forescout eyeSegment, Forescout eyeSight, Mandiant MSV, Microsoft AD, Microsoft
Azure AD, Microsoft Azure AD (Conditional Access), Microsoft Azure AD Identity Protection,
Microsoft Azure (IaaS), Microsoft Defender for Cloud, Microsoft Defender for Cloud Apps,
Microsoft Defender for Endpoint, Microsoft Intune, Microsoft Office 365 (SaaS), Microsoft
Sentinel, Palo Alto Networks NGFW, PC Matic Pro, Tenable.ad, Tenable.io, and Tenable NNM.

▪

645
646
647
648
649

Enterprise 1 Build 2 (E1B2) (EIG Run, Zscaler as PE) uses products from Amazon Web Services,
IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zscaler. Certificates from
DigiCert are also used.
E1B2 components consist of Amazon Web Services (AWS) Infrastructure as a Service (IaaS),
DigiCert CertCentral, IBM CP4S, IBM Security QRadar XDR, Mandiant MSV, Okta Identity Cloud,Okta Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint
IdentityIQ, Tenable.ad, Tenable.io, Tenable NNM, Zscaler Admin Portal, Zscaler Application
Connector, Zscaler Central Authority, Zscaler Client Connector (ZCC), Zscaler Internet Access(ZIA) Public Service Edges, and Zscaler Private Access (ZPA) Public Service Edges.

637
638
639
640
641
642
643
644

Enterprise 3 Build 1 (E3B1) (EIG Crawl, Microsoft as PE) uses products from F5, Forescout,
Lookout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and Tenable. Certificates from
DigiCert are also used.

Enterprise 4 Build 3 (E4B3) (EIG Run, IBM as PE) uses products from IBM, Mandiant, Palo Alto
Networks, Tenable, and VMware. Certificates from DigiCert are also used.
E4B3 components consist of DigiCert ONE, IBM CP4S, IBM QRadar XDR, IBM Security Guardium
Data Encryption, IBM Security MaaS360 (for both laptops and mobile devices), IBM Security
Verify, Mandiant MSV, Palo Alto Networks GlobalProtect VPN, Tenable.ad, Tenable.io, Tenable
NNM, and VMware infrastructure.

SDP, Microsegmentation, and SASE Builds:▪

Enterprise 1 Build 3 (E1B3) (SDP, Zscaler as PE) uses products from Amazon Web Services, IBM,
Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zscaler. Certificates from DigiCert
are also used.
E1B3 components consist of Amazon Web Services (AWS) Infrastructure as a Service (IaaS),
DigiCert CertCentral, IBM CP4S, IBM Security QRadar XDR, Mandiant MSV, Okta Identity Cloud,Okta Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPointNIST SP 1800-35: Implementing a Zero Trust Architecture

13

FOURTH PRELIMINARY DRAFT
656
657
658
659
660
661

IdentityIQ, Tenable.ad, Tenable.io, Tenable NNM, Zscaler Admin Portal, Zscaler Application
Connector, Zscaler Central Authority, Zscaler Client Connector (ZCC), Zscaler Internet Access(ZIA) Public Service Edges, and Zscaler Private Access (ZPA) Public Service Edges.
▪

662
663
664
665
666
667
668
669
670

E2B3 components consist of Cisco Duo, Cisco Identity Services Engine (ISE), Cisco network
devices, Cisco Secure Endpoint (CSE), Cisco Secure Network Analytics (SNA), Cisco Secure
Workload, DigiCert CertCentral, IBM Security QRadar XDR, Mandiant MSV, Palo Alto Networks
NGFW, Ping Identity PingOne, Radiant Logic RadiantOne Intelligent Identity Data Platform,
SailPoint IdentityIQ, Tenable.ad, Tenable.io, Tenable NNM, VMware Workspace ONE UEM andAccess.
▪

671
672
673
674
675
676
677
678
679
680
681
682
683
684
685

694
695
696
697
698
699

Enterprise 3 Build 3 (E3B3) (SDP and Microsegmentation, Microsoft and Forescout as PEs) uses
products from F5, Forescout, Mandiant, Microsoft, Palo Alto Networks, PC Matic, and Tenable.
Certificates from DigiCert are also used.
E3B3 components consist of DigiCert CertCentral, F5 BIG-IP, Forescout eyeControl, Forescout
eyeExtend, Forescout eyeSight, Forescout eyeSegment, Mandiant MSV, Microsoft AD, Microsoft
Azure AD, Microsoft Azure AD (Conditional Access), Microsoft Azure AD Identity Governance,
Microsoft Intune, Microsoft Sentinel, Microsoft Azure App Proxy, Microsoft Defender for
Endpoint, Microsoft Azure AD Identity Protection, Microsoft Defender for Identity, Microsoft
Defender for Office, Microsoft Entra Permissions Management, Microsoft Defender for CloudApps, Microsoft Purview – Data Loss Prevention (DLP), Microsoft Purview Information
Protection, Microsoft Purview Information Protection Scanner, Microsoft Intune VPN Tunnel,
Microsoft Azure Arc, Microsoft Azure Automanage, Microsoft Intune Privilege AccessWorkstation, Microsoft Azure Virtual Desktop Windows 365, Microsoft Defender for Cloud,Microsoft Azure (IaaS), Microsoft Office 365 (SaaS), Palo Alto Networks NGFW, PC Matic Pro,
Tenable.io, Tenable.ad, and Tenable NNM.

▪

686
687
688
689
690
691
692
693

Enterprise 2 Build 3 (E2B3) (Microsegmentation, Cisco and Ping Identity as PEs) uses products
from Cisco Systems, IBM, Mandiant, Palo Alto Networks, Ping Identity, Radiant Logic, SailPoint,
Tenable, and VMware. Certificates from DigiCert are also used.

Enterprise 1 Build 4 (E1B4) (SDP, Appgate as PE) uses products from Amazon Web Services,
Appgate, IBM, Ivanti, Mandiant, Okta, Radiant Logic, SailPoint, Tenable, and Zimperium.
Certificates from DigiCert are also used.
E1B4 components consist of Appgate SDP Controller, Appgate SDP Gateway, Appgate SDP client,
Appgate Portal, AWS IaaS and SaaS, DigiCert CertCentral, IBM CP4S, IBM Security QRadar XDR,
Ivanti Neurons for UEM Platform, Mandiant MSV, Okta Identity Cloud, Okta Verify App, Radiant
Logic RadiantOne Intelligent Identity Data Platform, SailPoint IdentityIQ, Tenable.ad, Tenable.io,
Tenable NNM, and Zimperium MTD.

▪

Enterprise 2 Build 4 (E2B4) (SDP and SASE, Broadcom as PE) uses products from Google Cloud,IBM, Mandiant, Okta, Radiant Logic, SailPoint, Symantec by Broadcom, Tenable, and VMware.
Certificates from DigiCert are also used.
E2B4 components consist of Symantec Cloud Secure Web Gateway (Cloud SWG), Symantec Zero
Trust Network Access (ZTNA), Symantec Cloud Access Security Broker (CASB), Symantec
Endpoint Security Agent, VMware Workspace ONE UEM, Symantec DLP Cloud Detection Service,
Symantec ZTNA Connector, Okta Identity Cloud, Okta Verify App, Radiant Logic RadiantOneIntelligent Identity Data Platform, SailPoint IdentityIQ, IBM Security QRadar XDR, Tenable.io,
Tenable.ad, Tenable NNM, Mandiant MSV, Google Cloud, and DigiCert CertCentral.

NIST SP 1800-35: Implementing a Zero Trust Architecture

14

FOURTH PRELIMINARY DRAFT
700
701

▪

702
703
704
705
706
707
708

E3B4 components consist of F5 BIG-IP, F5 NGINX Plus, F5 Access App, Microsoft AD, Microsoft
Azure AD, Microsoft Azure AD Identity Governance, Microsoft Intune, Microsoft Sentinel,
Tenable.io, Tenable.ad, Tenable NNM, Mandiant MSV, Forescout eyeControl, Forescout
eyeExtend, Forescout eyeSight, Forescout eyeSegment, Microsoft Azure (IaaS), and DigiCert
CertCentral.
▪

709
710
711
712
713
714
715
716

▪

736
737
738
739
740
741
742
743

Enterprise 1 Build 5 (E1B5) (Microsegmentation and SASE, Palo Alto Networks as PE) uses
products from Amazon Web Services, IBM, Mandiant, Okta, Palo Alto Networks, Radiant Logic,
SailPoint, and Tenable. Certificates from DigiCert are also used.
E1B5 components consist of PAN Panorama, PAN Next Generation Firewall (NGFW), PAN Prisma
Access, PAN Prisma SASE (Prisma Access & Prisma SD-WAN), PAN Cloud Delivered Security
Services (CDSS), PAN Cloud Identity Engine, PAN Global Protect, PAN Strata Cloud Manager,
Okta Identity Cloud, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint
IdentityIQ, Okta Verify App, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable NNM,
Mandiant MSV, DigiCert CertCentral, and AWS IaaS.

▪

726
727
728
729
730
731
732
733
734
735

Enterprise 4 Build 4 (E4B4) (SDP, Microsegmentation, and EIG; VMware as PE) uses products
from IBM, Mandiant, Tenable, and VMware. Certificates from DigiCert are also used.
E4B4 components consist of VMware Workspace ONE Access, VMware Unified Access Gateway(UAG), VMware NSX-T, VMware Workspace ONE UEM, VMware Workspace ONE MTD, VMware
Carbon Black Enterprise EDR, VMware Carbon Black Cloud, VMware vSphere, VMware vCenter,
VMware vSAN, IBM Security QRadar XDR, Mandiant MSV, Tenable.io, Tenable.ad, Tenable NNM,
and DigiCert ONE.

717
718
719
720
721
722
723
724
725

Enterprise 3 Build 4 (E3B4) (SDP, F5 as PE) uses products from F5, Forescout, Mandiant,
Microsoft, Palo Alto Networks, and Tenable. Certificates from DigiCert are also used.

Enterprise 2 Build 5 (E2B5) (SDP and SASE, Lookout SSE and Okta Identity Cloud as PEs) uses
products from Google Cloud, IBM, Lookout, Mandiant, Okta, Radiant Logic, SailPoint, Tenable,
and VMware. Certificates from DigiCert are also used.
E2B5 components consist of Lookout Security Service Edge (SSE) (includes Secure Private Access[SPA], Secure Cloud Access [SCA], and Secure Internet Access [SIA]), Lookout Secure Private
Access Connector, VMware Workspace ONE UEM, Lookout MES, Lookout Client, Okta Identity
Cloud, Okta Verify App, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint
IdentityIQ, IBM Security QRadar XDR, Tenable.io, Tenable.ad, Tenable Nessus Network Monitor(NNM), Mandiant Security Validation (MSV), Google Cloud, Google Workspace, and DigiCert
CertCentral.

▪

Enterprise 3 Build 5 (E3B5) (SDP and SASE, Microsoft Entra Conditional Access (formerly called
Azure AD Conditional Access) and Microsoft Security Service Edge as PEs) uses products from
Mandiant, Microsoft, and Tenable. Certificates from DigiCert are also used.
E3B5 components consist of Microsoft Entra Conditional Access, Microsoft Security Service Edge
(SSE) (which includes Entra Private Access, Entra Internet Access, and Microsoft 365 Access),
Microsoft Entra Private Access Connector, Microsoft Entra ID, Microsoft Entra ID Governance,
Microsoft Intune, Microsoft Defender for Endpoint, Microsoft Global Secure Access Client,
Microsoft Purview DLP, Microsoft Purview Information Protection, Microsoft Purview
Information Protection Scanner, Microsoft Entra ID Identity Protection, Microsoft Defender for
Identity, Microsoft Defender for Cloud, Microsoft Sentinel, Tenable.io, Tenable.ad, MandiantSecurity Validation, Microsoft Azure (IaaS), Microsoft 365 (SaaS), and DigiCert CertCentral.

NIST SP 1800-35: Implementing a Zero Trust Architecture

15

FOURTH PRELIMINARY DRAFT
744
745
746

▪

747
748
749
750
751

Enterprise 1 Build 6 (E1B6) (SDP and Microsegmentation, Ivanti Neurons for Zero Trust Accessas PE) uses products from Amazon Web Services, IBM, Ivanti, Mandiant, Okta, Radiant Logic,
SailPoint, and Tenable. Certificates from DigiCert are also used.
E1B6 components consist of Ivanti Neurons for Zero Trust Access (nZTA), Ivanti nZTA Gateway,
Okta Identity Cloud, Radiant Logic RadiantOne Intelligent Identity Data Platform, SailPoint
IdentityIQ, Okta Verify App, Ivanti Secure Access Client, IBM Security QRadar XDR, Tenable.io,
Tenable.ad, Tenable NNM, Mandiant Security Validation (MSV), DigiCert CertCentral, and AWS
IaaS.

752

4 Build Implementation Instructions

753
754
755
756

Table 4-1 identifies the policy engines and types of architecture used in each build. It also links to theonline locations where each build architecture is described in detail, as well as the online locations
where instructions for implementing each build can be found. These build implementation instructions
are designed to enable information technology professionals to replicate all or parts of this project.

757
758
759
760
761

To see which build suits your organization, you can first identify which of the ZTA approaches — EIG,
SDP, microsegmentation, or SASE — meets your organization’s requirements. You can then look at thebuild options provided in Table 4-1. Based on your selection of the ZTA approach, you can view thedetails of the relevant builds by clicking the link in the “Build Architecture, Technologies, and Flow
Diagrams” column.

762
763
764

Since most enterprises evolve their enterprise architecture toward ZTA, i.e., by starting with theiralready-existing enterprise environment and gradually adding or adapting capabilities such as PE, you
can start by looking at the builds with the products closest to your existing environment.

765
766

Table 4-1 Mapping of Builds to Online Details Regarding Architecture Descriptions and Implementation
Instructions
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Build
Implementation
Instructions

E1B1

Okta Identity Cloud
Ivanti Access ZSO

EIG Crawl

E1B1 Build
Architecture

E1B1 Build
Implementation
Instructions

E2B1

Ping Identity Ping
Federate

EIG Crawl

E2B1 Build
Architecture

E2B1 Build
Implementation
Instructions

E3B1

Azure AD (Conditional
Access, later renamed
Entra Conditional
Access)EIG Crawl

E3B1 Build
Architecture

E3B1 Build
Implementation
Instructions

NIST SP 1800-35: Implementing a Zero Trust Architecture

16

FOURTH PRELIMINARY DRAFT
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Build
Implementation
Instructions

E1B2

Zscaler ZPA Central
Authority (CA)EIG RunE1B2 Build
Architecture

E1B2 Build
Implementation
Instructions

E3B2

Microsoft Azure AD(Conditional Access,later renamed Entra
Conditional Access)Microsoft Intune
Forescout eyeControl
Forescout eyeExtend

EIG RunE3B2 Build
Architecture

E3B2 Build
Implementation
Instructions

E4B3

IBM Security Verify

EIG RunE4B3 Build
Architecture

E4B3 Build
Implementation
Instructions

E1B3

Zscaler ZPA Central
Authority (CA)SDP

E1B3 Build
Architecture

E1B3 Build
Implementation
Instructions

E2B3

Ping Identity
PingFederate
Cisco ISE
Cisco Secure Workload

Microsegmentation

E2B3 Build
Architecture

E2B3 Build
Implementation
Instructions

E3B3

Microsoft Azure AD(Conditional Access,later renamed Entra
Conditional Access)Microsoft Intune
Microsoft Sentinel
Forescout eyeControl
Forescout eyeExtend

SDP andMicrosegmentation

E3B3 Build
Architecture

E3B3 Build
Implementation
Instructions

E1B4

Appgate SDP Controller

SDP

E1B4 Build
Architecture

E1B4 Build
Implementation
Instructions

E2B4

Symantec Cloud Secure
Web Gateway (Cloud
SWG)
Symantec ZTNA
Symantec Cloud Access
Security Broker (CASB)

SDP and SASE

E2B4 Build
Architecture

E2B4 Build
Implementation
Instructions

NIST SP 1800-35: Implementing a Zero Trust Architecture

17

FOURTH PRELIMINARY DRAFT
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Build
Implementation
Instructions

E3B4

F5 BIG-IP
F5 NGINX Plus
Forescout eyeControl
Forescout eyeExtend

SDP

E3B4 Build
Architecture

E3B4 Build
Implementation
Instructions

E4B4

VMware Workspace
ONE Access
VMware Unified Access
Gateway (UAG)
VMware NSX-T

SDP,
E4B4 Build
Microsegmentation, Architectureand EIG

E4B4 Build
Implementation
Instructions

E1B5

PAN NGFWPAN Prisma Access

SASE andMicrosegmentation

E1B5 Build
Architecture

E1B5 Build
Implementation
Instructions

E2B5

Lookout SSE
Okta Identity Clouds

SDP and SASE

E2B5 Build
Architecture

E2B5 Build
Implementation
Instructions

E3B5

Microsoft Entra
Conditional Access(formerly called Azure
AD Conditional Access)Microsoft Security
Service Edge

SDP and SASE

E3B5 Build
Architecture

E3B5 Build
Implementation
Instructions

E1B6

Ivanti Neurons for Zero
Trust Access

SDP andMicrosegmentation

E1B6 Build
Architecture

E1B6 Build
Implementation
Instructions

767

5 General Findings

768
769
770

When deploying ZTA, the following capabilities are considered to be fundamental to determining
whether a request to access a resource should be granted and, once granted, whether the accesssession should be permitted to persist:

771▪

Authentication and periodic reauthentication of the requesting user’s identity772▪

Authentication and periodic reauthentication of the requesting endpoint

773
774

▪

Authentication and periodic reauthentication of the endpoint that is hosting the resource being
accessed775
776

In addition, the following capabilities are also considered highly desirable:▪

Verification and periodic reverification of the requesting endpoint’s health

NIST SP 1800-35: Implementing a Zero Trust Architecture

18

FOURTH PRELIMINARY DRAFT
777
778

▪

Verification and periodic reverification of the health of the endpoint that is hosting the resource
being accessed779

5.1 EIG Crawl Phase Findings

780
781
782
783
784
785
786
787
788

In the EIG crawl phase, we followed two patterns. First, we leveraged our ICAM solutions to also act as
PDPs. We discovered that many of the vendor solutions used in the EIG crawl phase do not integratewith each other out-of-the-box in ways that are needed to enable the ICAM solutions to function as
PDPs. Typically, network-level PEPs, such as routers, switches, and firewalls, do not integrate directlywith ICAM solutions. However, network-level PEPs that are identity-aware may integrate with ICAM
solutions. Also, endpoint protection solutions in general do not typically integrate directly with ICAM
solutions. However, some of the endpoint protection solutions considered for use in the builds haveout-of-the-box integrations with the MDM/UEM solutions used, which provide the endpoint protection
solutions with an indirect integration with the ICAM solutions.

789
790

Second, we used out-of-the-box integrations offered by the solution providers rather than performing
custom integrations. These two patterns combined do not support all the desired zero trust capabilities.

791
792
793
794
795
796

Both builds E1B1 and E3B1 were capable of authenticating and reauthenticating requesting users andrequesting endpoints, and of verifying and periodically reverifying the health of requesting endpoints,
and both builds were able to base their access decisions on the results of these actions. Access requests
were not granted unless the identities of the requesting user and the requesting endpoint could be
authenticated and the health of the requesting endpoint could be validated; however, no check was
performed to authenticate the identity or verify the health of the endpoint hosting the resource.

797
798
799
800
801
802

Access sessions that are in progress in both builds are periodically reevaluated by reauthenticating theidentities of the requesting user and the requesting endpoint and by verifying the health of therequesting endpoint. If these periodic reauthentications and verifications cannot be performed
successfully, the access session will eventually be terminated; however, neither the identity nor thehealth of the endpoint hosting the resource is verified on an ongoing basis, nor does its identity or
health determine whether it is permitted to be accessed.

803
804
805
806
807
808
809
810
811
812
813

Neither build E1B1 nor build E3B1 was able to support resource management as envisioned in the ZTA
logical architecture depicted in Figure 3-1. These builds do not include any ZTA technologies that
perform authentication and reauthentication of resources that host endpoints, nor are these builds
capable of verifying or periodically reverifying the health of the endpoints that host resources. In
addition, when using both builds E1B1 and E3B1, devices (requesting endpoints and endpoints hosting
resources) were initially joined to the network manually. Neither of the two EIG crawl phase builds
includes any technologies that provide network-level enforcement of an endpoint’s ability to access the
network. That is, there is no tool in either build that can keep any endpoint (either one that is hosting a
resource or one that is used by a user) from initially joining the network based on its authentication
status. The goal is to try to support resource management in future builds as allowed by thetechnologies used.

NIST SP 1800-35: Implementing a Zero Trust Architecture

19

FOURTH PRELIMINARY DRAFT

814

5.2 EIG Run Phase Findings

815

The EIG run phase enabled us to demonstrate additional capabilities over the EIG crawl phase, such as:

816
817
818

▪

establishment of secure, direct access tunnels from requesting endpoints to private enterprise
resources, regardless of whether the resources are located on-premises or in the cloud, driven
by policy and enforced by PEPs

819
820
821

▪

use of connectors that act as proxies for internal, private enterprise resources, enabling
resources to be accessed by authenticated, authorized users while ensuring that they are notdiscoverable by or visible to others

822
823
824

▪

protection for private enterprise resources hosted in the cloud that enables authenticated,authorized remote users to access those resources directly rather than having to hairpin
through the enterprise network

825
826

▪

ability to monitor, inspect, and enforce policy controls on traffic being sent to and fromresources in the cloud or on the internet

827
828

▪

discovery of new endpoints on the network and the ability to block newly discovered endpoints
that are not compliant with policy

829
830
831
832
833
834
835
836

Build E1B2, which uses Zscaler as its PE, PA, and PEP, does not have an EPP because this build does notinclude any collaborators with EPP solutions that integrate with Zscaler. Zscaler (e.g., the Zscaler client
connector) has capabilities to enforce policies based on a defined set of endpoint compliance checks toallow or deny user/endpoint access to a resource. However, it does not perform the functions of an EPP
solution to protect an endpoint. Zscaler integrates with EPP solutions to receive a more robust set of
information about the endpoints in order to make a decision to allow or deny access to a resource.
However, in build E1B2, we do not have a collaborator with an EPP solution that can integrate with
Zscaler.

837
838

Because there is no EPP in E1B2, there is no automatic solution to remediate an issue on the endpoint
either.

839
840
841

Build E1B2 also does not have a collaborator with a solution that supports determination of confidence
level/trust scores that can integrate with Zscaler. Due to the absence of a collaborator with thiscapability, Build E1B2 does not support the calculation of confidence levels/trust scores.

842
843
844
845

Build E2B1, which uses Ping Identity as its PE and PA and Ping Identity and Cisco Duo as its PEP, does nothave an EPP. Cisco Duo provides limited device health information, but not the full spectrum that an EPP
would provide. Because there is no official EPP in this build, there is no automatic solution to remediate
an issue on the endpoint. An EPP for Enterprise 2 was included in a later build phase (E2B3).

846
847
848
849
850
851
852
853

Build E3B2 currently supports one-way integration between Microsoft Intune and Forescout eyeExtend.
If Intune detects an endpoint out of compliance, eyeExtend can become informed of this problem bypulling information from Intune. However, if one of Forescout’s discovery tools detects a problem withan endpoint, there is currently no mechanism for this information to be passed from Forescout
eyeExtend to Microsoft Intune. Ideally, future integration of these products would allow Forescout
eyeExtend to inform Microsoft Intune when it detects a non-Azure AD-connected endpoint that is noncompliant, as this would enable Intune to direct Azure AD to block sign-in from the non-compliant
endpoint. Without a mechanism for enabling Forescout eyeExtend to send endpoint compliance

NIST SP 1800-35: Implementing a Zero Trust Architecture

20

FOURTH PRELIMINARY DRAFT
854
855

information to Microsoft Intune, Azure AD does not have a way of knowing that a non-Azure ADconnected endpoint is not compliant.

856

5.3 SDP, Microsegmentation, and SASE Phase Findings

857
858
859
860

More integration of zero trust products from different vendors is needed to support the implementationof ZTAs that are built using components from a variety of vendors. For the most effective zero trust
solutions, PDPs should integrate with a variety of security tools and other supporting components thatenable the PDP to assess the real-time risk of any given access request.

861
862
863
864
865

It is not unusual for a ZTA to have multiple PDPs, each of which may be integrated with one or moredifferent supporting component and/or PEPs. As a result, the policies that the ZTA enforces are notcentrally located. Rather, they are configured and managed in association with each of the various PDPs.
This makes it challenging to understand, articulate, and manage the ZTA’s policies as a comprehensive
whole.

866
867
868
869
870
871
872
873

In addition, the multiple PDPs that comprise a ZTA do not typically integrate with each other to share
information and so do not have a shared understanding of what users, endpoints, or other subjects may
pose risks. For example, one PDP may be aware that an endpoint is non-compliant, whereas this same
endpoint compliance information is not available to another PDP. On the other hand, the second PDP
may be aware that the endpoint’s user may have exhibited suspicious behavior, whereas the first PDP isnot. Ideally, when a ZTA has multiple PDPs, it is desirable to have an integrated approach that enables
the PDPs to share information so that they can each be more fully informed, share a common,
consolidated understanding of risks, and make a decision based on all information available.

874
875
876
877

The SIEM and/or SOAR components contain a wealth of information that could prove useful to a PDP as
it tries to determine whether any given access request should be allowed or not. Ideally, the SIEM and
SOAR should send this information to the PDP in real-time, if possible, to ensure that the PDP’s accessdecisions are fully informed.

878
879

Ideally, data security tools should be integrated with the PDP so that the PDP can be made aware of
instances in which access requests are denied by the tools that are designed to protect data.

880
881

Additionally, risk information and user behavior analytics should be shared with the PDP to potentially
improve ZTA security.

882
883
884
885
886

Some zero trust SDP solutions for managing endpoints can also manage resources by installing clients
onto those resources. However, solutions that are specifically designed to manage resources should beleveraged rather than the zero trust solutions that have the primary purpose of managing endpoints. In
some cases, the solutions that manage resources do not have out-of-the-box integration with the PDPs.
PDP integration capability should be available in these resource management solutions.

887
888
889
890
891

Endpoint compliance is essential for security. It is important to have tools that are capable of detecting
when an endpoint is not compliant and ensuring that the endpoint is not permitted to access resources
as a result. Furthermore, automatic solutions to remediate noncompliance issues on the endpointshould be deployed when possible, and these should be integrated with the organization’s configurationand patch management systems.

NIST SP 1800-35: Implementing a Zero Trust Architecture

21

FOURTH PRELIMINARY DRAFT

892

6 Functional Demonstrations

893
894
895

This section defines the methodologies we used to demonstrate the capabilities of the project’s ZTA
builds, summarizes the use cases that were demonstrated, and summarize the results of performing
these use cases with each of the project’s builds.

896

6.1 Demonstration Methodology

897
898
899
900
901
902
903

We are leveraging two types of demonstration methodologies in this project: manual and automated.
Demonstrations that require human interaction (e.g., user performs MFA) must be performed manually.
Demonstrations that do not require human interaction can be performed either manually or automated,or both. It is also possible to perform demonstrations in a hybrid manner in which the early part of ademonstration that requires user authentication is performed manually, followed by an automatedportion of the demonstration. This approach can be helpful for demonstrations that are complicated,
yet nevertheless require human interaction.

904
905
906
907
908
909
910
911
912
913
914
915

We deployed Mandiant Security Validation (MSV) throughout the project’s laboratory environment toenable us to monitor and verify various security characteristics of the builds. MSV automates a testing
program that provides visibility and evidence of how security controls are performing by emulating
attackers to safely process advanced cyberattack security content within production environments. It is
designed so defenses respond to it as if an attack is taking place within the enterprise. Virtual machines(VMs) that are intended to operate as actors are deployed on each of the subnetworks in each of theenterprises. These actors can be used to initiate various actions for the purpose of verifying that security
controls are working to support the objectives of zero trust. We also deployed three VMs that operate
as directors, two of which function as applications within enterprise 1 and enterprise 3 that are used bythose enterprises to monitor and audit their own traffic, and one of which is an overarching director
that is located within the management and orchestration domain and used by the project team todemonstrate and audit operations that span multiple enterprises.

916

This setup enabled the following dual-purpose MSV deployment:

917
918
919
920
921
922
923
924
925
926
927

1. A typical MSV deployment, in which each enterprise deploys MSV as an application within its
own enterprise and uses it for self-auditing and testing. Each enterprise deploys a director andmultiple actors that function as applications within the enterprise, enabling the enterprise tomonitor and test its own enterprise security capabilities, verifying the protections it receives
from the ZTA and its ability to operate as expected. In this capacity, MSV is treated just like anyother application deployed within that enterprise. The components may be protected by PEPs
according to enterprise policies, and directors and actors exchange traffic over the same data
communications paths as other enterprise applications. Firewalls and policies within the ZTA
must be configured to permit the communications that the MSV components send and receive,
including traffic that is sent between actors and the director to control the actions that are
performed to test various security controls.

928
929
930
931

2. The NCCoE project team, as testers, use MSV to monitor and audit enterprise and interenterprise actions. The project team deploys an overarching director and a management
backchannel connecting that director to all actors throughout the laboratory environment. Thisoverarching director is used as a tool to verify the security controls provided by each of the ZTAs

NIST SP 1800-35: Implementing a Zero Trust Architecture

22

FOURTH PRELIMINARY DRAFT
932
933
934
935
936
937
938
939
940
941
942
943
944
945

in the various enterprises and to monitor and audit inter-enterprise interactions. In thiscapacity, MSV is not functioning as an application deployed or controlled by the enterprises, butrather as a tool being used to monitor and audit enterprise and inter-enterprise activity.
Communications between the actors and this overarching director occur on a management
channel that is separate from the data networks in each of the enterprises. Using a separate
backchannel ensures that the tool being used to monitor and verify the various ZTA
architectures is not itself impacting those architectures. Enabling the overarching MSV director
to control the actor VMs via a backchannel requires each of the actor VMs to have two network
interface cards (NICs), one for enterprise data and one for MSV tool interoperation. Use of aseparate backchannel ensures that enterprise ZTA policies and firewalls don’t need to bemodified to accommodate the overarching MSV testing by permitting traffic between theoverarching director and the actors that would not normally be expected to transit any of theenterprise networks. Such policy and firewall modification would have been undesirable andwould, in effect, have amounted to unauthorized channels into the enterprise networks.

946
947
948
949
950

An MSV protective theater was also created in the lab. This is a virtualized system that allows
destructive actions to be tested without adversely impacting the enterprise deployments themselves.
For example, to understand the effects that malware might have on a specific system in one of theenterprises, that system could be imported into the protective theater and infected with malware to
test what the destructive effects of the malware might be.

951

6.2 Demonstration Use Cases

952
953
954

Eight demonstration use cases were defined to exercise the security functionality provided by each of
the example solutions that were implemented as part of this project. Each use case consists of one ormore scenarios. The use cases and their scenarios are summarized in the following subsections.

955
956
957
958

More detailed descriptions of each use case and scenario, including their preconditions; demonstration
steps; purposes; detailed tables of the various permutations of subject, ID, endpoint, and resource
attributes to be exercised; and expected outcomes are available in our supplemental documentation on
Functional Demonstrations.

959
960
961
962

Definitions of terminology used throughout the demonstration scenarios are available in our
Demonstration Terminology documentation. The terminology includes identifier, subject, endpoint, andresource types; compliance, authentication status, access levels, user and access profiles, assumptions,and other information that is required to fully describe the demonstration use cases.

963

6.2.1 Use Case A: Discovery and Identification

964
965

Use Case A demonstrates discovery and Identification of identifiers, endpoint assets, and data flows. Its
scenarios are:966▪

Scenario A-1: Discovery and authentication of endpoint assets

967▪

Scenario A-2: Reauthentication of identified assets

968▪

Scenario A-3: Discovery of transaction flows

NIST SP 1800-35: Implementing a Zero Trust Architecture

23

FOURTH PRELIMINARY DRAFT

969

6.2.2 Use Case B: Enterprise-ID Access

970
971

Use Case B demonstrates a subject with an ID that is issued and maintained by the enterprise requesting
access to a resource. Its scenarios are:

972
973
974

▪

Scenario B-1: Full/limited resource access using an enterprise endpoint – the subject is granted
full, limited, or no access to the requested resource as determined by its authentication status
and endpoint compliance status

975
976

▪

Scenario B-2: Full/limited internet access using an enterprise endpoint – the subject is granted
full, limited, or no access to the requested internet domain as determined by enterprise policy

977
978
979

▪

Scenario B-3: Stolen credential using an enterprise endpoint – a legitimate user’s enterprise ID
credential is stolen and is used to request access to an enterprise resource from an enterprisemanaged endpoint

980
981
982

▪

Scenario B-4: Full/limited resource access using BYOD – a subject using a bring-your-own device(BYOD) is granted full or limited access to the requested resource as determined byauthentication status and enterprise policy

983
984
985

▪

Scenario B-5: Full/limited internet access based on ID attributes – the subject is granted full,
limited, or no access to the requested internet domain as determined by enterprise ID profiles
and enterprise policy

986
987

▪

Scenario B-6: Stolen credential using BYOD – a legitimate user’s enterprise ID credential is stolen
and is used to request access to an enterprise resource from a BYOD endpoint

988
989
990

▪

Scenario B-7: Just-in-Time Access Privileges – An enterprise provisions access privileges to a
resource based on a single business process flow. Temporary privileges are granted to perform a
portion of the business process and then revoked when the process is complete.

991
992
993

▪

Scenario B-8: Enterprise-ID Step-Up Authentication – A subject who already has an active accesssession with a resource requests to perform an action on that resource that requires additional
authentication checks.

994

6.2.3 Use Case C: Collaboration: Federated-ID Access

995
996
997

Use Case C demonstrates a subject with a successfully authenticated Federated-ID (i.e., an ID that isissued and maintained by another enterprise in a trusted community of interest) requesting access to a
resource. Its scenarios are:

998
999

▪

Scenario C-1: Full resource access using an enterprise endpoint – the subject is granted fullaccess to the requested resource as determined its endpoint compliance status

1000
1001

▪

Scenario C-2: Limited resource access using an enterprise endpoint – the subject is granted
limited access to the requested resource as determined its endpoint compliance status

1002
1003
1004

▪

Scenario C-3: Limited internet access using an enterprise endpoint – the subject is granted
limited access to internet domains as determined by its endpoint compliance status andenterprise policy

1005
1006

▪

Scenario C-4: No internet access using enterprise owned endpoint – the subject is denied allaccess to internet domains as determined by enterprise policy

NIST SP 1800-35: Implementing a Zero Trust Architecture

24

FOURTH PRELIMINARY DRAFT
1007
1008

▪

Scenario C-5: Internet access using BYOD – the subject is granted or denied access to an internet
domain as determined by enterprise policy

1009
1010
1011

▪

Scenario C-6: Access resources using BYOD – the subject is granted limited access to an
enterprise resource as determined by enterprise policy, which dictates that if a subject is using a
BYOD, the subject’s access to enterprise resources will be limited

1012
1013
1014

▪

Scenario C-7: Stolen credential using an enterprise endpoint – a legitimate user’s federated ID
credential is stolen and is used to request access to an enterprise resource from an enterprisemanaged endpoint

1015
1016

▪

Scenario C-8: Stolen credential using BYOD – a legitimate user’s federated ID credential is stolen
and is used to request access to an enterprise resource from a BYOD endpoint1017

6.2.4 Use Case D: Other-ID Access

1018
1019
1020

Use Case D demonstrates a subject with an Other-ID (i.e., an ID that is issued and maintained by anotherenterprise but known or registered the first enterprise) requesting access to a resource. Its scenarios
are:

1021
1022
1023

▪

Scenario D-1: Full/limited resource access using an enterprise endpoint – the subject is granted
full, limited, or no access to the requested resource as determined by its authentication status
and endpoint compliance status

1024
1025

▪

Scenario D-2: Full/limited internet access using an enterprise endpoint – the subject is granted
full, limited, or no access to the requested internet domain as determined by enterprise policy

1026
1027
1028

▪

Scenario D-3: Stolen credential using BYOD or enterprise endpoint – a legitimate user’s Other-ID
credential is stolen and is used to request access to an enterprise resource from either anenterprise-managed endpoint or a BYOD

1029
1030
1031

▪

Scenario D-4: Full/limited resource access using BYOD – a subject using a bring-your-own device(BYOD) is granted full or limited access to the requested resource as determined byauthentication status and enterprise policy

1032
1033

▪

Scenario D-5: Full/limited internet access using BYOD – the subject is granted or denied accessto an internet domain as determined by enterprise policy

1034
1035

▪

Scenario D-6: Stolen credential using BYOD – a legitimate user’s Other-ID credential is stolen andis used to request access to an enterprise resource from a BYOD endpoint

1036
1037
1038

▪

Scenario D-7: Just-in-Time Access Privileges – An enterprise provisions access privileges to a
resource based on a single business process flow. Temporary privileges are granted to perform a
portion of the business process and then revoked when the process is complete.

1039
1040
1041

▪

Scenario D-8: Other-ID Step-Up Authentication – A subject who already has an active accesssession with a resource requests to perform an action on that resource that requires additional
authentication checks.

1042

6.2.5 Use Case E: Guest: No-ID Access

1043
1044

Use Case E demonstrates a subject that does not have an ID (i.e., a guest on the network) requesting
access to a resource. Its scenario is:

NIST SP 1800-35: Implementing a Zero Trust Architecture

25

FOURTH PRELIMINARY DRAFT
1045
1046

▪

Scenario E-1: Guest requests public internet access – the guest user is permitted to access public
internet domains and resources1047

6.2.6 Use Case F: Confidence Level

1048
1049
1050

Use Case F demonstrates a subject that has been granted access to a resource and has an active session
to the resource. The events listed in the following use cases cause the subject’s authorization to accessthe resource to be re-evaluated:

1051
1052

▪

Scenario F-1: User reauthentication fails during active session, causing the subject’s access to
the resource to be terminated

1053
1054

▪

Scenario F-2: Requesting endpoint reauthentication fails during active session, causing the
subject’s access to the resource to be terminated

1055
1056

▪

Scenario F-3: Resource reauthentication fails during active session, causing the subject’s accessto the resource to be terminated

1057
1058

▪

Scenario F-4: Compliance fails during active session, causing the subject’s access to the resource
to be terminated

1059
1060
1061
1062

▪

Scenario F-5: Compliance improves between requests – in this case the subject had not been
permitted to access a resource due to non-compliance of the requesting endpoint. However,after the endpoint is brought into compliance and access to the resource is requested again,
access is granted.

1063
1064

▪

Scenario F-6: Enterprise-ID Violating Data Use Policy, causing the subject’s access to theresource to be terminated

1065
1066

▪

Scenario F-7: Other-ID Violating Data Use Policy, causing the subject’s access to the resource tobe terminated Scenario F-8: Enterprise-ID Violating Internet Use Policy

1067
1068

▪

Scenario F-9: Other-ID Violating Internet Use Policy, causing the subject’s access to the resource
to be terminated

1069
1070
1071
1072

▪

Scenario F-10: Enterprise-ID Attempting Unauthorized Access Detection and Response, Access
Queries – the enterprise detects a subject’s attempt to access an unauthorized resource andresponds by revoking access to a resource to which the subject had previously been granted
access

1073
1074
1075

▪

Scenario F-11: Enterprise-ID Attempting Unauthorized Access Detection and Response, Ongoing
Sessions - the enterprise detects a subject’s attempt to access an unauthorized resource andresponds by terminating the user’s active, open access session with a resource

1076
1077
1078
1079

▪

Scenario F-12: Other-ID Attempting Unauthorized Access Detection and Response, Access
Queries - the enterprise detects a subject’s attempt to access an unauthorized resource andresponds by revoking access to a resource to which the subject had previously been granted
access

1080
1081
1082

▪

Scenario F-13: Other-ID Attempting Unauthorized Access Detection and Response, Ongoing
Sessions - the enterprise detects a subject’s attempt to access an unauthorized resource andresponds by terminating the user’s active, open access session with a resource

1083
1084

▪

Scenario F-14: Enterprise-ID Denied Access Due to Suspicious Endpoint – A subject requests
access from an endpoint that had been previously flagged as being suspected of being

NIST SP 1800-35: Implementing a Zero Trust Architecture

26

FOURTH PRELIMINARY DRAFT
1085
1086

compromised. The enterprise responds by denying the request and preventing all accessrequests from the enterprise ID used in this request

1087
1088
1089
1090

▪

Scenario F-15: Other-ID Denied Access due to Suspicious Endpoint – A subject requests accessfrom an endpoint that had been previously flagged as being suspected of being compromised.
The enterprise responds by denying the request and preventing all access requests from the
Other-ID used in this request

1091
1092
1093
1094

▪

Scenario F-16: Enterprise-ID Access Terminated Due to Suspicious Endpoint – A subject requests
access from an endpoint that had been previously flagged as being suspected of being
compromised. The enterprise responds by denying the request and terminating any open accesssessions from the Enterprise-ID used in this request

1095
1096
1097
1098

▪

Scenario F-17: Other-ID Access Terminated Due to Suspicious Endpoint – A subject requests
access from an endpoint that had been previously flagged as being suspected of being
compromised. The enterprise responds by denying the request and terminating any open accesssessions from the Other-ID used in this request

1099

6.2.7 Use Case G: Service-Service Interaction

1100
1101
1102
1103
1104
1105

Use Case G demonstrates service-to-service Interactions in which a non-person subject requests accessto a resource via API calls. The enterprise can uniquely identify and authenticate both the subject andthe resource, and both the subject and the resource are in compliance. Whether or not the accessrequest is granted depends on whether the subject is authorized to access the resource, which depends
on enterprise policy. The access request is an API call between two services; the location of the services
varies by scenario, as can be seen in the scenarios listed here:

1106
1107

▪

Scenario G-1: Service Calls Between Resources – both the subject and the resource are locatedon enterprise-operated infrastructure (on premises or branch)

1108
1109

▪

Scenario G-2: Service Calls to Cloud-Based Resources – the subject is located on enterpriseoperated infrastructure while the resource is cloud-based

1110
1111

▪

Scenario G-3: Service Calls between Cloud-Based Resources – both the subject and the resource
are located in the cloud

1112
1113
1114

▪

Scenario G-4: Service Calls between Containers – the subject is either in another container in asingle container runtime (e.g., Docker), in the same Kubernetes pod, or in a different Kubernetes
pod from the requested resource

1115
1116

▪

Scenario G-5: Service to Endpoint – an enterprise service attempts to access an enterprisemanaged endpoint to perform some action (e.g., maintenance, reconfiguration, etc.)1117

6.2.8 Use Case H: Data Level Security Scenarios

1118
1119
1120
1121
1122

Use Case H demonstrates data level security scenarios in which a subject requests access to data withdifferent levels of classification. There are at least two different levels of data sensitivity and a subject
who is authorized to access to a resource will be authorized either to have full access the highest level ofdata, or to have limited access of the data (e.g., low/limited/partial access) based on user identity,
endpoint type, and other attributes as articulated in the following use cases:

NIST SP 1800-35: Implementing a Zero Trust Architecture27

FOURTH PRELIMINARY DRAFT
1123
1124
1125

▪

Scenario H-1: Full/Limited Access to Resource Data Based on Identity Attributes – the subject
will be granted full or limited access to different levels of data based on their user identity
attributes

1126
1127
1128

▪

Scenario H-2: Full/Limited Access to Resource Data Based on Requesting Endpoint – the subject
will be granted full or limited access to different levels of data based on whether the requesting
endpoint is enterprise-managed or BYOD

1129
1130
1131

▪

Scenario H-3: Internet Access restricted when Accessing High Level Data – while a subject has anactive access session to a resource storing data with high classification, the enterprise will
restrict that subject from accessing public internet resources

1132
1133
1134

▪

Scenario H-4: Accessing High Level Data Triggers MFA Challenge – if a subject already as anactive access session with a resource and is accessing low-classification data, a request to accesshigh-classification data at that resource will trigger a multi-factor authentication challenge

1135
1136

▪

Scenario H-5: Just-in-Time Access to High Level Data – the enterprise can grant a subject
temporary access privileges to high level data when needed

1137
1138
1139
1140

▪

Scenario H-6: Operations Denied When Accessing High Level Data – a subject that is authorized
to fully access (e.g., read and write) high classification data when using an enterprise-managed
endpoint and located on premises or at a branch office can have their access privileges limited
to read-only when using a BYOD or when located remote from enterprise infrastructure.

1141
1142
1143
1144

▪

Scenario H-7: High Classified Data Has Extra Protection When Stored on Endpoints – when asubject downloads or copies high classification data onto the subject’s endpoint, the data is
encrypted or has some further protection that requires the subject to pass a challenge before
accessing or performing actions on the local copy of the data

1145

6.3 Functional Demonstration Results

1146
1147

Because only enterprise 1 has a branch office, demonstration scenarios involving a branch office could
only be performed with builds that were deployed in enterprise 1.

1148

6.3.1 Demonstration Result Summaries

1149

6.3.1.1 EIG Crawl Phase

1150

Three builds were implemented and demonstrated as part of the EIG crawl phase:

1151

▪

E1B1 (EIG Crawl, Okta and Ivanti as PEs),

1152

▪

E2B1 (EIG Crawl, Ping Identity as PE), and

1153

▪

E3B1 (EIG Crawl, Microsoft as PE).

1154

The following scenarios were considered out of scope for the EIG Crawl Phase:

1155

▪

Cloud-based scenarios,

1156

▪

Stolen Credential,

1157

▪

Just-in-Time Access Privileges,

1158

▪

Enterprise-ID Step-Up Authentication,

NIST SP 1800-35: Implementing a Zero Trust Architecture28

FOURTH PRELIMINARY DRAFT
1159▪

Federated-ID Access,

1160

▪

Confidence Level, and

1161
1162

▪

Service-Service Interactions scenarios were determined to be out of scope for the EIG crawl
phase.

1163
1164

Summaries of the demonstration results for each of these builds can be found in our supplemental EIG
Crawl Phase Summary Demonstration Results documentation.

1165

6.3.1.2 EIG Run Phase

1166

Three builds were implemented as part of the EIG run phase:

1167

▪

E1B2 (EIG Run, Zscaler as PE),

1168

▪

E3B2 (EIG Run, Microsoft and Forescout as PEs), and

1169

▪

E4B3 (EIG Run, IBM as PE)

1170

The following scenarios were considered out of scope for the EIG Run Phase for builds E1B2 and E3B2:

1171

▪

Just-in-Time Access Privileges,

1172

▪

Enterprise-ID Step-Up Authentication,

1173

▪

Federated-ID Access,

1174

▪

Confidence Level, and

1175

▪

Service-Service

1176
1177

Summaries of the demonstration results for each of these builds can be found in our supplemental EIG
Run Phase Summary Demonstration Results documentation.

1178

6.3.1.3 SDP, Microsegmentation, and SASE Phase

1179

Eleven builds were implemented as part of the SDP, Microsegmentation, and SASE phase:

1180

▪

E1B3 (SDP, Zscaler as PE)

1181

▪

E2B3 (Microsegmentation, Cisco and Ping Identity as PEs)

1182

▪

E3B3 (SDP and Microsegmentation, Microsoft and Forescout as PEs)

1183

▪

E1B4 (SDP, Appgate as PE)

1184

▪

E2B4 (SDP and SASE, Broadcom as PE)

1185

▪

E3B4 (SDP, F5 as PE)

1186

▪

E4B4 (SDP, Microsegmentation, and EIG, VMware as PE)

1187

▪

E1B5 (Microsegmentation and SASE, Palo Alto Networks as PE)

1188

▪

E2B5 (SDP and SASE, Lookout SSE and Okta Identity Clouds as PEs)

1189
1190

▪

E3B5 (SDP and SASE, Microsoft Entra Conditional Access (formerly called Azure AD Conditional
Access) and Microsoft Security Service Edge as PEs)

1191

▪

E1B6 (SDP and Microsegmentation, Ivanti Neurons for Zero Trust Access as PE)

NIST SP 1800-35: Implementing a Zero Trust Architecture

29

FOURTH PRELIMINARY DRAFT
1192
1193
1194

All the use cases were in scope. Summaries of the demonstration results for each of these builds can befound in our supplemental SDP, Microsegmentation, and SASE Phase Summary Demonstration Results
documentation.

1195

6.3.2 Demonstration Results in Full

1196
1197
1198

Table 6-1 identifies the policy engines and types of architecture used in each build. It also links to theonline locations where each build architecture is described in detail, as well as the online locations
where the full demonstration results for each build can be found.

1199
1200

Table 6-1 Mapping of Builds to Online Details Regarding Architecture Descriptions and Functional
Demonstration Results
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Full
Demonstration
Results

E1B1

Okta Identity Cloud
Ivanti Access ZSO

EIG Crawl

E1B1 Build
Architecture

E1B1 Full
Demonstration
Results

E2B1

Ping Identity Ping
Federate

EIG Crawl

E2B1 Build
Architecture

E2B1 Full
Demonstration
Results

E3B1

Azure AD (Conditional
Access)EIG Crawl

E3B1 Build
Architecture

E3B1 Full
Demonstration
Results

E1B2

Zscaler ZPA Central
Authority (CA)EIG RunE1B2 Build
Architecture

E1B2 Full
Demonstration
Results

E3B2

Microsoft Azure AD(Conditional Access)Microsoft Intune
Forescout eyeControl
Forescout eyeExtend

EIG RunE3B2 Build
Architecture

E3B2 Full
Demonstration
Results

E4B3

IBM Security Verify

EIG RunE4B3 Build
Architecture

E4B3 Full
Demonstration
Results

E1B3

Zscaler ZPA Central
Authority (CA)SDP

E1B3 Build
Architecture

E1B3 Full
Demonstration
Results

E2B3

Ping Identity
PingFederate
Cisco ISE
Cisco Secure Workload

Microsegmentation

E2B3 Build
Architecture

E2B3 Full
Demonstration
Results

NIST SP 1800-35: Implementing a Zero Trust Architecture30

FOURTH PRELIMINARY DRAFT
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Full
Demonstration
Results

E3B3

Microsoft Azure AD(Conditional Access)Microsoft Intune
Microsoft Sentinel
Forescout eyeControl
Forescout eyeExtend

SDP andMicrosegmentation

E3B3 Build
Architecture

E3B3 Full
Demonstration
Results

E1B4

Appgate SDP Controller

SDP

E1B4 Build
Architecture

E1B4 Full
Demonstration
Results

E2B4

Symantec Cloud Secure
Web Gateway (Cloud
SWG)
Symantec ZTNA
Symantec Cloud Access
Security Broker (CASB)

SDP and SASE

E2B4 Build
Architecture

E2B4 Full
Demonstration
Results

E3B4

F5 BIG-IP
F5 NGINX Plus
Forescout eyeControl
Forescout eyeExtend

SDP

E3B4 Build
Architecture

E3B4 Full
Demonstration
Results

E4B4

VMware Workspace
ONE Access
VMware Unified Access
Gateway (UAG)
VMware NSX-T

SDP,
E4B4 Build
Microsegmentation, Architectureand EIG

E4B4 Full
Demonstration
Results

E1B5

PAN NGFWPAN Prisma Access

SASE andMicrosegmentation

E1B5 Build
Architecture

E1B5 Full
Demonstration
Results

E2B5

Lookout SSE
Okta Identity Clouds

SDP and SASE

E2B5 Build
Architecture

E2B5 Full
Demonstration
Results

E3B5

Microsoft Entra
Conditional Access(formerly called Azure
AD Conditional Access)Microsoft Security
Service Edge

SDP and SASE

E3B5 Build
Architecture

E3B5 Full
Demonstration
Results

NIST SP 1800-35: Implementing a Zero Trust Architecture31

FOURTH PRELIMINARY DRAFT
Build

Policy Engines

ZTA Architecture
Instantiated

Links to Online
Details: Build
Architecture,
Technologies, andFlow Diagrams

Links to Online
Details: Full
Demonstration
Results

E1B6

Ivanti Neurons for Zero
Trust Access

SDP andMicrosegmentation

E1B6 Build
Architecture

E1B6 Full
Demonstration
Results

1201

7 Risk and Compliance Management

1202
1203
1204
1205

This section discusses risks addressed by the ZTA reference architecture and provides links to mappingsof ZTA security characteristics to CSF Subcategories, NIST SP 800-53 security controls, and EO 14028
security measures. The mappings include both general ZTA logical component capabilities and specific
ZTA example implementation vendor technology capabilities.

1206

7.1 Risks Addressed by the ZTA Reference Architecture

1207
1208
1209
1210
1211
1212
1213
1214
1215

Conventional network security has focused on perimeter defense. Historically, most organization
resources have been located within and protected by the enterprise’s network perimeter, which tended
to be large and static. Subjects that are inside the network perimeter are often assumed to be implicitly
trusted and are given broad access to the resources within the network perimeter. Attempts to accessresources from outside the network perimeter, i.e., from the internet, are often subject to more scrutiny
than those originating from within. However, a subject can be compromised regardless of whether it isinside or outside of the network perimeter. Once a subject is compromised, malicious actors—throughimpersonation and escalation—can gain access to the resources that the subject is authorized to accessand move laterally within the network perimeter to access adjacent resources.

1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227

By protecting each resource individually and employing extensive identity, authentication, andauthorization measures to verify a subject’s requirement to access each resource, zero trust can ensurethat authorized users, applications, and systems have access to only those resources that they
absolutely have a need to access in order to perform their duties, not to a broad set of resources that all
happen to be within the network perimeter. This way, if a malicious actor does manage to gain
unauthorized access to one resource, this access will not provide them with any advantage when trying
to move laterally to other nearby resources. To compromise those other resources, the attacker would
be required to figure out how to circumvent the mechanisms that are protecting those resourcesindividually because it is not possible to reach those resources from nearby compromised resources. In
this way, ZTA limits the insider threat because instead of having permission to access all resources
within the network perimeter, malicious insiders would only be permitted to access those resources
they require to perform their official roles.

1228
1229
1230
1231
1232

In addition, once a subject is granted access to a resource, this access is often permitted to continue fora substantial period of time without being reevaluated based on a defined policy. The access session isoften not monitored or subject to behavioral analysis, and the configuration and health of the devices
being used to access resources may be subject to initial, but not ongoing, scrutiny. So, if a subject does
manage to gain unauthorized access to a resource, the subject often has ample time to exfiltrate or

NIST SP 1800-35: Implementing a Zero Trust Architecture32

FOURTH PRELIMINARY DRAFT
1233
1234
1235
1236
1237
1238
1239

modify valuable information or further compromise the resource and/or use it as a point from which topivot and attack other corporate resources. ZTA limits these threats by performing continual verificationof a subject’s identity and authorization to access a resource. It may also perform behavioral analysis
and validation of each system’s health and configuration, and consider other factors such as day, time,and location of subject and resource. Based on the organization’s defined policy, ZTA makes dynamic
ongoing assessments of the risk of each access request in real-time to ensure it poses an acceptablelevel of risk.

1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253

A number of trends, including cloud computing and remote work, have also introduced additional
security threats. The growth in cloud computing has meant that enterprises are now storing criticalresources (e.g., databases, applications, servers) in the cloud (i.e., outside of the traditional network
perimeter) as well as on-premises. As a result, these resources cannot be protected by the network
perimeter strategy. A new protection paradigm is needed that focuses on protecting resourcesindividually, no matter where they are located, so that they are not at risk of being subjected to security
policies that are not under organization control or not enforced consistently across all enterprise
resources. Often the clouds in which resources are hosted are multitenant, meaning that different
enterprises have authorized access to their own portions of the cloud infrastructure, with each tenantreliant on the cloud service provider to enforce this separation. If a malicious actor were to figure out
how to subvert cloud security and move from one tenant’s account to the next, the organization’s
resources would be at risk. Use of ZTA to protect each resource individually serves as further assurance
that the resources will not be accessible to cloud users from other enterprises, nor will they beaccessible to users from within the enterprise who do not have a need to access them.

1254
1255
1256
1257
1258
1259
1260
1261
1262

The growth of the remote workforce, as well as collaboration with partners and dependence on
contractors are other trends that are also challenging the conventional security paradigm. The subjects
requesting authorized access to resources may not necessarily be within the network perimeter. They
may be employees working from home or from a coffee shop’s public Wi-Fi via the internet, or apartner, contractor, customer, or guest that requires access to some resources but must be restrictedfrom accessing other resources. By relying on strong identity, authentication, and authorization services
to determine precisely which resources a subject is authorized to access with respect to their role in or
relationship to the organization, ZTA can restrict subjects to accessing only those resources that they
have a need to access and ensure that they are not permitted to access any other resources.

1263
1264
1265

While implementing ZTA addresses many risks, it also has limitations. It cannot remove all risk, and the
ZTA implementation itself may introduce additional risks that need to be addressed. For more
information on the limitations of ZTA, see Section 5 of SP 800-207.

1266

7.2 ZTA Security Mappings

1267
1268
1269
1270
1271
1272

A mapping indicates that one concept is related to another concept. This publication introduces
mappings for ZTA cybersecurity functions, both those performed by the ZTA reference design’s logicalcomponents (see Section 3.1) as well as those performed by specific technologies used in the project’s
builds. The project’s mappings use the supportive relationship mapping style defined in Section 4.2 of
NIST Internal Report (IR) 8477, Mapping Relationships Between Documentary Standards, Regulations,
Frameworks, and Guidelines: Developing Cybersecurity and Privacy Concept Mappings [5]. This style uses

NIST SP 1800-35: Implementing a Zero Trust Architecture

33

FOURTH PRELIMINARY DRAFT
1273
1274

three relationship types: Supports, Is Supported By, and Equivalent. Each relationship of type Supports
or Is Supported By also has a property assigned to it: Example of, Integral to, or Precedes.

1275

Three categories of ZTA Security Mappings are available in our supplemental documentation:

1276
1277
1278

▪

Subcategories from the NIST Cybersecurity Framework (CSF) 1.1 [7] and The NIST Cybersecurity
Framework 2.0 (CSF 2.0) [8]. Note that mapping for CSF 1.1 was done only for the builds thatwere implemented before CSF 2.0 was finalized. Mapping for CSF 2.0 is done for all builds.

1279
1280

▪

Security controls from NIST SP 800-53r5 (Security and Privacy Controls for Information Systems
and Organizations) [9]

1281
1282

▪

Security measures defined in Security Measures for “EO-Critical Software” Use Under Executive
Order (EO) 14028 [10] in support of Executive Order (EO) 14028 [2]

1283
1284
1285
1286
1287
1288

These mappings describe how the functions in our ZTA reference design are related to the NIST
reference documents within the context of our ZTA reference design. Within each category of mapping,
there is both a general mapping from the ZTA reference design logical components to the document
being mapped to (i.e., CSF, SP 800-53, or EO 14028), as well as a set of collaborator-specific mappingsfrom the ZTA technology component capabilities that are included in one or more project builds to the
document being mapped to (CSF, SP 800-53, or EO 14028).

1289

The mappings were developed to support two primary use cases:

1290
1291
1292
1293

1. Why should organizations implement ZTA? This use case identifies how implementing ZTA cansupport an organization with achieving CSF Subcategories, SP 800-53 controls, and EO 14028
security measures. This helps communicate to an organization’s senior management that
expending resources to implement ZTA can also aid in fulfilling other security requirements.

1294
1295
1296
1297
1298
1299
1300

2. How can organizations implement ZTA? This use case identifies how an organization’s existing
implementations of CSF Subcategories, SP 800-53 controls, and EO 14028 security measures canhelp support a ZTA implementation. An organization wanting to implement ZTA might firstassess its current security capabilities so that it can plan how to add missing capabilities andenhance existing capabilities in order to implement ZTA. Organizations can leverage their
existing security investments and prioritize future security technology deployment to address
the gaps.

1301
1302

These mappings are intended to be used by any organization that is interested in implementing ZTA orthat has begun or completed a ZTA implementation.

1303
1304
1305
1306
1307
1308
1309
1310

The NCCoE ZTA project team performed the initial mapping between the cybersecurity functions
performed by the ZTA reference design’s logical components and the security characteristics in the
cybersecurity documents, with input and feedback from the collaborators who have contributed
technology to demonstrate ZTA capabilities. The collaborators then performed the technology-specificmappings between the cybersecurity functions performed by their products used in the project’s ZTA
builds and the security characteristics in the cybersecurity documents. In some cases, collaborators have
not yet produced mappings for their products. These mappings are expected to be included in futureversions of this document as collaborators develop them.

NIST SP 1800-35: Implementing a Zero Trust Architecture

34

FOURTH PRELIMINARY DRAFT

1311

8 Zero Trust Journey Takeaways

1312
1313
1314

Based on our experience building example implementations in the lab, we recommend that anorganization that wants to deploy and implement zero trust embark on a journey that includes thefollowing steps:

1315

▪

Discover and Inventory the Existing Environment

1316

▪

Formulate Access Policy to Support the Mission and Business Use Cases

1317

▪

Identify Existing Security Capabilities and Technology

1318
1319

▪

Eliminate Gaps in Zero Trust Policy and Processes by Applying a Risk-Based Approach Based on
the Value of Data

1320
1321

▪

Implement ZTA Components (People, Process, and Technology) and Incrementally Leverage
Deployed Security Solutions

1322

▪

Verify the Implementation to Support Zero Trust Outcomes

1323
1324

▪

Continuously Improve and Evolve Due to Changes in Threat Landscape, Mission, Technology,
and Regulations

1325
1326
1327

As of this writing, 17 ZTA builds have been completed and are documented. We are currently developing
two additional builds, with a continued focus on the use of microsegmentation, SDP, and SASE. Lessons
learned from the additional builds may necessitate minor updates to the takeaways.

1328

8.1 Discover and Inventory the Existing Environment

1329
1330
1331
1332
1333
1334
1335
1336
1337

The first step any organization should take on its zero trust journey is to identify all of its assets bydetermining what resources it has in its existing environment (hardware, software, applications, data,and services). This may involve deploying tools that monitor traffic to discover what resources are active
and being accessed and used. It is necessary to have a complete understanding and inventory of theorganization’s resources because these are the entities that the zero trust architecture will be designed
to protect. If resources are overlooked, it’s likely that they won’t be appropriately protected by the ZTA.
They could be vulnerable to exfiltration, modification, deletion, denial-of-service, or other types ofattack. It is imperative that all of the organization’s resources, whether on-premises or cloud-based, be
identified and inventoried.

1338
1339
1340
1341
1342
1343
1344

Discovery tools that are used to identify organization resources may do so, for example, by monitoringtransaction flows and communication patterns. These tools may also be useful in helping theorganization identify the business and access rules that are currently being enforced, and in identifying
access patterns that business operations require. Understanding how resources are accessed, by whom,and in what context will help the organization formulate its access policies. In addition, once theorganization has begun deploying a ZTA, continuing to use the discovery tools to observe theenvironment can be helpful to the organization as it audits and validates the ZTA on an ongoing basis.

NIST SP 1800-35: Implementing a Zero Trust Architecture

35

FOURTH PRELIMINARY DRAFT

1346

8.2 Formulate Access Policy to Support the Mission and Business Use
Cases

1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359

Once the organization has identified all the resources that it needs to protect and where they are, it may
formulate the policies that the ZTA will enforce to specify who is allowed to access each resource andunder what conditions. The access policies should be designed to ensure that permissions andauthorizations to access each resource conform with the principles of least privilege and separation ofduties. Typically, access to each resource will be denied by default, and access policies should beformulated to authorize subjects with the least privileges required in order to perform their assigned
task on a resource that they are permitted to access. This requires understanding the types of users thatwill be accessing resources and their access requirements, work locations, employment arrangements,
device types, and ownership models (e.g., BYOD and corporate-owned) because these will all influence
policy creation. Access authorizations may be constrained according to the location of the individual
requesting access, time of day, or other parameters that can further limit access without interfering withorganizational operations. All access policies should be informed by the criticality of the resource being
protected.

1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374

Initially, an organization may not have a clear sense of what resources each employee needs to access.
They may not be aware of which employees are accessing which resources or whether or not suchaccess conforms to the principles of least privilege and separation of duties. Information provided by thetools that were used to discover resources can be useful in this regard. They can monitor access patterns
and produce a list of access flows and patterns that are observed. For the remote access example, anorganization transitioning from a full device VPN to per-app tunneling could first set up a full device
tunnel and observe traffic, then begin enabling only the traffic that is required for the user profile. The
organization’s security team can then examine this list to determine which access flows should bepermitted and then formulate access rules that permit them. Any observed access flows that should not
be permitted may be denied by default or explicitly prohibited in the access policy. By basing accesspolicy on observed access patterns, an organization reduces the chances that it will create overly
restrictive policies that interfere with its ability to conduct normal operations. By taking into
consideration the criticality of the data being protected when formulating the access policy, anorganization can help ensure that the protections being provided to a resource are commensurate with
its value.

1375
1376
1377
1378
1379
1380
1381
1382
1383
1384

One challenge that organizations may have when formulating policy is that their ZTA may consist ofnumerous components that each perform policy engine and policy administration roles. As a result,access policy may not be centralized; rules may be distributed across numerous products, i.e., with somerules configured in an endpoint protection component; some configured in identity, credential, andaccess management components; other rules configured in a network security component; and stillother rules configured in a data security component or other component. The lack of a single location
where all policy rules can be centralized may make it challenging for an organization to maintain an
organized, complete, consistent understanding of its access policy. To help manage their access policies,
organizations should explicitly keep track of not only what their access rules are, but also where each of
the rules is configured.

1345

NIST SP 1800-35: Implementing a Zero Trust Architecture36

FOURTH PRELIMINARY DRAFT

1385

8.3 Identify Existing Security Capabilities and Technology

1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397

If an organization is planning to install a ZTA into a greenfield environment, meaning that it will not haveany existing IT equipment or security capabilities that it will want to use or accommodate, this stepwould not be needed. Most organizations embarking on a zero trust journey, however, will not be
starting from scratch. Instead, they will have an existing infrastructure and technology systems that
already perform security functions. Organizations will typically have at least network firewalls andintrusion detection systems to help provide perimeter security, and identity and credential accessmanagement systems that enable them to authenticate users and enforce authorized access based on
identity and role. They may have endpoint security systems protecting their laptops and/or mobile
devices to provide firewall protections and ensure that they are running required antivirus or othersecurity software. They may have tools for vulnerability and configuration management, log
management, and other security-related functions. They also likely have some sort of security
operations center.

1398
1399
1400
1401
1402
1403
1404
1405
1406

An organization should identify and inventory its existing security technology components andcapabilities to understand what protections they already provide, then determine whether thesecomponents should continue to provide these protections as part of the deployed ZTA or should be
repurposed. To save money, an organization will want to continue to use or repurpose as much of its
existing technology as possible without sacrificing security. Continuing to use existing technology will
require the organization to understand what potential zero trust components and products its existing
security technology will integrate with. Any additional components that are purchased specifically for
deployment in the ZTA should, ideally, integrate with the security technology components that theorganization already has and plans to continue to use.

1407
1408

8.4 Eliminate Gaps in Zero Trust Policy and Processes by Applying a RiskBased Approach Based on the Value of Data

1409
1410
1411
1412
1413
1414
1415
1416

Once an organization has inventories of the resources it needs to protect and the security capabilities it
already has, the organization is ready to begin planning its access protection topology, in terms ofwhether and where its infrastructure will be segmented and at what level of granularity each resource
will be protected. The access topology should be designed using a risk-based approach, isolating criticalresources in their own trust zones protected by a PEP but permitting multiple lower-value resources toshare a trust zone. In designing its access protection topology, the organization will identify which PEP is
responsible for protecting each resource as well as what supporting technologies will be involved inproviding input to resource access decisions.

1417
1418
1419
1420
1421
1422
1423

Initially, the organization’s network may not be well-segmented. In fact, before zero trust is
implemented, when the organization is still relying on perimeter-based protections, such a topology canbe thought of as the organization protecting all of its resources behind a single PEP, i.e., the perimeter
firewall. As the organization implements ZTA, it should segment its infrastructure into smaller parts.
Such segmentation will enable it to limit the potential impact of a breach or attack and make it easier tomonitor network traffic. In designing its access protection topology, the organization should apply
access control enforcement at multiple levels: application, host, and network.

NIST SP 1800-35: Implementing a Zero Trust Architecture

37

FOURTH PRELIMINARY DRAFT

1425

8.5 Implement ZTA Components (People, Process, and Technology) andIncrementally Leverage Deployed Security Solutions

1426

Once an organization has the following, it is ready to begin incrementally implementing ZTA:

1424

1427
1428

▪

a good understanding of its current environment in terms of the resources it needs to protect
and the security capabilities that it already has deployed;

1429
1430

▪

formulated the access policies that are appropriate to support its mission and business use
cases; and

1431
1432

▪

designed its access protection topology to identify the granularity at which access to various
resources will be protected and the supporting technologies that will provide input to the PDP.

1433
1434
1435

Given the importance of discovery to the successful implementation of a ZTA, the organization may
begin by deploying tools to continuously monitor the environment, if it has not done so already. The
organization can use these observations to audit and validate the ZTA on an ongoing basis.

1436
1437
1438
1439
1440
1441

In addition to discovery tools, the organization should ensure that any other baseline security tools such
as SIEMs, vulnerability scanning and assessment tools, and security validation tools are operational andconfigured to log, scan, assess, and validate the ZTA components that will be deployed. Having security
baseline tools in place before the organization begins deploying new ZTA components helps ensure that
the ZTA rollout will be well-monitored, enabling the organization to proceed with high confidence that it
will understand the security ramifications of the incremental deployment as it proceeds.

1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456

Identity, authentication, and authorization are critical to making resource access decisions. Given thatmaking and enforcing access decisions are the two main responsibilities of a ZTA, the organization will
want to use its existing or a new ICAM solution as a foundational building block of its initial ZTA
implementation. The organization should strongly consider implementing MFA in a risk-based manner
for its users. An endpoint protection or similar solution that can assess device health and that integrates
with the ICAM solution may also be another foundational component of an initial ZTA deployment. An
initial ZTA based on these two main components will be able to use the identity and authorizations ofsubjects and the health and compliance of requesting endpoints as the basis for making accessdecisions. Additional supporting components and features can then be deployed to address anincreasing number of ZTA requirements. Which types of components are deployed and in what order
will depend on the organization’s mission and business use cases. If data security is essential, then data
security components will be prioritized; if behavior-based anomaly detection is essential, thenmonitoring and AI-based analytics may be installed. The ZTA can be built incrementally, adding andintegrating more supporting components, features, and capabilities to gradually evolve to a morecomprehensive ZTA.

1457

8.6 Verify the Implementation to Support Zero Trust Outcomes

1458
1459
1460
1461
1462

The organization should continue to monitor all network traffic in real time for suspicious activity, bothto look for known attack signatures and patterns and to apply behavioral analytics to try to detect
anomalies or other activity that may be attack indicators. The organization should use deployeddiscovery and other baseline security tools to audit and validate the access enforcement decision of the
ZTA it has provisioned, correlating known data with information reported by the tools. The organization

NIST SP 1800-35: Implementing a Zero Trust Architecture38

FOURTH PRELIMINARY DRAFT
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473

should perform ongoing verification that the policies that are being enforced, as revealed by theobserved network flows, are in fact the policies that the organization has defined. Periodic testingshould be performed across a variety of use case scenarios, including those in which the resource islocated on-premises and in the cloud, the requesting endpoint is located on-premises and on theinternet, the requesting subject is and is not authorized to access the requested resource, therequesting endpoint is and is not managed, and the requesting resource is and is not compliant. In
addition, service-to-service requests, both authorized and unauthorized, should also be tested. The use
cases selected for testing should reflect those which most closely mirror how the organization’s users
access the organization’s resources on a day-to-day basis. Ideally, the organization can create a suite of
tests that it can use to validate the ZTA not only before deploying each new ZTA capability in theincremental rollout process, but also on a periodic basis once the ZTA rollout is considered complete.

1474
1475

8.7 Continuously Improve and Evolve Due to Changes in Threat
Landscape, Mission, Technology, and Regulations

1476
1477
1478
1479
1480
1481
1482

Once rolled out, the ZTA must continue to adapt to changing conditions. If technology components usedin the ZTA are upgraded or obsoleted by their manufacturer, they should be replaced. If innovative newtechnologies become available, the organization should consider whether they could be integrated into
the existing ZTA to take advantage of new defensive tactics, techniques, and procedures that might
improve the organization’s security posture. If the organization’s security goals change, either as a resultof a shifting mission or changes in regulations, the ZTA’s policies and the ZTA itself may need to evolve
to best address these new goals.

1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493

In addition, the ZTA may need to adapt to a changing threat landscape. As new types of adversary
attacks become known and prevalent, the ZTA will need to add the threat signatures for these attacks to
the list of things it monitors for. Ideally the ZTA will also perform behavior-based monitoring thatenables it to detect anomalies that may signal zero-day attacks for which threat signatures are not yet
known. Behavior-based monitoring tools provide the ZTA with some degree of agility and readiness withrespect to its ability to detect attacks by adversaries who are constantly changing their tactics andtechniques. In any case, as the threat landscape changes, the organization’s CISO and security teamneed to continually assess the ZTA’s topology, components, and policies to ensure that they are best
designed to address newly emerging threats. If the value of one or more of an organization’s resources
increases substantially, the organization may want to change how that resource is protected by the ZTA,
as well as what its access policies are.

1494
1495
1496
1497
1498
1499
1500

As input to this ongoing process of validation and improvement, organizations should continuously
monitor their network and other infrastructure and update policies, technologies, and network
segmentation topologies to ensure that they remain effective. Creating a ZTA is not a one-time project
but an ongoing process. The organization’s CISO or other security team members should performongoing validation of their ZTA access policies to ensure that they continue to be defined in a mannerthat supports the organization’s mission and business use cases while conforming with the principles ofleast privilege and separation of duties.

NIST SP 1800-35: Implementing a Zero Trust Architecture

39

FOURTH PRELIMINARY DRAFT

1501

Appendix A

List of Acronyms

1502

AD

Active Directory

1503

API

Application Programming Interface

1504

BYOD

Bring Your Own Device

1505

CASB

Cloud Access Security Broker

1506

CRADA

Cooperative Research and Development Agreement

1507

DNS

Domain Name System

1508

E1B1

Enterprise 1 Build 1

1509

E1B2

Enterprise 1 Build 2

1510

E1B3

Enterprise 1 Build 3

1511

E1B4

Enterprise 1 Build 4

1512

E1B5

Enterprise 1 Build 5

1513

E1B6

Enterprise 1 Build 6

1514

E2B1

Enterprise 2 Build 1

1515

E2B3

Enterprise 2 Build 3

1516

E2B4

Enterprise 2 Build 4

1517

E2B5

Enterprise 2 Build 5

1518

E3B1

Enterprise 3 Build 1

1519

E3B2

Enterprise 3 Build 2

1520

E3B3

Enterprise 3 Build 3

1521

E3B4

Enterprise 3 Build 4

1522

E3B5

Enterprise 3 Build 5

1523

E4B3

Enterprise 4 Build 3

1524

E4B4

Enterprise 4 Build 4

1525

EIG

Enhanced Identity Governance

1526

EP

Enterprise Endpoint

1527

EPP

Endpoint Protection Platform

1528

IaaS

Infrastructure as a Service

1529

ICAM

Identity, Credential, and Access Management

1530

IP

Internet Protocol

NIST SP 1800-35: Implementing a Zero Trust Architecture

40

FOURTH PRELIMINARY DRAFT
1531

ISE

(Cisco) Identity Services Engine

1532

IT

Information Technology

1533

ITL

Information Technology Laboratory

1534

MDM

Mobile Device Management

1535

MFA

Multifactor Authentication

1536

MSV

Mandiant Security Validation

1537

NCCoE

National Cybersecurity Center of Excellence

1538

NGFW

Next-Generation Firewall

1539

NIC

Network Interface Card

1540

NIST

National Institute of Standards and Technology

1541

OS

Operating System

1542

PEP

Policy Enforcement Point

1543

PIV

Personal Identity Verification

1544

PKI

Public Key Infrastructure

1545

RDP

Remote Desktop Protocol

1546

RSS

Enterprise Resource

1547

SaaS

Software as a Service

1548

SDP

Software-Defined Perimeter

1549

SIEM

Security Information and Event Management

1550

SNA

(Cisco) Secure Network Analytics

1551

SP

Special Publication

1552

SWG

Secure Web Gateway

1553

UEM

Unified Endpoint Management

NIST SP 1800-35: Implementing a Zero Trust Architecture

41

FOURTH PRELIMINARY DRAFT

1554

Appendix B

References

1555
1556
1557

[1]

S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, National Institute ofStandards and Technology (NIST) Special Publication (SP) 800-207, Gaithersburg, Md., August
2020, 50 pp. Available: https://csrc.nist.gov/publications/detail/sp/800-207/final.

1558
1559
1560

[2]

Executive Order no. 14028, Improving the Nation’s Cybersecurity, Federal Register Vol. 86,
No.93, May 17, 2021. Available: https://www.federalregister.gov/documents/2021/05/17/202110460/improving-the-nations-cybersecurity.

1561
1562

[3]

National Cybersecurity Center of Excellence, Internet of Things (IoT). Available:
https://www.nccoe.nist.gov/iot

1563
1564

[4]

National Cybersecurity Center of Excellence, Manufacturing. Available:
https://www.nccoe.nist.gov/manufacturing

1565
1566
1567
1568

[5]

“National Cybersecurity Center of Excellence (NCCoE) Zero Trust Cybersecurity: Implementing a
Zero Trust Architecture,” Federal Register Vol. 85, No. 204, October 21, 2020, pp. 66936-66939.
Available: https://www.federalregister.gov/documents/2020/10/21/2020-23292/nationalcybersecurity-center-of-excellence-nccoe-zero-trust-cybersecurity-implementing-a-zero-trust.

1569
1570
1571
1572

[6]

K. Scarfone, M. Souppaya, and M. Fagan, Mapping Relationships Between DocumentaryStandards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity and Privacy
Content Mappings, National Institute of Standards and Technology (NIST) Internal Report (IR)8477, Gaithersburg, Md., February 2024, 30 pp. Available: https://doi.org/10.6028/NIST.IR.8477

1573
1574

[7]

NIST. Framework for Improving Critical Infrastructure Cybersecurity, Version 1.1, April 2018.
Available: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf

1575
1576

[8]

NIST. The NIST Cybersecurity Framework 2.0, February 2024. Available:
https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

1577
1578
1579
1580

[9]

Joint Task Force, Security and Privacy Controls for Information Systems and Organizations,
National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Revision 5,
Gaithersburg, Md., September 2020, 465 pp. Available:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

1581
1582
1583

[10]

Security Measures for “EO-Critical Software” Use Under Executive Order (EO) 14028, National
Institute of Standards and Technology (NIST). Available: https://www.nist.gov/itl/executiveorder-improving-nations-cybersecurity/security-measures-eo-critical-software-use-2

1584

NIST SP 1800-35: Implementing a Zero Trust Architecture

42

FOURTH PRELIMINARY DRAFT

1585

Appendix C

Change Log

1586

In July 2024, the following changes were made for the practice guide’s fourth preliminary draft:

1587
1588

▪

Introduced a new manner of content delivery in two formats, one we refer to as the “High-Level
Document in PDF Format” and the other as the “Full Document in Web Format.”

1589

▪

Added builds E2B4, E3B4, E4B4, E1B5, E2B5, E3B5, and E1B6

1590
1591
1592
1593
1594
1595

In July 2023, the following changes were made for the practice guide’s third preliminary draft:▪

Added builds E1B3, E2B3, E3B3, E4B3, and E1B4In December 2022, the following changes were made for the practice guide’s second preliminary draft:▪

Added builds E2B1, E1B2, and E3B2

In July 2022, the first preliminary draft was created with:▪

Created original document including builds E1B1, and E3B1NIST SP 1800-35: Implementing a Zero Trust Architecture43