NIST SPECIAL PUBLICATION 1800-35D

Implementing a Zero Trust Architecture

Volume D:
Functional Demonstrations
Oliver Borchert Aaron Rodriguez Hashim Khan Wade Ellery
Alper Kerman Micah Wilson Tim LeMaster Don Coltrain
Scott Rose Cisco Lookout Radiant Logic
Murugiah Souppaya Herndon, VA Reston, VA Novato, CA
National Institute of
Standards and Technology Corey Bonnell James Elliott Frank Briguglio
Gaithersburg, MD Dean Coclin David Pricer Ryan Tighe
DigiCert Mandiant SailPoint
Jason Ajmo Lehi, UT Reston, VA Austin, TX
Yemi Fashina
Parisa Grayeli
Joseph Hunt Ryan Johnson Joey Cruz Chris Jensen
Jason Hurlburt Dung Lam Carmichael Patton Joshua Moll
F5 Microsoft Tenable
Nedu Irrechukwu Seattle, WA Redmond, WA Columbia, MD
Joshua Klosterman
Oksana Slivina
Susan Symington Neal Lucier Vinu Panicker Jason White
Tom May Okta Trellix, Public Sector
Allen Tan
Forescout San Francisco, CA Reston, VA
The MITRE Corporation
McLean, VA San Jose, CA
Andrew Keffalas Jacob Rapp
Peter Gallagher Tim Knudsen Norman Wong Paul Mancuso
Aaron Palermo Google Cloud Palo Alto Networks VMware
Appgate Mill Valley, CA Santa Clara, CA Palo Alto, CA
Coral Gables, FL
Harmeet Singh Rob Woodworth Joe Brown
Adam Cerini
Krishna Yellepeddy Shawn Higgins Jim Kovach
Conrad Fernandes
IBM PC Matic Zimperium
AWS (Amazon Web Services)
Armonk, NY Myrtle Beach, SC Dallas, TX
Arlington, VA

Kyle Black Corey Lund Bryan Rosensteel Bob Smith

Sunjeet Randhawa Farhan Saifudin Mitchell Lewars Syed Ali
Broadcom Software Ivanti Ping Identity Zscaler
San Jose, CA South Jordan, UT Denver, CO San Jose, CA

December 2022

SECOND PRELIMINARY DRAFT

This publication is available free of charge from

https://www.nccoe.nist.gov/projects/implementing-zero-trust-architecture
 SECOND PRELIMINARY DRAFT

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

8 While NIST and the NCCoE address goals of improving management of cybersecurity and privacy risk
9 through outreach and application of standards and best practices, it is the stakeholder’s responsibility to
10 fully perform a risk assessment to include the current threat, vulnerabilities, likelihood of a compromise,
11 and the impact should the threat be realized before adopting cybersecurity measures such as this
12 recommendation.

13 National Institute of Standards and Technology Special Publication 1800-35D, Natl. Inst. Stand. Technol.
14 Spec. Publ. 1800-35D, 123 pages, December 2022, CODEN: NSPUE2

15 FEEDBACK
16 You can improve this guide by contributing feedback. As you review and adopt this solution for your
17 own organization, we ask you and your colleagues to share your experience and advice with us.

18 Comments on this publication may be submitted to: [email protected].

19 Public comment period: December 21, 2022 through February 6, 2023

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

21 National Cybersecurity Center of Excellence

22 National Institute of Standards and Technology
23 100 Bureau Drive
24 Mailstop 2002
25 Gaithersburg, MD 20899
26 Email: [email protected]

NIST SP 1800-35D: Implementing a Zero Trust Architecture ii

 SECOND PRELIMINARY DRAFT

27 NATIONAL CYBERSECURITY CENTER OF EXCELLENCE

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

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

43 NIST CYBERSECURITY PRACTICE GUIDES

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

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

53 ABSTRACT
54 A zero trust architecture (ZTA) focuses on protecting data and resources. It enables secure authorized
55 access to enterprise resources that are distributed across on-premises and multiple cloud environments,
56 while enabling a hybrid workforce and partners to access resources from anywhere, at any time, from
57 any device in support of the organization’s mission. Each access request is evaluated by verifying the
58 context available at access time, including criteria such as the requester’s identity and role, the
59 requesting device’s health and credentials, the sensitivity of the resource, user location, and user
60 behavior consistency. If the enterprise’s defined access policy is met, a secure session is created to
61 protect all information transferred to and from the resource. A real-time and continuous policy-driven,

NIST SP 1800-35D: Implementing a Zero Trust Architecture iii

 SECOND PRELIMINARY DRAFT

62 risk-based assessment is performed to establish and maintain the access. In this project, the NCCoE and
63 its collaborators use commercially available technology to build interoperable, open, standards-based
64 ZTA implementations that align to the concepts and principles in NIST Special Publication (SP) 800-207,
65 Zero Trust Architecture. This NIST Cybersecurity Practice Guide explains how commercially available
66 technology can be integrated and used to build various ZTAs.

67 KEYWORDS
68 enhanced identity governance (EIG); identity, credential, and access management (ICAM); zero trust;
69 zero trust architecture (ZTA).

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

Name Organization

Quint Van Deman Amazon Web Services

Jason Garbis Appgate

Adam Rose Appgate

Jonathan Roy Appgate

Eric Michael Broadcom Software

Ken Andrews Cisco

Matthew Hyatt Cisco

Leo Lebel Cisco

Tom Oast Cisco

Peter Romness Cisco

Steve Vetter Cisco

Daniel Cayer F5

NIST SP 1800-35D: Implementing a Zero Trust Architecture iv

SECOND PRELIMINARY DRAFT

Name Organization

David Clark F5

Jay Kelley F5

Tim Jones Forescout

Yejin Jang Forescout

Andrew Campagna IBM

Adam Frank IBM

Nalini Kannan IBM

Priti Patil IBM

Nikhil Shah IBM

Mike Spisak IBM

Vahid Esfahani IT Coalition

Ebadullah Siddiqui IT Coalition

Musumani Woods IT Coalition

Tyler Croak Lookout

Madhu Dodda Lookout

Jeff Gilhool Lookout

Ken Durbin Mandiant

Earl Matthews Mandiant

NIST SP 1800-35D: Implementing a Zero Trust Architecture v

SECOND PRELIMINARY DRAFT

Name Organization

Tarek Dawoud Microsoft

Janet Jones Microsoft

Hemma Prafullchandra Microsoft

Brandon Stephenson Microsoft

Clay Taylor Microsoft

Sarah Young Microsoft

Spike Dog MITRE

Sallie Edwards MITRE

Ayayidjin Gabiam MITRE

Jolene Loveless MITRE

Karri Meldorf MITRE

Kenneth Sandlin MITRE

Lauren Swan MITRE

Jessica Walton MITRE

Mike Bartock NIST

Gema Howell NIST

Douglas Montgomery NIST

Kevin Stine NIST

NIST SP 1800-35D: Implementing a Zero Trust Architecture vi

SECOND PRELIMINARY DRAFT

Name Organization

Sean Frazier Okta

Kelsey Nelson Okta

Shankar Chandrasekhar Palo Alto Networks

Sean Morgan Palo Alto Networks

Seetal Patel Palo Alto Networks

Zack Austin PC Matic

Andy Tuch PC Matic

Ivan Anderson Ping Identity

Bill Baz Radiant Logic

John Petrutiu Radiant Logic

Rusty Deaton Radiant Logic

Deborah McGinn Radiant Logic

Lauren Selby Radiant Logic

Peter Amaral SailPoint

Jim Russell SailPoint

Esteban Soto SailPoint

Karen Scarfone Scarfone Cybersecurity

Jeremiah Stallcup Tenable

NIST SP 1800-35D: Implementing a Zero Trust Architecture vii

 SECOND PRELIMINARY DRAFT

Name Organization

Bill Stritzinger Tenable

Andrew Babakian VMware

Peter Bjork VMware

Genc Domi VMware

Keith Luck VMware

Dennis Moreau VMware*

Jeffrey Adorno Zscaler

Jeremy James Zscaler

Lisa Lorenzin Zscaler*

Matt Moulton Zscaler

Patrick Perry Zscaler

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

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

Technology Collaborators
Appgate IBM Ping Identity
AWS Ivanti Radiant Logic
Broadcom Software Lookout SailPoint
Cisco Mandiant Tenable
DigiCert Microsoft Trellix
F5 Okta VMware
Forescout Palo Alto Networks Zimperium
Google Cloud PC Matic Zscaler

NIST SP 1800-35D: Implementing a Zero Trust Architecture viii

 SECOND PRELIMINARY DRAFT

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

85 CALL FOR PATENT CLAIMS

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

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

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

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

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

101 2. without compensation and under reasonable terms and conditions that are demonstrably free
102 of any unfair discrimination.

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

NIST SP 1800-35D: Implementing a Zero Trust Architecture ix

 SECOND PRELIMINARY DRAFT

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

110 Such statements should be addressed to: [email protected]

NIST SP 1800-35D: Implementing a Zero Trust Architecture x

 SECOND PRELIMINARY DRAFT

111 Contents
112 1 Introduction ........................................................................................1
113 1.1 How to Use this Guide ................................................................................................... 1
114 2 Functional Demonstration Playbook ....................................................3
115 2.1 Definitions ..................................................................................................................... 3
116 2.1.1 Network IDs .................................................................................................................. 3
117 2.1.2 Subject and Requested Resource Types ....................................................................... 4
118 2.1.3 Resource and Querying Endpoint Compliance Classification ....................................... 4
119 2.1.4 Desired Outcomes ........................................................................................................ 4
120 2.1.5 Authentication Status ................................................................................................... 5
121 2.2 General Configurations ................................................................................................. 6
122 2.2.1 Access Level .................................................................................................................. 6
123 2.2.2 Access Profiles .............................................................................................................. 6
124 2.2.3 Resources and Capabilities ........................................................................................... 7
125 2.2.4 User Profiles.................................................................................................................. 8
126 2.3 Demonstration Methodology ........................................................................................ 8
127 2.4 Use Case A: Discovery and Identification of IDs, Assets, and Data Flows................... 10
128 2.4.1 Scenario A-1: Discovery and authentication of endpoint assets ............................... 10
129 2.4.2 Scenario A-2: Reauthentication of identified assets .................................................. 12
130 2.4.3 Scenario A-3: Discovery of transaction flows ............................................................. 14
131 2.5 Use Case B: Enterprise ID Access ................................................................................ 15
132 2.5.1 Scenario B-1: Full/limited resource access using an enterprise endpoint ................. 15
133 2.5.2 Scenario B-2: Full/limited internet access using an enterprise endpoint .................. 19
134 2.5.3 Scenario B-3: Stolen credential using an enterprise endpoint ................................... 22
135 2.5.4 Scenario B-4: Full/limited resource access using BYOD ............................................. 27
136 2.5.5 Scenario B-5: Full/limited internet access using BYOD .............................................. 31
137 2.5.6 Scenario B-6: Stolen credential using BYOD ............................................................... 33
138 2.6 Use Case C: Collaboration: Federated-ID Access ........................................................ 38
139 2.6.1 Scenario C-1: Full resource access using an enterprise endpoint .............................. 38

NIST SP 1800-35D: Implementing a Zero Trust Architecture xi

 SECOND PRELIMINARY DRAFT

140 2.6.2 Scenario C-2: Limited resource access using an enterprise endpoint ........................ 39
141 2.6.3 Scenario C-3: Limited internet access using an enterprise endpoint ......................... 41
142 2.6.4 Scenario C-4: No internet access using an enterprise endpoint ................................ 41
143 2.6.5 Scenario C-5: Internet access using BYOD .................................................................. 42
144 2.6.6 Scenario C-6: Access resources using BYOD ............................................................... 43
145 2.6.7 Scenario C-7: Stolen credential using an enterprise endpoint ................................... 45
146 2.6.8 Scenario C-8: Stolen credential using BYOD ............................................................... 46
147 2.7 Use Case D: Other-ID Access ....................................................................................... 47
148 2.7.1 Scenario D-1: Full/limited resource access using an enterprise endpoint ................. 47
149 2.7.2 Scenario D-2: Full/limited internet access using an enterprise endpoint .................. 51
150 2.7.3 Scenario D-3: Stolen credential using BYOD or enterprise endpoint ......................... 54
151 2.7.4 Scenario D-4: Full/limited resource access using BYOD ............................................. 59
152 2.7.5 Scenario D-5: Full/limited internet access using BYOD .............................................. 63
153 2.7.6 Scenario D-6: Stolen credential using BYOD .............................................................. 66
154 2.8 Use Case E: Guest: No-ID Access ................................................................................. 71
155 2.8.1 Scenario E-1: Guest requests public internet access.................................................. 71
156 2.9 Use Case F: Confidence Level ...................................................................................... 71
157 2.9.1 Scenario F-1: User reauthentication fails during active session ................................ 71
158 2.9.2 Scenario F-2: Requesting endpoint reauthentication fails during active session ...... 72
159 2.9.3 Scenario F-3: Resource reauthentication fails during active session ......................... 73
160 2.9.4 Scenario F-4: Compliance fails during active session ................................................. 74
161 2.9.5 Scenario F-5: Compliance improves between requests ............................................. 76

162 3 Functional Demonstration Results ..................................................... 77

163 3.1 EIG Crawl Phase Demonstration Results ..................................................................... 77
164 3.1.1 Enterprise 1 Build 1 (E1B1) Demonstration Results ................................................... 77
165 3.1.2 Enterprise 2 Build 1 (E2B1) Demonstration Results ................................................... 81
166 3.1.3 Enterprise 3 Build 1 (E3B1) Demonstration Results ................................................... 86
167 3.1.4 Enterprise 4 Build 1 (E4B1) Demonstration Results ................................................... 89
168 3.2 EIG Run Phase Demonstration Results ........................................................................ 89
169 3.2.1 Enterprise 1 Build 2 (E1B2) Demonstration Results ................................................... 89

NIST SP 1800-35D: Implementing a Zero Trust Architecture xii

 SECOND PRELIMINARY DRAFT

170 3.2.2 Enterprise 2 Build 2 (E2B2) Demonstration Results ................................................... 96

171 3.2.3 Enterprise 3 Build 2 (E3B2) Demonstration Results ................................................... 97

172 Appendix A List of Acronyms ............................................................... 107

173 Appendix B References ........................................................................ 109
174 List of Tables
175 Table 2-1 Authentication Status Codes ...............................................................................................5
176 Table 2-2 Access Levels ......................................................................................................................6
177 Table 2-3 Access Profiles ....................................................................................................................7
178 Table 2-4 Resources and Capabilities ..................................................................................................7
179 Table 2-5 User Profiles .......................................................................................................................8
180 Table 2-6 Scenario A-1 Demonstrations ............................................................................................ 11
181 Table 2-7 Scenario A-2 Demonstrations ............................................................................................ 13
182 Table 2-8 Scenario A-3 Demonstrations ............................................................................................ 15
183 Table 2-9 Scenario B-1 Demonstrations ............................................................................................ 16
184 Table 2-10 Scenario B-2 Demonstrations........................................................................................... 20
185 Table 2-11 Scenario B-3 Demonstrations........................................................................................... 22
186 Table 2-12 Scenario B-4 Demonstrations........................................................................................... 27
187 Table 2-13 Scenario B-5 Demonstrations........................................................................................... 31
188 Table 2-14 Scenario B-6 Demonstrations........................................................................................... 34
189 Table 2-15 Scenario C-1 Demonstrations ........................................................................................... 39
190 Table 2-16 Scenario C-2 Demonstrations ........................................................................................... 40
191 Table 2-17 Scenario C-3 Demonstrations ........................................................................................... 41
192 Table 2-18 Scenario C-4 Demonstrations ........................................................................................... 42
193 Table 2-19 Scenario C-5 Demonstrations ........................................................................................... 43
194 Table 2-20 Scenario C-6 Demonstrations ........................................................................................... 44
195 Table 2-21 Scenario C-7 Demonstrations ........................................................................................... 45
196 Table 2-22 Scenario C-8 Demonstrations ........................................................................................... 46

NIST SP 1800-35D: Implementing a Zero Trust Architecture xiii

 SECOND PRELIMINARY DRAFT

197 Table 2-23 Scenario D-1 Demonstrations .......................................................................................... 48

198 Table 2-24 Scenario D-2 Demonstrations .......................................................................................... 52
199 Table 2-25 Scenario D-3 Demonstrations .......................................................................................... 54
200 Table 2-26 Scenario D-4 Demonstrations .......................................................................................... 59
201 Table 2-27 Scenario D-5 Demonstrations .......................................................................................... 64
202 Table 2-28 Scenario D-6 Demonstrations .......................................................................................... 66
203 Table 2-29 Scenario E-1 Demonstrations ........................................................................................... 71
204 Table 2-30 Scenario F-1 Demonstrations ........................................................................................... 72
205 Table 2-31 Scenario F-2 Demonstrations ........................................................................................... 73
206 Table 2-32 Scenario F-3 Demonstrations ........................................................................................... 74
207 Table 2-33 Scenario F-4 Demonstrations ........................................................................................... 75
208 Table 2-34 Scenario F-5 Demonstrations ........................................................................................... 76
209 Table 3-1 Demonstration Results for E1B1 EIG Crawl Phase ............................................................... 77
210 Table 3-2 Demonstration Results for E2B1 EIG Crawl Phase ............................................................... 82
211 Table 3-3 Demonstration Results for E3B1 EIG Crawl Phase ............................................................... 86
212 Table 3-4 Demonstration Results for E1B2 EIG Crawl Phase ............................................................... 89
213 Table 3-5 Demonstration Results for E3B2 EIG Run Phase ..................................................................97

NIST SP 1800-35D: Implementing a Zero Trust Architecture xiv

 SECOND PRELIMINARY DRAFT

214 1 Introduction
215 To demonstrate the security characteristics supported by each zero trust architecture (ZTA) build that is
216 implemented as part of the NCCoE ZTA project, a variety of use cases have been defined, each of which
217 consists of numerous demonstrations that each have a specific expected outcome. The use cases are
218 designed to showcase ZTA security capabilities under a variety of conditions.

219 Section 2 of this document describes the use cases that have been defined. It also defines various types
220 of user IDs and endpoints, resources, user and access profiles, assumptions, and other information that
221 is required to fully describe the use cases. The purpose of this section of the document is to guide
222 operators as they perform each demonstration.

223 Section 3 of this document describes the results of performing these demonstrations using each of the
224 builds that have been implemented.

225 1.1 How to Use this Guide

226 This NIST Cybersecurity Practice Guide will help users develop a plan for migrating to ZTA. It
227 demonstrates a standards-based reference design for implementing a ZTA and provides users with the
228 information they need to replicate two different implementations of this reference design. Each of these
229 implementations, which are known as builds, are standards-based and align to the concepts and
230 principles in NIST Special Publication (SP) 800-207, Zero Trust Architecture. The reference design
231 described in this practice guide is modular and can be deployed in whole or in part, enabling
232 organizations to incorporate ZTA into their legacy environments gradually, in a process of continuous
233 improvement that brings them closer and closer to achieving the ZTA goals that they have prioritized
234 based on risk, cost, and resources.

235 NIST is adopting an agile process to publish this content. Each volume is being made available as soon as
236 possible rather than delaying release until all volumes are completed. Work continues on implementing
237 the example solutions and developing other parts of the content. As a second preliminary draft, we will
238 publish at least one additional draft for public comment before it is finalized.

239 When complete, this guide will contain five volumes:

240 ▪ NIST SP 1800-35A: Executive Summary – why we wrote this guide, the challenge we address,
241 why it could be important to your organization, and our approach to solving this challenge
242 ▪ NIST SP 1800-35B: Approach, Architecture, and Security Characteristics – what we built and why
243 ▪ NIST SP 1800-35C: How-To Guides – instructions for building the example implementations,
244 including all the security-relevant details that would allow you to replicate all or parts of this
245 project

NIST SP 1800-35D: Implementing a Zero Trust Architecture 1

 SECOND PRELIMINARY DRAFT

246 ▪ NIST SP 1800-35D: Functional Demonstrations – use cases that have been defined to showcase
247 ZTA security capabilities and the results of demonstrating them with each of the example
248 implementations (you are here)
249 ▪ NIST SP 1800-35E: Risk and Compliance Management– risk analysis and mapping of ZTA security
250 characteristics to cybersecurity standards and recommended practices
251 Depending on your role in your organization, you might use this guide in different ways:

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

254 ▪ challenges that enterprises face in migrating to the use of ZTA

255 ▪ example solution built at the NCCoE
256 ▪ benefits of adopting the example solution
257 Technology or security program managers who are concerned with how to identify, understand, assess,
258 and mitigate risk will be interested in this part of the guide, NIST SP 1800-35B, which describes what we
259 did and why.

260 Also, Section 3 of Risk and Compliance Management, NIST SP 1800-35E, will be of particular interest.
261 Section 3, ZTA Reference Architecture Security Mappings, maps logical components of the general ZTA
262 reference design to security characteristics listed in various cybersecurity guidelines and recommended
263 practices documents, including Framework for Improving Critical Infrastructure Cybersecurity (NIST
264 Cybersecurity Framework), Security and Privacy Controls for Information Systems and Organizations
265 (NIST SP 800-53), and Security Measures for “EO-Critical Software” Use Under Executive Order (EO)
266 14028.

267 You might share the Executive Summary, NIST SP 1800-35A, with your leadership team members to help
268 them understand the importance of migrating toward standards-based ZTA implementations that align
269 to the concepts and principles in NIST SP 800-207, Zero Trust Architecture [1].

270 IT professionals and operators who want to implement similar solutions will find the whole practice
271 guide useful. You can use the how-to portion of the guide, NIST SP 1800-35C, to replicate all or parts of
272 the builds created in our lab. The how-to portion of the guide provides specific product installation,
273 configuration, and integration instructions for implementing the example solution. We do not re-create
274 the product manufacturers’ documentation, which is generally widely available. Rather, we show how
275 we incorporated the products together in our environment to create an example solution. Also, you can
276 use NIST SP 1800-35D, which provides the use cases that have been defined to showcase ZTA security
277 capabilities and the results of demonstrating them with each of the example implementations.

278 This guide assumes that IT professionals have experience implementing security products within the
279 enterprise. While we have used a suite of commercial products to address this challenge, this guide does
280 not endorse these particular products. Your organization can adopt this solution or one that adheres to

NIST SP 1800-35D: Implementing a Zero Trust Architecture 2

 SECOND PRELIMINARY DRAFT

281 these guidelines in whole, or you can use this guide as a starting point for tailoring and implementing
282 parts of a ZTA. Your organization’s security experts should identify the products that will best integrate
283 with your existing tools and IT system infrastructure. We hope that you will seek products that are
284 congruent with applicable standards and recommended practices.

285 A NIST Cybersecurity Practice Guide does not describe “the” solution, but example solutions. This is a
286 second preliminary draft guide. As the project progresses, the second preliminary draft will be updated,
287 and additional volumes will also be released for comment. We seek feedback on the publication’s
288 contents and welcome your input. Comments, suggestions, and success stories will improve subsequent
289 versions of this guide. Please contribute your thoughts to [email protected].

290 2 Functional Demonstration Playbook

291 This section is intended to guide the operator through the set of ZTA scenarios and use cases that have
292 been defined for demonstration in this project. To reduce the number of iterations, some potential
293 demonstrations have been omitted because they are not sufficiently different from another
294 demonstration that has been included. For example, if the requester’s access to a resource is blocked
295 due to a non-compliant on-premises resource, then it is sufficient to demonstrate this once with an on-
296 premises-to-on-premises request; this demonstration does not need to be repeated making the request
297 from a branch office or remote access location because the location of the requester in this
298 demonstration is irrelevant. The demonstration playbook is not exhaustive, and it does not capture all
299 possible demonstration cases.

300 This playbook is still under development. Additional scenarios and use cases will be included in the next
301 version as the implementations evolve and add capabilities. For this current draft of the document and
302 as discussed in Volume B of this guide, the scenarios are limited to on-premises resources or public
303 internet resources with only enhanced identity governance (EIG) considered. Subject endpoints are
304 located on-premises or at branch or remote locations. Only EIG approach solutions are currently present
305 in the builds. Microsegmentation and software-defined perimeter (SDP) solutions are currently out of
306 scope.

307 2.1 Definitions

308 2.1.1 Network IDs
309 As defined in NIST SP 800-63, an identity is an attribute or set of attributes that uniquely identifies a
310 subject [2]. A network identity is used here simply as an identity that allows the subject to identify itself
311 to all connected enterprise resources. The following definitions are used for network IDs:

312 ▪ Enterprise-ID: A network ID issued and maintained by the enterprise. It is stored in one (or
313 more) identity stores maintained by the enterprise.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 3

 SECOND PRELIMINARY DRAFT

314 ▪ Federated-ID: A network ID issued and maintained by another enterprise in a community of

315 interest, and partner enterprises have a trusted means to authenticate the ID. This could include
316 things such as a common PKI, etc.
317 ▪ Other-ID: A network ID issued and maintained by another enterprise but known or registered by
318 the first enterprise. Examples include contractors, customers, etc. The other enterprise has
319 limited means to authenticate to the first enterprise.
320 ▪ No-ID: An anonymous network ID unknown to the enterprise that the enterprise would be
321 unable to authenticate. This is also referred to as a “guest” to the enterprise.

322 2.1.2 Subject and Requested Resource Types

323 In zero trust, all enterprise data, assets, etc. are considered resources. To clarify the actors (subject and
324 requested resource) in the following scenarios, the following more detailed definitions are used:

325 ▪ Enterprise endpoint (EP): Owned and fully managed by the enterprise. The enterprise can
326 inspect and modify any data on the endpoint. An EP is usually acting as the requesting subject
327 but can be the target of a management utility.
328 ▪ Enterprise resource (RSS): Fully managed by the enterprise. The enterprise can inspect and
329 modify the resource. An RSS is usually acting as the target of a request.
330 ▪ Bring Your Own Device (BYOD): Not owned by the enterprise and not fully managed. The
331 enterprise can inspect the device but cannot directly manage or wipe the device. User agents,
332 certificates, etc. may be pre-installed by a private owner, but the endpoint cannot be managed.
333 A BYOD is usually acting as the requesting subject or as the target of a management utility.
334 ▪ Guest device: Not owned or managed by the enterprise and is opaque to the enterprise. The
335 enterprise can only see what is emitted and received by its enterprise managed infrastructure.
336 Examples include browser user agents and DNS queries. A guest device is usually acting as the
337 requesting subject or as the target of a management utility.

338 2.1.3 Resource and Querying Endpoint Compliance Classification

339 The following definitions are used for endpoint and resource security compliance policies:

340 ▪ (EIG) Endpoint Compliance: Policy that requires the endpoint device to be uniquely identified
341 and to conform to the enterprise security policy for the device.
342 ▪ (EIG) Resource Compliance: Policy that requires the enterprise-managed resource to be
343 identified and to conform to the enterprise security policy for the resource.

344 2.1.4 Desired Outcomes

345 The following definitions are used for desired outcomes:

NIST SP 1800-35D: Implementing a Zero Trust Architecture 4

 SECOND PRELIMINARY DRAFT

346 ▪ Access to Network: Endpoint is allocated an address on enterprise infrastructure and

347 enrolled/updated into any monitoring system in place. This result is only applicable to select on-
348 premises (or branch) demonstrations.
349 ▪ Access to Public Network: Endpoint is allocated an address, but only allowed access to the
350 (public) internet; cannot reach/access non-public enterprise resources. This result is only
351 applicable to select on-premises (or branch) demonstrations.
352 ▪ Limited Access to Network: Endpoint is allocated an address with strict traffic restrictions. This
353 may include a quarantine state with only access to update/patch management system. This
354 result is only applicable to select on-premises (or branch) demonstrations.
355 ▪ No Access to Network: Endpoint is not allocated an address and cannot send or receive
356 communication. This result is only applicable to select on-premises (or branch) demonstrations.
357 ▪ Access (to Resource) Successful: Access to the resources that are specified in the profile is
358 achieved.
359 ▪ Access (to Resource) Limited: Access to a subset, but not all, of the resources that are specified
360 in the profile is achieved.
361 ▪ Access (to Resource) Not Successful: No access to the requested resource is achieved.
362 ▪ Keep Access (to Resource): Access remains at the previous state.
363 ▪ Max. Limited Access to Network: This outcome is specific for device-based assets that will be
364 authenticated. This means that portions of the network or some RSS will not be available to be
365 accessed by this subject.
366 ▪ Terminate Access (to X): The session is terminated or all access to the network is terminated
367 (i.e., no longer allowed to send/receive communications).
368 ▪ Other Outcome: Some demonstrations use explicit text that informs of a desired action.
369 Examples: “Terminate all sessions” or “Log API call.”

370 2.1.5 Authentication Status

371 Table 2-1 explains the authentication status codes used in the demonstration use case tables below.

372 Table 2-1 Authentication Status Codes

Activity Description Examples

A+ Authentication successful All provided credentials matched
A- Authentication not successful Password failure, MFA failure, account does not
exist, account blocked, suspicions raised
RA+ Successful re-authentication of a All provided credentials matched
previously successful authentication

NIST SP 1800-35D: Implementing a Zero Trust Architecture 5

 SECOND PRELIMINARY DRAFT

Activity Description Examples

RA- Failed re-authentication of a Password failure, MFA failure, account does not
previously successful authentication exist, account blocked, suspicious activity
A Actively authenticated Previously authenticated but no need for re-
authentication yet
--- Not authenticated yet

373 2.2 General Configurations

374 This section focuses on the configurations and specifications used within the demonstration use cases.

375 2.2.1 Access Level

376 Table 2-2 defines the access levels used in the demonstration scenarios. An access level specifies a set of
377 available actions or access allowed to a subject. Downgrading an access level means the access level will
378 be replaced by the new downgraded access level. For example, if a subject with access level “Full
379 Access” gets downgraded to access level “Limited Access,” this means the subject only has access to
380 resources and/or functions that require at least “Limited Access.” Similarly, if a subject with access level
381 “Limited Access” gets downgraded, the subject will have no further access to anything. Downgraded
382 access levels can be reversed to their original state.

383 Table 2-2 Access Levels

Access Level Can Downgrade to Description

Full Access Limited Access This allows the subject to use all functions available on the
selected resource.
Limited Access None This allows the subject to use a subset of functions available
on the selected resource.
None None No access

384 2.2.2 Access Profiles

385 Table 2-3 defines the access levels used in the demonstration scenarios. Access profiles provide the
386 configuration and maximum access level that can be used. Access levels within the profile can be
387 downgraded to the next lower level when the demonstration directs the operator to limit the access.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 6

 SECOND PRELIMINARY DRAFT

388 Table 2-3 Access Profiles

Access Profile Maximum Access Description

Level
P_FULL Full Access This provides the capability to access all capabilities of each
available resource.
P_LIMITED Limited Access This provides the capability to select a limited set of capabilities
by the available resources.
P_NONE none No access

389 2.2.3 Resources and Capabilities

390 Table 2-4 defines the resources and capabilities used in the demonstration scenarios. Resources (RSS)
391 and capabilities (CAP) specify items and actions used within the demonstrations. Access to them
392 requires a minimum access level. For convenience, the Access Profile column lists the access profiles
393 that will provide access to the given resource or capability. The Example column provides suggestions
394 regarding resources and capabilities that the access level could be representing.

395 Table 2-4 Resources and Capabilities

Component Type Minimum Access Profile Example

Access Level
RSS1 Resource Full Access P_FULL GitLab only accessible by P_FULL
RSS2 Resource Limited Access P_FULL, P_LIMITED File server

CAP1-RSS1 Capability Full Access P_FULL Create and access repositories

CAP2-RSS1 Capability Full Access P_FULL Access repositories

CAP1-RSS2 Capability Full Access P_FULL Read and write access

CAP2-RSS2 Capability Limited Access P_FULL, P_LIMITED Read-only access to all or
limited part of resource

URL1 Resource Full Access P_FULL https://www.nccoe.nist.gov

URL2 Resource Limited Access P_FULL, P_LIMITED https://www.nist.gov

NIST SP 1800-35D: Implementing a Zero Trust Architecture 7

 SECOND PRELIMINARY DRAFT

396 2.2.4 User Profiles

397 Table 2-5 contains the different user profiles (UP) used with an enterprise-ID (UP-E) or other-ID (UP-O)
398 for the demonstrations. Some profiles might be redundant (e.g., UP-E1 and UP-E4). This is done to help
399 keep the profile configuration simple because the demonstrations that the redundant profiles are used
400 in utilize different resources.

401 Table 2-5 User Profiles

User Profile Access Profile Resource Status Downgrade Trigger Examples

UP-E1 P_FULL RSS1 Active Endpoint falls out of compliance
UP-O1 RSS2
UP-E2 P_LIMITED RSS2 Active Endpoint falls out of compliance
UP-O2
UP-E3 none none Deactivated
UP-O3 or deleted

UP-E4 P_FULL URL1 Active Endpoint falls out of compliance

UP-O4 URL2
UP-E5 P_LIMITED URL1 Active Endpoint falls out of compliance
UP-O5 URL2 Internet access only during specific times

UP-E6 P_FULL RSS1 Active Detection of multiple logins from different

UP-O6 locations
Detection of second login from enterprise-
owned device not assigned to user
Detection of login from location outside of
the country
UP-E7 P_FULL RSS1 Active Account reported compromised
UP-O7 Using old MFA method (stolen PIV card)

402 2.3 Demonstration Methodology

403 We are leveraging two types of demonstration methodologies: manual and automated. Demonstrations
404 that require human interaction (e.g., user performs multifactor authentication) must be performed
405 manually. Demonstrations that do not require human interaction can be performed either manually or
406 automated, or both. It is also possible to perform demonstrations in a hybrid manner in which the early
407 part of a demonstration that requires user authentication is performed manually, followed by an

NIST SP 1800-35D: Implementing a Zero Trust Architecture 8

 SECOND PRELIMINARY DRAFT

408 automated portion of the demonstration. This approach can be helpful for demonstrations that are
409 complicated, yet nevertheless require human interaction.

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

422 This setup enabled the following dual-purpose MSV deployment:

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

434 2. The NCCoE project team, as testers, use MSV to monitor and audit enterprise and inter-
435 enterprise actions. The project team deploys an overarching director and a management
436 backchannel connecting that director to all actors throughout the laboratory environment. This
437 overarching director is used as a tool to verify the security controls provided by each of the ZTAs
438 in the various enterprises and to monitor and audit inter-enterprise interactions. In this
439 capacity, MSV is not functioning as an application deployed or controlled by the enterprises, but
440 rather as a tool being used to monitor and audit enterprise and inter-enterprise activity.
441 Communications between the actors and this overarching director occur on a management
442 channel that is separate from the data networks in each of the enterprises. Using a separate
443 backchannel ensures that the tool being used to monitor and verify the various ZTA
444 architectures is not itself impacting those architectures. Enabling the overarching MSV director

NIST SP 1800-35D: Implementing a Zero Trust Architecture 9

 SECOND PRELIMINARY DRAFT

445 to control the actor VMs via a backchannel requires each of the actor VMs to have two network
446 interface cards (NICs), one for enterprise data and one for MSV tool interoperation. Use of a
447 separate backchannel ensures that enterprise ZTA policies and firewalls don’t need to be
448 modified to accommodate the overarching MSV testing by permitting traffic between the
449 overarching director and the actors that would not normally be expected to transit any of the
450 enterprise networks. Such policy and firewall modification would have been undesirable and
451 would, in effect, have amounted to unauthorized channels into the enterprise networks.

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

457 2.4 Use Case A: Discovery and Identification of IDs, Assets, and Data Flows
458 NIST SP 800-207 [1] discusses the discovery and cataloging of all enterprise IDs, assets, and data flows as
459 the initial step before migrating to a ZTA. An enterprise needs to identify and understand the workflows
460 used in business processes, the IDs used, and the resources involved. Then it can move on to creating
461 policies around those workflows. This use case covers this initial exercise.

462 The following discovery use cases did not originally appear in the Project Description [3] but were
463 subsequently included to reflect the full ZTA migration process described in NIST SP 800-207.

464 2.4.1 Scenario A-1: Discovery and authentication of endpoint assets

465 Discovery here is focused on detecting assets and flows on the network, mapping them to identified
466 assets and flows, and providing access accordingly.

467 Pre-Condition: Enterprise-owned components (RSS and EP) have already undergone initial onboarding
468 for the enterprise, and BYODs have already registered with the enterprise. Any necessary agents,
469 certificates, etc. have been installed. Non-onboarded enterprise-owned components as well as non-
470 registered BYODs are treated the same as unknown guest devices. BYOD devices must have a software
471 agent installed that allows inspection of the devices to create a report of the device hygiene (e.g., look
472 for accepted virus scanner and approved OS). The enterprise infrastructure is a macrosegmented local
473 network with an “enterprise” segment with resources that can only be accessed by authorized
474 enterprise IDs and a “guest” segment with access to the public internet only.

475 Demonstration: Connect the device to the network and demonstrate network connectivity.

476 Purpose and Outcome: This scenario demonstrates the capability to authenticate assets at a specific
477 location and provide enterprise network access.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 10

 SECOND PRELIMINARY DRAFT

478 Table 2-6 Scenario A-1 Demonstrations

Demo ID Subj Onboarded/ Auth Compl Subj Desired Outcome

Type Registered Stat Loc
a RSS Y A+ Y Access to Network
b RSS Y A+ N No Access to Network
c RSS Y A- --- No Access to Network
d RSS N --- --- No Access to Network

e EP Y A+ Y Access to Network
f EP Y A+ N Max. Limited Access to
Network
g EP Y A- --- On- No Access to Network
A-1.1
h EP N --- --- Prem Access to Public Network

i BYOD Y A+ Y Access to Network

j BYOD Y A+ N Limited Access to Network
k BYOD Y A- --- No Access to Network
l BYOD N --- --- Access to Public Network

m Guest --- --- --- Access to Public Network

Dev.
a RSS Y A+ Y Access to Network
b RSS Y A+ N No Access to Network
c RSS Y A- --- No Access to Network
d RSS N --- --- No Access to Network

A-1.2 e EP Y A+ Y Branch Access to Network

f EP Y A+ N Limited Access to Network
g EP Y A- --- No Access to Network
h EP N --- --- Access to Public Network

i BYOD Y A+ Y Access to Network

NIST SP 1800-35D: Implementing a Zero Trust Architecture 11

 SECOND PRELIMINARY DRAFT

Demo ID Subj Onboarded/ Auth Compl Subj Desired Outcome

Type Registered Stat Loc
j BYOD Y A+ N Limited Access to Network
k BYOD Y A- --- No Access to Network
l BYOD N --- --- Access to Public Network

m Guest --- --- --- Access to Public Network

Dev.
a EP Y A+ Y Access to Network
b EP Y A+ N Max. Limited Access to
Network
c EP Y A- --- No Access to Network
Remot
A-1.3
e
d BYOD Y A+ Y Access to Network
e BYOD Y A+ N Max. Limited Access to
Network
f BYOD Y A- --- No Access to Network
a RSS Y A+ Y Access to Network
b RSS Y A+ N No Access to Network
c RSS Y A- --- No Access to Network
d RSS N --- --- No Access to Network
A-1.4 Cloud
e EP Y A+ Y Access to Network
f EP Y A+ N Max. Limited Access to
Network
g EP Y A- --- No Access to Network

479 2.4.2 Scenario A-2: Reauthentication of identified assets

480 Once an asset is identified and authenticated, continuous re-authentication is necessary.

481 Pre-Condition: The asset (user endpoint, resource) underwent previous authentication and is ready for
482 operation.

483 Demonstration: The asset is reauthenticated and will either pass or fail reauthentication.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 12

 SECOND PRELIMINARY DRAFT

484 Purpose and Outcome: This scenario demonstrates the proper reauthentication of an asset and
485 performs the desired action accordingly.

486 Table 2-7 Scenario A-2 Demonstrations

Demo ID Subj Onboarded/ Auth Compl Subj Desired Outcome

Type Registered Stat Loc
a RSS Y RA+ Y Keep Access to Network
b RSS Y RA+ N Terminate Access to Network
c RSS Y RA- --- Terminate Access to Network

d EP Y RA+ Y Keep Access to Network

e EP Y RA+ N Max. Limited Access to
On-
A-2.1 Network
Prem
f EP Y RA- --- Terminate Access to Network

g BYOD Y RA+ Y Keep Access to Network

h BYOD Y RA+ N Max. Limited Access to
Network
i BYOD Y RA- --- Terminate Access to Network
a RSS Y RA+ Y Keep Access to Network
b RSS Y RA+ N Terminate Access to Network
c RSS Y RA- --- Terminate Access to Network

d EP Y RA+ Y Keep Access to Network

e EP Y RA+ N Max. Limited Access to
A-2.2 Branch Network
f EP Y RA- --- Terminate Access to Network

g BYOD Y RA+ Y Keep Access to Network

h BYOD Y RA+ N Max. Limited Access to
Network
i BYOD Y RA- --- Terminate Access to Network
A-2.3 a EP Y RA+ Y Keep Access to Network

NIST SP 1800-35D: Implementing a Zero Trust Architecture 13

 SECOND PRELIMINARY DRAFT

Demo ID Subj Onboarded/ Auth Compl Subj Desired Outcome

Type Registered Stat Loc
b EP Y RA+ N Remot Max. Limited Access to
e Network
c EP Y RA- --- Terminate Access to Network

d BYOD Y RA+ Y Keep Access to Network

e BYOD Y RA+ N Max. Limited Access to
Network
f BYOD Y RA- --- Terminate Access to Network
a RSS Y RA+ Y Keep Access to Network
b RSS Y RA+ N Terminate Access to Network
c RSS Y RA- --- Terminate Access to Network

A-2.4 Cloud
d EP Y RA+ Y Keep Access to Network
e EP Y RA+ N Max. Limited Access to
Network
f EP Y RA- --- Terminate Access to Network

487 2.4.3 Scenario A-3: Discovery of transaction flows

488 This scenario demonstrates the monitoring of transactions between endpoints. Transactions include
489 user access to a resource or service-to-service communication.

490 Pre-Condition: User (Enterprise-ID or Other-ID) has a set of privileges to a resource and can successfully
491 authenticate. Requesting endpoints are considered successfully authenticated. Some mechanism is
492 present either on the endpoints or along the communication path that can observe and log actions.

493 Demonstration: Logs are produced that map user access requests, API calls, etc., between resources.
494 The logs may be on a third resource.

495 Purpose and Outcome: This scenario demonstrates the discovery and recording of metadata of traffic
496 flows between resources and user access requests/actions. The actual inspection of traffic is not
497 necessary.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 14

 SECOND PRELIMINARY DRAFT

498 Table 2-8 Scenario A-3 Demonstrations

Demo ID Endpoint Type Req Loc RSS Loc Desired Outcome

a USER User request and action is recorded
A-3.1 On-Prem On-Prem
b RSS/Service API call is recorded
a USER User request and action is recorded
A-3.2 On-Prem Cloud
b RSS/Service API call is recorded
a USER User request and action is recorded
A-3.3 Branch On-Prem
b RSS/Service API call is recorded
a USER User request and action is recorded
A-3.4 Branch Cloud
b RSS/Service API call is recorded
A-3.5 a USER Remote On-Prem User request and action is recorded
A-3.6 a USER Remote Cloud User request and action is recorded

499 2.5 Use Case B: Enterprise ID Access

500 Demonstrations in this use case deal with different scenarios using access to enterprise resources as
501 well as non-enterprise resources located on-premises, in the cloud, and on the internet.

502 Each activity demonstrates the capability of authentication from within a given setting. The access is
503 authenticated with an “enterprise-ID” using an enterprise-owned endpoint (EP) as well as a privately
504 owned endpoint (BYOD). Each scenario provides a set of pre-conditions as well as multiple
505 demonstrations.

506 2.5.1 Scenario B-1: Full/limited resource access using an enterprise endpoint
507 This scenario deals with a request using different enterprise ID profiles, one with access to all provided
508 resources and one with access to a limited set of resources (e.g., only RSS1 but not RSS2), or limited
509 functionality while accessing an enterprise-controlled resource (e.g., read-only vs. read/write).

510 Pre-Condition: The enterprise provides multiple user accounts with different access levels. The P_FULL
511 access profile specifies access to all resources (RSS) within the enterprise and/or all capabilities (CAP) of
512 resources within the enterprise. Additionally, the P_LIMITED access profile specifies access to a subset of
513 the resources and/or only limited functionality of each resource. Both endpoints’ compliance (Compl) is
514 already verified, and systems are authenticated per demonstration policy.

515 Demonstration: Each requestor using an enterprise-ID will attempt to successfully access an enterprise
516 resource or a functionality of an enterprise resource.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 15

 SECOND PRELIMINARY DRAFT

517 Purpose and Outcome: This demonstration focuses on user privilege, authentication/re-authentication,
518 the endpoint and RSS location, and the compliance of endpoints.

519 Table 2-9 Scenario B-1 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 On-Prem RA+ A A RSS1 Y Y Access Successful

B-1.1 →
i E1 On-Prem RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 Branch → A+ A A RSS1 Y Y Access Not Successful
B-1.2
e E2 On-Prem A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 16

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
h E1 RA+ A A RSS1 Y Y Access Successful
i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 Remote RA+ A A RSS1 Y Y Access Successful

B-1.3 →
i E1 On-Prem RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 On-Prem A+ A A RSS1 Y Y Access Successful
B-1.4
b E1 → A+ A A RSS2 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 17

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
c E1 Cloud A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 RA+ A A RSS1 Y Y Access Successful

i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 Branch → A- A --- --- Y --- Access Not Successful
B-1.5
Cloud
h E1 RA+ A A RSS1 Y Y Access Successful
i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 18

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 Remote RA+ A A RSS1 Y Y Access Successful

B-1.6 →
i E1 Cloud RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful

520 2.5.2 Scenario B-2: Full/limited internet access using an enterprise endpoint
521 This scenario deals with access from an enterprise-owned device to non-enterprise-managed internet
522 resources using different enterprise ID profiles: one with access to the internet, one with limited access
523 to the internet, and one with no access to the internet.

524 Pre-Condition: The enterprise provides multiple user accounts with different access levels to the
525 internet. The internet access will be performed using an enterprise-owned endpoint. RSS types are OK
526 for approved and not OK for not-approved internet resources. The approval depends on the user’s
527 policy. User endpoints are checked for compliance (Compl) per demonstration policy. “Out of Hours”

NIST SP 1800-35D: Implementing a Zero Trust Architecture 19

 SECOND PRELIMINARY DRAFT

528 refers to the request taking place outside of marked business hours, which would fall outside of normal
529 access behaviors seen for the ID.

530 Demonstration: Each requestor using an Enterprise-ID will attempt to successfully access a non-
531 enterprise resource.

532 Purpose and Outcome: This demonstration focuses on the endpoint location as well as the resource
533 location.

534 Table 2-10 Scenario B-2 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP EP Out of
RSS Hours
a E4 A+ A URL1 Y N Access Successful
b E4 A+ A URL2 Y N Access Successful
c E4 A+ A URL1 Y Y Access Successful
d E4 A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful
f E5 A+ A URL1 Y N Access Not Successful
g E5 A+ A URL2 Y N Access Successful
h E5 A+ A URL1 Y Y Access Not Successful
i E5 On-Prem A+ A URL1 Y Y Access Not Successful
B-2.1 →
j E5 Internet A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

m E4 A+ A URL1 N --- Access Not Successful

n E4 A+ A URL2 N --- Access Successful
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful
a E4 Branch A+ A URL1 Y N Access Successful
B-2.2 b E4 → A+ A URL2 Y N Access Successful
c E4 Internet A+ A URL1 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 20

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP EP Out of
RSS Hours
d E4 A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful
f E5 A+ A URL1 Y N Access Not Successful
g E5 A+ A URL2 Y N Access Successful
h E5 A+ A URL1 Y Y Access Not Successful
i E5 A+ A URL1 Y Y Access Not Successful
j E5 A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

m E4 A+ A URL1 N --- Access Not Successful

n E4 A+ A URL2 N --- Access Successful
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful
a E4 A+ A URL1 Y N Access Successful
b E4 A+ A URL2 Y N Access Successful
c E4 A+ A URL1 Y Y Access Successful
d E4 A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful
f E5 A+ A URL1 Y N Access Not Successful
g E5 Remote A+ A URL2 Y N Access Successful
B-2.3 →
h E5 Internet A+ A URL1 Y Y Access Not Successful
i E5 A+ A URL1 Y Y Access Not Successful
j E5 A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 21

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP EP Out of
RSS Hours
m E4 A+ A URL1 N --- Access Not Successful
n E4 A+ A URL2 N --- Access Successful
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful

535 2.5.3 Scenario B-3: Stolen credential using an enterprise endpoint

536 This scenario deals with a request using a stolen credential. It does not matter if the access is performed
537 using an enterprise endpoint.

538 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing the enterprise
539 resource RSS1 using an enterprise endpoint. The endpoints are compliant and authenticated, and so is
540 the resource.

541 Demonstration: Two requests for the same enterprise resource are performed using the same user
542 credentials. The “Real Request” is performed using the latest credentials, which are modified/replaced
543 after being reported stolen. The “Hostile Request” is performed using a stolen enterprise-ID. All
544 authentication methods of the Hostile Request are compromised. Re-authentication always follows a
545 previously successful authentication.

546 Purpose and Outcome: This demonstration focuses on the detection of a stolen requester’s enterprise-
547 ID and enforcement of isolation.

548 Table 2-11 Scenario B-3 Demonstrations

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
On-Prem Successful
c E6 On-Prem A A+ N Change to Access Access Not
B-3.1
→ Limited Successful
d E6 On-Prem A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 22

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- All Sessions
Terminated
o E7 A --- Y All Sessions ---
Terminated
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
On-Prem Limited Successful
d E6 Branch A A- N Keep Access Access Not
B-3.2
→ Successful
e E6 On-Prem --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 23

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Branch Successful
e E6 On-Prem --- A+ N --- Access Successful
B-3.3
f E6 → --- A- N --- Access Not
On-Prem Successful
g E6 A+ A N Access Not Change to Access
Successful Limited
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

NIST SP 1800-35D: Implementing a Zero Trust Architecture 24

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Remote Successful
On-Prem
B-3.4 g E6 A+ A N Access Not Change to Access
→
Successful Limited
On-Prem
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---

NIST SP 1800-35D: Implementing a Zero Trust Architecture 25

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
On-Prem Successful Limited
Remote
B-3.5 h E6 A- A N Access Not Keep Access
→
Successful
On-Prem

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 26

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
o E7 A --- Y Change to Access ---
Limited

549 2.5.4 Scenario B-4: Full/limited resource access using BYOD

550 This scenario deals with requests using different enterprise ID profiles, one with access to all provided
551 resources and one with access to a limited set of resources (e.g., only RSS1 but not RSS2) or limited
552 functionality while accessing an enterprise-controlled resource (e.g., read-only vs. read/write). In this
553 scenario, the device used is BYOD.

554 Pre-Condition: The enterprise provides multiple User accounts with different access levels. The P_FULL
555 access profile specifies access to either all resources (RSS) within the enterprise and/or all capabilities
556 (CAP) of resources within the enterprise. Additionally, the P_LIMITED access profile specifies access to
557 either a subset of the resources and/or limited functionality of each resource. Both endpoints’
558 compliance (Compl) is already verified, and systems are authenticated per demonstration policy.

559 Demonstration: Each requestor using an enterprise-ID will attempt to successfully access an enterprise
560 resource or a functionality of an enterprise resource.

561 Purpose and Outcome: This demonstration focuses on user privilege, authentication/re-authentication,
562 the endpoint and RSS location, and the compliance of endpoints.

563 Table 2-12 Scenario B-4 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 On-Prem A+ A A RSS1 Y Y Access Not Successful
B-4.1 e E2 → A+ A A RSS2 Y Y Access Successful
f E2 On-Prem A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 RA+ A A RSS1 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 27

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 Branch → RA+ A A RSS1 Y Y Access Successful

B-4.2
i E1 On-Prem RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 Remote A+ A A RSS1 Y Y Access Successful
B-4.3 b E1 → A+ A A RSS2 Y Y Access Successful
c E1 On-Prem A- A --- --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 28

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 RA+ A A RSS1 Y Y Access Successful

i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 On-Prem A- A --- --- Y --- Access Not Successful
B-4.4 →
h E1 Cloud RA+ A A RSS1 Y Y Access Successful
i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 29

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 Branch → RA+ A A RSS1 Y Y Access Successful

B-4.5
j E1 Cloud RA- A --- --- Y --- Access Not Successful
k E1 RA+ A A RSS1 N Y Access Not Successful
l E1 RA+ A A RSS2 N Y Access Limited

m E1 A+ A A RSS1 N Y Access Not Successful

n E1 A+ A A RSS2 N Y Access Limited
o E1 A+ A A RSS1 Y N Access Not Successful
p E1 A+ A A RSS2 Y N Access Not Successful
q E2 A+ A A RSS2 Y N Access Not Successful
a E1 A+ A A RSS1 Y Y Access Successful
b E1 A+ A A RSS2 Y Y Access Successful
c E1 A- A --- --- Y --- Access Not Successful
d E2 Remote A+ A A RSS1 Y Y Access Not Successful
B-4.6 e E2 → A+ A A RSS2 Y Y Access Successful
f E2 Cloud A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h E1 RA+ A A RSS1 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 30

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
i E1 RA- A --- --- Y --- Access Not Successful
j E1 RA+ A A RSS1 N Y Access Not Successful
k E1 RA+ A A RSS2 N Y Access Limited

l E1 A+ A A RSS1 N Y Access Not Successful

m E1 A+ A A RSS2 N Y Access Limited
n E1 A+ A A RSS1 Y N Access Not Successful
o E1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful

564 2.5.5 Scenario B-5: Full/limited internet access using BYOD

565 This scenario deals with access from an enterprise-owned device to non-enterprise-managed internet
566 resources using different enterprise ID profiles: one with access to the internet, one with limited access
567 to the internet, and one with no access to the internet.

568 Pre-Condition: The enterprise provides multiple user accounts with different access levels to the
569 internet. Internet access will be performed using an enterprise-owned endpoint. RSS types are OK for
570 approved and not OK for not-approved internet resources. The approval depends on the user’s policy.
571 User endpoints are checked for compliance (Compl) per demonstration policy.

572 Demonstration: Each requestor using an enterprise-ID will attempt to successfully access a non-
573 enterprise resource.

574 Purpose and Outcome: This demonstration focuses on the endpoint location and the resource location.

575 Table 2-13 Scenario B-5 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP EP Out of
Hours
a E4 A+ A URL1 Y N Access Successful
b E4 On-Prem A+ A URL2 Y N Access Successful
B-5.1 c E4 → A+ A URL1 Y Y Access Successful
d E4 Internet A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 31

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP EP Out of
Hours
f E5 A+ A URL1 Y N Access Not Successful
g E5 A+ A URL2 Y N Access Successful
h E5 A+ A URL1 Y Y Access Not Successful
i E5 A+ A URL1 Y Y Access Not Successful
j E5 A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

m E4 A+ A URL1 N --- Access Not Successful

n E4 A+ A URL2 N --- Access Successful
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful
a E4 A+ A URL1 Y N Access Successful
b E4 A+ A URL2 Y N Access Successful
c E4 A+ A URL1 Y Y Access Successful
d E4 A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful
f E5 A+ A URL1 Y N Access Not Successful
g E5 A+ A URL2 Y N Access Successful
Branch
h E5 A+ A URL1 Y Y Access Not Successful
B-5.2 →
i E5 A+ A URL1 Y Y Access Not Successful
Internet
j E5 A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

m E4 A+ A URL1 N --- Access Not Successful

n E4 A+ A URL2 N --- Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 32

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP EP Out of
Hours
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful
a E4 A+ A URL1 Y N Access Successful
b E4 A+ A URL2 Y N Access Successful
c E4 A+ A URL1 Y Y Access Successful
d E4 A+ A URL1 Y Y Access Successful
e E4 A- A --- Y --- Access Not Successful
f E5 A+ A URL1 Y N Access Not Successful
g E5 A+ A URL2 Y N Access Successful
h E5 A+ A URL1 Y Y Access Not Successful
i E5 Remote A+ A URL1 Y Y Access Not Successful
B-5.3 →
j E5 Internet A- A --- Y --- Access Not Successful

k E4 RA+ A URL1 Y --- Access Successful

l E4 RA- A --- Y --- Access Not Successful

m E4 A+ A URL1 N --- Access Not Successful

n E4 A+ A URL2 N --- Access Successful
o E5 A+ A URL1 N N Access Not Successful
p E5 A+ A URL2 N N Access Not Successful

576 2.5.6 Scenario B-6: Stolen credential using BYOD

577 This scenario deals with a request using a stolen credential. It does not matter if the access is performed
578 using an enterprise endpoint or BYOD device.

579 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing the enterprise
580 resource RSS1 using an enterprise endpoint. The endpoints are compliant and authenticated, and so is
581 the resource.

582 Demonstration: Two requests for the same enterprise resource are performed using the same user
583 credentials. The “Real Request” is performed using the latest credentials, which are modified/replaced
584 after being reported stolen, and that request can succeed. The “Hostile Request” is performed using a

NIST SP 1800-35D: Implementing a Zero Trust Architecture 33

 SECOND PRELIMINARY DRAFT

585 stolen enterprise-ID. All authentication methods are compromised for the Hostile Request. Re-
586 authentication always follows a previously successful authentication.

587 Purpose and Outcome: This demonstration focuses on the detection of a stolen requester’s enterprise-
588 ID and enforcement of isolation.

589 Table 2-14 Scenario B-6 Demonstrations

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stol for Real Request for Hostile Request
Hostile Req Req en
> RSS
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
On-Prem Successful Limited
On-Prem
B-6.1 h E6 A- A N Access Not Keep Access
→
Successful
On-Prem

i E6 A+ --- Y Access Successful ---

j A A- Y Keep Access Access Not
Successful
k --- A- Y --- Access Not
Successful
l E6 RA+ --- Y Access Successful ---
m E6 --- RA- Y --- Access Not
Successful
n E6 --- A Y --- All Sessions
Terminated

NIST SP 1800-35D: Implementing a Zero Trust Architecture 34

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stol for Real Request for Hostile Request
Hostile Req Req en
> RSS
o E6 A --- Y All Sessions ---
Terminated
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited
h E6 On-Prem A- A N Access Not Keep Access
B-6.2 Branch → Successful
On-Prem
i E7 A+ --- Y Access Successful ---
j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 Branch A+ --- N Access Successful ---
B-6.3 b E6 On-Prem A- --- N Access Not ---
→ Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 35

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stol for Real Request for Hostile Request
Hostile Req Req en
> RSS
c E6 On-Prem A A+ N Change to Access Access Not
Limited Successful
d E6 A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Remote Successful
c E6 On-Prem A A+ N Change to Access Access Not
B-6.4
→ Limited Successful
d E6 On-Prem A A- N Keep Access Access Not
Successful
e E6 --- A+ N --- Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 36

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stol for Real Request for Hostile Request
Hostile Req Req en
> RSS
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited
a E6 A+ --- N Access Successful ---
b E6 A- --- N Access Not ---
Successful
c E6 A A+ N Change to Access Access Not
On-Prem Limited Successful
d E6 Remote A A- N Keep Access Access Not
B-6.5
→ Successful
e E6 On-Prem --- A+ N --- Access Successful
f E6 --- A- N --- Access Not
Successful
g E6 A+ A N Access Not Change to Access
Successful Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 37

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stol for Real Request for Hostile Request
Hostile Req Req en
> RSS
h E6 A- A N Access Not Keep Access
Successful

i E7 A+ --- Y Access Successful ---

j E7 A A- Y Keep Access Access Not
Successful
k E7 --- A- Y --- Access Not
Successful
l E7 RA+ --- Y Access Successful ---
m E7 --- RA- Y --- Access Not
Successful
n E7 --- A Y --- Change to Access
Limited
o E7 A --- Y Change to Access ---
Limited

590 2.6 Use Case C: Collaboration: Federated-ID Access

591 2.6.1 Scenario C-1: Full resource access using an enterprise endpoint
592 This scenario deals with a request using a successfully authenticated federated ID accessing an
593 enterprise-controlled resource. In this scenario, the maximum access configuration of the requester for
594 the enterprise-managed resource is set to full access.

595 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
596 authorized with full access to the resource.

597 Demonstration: The requestor using a federated ID will attempt to access an enterprise resource using
598 an enterprise-owned endpoint.

599 Purpose and Outcome: This demonstration focuses on the endpoint location with endpoint/resource
600 compliance (Compl).

NIST SP 1800-35D: Implementing a Zero Trust Architecture 38

 SECOND PRELIMINARY DRAFT

601 Table 2-15 Scenario C-1 Demonstrations

Demo ID Req EP Req Loc RSS EP RSS Loc Desired Outcome

Compl Compl
a Y Y Access Successful
b N Y Access Not Successful
C-1.1 On-Prem On-Prem
c Y N Access Limited
d N N Access Not Successful
Comment: In this set of demonstrations, the desired outcome will be to deny access to the resource
in case the endpoint is not compliant. If the endpoint is compliant but the resource is not compliant,
the access is restricted.
a Y Y Access Successful
C-1.2 Branch On-Prem
b N Y Access Not Successful

A Y Y Access Successful
C-1.3 Remote On-Prem
b N Y Access Not Successful

a Y Y Access Successful
b N Y Access Not Successful
C-1.4 On-Prem Cloud
c Y N Access Limited
d N N Access Not Successful

a Y Y Access Successful
C-1.5 Branch Cloud
b N Y Access Not Successful

a Y Y Access Successful
C-1.6 Remote Cloud
b N Y Access Not Successful

602 2.6.2 Scenario C-2: Limited resource access using an enterprise endpoint
603 This scenario deals with a request using a successfully authenticated federated ID accessing an
604 enterprise-controlled resource. In this scenario, the maximum access configuration of the requester for
605 the enterprise-managed resource is set to limited access.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 39

 SECOND PRELIMINARY DRAFT

606 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
607 authorized with limited access to the resource.

608 Demonstration: The requestor using a federated ID will attempt to access an enterprise resource using
609 an enterprise-owned endpoint.

610 Purpose and Outcome: This demonstration focuses on the endpoint location with endpoint/resource
611 compliance (Compl).

612 Table 2-16 Scenario C-2 Demonstrations

Demo ID Req EP Req Loc RSS EP RSS Loc Desired Outcome

Compl Compl
a Y Y Access Limited
b N Y Access Not Successful
C-2.1 On-Prem On-Prem
c Y N Access Limited
d N N Access Not Successful
Comment: In this set of demonstrations, the desired outcome will be to deny access to the resource
in case the endpoint is not compliant. If the endpoint is compliant but the resource is not compliant,
the access is restricted.
a Y Y Access Limited
C-2.2 Branch On-Prem
b N Y Access Not Successful

a Y Y Access Limited
C-2.3 Remote On-Prem
b N Y Access Not Successful

a Y Y Access Limited
b N Y Access Not Successful
C-2.4 On-Prem Cloud
c Y N Access Limited
d N N Access Not Successful

a Y Y Access Limited
C-2.5 Branch Cloud
b N Y Access Not Successful

a Y Y Access Limited
C-2.6 Remote Cloud
b N Y Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 40

 SECOND PRELIMINARY DRAFT

613 2.6.3 Scenario C-3: Limited internet access using an enterprise endpoint
614 This scenario deals with a request using a successfully authenticated federated ID accessing a non-
615 enterprise-controlled resource in the public internet using an enterprise-owned endpoint device with
616 limited internet access.

617 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
618 authorized with limited access to the Internet.

619 Demonstration: The requestor using a federated ID will attempt to access two resources located in the
620 public Internet. The resources are not controlled by the enterprise. One resource is allowed, the other
621 one is blocked.

622 Purpose and Outcome: This demonstration focuses on the endpoint resource compliance with access of
623 non-enterprise-controlled resources on the internet by a requester with internet access using an
624 enterprise-controlled resource.

625 Table 2-17 Scenario C-3 Demonstrations

Demo ID Req EP Req Loc RSS Access RSS Loc Desired Outcome
Compl Policy
a Y Allowed RSS 1 Access Successful
b N On- Allowed RSS 1 Access Not Successful
C-3.1 Internet
c Y Prem Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
a Y Allowed RSS 1 Access Successful
b N Allowed RSS 1 Access Not Successful
C-3.2 Branch Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
a Y Allowed RSS 1 Access Successful
b N Allowed RSS 1 Access Not Successful
C-3.3 Remote Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful

626 2.6.4 Scenario C-4: No internet access using an enterprise endpoint

627 This scenario deals with a request using a successfully authenticated federated ID accessing a non-
628 enterprise-controlled resource in the public internet using an enterprise-owned endpoint device with
629 internet access disabled.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 41

 SECOND PRELIMINARY DRAFT

630 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
631 authorized with no access to the Internet.

632 Demonstration: The requestor using a federated ID will attempt to access two resources both located in
633 the public Internet. The resources are not controlled by the enterprise. One resource is allowed, the
634 other one is blocked.

635 Purpose and Outcome: This demonstration focuses on the endpoint resource compliance with access of
636 non-enterprise-controlled resources on the internet by a requester with no internet access.

637 Table 2-18 Scenario C-4 Demonstrations

Demo ID Req EP Req Loc RSS Access RSS Loc Desired Outcome
Compl Policy
a Y Allowed RSS 1 Access Not Successful
b N On- Allowed RSS 1 Access Not Successful
C-4.1 Internet
c Y Prem Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
a Y Allowed RSS 1 Access Not Successful
b N Allowed RSS 1 Access Not Successful
C-4.2 Branch Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
a Y Allowed RSS 1 Access Not Successful
b N Allowed RSS 1 Access Not Successful
C-4.3 Remote Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful

638 2.6.5 Scenario C-5: Internet access using BYOD

639 This scenario deals with a request using a successfully authenticated federated ID accessing a resource
640 on the Internet using privately owned devices. For this scenario, it is not needed to perform additional
641 testing depending on the access level (full, limited) towards the resource because the access level is set
642 to be restricted due to the device being BYOD.

643 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
644 authorized with limited access to the Internet. Both resources RSS1 and RSS2 are not managed by the
645 enterprise. For example, RSS1 could be a gambling site and RSS2 could be a search engine.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 42

 SECOND PRELIMINARY DRAFT

646 Demonstration: The requestor using a federated ID will attempt to access two resources both located in
647 the public Internet. The resources are not controlled by the enterprise. One resource is allowed, the
648 other one is blocked. The endpoint itself is of type BYOD.

649 Purpose and Outcome: This demonstration focuses on BYOD endpoint compliance with access of non-
650 enterprise-controlled resources on the internet by a requester with limited internet access.

651 Table 2-19 Scenario C-5 Demonstrations

Demo ID Req EP Req Loc RSS Access RSS Loc Desired Outcome
Compl Policy
a Y Allowed RSS 1 Access Successful
b N On- Allowed RSS 1 Access Not Successful/Limited
C-5.1 Internet
c Y Prem Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
Comment: Compliance on the endpoint might not be completely determined.
a Y Allowed RSS 1 Access Successful
b N Allowed RSS 1 Access Not Successful/Limited
C-5.2 Branch Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
Comment: Compliance on the endpoint might not be completely determined.
a Y Allowed RSS 1 Access Successful
b N Allowed RSS 1 Access Not Successful/Limited
C-5.3 Remote Internet
c Y Blocked RSS 2 Access Not Successful
d N Blocked RSS 2 Access Not Successful
Comment: Compliance on the endpoint might not be completely determined.

652 2.6.6 Scenario C-6: Access resources using BYOD

653 This scenario deals with a request using a successfully authenticated federated ID accessing an
654 enterprise-controlled resource using privately owned devices. For this scenario it is not needed to
655 perform additional testing depending on the access level (full, limited) towards the resource because
656 the access level is set to be restricted due to the device being BYOD.

657 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
658 authorized with full access to the resource. The system setup must lower the access level to the
659 resource into a restricted access mode due to the usage of BYOD.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 43

 SECOND PRELIMINARY DRAFT

660 Demonstration: The requestor using a federated ID will attempt to access an enterprise resource using a
661 privately owned device.

662 Purpose and Outcome: This demonstration focuses on the endpoint device (BYOD), lowering access
663 level rights, and endpoint compliance and location.

664 Table 2-20 Scenario C-6 Demonstrations

Demo ID Req. EP Req. Loc RSS EP RSS Loc Desired Outcome

Compl Compl
a Y Y Access Limited
b N On- Y On- Access Not Successful
C-6.1
c Y Prem N Prem Access Limited/Restricted
d N N Access Not Successful
Comment: In this set of demonstrations, the desired outcome will be to deny access to the
resource in case the endpoint is not compliant. If the endpoint is compliant, but the resource
is not compliant, the access is restricted.
a Y Y On- Access Limited
C-6.2 Branch
b N Y Prem Access Not Successful

a Y Y On- Access Limited

C-6.3 Remote
b N Y Prem Access Not Successful

a Y Y Access Limited
b N On- Y Access Not Successful
C-6.4 Cloud
c Y Prem N Access Limited/Restricted
d N N Access Not Successful

a Y Y Access Limited
C-6.5 Branch Cloud
b N Y Access Not Successful

a Y Y Access Limited
C-6.6 Remote Cloud
b N Y Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 44

 SECOND PRELIMINARY DRAFT

665 2.6.7 Scenario C-7: Stolen credential using an enterprise endpoint

666 This scenario deals with a request using a stolen credential employing an enterprise endpoint.

667 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing an enterprise
668 resource using an enterprise endpoint.

669 Demonstration: The requestor, using a stolen federated ID, will attempt to access an enterprise
670 resource using an enterprise endpoint.

671 Purpose and Outcome: This demonstration focuses on the requester’s federated ID as well as the
672 endpoint status (stolen vs. not stolen).

673 Table 2-21 Scenario C-7 Demonstrations

Demo ID Req Req Loc Req EP RSS Loc Desired Outcome

Credential
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.1 On-Prem On-Prem
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.2 Branch On-Prem
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.3 Remote On-Prem
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.4 On-Prem Cloud
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail

NIST SP 1800-35D: Implementing a Zero Trust Architecture 45

 SECOND PRELIMINARY DRAFT

Demo ID Req Req Loc Req EP RSS Loc Desired Outcome

Credential
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.5 Branch Cloud
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail
a Active Active Access Successful
b Active Flagged Stolen Access Not Successful
C-7.6 Remote Cloud
c Flagged Stolen Active Access Not Successful
d Flagged Stolen Flagged Stolen Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail

674 2.6.8 Scenario C-8: Stolen credential using BYOD

675 This scenario deals with a request using a stolen credential employing a BYOD endpoint.

676 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing an enterprise
677 resource using a privately owned device (BYOD).

678 Demonstration: The requestor using a stolen federated ID will attempt to access an enterprise resource
679 using a BYOD endpoint.

680 Purpose and Outcome: This demonstration focuses on the requester’s federated ID status (stolen vs.
681 not stolen).

682 Table 2-22 Scenario C-8 Demonstrations

Demo ID Req Req Loc Req EP RSS Loc Desired Outcome

Credential Compliance
a Active Y Access Successful
C-8.1 On-Prem On-Prem
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)
a Active Y Access Successful
C-8.2 Branch On-Prem
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)

NIST SP 1800-35D: Implementing a Zero Trust Architecture 46

 SECOND PRELIMINARY DRAFT

Demo ID Req Req Loc Req EP RSS Loc Desired Outcome

Credential Compliance
a Active Y Access Successful
C-8.3 Remote On-Prem
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)
a Active Y Access Successful
C-8.4 On-Prem Cloud
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)
a Active Y Access Successful
C-8.5 Branch Cloud
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)
a Active Y Access Successful
C-8.6 Remote Cloud
b Flagged Stolen Y Access Not Successful
Comment: For “Flagged Stolen” credentials, MFA should fail, BYOD outside compliance must
not be granted access (see C-5/6)

683 2.7 Use Case D: Other-ID Access

684 Demonstrations in this use case deal with different scenarios using access to enterprise resources as
685 well as non-enterprise resources located on-premises, in the cloud, and on the internet. Each activity
686 demonstrates the capability of authentication from within a given setting. The access is authenticated
687 with an “other ID” using enterprise-owned endpoints (EP) as well as privately owned endpoints (BYOD).
688 Each scenario provides a set of pre-conditions as well as multiple demonstrations.

689 2.7.1 Scenario D-1: Full/limited resource access using an enterprise endpoint
690 This scenario deals with a request using different “other-ID” profiles, one with access to all provided
691 resources and one with access to a limited set of resources (e.g., only RSS1 but not RSS2) or with limited
692 functionality while accessing an enterprise-controlled resource (e.g., read-only vs. read/write).

693 Pre-Condition: The enterprise provides multiple User accounts with different access levels. The P_FULL
694 access profile specifies access to all resources (RSS) within the enterprise and/or access to all capabilities
695 (CAP) of resources within the enterprise. Additionally, the P_LIMITED access profile specifies access to
696 either a subset of the recourses and/or only limited functionality of each resource. Both endpoints’
697 compliance (Compl) is already verified, and systems are authenticated per demonstration policy.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 47

 SECOND PRELIMINARY DRAFT

698 Demonstration: Each requestor using an “other ID” will attempt to successfully access an enterprise
699 resource or a functionality of an enterprise resource.

700 Purpose and Outcome: This demonstration focuses on user privilege, authentication/re-authentication,
701 and endpoint and RSS location, as well as the compliance of endpoints.

702 Table 2-23 Scenario D-1 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 On-Prem RA+ A A RSS1 Y Y Access Successful

D-1.1 →
i O1 On-Prem RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 Branch → A- A --- --- Y --- Access Not Successful
D-1.2
d E2 On-Prem A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 48

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
g E3 A- A --- --- Y --- Access Not Successful

h O1 RA+ A A RSS1 Y Y Access Successful

i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 Remote RA+ A A RSS1 Y Y Access Successful

D-1.3 →
i O1 On-Prem RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 49

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d E2 A+ A A RSS1 Y Y Access Not Successful
e E2 A+ A A RSS2 Y Y Access Successful
f E2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 On-Prem RA+ A A RSS1 Y Y Access Successful

D-1.4 →
i O1 Cloud RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 Branch → A- A --- --- Y --- Access Not Successful
D-1.5
g O3 Cloud A- A --- --- Y --- Access Not Successful

h O1 RA+ A A RSS1 Y Y Access Successful

i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 50

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP RSS EP RSS

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 A- A --- --- Y --- Access Not Successful
g O3 A- A --- --- Y --- Access Not Successful

h O1 Remote RA+ A A RSS1 Y Y Access Successful

D-1.6 →
i O1 Cloud RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful

703 2.7.2 Scenario D-2: Full/limited internet access using an enterprise endpoint
704 This scenario deals with access from an enterprise-owned device to non-enterprise-managed internet
705 resources using different enterprise ID profiles: one with access to the internet, one with limited access
706 to the internet, and one with no access to the internet.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 51

 SECOND PRELIMINARY DRAFT

707 Pre-Condition: The enterprise provides multiple user accounts with different access levels to the
708 internet. The Internet access will be performed using an enterprise-owned endpoint. RSS types are OK
709 for approved and not OK for not-approved internet resources. The approval depends on the user’s
710 policy. User endpoints are checked for compliance (Compl) per demonstration policy.

711 Demonstration: Each requestor using an enterprise-ID will attempt to successfully access a non-
712 enterprise resource.

713 Purpose and Outcome: This demonstration focuses on the endpoint location as well as the resource
714 location.

715 Table 2-24 Scenario D-2 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. → User EP EP Out of
RSS Hours
a O4 A+ A URL1 Y N Access Successful
b O4 A+ A URL2 Y N Access Successful
c O4 A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
e O4 A- A --- Y --- Access Not Successful
f O5 A+ A URL1 Y N Access Not Successful
g O5 A+ A URL2 Y N Access Successful
h O5 A+ A URL1 Y Y Access Not Successful
i O5 On-Prem A+ A URL1 Y Y Access Not Successful
D-2.1 →
j O5 Internet A- A --- Y --- Access Not Successful

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful
a O4 Branch A+ A URL1 Y N Access Successful
D-2.2
b O4 → A+ A URL2 Y N Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 52

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. → User EP EP Out of
RSS Hours
c O4 Internet A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
e O4 A- A --- Y --- Access Not Successful
f O5 A+ A URL1 Y N Access Not Successful
g O5 A+ A URL2 Y N Access Successful
h O5 A+ A URL1 Y Y Access Not Successful
i O5 A+ A URL1 Y Y Access Not Successful
j O5 A- A --- Y --- Access Not Successful

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful
a O4 A+ A URL1 Y N Access Successful
b O4 A+ A URL2 Y N Access Successful
c O4 A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
e O4 A- A --- Y --- Access Not Successful
f O5 Remote A+ A URL1 Y N Access Not Successful
D-2.3 g O5 → A+ A URL2 Y N Access Successful
h O5 Internet A+ A URL1 Y Y Access Not Successful
i O5 A+ A URL1 Y Y Access Not Successful
j O5 A- A --- Y --- Access Not Successful

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 53

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. → User EP EP Out of
RSS Hours

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful

716 2.7.3 Scenario D-3: Stolen credential using BYOD or enterprise endpoint
717 This scenario deals with a request using a stolen credential. It does not matter if the access is performed
718 using an enterprise endpoint or BYOD device.

719 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing enterprise resource
720 RSS1 using an enterprise endpoint. The requesting endpoint and requested resource are both in
721 compliance.

722 Demonstration: Two requests for the same enterprise resource from an enterprise endpoint are
723 performed using the same user credentials. The “Real Request” is performed using the latest
724 credentials, which are modified/replaced after being reported stolen, and that request can succeed. The
725 “Hostile Request” is performed using a stolen enterprise ID. All authentication methods are
726 compromised. Re-authentication always follows a previously successful authentication.

727 Purpose and Outcome: This demonstration focuses on the detection of a stolen requester’s enterprise
728 ID and enforcement of isolation.

729 Table 2-25 Scenario D-3 Demonstrations

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
On-Prem
Successful
On-Prem
D-3.1 c O6 A A+ N Change to Access Access Not
→
Limited Successful
On-Prem
d O6 A A- N Keep Access Access Not
Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 54

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
Successful Limited
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- All Sessions
Terminated
o O7 A --- Y All Sessions ---
Terminated
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
On-Prem Limited Successful
d O6 Branch A A- N Keep Access Access Not
D-3.2
→ Successful
e O6 On-Prem --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
Successful Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 55

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
Branch
e O6 On-Prem --- A+ N --- Access Successful
D-3.3
f O6 → --- A- N --- Access Not
On-Prem Successful
g O6 A+ A N Access Not Change to Access
Successful Limited
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

NIST SP 1800-35D: Implementing a Zero Trust Architecture 56

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Remote Successful
On-Prem
D-3.4 g O6 A+ A N Access Not Change to Access
→
Successful Limited
On-Prem
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---

NIST SP 1800-35D: Implementing a Zero Trust Architecture 57

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
On-Prem Successful Limited
Remote
D-3.5 h O6 A- A N Access Not Keep Access
→
Successful
On-Prem

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 58

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
o O7 A --- Y Change to Access ---
Limited

730 2.7.4 Scenario D-4: Full/limited resource access using BYOD

731 This scenario deals with a request using different enterprise ID profiles, one with access to all provided
732 resources and one with access to a limited set of resources (e.g., only RSS1 but not RSS2) or with limited
733 functionality while accessing an enterprise-controlled resource (e.g., read-only vs. read/write). In this
734 scenario the device used is BYOD.

735 Pre-Condition: The enterprise provides multiple user accounts with different access levels. The P_FULL
736 access profile specifies access to either all resources (RSS) within the enterprise and/or all capabilities
737 (CAP) of resources within the enterprise. Additionally, the P_LIMITED access profile specifies access to
738 either a subset of the recourses and/or only limited functionality of each resource. Both endpoints’
739 compliance (Compl) is already verified, and systems are authenticated per demonstration policy.

740 Demonstration: Each requestor using an enterprise ID will attempt to successfully access an enterprise
741 resource or a functionality of an enterprise resource.

742 Purpose and Outcome: This demonstration focuses on user privilege, authentication/re-authentication,
743 the endpoint and RSS location, as well as the compliance of endpoints.

744 Table 2-26 Scenario D-4 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP RSS EP RSS
RSS
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d E2 On-Prem A+ A A RSS1 Y Y Access Not Successful
D-4.1 e E2 → A+ A A RSS2 Y Y Access Successful
f E2 On-Prem A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 RA+ A A RSS1 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 59

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP RSS EP RSS
RSS
i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p E2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 Branch RA+ A A RSS1 Y Y Access Successful

D-4.2 →
i O1 On-Prem RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful
a O1 Remote A+ A A RSS1 Y Y Access Successful
D-4.3
b O1 → A+ A A RSS2 Y Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 60

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP RSS EP RSS
RSS
c O1 On-Prem A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 A- A --- --- Y --- Access Not Successful
g E3 A- A --- --- Y --- Access Not Successful

h O1 RA+ A A RSS1 Y Y Access Successful

i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 On-Prem A- A --- --- Y --- Access Not Successful
D-4.4 g O3 → A- A --- --- Y --- Access Not Successful
Cloud

h O1 RA+ A A RSS1 Y Y Access Successful

i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 61

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP RSS EP RSS
RSS
l O1 A+ A A RSS1 N Y Access Not Successful
m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 A- A --- --- Y --- Access Not Successful
d O2 A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 A- A --- --- Y --- Access Not Successful
g O2 A- A --- --- Y --- Access Not Successful

h O1 Branch RA+ A A RSS1 Y Y Access Successful

D-4.5 →
i O1 Cloud RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful
a O1 A+ A A RSS1 Y Y Access Successful
b O1 A+ A A RSS2 Y Y Access Successful
c O1 Remote A- A --- --- Y --- Access Not Successful
D-4.6 →
d O2 Cloud A+ A A RSS1 Y Y Access Not Successful
e O2 A+ A A RSS2 Y Y Access Successful
f O2 A- A --- --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 62

 SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > User EP RSS EP RSS
RSS
g O3 A- A --- --- Y --- Access Not Successful

h O1 RA+ A A RSS1 Y Y Access Successful

i O1 RA- A --- --- Y --- Access Not Successful
j O1 RA+ A A RSS1 N Y Access Not Successful
k O1 RA+ A A RSS2 N Y Access Limited

l O1 A+ A A RSS1 N Y Access Not Successful

m O1 A+ A A RSS2 N Y Access Limited
n O1 A+ A A RSS1 Y N Access Not Successful
o O1 A+ A A RSS2 Y N Access Not Successful
p O2 A+ A A RSS2 Y N Access Not Successful

745 2.7.5 Scenario D-5: Full/limited internet access using BYOD

746 This scenario deals with access from an enterprise-owned device to non-enterprise-managed internet
747 resources using different enterprise ID profiles: one with access to the internet, one with limited access
748 to the internet, and one with no access to the internet.

749 Pre-Condition: The enterprise provides multiple user accounts with different access levels to the
750 internet. The internet access will be performed using a BYOD endpoint. RSS types are OK for approved
751 and not OK for not-approved internet resources. The approval depends on the user’s policy. User
752 endpoints are checked for compliance (Compl) per demonstration policy.

753 Demonstration: Each requestor using an enterprise ID will attempt to successfully access a non-
754 enterprise resource.

755 Purpose and Outcome: This demonstration focuses on the endpoint location as well as the resource
756 location.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 63

 SECOND PRELIMINARY DRAFT

757 Table 2-27 Scenario D-5 Demonstrations

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP EP Out of
Hours
a O4 A+ A URL1 Y N Access Successful
b O4 A+ A URL2 Y N Access Successful
c O4 A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
e O4 A- A --- Y --- Access Not Successful
f O5 A+ A URL1 Y N Access Not Successful
g O5 A+ A URL2 Y N Access Successful
h O5 A+ A URL1 Y Y Access Not Successful
i O5 On-Prem A+ A URL1 Y Y Access Not Successful
D-5.1 →
j O5 Internet A- A --- Y --- Access Not Successful

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful
a O4 A+ A URL1 Y N Access Successful
b O4 A+ A URL2 Y N Access Successful
c O4 A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
Branch
e O4 A- A --- Y --- Access Not Successful
D-5.2 →
f O5 A+ A URL1 Y N Access Not Successful
Internet
g O5 A+ A URL2 Y N Access Successful
h O5 A+ A URL1 Y Y Access Not Successful
i O5 A+ A URL1 Y Y Access Not Successful
j O5 A- A --- Y --- Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 64

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Access Compl Desired Outcome

Req. > RSS User EP EP Out of
Hours

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful
a O4 A+ A URL1 Y N Access Successful
b O4 A+ A URL2 Y N Access Successful
c O4 A+ A URL1 Y Y Access Successful
d O4 A+ A URL1 Y Y Access Successful
e O4 A- A --- Y --- Access Not Successful
f O5 A+ A URL1 Y N Access Not Successful
g O5 A+ A URL2 Y N Access Successful
h O5 A+ A URL1 Y Y Access Not Successful
i O5 Remote A+ A URL1 Y Y Access Not Successful
D-5.3 →
j O5 Internet A- A --- Y --- Access Not Successful

k O4 RA+ A URL1 Y --- Access Successful

l O4 RA- A --- Y --- Access Not Successful

m O4 A+ A URL1 N --- Access Not Successful

n O4 A+ A URL2 N --- Access Successful
o O5 A+ A URL1 N N Access Not Successful
p O5 A+ A URL2 N N Access Not Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 65

 SECOND PRELIMINARY DRAFT

758 2.7.6 Scenario D-6: Stolen credential using BYOD

759 This scenario deals with a request using a stolen credential. It does not matter if the access is performed
760 using an enterprise endpoint or BYOD device.

761 Pre-Condition: The requestor’s credential is stolen and is used to attempt accessing enterprise resource
762 RSS1 using a BYOD endpoint. The endpoints and requested resources are considered compliant.

763 Demonstration: One request is performed and is successful, in parallel using the same user credentials
764 from 2 separate devices to one resource. One of the requestors is using a stolen enterprise-ID will
765 attempt to access an Enterprise Resource using a BYOD endpoint.

766 The “Real Req” always uses the latest credentials which are modified/replaced after being reported
767 stolen. Re-Authentication always follows a previously successful authentication.

768 All authentication methods are compromised

769 Two requests for the same enterprise resource from at least one BYOD endpoint are performed using
770 the same user credentials. The “Real Request” is performed using the latest credentials, which are
771 modified/replaced after being reported stolen, and that request can succeed. The “Hostile Request” is
772 performed using a stolen enterprise-ID. All authentication methods are compromised. Re-authentication
773 always follows a previously successful authentication.

774 Purpose and Outcome: This demonstration focuses on the detection of a stolen requester’s enterprise-
775 ID and enforcement of isolation.

776 Table 2-28 Scenario D-6 Demonstrations

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 On-Prem A A+ N Change to Access Access Not
On-Prem Limited Successful
D-6.1
d O6 → A A- N Keep Access Access Not
On-Prem Successful
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 66

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
g O6 A+ A N Access Not Change to Access
Successful Limited
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- All Sessions
Terminated
o O7 A --- Y All Sessions ---
Terminated
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
On-Prem Successful
Branch
D-6.2 e O6 --- A+ N --- Access Successful
→
f O6 On-Prem --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
Successful Limited
h O6 A- A N Access Not Keep Access
Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 67

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
i O7 A+ --- Y Access Successful ---
j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
e O6 --- A+ N --- Access Successful
f O6 Branch --- A- N --- Access Not
On-Prem Successful
D-6.3
g O6 → A+ A N Access Not Change to Access
On-Prem Successful Limited
h O6 A- A N Access Not Keep Access
Successful

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 68

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
Remote Successful Limited
On-Prem
D-6.4 h O6 A- A N Access Not Keep Access
→
Successful
On-Prem

i O7 A+ --- Y Access Successful ---

j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 69

SECOND PRELIMINARY DRAFT

Demo ID UP Location Auth Stat Rep. Desired Outcome Desired Outcome

Real Real Hostile Stolen for Real Request for Hostile Request
Hostile Req Req
> RSS
o O7 A --- Y Change to Access ---
Limited
a O6 A+ --- N Access Successful ---
b O6 A- --- N Access Not ---
Successful
c O6 A A+ N Change to Access Access Not
Limited Successful
d O6 A A- N Keep Access Access Not
Successful
e O6 --- A+ N --- Access Successful
f O6 --- A- N --- Access Not
Successful
g O6 A+ A N Access Not Change to Access
Successful Limited
On-Prem
h O6 A- A N Access Not Keep Access
Remote Successful
D-6.5
→
On-Prem
i O7 A+ --- Y Access Successful ---
j O7 A A- Y Keep Access Access Not
Successful
k O7 --- A- Y --- Access Not
Successful
l O7 RA+ --- Y Access Successful ---
m O7 --- RA- Y --- Access Not
Successful
n O7 --- A Y --- Change to Access
Limited
o O7 A --- Y Change to Access ---
Limited

NIST SP 1800-35D: Implementing a Zero Trust Architecture 70

 SECOND PRELIMINARY DRAFT

777 2.8 Use Case E: Guest: No-ID Access

778 2.8.1 Scenario E-1: Guest requests public internet access
779 For No-ID access, the only deciding factor is the type of device used and any known compliance state of
780 the device. Authentication/authorization is not a factor (No-ID). Enterprise resource compliance is
781 likewise assumed, as resources would not be visible otherwise.

782 Pre-Condition: The requestor does not need to authenticate (i.e., guest access). Per configuration, the
783 requestor is authorized with default universal access to the resource (i.e., no authentication or
784 authorization checks are performed). A request to access the enterprise resource is granted and a
785 session is established. The resource is assumed to be in compliance.

786 Demonstration: Systems can differentiate between device classifications and perform some action
787 based on policy to restrict privileged devices (i.e., enterprise-managed, BYOD) based on endpoint
788 compliance policy.

789 Purpose and Outcome: This demonstration focuses on device identification and compliance (when
790 applicable).

791 Table 2-29 Scenario E-1 Demonstrations

Demo ID Location of Access Desired Outcome

Subject

a Public resource Access Successful

E-1.1 On-Prem
b Public internet Access Successful

a Public resource Access Successful

E-1.2 Branch
b Public internet Access Successful

792 2.9 Use Case F: Confidence Level

793 2.9.1 Scenario F-1: User reauthentication fails during active session
794 This scenario is based on a successful request with an established session to an enterprise resource
795 using an enterprise-owned endpoint. The requestor’s reauthentication will fail, reducing the confidence
796 level. This leads to terminating the active session.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 71

 SECOND PRELIMINARY DRAFT

797 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
798 authorized with full access to the resource. A request to access the enterprise resource is granted and a
799 session is established.

800 Demonstration: The reauthentication of the requestor fails, and the session will be terminated.

801 Purpose and Outcome: This demonstration focuses on the requester’s identification, which fails re-
802 authentication during an active session.

803 Table 2-30 Scenario F-1 Demonstrations

Demo ID Re-auth Req Loc RSS Loc Desired Outcome

a Passes Session stays active
F-1.1 On-Prem On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-1.2 Branch On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-1.3 Remote On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-1.4 On-Prem Cloud
b Fails Session will be terminated

a Passes Session stays active

F-1.5 Branch Cloud
b Fails Session will be terminated

a Passes Session stays active

F-1.6 Remote Cloud
b Fails Session will be terminated

804 2.9.2 Scenario F-2: Requesting endpoint reauthentication fails during active
805 session
806 This scenario is based on a successful request with an established session to an enterprise resource
807 using an enterprise-owned endpoint. The reauthentication of the requesting endpoint will fail, reducing
808 the confidence level. This leads to terminating the active session.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 72

 SECOND PRELIMINARY DRAFT

809 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
810 authorized with full access to the resource. A request to access the enterprise resource is granted and a
811 session is established.

812 Demonstration: The reauthentication of the requestor’s endpoint fails, and the session will be
813 terminated.

814 Purpose and Outcome: This demonstration focuses on the requester’s endpoint identification, which
815 fails re-authentication during an active session.

816 Table 2-31 Scenario F-2 Demonstrations

Demo ID Re-auth Req. Loc RSS Loc Desired Outcome

a Passes Session stays active
F-2.1 On-Prem On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-2.2 Branch On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-2.3 Remote On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-2.4 On-Prem Cloud
b Fails Session will be terminated

a Passes Session stays active

F-2.5 Branch Cloud
b Fails Session will be terminated

a Passes Session stays active

F-2.6 Remote Cloud
b Fails Session will be terminated

817 2.9.3 Scenario F-3: Resource reauthentication fails during active session
818 This scenario is based on a successful request with an established session to an enterprise resource. The
819 reauthentication of the resource will fail, reducing the confidence level. This leads to terminating the
820 active session.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 73

 SECOND PRELIMINARY DRAFT

821 Pre-Condition: The requestor is identified and authenticated. Per configuration, the requestor is
822 authorized with full access to the resource. A request to access the enterprise resource is granted and a
823 session is established.

824 Demonstration: The reauthentication of the resource fails, and the session will be terminated.

825 Purpose and Outcome: This demonstration focuses on the resource identification, which fails re-
826 authentication during an active session.

827 Table 2-32 Scenario F-3 Demonstrations

Demo ID Re-auth Req. Loc RSS Loc Desired Outcome

a Passes Session stays active
F-3.1 On-Prem On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-3.2 Branch On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-3.3 Remote On-Prem
b Fails Session will be terminated

a Passes Session stays active

F-3.4 On-Prem Cloud
b Fails Session will be terminated

a Passes Session stays active

F-3.5 Branch Cloud
b Fails Session will be terminated

a Passes Session stays active

F-3.6 Remote Cloud
b Fails Session will be terminated

828 2.9.4 Scenario F-4: Compliance fails during active session

829 This scenario is based on a successful request with an established session to an enterprise resource
830 using an enterprise-owned endpoint. The endpoint will fall out of compliance, reducing the confidence
831 level. This terminates the session.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 74

 SECOND PRELIMINARY DRAFT

832 Pre-Condition: The requestor is identified and authenticated. The endpoint used is tested and
833 considered compliant. A request to access the enterprise resource is granted and a session is
834 established.

835 Demonstration: The requesting endpoint falls out of policy (becomes not compliant), and the session
836 will be terminated. The requesting endpoint is either enterprise-owned or BYOD. It cannot be a guest
837 endpoint for these demonstrations.

838 Purpose and Outcome: This demonstration focuses on the requester’s endpoint compliance, which
839 changes from compliant to not compliant during an active session.

840 Table 2-33 Scenario F-4 Demonstrations

Demo ID Req EP Req Loc RSS Loc Desired Outcome

Compl
a Y Session stays active
F-4.1 On-Prem On-Prem
b N Session will be terminated

a Y Session stays active

F-4.2 Branch On-Prem
b N Session will be terminated

a Y Session stays active

F-4.3 Remote On-Prem
b N Session will be terminated

a Y Session stays active

F-4.4 On-Prem Cloud
b N Session will be terminated

a Y Session stays active

F-4.5 Branch Cloud
b N Session will be terminated

a Y Session stays active

F-4.6 Remote Cloud
b N Session will be terminated

NIST SP 1800-35D: Implementing a Zero Trust Architecture 75

 SECOND PRELIMINARY DRAFT

841 2.9.5 Scenario F-5: Compliance improves between requests

842 This scenario is the inverse of scenario F-4. Here, there is an initial rejection due to compliance issues,
843 followed by a mitigation that improves the confidence level. Then a repeat request will be successful
844 and establish a session to an enterprise resource.

845 Pre-Condition: The requestor is identified and could be authenticated, depending on when
846 authentication takes place in the process. The endpoint used is tested and initially considered
847 noncompliant. The endpoint then improves its compliance status and the request is re-issued. A request
848 to access the enterprise resource is granted and a session is established.

849 Demonstration: The requesting endpoint is initially out of policy (not compliant) but can remediate the
850 issue and is successful in a repeated request for the same resource.

851 Purpose and Outcome: This demonstration focuses on the requester’s endpoint compliance, which
852 changes from not compliant to compliant before fully establishing a session.

853 Table 2-34 Scenario F-5 Demonstrations

Demo ID Req EP Req Loc RSS Loc Desired Outcome

Compl
a N Access Not Successful
F-5.1 On-Prem On-Prem
b Y Access Successful

a N Access Not Successful

F-5.2 Branch On-Prem
b Y Access Successful

a N Access Not Successful

F-5.3 Remote On-Prem
b Y Access Successful

a N Access Not Successful

F-5.4 On-Prem Cloud
b Y Access Successful

a N Access Not Successful

F-5.5 Branch Cloud
b Y Access Successful

a N Access Not Successful

F-5.6 Remote Cloud
b Y Access Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 76

 SECOND PRELIMINARY DRAFT

Demo ID Req EP Req Loc RSS Loc Desired Outcome

Compl

854 3 Functional Demonstration Results

855 3.1 EIG Crawl Phase Demonstration Results
856 This section lists the demonstration results for each of the builds that was implemented as part of the
857 EIG crawl phase, as defined in NIST SP 1800-35B: Approach, Architecture, and Security Characteristics.

858 3.1.1 Enterprise 1 Build 1 (E1B1) Demonstration Results

859 Table 3-1 lists the results for all EIG crawl phase demonstrations run in Enterprise 1 Build 1 (E1B1). While
860 the technology deployed in E1B1 was able to determine endpoint compliance for mobile devices and
861 prevent noncompliant mobile endpoints from accessing resources, it was not able to determine the
862 compliance status of desktop endpoints and automatically use that as a determining factor in deciding
863 whether access requests originating from that desktop endpoint should be granted. Consequently, the
864 results listed in this section only include demonstrations in which the requesting endpoints are mobile
865 devices. No demonstrations were performed in which the requesting device was a desktop system. In all
866 demonstrations that were conducted, the ZTA functionality included in the build performed as expected.

867 Table 3-1 Demonstration Results for E1B1 EIG Crawl Phase

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.a-m N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build. All
devices are already joined to the network. There is
no tool that can keep any entity (RSS, EP, BYOD, or
guest device) from joining the network based on its
authentication status.
A-1.2.a-m N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.
A-1.3.a-f N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.
A-1.4.a-g N/A N/A Cloud-based resources are out of scope until the run
phase.
A-2.1.a-i N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 77

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
There is no tool that can reauthenticate any entity
(RSS, EP, BYOD, or guest device) and terminate its
network access based on authentication status.
A-2.2.a-i N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build
based on reauthentication status.
A-2.3.a-f N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build
based on reauthentication status.
A-2.4.a-f N/A N/A Cloud-based resources are out of scope until the run
phase.
A-3.1.a, A-3.3.a, A- User User login Success: Okta records the authentication logs.
3.5.a request to an Administrators can log in to Okta and view logs of
and action applicatio when a user logged onto an application and whether
is n is logged the authentication was successful or not.
recorded
A-3.1.b, A-3.3.b API call is Logs Success: Okta logs have relevant information about
recorded contain the authentication between the user and resource.
relevant
API
informatio
n
A-3.2.a-b, A-3.4.a-b, N/A N/A Cloud-based resources are out of scope until the run
A-3.6.a phase.
B-1.1.a, B-1.2.a, B- Access Access Partial success: For the mobile endpoint, user access
1.3.a, B-4.1.a, B- Successful Successful to resource RSS1 is based on endpoint compliance.
4.2.a, B-4.3.a, D- However, we cannot validate compliance of RSS1.
1.1.a, D-1.2.a, D-
1.3.a, D-4.1.a, D-
4.2.a, D-4.3.a
B-1.1.b, B-1.2.b, B- Access Access Partial success: For the mobile endpoint, user access
1.3.b, B-4.1.b, B- Successful Successful to resource RSS1 is based on endpoint compliance.
4.2.b, B-4.3.b, D- However, we cannot validate compliance of RSS2.
1.1.b, D-1.2.b, D-
1.3.b, D-4.1.b, D-
4.2.b, D-4.3.b

NIST SP 1800-35D: Implementing a Zero Trust Architecture 78

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.1.c, B-1.2.c, B- Access Access Partial success: Demonstrated user authentication
1.3.c, B-4.1.c, B- Not Not failure at the mobile endpoint, but we cannot
4.2.c, B-4.3.c, D- Successful Successful validate compliance on RSS1. Partial demonstration
1.1.c, D-1.2.c, D- completed with user not able to log in to mobile
1.3.c, D-4.1.c, D- device.
4.2.c, D-4.3.c
B-1.1.d, B-1.2.d, B- Access Access Partial success: Mobile: Based on configuration in
1.3.d, B-4.1.d, B- Not Not Ent1, the E2 is not authorized to access RSS1 based
4.2.d, B-4.3.d, D- Successful Successful on enterprise governance policy.
1.1.d, D-1.2.d, D- Also, RSS compliance cannot be demonstrated in
1.3.d, D-4.1.d, D- this phase. In this case, user is not granted access to
4.2.d, D-4.3.d RSS1.
B-1.1.e, B-1.2.e, B- Access Access Partial success: Mobile: User access to RSS2 is based
1.3.e, B-4.1.e, B- Successful Successful on the EP’s compliance. Cannot validate compliance
4.2.e, B-4.3.e, D- on RSS2. Partial demonstration.
1.1.e, D-1.2.e, D-
1.3.e, D-4.1.e, D-
4.2.e, D-4.3.e
B-1.1.f, B-1.2.f, B- Access Access Partial success: Mobile: User authentication failure is
1.3.f, B-4.1.f, B-4.2.f, Not Not at the endpoint. Cannot validate compliance on
B-4.3.f, D-1.1.f, D- Successful Successful RSS1. Partial demonstration completed with user
1.2.f, D-1.3.f, D- not able to log in to mobile device.
4.1.f, D-4.2.f, D-4.3.f
B-1.1.g, B-1.2.g, B- Access N/A Demonstration cannot be completed. Mobile: must
1.3.g, B-4.1.g, B- Not have certain tools installed to manage the mobile
4.2.g, B-4.3.g, D- Successful device and its compliance. The only way this
1.1.g, D-1.2.g, D- happens is if the user forgets the login password on
1.3.g, D-4.1.g, D- the mobile device.
4.2.g, D-4.3.g
B-1.1.h, B-1.2.h, B- Access Access Success: GitLab session timeout is set to one minute
1.3.h, B-4.1.h, B- Successful Successful for demonstration purposes. After session timed
4.2.h, B-4.3.h, D- out, user was re-authenticated.
1.1.h, D-1.2.h, D-
1.3.h, D-4.1.h, D-
4.2.h, D-4.3.h
B-1.1.i, B-1.2.i, B- Access N/A Success: Only way to do this is to not use Okta
1.3.i, B-4.1.i, B-4.2.i, Not FastPass, which would make this case invalid. We
B-4.3.i, D-1.1.i, D- Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 79

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
1.2.i, D-1.3.i, D-4.1.i, pressed “No” on Okta FastPass and access was
D-4.2.i, D-4.3.i denied.
B-1.1.j, B-1.2.j, B- Access Access Success: On Ivanti, after initial authentication,
1.3.j, B-4.1.j, B-4.2.j, Not Not implemented a block on the Mobile Iron cloud. After
B-4.3.j, D-1.1.j, D- Successful Successful GitLab timed out, re-authentication was
1.2.j, D-1.3.j, D-4.1.j, unsuccessful.
D-4.2.j, D-4.3.j
B-1.1.k, B-1.2.k, B- Access N/A Partial success: Access to RSS2 is blocked. Currently
1.3.k, B-4.1.k, B- Limited cannot perform limited access.
4.2.k, B-4.3.k, D-
1.1.k, D-1.2.k, D-
1.3.k, D-4.1.k, D-
4.2.k, D-4.3.k
B-1.1.l-m, B-1.2.l-m, Access Access Success: User was denied access because the
B-1.3.l-m, B-4.1.l-m, Denied Denied endpoint was non-compliant.
B-4.2.l-m, B-4.3.l-m,
D-1.1.l-m, D-1.2.l-m,
D-1.3.l-m, D-4.1.l-m,
D-4.2.l-m, D-4.3.l-m
B-1.1.n-p, B-1.2.n-p, N/A N/A Demonstration cannot be run. Unable to perform
B-1.3.n-p, B-4.1.n-p, compliance checks on RSS.
B-4.2.n-p, B-4.3.n-p,
D-1.1.n-p, D-1.2.n-p,
D-1.3.n-p, D-4.1.n-p,
D-4.2.n-p, D-4.3.n-p
B-1.2.a-p The results are the same as B-1.1 since network
policies allow access from branch to Ent1. See
results from B-1.1.
B-1.3.a-p The results are the same as B-1.1 given that network
policies allow the user/device to access the
enterprise remotely using a VPN connection. See
results from B-1.1.
B-1.4.a-p, B-1.5.a-p, N/A N/A Cloud-based resources are out of scope until run
B-1.6.a-p, B-4.4.a-p, phase.
B-4.5.a-q, and B-
4.6.a-p

NIST SP 1800-35D: Implementing a Zero Trust Architecture 80

 SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-2.1.a-p, B-2.2.a-p, N/A N/A Out of scope until run phase. Tools are needed to
B-5 create policies to allow or deny access to internet
resources.
B-3, B-6 N/A N/A Out of scope until run phase.
B-4 As documented in the rows above, the results of all
B-4 use case demonstrations are the same as the
results of the B-1 use cases because the device is
both authenticated and compliant. In this case, a
BYOD device will have to install both the Ivanti
Neurons for UEM agent and Okta Verify App. See
results from B-1.1 for B-4.1, B-4.2, and B-4.3.
All C Use Cases N/A N/A Demonstrations cannot be performed. Currently, no
federation configuration has been set up between
Ent1, Ent2, and Ent3.
All D Use Cases As documented in the rows above, the results of all
D use case demonstrations are the same as the
results of the B use cases. Note that the user is a
contractor and will have access to resources based
on need. The Ivanti Neurons for UEM agent and
Okta Verify App will have to be installed on the
contractor’s device, whether it’s provided by the
enterprise or BYOD.
All E Use Cases N/A N/A Guest (No-ID) access is considered out of scope for
the EIG crawl phase.
All F Use Cases N/A N/A Confidence level use cases are considered out of
scope for the EIG crawl phase.

868 3.1.2 Enterprise 2 Build 1 (E2B1) Demonstration Results

869 Table 3-2 lists the results for all EIG crawl phase demonstrations run in Enterprise 2 Build 1 (E2B1). In all
870 demonstrations that we attempted to conduct, the ZTA functionality included in the build performed as
871 expected. The technology deployed in E2B1 was able to determine endpoint compliance for Android,
872 iOS, Windows, and Mac devices and prevent noncompliant endpoints from accessing private resources.
873 Consequently, compliance of endpoints was observed with health checks from Duo prior to the second-
874 factor authentication.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 81

 SECOND PRELIMINARY DRAFT

875 Table 3-2 Demonstration Results for E2B1 EIG Crawl Phase

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.a-m N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build. All
devices are already joined to the network. There is
no tool that can keep any entity (RSS, EP, BYOD, or
guest device) from joining the network based on its
authentication status.
A-1.2.a-m, A-1.3.a-f N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.
A-1.4.a-g N/A N/A Cloud-based resources are out of scope until the run
phase.
A-2.1.a-i N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.
There is no tool that can reauthenticate any entity
(RSS, EP, BYOD, or guest device) and terminate its
network access based on authentication status.
A-2.2.a-I, A-2.3.a-f N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build
based on reauthentication status.
A-2.4.a-f N/A N/A Cloud-based resources are out of scope until the run
phase.
A-3.1.a, A-3.3.a, A- User User login Success: Duo records the authentication logs.
3.5.a request to an Administrators can log in to Duo and view logs of
and action applicatio when a user logged onto an application and whether
is n is logged the authentication was successful or not.
recorded
A-3.1.b, A-3.3.b API call is Logs Success: Duo logs have relevant information about
recorded contain the authentication between the user and resource.
relevant
API
informatio
n
A-3.2.a-b, A-3.4.a-b, N/A N/A Cloud-based resources are out of scope until the run
A-3.6.a phase.
B-1.1.a, B-1.2.a, B- Access Access Partial success: User access to resource RSS1 is
1.3.a, B-4.1.a, B- Successful Successful based on endpoint compliance. Users much have

NIST SP 1800-35D: Implementing a Zero Trust Architecture 82

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
4.2.a, B-4.3.a, D- Duo client installed on device for health check. Users
1.1.a, D-1.2.a, D- also must have Duo Mobile installed on a mobile
1.3.a, D-4.1.a, D- device to perform second-factor authentication.
4.2.a, D-4.3.a However, we cannot validate compliance of RSS1 so
we label this “partial success”.
B-1.1.b, B-1.2.b, B- Access Access Partial success due to scope: User access to resource
1.3.b, B-4.1.b, B- Successful Successful RSS2 is based on endpoint compliance. However, we
4.2.b, B-4.3.b, D- cannot validate compliance of RSS2.
1.1.b, D-1.2.b, D-
1.3.b, D-4.1.b, D-
4.2.b, D-4.3.b
B-1.1.c, B-1.2.c, B- Access Access Partial success: Demonstrated user authentication
1.3.c, B-4.1.c, B- Not Not failure at the endpoint, but we cannot validate
4.2.c, B-4.3.c, D- Successful Successful compliance on RSS1. Partial demonstration
1.1.c, D-1.2.c, D- completed with user not able to log in to RSS1 due
1.3.c, D-4.1.c, D- to incorrect credentials.
4.2.c, D-4.3.c
B-1.1.d, B-1.2.d, B- Access Access Partial success: Based on configuration in Ent2, the
1.3.d, B-4.1.d, B- Not Not E2 is not authorized to access RSS1 based on
4.2.d, B-4.3.d, D- Successful Successful enterprise governance policy.
1.1.d, D-1.2.d, D- Also, RSS compliance cannot be demonstrated in
1.3.d, D-4.1.d, D- this phase. In this case, user is not granted access to
4.2.d, D-4.3.d RSS1.
B-1.1.e, B-1.2.e, B- Access Access Partial success: User access to RSS2 is based on the
1.3.e, B-4.1.e, B- Successful Successful EP’s compliance. Cannot validate compliance on
4.2.e, B-4.3.e, D- RSS2. Partial demonstration.
1.1.e, D-1.2.e, D-
1.3.e, D-4.1.e, D-
4.2.e, D-4.3.e
B-1.1.f, B-1.2.f, B- Access Access Partial success: User authentication failure is at the
1.3.f, B-4.1.f, B-4.2.f, Not Not endpoint. Cannot validate compliance on RSS1.
B-4.3.f, D-1.1.f, D- Successful Successful Partial demonstration completed with user not able
1.2.f, D-1.3.f, D- to log in from device.
4.1.f, D-4.2.f, D-4.3.f
B-1.1.g, B-1.2.g, B- Access N/A Demonstration cannot be completed. Must have
1.3.g, B-4.1.g, B- Not certain tools installed to manage the mobile device
4.2.g, B-4.3.g, D- Successful and its compliance. The only way this happens is if
1.1.g, D-1.2.g, D-

NIST SP 1800-35D: Implementing a Zero Trust Architecture 83

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
1.3.g, D-4.1.g, D- the user forgets the login password on the mobile
4.2.g, D-4.3.g device.
B-1.1.h, B-1.2.h, B- Access Access Success: GitLab session timeout is set to one minute
1.3.h, B-4.1.h, B- Successful Successful for demonstration purposes. After session timed
4.2.h, B-4.3.h, D- out, user was re-authenticated.
1.1.h, D-1.2.h, D-
1.3.h, D-4.1.h, D-
4.2.h, D-4.3.h
B-1.1.i, B-1.2.i, B- Access Access Success: Only way to do this is to put in a wrong
1.3.i, B-4.1.i, B-4.2.i, Not Not password for failure.
B-4.3.i, D-1.1.i, D- Successful Successful
1.2.i, D-1.3.i, D-4.1.i,
D-4.2.i, D-4.3.i
B-1.1.j, B-1.2.j, B- Access Access Success: On Duo, implemented a block on devices
1.3.j, B-4.1.j, B-4.2.j, Not Not that do not have firewall enabled. After GitLab timed
B-4.3.j, D-1.1.j, D- Successful Successful out, we turned off the firewall on the device and re-
1.2.j, D-1.3.j, D-4.1.j, authentication was unsuccessful.
D-4.2.j, D-4.3.j
B-1.1.k, B-1.2.k, B- Access N/A Partial success: Access to RSS2 is blocked if EP is not
1.3.k, B-4.1.k, B- Limited compliant. Currently cannot perform limited access.
4.2.k, B-4.3.k, D-
1.1.k, D-1.2.k, D-
1.3.k, D-4.1.k, D-
4.2.k, D-4.3.k
B-1.1.l-m, B-1.2.l-m, Access Access Success: User was denied access because the
B-1.3.l-m, B-4.1.l-m, Denied Denied endpoint was non-compliant.
B-4.2.l-m, B-4.3.l-m,
D-1.1.l-m, D-1.2.l-m,
D-1.3.l-m, D-4.1.l-m,
D-4.2.l-m, D-4.3.l-m
B-1.1.n-p, B-1.2.n-p, N/A N/A Demonstration cannot be run. Unable to perform
B-1.3.n-p, B-4.1.n-p, compliance checks on RSS.
B-4.2.n-p, B-4.3.n-p,
D-1.1.n-p, D-1.2.n-p,
D-1.3.n-p, D-4.1.n-p,
D-4.2.n-p, D-4.3.n-p
B-1.2.a-p The results would be the same as B-1.1 since
network policies allow access from a branch office to

NIST SP 1800-35D: Implementing a Zero Trust Architecture 84

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
Ent2. See results from B-1.1. (Note: Ent2 does not
have a branch office. If we were to create a branch
office, the network policies will allow the branch
office to Ent2. Therefore, it would be part of the
Ent2 policies and results would be identical to B-1.1.)
B-1.3.a-p The results are the same as B-1.1, given that
network policies allow the user/device to access the
enterprise remotely using a VPN connection. See
results from B-1.1.
B-1.4.a-p, B-1.5.a-p, N/A N/A Cloud-based resources are out of scope until run
B-1.6.a-p, B-4.4.a-p, phase.
B-4.5.a-q, and B-
4.6.a-p
B-2.1.a-p, B-2.2.a-p, N/A N/A Out of scope until run phase. Tools are needed to
B-5 create policies to allow or deny access to internet
resources.
B-3, B-6 N/A N/A Out of scope until run phase.
B-4 As documented in the rows above, the results of all
B-4 use case demonstrations are the same as the
results of the B-1 use cases because the device is
both authenticated and compliant. In this case, a
BYOD device will have to install Duo client for health
check. See results from B-1.1 for B-4.1, B-4.2, and B-
4.3.
All C Use Cases N/A N/A Demonstrations cannot be performed. Currently, no
federation configuration has been set up between
Ent1, Ent2, and Ent3.
All D Use Cases As documented in the rows above, the results of all
D use case demonstrations are the same as the
results of the B use cases. Note that the user is a
contractor and will have access to resources based
on need. The Duo client will have to be installed on
the contractor’s device, whether it’s provided by the
enterprise or BYOD. User must also install Duo
Mobile on their mobile device for second-factor
authentication.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 85

 SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
All E Use Cases N/A N/A Guest (No-ID) access is considered out of scope for
the EIG crawl phase.
All F Use Cases N/A N/A Confidence level use cases are considered out of
scope for the EIG crawl phase.
876

877 3.1.3 Enterprise 3 Build 1 (E3B1) Demonstration Results

878 Table 3-3 lists the demonstration results for all EIG crawl phase demonstrations run in Enterprise 3 Build
879 1 (E3B1). In all demonstrations that we attempted to conduct, the ZTA functionality included in the build
880 performed as expected. The technology deployed in E3B1 was able to determine endpoint compliance
881 for Android, iOS, Windows, and Mac devices and prevent noncompliant endpoints from accessing
882 private resources.

883 Table 3-3 Demonstration Results for E3B1 EIG Crawl Phase

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.a-m N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build. All devices are already
joined to the network. There is no tool that can keep any
entity (RSS, EP, BYOD, or guest device) from joining the
network based on its authentication status.
A-1.2.a-m N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build.
A-1.3.a-f N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build.
A-1.4.a-g N/A N/A Cloud-based resources are out of scope until run phase.
A-2.1.a-i N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build. There is no tool that
can reauthenticate any entity (RSS, EP, BYOD, or guest device)
and terminate its network access based on authentication
status.
A-2.2.a-i N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build based on
reauthentication status.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 86

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
A-2.3.a-f N/A N/A Demonstration cannot be completed. There is no network-
level enforcement present in this build based on
reauthentication status.
A-2.4.a-f N/A N/A Cloud-based resources are out of scope until run phase.
A-3.1.a, User User login Success: Azure AD records the authentication logs.
A-3.3.a, request to an Administrators can log in to Azure AD and view logs of when a
A-3.5.a and application user logged onto an application and whether the
action is is logged authentication was successful or not.
recorded
A-3.1.b, API call is Logs Success: Azure AD logs have relevant information about the
A-3.3.b recorded contain authentication between the user and resource.
relevant
API
information
A-3.2.a-b, N/A N/A Cloud-based resources are out of scope until run phase.
A-3.4.a-b,
A-3.6.a
B-1.1.a Access Access Partial Success: Users access RSS1 based on the EP
Successful Successful compliance. Cannot validate compliance of RSS1, so can only
partially demonstrate.
B-1.1.b Access Access Partial Success: Authenticated user access to RSS2 successful.
Successful Successful Can only partially demonstrate because cannot validate
compliance on RSS2.
B-1.1.c Access Access Not Partial Success: User authentication failure prevents access.
Not Successful Cannot validate compliance on RSS1. Partial demonstration
Successful completed with user not able to authenticate.
B-1.1.d Access Access Not Partial Success: Based on configuration in Ent 3, the E2 is not
Not Successful authorized to access RSS1 based on enterprise governance
Successful policy. Also, RSS compliance cannot be demonstrated in this
phase. In this case, user is not granted access to RSS1.
B-1.1.e Access Access Partial Success: Authenticated user access to RSS2 successful.
Successful Successful Can partially demonstrate. Cannot validate compliance on
RSS2.
B-1.1.f Access Access Not Success: User authentication failure prevents access.
Not Successful
Successful

NIST SP 1800-35D: Implementing a Zero Trust Architecture 87

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.1.g Access Access Not Success: User authentication failure prevents access.
Not Successful
Successful
B-1.1.h Access Access Partial Success: GitLab session timeout is set to one minute for
Successful Successful demonstration purposes. After session timed out, user was re-
authenticated. Can only partially demonstrate because cannot
validate RSS1 compliance.
B-1.1.i Access Access Not Success: Unauthenticated users were prevented from
Not Successful accessing resources.
Successful
B-1.1.j Access Access Not Partial Success: Authenticated user access to RSS1 successful.
Not Successful Can partially demonstrate. Cannot validate compliance on
Successful RSS1. After GitLab timed out, re-authentication was
unsuccessful.
B-1.1.k Access N/A Not able to demonstrate with current set of technologies.
Limited Cannot limit access based on device non-compliance.
B-1.1.l-p N/A N/A Cannot demonstrate. Unable to perform compliance checks
on RSS.
B-1.2.a-p Cannot test because there is no branch office in Ent. 3.
B-1.3.a-p The results are the same as B-1.1, given that network policies
allow the user/device to access the enterprise remotely using
a VPN connection. See results from B-1.1.
B-1.4.a-p, N/A N/A Cloud-based resources are out of scope until run phase.
B-1.5.a-p,
and B-
1.6.a-p
B-2, B-5 N/A N/A Out of scope until run phase. Tools are needed to create
policies to allow or deny access to internet resources.
B-3, B-6 Out of scope until run phase.
B-4 All demonstrations here are the same as B-1 since the device
is both authenticated and compliant.
All C Use N/A N/A Demonstrations cannot be performed. Currently, no
Cases federation configuration has been set up between Ent1, Ent2,
and Ent3.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 88

 SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
All D Use All demonstrations here are the same as B-1 since the device
Cases is both authenticated and compliant. Note that the user is a
contractor.
All E Use N/A N/A Guest (No-ID) access is considered out of scope for the EIG
Cases crawl phase.
All F Use N/A N/A Confidence level use cases are considered out of scope for the
Cases EIG crawl phase.

884 3.1.4 Enterprise 4 Build 1 (E4B1) Demonstration Results

885 These results will be included in the next version of this draft document.

886 3.2 EIG Run Phase Demonstration Results

887 This section lists the demonstration results for each of the builds that was implemented as part of the
888 EIG run phase, as defined in NIST SP 1800-35B: Approach, Architecture, and Security Characteristics.

889 3.2.1 Enterprise 1 Build 2 (E1B2) Demonstration Results

890 Table 3-4 lists the demonstration results for all EIG run phase demonstrations run in Enterprise 1 Build 2
891 (E1B2). In all demonstrations that we attempted to conduct, the ZTA functionality included in the build
892 performed as expected. The technology deployed in E1B2 was able to determine endpoint compliance
893 for Windows, Linux, Mac, and mobile devices and prevent noncompliant endpoints from accessing
894 private resources.

895 Table 3-4 Demonstration Results for E1B2 EIG Crawl Phase

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.a-m N/A N/A Demonstration cannot be completed. There is no
network-level enforcement present in this build.
Zscaler uses the client connector to allow a user on a
device to access specific resources only, whether on-
prem or remote. Users cannot readily access
resources in the enterprise (or network) if they do
not have permissions to access them. Resources are
not authenticated or checked for compliance in this
phase.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 89

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
A-1.2.a-m, A-1.3.a-f, N/A N/A Same as in A-1. Demonstration cannot be
A-1.4.a-g completed. There is no network-level enforcement
present in this build.
A-2.1.a-I, A-2.2.a-I, N/A N/A Same as in A-1. Demonstration cannot be
A-2.3.a-f, A-2.4.a-f completed. There is no network-level enforcement
present in this build.
A-3.1.a, A-3.3.a, A- User User login Success: Okta records the authentication logs.
3.5.a request to an Administrators can log in to Okta and view logs of
and action applicatio when a user logged onto an application and whether
is n is logged the authentication was successful or not. Zscaler
recorded Private Access (ZPA) records relevant information
about the connection between the endpoint and
resource.
A-3.1.b, A-3.3.b API call is Logs Success: Okta records the authentication logs.
recorded contain Administrators can log in to Okta and view logs of
relevant when a user logged onto an application and whether
API the authentication was successful or not. Zscaler ZPA
informatio records relevant information about the connection
n between the endpoint and resource.
A-3.2.a, A-3.4.a, A- User User login Success: Okta records the authentication logs.
3.6.a request to an Administrators can log in to Okta and view logs of
and action applicatio when a user logged onto an application and whether
is n is logged the authentication was successful or not. Zscaler ZPA
recorded records relevant information about the connection
between the endpoint and resource.
A-3.2.b, A-3.4.b, A- API call is Logs Success: Okta records the authentication logs.
3.6.a recorded contain Administrators can log in to Okta and view logs of
relevant when a user logged onto an application and whether
API the authentication was successful or not. Zscaler ZPA
informatio records relevant information about the connection
n between the endpoint and resource.
B-1.1.a, B-1.2.a, B- Access Access Partial success: User is authenticated via Okta when
1.3.a, B-4.1.a, B- Successful Successful accessing the resource. User logs into Zscaler client
4.2.a, B-4.3.a, D- connector as part of login process to the endpoint
1.1.a, D-1.2.a, D- and policies are applied to the user/endpoint
1.3.a, D-4.1.a, D- (including laptops, workstations, and mobile
4.2.a, D-4.3.a devices). User successfully connects to RSS1.
However, we cannot validate compliance of RSS1.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 90

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.1.b, B-1.2.b, B- Access Access Partial success: User is authenticated via Okta when
1.3.b, B-4.1.b, B- Successful Successful accessing the resource. User logs into Zscaler client
4.2.b, B-4.3.b, D- connector as part of login process to the endpoint
1.1.b, D-1.2.b, D- and policies are applied to the user/endpoint
1.3.b, D-4.1.b, D- (including laptops, workstations, and mobile
4.2.b, D-4.3.b devices). User successfully connects to RSS1.
However, we cannot validate compliance of RSS1.
B-1.1.c, B-1.2.c, B- Access Access Success: Demonstration completed with user not
1.3.c, B-4.1.c, B- Not Not able to log in to resource.
4.2.c, B-4.3.c, D- Successful Successful
1.1.c, D-1.2.c, D-
1.3.c, D-4.1.c, D-
4.2.c, D-4.3.c
B-1.1.d, B-1.2.d, B- Access Access Partial success: Based on configuration in Ent1, the
1.3.d, B-4.1.d, B- Not Not E2 is not authorized to access RSS1 based on
4.2.d, B-4.3.d, D- Successful Successful enterprise governance policy. ZPA will deny access
1.1.d, D-1.2.d, D- to the resource.
1.3.d, D-4.1.d, D- Also, RSS compliance cannot be demonstrated in
4.2.d, D-4.3.d this phase. In this case, user is not granted access to
RSS1.
B-1.1.e, B-1.2.e, B- Access Access Partial success: User is authenticated via Okta when
1.3.e, B-4.1.e, B- Successful Successful accessing the resource. User logs into Zscaler client
4.2.e, B-4.3.e, D- connector as part of login process to the endpoint
1.1.e, D-1.2.e, D- and policies are applied to the user/endpoint
1.3.e, D-4.1.e, D- (including laptops, workstations, and mobile
4.2.e, D-4.3.e devices). User successfully connects to RSS2.
However, we cannot validate compliance of RSS2.
B-1.1.f, B-1.2.f, B- Access Access Success: Without user authentication for the
1.3.f, B-4.1.f, B-4.2.f, Not Not resource the access attempt did not succeed.
B-4.3.f, D-1.1.f, D- Successful Successful
1.2.f, D-1.3.f, D-
4.1.f, D-4.2.f, D-4.3.f
B-1.1.g, B-1.2.g, B- Access Access Success: Without user authentication for the
1.3.g, B-4.1.g, B- Not Not resource, the access attempt did not succeed.
4.2.g, B-4.3.g, D- Successful Successful
1.1.g, D-1.2.g, D-
1.3.g, D-4.1.g, D-
4.2.g, D-4.3.g

NIST SP 1800-35D: Implementing a Zero Trust Architecture 91

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.1.h, B-1.2.h, B- Access Access Success: GitLab session timeout is set to one minute
1.3.h, B-4.1.h, B- Successful Successful for demonstration purposes. After session timed
4.2.h, B-4.3.h, D- out, user was re-authenticated.
1.1.h, D-1.2.h, D-
1.3.h, D-4.1.h, D-
4.2.h, D-4.3.h
B-1.1.i, B-1.2.i, B- Access Access Success: After session timeout, user tried to login
1.3.i, B-4.1.i, B-4.2.i, Not Not with incorrect password and was denied.
B-4.3.i, D-1.1.i, D- Successful Successful
1.2.i, D-1.3.i, D-4.1.i,
D-4.2.i, D-4.3.i
B-1.1.j, B-1.2.j, B- Access Access Success: Device posture failure detected by ZPA so
1.3.j, B-4.1.j, B-4.2.j, Not Not access was denied.
B-4.3.j, D-1.1.j, D- Successful Successful
1.2.j, D-1.3.j, D-4.1.j,
D-4.2.j, D-4.3.j
B-1.1.k, B-1.2.k, B- Access N/A Partial success: Access to RSS2 is blocked. Currently
1.3.k, B-4.1.k, B- Limited cannot perform limited access.
4.2.k, B-4.3.k, D-
1.1.k, D-1.2.k, D-
1.3.k, D-4.1.k, D-
4.2.k, D-4.3.k
B-1.1.l-m, B-1.2.l-m, Access Access Success: User was denied access because the
B-1.3.l-m, B-4.1.l-m, Denied Denied endpoint was non-compliant. Device posture failure
B-4.2.l-m, B-4.3.l-m, detected by ZPA.
D-1.1.l-m, D-1.2.l-m,
D-1.3.l-m, D-4.1.l-m,
D-4.2.l-m, D-4.3.l-m
B-1.1.n-p, B-1.2.n-p, N/A N/A Demonstration cannot be run. Unable to perform
B-1.3.n-p, B-4.1.n-p, compliance checks on RSS.
B-4.2.n-p, B-4.3.n-p,
D-1.1.n-p, D-1.2.n-p,
D-1.3.n-p, D-4.1.n-p,
D-4.2.n-p, D-4.3.n-p
B-1.2.a-p The results are the same as B-1.1 since network
policies allow access from branch to Ent1. See
results from B-1.1.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 92

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.3.a-p The results are the same as B-1.1, given that ZPA
policies allow the user/device to access the
enterprise remotely the same way that user/device
would access a resource within the enterprise. See
results from B-1.1.
B-1.4.a-p, B-1.5.a-p, Access to cloud-based resources (RSS1 and RSS2) are
B-1.6.a-p, B-4.4.a-p, the same as on-prem. See results from B-1.1.
B-4.5.a-q, and B-
4.6.a-p
B-2.1.a-d, B-2.2.a-d, Access Access Success: Employee is granted access to URL1 and
B-2.3.a-d B-5 Successful Successful URL2 regardless of hourly access time because
employees have full access to both URLs at all times
per ZScaler policy.
B-2.1.e, B-2.2.e, B- Access Access Success: The only way the user is not authenticated
2.3.e Not Not is if the user inputs the incorrect password or does
Successful Successful not have a second factor during Zscaler Client
Connector (ZCC) login. With incorrect 1st or 2nd
factor, ZCC will fail to connect with ZIA and will not
be able to access the internet.
B-2.1f, B-2.2f, B-2.3f Access Access Success: Contractor is blocked from URL1 as
Not Not expected per Zscaler policy.
Successful Successful
B-2.1g, B-2.2g, B- Access Access Success: Contractor is granted access to URL2 as
2.3g Successful Successful expected per Zscaler policy.
B-2.1.h-I,B-2.2.h-I,B- Access Access Success: Contractor is blocked from accessing URL1
2.3.h-i Not Not due to failed authentication.
Successful Successful
B-2.1.j, B-2.2.j, B- Access Access The only way the user is not authenticated is if the
2.3.j Not Successful user inputs the incorrect password or does not have
Successful a second factor during ZCC login. Access is successful
because internet access is required for ZIA to
function. If not authenticated to ZIA, internet access
is unrestricted unless blocked by company firewall.
B-2.1.k, B-2.2.k, B- Access Access Success: Employee is granted access after successful
2.3.k Successful Successful reauthentication per Zscaler policy as expected.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 93

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-2.1.l, B-2.2.l, B- Access Access Success: Employee cannot access URL1 or URL2 after
2.3.l Not Not reauthentication to Zscaler fails as expected.
Successful Successful
B-2.1.m-p, B-2.2.m- N/A N/A Demonstration cannot be completed. ZIA does not
p, B-2.3.m-p perform device posture/compliance checks on
endpoints without integration of a third-party EPP
product.
B-3.1.a, B-3.4.a, B- Real Req Real Req Success: Real Request successfully authenticated.
3.5.a Success Success
B-3.1.b, B-3.4.b, B- Real Req Real Req Success: Incorrect credentials were entered, and the
3.5.b Fail Fail Real Request failed as expected.
B-3.1.c, B-3.4.c, B- Limit N/A Unable to complete demonstration. Current build
3.5.c Access for does not have the capability to differentiate
Real between the Real Request and Hostile Request in
Request, this context.
Deny
Access to
Hostile
Request
B-3.1.d, B-3.4.d, B- Real N/A Unable to complete demonstration. Current build
3.5.d Request does not have the capability to differentiate
Keep between the Real Request and Hostile Request in
Access, this context.
Deny
Access to
Hostile
Request
B-3.1.e, B-3.4.e, B- Hostile Hostile Success: Hostile Request successfully authenticated.
3.5.e Request Request
Successful Successful
B-3.1.f, B-3.4.f, B- Hostile Hostile Success: Incorrect credentials were entered, and the
3.5.f Request Request Hostile Request failed as expected.
Unsuccess Unsuccess
ful ful
B-3.1.g, B-3.4.g, B- Real N/A Unable to complete demonstration. Current build
3.5.g Request does not have the capability to differentiate
Fail,

NIST SP 1800-35D: Implementing a Zero Trust Architecture 94

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
Hostile between the Real Request and Hostile Request in
Request this context.
Access
Limited
B-3.1.h, B-3.4.h, B- Real N/A Unable to complete demonstration. Current build
3.5.h Request does not have the capability to differentiate
Fail, between the Real Request and Hostile Request in
Hostile this context.
Request
remains
authentic
ated
B-3.1.i, B-3.4.i, B- Real Req Real Req Success: Real Request successfully authenticated.
3.5.i Success Success
B-3.1.j, B-3.4.j, B- Real N/A Unable to complete demonstration. Current build
3.5.j Request does not have the capability to differentiate
remains between the Real Request and Hostile Request in
authentic this context.
ated,
Hostile
Request
Fail
B-3.1.k, B-3.4.k, B- Hostile Hostile Success: Incorrect credentials were entered, and the
3.5.k Request Request Hostile Request failed as expected.
Fail Fail
B-3.1.l, B-3.4.l, B- Real Real Success: Real Request successfully reauthenticated.
3.5.l Request Requet
Access Access
Successful Successful
B-3.1.m, B-3.4.m, B- Hostile Hostile Success: Hostile Request reauthentication failed.
3.5.m Request Request
Access Access
Denied Denied
B-3.1.n, B-3.4.n, B- N/A N/A Demonstration could not be completed due to build
3.5.n not supporting session termination at this level.
B-3.1.o, B-3.4.o, B- N/A N/A Demonstration could not be completed due to build
3.5.o not supporting session termination at this level.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 95

 SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-4 As documented in the rows above, the results of all
B-4 use case demonstrations are the same as the
results of the B-1 use cases because the device is
both authenticated and compliant. In this case, a
BYOD device will have to install both the Ivanti
Neurons for UEM agent and Okta Verify App. See
results from B-1.1 for B-4.1, B-4.2, and B-4.3.
All C Use Cases N/A N/A Demonstrations cannot be performed. Currently, no
federation configuration has been set up between
Ent1, Ent2, and Ent3.
All D Use Cases As documented in the rows above, the results of all
D use case demonstrations are the same as the
results of the B use cases. Note that the user is a
contractor and will have access to resources based
on need. The Ivanti Neurons for UEM agent and
Okta Verify App will have to be installed on the
contractor’s device, whether it’s provided by the
enterprise or BYOD.
E-1.1a, E-1.2a Success Success Success: User/device is recognized by Zscaler
Internet Access (ZIA) as unmanaged and given access
to the internet. Per ZIA enterprise policies, resources
on the internet that are deemed safe for access are
reachable by the user with no ID, which includes a
public resource from Enterprise 1.
E-1.1b, E-1.2b Success Success Success: User/device is recognized by ZIA as
unmanaged and given access to the internet. Per ZIA
enterprise policies, resources on the internet that
are deemed safe for access are reachable by the
user with no ID.
All F Use Cases N/A N/A Test cannot be completed without third-party
integration with an EPP.

896 3.2.2 Enterprise 2 Build 2 (E2B2) Demonstration Results

897 There will not be an EIG run phase build in Enterprise 2, i.e., there will not be an E2B2.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 96

 SECOND PRELIMINARY DRAFT

898 3.2.3 Enterprise 3 Build 2 (E3B2) Demonstration Results

899 Table 3-5 lists the demonstration results for all EIG run phase demonstrations run in Enterprise 3 Build 2
900 (E3B2). In all demonstrations that we attempted to conduct, the ZTA functionality included in the build
901 performed as expected. The technology deployed in E3B2 was able to determine endpoint compliance
902 for Android, iOS, Windows, and Mac devices and prevent noncompliant endpoints from accessing
903 private resources.

904 Table 3-5 Demonstration Results for E3B2 EIG Run Phase

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.a-d Access to Access to Success: Resource has access to network in
Network Network accordance with Forescout policy.
A-1.1.b, A-1.1.c, No Access to No Access to Partial success: In the current configuration, the
A-1.1.g Network Network endpoint has access limited to the local subnet in
accordance with Forescout policy.
A-1.1.d No Access to N/A Demonstration cannot be completed. By Scenario
Network A-1 definition, a resource has already undergone
onboarding.
A-1.1.e Access to Access to Success: Endpoint has access to network in
Network Network accordance with Forescout policy.
A-1.1.f Max. Limited Max. Success: Endpoint has access limited in
Access to Limited accordance with Forescout policy.
Network Access to
Network
A-1.1.h Access to N/A Demonstration cannot be completed. By Scenario
Public A-1 definition, an endpoint has already
Network undergone onboarding.
A-1.1.i Access to Access to Success: BYOD has access to network in
Network Network accordance with Forescout policy.
A-1.1.j Limited Limited Success: Endpoint has access limited to the local
Access to Access to subnet in accordance with Forescout policy.
Network Network
A-1.1.k No Access to No Access to Partial success: In the current configuration, the
Network Network endpoint has access limited to the local subnet in
accordance with Forescout policy.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 97

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
A-1.1.l Access to N/A Demonstration cannot be completed. By Scenario
Public A-1 definition, the BYOD has already undergone
Network onboarding.
A-1.1.m Access to Access to Success: BYOD has access to network in
Public Public accordance with Forescout policy.
Network Network
A-1.2.a-m Access to N/A Demonstration cannot be completed. There is no
Network branch office configured for Enterprise 3.
A-1.3.a Access to Access to Success: Endpoint has access to network in
Network Network accordance with Forescout policy.
A-1.3.b Max. Limited Max. Success: Endpoint has access limited in
Access to Limited accordance with Forescout policy.
Network Access to
Network
A-1.3.c No Access to No Access to Success: Endpoint is denied access to the network
Network Network after failing to authenticate to the GlobalProtect
VPN.

A-1.3.d Access to Access to Success: BYOD has access to network in

Network Network accordance with Forescout policy.

A-1.3.e Max. Limited Max. Success: Endpoint has access limited in

Access to Limited accordance with Forescout policy.
Network Access to
Network
A-1.3.f No Access to No Access to Success: BYOD is denied access to the network
Network Network after failing to authenticate to the GlobalProtect
VPN.

A-1.4.a-g N/A N/A Testing of cloud-based resources and endpoints

as subjects is out of scope.
A-2.1.a Keep Access Keep Access Success: Resource has access to network in
to Network to Network accordance with Forescout policy.
A-2.1.b Terminate Limit Access Partial Success: Resource has access limited to the
Access to to Network local subnet in accordance with Forescout policy.
Network

NIST SP 1800-35D: Implementing a Zero Trust Architecture 98

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
A-2.1.c Terminate Limit Access Partial Success: Resource has access limited to the
Access to to Network local subnet in accordance with Forescout policy.
Network
A-2.1.d Keep Access Keep Access Success: Endpoint has access to network in
to Network to Network accordance with Forescout policy.
A-2.1.e Max. Limited Max. Success: Endpoint has access limited in
Access to Limited accordance with Forescout policy.
Network Access to
Network
A-2.1.f Terminate Limit Access Partial Success: Resource has access limited to the
Access to to Network local subnet in accordance with Forescout policy.
Network
A-2.1.g Keep Access Keep Access Success: BYOD has access to network in
to Network to Network accordance with Forescout policy.
A-2.1.h Max. Limited Max. Success: Endpoint has access limited in
Access to Limited accordance with Forescout policy.
Network Access to
Network
A-2.1.i Terminate Limit Access Partial success: BYOD has access limited to the
Access to to Network local subnet in accordance with Forescout policy.
Network
A-2.2.a-i N/A N/A Demonstration cannot be completed. There is no
branch office configured for Enterprise 3.
A-2.3.a Keep Access Keep Access Success: Endpoint has access to network in
to Network to Network accordance with Forescout policy.
A-2.3.b Max. Limited Max. Success: Endpoint has access limited in
Access to Limited accordance with Forescout policy.
Network Access to
Network
A-2.3.c Terminate Terminate Success: Endpoint has access terminated after
Access to Access to failing to re-authenticate to the GlobalProtect
Network Network VPN.
A-2.3.d Keep Access Keep Access Success: BYOD has access to network in
to Network to Network accordance with Forescout policy.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 99

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
A-2.3.e Max. Limited Max. Success: BYOD has access limited in accordance
Access to Limited with Forescout policy.
Network Access to
Network
A-2.3.f Terminate Terminate Success: BYOD has access terminated after failing
Access to Access to to re-authenticate to the GlobalProtect VPN.
Network Network
A-2.4.a,d Keep Access Keep Access Success: Azure is able to allow access to cloud
to Network to Network endpoints and resources.
A-2.4.b,c,f Terminate Terminate Success: Azure is able to limit access to cloud
Access to Access to endpoints and resources.
Network Network
A-2.4.e Max. Limited Max. Success: Azure is able to limit access to cloud
Access to Limited endpoints and resources.
Network Access to
Network
A-3.1.a, A-3.2.a User request N/A User activity and transaction flow is logged.
and action is Individual user actions are not visible.
recorded
A-3.3.a, A-3.4.a, User request N/A Branch testing is not available for this build.
and action is
recorded
A-3.5.a, A-3.6.a User request N/A User activity and transaction flow is logged.
and action is Individual user actions are not visible.
recorded
A-3.1.b, A-3.2.b, API call is N/A Service activity and transaction flow is logged by
A-3.3.b, A-3.4.b recorded Forescout. Individual API calls are not visible.

B-1.1.a Access Access Success: Users access RSS1 based on the EP and
Successful Successful RSS compliance with Forescout and Azure AD
policy.
B-1.1.b Access Access Success: Users access RSS2 based on the EP and
Successful Successful RSS compliance with Forescout and Azure AD
policy.
B-1.1.c Access Not Access Not Success: User authentication failure to Azure AD
Successful Successful prevents access.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 100

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-1.1.d Access Not Access Not Success: E2 is not authorized to access RSS1 in
Successful Successful accordance with Azure AD policy.
B-1.1.e Access Access Success: Users access RSS2 based on the EP and
Successful Successful RSS compliance with Forescout and Azure AD
policy.
B-1.1.f, B-1.1.g, Access Not Access Not Success: User authentication failure to Azure AD
Successful Successful prevents access.
B-1.1.h Access Access Success: Session timeout is set to one minute for
Successful Successful demonstration purposes. After session timed out,
user was re-authenticated to Azure AD.
B-1.1.i Access Not Access Not Success: Users were prevented from accessing
Successful Successful resources after re-authentication failure to Azure
AD.
B-1.1.j Access Not Access Not Success: Initial user authentication to Azure AD
Successful Successful was successful and user was granted access to
RSS1. After E1 became non-compliant, user access
to RSS1 was blocked in accordance with Forescout
policy, and the user was unable to re-authenticate
to Azure AD.
B-1.1.k Access Access Not Partial success: Initial user authentication to
Limited Successful Azure AD was successful and user was granted
access to RSS2. In this case, changing the user’s
access level on RSS2 would require application-
level control that is not available at this time.
After E1 became non-compliant, user access to
RSS2 was blocked in accordance with Forescout
policy, and the user was unable to re-authenticate
to Azure AD.
B-1.1.l Access Not Access Not Success: After E1 became non-compliant, user
Successful Successful access to RSS1 was blocked in accordance with
Forescout policy, and the user was unable to
authenticate to Azure AD.
B-1.1.m Access Access Not Partial success: In this case, changing the user’s
Limited Successful access level on RSS2 would require application-
level control that is not available at this time.
After E1 became non-compliant, user access to
RSS2 was blocked in accordance with Forescout

NIST SP 1800-35D: Implementing a Zero Trust Architecture 101

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
policy, and the user was unable to authenticate to
Azure AD.
B-1.1.n-p Access Not Access Not Success: After the RSS became non-compliant,
Successful Successful user access to the RSS was blocked in accordance
with Forescout policy, and the user was unable to
authenticate to Azure AD.
B-1.2.a-p Cannot test because there is no branch office in
Ent. 3.
B-1.3.a-p The results are the same as B-1.1, given that
network policies allow the user/device to access
the enterprise remotely using a VPN connection.
See results from B-1.1.
B-1.4.a Access Access Success: Users access RSS1 based on the EP
Successful Successful compliance with Forescout and Azure AD policy.
B-1.4.b Access Access Success: Users access RSS2 based on the EP
Successful Successful compliance with Forescout and Azure AD policy.
B-1.4.c Access Not Access Not Success: User authentication failure to Azure AD
Successful Successful prevents access.
B-1.4.d Access Not Access Not Success: E2 is not authorized to access RSS1 in
Successful Successful accordance with Azure AD policy.
B-1.4.e Access Access Success: Users access RSS2 based on the EP and
Successful Successful RSS compliance with Forescout and Azure AD
policy.
B-1.4.f, B-1.4.g Access Not Access Not Success: User authentication failure to Azure AD
Successful Successful prevents access.
B-1.4.h Access Access Success: Session timeout is set to one minute for
Successful Successful demonstration purposes. After session timed out,
user was re-authenticated to Azure AD.
B-1.4.i Access Not Access Not Success: Users were prevented from accessing
Successful Successful resources after re-authentication failure to Azure
AD.
B-1.4.j Access Not Access Not Success: Initial user authentication to Azure AD
Successful Successful was successful and user was granted access to
RSS1. After E1 became non-compliant, user access
to RSS1 was blocked in accordance with Forescout

NIST SP 1800-35D: Implementing a Zero Trust Architecture 102

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
policy, and the user was unable to re-authenticate
to Azure AD.
B-1.4.k Access Access Not Partial success: Initial user authentication to
Limited Successful Azure AD was successful and user was granted
access to RSS2. In this case, changing the user’s
access level on RSS2 would require application-
level control that is not available at this time.
After E1 became non-compliant, user access to
RSS2 was blocked in accordance with Forescout
policy, and the user was unable to re-authenticate
to Azure AD.
B-1.4.l Access Not Access Not Success: After E1 became non-compliant, user
Successful Successful access to RSS1 was blocked in accordance with
Forescout policy, and the user was unable to
authenticate to Azure AD.
B-1.4.m Access Access Not Partial success: In this case, changing the user’s
Limited Successful access level on RSS2 would require application-
level control that is not available at this time.
After E1 became non-compliant, user access to
RSS2 was blocked in accordance with Forescout
policy, and the user was unable to authenticate to
Azure AD.
B-1.4.n-p N/A N/A Demonstration cannot be performed as
verification of cloud resource compliance is not
available at this time.
B-1.5.a-p N/A N/A Demonstration cannot be performed as branch
office is not available at this time.
B-1.6.a-p In the current implementation, remote users are
connected to a VPN that routes network traffic
through the on-prem environment. All test results
are similar to B-1.4.a-p.
B-2.1.a-d,g,n Access Access Success: Access allowed in accordance with
Successful Successful Forescout policy.
B2.1.e,f,l,m,o,p Access Not Access Not Success: Access denied in accordance with
Successful Successful Forescout policy.
B-2.2 N/A N/A Demonstration cannot be performed as branch
office is not available at this time.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 103

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-2.3 In the current implementation, remote users are
connected to a VPN that routes network traffic
through the on-prem environment. All test results
are similar to B-2.1.a-p.
B-3.1.a, B-3.4.a, Real Req Real Req Success: Real Request successfully authenticated.
B-3.5.a Success Success
B-3.1.b, B-3.4.b, Real Req Fail Real Req Fail Success: Incorrect credentials were entered, and
B-3.5.b the Real Request failed as expected.
B-3.1.c, B-3.4.c, Limit Access N/A Unable to complete demonstration. Current build
B-3.5.c for Real does not have the capability to differentiate
Request, Deny between the Real Request and Hostile Request in
Access to this context.
Hostile
Request
B-3.1.d, B-3.4.d, Real Request N/A Unable to complete demonstration. Current build
B-3.5.d Keep Access, does not have the capability to differentiate
Deny Access between the Real Request and Hostile Request in
to Hostile this context.
Request
B-3.1.e, B-3.4.e, Hostile Hostile Success: Hostile Request successfully
B-3.5.e Request Request authenticated.
Successful Successful
B-3.1.f, B-3.4.f, Hostile Hostile Success: Incorrect credentials were entered, and
B-3.5.f Request Request the Hostile Request failed as expected.
Unsuccessful Unsuccessful
B-3.1.g, B-3.4.g, Real Request N/A Unable to complete demonstration. Current build
B-3.5.g Fail, Hostile does not have the capability to differentiate
Request between the Real Request and Hostile Request in
Access this context.
Limited
B-3.1.h, B-3.4.h, Real Request N/A Unable to complete demonstration. Current build
B-3.5.h Fail, Hostile does not have the capability to differentiate
Request between the Real Request and Hostile Request in
remains this context.
authenticated
B-3.1.i, B-3.4.i, Real Req Real Req Success: Real Request successfully authenticated.
B-3.5.i Success Success

NIST SP 1800-35D: Implementing a Zero Trust Architecture 104

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
B-3.1.j, B-3.4.j, Real Request N/A Unable to complete demonstration. Current build
B-3.5.j remains does not have the capability to differentiate
authenticated, between the Real Request and Hostile Request in
Hostile this context.
Request Fail
B-3.1.k, B-3.4.k, Hostile Hostile Success: Incorrect credentials were entered, and
B-3.5.k Request Fail Request Fail the Hostile Request failed as expected.
B-3.1.l, B-3.4.l, Real Request Real Success: Real Request successfully
B-3.5.l Access Request reauthenticated.
Successful Access
Successful
B-3.1.m, B- Hostile Hostile Success: Hostile Request reauthentication fails.
3.4.m, B-3.5.m Request Request
Access Denied Access
Denied
B-3.1.n, B-3.4.n, Hostile Hostile Success: Azure AD sessions terminated.
B-3.5.n Request Request
Session Session
Terminated Terminated
B-3.1.o, B-3.4.o, Real Request Real Success: Azure AD sessions terminated.
B-3.5.o Session Request
Terminated Session
Terminated
B-3.2, B-3.3 N/A N/A Branch office is not included in Build 3.
B-4 All demonstrations here are the same as B-1 since
the device is both authenticated and compliant.
B-5 All demonstrations here are the same as B-2 since
the device is both authenticated and compliant.
B-6 All demonstrations here are the same as B-3 since
the device is both authenticated and compliant.
All C Use Cases N/A N/A Demonstrations cannot be performed. Currently,
no federation configuration has been set up
between Ent1, Ent2, and Ent3.
All D Use Cases All demonstrations here are the same as B-1 since
the device is both authenticated and compliant.
Note that the user is a contractor.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 105

SECOND PRELIMINARY DRAFT

Demo ID Expected Observed Comments

Outcome Outcome
Access Access Success: Guests can access public resources and
E-1.1.a,b Successful Successful internet in accordance with policy.

E-1.2.a,b N/A N/A Demonstration cannot be performed as branch

office is not available at this time.
All F Use Cases N/A N/A Confidence level use cases are considered out of
scope for the EIG run phase.

NIST SP 1800-35D: Implementing a Zero Trust Architecture 106

 SECOND PRELIMINARY DRAFT

905 Appendix A List of Acronyms

AD Active Directory
API Application Programming Interface
BYOD Bring Your Own Device
CRADA Cooperative Research and Development Agreement
DNS Domain Name System
E1B1 Enterprise 1 Build 1
E1B2 Enterprise 1 Build 2
E2B1 Enterprise 2 Build 1
E2B2 Enterprise 2 Build 2
E3B1 Enterprise 3 Build 1
E3B2 Enterprise 3 Build 2
E4B1 Enterprise 4 Build 1
EIG Enhanced Identity Governance
EP Enterprise Endpoint
ICAM Identity, Credential, and Access Management
IP Internet Protocol
IT Information Technology
ITL Information Technology Laboratory
MFA Multifactor Authentication
MSV Mandiant Security Validation
NCCoE National Cybersecurity Center of Excellence
NIC Network Interface Card
NIST National Institute of Standards and Technology
OS Operating System
PEP Policy Enforcement Point

NIST SP 1800-35D: Implementing a Zero Trust Architecture 107

SECOND PRELIMINARY DRAFT

PIV Personal Identity Verification

PKI Public Key Infrastructure
RSS Enterprise Resource
SP Special Publication
UEM Unified Endpoint Management
UP User Profile
URL Uniform Resource Locator
VM Virtual Machine
VPN Virtual Private Network
ZCC Zscaler Client Connector
ZIA Zscaler Internet Access
ZPA Zscaler Private Access
ZTA Zero Trust Architecture

NIST SP 1800-35D: Implementing a Zero Trust Architecture 108

 SECOND PRELIMINARY DRAFT

906 Appendix B References

907 [1] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, National Institute of
908 Standards and Technology (NIST) Special Publication (SP) 800-207, Gaithersburg, Md., August
909 2020, 50 pp. Available: https://doi.org/10.6028/NIST.SP.800-207.

910 [2] P. Grassi, M. Garcia, and J. Fenton, Digital Identity Guidelines, National Institute of Standards
911 and Technology (NIST) Special Publication (SP) 800-63-3, Gaithersburg, Md., June 2017, 75 pp.
912 Available: https://doi.org/10.6028/NIST.SP.800-63-3.

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

NIST SP 1800-35D: Implementing a Zero Trust Architecture 109