2NIST Special Publication
NIST SP 800-63-4 2pd

3Digital Identity Guidelines

4

Second Public Draft

1

5
6
7
8
9
10
11
12

13
14

15

David Temoshok
Diana Proud-Madruga
Yee-Yin Choong
Ryan Galluzzo
Sarbari Gupta
Connie LaSalle
Naomi Lefkovitz
Andrew RegenscheidThis publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-63-4.2pd

17

NIST Special Publication
NIST SP 800-63-4 2pd

18

Digital Identity Guidelines

19

Second Public Draft

16

20
21
22
23
24
25

26
27
28

29
30
31

32
33
34

David Temoshok
Ryan Galluzzo
Connie LaSalle
Naomi Lefkovitz
Applied Cybersecurity Division
Information Technology Laboratory
Andrew Regenscheid
Computer Security Division
Information Technology Laboratory
Yee-Yin Choong
Information Access Division
Information Technology Laboratory
Diana Proud-Madruga
Sarbari Gupta
Electrosoft

36

This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-63-4.2pd

37

August 2024

35

38
39
40

41
42

U.S. Department of Commerce
Gina M. Raimondo, Secretary
National Institute of Standards and Technology
Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

43
44
45
46
47

48
49
50
51
52
53
54

Certain commercial entities, equipment, or materials may be identified in thisdocument in order to describe an experimental procedure or concept adequately. Such
identification is not intended to imply recommendation or endorsement by the National
Institute of Standards and Technology, nor is it intended to imply that the entities,
materials, or equipment are necessarily the best available for the purpose.
There may be references in this publication to other publications currently underdevelopment by NIST in accordance with its assigned statutory responsibilities. The
information in this publication, including concepts and methodologies, may be used byfederal agencies even before the completion of such companion publications. Thus, until
each publication is completed, current requirements, guidelines, and procedures, where
they exist, remain operative. For planning and transition purposes, federal agencies may
wish to closely follow the development of these new publications by NIST.

57

Organizations are encouraged to review all draft publications during public comment
periods and provide feedback to NIST. Many NIST cybersecurity publications, other thanthe ones noted above, are available at https://csrc.nist.gov/publications.

58

Authority

55
56

59
60
61
62
63
64
65
66

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

73

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

74

NIST Technical Series Policies

67
68
69
70
71
72

75
76

Copyright, Fair Use, and Licensing Statements
NIST Technical Series Publication Identifier Syntax

77

Publication History

79

Approved by the NIST Editorial Review Board on YYYY-MM-DD [will be added upon final
publication]

80

How to Cite this NIST Technical Series Publication

78

84

Temoshok D, Proud-Madruga D, Choong YY, Galluzzo R, Gupta S, LaSalle C, Lefkovitz
N, Regenscheid A (2024) Digital Identity Guidelines. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-63-4 2pd. https://doi.org/10.6028/NIST.SP.800-63-4.2pd

85

Author ORCID iDs

81
82
83

93

David Temoshok: 0000-0001-6195-0331
Diana Proud-Madruga: 0000-0002-8972-7809
Yee-Yin Choong: 0000-0002-3889-6047
Ryan Galluzzo: 0000-0003-0304-4239
Sarbari Gupta: 0000-0003-1101-0856
Connie LaSalle: 0000-0001-6031-7550
Naomi Lefkovitz: 0000-0003-3777-3106
Andrew Regenscheid: 0000-0002-3930-527X

94

Public Comment Period

95

August 21, 2024 - October 7, 2024

96

Submit Comments

97

mailto:dig-comments@nist.gov

98

Additional Information

86
87
88
89
90
91
92

100

Additional information about this publication is available at https://csrc.nist.gov/pubs/
sp/800/63/4/2pd, including related content, potential updates, and document history.

101

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

99

NIST SP 800-63-4 2pd
August 2024

102

Digital Identity Guidelines

Abstract

110

These guidelines cover identity proofing and authentication of users (such as employees,
contractors, or private individuals) interacting with government information systems
over networks. They define technical requirements in each of the areas of identity
proofing, registration, authenticators, management processes, authentication protocols,
federation, and related assertions. They also offer technical recommendations and otherinformative text intended as helpful suggestions. The guidelines are not intended toconstrain the development or use of standards outside of this purpose. This publication
supersedes NIST Special Publication (SP) 800-63-3.

111

Keywords

103
104
105
106
107
108
109

114

authentication; authentication assurance; authenticator; assertions; credential service
provider; digital authentication; digital credentials; identity proofing; federation;
passwords; PKI.

115

Reports on Computer Systems Technology

112
113

116
117
118
119
120
121
122
123
124
125
126

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

iNIST SP 800-63-4 2pd
August 2024

127

128
129
130
131
132
133
134
135
136

137
138
139
140

141
142
143
144
145

146
147
148
149

150
151
152
153

154
155
156
157

158
159
160
161
162

163
164

Digital Identity Guidelines

Note to Reviewers
In December 2022, NIST released the Initial Public Draft (IPD) of SP 800-63, Revision 4.
Over the course of a 119-day public comment period, the authors received exceptional
feedback from a broad community of interested entities and individuals. The input
from nearly 4,000 specific comments has helped advance the improvement ofthese Digital Identity Guidelines in a manner that supports NIST’s critical goals ofproviding foundational risk management processes and requirements that enable theimplementation of secure, private, equitable, and accessible identity systems. Based on
this initial wave of feedback, several substantive changes have been made across all of
the volumes. These changes include but are not limited to the following:
1. Updated text and context setting for risk management. Specifically, the authors
have modified the process defined in the IPD to include a context-setting step ofdefining and understanding the online service that the organization is offering andintending to potentially protect with identity systems.
2. Added recommended continuous evaluation metrics. The continuous
improvement section introduced by the IPD has been expanded to include a setof recommended metrics for holistically evaluating identity solution performance.
These are recommended due to the complexities of data streams and variances insolution deployments.
3. Expanded fraud requirements and recommendations. Programmatic fraud
management requirements for credential service providers and relying parties now
address issues and challenges that may result from the implementation of fraud
checks.
4. Restructured the identity proofing controls. There is a new taxonomy andstructure for the requirements at each assurance level based on the meansof providing the proofing: Remote Unattended, Remote Attended (e.g., video
session), Onsite Unattended (e.g., kiosk), and Onsite Attended (e.g., in-person).
5. Integrated syncable authenticators. In April 2024, NIST published interim guidance
for syncable authenticators. This guidance has been integrated into SP 800-63B asnormative text and is provided for public feedback as part of the Revision 4 volumeset.
6. Added user-controlled wallets to the federation model. Digital wallets andcredentials (called “attribute bundles” in SP 800-63C) are seeing increased
attention and adoption. At their core, they function like a federated IdP, generating
signed assertions about a subject. Specific requirements for this presentation andthe emerging context are presented in SP 800-63C-4.
The rapid proliferation of online services over the past few years has heightened theneed for reliable, equitable, secure, and privacy-protective digital identity solutions.
ii

NIST SP 800-63-4 2pd
August 2024

165
166
167
168
169
170
171

172
173
174

Digital Identity Guidelines

Revision 4 of NIST Special Publication SP 800-63, Digital Identity Guidelines, intends
to respond to the changing digital landscape that has emerged since the last majorrevision of this suite was published in 2017, including the real-world implications of
online risks. The guidelines present the process and technical requirements for meeting
digital identity management assurance levels for identity proofing, authentication, andfederation, including requirements for security and privacy as well as considerations forfostering equity and the usability of digital identity solutions and technology.
Based on the feedback provided in response to the June 2020 Pre-Draft Call forComments, research into real-world implementations of the guidelines, market
innovation, and the current threat environment, this draft seeks to:175• Address comments received in response to the IPD of Revision 4 of SP 800-63

176• Clarify the text to address the questions and issues raised in the public comments

177
178
179
180

181
182

183

184
185
186

187
188
189
190

191

192
193

194
195

196
197

198
199
200

• Update all four volumes of SP 800-63 based on current technology and market
developments, the changing digital identity threat landscape, and organizational
needs for digital identity solutions to address online security, privacy, usability, andequityNIST is specifically interested in comments and recommendations on the following
topics:
1. Risk Management and Identity Models• Is the “user controlled” wallet model sufficiently described to allow entities
to understand its alignment to real-world implementations of wallet-based
solutions such as mobile driver’s licenses and verifiable credentials?
• Is the updated risk management process sufficiently well-defined to support
an effective, repeatable, real-world process for organizations seeking to
implement digital identity system solutions to protect online services andsystems?
2. Identity Proofing and Enrollment• Is the updated structure of the requirements around defined types of
proofing sufficiently clear? Are the types sufficiently described?
• Are there additional fraud program requirements that need to be introduced
as a common baseline for CSPs and other organizations?
• Are the fraud requirements sufficiently described to allow for appropriatebalancing of fraud, privacy, and usability trade-offs?
• Are the added identity evidence validation and authenticity requirements
and performance metrics realistic and achievable with existing technology
capabilities?
iii

NIST SP 800-63-4 2pd
August 2024

201

202
203
204

205
206
207

208
209
210

211

212
213
214
215

216

217
218
219
220

221
222

223
224
225
226
227
228
229
230

Digital Identity Guidelines

3. Authentication and Authenticator Management• Are the syncable authenticator requirements sufficiently defined to allow forreasonable risk-based acceptance of syncable authenticators for public andenterprise-facing uses?
• Are there additional recommended controls that should be applied? Are
there specific implementation recommendations or considerations thatshould be captured?
• Are wallet-based authentication mechanisms and “attribute bundles”
sufficiently described as authenticators? Are there additional requirementsthat need to be added or clarified?
4. Federation and Assertions• Is the concept of user-controlled wallets and attribute bundles sufficiently
and clearly described to support real-world implementations? Are there
additional requirements or considerations that should be added to improve
the security, usability, and privacy of these technologies?
5. General• What specific implementation guidance, reference architectures, metrics,
or other supporting resources could enable more rapid adoption andimplementation of this and future iterations of the Digital Identity
Guidelines?
• What applied research and measurement efforts would provide the greatest
impacts on the identity market and advancement of these guidelines?
Reviewers are encouraged to comment and suggest changes to the text of all four draftvolumes of the SP 800-63-4 suite. NIST requests that all comments be submitted by
11:59pm Eastern Time on October 7th, 2024. Please submit your comments to digcomments@nist.gov. NIST will review all comments and make them available on the
NIST Identity and Access Management website. Commenters are encouraged to use thecomment template provided on the NIST Computer Security Resource Center website
for responses to these notes to reviewers and for specific comments on the text of the
four-volume suite.

iv

NIST SP 800-63-4 2pd
August 2024

231

232
233
234
235
236
237
238

239
240

241
242

243
244
245

246
247

248
249

250
251
252
253
254
255

Digital Identity Guidelines

Call for Patent Claims
This public review includes a call for information on essential patent claims (claims
whose use would be required for compliance with the guidance or requirements inthis Information Technology Laboratory (ITL) draft publication). Such guidance and/or
requirements may be directly stated in this ITL Publication or by reference to anotherpublication. This call also includes disclosure, where known, of the existence of pending
U.S. or foreign patent applications relating to this ITL draft publication and of any
relevant unexpired U.S. or foreign patents.
ITL may require from the patent holder, or a party authorized to make assurances on its
behalf, in written or electronic form, either:a) assurance in the form of a general disclaimer to the effect that such party does nothold and does not currently intend holding any essential patent claim(s); orb) assurance that a license to such essential patent claim(s) will be made available
to applicants desiring to utilize the license for the purpose of complying with theguidance or requirements in this ITL draft publication either:i. under reasonable terms and conditions that are demonstrably free of any
unfair discrimination; orii. without compensation and under reasonable terms and conditions that aredemonstrably free of any unfair discrimination.
Such assurance shall indicate that the patent holder (or third party authorized to makeassurances on its behalf) will include in any documents transferring ownership of patents
subject to the assurance, provisions sufficient to ensure that the commitments in theassurance are binding on the transferee, and that the transferee will similarly include
appropriate provisions in the event of future transfers with the goal of binding eachsuccessor-in-interest.

258

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

259

Such statements should be addressed to: mailto:dig-comments@nist.gov.

256
257

v

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

260

Table of Contents

261

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

1

262

1.1.

Scope and Applicability . . . . . . . . . . . . . . . . . . . . . . . . . .

2

263

1.2.

How to Use This Suite of SPs . . . . . . . . . . . . . . . . . . . . . . . .

3

264

1.3.

Enterprise Risk Management Requirements and Considerations . . . . .

4

265

1.3.1. Security, Fraud, and Threat Prevention . . . . . . . . . . . . . .

4

266

1.3.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

267

1.3.3. Equity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

268

1.3.4. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

269

1.4.

Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

270

1.5.

Document Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2. Digital Identity Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

271

272

2.1.

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

273

2.2.

Identity Proofing and Enrollment . . . . . . . . . . . . . . . . . . . . .

11

2.2.1. Subscriber Accounts . . . . . . . . . . . . . . . . . . . . . . . .

12Authentication and Authenticator Management . . . . . . . . . . . . .

12

276

2.3.1. Authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

277

2.3.2. Authentication Process . . . . . . . . . . . . . . . . . . . . . .

13

274

275

2.3.

278

2.4.

Federation and Assertions . . . . . . . . . . . . . . . . . . . . . . . . .

14

279

2.5.

Examples of Digital Identity Models . . . . . . . . . . . . . . . . . . . .

16

3. Digital Identity Risk Management . . . . . . . . . . . . . . . . . . . . . . . .

22

280

281

3.1.

Define the Online Service . . . . . . . . . . . . . . . . . . . . . . . . .

25

282

3.2.

Conduct Initial Impact Assessment . . . . . . . . . . . . . . . . . . . .

28

283

3.2.1. Identify Impact Categories and Potential Harms . . . . . . . . .

29

284

3.2.2. Identify Potential Impact Levels . . . . . . . . . . . . . . . . . .

30

285

3.2.3. Impact Analysis . . . . . . . . . . . . . . . . . . . . . . . . . .

32

286

3.2.4. Determine Combined Impact Level for Each User Group . . . . .

33

Select Initial Assurance Levels and Baseline Controls . . . . . . . . . . .

34

288

3.3.1. Assurance Levels . . . . . . . . . . . . . . . . . . . . . . . . . .

34

289

3.3.2. Assurance Level Descriptions . . . . . . . . . . . . . . . . . . .

35

287

3.3.

vi

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

290

3.3.3. Initial Assurance Level Selection . . . . . . . . . . . . . . . . . .

37

291

3.3.4. Identify Baseline Controls . . . . . . . . . . . . . . . . . . . . .

39

Tailor and Document Assurance Levels . . . . . . . . . . . . . . . . . .

40

293

3.4.1. Assess Privacy, Equity, Usability and Threat Resistance . . . . . .

41

294

3.4.2. Identify Compensating Controls . . . . . . . . . . . . . . . . . .

43

295

3.4.3. Identify Supplemental Controls . . . . . . . . . . . . . . . . . .

43

296

3.4.4. Digital Identity Acceptance Statement (DIAS) . . . . . . . . . . .

44

Continuously Evaluate and Improve . . . . . . . . . . . . . . . . . . . .

44

298

3.5.1. Evaluation Inputs . . . . . . . . . . . . . . . . . . . . . . . . . .

45

299

3.5.2. Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . .

45

300

3.5.3. Measurement in Support of Equity Assessments and Outcomes .

48

292

297

3.4.

3.5.

301

3.6.

Redress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

302

3.7.

Cybersecurity, Fraud, and Identity Program Integrity . . . . . . . . . . .

50

303

3.8.

Artificial Intelligence (AI) and Machine Learning (ML) in Identity Systems

50

304

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

305

Appendix A. List of Symbols, Abbreviations, and Acronyms . . . . . . . . . . . .

56

306

Appendix B. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

307

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

82

308

C.1.

SP 800-63-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

309

C.2.

SP 800-63-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

310

C.3.

SP 800-63-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

311

C.4.

SP 800-63-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

312

List of Tables

316

Table 1.
Table 2.
Table 3.
Table 4.

317

List of Figures

313
314
315

318
319

Fig. 1.
Fig. 2.

IAL Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AAL Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FAL Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . .

Sample Identity Proofing and Enrollment Digital Identity Model . . . . .
Sample Authentication Process . . . . . . . . . . . . . . . . . . . . . .
vii

35
36
37
46

11
14

NIST SP 800-63-4 2pd
August 2024

320
321
322

Fig. 3.
Fig. 4.
Fig. 5.

323
324

Fig. 6.

Digital Identity Guidelines

Non-Federated Digital Identity Model Example . . . . . . . . . . . . . .
Federated Digital Identity Model Example . . . . . . . . . . . . . . . . .
Federated Digital Identity Model with Subscriber-Controlled Wallet Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
High-level diagram of the Digital Identity Risk Management Process Flow

viii

17
18
20
26

NIST SP 800-63-4 2pd
August 2024

325

Digital Identity Guidelines

Preface328This publication and its companion volumes, [SP800-63A], [SP800-63B], and [SP800-63C],
provide technical guidelines to organizations for the implementation of digital identity
services.

329

Acknowledgments

326
327

330
331
332
333
334
335

The authors would like to thank their fellow collaborators — Christine Abruzzi, James
L. Fenton, and Justin P. Richer — on the current revision of this Special Publication, as
well as Kerrianne Buchanan for her contributions and review. The authors would also
like to acknowledge the past contributions of Donna F. Dodson, Elaine M. Newton, Ray
A. Perlner, W. Timothy Polk, Emad A. Nabbus, Paul A. Grassi, Michael E. Garcia, Kaitlin
Boeckl, Joni Brennan, Ellen Nadeau, Ben Piccareta, and Danna Gabel O’Rourke.

ix

NIST SP 800-63-4 2pd
August 2024

336

1. Introduction

337

This section is informative.

338
339
340
341
342
343
344
345
346
347
348
349
350
351
352

353
354
355
356
357
358
359
360
361
362
363
364
365
366

367
368
369
370
371
372
373
374

Digital Identity Guidelines

The rapid proliferation of online services over the past few years has heightened theneed for reliable, equitable, secure, and privacy-protective digital identity solutions. A
digital identity is always unique in the context of an online service. However, a person
may have multiple digital identities and while a digital identity may relay a unique andspecific meaning within the context of an online service, the real-life identity of theindividual behind the digital identity may not be known. When confidence in a person’s
real-life identity is not required to provide access to an online service, organizations may
use anonymous or pseudonymous accounts. In all other use cases, a digital identity isintended to demonstrate trust between the holder of the digital identity and the person,organization, or system on the other side of the online service. However, this process canpresent challenges. There are multiple opportunities for mistakes, miscommunication,
impersonation, and other attacks that fraudulently claim another person’s digital
identity. Additionally, given the broad range of individual needs, constraints, capacities,
and preferences, online services must be designed with equity, usability, and flexibility toensure broad and enduring participation and access to digital devices and services.
Digital identity risks are dynamic and exist along a continuum; consequently,
organizations’ digital identity risk management approach should seek to manage risks
using outcome-based approaches that are designed to meet the organization’s uniqueneeds. This guidance defines specific assurance levels which operate as baseline control
sets designed to provide a common point for organizations seeking to address identityrelated risks. Assurance levels provide multiple benefits, including a starting point foragencies in their risk management journey and a common structure for supportinginteroperability between different entities. It is, however, impractical to create assurance
levels that can comprehensively address the entire spectrum of risks, threats, or
considerations and organization will face when deploying an identity solution. For thisreason, these guidelines promote a risk-oriented approach to digital identity solution
implementation rather than a compliance-oriented approach, and organizations areencouraged to tailor their control implementations based on the processes defined inthese guidelines.
Additionally, risks associated with digital identity stretch beyond the potential impacts
to the organization providing online services. These guidelines endeavor to accountfor risks to individuals, communities, and other organizations more robustly andexplicitly. Organizations should consider how digital identity decisions that prioritize
security might affect, or need to accommodate, the individuals who interact with theorganization’s programs and services. Privacy, equity, and usability for individuals
should be considered along with security. Additionally, organizations should consider
their digital identity approach alongside other mechanisms for identity management,

1

NIST SP 800-63-4 2pd
August 2024

375
376
377
378
379

380
381
382
383
384

385
386
387
388
389
390
391
392
393
394
395
396

397
398
399
400
401

402
403
404
405

406
407
408
409
410
411
412

Digital Identity Guidelines

such as those used in call centers and in-person interactions. By taking a humancentric and continuously informed approach to mission delivery, organizations havean opportunity to incrementally build trust with the variety of populations they serve,
improve customer satisfaction, identify issues more quickly, and provide individuals with
culturally appropriate and effective redress options.
The composition, models, and availability of identity services has significantly changed
since the first version of SP 800-63 was released, as have the considerations andchallenges of deploying secure, private, usable, and equitable services to diverse user
communities. This revision addresses these challenges by clarifying requirements basedon the function that an entity may serve under the overall digital identity model.
Additionally, this publication provides instruction for credential service providers(CSPs), verifiers, and relying parties (RPs), that supplement the NIST Risk Management
Framework [NISTRMF] and its component special publications. It describes the risk
management processes that organizations should follow to implement digital identity
services and expands upon the NIST RMF by outlining how equity and usability
considerations should be incorporated. It also highlights the importance of considering
impacts, not only on enterprise operations and assets, but also on individuals, otherorganizations, and — more broadly — society. Furthermore, digital identity management
processes for identity proofing, authentication, and federation typically involve
processing personal information, which can present privacy risks. Therefore, theseguidelines include privacy requirements and considerations to help mitigate potential
associated privacy risks.
Finally, while these guidelines provide organizations with technical requirements andrecommendations for establishing, maintaining, and authenticating the digital identity ofsubjects who access digital systems over a network, additional support options outsideof the purview of information technology teams may be needed to address barriers andadverse impacts, foster equity, and successfully deliver on mission objectives.
1.1. Scope and Applicability
This guidance applies to all online services for which some level of digital identity
is required, regardless of the constituency (e.g., residents, business partners, andgovernment entities). For this publication, “person” refers only to natural persons.
These guidelines primarily focus on organizational services that interact with external
users, such as residents accessing public benefits or private-sector partners accessing
collaboration spaces. However, it also applies to federal systems accessed by employees
and contractors. The Personal Identity Verification (PIV) of Federal Employees andContractors standard [FIPS201] and its corresponding set of Special Publications andorganization-specific instructions extend these guidelines for the federal enterprise,by providing additional technical controls and processes for issuing and managing

2

NIST SP 800-63-4 2pd
August 2024

413
414

415
416
417
418

419
420
421
422
423
424
425

426
427
428
429
430
431
432
433

434
435

Digital Identity Guidelines

Personal Identity Verification (PIV) Cards, binding additional authenticators as derived
PIV credentials, and using federation architectures and protocols with PIV systems.
Online services not covered by this guidance include those associated with national
security systems as defined in 44 U.S.C. § 3552(b)(6). Private-sector organizations andstate, local, and tribal governments whose digital processes require varying levels ofdigital identity assurance may consider the use of these standards where appropriate.
These guidelines address logical access to online systems, services, and applications.
They do not specifically address physical access control processes. However, theprocesses specified in these guidelines can be applied to physical access use cases whereappropriate. Additionally, these guidelines do not explicitly address some subjects
including, but not limited to, machine-to-machine authentication, interconnected
devices (e.g., Internet of Things (IoT) devices), or access to Application Programming
Interfaces (APIs) on behalf of subjects.
1.2. How to Use This Suite of SPs
These guidelines support the mitigation of the negative impacts of errors that occur
during the identity system functions of identity proofing, authentication, and federation.
Sec. 3, Digital Identity Risk Management, provides details on the risk assessment process
and how the results of the risk assessment and additional context inform the selectionof controls to secure the identity proofing, authentication, and federation processes.
Controls are selected by determining the assurance level required to mitigate eachapplicable type of digital identity error for a particular service based on risk and mission.
Specifically, organizations are required to individually select assurance levels1 that
correspond to each function being performed:

436• Identity Assurance Level (IAL) refers to the identity proofing process.

437• Authentication Assurance Level (AAL) refers to the authentication process.

438
439

440

441
442
443
444

445
446
447

• Federation Assurance Level (FAL) refers to the federation process when the RP isconnected to a CSP or an IdP through a federated protocol.
SP 800-63 is organized as the following suite of volumes:• SP 800-63 Digital Identity Guidelines provides the digital identity models, risk
assessment methodology, and process for selecting assurance levels for identity
proofing, authentication, and federation. SP 800-63 contains both normative andinformative material.
• [SP800-63A]: provides requirements for identity proofing and the enrollment ofapplicants, either remotely or in-person, that wish to gain access to resourcesat each of the three IALs. It details the responsibilities of CSPs with respect to
1 When described generically or bundled, these guidelines will refer to IAL, AAL, and FAL as xAL.

3

NIST SP 800-63-4 2pd
August 2024

448
449
450
451
452
453
454
455
456
457
458
459
460
461
462

463
464
465
466
467
468
469

470
471
472
473
474
475
476
477
478

479
480
481
482

483
484
485

Digital Identity Guidelines

establishing and maintaining subscriber accounts and binding CSP issued or
subscriber-provided authenticators to the subscriber account. SP 800-63A contains
both normative and informative material.
• [SP800-63B] provides requirements for authentication processes, including choices
of authenticators, that may be used at each of the three AALs. It also provides
recommendations on events that may occur during the lifetime of authenticators,
including invalidation in the event of loss or theft. SP 800-63B contains bothnormative and informative material.
• [SP800-63C] provides requirements on the use of federated identity architectures
and assertions to convey the results of authentication processes and relevant
identity information to an agency application. This volume offers privacyenhancing techniques for sharing information about a valid, authenticated subject,and describes methods that allow for strong multi-factor authentication (MFA)
while the subject remains pseudonymous to the online service. SP 800-63C
contains both normative and informative material.
1.3. Enterprise Risk Management Requirements and Considerations
Effective enterprise risk management is multidisciplinary by design and involves
the consideration of diverse sets of factors and equities. In a digital identity risk
management context, these factors include, but are not limited to, information security,
privacy, equity, and usability. It is important for risk management efforts to weighthese factors as they relate to enterprise assets and operations, individuals, otherorganizations, and society.
During the process of analyzing factors relevant to digital identity, organizations may
determine that measures outside of those specified in this publication are appropriate
in certain contexts (e.g., where privacy or other legal requirements exist or where
the output of a risk assessment leads the organization to determine that additional
measures or alternative procedural safeguards are appropriate). Organizations, including
federal agencies, may employ compensating or supplemental controls that are notspecified in this publication. They may also consider partitioning the functionality ofan online service to allow less sensitive functions to be available at a lower level ofassurance in order to improve equity and access without compromising security.
The considerations detailed below support enterprise risk management efforts andencourage informed, inclusive, and human-centered service delivery. While this list of
considerations is not exhaustive, it highlights a set of cross-cutting factors that are likely
to impact decision-making associated with digital identity management.
1.3.1. Security, Fraud, and Threat Prevention
It is increasingly important for organizations to assess and manage digital identity
security risks, such as unauthorized access due to impersonation. As organizations
4

NIST SP 800-63-4 2pd
August 2024

486
487
488
489

490
491
492
493
494
495

496
497
498
499
500
501
502
503

504
505
506

507
508
509
510
511
512
513
514
515
516
517
518
519

520
521
522
523
524

Digital Identity Guidelines

consult this guidance, they should consider potential impacts to the confidentiality,
integrity, and availability of information and information systems that they manage andthat their service providers and business partners manage on behalf of the individuals
and communities that they serve.
Federal agencies implementing these guidelines are required to meet statutory
responsibilities, including those under the Federal Information Security Modernization
Act (FISMA) of 2014 [FISMA] and related NIST standards and guidelines. NIST
recommends that non-federal organizations implementing these guidelines follow
comparable standards (e.g., ISO 27001) to ensure the secure operation of their digitalsystems.
FISMA requires federal agencies to implement appropriate controls to protect federal
information and information systems from unauthorized access, use, disclosure,disruption, or modification. The NIST RMF [NISTRMF] provides a process that integrates
security, privacy, and cyber supply-chain risk management activities into the systemdevelopment life cycle. It is expected that federal agencies and organizations thatprovide services under these guidelines have already implemented the controls andprocesses required under FISMA and associated NIST risk management processes andpublications.
The controls and requirements encompassed by the identity, authentication, andFederation Assurance Levels under these guidelines augment, but do not replace or alter,
the information and information system controls determined under FISMA and the RMF.
It is increasingly important for organizations to assess and manage identity-related fraudrisks associated with identity proofing and authentication processes. As organizations
consult this guidance, they should consider the evolving threat environment, theavailability of innovative anti-fraud measures in the digital identity market, and thepotential impact of identity-related fraud. This is particularly important with respect topublic-facing online services where the impact of identity-related fraud on e-government
service delivery, public trust, and agency reputation can be substantial. This version
enhances measures to combat identity theft and identity-related fraud by repurposing
IAL1 as a new assurance level, updating authentication risk and threat models to accountfor new attacks, providing new options for phishing resistant authentication, introducing
requirements to prevent automated attacks against enrollment processes, and preparing
for new technologies (e.g., mobile driver’s licenses and verifiable credentials) that canleverage strong identity proofing and authentication.
1.3.2. Privacy
When designing, engineering, and managing digital identity systems, it is imperative toconsider the potential of that system to create privacy-related problems for individuals
when processing (e.g., collection, storage, use, and destruction) personally identifiable
information (PII) and the potential impacts of problematic data actions. If a breach of5

NIST SP 800-63-4 2pd
August 2024

525
526
527

528
529
530
531

532
533
534

535
536
537

538
539
540
541

542
543
544

545
546
547
548

549
550
551
552

553
554
555
556
557
558
559
560
561

Digital Identity Guidelines

PII or a release of sensitive information occurs, organizations need to ensure that theprivacy notices describe, in plain language, what information was improperly released
and, if known, how the information was exploited.
Organizations need to demonstrate how organizational privacy policies and system
privacy requirements have been implemented in their systems. These guidelines
recommend that organizations employ the full set of legal and regulatory mandates that
may affect their users and technology providers including:• The NIST Privacy Framework [NISTPF], which enables privacy engineering
practices that support privacy by design concepts and helps organizations protect
individuals’ privacy.
• The [PrivacyAct] of 1974, 2020 Edition which established a set of fair information
practices for the collection, maintenance, use, and disclosure of information about
individuals that is maintained by federal agencies in systems of records.
• OMB Guidance for Implementing the Privacy Provisions of the E-Government Act
of 2002 [M-03-22], which describes the Privacy Impact Assessments that aresupported by the privacy risk assessments that are required for PII processing or
storing.
• [SP800-53] Security and Privacy Controls for Information Systems andOrganizations , which lists privacy controls that can be implemented to mitigate
the risks identified in the privacy risk and impact assessments.
• [SP800-122] Guide to Protecting the Confidentiality of Personally Identifiable
Information (PII), which assists federal agencies in understanding what PII is, therelationship between protecting the confidentiality of PII, privacy, and the Fair
Information Practices, and safeguards for protecting PII.
Furthermore, each volume of SP 800-63, ([SP800-63A], [SP800-63B], and [SP800-63C])
contains a specific section providing detailed privacy guidance and considerations for the
implementation of the processes, controls, and requirements presented in that volume
as well as normative requirements on data collection, retention, and minimization.
1.3.3. Equity
Equity has been defined as “the consistent and systematic fair, just, and impartial
treatment of all individuals, including individuals who belong to underserved
communities that have been denied such treatment” [EO13985]. Incorporating equity
considerations when designing or operating a digital identity service helps ensure
a person’s ability to engage in an online service, such as accessing a critical service
like healthcare. Accessing online services is often dependent on a person’s ability topresent a digital identity and use the required technologies successfully and safely. Many
populations are either unable to successfully present a digital identity or face a higher
6

NIST SP 800-63-4 2pd
August 2024

562
563
564
565
566

567
568
569
570
571
572
573

574
575
576
577
578
579
580

581
582
583
584
585
586

587
588
589
590
591
592
593
594
595
596

597
598

Digital Identity Guidelines

degree of burden in navigating online services than their more privileged peers. In apublic service context, this poses a direct risk to successful mission delivery. In a broader
societal context, challenges related to digital access can exacerbate existing inequities
and continue systemic cycles of exclusion for historically marginalized and underserved
groups.
To support the continuous evaluation and improvement program described in Sec. 3, it
is important to maintain awareness of existing inequities faced by served populations
and potential new inequities or disparities between populations that could be caused or
exacerbated by the design or operation of digital identity systems. This can help identify
the opportunities, processes, business partners, and multi-channel identity proofing andservice delivery methods that best support the needs of those populations while also
managing privacy, security, and fraud risks.
Further, section 508 of the Rehabilitation Act of 1973 (2011) [Section508] was enacted
to eliminate barriers in information technology and require federal agencies to makeelectronic and information technologies accessible to people with disabilities. Whilethese guidelines do not directly assert requirements from [Section508], federal agencies
and their identity service providers are expected to design online services and systems
with the experiences of people with disabilities in mind to ensure that accessibility isprioritized.
1.3.4. Usability
Usability refers to the extent to which a system, product, or service can be used toachieve goals with effectiveness, efficiency, and satisfaction in a specified context of use.
Usability also supports major objectives such as equity, service delivery, and security.
Like equity, usability requires an understanding of the people who interact with a digital
identity system or process, as well as their unique goals and context of use.
Readers of this guidance should take a holistic approach to considering the interactions
that each user will engage in throughout the process of enrolling in and authenticating
to a service. Throughout the design and development of a digital identity systemor process, it is important to conduct usability evaluations with demographically
representative users, from all communities served and perform realistic scenarios andtasks in appropriate contexts of use. Additionally, following usability guidelines andconsiderations can help organizations meet customer experience goals articulated infederal policy [EO14058]. Digital identity management processes should be designed andimplemented so that it is easy for users to do the right thing, hard to do the wrong thing,and easy to recover when the wrong thing happens.
1.4. Notations
This guideline uses the following typographical conventions in text:

7

NIST SP 800-63-4 2pd
August 2024

599
600

601
602
603

604
605
606
607
608

609
610

611
612
613

Digital Identity Guidelines• Specific terms in CAPITALS represent normative requirements. When these sameterms are not in CAPITALS , the term does not represent a normative requirement.
– The terms “ SHALL ” and “ SHALL NOT ” indicate requirements to be followed
strictly in order to conform to the publication and from which no deviation ispermitted.
– The terms “ SHOULD ” and “ SHOULD NOT ” indicate that among several
possibilities, one is recommended as particularly suitable without mentioning
or excluding others, that a certain course of action is preferred but notnecessarily required, or that (in the negative form) a certain possibility or
course of action is discouraged but not prohibited.
– The terms “ MAY ” and “ NEED NOT ” indicate a course of action that ispermissible within the limits of the publication.
– The terms “ CAN ” and “ CANNOT ” indicate a material, physical, or causal
possibility and capability or — in the negative — the absence of thatpossibility or capability.

8

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines616

1.5. Document StructureThis document is organized as follows. Each section is labeled as either normative (i.e.,
mandatory for compliance) or informative (i.e., not mandatory).

617• Section 1 provides an introduction to the document. This section is informative.

618• Section 2 describes a general model for digital identity. This section is informative.

619• Section 3 describes the digital identity risk model. This section is normative.

614
615

620
621

622
623

624
625

626
627

• The References section contains a list of publications that are cited in thisdocument. This section is informative.
• Appendix A contains a selected list of abbreviations used in this document. Thisappendix is informative.
• Appendix B contains a glossary of selected terms used in this document. Thisappendix is informative.
• Appendix C contains a summarized list of changes in this document’s history. Thisappendix is informative.

9

NIST SP 800-63-4 2pd
August 2024

628

2. Digital Identity Model

629

This section is informative.

630
631
632
633
634
635
636

637
638

639

Digital Identity Guidelines

2.1. Overview
The SP 800-63 guidelines use digital identity models that reflect technologies andarchitectures that already currently available in the market. These models have a varietyof entities and functions and vary in complexity. Simple models group functions, suchas creating subscriber accounts and providing attributes, under a single entity. Morecomplex models separate these functions among a larger number of entities. The
entities, and their associated functions, found in digital identity models include:
Subject: In these guidelines, a subject is a person and is represented by one of threeroles, depending on where they are in the digital identity process.
• Applicant — The subject to be identity-proofed and enrolled.

642• Subscriber — - The subject who has successfully completed the identity proofingand enrollment process or authentication (i.e., when the subject is in an active online session).

643• Claimant — The subject “making a claim” to be eligible for authentication.

640
641

644
645
646

647
648
649
650
651

652
653
654
655

656
657
658
659

660
661

Service provider: Service providers can perform any combination of functions involvedin granting access to and delivering online services, such as a credential service provider,relyin party, verifier, and Identity provider.
Credential service provider (CSP): CSP functions include identity proofing applicants tothe identity service and registering authenticators to subscriber accounts. A subscriber
account is the CSP’s established record of the subscriber, the subscriber’s attributes, andassociated authenticators. CSP functions may be performed by an independent third
party.
Relying party (RP): RP functions rely on the information in the subscriber accountfrom the CSP, typically to process a digital transaction or grant access to information
or a system. When using federation, the RP accesses the information in the subscriber
account through assertions from an identity provider.
Verifier: The function of a verifier is to verify the claimant’s identity by verifying theclaimant’s possession and control of one or more authenticators using an authentication
protocol. To do this, the verifier needs to confirm the binding of the authenticators withthe subscriber account and check that the subscriber account is active.
Identity provider (IdP): When using federation, the IdP manages the subscriber’s
primary authenticators and issues assertions derived from the subscriber account.

10

NIST SP 800-63-4 2pd
August 2024

662
663

Digital Identity Guidelines

2.2. Identity Proofing and Enrollment
Normative requirements can be found in [SP800-63A], Identity Proofing and Enrollment.

665[SP800-63A] provides general information and normative requirements for the identity
proofing and enrollment processes as well as requirements that are specific to IALs.

666

Figure 1 shows a sample of interactions for identity proofing and enrollment.

664

667
668
669
670
671

672
673

To start, an applicant opts to enroll with a CSP by requesting access. The CSP or theentity fulfilling CSP functions requests identity evidence and attributes, which theapplicant provides. If the applicant is successfully identity-proofed, they are enrolled
in the identity service as a subscriber of that CSP. A unique subscriber account is thencreated and one or more authenticators are registered to the subscriber account.
Subscribers have a responsibility to maintain control of their authenticators (e.g., guard
against theft) and comply with CSP policies to remain in good standing with the CSP.

Subject

Applicant

CSP

Request Access

Request Identity Evidence and Attributes

Submit Identity Evidence and Attributes

Subscriber

Identity Service Enrollment• ID Proofing• CSP Subscriber
Account Creation• Enrollment Process

Fig. 1. Sample Identity Proofing and Enrollment Digital Identity Model

11

NIST SP 800-63-4 2pd
August 2024

674
675
676
677

Digital Identity Guidelines

2.2.1. Subscriber Accounts
At the time of enrollment, the CSP establishes a subscriber account to uniquely identify
each subscriber and record any authenticators registered (bound) to that subscriber
account. The CSP may:679

• Issue and register one or more authenticators to the subscriber at the time ofenrollment,

680• Register authenticators provided by the subscriber to the subscriber account,

678

681
682

683
684

685
686

687
688
689

• Register additional authenticators to the subscriber account at a later time asneeded, or• Provision the subscriber account to one or more general-purpose or subscribercontrolled wallets, for use in a federated protocol system.
See Sec. 5 of [SP800-63A], Subscriber-Accounts, for more information and normativerequirements.
2.3. Authentication and Authenticator Management
Normative requirements can be found in [SP800-63B], Authentication and Authenticator
Management.

693

2.3.1. Authenticators[SP800-63B] provides normative descriptions of permitted authenticator types, theircharacteristics (e.g., phishing resistance), and authentication processes appropriate foreach AAL.

694

This guidance defines three types of authentication factors used for authentication:

690
691
692

695

• Something you know (e.g., a password)696• Something you have (e.g., a device containing a cryptographic key)697

• Something you are (e.g., a fingerprint or other biometric characteristic data)

698
699
700
701
702

703
704
705
706
707

Single-factor authentication requires only one of the above factors, most often“something you know”. Multiple instances of the same factor still constitute single-factor
authentication. For example, a user-generated PIN and a password do not constitute two
factors as they are both “something you know.” Multi-factor authentication (MFA) refers
to the use of more than one distinct factor.
This guidance specifies that authenticators always contain or comprise a secret. The
secrets contained in an authenticator are based on either key pairs (i.e., asymmetric
cryptographic keys) or shared secrets (including symmetric cryptographic keys, seeds
for generating one-time passwords (OTP), and passwords). Asymmetric key pairs arecomprised of a public key and a related private key. The private key is stored on the
12

NIST SP 800-63-4 2pd
August 2024

708
709
710
711
712
713
714
715
716

717
718
719
720
721
722

723
724
725
726
727
728

729
730
731
732

733
734

735
736
737
738
739

740
741
742
743
744
745

Digital Identity Guidelines

authenticator and is only available for use by the claimant who possesses and controls
the authenticators. A verifier that has the subscriber’s public key (e.g., through apublic key certificate) can use an authentication protocol to verify that the claimant is
a subscriber who has possession and control of the associated private key containedin the authenticator. Symmetric keys are generally chosen at random, complex andlong enough to thwart network-based guessing attacks, and stored in hardware orsoftware that the subscriber controls. Passwords typically have fewer characters andless complexity than cryptographic keys resulting in increased vulnerabilities that require
additional defenses to mitigate.
Passwords used as activation factors for multi-factor authenticators are referred toas activation secrets. An activation secret is used to decrypt a stored key used forauthentication or is compared against a locally held and stored verifier to provide accessto the authentication key. In either of these cases, the activation secret remains within
the authenticator and its associated user endpoint. An example of an activation secretwould be the PIN used to activate a PIV card.
Biometric characteristics are unique, personal attributes that can be used to verify
the identity of a person who is physically present at the point of authentication. This
includes, but is not limited to, facial features, fingerprints, and iris patterns. Whilebiometric characteristics cannot be used for single-factor authentication, they canbe used as an authentication factor for multi-factor authentication when used in
combination with a physical authenticator (i.e., something you have).
Some authentication methods used for in-person interactions do not apply directly todigital authentication. For example, a physical driver’s license is something you have andmay be useful when authenticating to a human (e.g., a security guard), but it is not anauthenticator for online services.
Some commonly used authentication methods do not contain or comprise secrets andare therefore not acceptable for use under these guidelines. For example:• Knowledge-based authentication, where the claimant is prompted to answer
questions that are presumably known only by the claimant, does not constitutean acceptable secret for digital authentication.
• A biometric characteristic does not constitute a secret and cannot be used as asingle-factor authenticator.
2.3.2. Authentication Process
The authentication process enables an RP to trust that a claimant is who they say theyare. Some approaches are described in [SP800-63B], Authentication and Authenticator
Management. The sample authentication process in Fig. 2 shows interactions between
the RP, a claimant, and a verifier/CSP. The verifier is a functional role and is frequently
implemented in combination with the CSP, the RP, or both (as shown in Fig. 4).
13

NIST SP 800-63-4 2pd
August 2024

Subject

Digital Identity Guidelines

RP

Verifier

Request Authentication

Claimant
Submit authenticator output

VerifyAuthenticator
OutputReturn Authentication Result

Open Authenticated Session

Subscriber

Fig. 2. Sample Authentication Process

746
747
748
749
750
751
752
753

754
755
756
757
758

759
760

761
762

A successful authentication process demonstrates that the claimant has possession andcontrol of one or more valid authenticators that are bound to the subscriber’s identity.
In general, this is done using an authentication protocol that involves an interaction
between the verifier and the claimant. The exact nature of the interaction is extremely
important in determining the overall security of the system. Well-designed protocols canprotect the integrity and confidentiality of communication between the claimant and theverifier both during and after the authentication and can help limit the damage done by
an attacker masquerading as a legitimate verifier.
Additionally, mechanisms located at the verifier can mitigate online guessing attacks
against lower entropy secrets (e.g., passwords and PINs) by limiting the rate at which an
attacker can make authentication attempts, or otherwise delaying incorrect attempts.
Generally, this is done by keeping track of and limiting the number of unsuccessfulattempts, since the premise of an online guessing attack is that most attempts will fail.
2.4. Federation and Assertions
Normative requirements can be found in [SP800-63C], Federation and Assertions.
Section III of OMB [M-19-17] Enabling Mission Delivery through Improved Identity,
Credential, and Access Management directs agencies to support cross-government
14

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

768

identity federation and interoperability. The term federation can be applied to several
different approaches that involve the sharing of information between different trust
domains. These approaches differ based on the kind of information that is being shared
between the domains. These guidelines address the federation processes that allow for
the conveyance of identity and authentication information based on trust agreements
across a set of networked systems through federation assertions.

769

There are many benefits to using federated architectures including, but not limited to:

763
764
765
766
767

770
771

772
773
774

775
776

777
778

779
780

781
782
783
784

• Enhanced user experience (e.g., a subject can be identity proofed once but theirsubscriber account used at multiple RPs).
• Cost reduction to both the subscriber (e.g., reduction in authenticators) andthe organization (e.g., reduction in information technology infrastructure and a
streamlined architecture).
• Minimizing data in RPs that do not need to collect, store, or dispose of personal
information.
• Minimizing data exposed to RPs by using pseudonymous identifiers and derived
attribute values instead of copying account values to each application.
• Mission enablement, since organizations will need to focus fewer resources oncomplex identity management processes.
While the federation process is generally the preferred approach to authentication
when the RP and IdP are not administered together under a common security domain,
federation can also be applied within a single security domain for a variety of benefits
including centralized account management and technical integration.

791

The SP 800-63 guidelines are agnostic to the identity proofing, authentication, andfederation architectures that an organization selects, and they allow organizations to
deploy a digital identity scheme according to their own requirements. However, there
are scenarios that an organization may encounter that make federation potentiallymore efficient and effective than establishing identity services that are local to theorganization or individual applications. The following lists detailed potential scenarios
in which the organization may consider federation to be a viable option:

792• Potential users already have an authenticator at or above the required AAL.

785
786
787
788
789
790

793
794

795
796
797

798
799

• Multiple types of authenticators are required to cover all possible user
communities.
• An organization does not have the necessary infrastructure to support
management of subscriber accounts (e.g., account recovery, authenticatorissuance, help desk).
• There is a desire to allow primary authenticators to be added and upgraded overtime without changing the RP’s implementation.
15

NIST SP 800-63-4 2pd
August 2024

800
801
802

803
804

805
806

807
808

Digital Identity Guidelines• There are different environments to be supported, since federation protocols are
network-based and allow for implementation on a wide variety of platforms andlanguages.
• Potential users come from multiple communities, each with its own existing
identity infrastructure.
• The organization needs the ability to centrally manage account lifecycles, including
account revocation and the binding of new authenticators.
An organization may want to consider accepting federated identity attributes if any of
the following apply:

810• Pseudonymity is required, necessary, feasible, or important to stakeholders
accessing the service.

811• Access to the service requires a defined list of attributes.

812• Access to the service requires at least one derived attribute value.

809

813
814

815
816

817
818
819
820
821

822
823
824
825

826
827

828
829

830
831
832
833

• The organization is not the authoritative source or issuing source for required
attributes.
• Attributes are only required temporarily during use (e.g., to make an accessdecision), and the organization does not need to retain the data.
2.5. Examples of Digital Identity Models
The entities and interactions that comprise the non-federated digital identity model areillustrated in Fig. 3. The general-purpose federated digital identity model is illustrated
in Fig. 4, and a federated digital identity model with a subscriber-controlled wallet is
illustrated in Fig. 5.
Figure 3 shows an example of a common sequence of interactions in the non-federated
model. Other sequences could also achieve the same functional requirements. One
common sequence of interactions for identity proofing and enrollment activities is asfollows:• Step 1: An applicant applies to a CSP through an identity proofing and enrollment
process. The CSP identity proofs that applicant.
• Step 2: Upon successful identity proofing, the applicant is enrolled in the identity
service as a subscriber.
– A subscriber account and corresponding authenticators are establishedbetween the CSP and the subscriber. The CSP maintains the subscriber
account, its status, and the enrollment data. The subscriber maintains theirauthenticators.

16

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

5

Subject

AuthenticatedSessionSubject Roles

1
Identity Proofing
and Enrollment

Applicant3

Subscriber

Authentication
RequestRP

Claimant

42

Authentication
Process

Verifier

Authenticator
Enrollment / Issuance

CSP

Fig. 3. Non-Federated Digital Identity Model Example

834
835
836

837
838

839
840

841
842
843

844
845
846

847

Steps 3 through 5 may immediately follow steps 1 and 2 or they may be done at a latertime. The usual sequence of interactions involved in using one or more authenticators to
perform digital authentication in the non-federated model is as follows:• Step 3: The claimant initiates an online interaction with the RP and the RP
requests that the claimant authenticate.
• Step 4: The claimant proves possession and control of the authenticators to theverifier through an authentication process:– The verifier interacts with the CSP to verify the binding of the claimant’s
identity to their authenticators in the subscriber account and to optionallyobtain additional subscriber attributes.
– The CSP or verifier functions of the service provider give information about
the subscriber. The RP requests the attributes it requires from the CSP. The
RP optionally uses this information to make authorization decisions.
• Step 5: An authenticated session is established between the subscriber and the RP.
17

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

6

AuthenticatedSessionSubject

3

Subject Roles

5

Federation
RequestApplicant1

RP

Federation
ProtocolSubscriber

Identity Proofing
and Enrollment

IdP

Claimant

42

Authentication
Process

Verifier

Authenticator
Enrollment / Issuance

CSP
Subscriber
Accounts

Fig. 4. Federated Digital Identity Model Example

848

849
850

851
852

853
854

855
856
857
858
859
860
861

Figure 4 shows an example of those same common interactions in a federated model.
• Step 1: An applicant applies to a CSP through an identity proofing and enrollment
process. The CSP identity proofs that applicant.
• Step 2: Upon successful identity proofing, the applicant is enrolled in the identity
service as a subscriber.
– A subscriber account and corresponding authenticators are establishedbetween the CSP and the subscriber.
– Unlike in Fig. 3, the IdP is provisioned either directly by the CSP or indirectly
through access to attributes of the subscriber account. The CSP maintains
the subscriber account, its status, and the enrollment data collected inaccordance with the record retention and disposal requirements described inSec. 3.1.1 of [SP800-63A]. The subscriber maintains their authenticators. The
IdP maintains its view of the subscriber account, any federated identifiers
assigned to the subscriber account, and authorizations to RPs.

18

NIST SP 800-63-4 2pd
August 2024

862
863

864
865

866
867

868
869
870

Digital Identity Guidelines

The usual sequence of interactions involved in using one or more authenticators in thefederated model to perform digital authentication is as follows:• Step 3: The RP requests that the claimant authenticate. This triggers a request for
federated authentication to the IdP.
• Step 4: The claimant proves possession and control of the authenticators to theverifier function of the IdP through an authentication process.
– Within the IdP, the verifier and CSP functions interact to verify the bindingof the claimant’s authenticators with those bound to the claimed subscriber
account and optionally to obtain additional subscriber attributes.

876• Step 5: The RP and the IdP communicate through a federation protocol. The IdPprovides an assertion and optionally additional attributes to the RP through afederation protocol. The RP verifies the assertion to establish confidence in theidentity and attributes of a subscriber for an online service at the RP. RPs may use
a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL,
FAL, and other factors to make authorization decisions.

877• Step 6: An authenticated session is established between the subscriber and the RP.

871
872
873
874
875

878
879
880
881
882
883
884
885

In the two cases described in Fig. 3 and Fig. 4, the verifier does not always need tocommunicate in real time with the CSP to complete the authentication activity (e.g.,
digital certificates can be used). Therefore, the line between the verifier and the CSP
represents a logical link between the two entities. In some implementations, the verifier,RP, and CSP functions may be distributed and separated. However, if these functions
reside on the same platform, the interactions between the functions are signals between
applications or application modules that run on the same system rather than using
network protocols.

892

Figure 5 shows an example of the interactions in a federated digital identity model inwhich the subscriber controls a device with software (i.e., a digital wallet) that acts as
the IdP. In the terminology of the “three-party model”, the CSP is the issuer, the IdP is
the holder, and the RP is the verifier. In this model, it is common for the RP to establish
a trust agreement with the CSP through the use of a federation authority as defined in[SP800-63C]. This arrangement allows the RP to accept assertions from the subscribercontrolled wallet without needing a direct trust relationship with the wallet.

893• Step 1: An applicant applies to a CSP identity proofing and enrollment process.

886
887
888
889
890
891

895

• Step 2: Upon successful identity proofing, the applicant goes through an
onboarding process and is enrolled in the identity service as a subscriber.

896• Step 3: The subscriber-controlled wallet is onboarded by the CSP.

894

897

– The subscriber authenticates to the CSP’s onboarding function.

19

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

AuthenticatedSession7
Subject

Federation
RequestApplicant1
Identity Proofing
and Enrollment

RP

4

Subject Roles

6
Federation
ProtocolSubscriber
Claimant
SubscriberControlled
Wallet5 Activation
3

IdP Onboarding Process

2 Onboarding Process

CSP

Verifier

Fig. 5. Federated Digital Identity Model with Subscriber-Controlled Wallet Example

898
899

900
901

902
903

904
905

906
907

908
909

910

– The subscriber activates the subscriber-controlled wallet using an activation
factor.
– The wallet sends a request to the CSP, including proof of a key held by thewallet.
– The CSP creates an attribute bundle that contains a reference for the key of
the wallet and any additional attributes.
The usual sequence of interactions involved in providing an assertion to the RP from asubscriber-controlled wallet is as follows:• Step 4: The RP requests that the claimant authenticate. This triggers a request for
federated authentication to the wallet.
• Step 5: The claimant proves possession and control of the subscriber-controlledwallet.
– The subscriber activates the wallet using an activation factor.

20

NIST SP 800-63-4 2pd
August 2024

911
912

Digital Identity Guidelines– The wallet prepares an assertion including the attribute bundle provided by
the CSP for the subscriber account.

918• Step 6: The RP and the wallet communicate through a federation protocol. The
wallet provides an assertion and optionally additional attributes to the RP througha federation protocol. The RP verifies the assertion to establish confidence in theidentity and attributes of a subscriber for an online service at the RP. RPs may use
a subscriber’s federated identity (pseudonymous or non-pseudonymous), IAL, AAL,
FAL, and other factors to make authorization decisions.

919• Step 7: An authenticated session is established between the subscriber and the RP.

913
914
915
916
917

920

Note: Other protocols and specifications often refer to attributebundles as credentials. These guidelines use the term credentials
for a different concept. To avoid a conflict, the term attribute bundle
is used within these guidelines. Normative requirements for attributebundles can be found including Sec. 3.11.1 of [SP800-63C].

21

NIST SP 800-63-4 2pd
August 2024

921

3. Digital Identity Risk Management

922

This section is normative.

923
924
925
926
927
928
929

930
931
932
933

934
935
936

937
938
939

940
941
942

943
944
945

946
947

948
949
950
951
952
953
954

Digital Identity Guidelines

This section provides details on the methodology for assessing digital identity risks
associated with online services and the residual risks to users of the online service,communities impacted by the service, the service provider organization, and its mission
and business partners. It offers guidance on selecting usable, equitable, and privacyenhancing security and anti-fraud controls that mitigate those risks. Additionally, itemphasizes the importance of continuously evaluating the performance of the selected
controls.
The Digital Identity Risk Management (DIRM) process focuses on the identification andmanagement of risks according to two dimensions: (1) risks to the online service thatmight be addressed by an identity system; and (2) risks from the identity system to be
implemented.
The first dimension of risk informs initial assurance level selections and seeks to identify
the risks associated with a compromise of the online service that might be addressed by
an identity system. For example:• Identity proofing: What negative impacts would reasonably be expected if an
imposter were to gain access to a service or receive a credential using the identityof a legitimate user (e.g., an attacker successfully impersonates someone)?
• Authentication: What negative impacts would reasonably be expected if a false
claimant accessed an account that was not rightfully theirs (e.g., an attacker who
compromises or steals an authenticator)?
• Federation: What negative impacts would reasonably be expected if thewrong subject successfully accessed an online service, system, or data (e.g.,compromising or replaying an assertion)?
All three types of errors can result in the wrong subject successfully accessing an online
service, system, or data.
If it is determined that there are risks associated with a compromise of the online service
that could be addressed by an identity system, an initial assurance level is selected andthe second dimension of risk is then considered. The second dimension of risk seeks
to identify the risks posed by the identity system and informs the tailoring process.
Tailoring provides a process to modify an initially assessed assurance level, implementcompensating or supplemental controls, or modify selected controls based on ongoingdetailed risk assessments.

22

NIST SP 800-63-4 2pd
August 2024

955
956

957
958
959
960
961
962

963
964
965
966
967

968
969

970
971

972
973
974
975
976

977
978
979
980
981
982
983
984
985
986
987

988
989
990
991
992
993

Digital Identity Guidelines

For example, assuming that aspects of the identity system are not sufficiently privacyenhancing, usable, equitable, or able or necessary to address specific real-world threats:• Identity proofing: What is the impact of not successfully identity proofing andenrolling a legitimate subject due to barriers faced by the subject throughout
the process of identity proofing, including biases? What is the impact of falling
victim to a breach of information that was excessively collected and retained tosupport identity proofing processes? What is the impact if the initial IAL does notcompletely address specific threats, threat actors, and fraud?
• Authentication: What is the impact of failing to authenticate the correct subject
due to barriers faced by the subject in presenting their authenticator, including
biases or usability issues? What is the impact if the initial AAL does not completely
address targeted account takeover models or specific authenticator types fail tomitigate anticipated attacks?
• Federation: What is the impact of releasing subscriber attributes to the wrong
online service or system?
The outcomes of the DIRM process depend on the role that an entity plays within thedigital identity model.
1. For relying parties, the intent of this process is to determine the assurance
levels and any tailoring required to protect online services and the applications,transactions, and systems that comprise or are impacted by those services. This
directly contributes to the selection, development, and procurement of CSP
services. Federal RPs SHALL implement the DIRM process for all online services.
2. For credential service providers and identity providers, the intent of this process
is to design service offerings that meet the requirements of the defined assurance
levels, continuously guard against compromises to the identity system, and meetthe needs of RPs. Whenever a service offering deviates from normative guidance,
those deviations must be clearly communicated to the RPs that utilize the service.
All CSPs SHALL implement the DIRM process for the services they offer and SHALL
make a Digital Identity Acceptance Statement (DIAS) for each offering available
to all current or potential RPs. CSPs MAY base their assessment on anticipatedor representative digital identity services they wish to support. In creating thisrisk assessment, CSPs SHOULD seek input from real-world RPs on their user
populations and their anticipated context.
This process augments the risk management processes required by the Federal
Information Security Modernization Act [FISMA]. The results of the DIRM impact
assessment for the online service may be different from the FISMA impact level for theunderlying application or system. Identity process failures may result in different levelsof impact for various user groups. For example, the overall assessed FISMA impact level
for a payment system may result in a ‘FISMA Moderate’ impact category due to sensitive
23

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

1001

financial data processed by the system. However, for individuals who are making guest
payments where no persistent account is established, the authentication and proofing
impact levels may be lower as associated data may not be retained or made accessible.
Agency authorizing officials SHOULD require documentation demonstrating adherence
to the DIRM process as a part of the Authority to Operate (ATO) for the underlying
information system that supports an online service. Agency authorizing officials SHOULD
require documentation from CSPs demonstrating adherence to the DIRM as part ofprocurement or ATO processes for integration with CSPs.

1002

There are 5 steps in the DIRM process:

994
995
996
997
998
999
1000

1003
1004
1005
1006
1007
1008
1009
1010
1011
1012

1013
1014
1015
1016
1017
1018
1019
1020
1021
1022

1023
1024
1025
1026
1027
1028
1029

1030
1031
1032
1033

1. Define the online service: As a starting point, the organization documents a
description of the online service in terms of its functional scope, the user groups
it is intended to serve, the types of online transactions available to each usergroup, and the underlying data that the online service processes through its
interfaces. If the online service is one element of a broader business process, itsrole is documented, as are the impacts of any data collected and processed by the
online service. Additionally, an organization needs to determine the entities thatwill be impacted by the online service and the broader business process of which
it is a part. The outcome is a description of the online service, its users, and theentities that may be impacted by its functionality.
2. Conduct initial impact assessment: In this step, organizations evaluate their user
population and assess the impacts of a compromise of the online service thatmight be addressed by an identity system (i.e., identity proofing, authentication,or federation). Each function of the online service is assessed against a defined
set of harms and impact categories. Each user group of the online service isconsidered separately based on the transactions available to that user group (i.e.,
the permissions that the group is granted relative to the data and functions of theonline service). The outcome of this step is a documented set of impact categories
and associated impact levels (i.e., Low, Moderate, or High) for each user group of
the online service.
3. Select initial assurance levels: In this step, the impact categories and impact levels
are evaluated to determine the initial assurance levels to protect the online service
from unauthorized access and fraud. Using the assurance levels, the organization
identifies the baseline controls for the IAL, AAL, and FAL for each user group basedon the requirements from companion volumes [SP800-63A], [SP800-63B], and[SP800-63C], respectively. The outcome of this step is an identified initial IAL, AAL,
and FAL, as applicable, for each user group.
4. Tailor and document assurance level determinations: In this step, detailed
assessments are conducted or leveraged to determine the potential impact of
the initially selected assurance levels and their associated controls on privacy,
equity, usability, and resistance to the current threat environment. Tailoring may
24

NIST SP 800-63-4 2pd
August 2024

1034
1035
1036
1037
1038

1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050

1051
1052
1053
1054
1055
1056
1057
1058
1059

1060
1061
1062
1063
1064
1065
1066

1067
1068
1069
1070
1071
1072

Digital Identity Guidelines

result in a modification of the initially assessed assurance level, the identificationof compensating or supplemental controls, or both. All assessments and final
decisions are documented and justified. The outcome is a DIAS (see Sec. 3.4.4)
with a defined and implementable set of assurance levels and a final set ofcontrols for the online service.
5. Continuously evaluate and improve: In this step, information on the performanceof the identity management approach is gathered and evaluated. This evaluationconsiders a diverse set of factors, including business impacts, effects on fraud
rates, and impacts on user communities. This information is crucial in determining
if the selected assurance level and controls meet mission, business, security,and — where applicable — program integrity needs. It also helps monitor for
unintended harms that impact privacy and equitable access. Opportunities for
improvement should also be considered by closely monitoring the evolving threat
landscape and investigating new technologies and methodologies that can counter
those threats or improve usability, equity, or privacy. The outcomes of this step are
performance metrics, documented and transparent processes for evaluation andredress, and ongoing improvements to the identity management approach.
Figure 6 illustrates the major actions and outcomes for each step of the DIRM process
flow. While presented as a “stepwise” approach, there can be many points in the processthat require divergence from the sequential order, including the need for iterative cycles
between initial task execution and revisiting tasks. For example, the introduction of new
regulations or requirements while an assessment is ongoing may require organizations torevisit a step in the process. Additionally, new functionality, changes in data usage, andchanges to the threat environment may require an organization to revisit steps in the
Digital Identity Risk Management process at any point, including potentially modifying
the assurance level and/or the related controls of the online service.
Organizations SHOULD adapt and modify this overall approach to meet organizational
processes, governance, and enterprise risk management practices. At a minimum,organizations SHALL execute and document each step, consult with a representative
sample of the online service’s user population to inform the design and performance
evaluation of the identity management approach, and complete and document thenormative mandates and outcomes of each step regardless of operational approach or
enabling tools.
3.1. Define the Online Service
The purpose of defining the online service is to establish a common understandingof the context and circumstances that influence the organization’s risk management
decisions. The context-rich information ascertained during this step is intended to inform
subsequent steps of the DIRM process. The role of the online service is contextualized
as part of the broader business environment and associated processes, resulting in
25

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

Step 1: Define the Online Service
Outcome: Functional Scope; User Groups; Impacted Entities

Step 2: Conduct Initial Impact Assessment for each User Group
Determine Impact Levels per Impact Category
Outcome: Combined Impact Level (Low/Mod/High) for each User Group

Step 3: Select Initial Assurance Levels for each User Group
Map Combined Impact Level to Initial IAL/AAL/FAL and Controls
Outcome: Baseline Controls for Initial IAL/AAL/FAL for each User Group

Step 4: Tailor and Document Assurance Levels for each User Group
Using Baseline Controls, Conduct Privacy, Equity, Usability, and Threat Assessments
Adjust Initial IAL/AAL/FAL; Select Compensating and Supplemental Controls
Outcome: Digital Identity Acceptance Statement with Final IAL/AAL/FAL and Controls

Implement/Deploy/Adjust Identity Management System for Online Services

Step 5: Continuously Evaluate and Improve
Establish Performance Metrics; Collect Evaluation Inputs; Assess Performance
Outcome: Updated Digital Identity Acceptance Statement with Adjustments to Controls

Fig. 6. High-level diagram of the Digital Identity Risk Management Process Flow

26

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines1074

a documented description of the online service functionality, user groups and their
expectations, data processed and other pertinent details.

1075

RPs SHALL develop a description of the online service that includes, at minimum:

1073

1076

• Organizational mission and business objectives supported by the online service

1077• Mission and business partner dependencies associated with the online service

1078
1079

1080
1081

1082
1083

1084
1085
1086

1087
1088
1089

1090
1091

1092
1093
1094
1095
1096
1097
1098
1099
1100

1101
1102
1103
1104
1105
1106
1107
1108
1109

• Legal, regulatory, and contractual requirements, including privacy and civil liberties
obligations that apply to the online service• Functionality of the online service and the underlying data that it is expected toprocess• User groups that need to have access to the online service as well as the types of
online transactions and privileges available to each user group• User expectations for the online service, including functionality, features, identity
verification and authentication options, accessibility and language requirements,
and culturally responsive communication alternatives• The results of any pre-existing DIRA assessments (as an input) and the current
state of any pre-existing identity technologies (i.e., proofing, authentication, or
federation)• Across all users served, the estimated availability of forms of identity evidence tosupport the identity proofing process for services that require identity proofing.
Additionally, an organization needs to determine the entities that will be impacted by
the online service and the broader business process of which it is a part. It is imperative
to consider the unexpected and undesirable impacts on different entities, populations,or demographic groups that result from an unauthorized user gaining access to theonline service due to a failure of the digital identity system. For example, if an attacker
obtained unauthorized access to an application that controls a power plant, the actions
taken by the bad actor could have devastating environmental impacts on the local
populations that live near the facility as well as cause power outages for the localities
served by the plant.
It is important to differentiate between user groups and impacted entities as describedin this document. The online service will allow access to a set of users who may bepartitioned into a few user groups based on the kind of functionality that is offered tothat user group. For example, an income tax filing and review online service may havethe following user groups: (i) citizens who need to check on the status of their personal
tax returns; (2) tax preparers who file tax returns on behalf of their clients; and (3)system administrators who assign privileges to different groups of users or create newuser groups as needed. In contrast, impacted entities include all populations impacted
by the online service and its functionality. For example, an online service that allows
27

NIST SP 800-63-4 2pd
August 2024

1110
1111
1112
1113
1114
1115

1116
1117
1118
1119
1120
1121

1122
1123
1124
1125

1126
1127
1128
1129

1130
1131
1132
1133
1134

Digital Identity Guidelines

remote access to control, operate and monitor a water treatment facility may have thefollowing types of impacted entities: (1) populations that drink the water from thatwater treatment facility; (2) technicians who control and operate the water treatment
facility; (3) the organization that owns and operates the facility; and (4) auditors andother officials who provide oversight of the facility and its compliance with applicableregulations.
Accordingly, impact assessments SHALL include individuals who use the online
application as well as the organization itself. Additionally, organizations SHOULD
identify other entities (e.g., mission partners, communities, and those identified in[SP800-30]) that need to be specifically included based on mission and business needs.
At a minimum, agencies SHALL document all impacted when conducting their impact
assessments.
The output of this step is a documented description of the online service including alist of entities that are impacted by the functionality provided by the online service.
This information will serve as a basis and establish the context for effectively applying
the impact assessments as detailed in the following sections.
3.2. Conduct Initial Impact Assessment
This step of the DIRM process addresses the first dimension of risk (i.e., risks to theidentity system) and seeks to identify the risks to the online service that might be
addressed by an identity system.
The purpose of the initial impact assessment is to identify the potential adverse impactsof failures in identity proofing, authentication, and federation that are specific toan online service, yielding an initial set of assurance levels. RPs SHOULD consider
historical data and results from user focus groups when performing this step. The impact
assessment SHALL include:1136• Identifying a set of impact categories and the potential harms for each impact
category,1137• Identifying the levels of impact, and1138• Assessing the level of impact for each user group.

1135

1139
1140
1141
1142
1143

1144
1145
1146
1147

The level of impact for each user group identified in Sec. 3.1 SHALL be consideredseparately based on the transactions available to that user group. Assessing theuser groups separately allows organizations maximum flexibility in selecting andimplementing an identity approach and assurance levels that are appropriate for eachuser group.
The output of this assessment is a defined impact level (i.e., Low, Moderate, or High)for each user group. This serves as the primary input to the initial assurance levelselection. The effort focuses on defining and documenting the impact assessment topromote consistent application across an organization.
28

NIST SP 800-63-4 2pd
August 2024

1148
1149
1150

Digital Identity Guidelines

3.2.1. Identify Impact Categories and Potential Harms
Initial assurance levels for online services SHALL be determined by assessing thepotential impact of — at a minimum — each of the following categories:

1151• Degradation of mission delivery

1152• Damage to trust, standing or reputation

1153• Unauthorized access to information

1154• Financial loss or financial liability

1155• Loss of life or danger to human safety, human health, or environmental health

1156
1157
1158
1159

Organizations SHOULD include additional impact categories, as appropriate, based on
their mission and business objectives. Each impact category SHALL be documented
and consistently applied when implementing the DIRM process across different online
services offered by the organization.

1163

Harms refer to any adverse effects that would be experienced by an entity. They provide
a means to effectively understand the impact categories and how they may apply to
specific entities impacted by the online service. For each impact category, agencies
SHALL consider potential harms for each of the impacted entities identified in Sec. 3.1.

1164

Examples of harms associated with each category include, but are not limited to:

1160
1161
1162

1165

1166
1167

1168
1169
1170
1171
1172
1173

1174

1175
1176

1177
1178
1179

1180

• Degradation of mission delivery:– Harms to individuals may include the inability to access government services
or benefits for which they are eligible.
– Harms to the organization (including the organization offering the online
service as well as organizations supported by the online service) may include
an inability to perform current mission/business functions in a sufficiently
timely manner, with sufficient confidence and/or correctness, or withinplanned resource constraints or an inability or limited ability to performmission/business functions in the future.
• Damage to trust, standing or reputation:– Harms to individuals may include damage to image or reputation as a resultof impersonation.
– Harms to the organization may include damage to reputation resulting indamage to existing trust relationships, image, or reputation or the inability toforge future, potential trust relationships.
• Unauthorized access to information:

29

NIST SP 800-63-4 2pd
August 2024

1181
1182
1183
1184

1185
1186
1187
1188

1189

1190
1191
1192
1193

Digital Identity Guidelines– Harms to individuals may include breach of PII or other sensitive information,
which may result in secondary harms such as financial loss, loss of life,
physical or psychological injury, impersonation, identity theft, or persistent
inconvenience.
– Harms to the organization may include exfiltration, deletion, degradation,
or exposure of intellectual property or unauthorized disclosure of otherinformation assets such as classified materials or controlled unclassified
information (CUI).
• Financial loss or liability:– Harms to individuals may include debts incurred or assets lost as a resultof fraud or other harm, damage to or loss of credit, actual or potential
employment, or sources of income, loss of accessible affordable housing
and/or other financial loss.

1195– Harms to the organization may include costs related to fraud or othercriminal activity, loss of assets, devaluation, or loss of business.

1196• Loss of life or danger to human safety, human health, or environmental health:

1194

1197
1198
1199
1200

1201
1202
1203

1204
1205

1206
1207
1208
1209
1210
1211

– Harms to individuals may include death; damage to or loss of physical,
mental, or emotional well-being; or impact to environmental health that
could result in uninhabitability of the local environment and require somelevel of intervention to address potential or actual damage.
– Harms to the organization may include damage to or loss of theorganization’s workforce or the impact of unsafe conditions that render theorganization unable to operate or reduce its capacity to operate.
The outcome of this activity will be a list of impact categories and harms that will be
used to assess impacts on entities identified in Sec. 3.1.
3.2.2. Identify Potential Impact Levels
Initial assurance levels for digital transactions are determined by assessing the potential
level of impact caused by a compromise of the online service that might be addressedby an identity system for each of the impact categories selected for consideration by theorganization (from Sec. 3.2.1). Impact levels can be assigned using one of the following
potential impact values:1212• Low: Could be expected to have a limited adverse effect1213• Moderate: Could be expected to have a serious adverse effect1214• High: Could be expected to have a severe or catastrophic adverse effect30

NIST SP 800-63-4 2pd
August 2024

1215
1216
1217
1218
1219
1220
1221
1222

1223

1224
1225
1226

1227
1228
1229

1230
1231
1232

1233

1234
1235

1236
1237
1238

1239
1240
1241
1242

1243

1244
1245

1246
1247

1248
1249
1250

Digital Identity Guidelines

In this step, the impact of access by an unauthorized individual SHALL be considered
for each user group, each impact category, and each of the impacted entities. Examplesof potential impacts in each of the categories are provided below. However, to provide
a more objective basis for impact level assignments, organizations SHOULD develop
thresholds and examples for the impact levels for each impact category. Where this isdone, particularly with specifically defined quantifiable values, these thresholds SHALL
be documented and used consistently in the DIRM assessments across an organization toallow for a common understanding of risks.
• Degradation of mission delivery:– Low: Expected to result in limited mission capability degradation suchthat the organization is still able to perform its primary functions but with
noticeably reduced effectiveness.
– Moderate: Expected to result in serious mission capability degradation suchthat the organization is still able to perform its primary functions but withsignificantly reduced effectiveness.
– High: Expected to result in severe or catastrophic mission capability
degradation or loss over a duration such that the organization is unable toperform one or more of its primary functions.
• Damage to trust, standing or reputation:– Low: Expected to result in limited, short-term inconvenience, distress, orembarrassment to any party.
– Moderate: Expected to result in serious short-term or limited long-term
inconvenience, distress, or damage to the standing or reputation of any
party.
– High: Expected to result in severe or serious long-term inconvenience,
distress, or damage to the standing or reputation of any party; ordinarily
reserved for situations with particularly severe effects or that potentiallyaffect many individuals.
• Unauthorized access to information:– Low: Expected to have a limited adverse effect on organizational operations,organizational assets, or individuals as defined in [FIPS199].
– Moderate: Expected to have a serious adverse effect on organizational
operations, organizational assets, or individuals as defined in [FIPS199].
– High: Expected to have a severe or catastrophic adverse effect onorganizational operations, organizational assets, or individuals as definedin [FIPS199].

31

NIST SP 800-63-4 2pd
August 2024

1251

1252

1253
1254

Digital Identity Guidelines• Financial loss or financial liability:– Low: Expected to result in limited financial loss or liability to any party.
– Moderate: Expected to result in a serious financial loss or liability to any
party.

1256– High: Expected to result in severe or catastrophic financial loss or liability to
any party.

1257• Loss of life or danger to human safety, human health, or environmental health:

1255

1258
1259
1260
1261

1262
1263
1264
1265
1266

1267
1268
1269
1270
1271

1272
1273
1274

1275
1276
1277
1278
1279

– Low: Expected to result in minor injury or an acute health issue that resolves
itself and does not require medical attention, including mental healthtreatment; or an impact to environmental health that requires at most some
limited intervention to prevent further or reverse existing damage.
– Moderate: Expected to result in moderate risk of minor injury or limited riskof injury that requires medical attention, including mental health treatment;
an impact to environmental health that results in a period of uninhabitability
and requires intervention to prevent further or reverse existing damage; orthe compounding impacts of multiple low-impact events.
– High: Expected to result in serious injury, trauma, or death; impacts toenvironmental health that results in long-term or permanent uninhabitability
and require significant intervention to prevent further or reverse existingdamage, if possible; or the compounding impacts of multiple moderate
impact events.
This guidance provides three impact levels. However, agencies MAY define moregranular impact levels and develop their own methodologies for their initial impact
assessment activities.
3.2.3. Impact Analysis
The impact analysis considers the level of impact (i.e., Low, Moderate or High) ofcompromises of the online service that might be addressed by the identity system
functions (i.e., identity proofing, authentication, and federation). The impact analysis
considers the following dimensions:1280• User groups Sec. 3.1

1281• Impacted entities Sec. 3.1

1282• Impact categories Sec. 3.2.1

1283• Impact levels Sec. 3.2.2

32

NIST SP 800-63-4 2pd
August 2024

1284
1285

1286
1287
1288
1289

1290
1291
1292
1293
1294
1295
1296
1297
1298
1299

1300
1301
1302
1303

1304
1305
1306

1307
1308
1309
1310
1311

1312
1313

1314
1315

1316
1317

1318
1319

Digital Identity Guidelines

If there is no harm or impact for a given impact category for any entity, the impact levelcan be marked as None.
For each user group, the impact analysis SHALL consider the level of impact for each
impact category for each type of impacted entity. Because different sets of transactions
are available to each user group, it is important to consider each user group separately
for this analysis.
For example, for an online service that allows for the control, operation and monitoringof a water treatment facility, each group of users (e.g., technicians who control andoperate the facility, auditors and monitoring officials, system administrators, etc.) is
considered separately based on the transactions available to that user group throughthe online service. In other words, the impact analysis tries to determine if a bad actor
obtained unauthorized access to the online service as a member of a user group andperformed some nefarious actions and the level of impact (i.e., Low, Moderate or High)on various impacted entities (e.g., citizens who drink the water, the organization thatowns the facility, auditors, monitoring officials, etc.) for each of the impact categories
being considered.
The impact analysis SHALL be performed for each user group that has access to theonline service. For each impact category, the impact level is estimated for each impacted
entity as a result of a compromise of the online service caused by failures in the identity
management functions.
The output of this impact analysis is a set of impact levels for each user group that
SHALL be documented in a suitable format for further analysis in accordance with thenext subsection below.
3.2.4. Determine Combined Impact Level for Each User GroupThe impact assessment level results for each user group generated from the previous
step are combined to establish a single impact level for that user group. This single
impact level represents the risks to impacted entities that result from a compromise ofidentity proofing, authentication, and/or federation functions for that user group.
Organizations can apply a variety of methods for this combinatorial analysis to determine
the effective impact level for each user group. Some options include:• Using a high-water mark approach across the various impact categories andimpacted entities to derive the effective impact level• Assigning different weights to different impact categories and/or impacted entities
and taking an average to derive the effective impact level• Some other combinatorial logic that aligns with the organization’s mission andpriorities

33

NIST SP 800-63-4 2pd
August 2024

1320
1321
1322
1323

1324
1325
1326

1327
1328
1329
1330
1331

1332
1333
1334
1335

1336
1337

1338
1339
1340
1341
1342
1343

1344
1345
1346

1347
1348
1349

1350
1351
1352

Digital Identity Guidelines

Organizations SHALL document the approach they use to combine their impact
assessment into an overall impact score for each of their defined user groups and SHALL
apply it consistently across all its online services. At the conclusion of the combinatorial
analysis, organizations SHALL document the impact for each user group.
The outcome of this step is an effective impact level for each user group due to acompromise of the identity management system functions (i.e., identity proofing,authentication, federation).
3.3. Select Initial Assurance Levels and Baseline Controls
The initial impact analysis of the last step yields an effective impact level (i.e., Low,
Moderate, or High) that serves as a primary input to the process of selecting the initialassurance levels for identity proofing, authentication, and federation for each usergroup.
The purpose of the initial assurance level is to identify baseline digital identity controls(including process and technology elements) for each identity management function,from the requirements and guidelines in the companion volumes [SP800-63A],[SP800-63B], and [SP800-63C].
The initial set of digital identity controls and processes selected will be assessed andtailored in Step 4 based on potential risks generated by the identity management system.
3.3.1. Assurance Levels
Depending on the functionality and deployed architecture of the online service, it may
require the support of one or more of the identity management functions (i.e., identity
proofing, authentication, and federation). The strength of these functions is described interms of assurance levels. The RP SHALL identify the types of assurance levels that apply
to their online service from the following:• IAL: The robustness of the identity proofing process to determine the identityof an individual. The IAL is selected to mitigate risks that result from potential
identity proofing failures.
• AAL: The robustness of the authentication process itself, and the binding between
an authenticator and a specific individual’s identifier. The AAL is selected tomitigate risks that result from potential authentication failures.
• FAL: The robustness of the federation process used to communicate
authentication and attribute information to an RP from an IdP. The FAL is selected
to mitigate risks that result from potential federation failures.

34

NIST SP 800-63-4 2pd
August 2024

1353
1354
1355
1356
1357

1358
1359
1360
1361
1362

1363
1364

1365
1366
1367

Digital Identity Guidelines

3.3.2. Assurance Level Descriptions
A summary of each of the xALs is provided below. While high-level descriptions of
the assurance levels are provided in this subsection, readers of this guidance areencouraged to refer to companion volumes [SP800-63A], [SP800-63B], and [SP800-63C]
for normative guidelines and requirements for each assurance level.
3.3.2.1. Identity Assurance Level• IAL1: Supports the real-world existence of the claimed identity. Core attributes are
obtained from identity evidence or asserted by the applicant. All core attributes
are validated against authoritative or credible sources and steps are taken to link
the attributes to the person undergoing the identity proofing process.
• IAL2: IAL2 adds rigor by requiring the collection of additional evidence and a more
rigorous process for validating the evidence and verifying the identity.
• IAL3: IAL3 adds the requirement for a trained CSP representative (i.e., proofing
agent) to interact directly with the applicant as part of an on-site attended identity
proofing session as well as the collection of at least one biometric.
Table 1. IAL Summary

IAL

Control Objectives

IAL1

Limit highly scalable attacks; provide protection against synthetic
identity. Provide protections against attacks using compromised
PII.
Limit scaled and targeted attacks. Provide protections against
basic evidence falsification and evidence theft. Provide
protections against basic social engineering.
Limit sophisticated attacks. Provide protections against advanced
evidence falsification, theft, and repudiation. Provide protection
against advanced social engineering attacks.

IAL2

IAL3

1368
1369
1370
1371
1372
1373
1374

3.3.2.2. Authentication Assurance Level• AAL1: AAL1 provides a basic level of confidence that the claimant controls anauthenticator bound to the subscriber account being authenticated. AAL1 requires
only single-factor authentication using a wide range of available authentication
technologies. However, it is recommended that online services assessed at AAL1
offer multi-factor authentication options. Successful authentication requires thatthe claimant prove possession and control of the authenticator.

35

NIST SP 800-63-4 2pd
August 2024

1375
1376
1377
1378
1379

1380
1381
1382
1383
1384
1385
1386
1387

Digital Identity Guidelines• AAL2: AAL2 provides high confidence that the claimant controls one or moreauthenticators bound to the subscriber account being authenticated. Proofof possession and control of two distinct authentication factors is required. A
phishing-resistant authentication option must be offered for online services
assessed at AAL2.
• AAL3: AAL3 provides very high confidence that the claimant controls one ormore authenticators bound to the subscriber account being authenticated.
Authentication at AAL3 is based on the proof of possession of a key throughthe use of a public-key cryptographic protocol. AAL3 authentication requires a
hardware-based authenticator with a non-exportable private key and a phishingresistant authenticator; the same device may fulfill both requirements. In order toauthenticate at AAL3, claimants are required to prove possession and control of
two distinct authentication factors.
Table 2. AAL Summary

AAL

Control Objectives

AAL1

Provide minimal protections against attacks. Deter password
focused attacks.
Support multifactor authentication. Offer phishing-resistantoptions.
Provide phishing resistance and verifier compromise protections.

AAL2
AAL3

1388
1389
1390
1391

1392
1393
1394

1395
1396
1397
1398

3.3.2.3. Federation Assurance Level• FAL1: FAL1 allows a subscriber to authenticate to the RP using an assertion froman IdP in a federation protocol. FAL1 provides assurance that the assertion camefrom a specific IdP and was intended for a specific RP.
• FAL2: FAL2 additionally requires that the trust agreement between the IdP and
RP be established prior to the federation transaction, and that the RP have robust
protections against injection of assertions from attackers.
• FAL3: FAL3 additionally requires the subscriber to authenticate directly to the RPwith a bound authenticator and present the assertion from the IdP. Additionally,
the IdP and RP establish their identities and cryptographic key material with eachother through a highly trusted process that is often manual.

36

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

Table 3. FAL Summary

1399
1400
1401
1402
1403
1404
1405
1406

1407
1408
1409
1410

1411
1412
1413
1414
1415
1416

1417
1418
1419
1420
1421
1422
1423
1424
1425

FAL

Control Objectives

FAL1
FAL2
FAL3

Provide protections against forged assertions.
Provide protections against forged assertions and injection attacks.
Provide protection against IdP compromise.

3.3.3. Initial Assurance Level Selection
The overall impact level for each user group is used as the basis for the selection of theinitial assurance level and related technical and process controls for the digital identity
functions for the organization’s online service under assessment. These initial assurance
levels and control selections are primarily based on the impacts arising from failures
within the digital identity functions that allow an unauthorized entity to gain access tothe online service. The initial assurance levels and controls will be further assessed andtailored, as appropriate, in the next step of the DIRM process.
Organizations SHALL develop and document a process and governance model for
selecting initial assurance levels and controls based on the potential impact of failuresin the digital identity approach. This section provides guidance on the major elements toinclude in that process.
While online service providers must assess and determine the xALs that are appropriate
for protecting their applications, the selection of these assurance levels does not meanthat the online service provider must implement the controls independently. Based on
the identity model that the online service provider chooses to implement, some or all of
the assurance levels may be implemented by an external entity such as a third-party CSP
or IdP.
3.3.3.1. Selecting Initial IAL
Before selecting an initial assurance level, RPs must determine if identity proofing isneeded for the users of their online services. Identity proofing is not required if theonline service does not require any personal information to execute digital transactions.
If personal information is needed, the RP needs to determine if validated attributes are
required or if self-asserted attributes are acceptable. The system may also be able tooperate without identity proofing if the potential harms from accepting self-asserted
attributes are insignificant. In such cases, the identity proofing processes described in[SP800-63A] are not applicable to the system.

37

NIST SP 800-63-4 2pd
August 2024

1426
1427

If the online service does require identity proofing, an initial IAL is selected through asimple mapping process, as follows:1428• Low impact: IAL1

1429

• Moderate impact: IAL2

1430

• High impact: IAL3

1431
1432
1433

1434
1435
1436

1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448

1449
1450

The organization SHALL document whether identity proofing is required for theirapplication and, if it is, SHALL select an initial IAL for each user group based on theeffective impact level determination from Sec. 3.2.4.
The IAL reflects the level of assurance that an applicant holds the claimed real-life
identity. The initial selection assumes that higher potential impacts of failures in theidentity proofing process should be mitigated by higher assurance processes.
3.3.3.2. Selecting Initial AAL
Not all online services require authentication. Online services that offer access to public
information and do not utilize subscriber accounts do not necessarily need to implement
authentication mechanisms. However, authentication is needed for online services that
do offer access to personal information, protected information, or subscriber accounts.
In addition to the impact assessments mandated by these guidelines, when making
decisions regarding the application of authentication assurance levels and authentication
mechanisms, it is important that organizations consider legal, regulatory, or policy
requirements that govern online services. For example, [EO13681] states “that allorganizations making personal data accessible to citizens through digital applications
require the use of multiple factors of authentication,” which requires a minimum
selection of AAL2 for applications meeting those criteria.
If the online service requires an authenticator to be implemented, an initial AAL is
selected through a simple mapping process, as follows:

1451• Low impact: AAL1

1452

• Moderate impact: AAL2

1453

• High impact: AAL3

1454
1455
1456

1457
1458
1459
1460

Digital Identity Guidelines

The organization SHALL document whether authentication is needed for their online
service and, if it is, SHALL select an initial AAL for each user group based on the effective
impact level determination from Sec. 3.2.4.
The AAL reflects the level of assurance that the claimant is the same individual to whom
the credential or authenticator was issued. The initial selection assumes that higher
potential impacts of failures in the authentication process should be mitigated by higher
assurance processes.
38

NIST SP 800-63-4 2pd
August 2024

1461
1462
1463
1464
1465
1466
1467
1468

1469
1470

3.3.3.3. Selecting Initial FAL
Identity federation brings many benefits including a convenient user experience thatavoids redundant, costly, and often time-consuming identity processes. The benefitsof federation through a general-purpose IdP model or a subscriber-controlled walletmodel are covered in Sec. 5 of [SP800-63C]. However, not all online services will be able
to make use of federation, whether for risk-based reasons or due to legal or regulatory
requirements. Consistent with [M-19-17], federal agencies that operate online services
SHOULD implement federation as an option for user access.
If the online service implements identity federation, an initial FAL is selected through asimple mapping process, as follows:

1471• Low impact: FAL1

1472

• Moderate impact: FAL2

1473

• High impact: FAL3

1474
1475
1476

1477
1478
1479
1480

1481
1482
1483
1484
1485
1486

1487
1488

Digital Identity Guidelines

The organization SHALL document whether federation will be used for their online
service and, if it is, SHALL select an initial FAL for each user group based on the effective
impact level determination from Sec. 3.2.4.
The FAL reflects the level of assurance in identity assertions that convey the results ofauthentication processes and relevant identity information to RP online services. The
preliminary selection assumes that higher potential impacts of failures in federated
identity architectures should be mitigated by higher assurance processes.
3.3.4. Identify Baseline Controls
The selection of the initial assurance levels for each of the applicable identity functions(i.e., IAL, AAL, and FAL) serves as the basis for the selection of the baseline digital
identity controls from the guidelines in companion volumes [SP800-63A], [SP800-63B],
and [SP800-63C]. As described in Sec. 3.4, the baseline controls include technology andprocess controls that will be assessed against additional potential impacts.
The output of this step SHALL include the relevant xALs and controls for each user group,
as follows:1489• Initial IAL and related technology and process controls from [SP800-63A]

1490• Initial AAL and related technology and process controls from [SP800-63B]

1491• Initial FAL and related technology and process controls from [SP800-63C]

39

NIST SP 800-63-4 2pd
August 2024

1492
1493
1494
1495
1496

1497
1498
1499
1500
1501
1502
1503
1504
1505
1506

1507
1508
1509
1510
1511
1512

1513
1514
1515
1516
1517
1518
1519
1520

1521
1522
1523
1524
1525
1526
1527

Digital Identity Guidelines

3.4. Tailor and Document Assurance Levels
The second dimension of risk addressed by the Digital Identity Risk Management process
focuses on risks from the identity management system. These risks inform the tailoringprocess and seeks to identify the risks and unintended consequences that result fromthe initial selection of xALs and the related technical and process controls in Sec. 3.3.4.
Tailoring provides a process to modify an initially assessed assurance level andimplement compensating or supplemental controls based on ongoing detailed risk
assessments. It provides a pathway for flexibility and enables organizations to achieverisk management objectives that align with their specific context, users, and threat
environment. This process focuses on assessing for unintended risks and equity, privacy,
and usability impacts, and specific environmental threats. It does not prioritize any
specific risk area or outcomes for agencies. Making decisions that balance different typesof risks to meet organizational outcomes remains the responsibility of organizations.
Organizations SHOULD employ tailoring with the objective of aligning of digital identity
controls to their specific context, users, and threat environment.
Within the tailoring step, organizations SHALL focus on impacts to mission delivery due
to the implementation of identity management controls that result in disproportionate
impact on marginalized or historically underserved populations. Organizations SHALL
consider not only the possibility of certain intended subjects failing to access the online
service, but also the burdens, frustrations, and frictions experienced as a result of theidentity management controls.
As a part of the tailoring process, organizations SHALL review the impact assessment
documentation and practice statements2 from CSPs and IdPs that they use or intend touse. However, organizations SHALL also conduct their own analysis to ensure that theorganization’s specific mission and the communities being served by the online service
are given due consideration for tailoring purposes. As a result the organization may
require their chosen CSP to strengthen or provide optionality in the implementation ofcertain controls to address risks and unintended impacts to the organization’s mission
and the communities served.
To promote interoperability and consistency across organizations, third-party CSPs
SHOULD implement their (assessed or tailored) xALs consistent with the normative
guidance in this document. However, these guidelines provide flexibility to allow
organizations to tailor the initial xALs and related controls to meet specific mission
needs, address unique risk appetites, and provide secure and accessible online services.
In doing so, CSPs MAY offer and organizations MAY utilize tailored sets of controls thatdiffer from the normative statements in this guidance.

2 Further information on practice statements and their contents can be found in Section 3.1 of SP800-63A.

40

NIST SP 800-63-4 2pd
August 2024

Digital Identity Guidelines

1529

Therefore, organizations SHALL establish and document an xAL tailoring process. At aminimum this process:1530• SHALL follow a documented governance approach to allow for decision-making.

1528

1531
1532
1533

1534
1535

1536
1537
1538
1539

1540
1541

1542
1543
1544

1545
1546
1547
1548
1549
1550
1551

1552
1553

1554
1555
1556
1557
1558
1559
1560
1561
1562
1563

• SHALL document all decisions in the tailoring process, including the assessed xALs,
modified xALs, and supplemental and compensating controls in the Digital Identity
Acceptance Statement (see Sec. 3.4.4).
• SHALL justify and document all risk-based decisions or modifications to the initiallyassessed xALs in the Digital Identity Acceptance Statement (see Sec. 3.4.4).
• SHOULD establish a cross-functional capability to support subject matter analysis
of xAL selection impacts in the tailoring process (e.g., subject matter experts who
can speak about risks and considerations related to privacy, usability, fraud andimpersonation impacts, equity, and other germane areas).
• SHOULD be a continuous process that incorporates real-world operational data toevaluate the impacts of selected xAL controls.
The tailoring process promotes a structured means of balancing risks and impacts in thefurtherance of protecting online services, systems, and data in a manner that enables
mission success while supporting equity, privacy, and usability for individuals.
3.4.1. Assess Privacy, Equity, Usability and Threat Resistance
When selecting and tailoring assurance levels for specific online services, it is criticalthat insights and inputs to the process extend beyond the initial impact assessment
in Sec. 3.2. When transitioning from the initial assurance level selection in Sec. 3.3.4
to the final xAL selection and implementation, organizations SHALL conduct detailed
assessments of the controls defined for the initially selected xALs to identify potential
impacts in the operational environment.
At a minimum, organizations SHALL assess the impacts and potential unintended
consequences related to the following areas:• Privacy – Identify unintended consequences to the privacy of individuals thatwill be subject to the controls at an assessed xAL and of individuals affected byorganizational or third-party practices related to the establishment, management,or federation of a digital identity. Privacy assessments SHOULD leverage existing
Privacy Threshold Assessments (PTAs) and Privacy Impact Assessments (PIAs) as
inputs to the privacy assessment process. However, as the goal of the privacy
assessment is to identify privacy risks that arise from the initial assurance levelselection, additional assessments and evaluations that are specific to the baseline
controls for the assurance levels may be required for the underlying information
system.

41

NIST SP 800-63-4 2pd
August 2024

1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574

1575
1576
1577
1578
1579
1580

1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591

1592
1593
1594
1595

1596
1597
1598
1599

1600
1601
1602

Digital Identity Guidelines• Equity – Determine whether implementation of the initial assurance levels may
create, maintain, or exacerbate inequities across communities. Equity assessments
SHALL evaluate impacts on the communities being served by considering factors
such as: proficiency with and access to technology, the availability of end devices
with required technical capabilities (e.g., cameras), shared computing or device
scenarios, housing status, access to internet, internet speed, family income
bracket, credit score, disability status, sex, skin tone, age, native language,
English fluency, and education. The intent of this assessment is to mitigate
potential impacts on marginalized and historically underserved groups and limit
disproportionate impacts from the requirements of the identity management
functions.
• Usability – Determine whether implementation of the initial assurance levels will
result in challenges to the end-user experience. Usability assessments SHALL
consider usability impacts that result from the identity management controls toensure that they do not cause undue burdens, frustrations, or frictions for thecommunities served and that there are pathways to provide accessibility to users
of all capabilities.
• Threat Resistance – Determine whether the defined assurance level and related
controls will address specific threats to the online service based on the operational
environment, its threat actors, and known tactics, techniques, and procedures(TTPs). Threat assessments SHALL consider specific and known threats, threat
actors, and TTPs within the implementation environment for the identity
management functions. For example, certain benefits programs may be more
subject to familial threats or collusion. Supplemental controls MAY need to be
implemented to address specific threats within communities served by the online
service. Conversely, agencies MAY tailor their assessed xAL down or modify theirbaseline controls if their threat assessment indicates that a reduced threat posture
is appropriate based on their environment.
Organizations SHOULD leverage consultation and feedback to ensure that the tailoringprocess addresses the constraints of the entities and communities served. Organizations
MAY establish mechanisms through which civil society organizations that work with
marginalized groups can provide input on the impacts felt or likely to be felt.
Additionally, organizations SHOULD conduct additional business-specific assessments asappropriate to fully represent mission- and domain-specific considerations not captured
here. These assessments SHALL be extended to any compensating or supplemental
controls as defined in Sec. 3.4.2 and Sec. 3.4.3.
The outcome of this step is a set of risk assessments for privacy, equity, usability,
threat resistance and other dimensions that informs the tailoring of the initialassurance levels and the selection of compensating and supplemental controls.

42

NIST SP 800-63-4 2pd
August 2024

1603
1604
1605
1606
1607

1608
1609
1610
1611
1612
1613

1614
1615
1616
1617
1618
1619
1620
1621

1622
1623
1624
1625
1626
1627

1628
1629
1630
1631

1632
1633
1634
1635
1636
1637

1638
1639
1640

Digital Identity Guidelines

3.4.2. Identify Compensating Controls
A compensating control is a management, operational, or technical control employedby an organization in lieu of a normative control in the defined xALs. They are intended
to address the same risks as the baseline control is intended to address to the greatest
degree practicable.
Organizations MAY choose to implement a compensating control when they areunable to implement a baseline control or when a risk assessment indicates that acompensating control sufficiently mitigates risk in alignment with organizational risk
tolerance. This control MAY be a modification to the normative statements as definedin these guidelines, but MAY also be applied elsewhere in an application, digitaltransaction, or service lifecycle. For example:• A federal agency could choose to use a federal background investigation andchecks, as referenced by Personal Identity Verification [FIPS201], to compensate
for the identity evidence validation with authoritative sources requirement underthese guidelines.
• An organization could choose to implement stricter auditing and transactional
review processes on a payment application where verification processes using
weaker forms of identity evidence were accepted due to the lack of required
evidence in the end-user population.
Where compensating controls are implemented, organizations SHALL document
the compensating control, the rationale for the deviation, comparability of thechosen alternative, and resulting residual risk (if any). CSPs and IDPs who implementcompensating controls SHALL communicate this information to all potential RPs
prior to integration to allow the RP to assess and determine the acceptability of thecompensating controls for their use cases.
The process of tailoring allows agencies and service providers to make risk-based
decisions regarding how they implement their xALs and related controls. It also provides
a mechanism for documenting and communicating decisions through the Digital Identity
Acceptance Statement described in Sec. 3.4.4.
3.4.3. Identify Supplemental Controls
Supplemental controls are those that may be added to further strengthen the baseline
controls specified for the organization’s selected assurance levels. Organizations
SHOULD identify and implement supplemental controls to address specific threats inthe operational environment that may not be addressed by the baseline controls. For
example:• To complete the proofing process, an organization could choose to verify an end
user against additional pieces of identity evidence, beyond what is required by theassurance level, due to a high prevalence of fraudulent attempts.
43

NIST SP 800-63-4 2pd
August 2024

1641
1642

1643
1644
1645

1646
1647

Digital Identity Guidelines• An organization could restrict users to only phishing-resistant authentication at
AAL2.
• An organization could choose to implement risk-scoring analytics, coupled with
re-proofing mechanisms, to confirm a user’s identity when their access attempts
exhibit certain risk factors.
Any supplemental controls SHALL be assessed for impacts based on the same factors
used to tailor the organization’s assurance level and SHALL be documented.

1654

3.4.4. Digital Identity Acceptance Statement (DIAS)
Organizations SHALL develop a Digital Identity Acceptance Statement (DIAS) to
document the results of the Digital Identity Risk Management process for each online
service managed by the organization. A CSP/IdP SHALL make their DIAS and practicestatements available to RPs. RPs who intend to use a particular CSP/IdP SHALL review
the latter’s DIAS and practice statements and incorporate relevant information into theorganization’s DIAS for each online service.

1655

The DIAS SHALL include, at a minimum:

1656• Initial impact assessment results,

1657• Initially assessed xALs,

1658• Tailored xAL and rationale, if the tailored xAL differs from the initially assessed xAL,

1659

• All compensating controls with their comparability or residual risk, and1660• All supplemental controls.

1648
1649
1650
1651
1652
1653

1661
1662

1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674

Federal agencies SHOULD include this information in the information systemauthorization package described in [NISTRMF].
3.5. Continuously Evaluate and Improve
Threat actors adapt; user capabilities, expectations, and needs shift; seasonal surges
occur; and missions evolve. As such, risk assessments and identity solutions must becontinuously improved. In addition to keeping pace with the threat and technology
environment, continuous improvement is a critical tool for illustrating programmatic
gaps that — if unaddressed — may hinder the implementation of identity management
systems in a manner that balances risk management objectives. For instance, anorganization may determine that a portion of the target population intended to beserved by the online service does not have access to affordable high-speed internet
services needed to support remote identity proofing. The organization could address thisgap with a program that implements local proofing capabilities within the community
or by offering appointments with proofing agents who will meet the individual at an

44

NIST SP 800-63-4 2pd
August 2024

1675
1676

1677
1678
1679
1680
1681
1682
1683
1684
1685

1686
1687
1688
1689

1690
1691
1692

1693
1694

1695
1696

1697
1698

1699
1700

1701
1702

1703
1704
1705

1706
1707
1708
1709

Digital Identity Guidelines

address that is more accessible and convenient, such as their local community center,closest post office, an affiliated business partner facility, or the individual’s home.
To address the shifting environment in which they operate and more rapidly address
service capability gaps, organizations SHALL implement a continuous evaluation andimprovement program that leverages input from end users who have interacted with theidentity management system as well as performance metrics for the online service. This
program SHALL be documented, including the metrics that are collected, the sources ofdata required to enable performance evaluation, and the processes in place for taking
timely actions based on the continuous improvement process. This program and its
effectiveness SHOULD be assessed on a defined basis to ensure that outcomes are being
achieved and that programs are addressing issues in a timely manner.
Additionally, organizations SHALL monitor the evolving threat landscape to stay
informed of the latest threats and fraud tactics. Organizations SHALL regularly assess
the effectiveness of current security measures and fraud detection capabilities against
the latest threats and fraud tactics.
3.5.1. Evaluation Inputs
To fully understand the performance of their identity system, organizations will need to
identify critical inputs to their evaluation process. At a minimum these SHALL include:• Integrated CSP, IdP, and authenticator functions as well as validation, verification,and fraud management systems as appropriate.
• Customer feedback mechanisms such as complaint processes, help-desk statistics,
and other user feedback (e.g., surveys, interviews, or focus groups)• Threat analysis, threat reporting, and threat intelligence feeds as available to theorganization.
• Fraud trends, fraud investigation results, and fraud metrics as available to theorganization.
• The results of ongoing equity assessments, privacy assessments, and usability
assessments.
Organizations SHALL document their metrics, reporting requirements, and data inputs
for any CSP, IdP, or other integrated identity services to ensure that expectations areappropriately communicated to partners and vendors.
3.5.2. Performance Metrics
The exact metrics available to organizations will vary based on the technologies,
architectures, and deployment patterns they follow. Additionally, what is available
and what is useful may vary over time. Therefore, these guidelines do not attempt
45

NIST SP 800-63-4 2pd
August 2024

1710
1711
1712
1713
1714
1715

Digital Identity Guidelines

to define a comprehensive set of metrics for all scenarios. Table 4 provides a set ofrecommended metrics that organizations SHOULD capture as part of their continuous
evaluation program. However, organizations are not constrained by this table and
SHOULD implement metrics that are not defined here based on their specific systems,
technology, and program needs. In Table 4, all references to unique users include both
legitimate users and imposters.
Table 4. Performance Metrics

Title

Description

Type

Pass Rate (Overall)

Percentage of unique users who successfully
proof.
Percentage of unique users who successfully
proof for each offered type (i.e., Remote
Unattended, Remote Attended, Onsite
Attended, Onsite Unattended).
Percentage of unique users who start theidentity proofing process but are unable tosuccessfully complete all the steps.
Percentage adjusted to account for digitaltransactions that are terminated based on
suspected fraud.
Percentage of unique users who do notcomplete proofing due to a process
failure for each offered type (i.e., Remote
Unattended, Remote Attended, Onsite
Attended, Onsite Unattended)
Percentage of unique users who start
the identity proofing process, but do notcomplete it without failing a process.
Percentage of unique users who start a
specific type of identity proofing process,but do not complete it without failing aprocess.
Percentage of unique users who are
unsuccessful at completing each identity
proofing step in a CSP process.
Average time that it takes a user tocomplete each defined proofing typeoffered as part of an identity service.

Proofing

Pass Rate (PerProofing Type)

Fail Rate (Overall)

Estimated Adjusted
Fail Rate
Fail Rate (Per Proofing
Type)

Abandonment Rate
(Overall)Abandonment Rate
(Per Proofing Type)

Failure Rates (PerProofing Process
Step)
Completion (Times
Per Proofing Type)46

Proofing

Proofing

Proofing

Proofing

Proofing

Proofing

Proofing

Proofing

NIST SP 800-63-4 2pd
August 2024

Authenticator Type
Usage
Authentication
FailuresAccount Recovery
Attempts
Confirmed Fraud

Suspected Fraud
Reported Fraud
Fraud (Per Proofing
Type
Fraud (Per
Authentication Type)
Help Desk Calls
Help Desk Calls (PerType)
Help Desk Resolution
Times
Customer Satisfaction
Surveys
Redress requests
Redress resolution
times

1716
1717
1718
1719
1720
1721

Digital Identity Guidelines

Percentage of subscribers who have an
active authenticator by each type available.
Percentage of authentication events that fail(not to include attempts that are successful
after re-entry of an authenticator output).
The number of account or authenticator
recovery processes initiated by subscribers
Percentage of digital transactions thatare confirmed to be fraudulent throughinvestigation or self-reporting.
Percentage of digital transactions that aresuspected of being fraudulent.
Percentage of digital transactions reported
to be fraudulent by users.
Number of digital transactions that aresuspected, confirmed, and reported by eachavailable type of proofing.
Number of digital transactions suspected,
confirmed, and reported by each available
type of authentication
Number of calls received by the CSP or
identity service.
Number of calls received related to eachoffered service (e.g., proofing failures,
authenticator resets, complaints)
Average length of time it takes to resolve acomplaint or help desk ticket.
The results of customer feedback surveys
conducted by CSPs, RP, or both.
The number of redress requests received
related to the identity management system.
The average time it takes to resolve
redress requests related to the identity
management system.

Authentication
Authentication

Authentication
Fraud

Fraud
Fraud
Fraud

Fraud

Customer Support
Customer Support

Customer Support
User Experience
User Experience
User Experience

The data used to generate continuous evaluation metrics may not always reside with
the identity program or the organizational entity responsible for identity management
systems. The intent of these metrics is not to establish redundant processes but tointegrate with existing data sources whenever possible to collect information that is
critical to identity program evaluation. For example, customer service representative(CSR) teams may already have substantial information on customer requests, complaints,
47

NIST SP 800-63-4 2pd
August 2024

1722
1723
1724

1725
1726
1727
1728
1729
1730
1731
1732
1733
1734

1735
1736
1737
1738
1739

1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750

1751
1752
1753
1754

1755
1756
1757

Digital Identity Guidelines

or concerns. Identity management systems would be expected to coordinate with theseteams to acquire the information needed to discern identity management systemrelated complaints or issues.
3.5.3. Measurement in Support of Equity Assessments and Outcomes
A primary purpose of continuous improvement is to improve equity and accessibility
outcomes for different user populations. As a result, the metrics collected byorganizations SHOULD be further evaluated to provide insights into the performance of
their identity management systems for their supported communities and demographics.
Where possible, these efforts SHOULD avoid the collection of additional personal
information and instead use informed analysis of proxy data to help provide indicatorsof potential disparities. This can include comparing and filtering the metrics to identify
deviations in performance across different user populations based on other available
data such as zip code, geographic region, age, or sex.
Organizations are encouraged to consult the OMB Report A Vision for Equitable
Data: Recommendations from the Equitable Data Working Group [EO13985-vision]for guidance on incorporating performance metrics into equity assessments acrossdemographic groups and generating disaggregated statistical estimates to assess
equitable performance outcomes.
3.6. Redress
An important part of designing services that support a wide range of populations is theinclusion of processes to adjudicate issues and provide redress3 as warranted. Service
failures, disputes, and other issues tend to arise as part of normal operations, and theirimpact can vary broadly, from minor inconveniences to major disruptions or damage.
Barriers to access, as well as cybersecurity incidents and data breaches, have real-worldconsequences for affected individuals. Furthermore, the same issue experienced by
one person or community as an inconvenience can have a disproportionately damaging
impacts on other individuals and communities, particularly those that are currently
experiencing other harms or barriers. Left unchecked, these issues can result in harmsthat exacerbate existing inequities and allow systemic cycles of exclusion to continue.
To enable equitable access to critical services while deterring identity-related fraud andcybersecurity threats, it is essential for organizations to plan for potential issues and todesign redress approaches that aim to be fair, transparent, easy for legitimate claimants
to navigate, and resistant to exploitation attempts.
Understanding when and how harms might be occurring is a critical first step fororganizations to take informed action. Continuous evaluation and improvement
programs can play a key role in identifying instances and patterns of potential harm.
3 Redress generally refers to a remedy that is made after harm occurs.

48

NIST SP 800-63-4 2pd
August 2024

1758
1759
1760
1761
1762
1763

1764
1765
1766

1767
1768

Digital Identity Guidelines

Moreover, there may be business processes in place outside of those establishedto support identity management that can be leveraged as part of a comprehensive
approach to issue adjudication and redress. Beyond these activities, additional practices
can be implemented to ensure that users of identity management systems are able
to voice their concerns and have a path to redress. Requirements for these practices
include:• RPs and CSPs SHALL enable people to convey grievances and seek redress throughan issue handling process that is documented, accessible, trackable, and usable by
all people, and whose instructions are easy to find on a public-facing website.
• RPs and CSPs SHALL institute a governance model, including documented roles
and responsibilities, for implementing this issue handling process.

1770• The issue handling process SHALL be implemented as a dedicated function that
includes:1771– Procedures for the impartial review of evidence pertinent to issues;

1769

1773

– Procedures for requesting and collecting additional evidence that informs theissues; and1774– Procedures to expeditiously resolve issues and determine corrective action.

1772

1775
1776
1777

1778
1779
1780

1781
1782
1783
1784

1785
1786

1787
1788
1789
1790
1791

• RPs and CSPs SHALL make human support personnel available to intervene andoverride issue adjudication outputs generated by algorithmic support mechanisms,
such as chatbots.
• RPs and CSPs SHALL educate support personnel on issue handling proceduresfor the digital identity management system, the avenues for redress, and thealternatives available to gain access to services.
• RPs and CSPs SHALL implement a process for personnel and technologies thatprovides support functions to report major barriers that end users face andcommonly expressed grievances. This process SHALL enable tracing (e.g.,
who/what is reported) and tracking (e.g. progress/state of action taken).
• RPs and CSPs SHALL incorporate findings derived from the issue handling process
into continuous evaluation and improvement activities.
Organizations are encouraged to consider these and other emerging redress practices.
Prior to adopting any new redress practice, including supporting technology,
organizations SHOULD test the practice with target populations to avoid the introductionof unintended consequences, particularly those that may counteract or contradict thegoals associated with redress.

49

NIST SP 800-63-4 2pd
August 2024

1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804

1805
1806
1807
1808
1809
1810
1811

1812
1813
1814
1815
1816

1817
1818
1819
1820
1821
1822
1823

1824
1825

1826
1827
1828
1829

Digital Identity Guidelines

3.7. Cybersecurity, Fraud, and Identity Program Integrity
Identity solutions should not operate in a vacuum. Close coordination of identity
functions with teams that are responsible for cybersecurity, privacy, threat intelligence,
fraud detection, and program integrity can enable a more complete protection ofbusiness capabilities, while constantly improving identity solution capabilities. For
example, payment fraud data collected by program integrity teams could provide
indicators of compromised subscriber accounts and potential weaknesses in identity
proofing implementations. Similarly, threat intelligence teams may learn of new
TTPs that Could impact identity proofing, authentication, and federation processes.
Organizations SHALL establish consistent mechanisms for the exchange of information
between critical internal security and fraud stakeholders. Organizations SHOULD do thesame for external stakeholders and identity services that are part of the protection planfor their online services.
When supporting identity service providers (e.g., CSPs) are external to an organization,
the exchange of data related to security, fraud, and other RP functions may becomplicated by regulation or policy. However, establishing the necessary mechanisms
and guidelines to enable effective information-sharing SHOULD be considered incontractual and legal mechanisms. All data collected, transmitted, or shared SHALL
be minimized and subject to a detailed privacy and legal assessment by the generating
entity.
This section is meant to address coordination and integration with various organizational
functional teams to achieve better outcomes for the identity functions. Ideally, such
coordination is performed throughout the risk management process and operations
lifecycle. Companion volumes [SP800-63A], [SP800-63B], and [SP800-63C] provide
specific fraud mitigation requirements related to each of the identity functions.
3.8. Artificial Intelligence (AI) and Machine Learning (ML) in Identity Systems
Identity solutions have used and will continue to use AI and ML for multiple purposes,
such as improving the performance of biometric matching systems, documenting
authentication, detecting fraud, and even assisting users (e.g., chatbots). The potential
applications of AI/ML are extensive. They also introduce distinct risks and potential
issues, including disparate outcomes, biased outputs, and the exacerbation of existing
inequities and access issues.
The following requirements apply to all uses of AI and ML regardless of how they areused in identity systems:• All uses of AI and ML SHALL be documented and communicated to organizations
that rely on these systems. The use of integrated technologies that leverage AI
and ML by CSPs, IdPs, or verifiers SHALL be disclosed to all RPs that make accessdecisions based on information from these systems.
50

NIST SP 800-63-4 2pd
August 2024

1830
1831
1832
1833
1834

1835
1836
1837
1838
1839

1840
1841
1842
1843
1844
1845

Digital Identity Guidelines• All organizations that use AI and ML SHALL provide information to any entities
that use their technology on the methods and techniques used for training
their models, a description of the data sets used in training, information on thefrequency of model updates, and the results of all testing completed on theiralgorithms.
• All organizations that use AI and ML systems or rely on services that use thesesystems SHALL implement NIST AI Risk Management Framework ([NISTAIRMF])
to evaluate the risks that may be introduced by the use of AI and ML. 4. All
organizations that use AI and ML SHALL consult [SP1270], Towards a Standard forManaging Bias in Artificial Intelligence.
NIST continues to advance efforts to promote safe and trustworthy AI implementations
through a number of venues. In particular, the U.S. AI Safety Institute, housed at NIST
[US-AI-Safety-Inst], is creating a portfolio of safety-focused resources, guidance, andtools that can improve how organizations assess, deploy, and manage their AI systems.
Organizations are encouraged to follow the U.S. AI Safety Institute’s efforts and make useof their resources.

51

NIST SP 800-63-4 2pd
August 2024

1846

References

1847

This section is informative.

1848
1849
1850
1851

1852
1853
1854
1855
1856

1857
1858
1859
1860
1861

1862
1863
1864
1865
1866
1867

1868
1869
1870
1871
1872

1873
1874
1875
1876
1877

1878
1879
1880
1881

Digital Identity Guidelines[A-130] Office of Management and Budget (2016) Managing Information as a Strategic
Resource. (The White House, Washington, DC), OMB Circular A-130, July 28, 2016.
Available at https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/
OMB/circulars/a130/a130revised.pdf[EO13985] Biden J (2021) Advancing Racial Equity and Support for Underserved
Communities Through the Federal Government. (The White House, Washington, DC),
Executive Order 13985, January 25, 2021. https://www.federalregister.gov/documents/
2021/01/25/2021-01753/advancing-racial-equity-and-support-for-underservedcommunities-through-the-federal-government[EO13985-vision] Office of Management and Budget (2022) A Vision for Equitable
Data: Recommendations from the Equitable Data Working Group. (The White House,
Washington, DC), OMB Report Pursuant to Executive Order 13985, April 22, 2022. https://www.whitehouse.gov/wp-content/uploads/2022/04/eo13985-vision-for-equitabledata.pdf[EO14012] Biden J (2021) Restoring Faith in Our Legal Immigration Systems andStrengthening Integration and Inclusion Efforts for New Americans. (The White House,
Washington, DC), Executive Order 14012, February 02, 2021. https://www.whitehouse.
gov/briefing-room/presidential-actions/2021/02/02/executive-order-restoring-faith-inour-legal-immigration-systems-and-strengthening-integration-and-inclusion-efforts-fornew-americans/[EO14058] Biden J (2021) Transforming Federal Customer Experience and Service
Delivery to Rebuild Trust in Government. (The White House, Washington, DC), Executive
Order 14058, December 13, 2021. https://www.federalregister.gov/documents/2021/
12/16/2021-27380/transforming-federal-customer-experience-and-service-delivery-torebuild-trust-in-government[EO14091] Biden J (2023) Further Advancing Racial Equity and Support for Underserved
Communities Through the Federal Government. (The White House, Washington, DC),
Executive Order 14091, February 16, 2023. https://www.whitehouse.gov/briefingroom/presidential-actions/2023/02/16/executive-order-on-further-advancing-racialequity-and-support-for-underserved-communities-through-the-federal-government/[FIPS199] National Institute of Standards and Technology (2004) Standards for Security
Categorization of Federal Information and Information Systems. (U.S. Department ofCommerce, Washington, DC), Federal Information Processing Standards Publication(FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199

52

NIST SP 800-63-4 2pd
August 2024

1882
1883
1884
1885

1886
1887

1888
1889
1890

1891
1892
1893
1894

1895
1896
1897
1898

1899
1900
1901

1902
1903
1904
1905

1906
1907
1908
1909

1910
1911
1912
1913

1914
1915
1916

Digital Identity Guidelines[FIPS201] National Institute of Standards and Technology (2022) Personal Identity
Verification (PIV) of Federal Employees and Contractors. (U.S. Department of Commerce,
Washington, DC), Federal Information Processing Standards Publication (FIPS) 201-3.
https://doi.org/10.6028/NIST.FIPS.201-3[FISMA] Federal Information Security Modernization Act of 2014, Pub. L. 113-283, 128
Stat. 3073. https://www.govinfo.gov/app/details/PLAW-113publ283[ISO/IEC9241-11] International Standards Organization (2018) ISO/IEC 9241-11
Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts(ISO, Geneva, Switzerland). Available at https://www.iso.org/standard/63500.html[M-03-22] Office of Management and Budget (2003) OMB Guidance for Implementing
the Privacy Provisions of the E-Government Act of 2002. (The White House, Washington,
DC), OMB Memorandum M-03-22, September 26, 2003. Available at https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html[M-19-17] Office of Management and Budget (2019) Enabling Mission Delivery throughImproved Identity, Credential, and Access Management. (The White House, Washington,
DC), OMB Memorandum M-19-17, May 21, 2019. Available at https://www.whitehouse.
gov/wp-content/uploads/2019/05/M-19-17.pdf[NISTAIRMF] Tabassi E (2023) Artificial Intelligence Risk Management Framework (AIRMF 1.0). (National Institute of Standards and Technology (U.S.), Gaithersburg, MD),NIST AI 100-1. https://doi.org/10.6028/NIST.AI.100-1[NISTIR8062] Brooks SW, Garcia ME, Lefkovitz NB, Lightman S, Nadeau EM (2017) An
Introduction to Privacy Engineering and Risk Management in Federal Systems. (National
Institute of Standards and Technology, Gaithersburg, MD), NIST Interagency or Internal
Report (IR) 8062. https://doi.org/10.6028/NIST.IR.8062[NISTRMF] Joint Task Force (2018) Risk Management Framework for Information Systems
and Organizations: A System Life Cycle Approach for Security and Privacy. (National
Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP)
800-37, Rev. 2. https://doi.org/10.6028/NIST.SP.800-37r2[NISTPF] National Institute of Standards and Technology (2020) NIST Privacy Framework:
A Tool for Improving Privacy Through Enterprise Risk Management, Version 1.0.
(National Institute of Standards and Technology, Gaithersburg, MD), NIST Cybersecurity
White Paper (CSWP) NIST CSWP 10. https://doi.org/10.6028/NIST.CSWP.10[PrivacyAct] Privacy Act of 1974, Pub. L. 93-579, 5 U.S.C. § 552a, 88 Stat. 1896 (1974).
https://www.govinfo.gov/content/pkg/USCODE-2018-title5/pdf/USCODE-2018-title5partI-chap5-subchapII-sec552a.pdf

53

NIST SP 800-63-4 2pd
August 2024

1917
1918
1919

1920
1921
1922
1923

1924
1925
1926
1927

1928
1929
1930

1931
1932
1933

1934
1935
1936
1937

1938
1939
1940
1941

1942
1943
1944
1945

1946
1947
1948
1949

1950
1951
1952
1953

Digital Identity Guidelines[RFC5246] Rescorla E, Dierks T (2008) The Transport Layer Security (TLS) Protocol Version
1.2. (Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5246.
https://doi.org/10.17487/RFC5246[RFC5280] Cooper D, Santesson S, Farrell S, Boeyen S, Housley R, Polk W (2008) Internet
X.509 Public Key Infrastructure Certification and Certificate Revocation List (CRL) Profile.
(Internet Engineering Task Force (IETF)), IETF Request for Comments (RFC) 5280. https://doi.org/10.17487/RFC5280[RFC9325] Sheffer Y, Saint-Andre P, Fossati T (2022) Recommendations for Secure Use of
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). (Internet
Engineering Task Force (IETF)), IETF Request for Comments (RFC) 9325. https://doi.org/
10.17487/RFC9325[Section508] Section 508 of the Rehabilitation Act of 1973 (2011), 29 U.S.C. § 794(d).
https://www.govinfo.gov/content/pkg/USCODE-2011-title29/html/USCODE-2011title29-chap16-subchapV-sec794d.htm[SP800-30] Blank R, Gallagher P (2012) Guide for Conducting Risk Assessments. (National
Institute of Standards and Technology, Gaithersburg, MD) NIST Special Publication (SP)
800-30 Revision 1. https://doi.org/10.6028/NIST.SP.800-30r1[SP800-52] McKay K, Cooper D (2019) Guidelines for the Selection, Configuration, andUse of Transport Layer Security (TLS) Implementations. (National Institute of Standards
and Technology), NIST Special Publication (SP) 800-52 Rev. 2. https://doi.org/10.6028/
NIST.SP.800-52r2[SP800-53] Joint Task Force (2020) Security and Privacy Controls for Information Systems
and Organizations. (National Institute of Standards and Technology, Gaithersburg, MD),NIST Special Publication (SP) 800-53 Rev. 5, Includes updates as of December 10, 2020.
https://doi.org/10.6028/NIST.SP.800-53r5[SP800-57Part1] Barker EB (2020) Recommendation for Key Management: Part 1 –General. (National Institute of Standards and Technology, Gaithersburg, MD), NIST
Special Publication (SP) 800-57 Part 1, Rev. 5. https://doi.org/10.6028/NIST.SP.80057pt1r5[SP800-63A] Temoshok D, Abruzzi C, Choong YY, Fenton JL, Galluzzo R, LaSalle C,
Lefkovitz N, Regenscheid A (2024) Digital Identity Guidelines: Identity Proofing andEnrollment. (National Institute of Standards and Technology, Gaithersburg, MD), NIST
Special Publication (SP) 800-63A-4 2pd. https://doi.org/10.6028/NIST.SP.800-63a-4.2pd[SP800-63B] Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Galluzzo
R, Richer JP (2024) Digital Identity Guidelines: Authentication and Authenticator
Management. (National Institute of Standards and Technology, Gaithersburg, MD), NIST
Special Publication (SP) 800-63B-4 ipd. https://doi.org/10.6028/NIST.SP.800-63b-4.2pd
54

NIST SP 800-63-4 2pd
August 2024

1954
1955
1956
1957

1958
1959
1960
1961

1962
1963
1964
1965

1966
1967

Digital Identity Guidelines[SP800-63C] Temoshok D, Richer JP, Choong YY, Fenton JL, Lefkovitz N, Regenscheid
A, Galluzzo R (2024) Digital Identity Guidelines: Federation and Assertions. (National
Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP)
800-63C-4 2pd. https://doi.org/10.6028/NIST.SP.800-63c-4.2pd[SP800-122] McCallister E, Grance T, Scarfone KA (2010) Guide to Protecting theConfidentiality of Personally Identifiable Information (PII). (National Institute ofStandards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-122.
https://doi.org/10.6028/NIST.SP.800-122[SP1270] Schwartz R, Vassilev A, Greene K, Perine L, Burt A, Hall P (2022) Towards a
standard for identifying and managing bias in artificial intelligence. (National Instituteof Standards and Technology (U.S.), Gaithersburg, MD), NIST SP 1270. https://doi.org/10.
6028/NIST.SP.1270[US-AI-Safety-Inst] U.S. Artificial Intelligence Safety Institute (2023) NIST. Available athttps://www.nist.gov/aisi

55

NIST SP 800-63-4 2pd
August 2024

1968

1969
1970

1971
1972

1973
1974

1975
1976

1977
1978

1979
1980

1981
1982

1983
1984

1985
1986

1987
1988

1989
1990

1991
1992

1993
1994

Digital Identity Guidelines

Appendix A. List of Symbols, Abbreviations, and Acronyms
1:1 Comparison
One-to-One Comparison
ABAC
Attribute-Based Access Control
AAL
Authentication Assurance Level
CAPTCHA
Completely Automated Public Turing test to tell Computers and Humans Apart
CSP
Credential Service Provider
CSRF
Cross-Site Request Forgery
XSS
Cross-Site Scripting
DNS
Domain Name System
FACT Act
Fair and Accurate Credit Transaction Act of 2003
FAL
Federation Assurance LevelFEDRAMP
Federal Risk and Authorization Management Program
FMR
False Match Rate
FNMR
False Non-Match Rate

56

NIST SP 800-63-4 2pd
August 2024

1995
1996

1997
1998

1999
2000

2001
2002

2003
2004

2005
2006

2007
2008

2009
2010

2011
2012

2013
2014

2015
2016

2017
2018

2019
2020

2021
2022

Digital Identity Guidelines

IAL
Identity Assurance Level
IdP
Identity Provider
JOSE
JSON Object Signing and Encryption
JWT
JSON Web Token
KBA
Knowledge-Based Authentication
KBV
Knowledge-Based VerificationKDC
Key Distribution Center
MAC
Message Authentication Code
MFA
Multi-Factor Authentication
NARA
National Archives and Records Administration
OTP
One-Time Password
PAD
Presentation Attack Detection
PIA
Privacy Impact Assessment
PII
Personally Identifiable Information
57

NIST SP 800-63-4 2pd
August 2024

2023
2024

2025
2026

2027
2028

2029
2030

2031
2032

2033
2034

2035
2036

2037
2038

2039
2040

2041
2042

2043
2044

2045
2046

2047
2048

2049
2050

Digital Identity Guidelines

PIN
Personal Identification Number
PKI
Public Key Infrastructure
PSTN
Public Switched Telephone Network
RMF
Risk Management Framework
RP
Relying Party
SA&A
Security Authorization & Accreditation
SAML
Security Assertion Markup Language
SAOP
Senior Agency Official for Privacy
SSL
Secure Sockets Layer
SSO
Single Sign-On
SMS
Short Message Service
SORN
System of Records Notice
TEE
Trusted Execution Environment
TLS
Transport Layer Security
58

NIST SP 800-63-4 2pd
August 2024

2051
2052

2053
2054

2055
2056

2057
2058

Digital Identity Guidelines

TPM
Trusted Platform Module
TTP
Tactics, Techniques, and Procedures
VOIP
Voice-Over-IP
XSS
Cross-Site Scripting

59

NIST SP 800-63-4 2pd
August 2024

2059

Appendix B. Glossary

2060This section is informative.

2061
2062
2063
2064

2065
2066
2067

2068
2069
2070

2071
2072
2073

2074
2075
2076

2077
2078
2079

2080
2081

2082
2083
2084
2085
2086

2087
2088

Digital Identity Guidelines

A wide variety of terms are used in the realm of digital identity. While many definitions
are consistent with earlier versions of SP 800-63, some have changed in this revision.
Many of these terms lack a single, consistent definition, warranting careful attention to
how the terms are defined here.
account linking
The association of multiple federated identifiers with a single RP subscriber account, or
the management of those associations.
account recovery
The ability to regain ownership of a subscriber account and its associated informationand privileges.
account resolution
The association of an RP subscriber account with information already held by the RPprior to the federation transaction and outside of a trust agreement.
activation
The process of inputting an activation factor into a multi-factor authenticator to enable
its use for authentication.
activation factor
An additional authentication factor that is used to enable successful authentication witha multi-factor authenticator.
activation secret
A password that is used locally as an activation factor for a multi-factor authenticator.
allowlist
A documented list of specific elements that are allowed, per policy decision. In
federation contexts, this is most commonly used to refer to the list of RPs allowed toconnect to an IdP without subscriber intervention. This concept has historically been
known as a whitelist.
applicantA subject undergoing the processes of identity proofing and enrollment.

60

NIST SP 800-63-4 2pd
August 2024

2089
2090
2091
2092

2093
2094
2095
2096
2097

2098
2099
2100

2101
2102
2103

2104
2105

2106
2107
2108
2109

2110
2111
2112
2113

2114
2115
2116

2117
2118
2119
2120
2121

Digital Identity Guidelines

applicant reference
A representative of the applicant who can vouch for the identity of the applicant, specificattributes related to the applicant, or conditions relative to the context of the individual(e.g., emergency status, homelessness).
approved cryptography
An encryption algorithm, hash function, random bit generator, or similar technique thatis Federal Information Processing Standard (FIPS)-approved or NIST-recommended.
Approved algorithms and techniques are either specified or adopted in a FIPS or NIST
recommendation.
assertion
A statement from an IdP to an RP that contains information about an authentication
event for a subscriber. Assertions can also contain identity attributes for the subscriber.
assertion reference
A data object, created in conjunction with an assertion, that is used by the RP to retrieve
an assertion over an authenticated protected channel.
assertion presentation
The method by which an assertion is transmitted to the RP.
asymmetric keys
Two related keys, comprised of a public key and a private key, that are used to perform
complementary operations such as encryption and decryption or signature verificationand generation.
attestation
Information conveyed to the CSP, generally at the time that an authenticator is bound,describing the characteristics of a connected authenticator or the endpoint involved in
an authentication operation.
attribute
A quality or characteristic ascribed to someone or something. An identity attribute is an
attribute about the identity of a subscriber.
attribute bundle
A package of attribute values and derived attribute values from a CSP. The package
has necessary cryptographic protection to allow validation of the bundle independent
from interaction with the CSP or IdP. Attribute bundles are often used with subscribercontrolled wallets.

61

NIST SP 800-63-4 2pd
August 2024

2122
2123
2124

2125
2126
2127

2128
2129
2130
2131

2132
2133
2134
2135
2136

2137
2138

2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149

2150
2151

2152
2153
2154
2155

Digital Identity Guidelines

attribute provider
The provider of an identity API that provides access to a subscriber’s attributes without
necessarily asserting that the subscriber is present to the RP.
attribute validation
The process or act of confirming that a set of attributes are accurate and associated witha real-life identity. See validation.
attribute value
A complete statement that asserts an identity attribute of a subscriber, independentof format. For example, for the attribute “birthday,” a value could be “12/1/1980” or“December 1, 1980.”
audience restriction
The restriction of a message to a specific target audience to prevent a receiver fromunknowingly processing a message intended for another recipient. In federation
protocols, assertions are audience restricted to specific RPs to prevent an RP fromaccepting an assertion generated for a different RP.
authenticate
See authentication.
authenticated protected channel
An encrypted communication channel that uses approved cryptography where theconnection initiator (client) has authenticated the recipient (server). Authenticatedprotected channels are encrypted to provide confidentiality and protection against
active intermediaries and are frequently used in the user authentication process.
Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC9325]
are examples of authenticated protected channels in which the certificate presented
by the recipient is verified by the initiator. Unless otherwise specified, authenticatedprotected channels do not require the server to authenticate the client. Authenticationof the server is often accomplished through a certificate chain that leads to a trusted
root rather than individually with each server.
authenticated session
See protected session.
authentication
The process by which a claimant proves possession and control of one or moreauthenticators bound to a subscriber account to demonstrate that they are thesubscriber associated with that account.

62

NIST SP 800-63-4 2pd
August 2024

2156
2157

2158
2159
2160

2161
2162
2163
2164
2165
2166
2167

2168
2169
2170
2171
2172

2173
2174
2175

2176
2177
2178
2179
2180
2181

2182
2183
2184
2185

2186
2187
2188
2189

Digital Identity Guidelines

Authentication Assurance Level (AAL)
A category that describes the strength of the authentication process.
authentication factor
The three types of authentication factors are something you know, something you have,and something you are. Every authenticator has one or more authentication factors.
authentication intent
The process of confirming the claimant’s intent to authenticate or reauthenticate byrequiring user intervention in the authentication flow. Some authenticators (e.g., OTPs)
establish authentication intent as part of their operation. Others require a specific step,
such as pressing a button, to establish intent. Authentication intent is a countermeasureagainst use by malware at the endpoint as a proxy for authenticating an attacker without
the subscriber’s knowledge.
authentication protocol
A defined sequence of messages between a claimant and a verifier that demonstrates
that the claimant has possession and control of one or more valid authenticators toestablish their identity, and, optionally, demonstrates that the claimant is communicatingwith the intended verifier.
authentication secret
A generic term for any secret value that an attacker could use to impersonate thesubscriber in an authentication protocol.
These are further divided into short-term authentication secrets, which are only usefulto an attacker for a limited period of time, and long-term authentication secrets, whichallow an attacker to impersonate the subscriber until they are manually reset. The
authenticator secret is the canonical example of a long-term authentication secret, while
the authenticator output — if it is different from the authenticator secret — is usually ashort-term authentication secret.
authenticator
Something that the subscriber possesses and controls (e.g., a cryptographic module orpassword) and that is used to authenticate a claimant’s identity. See authenticator typeand multi-factor authenticator.
authenticator binding
The establishment of an association between a specific authenticator and a subscriber
account that allows the authenticator to be used to authenticate for that subscriber
account, possibly in conjunction with other authenticators.

63

NIST SP 800-63-4 2pd
August 2024

2190
2191
2192
2193
2194

2195
2196

2197
2198
2199

2200
2201

2202
2203
2204
2205
2206
2207
2208

2209
2210

2211
2212
2213
2214
2215

2216
2217
2218

2219
2220

Digital Identity Guidelines

authenticator output
The output value generated by an authenticator. The ability to generate valid
authenticator outputs on demand proves that the claimant possesses and controls
the authenticator. Protocol messages sent to the verifier depend on the authenticator
output, but they may or may not explicitly contain it.
authenticator secret
The secret value contained within an authenticator.
authenticator typeA category of authenticators with common characteristics, such as the types ofauthentication factors they provide and the mechanisms by which they operate.
authenticity
The property that data originated from its purported source.
authoritative source
An entity that has access to or verified copies of accurate information from an issuing
source such that a CSP has high confidence that the source can confirm the validity of
the identity attributes or evidence supplied by an applicant during identity proofing.
An issuing source may also be an authoritative source. Often, authoritative sources are
determined by a policy decision of the agency or CSP before they can be used in theidentity proofing validation phase.
authorize
A decision to grant access, typically automated by evaluating a subject’s attributes.
authorized party
In federation, the organization, person, or entity that is responsible for making decisions
regarding the release of information within the federation transaction, most notably
subscriber attributes. This is often the subscriber (when runtime decisions are used) or
the party operating the IdP (when allowlists are used).
back-channel communication
Communication between two systems that relies on a direct connection without using
redirects through an intermediary such as a browser.
bearer assertion
An assertion that can be presented on its own as proof of the identity of the presenter.

64

NIST SP 800-63-4 2pd
August 2024

2221
2222
2223
2224
2225

2226
2227
2228

2229
2230
2231
2232
2233
2234
2235

2236
2237
2238

2239
2240
2241
2242
2243
2244
2245
2246
2247

2248
2249

2250
2251
2252

2253
2254

Digital Identity Guidelines

biometric reference
One or more stored biometric samples, templates, or models attributed to an individual
and used as the object of biometric comparison in a database, such as a facial image
stored digitally on a passport, fingerprint minutiae template on a National ID card or
Gaussian Mixture Model for speaker recognition.
biometric sample
An analog or digital representation of biometric characteristics prior to biometric feature
extraction, such as a record that contains a fingerprint image.
biometrics
Automated recognition of individuals based on their biological or behavioral
characteristics. Biological characteristics include but are not limited to fingerprints, palm
prints, facial features, iris and retina patterns, voiceprints, and vein patterns. Behavioral
characteristics include but are not limited to keystrokes, angle of holding a smart phone,screen pressure, typing speed, mouse or mobile phone movements, and gyroscope
position.
blocklist
A documented list of specific elements that are blocked, per policy decision. This
concept has historically been known as a blacklist.
challenge-response protocol
An authentication protocol in which the verifier sends the claimant a challenge (e.g.,a random value or nonce) that the claimant combines with a secret (e.g., by hashing
the challenge and a shared secret together or by applying a private-key operation
to the challenge) to generate a response that is sent to the verifier. The verifier can
independently verify the response generated by the claimant (e.g., by re-computing
the hash of the challenge and the shared secret and comparing to the response or
performing a public-key operation on the response) and establish that the claimantpossesses and controls the secret.
claimant
A subject whose identity is to be verified using one or more authentication protocols.
claimed address
The physical location asserted by a subject where they can be reached. It includes theindividual’s residential street address and may also include their mailing address.
claimed identity
An applicant’s declaration of unvalidated and unverified personal attributes.

65

NIST SP 800-63-4 2pd
August 2024

2255
2256
2257
2258
2259

2260
2261
2262

2263
2264
2265

2266
2267
2268
2269

2270
2271
2272
2273

2274
2275
2276
2277

2278
2279
2280
2281
2282
2283

2284
2285
2286
2287

2288
2289
2290

Digital Identity Guidelines

compensating controls
Alternative controls to the normative controls for the assessed and selected xALs of anorganization based on that organization’s mission, risk tolerance, business processes,
and risk assessments and considerations for the privacy, usability, and equity of the
populations served by the online service.
controls
Policies, procedures, guidelines, practices, or organizational structures that manage
security, privacy, and other risks. See supplemental controls and compensating controls
core attributes
The set of identity attributes that the CSP has determined and documented to berequired for identity proofing.
credential
An object or data structure that authoritatively binds an identity — via an identifier— and (optionally) additional attributes, to at least one authenticator possessed andcontrolled by a subscriber.
A credential is issued, stored, and maintained by the CSP. Copies of information from thecredential can be possessed by the subscriber, typically in the form of one or more digital
certificates that are often contained in an authenticator along with their associatedprivate keys.
credential service provider (CSP)
A trusted entity whose functions include identity proofing applicants to the identity
service and registering authenticators to subscriber accounts. A CSP may be an
independent third party.
credible source
An entity that can provide or validate the accuracy of identity evidence and attributeinformation. A credible source has access to attribute information that was validated
through an identity proofing process or that can be traced to an authoritative source,or it maintains identity attribute information obtained from multiple sources that ischecked for data correlation for accuracy, consistency, and currency.
cross-site request forgery (CSRF)
An attack in which a subscriber who is currently authenticated to an RP and connected
through a secure session browses an attacker’s website, causing the subscriber tounknowingly invoke unwanted actions at the RP.
For example, if a bank website is vulnerable to a CSRF attack, it may be possible for a
subscriber to unintentionally authorize a large money transfer by clicking on a malicious
link in an email while a connection to the bank is open in another browser window.
66

NIST SP 800-63-4 2pd
August 2024

2291
2292
2293
2294
2295
2296

2297
2298
2299

2300
2301
2302
2303
2304

2305
2306
2307

2308
2309

2310
2311
2312
2313
2314
2315
2316

2317
2318
2319
2320

2321
2322

2323
2324
2325

Digital Identity Guidelines

cross-site scripting (XSS)
A vulnerability that allows attackers to inject malicious code into an otherwise benign
website. These scripts acquire the permissions of scripts generated by the target website
to compromise the confidentiality and integrity of data transfers between the website
and clients. Websites are vulnerable if they display user-supplied data from requests orforms without sanitizing the data so that it is not executable.
cryptographic authenticator
An authenticator that proves possession of an authentication secret through directcommunication with a verifier through a cryptographic authentication protocol.
cryptographic key
A value used to control cryptographic operations, such as decryption, encryption,
signature generation, or signature verification. For the purposes of these guidelines,
key requirements shall meet the minimum requirements stated in Table 2 of[SP800-57Part1]. See asymmetric keys or symmetric keys.
cryptographic module
A set of hardware, software, or firmware that implements approved security functions
including cryptographic algorithms and key generation.
data integrity
The property that data has not been altered by an unauthorized entity.
derived attribute value
A statement that asserts a limited identity attribute of a subscriber without containing
the attribute value from which it is derived, independent of format. For example, insteadof requesting the attribute “birthday,” a derived value could be “older than 18”. Insteadof requesting the attribute for “physical address,” a derived value could be “currently
residing in this district.” Previous versions of these guidelines referred to this construct
as an “attribute reference.”
digital authentication
The process of establishing confidence in user identities that are digitally presented
to a system. In previous editions of SP 800-63, this was referred to as electronic
authentication.
digital identity
An attribute or set of attributes that uniquely describes a subject within a given context.
Digital Identity Acceptance Statement (DIAS)
Documents the results of the digital identity risk management process. This includes theimpact assessment, initial assurance level selection, and tailoring process.
67

NIST SP 800-63-4 2pd
August 2024

2326
2327
2328
2329
2330

2331
2332
2333

2334
2335
2336

2337
2338

2339
2340
2341
2342

2343
2344
2345

2346
2347
2348
2349

2350
2351
2352
2353
2354
2355
2356
2357

2358
2359

Digital Identity Guidelines

digital signature
An asymmetric key operation in which the private key is used to digitally sign data andthe public key is used to verify the signature. Digital signatures provide authenticity
protection, integrity protection, and non-repudiation support but not confidentiality or
replay attack protection.
digital transaction
A discrete digital event between a user and a system that supports a business orprogrammatic purpose.
disassociability
Enabling the processing of PII or events without association to individuals or devices
beyond the operational requirements of the system. [NISTIR8062]
electronic authentication (e-authentication)
See digital authentication.
endpoint
Any device that is used to access a digital identity on a network, such as laptops,
desktops, mobile phones, tablets, servers, Internet of Things devices, and virtualenvironments.
enrollment
The process through which a CSP/IdP provides a successfully identity-proofed applicant
with a subscriber account and binds authenticators to grant persistent access.
entropy
The amount of uncertainty that an attacker faces to determine the value of a secret.
Entropy is usually stated in bits. A value with n bits of entropy has the same degree of
uncertainty as a uniformly distributed n-bit random value.
equityThe consistent and systematic fair, just, and impartial treatment of all individuals,
including individuals who belong to underserved communities that have been denied
such treatment, such as Black, Latino, and Indigenous and Native American persons,
Asian Americans and Pacific Islanders, and other persons of color; members of religious
minorities; lesbian, gay, bisexual, transgender, and queer (LGBTQ+) persons; persons withdisabilities; persons who live in rural areas; and persons otherwise adversely affected bypersistent poverty or inequality. [EO13985]
factorSee authentication factor
68

NIST SP 800-63-4 2pd
August 2024

2360
2361
2362
2363
2364
2365
2366
2367

2368
2369

2370
2371
2372
2373

2374
2375
2376

2377
2378
2379

2380
2381

2382
2383
2384
2385

2386
2387
2388

2389
2390
2391

Digital Identity Guidelines

Federal Information Processing Standard (FIPS)
Under the Information Technology Management Reform Act (Public Law 104-106),
the Secretary of Commerce approves the standards and guidelines that the National
Institute of Standards and Technology (NIST) develops for federal computer systems.
NIST issues these standards and guidelines as Federal Information Processing Standards(FIPS) for government-wide use. NIST develops FIPS when there are compelling federal
government requirements, such as for security and interoperability, and there are no
acceptable industry standards or solutions. See background information for more details.
FIPS documents are available online on the FIPS home page: https://www.nist.gov/itl/
fips.cfm
federated identifier
The combination of a subject identifier within an assertion and an identifier for the
IdP that issued that assertion. When combined, these pieces of information uniquely
identify the subscriber in the context of a federation transaction.
federation
A process that allows for the conveyance of identity and authentication information
across a set of networked systems.
Federation Assurance Level (FAL)
A category that describes the process used in a federation transaction to communicate
authentication events and subscriber attributes to an RP.
federation protocol
A technical protocol that is used in a federation transaction between networked systems.
federation proxy
A component that acts as a logical RP to a set of IdPs and a logical IdP to a set of RPs,
bridging the two systems with a single component. These are sometimes referred to as“brokers.”
federation transaction
A specific instance of processing an authentication using a federation process for a
specific subscriber by conveying an assertion from an IdP to an RP.
front-channel communication
Communication between two systems that relies on passing messages through anintermediary, such as using redirects through the subscriber’s browser.

69

NIST SP 800-63-4 2pd
August 2024

2392
2393
2394

2395
2396

2397
2398

2399
2400
2401
2402

2403
2404

2405
2406

2407
2408
2409

2410
2411
2412
2413
2414
2415

2416
2417
2418

2419
2420
2421

2422
2423
2424

Digital Identity Guidelines

hash function
A function that maps a bit string of arbitrary length to a fixed-length bit string. Approved
hash functions satisfy the following properties:
1. One-way — It is computationally infeasible to find any input that maps to any prespecified output.
2. Collision-resistant — It is computationally infeasible to find any two distinct inputs
that map to the same output.
identifier
A data object that is associated with a single, unique entity (e.g., individual, device, or
session) within a given context and is never assigned to any other entity within that
context.
identitySee digital identity
identity API
A protected API accessed by an RP to access the attributes of a specific subscriber.
Identity Assurance Level (IAL)
A category that conveys the degree of confidence that the subject’s claimed identity istheir real identity.
identity evidence
Information or documentation that supports the real-world existence of the claimed
identity. Identity evidence may be physical (e.g., a driver’s license) or digital (e.g., amobile driver’s license or digital assertion). Evidence must support both validation (i.e.,
confirming authenticity and accuracy) and verification (i.e., confirming that the applicant
is the true owner of the evidence).
identity proofing
The processes used to collect, validate, and verify information about a subject toestablish assurance in the subject’s claimed identity.
identity provider (IdP)
The party in a federation transaction that creates an assertion for the subscriber andtransmits the assertion to the RP.
identity resolution
The process of collecting information about an applicant to uniquely distinguish an
individual within the context of the population that the CSP serves.
70

NIST SP 800-63-4 2pd
August 2024

2425
2426

2427
2428
2429
2430

2431
2432
2433

2434
2435
2436
2437

2438
2439

2440
2441
2442

2443
2444
2445

2446
2447

2448
2449
2450
2451

2452
2453
2454
2455

Digital Identity Guidelines

identity verification
See verification
injection attack
An attack in which an attacker supplies untrusted input to a program. In the context offederation, the attacker presents an untrusted assertion or assertion reference to the RP
in order to create an authenticated session with the RP.
issuing source
An authority responsible for the generation of data, digital evidence (i.e., assertions), or
physical documents that can be used as identity evidence.
knowledge-based verification (KBV)
A process of validating knowledge of personal or private information associated with anindividual for the purpose of verifying the claimed identity of an applicant. KBV does notinclude collecting personal attributes for the purposes of identity resolution.
legal person
An individual, organization, or company with legal rights.
login
Establishment of an authenticated session between a person and a system. Also known
as “sign in”, “log on”, and “sign on.”manageability
Providing the capability for the granular administration of personally identifiable
information, including alteration, deletion, and selective disclosure. [NISTIR8062]
memorized secretSee password.
message authentication code (MAC)
A cryptographic checksum on data that uses a symmetric key to detect both accidental
and intentional modifications of the data. MACs provide authenticity and integrity
protection, but not non-repudiation protection.
mobile code
Executable code that is normally transferred from its source to another computer systemfor execution. This transfer is often through the network (e.g., JavaScript embedded in a
web page) but may transfer through physical media as well.

71

NIST SP 800-63-4 2pd
August 2024

2456
2457
2458
2459
2460

2461
2462
2463
2464

2465
2466

2467
2468
2469
2470
2471
2472

2473
2474
2475
2476
2477
2478

2479
2480
2481

2482
2483
2484
2485

2486
2487
2488

Digital Identity Guidelines

multi-factor authentication (MFA)
An authentication system that requires more than one distinct type of authentication
factor for successful authentication. MFA can be performed using a multi-factor
authenticator or by combining single-factor authenticators that provide different types
of factors.
multi-factor authenticator
An authenticator that provides more than one distinct authentication factor, such as a
cryptographic authentication device with an integrated biometric sensor that is required
to activate the device.
natural person
A real-life human being, not synthetic or artificial.
network
An open communications medium, typically the Internet, used to transport messages
between the claimant and other parties. Unless otherwise stated, no assumptions are
made about the network’s security; it is assumed to be open and subject to active (e.g.,
impersonation, session hijacking) and passive (e.g., eavesdropping) attacks at any point
between the parties (e.g., claimant, verifier, CSP, RP).
nonce
A value used in security protocols that is never repeated with the same key. For example,
nonces used as challenges in challenge-response authentication protocols must not be
repeated until authentication keys are changed. Otherwise, there is a possibility of a
replay attack. Using a nonce as a challenge is a different requirement than a randomchallenge, because a nonce is not necessarily unpredictable.
non-repudiation
The capability to protect against an individual falsely denying having performed aparticular transaction.
offline attack
An attack in which the attacker obtains some data (typically by eavesdropping on anauthentication transaction or by penetrating a system and stealing security files) thatthe attacker is able to analyze in a system of their own choosing.
one-to-one (1:1) comparison
The process in which a biometric sample from an individual is compared to a biometricreference to produce a comparison score.

72

NIST SP 800-63-4 2pd
August 2024

2489
2490
2491

2492
2493
2494

2495
2496

2497
2498

2499
2500
2501
2502

2503
2504
2505
2506
2507

2508
2509

2510
2511

2512
2513
2514
2515

2516
2517
2518
2519

Digital Identity Guidelines

online attack
An attack against an authentication protocol in which the attacker either assumes therole of a claimant with a genuine verifier or actively alters the authentication channel.
online guessing attack
An attack in which an attacker performs repeated logon trials by guessing possible valuesof the authenticator output.
online service
A service that is accessed remotely via a network, typically the internet.
pairwise pseudonymous identifier
A pseudonymous identifier generated by an IdP for use at a specific RP.
passphrase
A password that consists of a sequence of words or other text that a claimant uses toauthenticate their identity. A passphrase is similar to a password in usage but is generally
longer for added security.
password
A type of authenticator consisting of a character string that is intended to be memorized
or memorable by the subscriber to permit the claimant to demonstrate something theyknow as part of an authentication process. Passwords are referred to as memorized
secrets in the initial release of SP 800-63B.
personal identification number (PIN)
A password that typically consists of only decimal digits.
personal information
See personally identifiable information.
personally identifiable information (PII)
Information that can be used to distinguish or trace an individual’s identity, either
alone or when combined with other information that is linked or linkable to a specificindividual. [A-130]
personally identifiable information processing
An operation or set of operations performed upon personally identifiable informationthat can include the collection, retention, logging, generation, transformation, use,
disclosure, transfer, or disposal of personally identifiable information.

73

NIST SP 800-63-4 2pd
August 2024

2520
2521
2522
2523
2524

2525
2526
2527
2528

2529
2530
2531
2532

2533
2534
2535

2536
2537

2538
2539
2540
2541

2542
2543
2544

2545
2546
2547
2548
2549

2550
2551
2552
2553

Digital Identity Guidelines

pharming
An attack in which an attacker corrupts an infrastructure service such as DNS (e.g.,
Domain Name System [DNS]) and causes the subscriber to be misdirected to a forgedverifier/RP, which could cause the subscriber to reveal sensitive information, download
harmful software, or contribute to a fraudulent act.
phishing
An attack in which the subscriber is lured (usually through an email) to interact witha counterfeit verifier/RP and tricked into revealing information that can be used tomasquerade as that subscriber to the real verifier/RP.
phishing resistance
The ability of the authentication protocol to prevent the disclosure of authentication
secrets and valid authenticator outputs to an impostor verifier without reliance on thevigilance of the claimant.
physical authenticator
An authenticator that the claimant proves possession of as part of an authentication
process.
possession and control of an authenticator
The ability to activate and use the authenticator in an authentication protocol.
practice statement
A formal statement of the practices followed by the parties to an authentication process(e.g., CSP or verifier). It usually describes the parties’ policies and practices and canbecome legally binding.
predictability
Enabling reliable assumptions by individuals, owners, and operators about PII and its
processing by an information system. [NISTIR8062]
private key
In asymmetric key cryptography, the private key (i.e., a secret key) is a mathematical
key used to create digital signatures and, depending on the algorithm, decrypt
messages or files that are encrypted with the corresponding public key. In symmetrickey cryptography, the same private key is used for both encryption and decryption.
processing
Operation or set of operations performed upon PII that can include, but is not limited to,the collection, retention, logging, generation, transformation, use, disclosure, transfer,and disposal of PII. [NISTIR8062]
74

NIST SP 800-63-4 2pd
August 2024

2554
2555
2556

2557
2558
2559
2560
2561
2562

2563
2564
2565
2566

2567
2568
2569
2570

2571
2572
2573
2574
2575

2576
2577
2578

2579
2580
2581
2582
2583

2584
2585
2586

2587
2588

Digital Identity Guidelines

presentation attack
Presentation to the biometric data capture subsystem with the goal of interfering withthe operation of the biometric system.
presentation attack detection (PAD)
Automated determination of a presentation attack. A subset of presentation attack
determination methods, referred to as liveness detection, involves the measurement andanalysis of anatomical characteristics or voluntary or involuntary reactions, to determine
if a biometric sample is being captured from a living subject that is present at the point of
capture.
process assistant
An individual who provides support for the proofing process but does not support
decision-making or risk-based evaluation (e.g., translation, transcription, or accessibility
support).
proofing agent
An agent of the CSP who is trained to attend identity proofing sessions and can makelimited risk-based decisions – such as physically inspecting identity evidence and making
physical comparisons of the applicant to identity evidence.
Privacy Impact Assessment (PIA)
A method of analyzing how personally identifiable information (PII) is collected, used,shared, and maintained. PIAs are used to identify and mitigate privacy risks throughout
the development lifecycle of a program or system. They also help ensure that handlinginformation conforms to legal, regulatory, and policy requirements regarding privacy.
protected session
A session in which messages between two participants are encrypted and integrity isprotected using a set of shared secrets called “session keys.”
A protected session is said to be authenticated if — during the session — one participant
proves possession of one or more authenticators in addition to the session keys,
and if the other party can verify the identity associated with the authenticators. If
both participants are authenticated, the protected session is said to be mutuallyauthenticated.
Provisioning API
A protected API that allows an RP to access identity attributes for multiple subscribers
for the purposes of provisioning and managing RP subscriber accounts.
pseudonym
A name other than a legal name.
75

NIST SP 800-63-4 2pd
August 2024

2589
2590

2591
2592
2593
2594

2595
2596
2597

2598
2599
2600
2601
2602

2603
2604
2605
2606

2607
2608
2609

2610
2611

2612
2613
2614

2615
2616
2617

2618
2619
2620
2621

Digital Identity Guidelines

pseudonymity
The use of a pseudonym to identify a subject.
pseudonymous identifier
A meaningless but unique identifier that does not allow the RP to infer anything
regarding the subscriber but that does permit the RP to associate multiple interactions
with a single subscriber.
public key
The public part of an asymmetric key pair that is used to verify signatures or encryptdata.
public key certificate
A digital document issued and digitally signed by the private key of a certificate authoritythat binds an identifier to a subscriber’s public key. The certificate indicates that thesubscriber identified in the certificate has sole control of and access to the private key.
See also [RFC5280].
public key infrastructure (PKI)
A set of policies, processes, server platforms, software, and workstations used toadminister certificates and public-_private key_ pairs, including the ability to issue,
maintain, and revoke public key certificates.
reauthentication
The process of confirming the subscriber’s continued presence and intent to beauthenticated during an extended usage session.
registration
See enrollment.
relying party (RP)An entity that relies upon a verifier’s assertion of a subscriber’s identity, typically toprocess a transaction or grant access to information or a system.
remoteA process or transaction that is conducted through connected devices over a network,
rather than in person.
replay attack
An attack in which the attacker is able to replay previously captured messages (between
a legitimate claimant and a verifier) to masquerade as that claimant to the verifier orvice versa.
76

NIST SP 800-63-4 2pd
August 2024

2622
2623
2624

2625
2626

2627
2628
2629

2630
2631
2632
2633
2634
2635
2636

2637
2638
2639
2640
2641
2642

2643
2644
2645
2646
2647

2648
2649
2650

2651
2652

2653
2654

Digital Identity Guidelines

replay resistance
The property of an authentication process to resist replay attacks, typically by the use of
an authenticator output that is valid only for a specific authentication.
resolution
See identity resolution.
restricted
An authenticator type, class, or instantiation that has additional risk of false acceptanceassociated with its use and is therefore subject to additional requirements.
risk assessment
The process of identifying, estimating, and prioritizing risks to organizational operations(i.e., mission, functions, image, or reputation), organizational assets, individuals, andother organizations that result from the operation of a system. A risk assessment ispart of risk management, incorporates threat and vulnerability analyses, and considers
mitigations provided by security controls that are planned or in-place. It is synonymouswith “risk analysis.”risk management
The program and supporting processes that manage information security risk
to organizational operations (including mission, functions, image, reputation),organizational assets, individuals, and other organizations and includes (i) establishing
the context for risk-related activities, (ii) assessing risk, (iii) responding to risk once
determined, and (iv) monitoring risk over time.
RP subscriber accountAn account established and managed by the RP in a federated system based on the RP’sview of the subscriber account from the IdP. An RP subscriber account is associatedwith one or more federated identifiers and allows the subscriber to access the accountthrough a federation transaction with the IdP.
salt
A non-secret value used in a cryptographic process, usually to ensure that the results ofcomputations for one instance cannot be reused by an attacker.
Secure Sockets Layer (SSL)
See Transport Layer Security (TLS).
security domain
A set of systems under a common administrative and access control.

77

NIST SP 800-63-4 2pd
August 2024

2655
2656
2657
2658

2659
2660
2661
2662
2663
2664

2665
2666
2667
2668
2669
2670

2671
2672

2673
2674
2675
2676

2677
2678
2679
2680

2681
2682
2683
2684

2685
2686
2687
2688

Digital Identity Guidelines

Senior Agency Official for Privacy (SAOP)
Person responsible for ensuring that an agency complies with privacy requirements
and manages privacy risks. The SAOP is also responsible for ensuring that the agency
considers the privacy impacts of all agency actions and policies that involve PII.
sessionA persistent interaction between a subscriber and an endpoint, either an RP or a CSP. A
session begins with an authentication event and ends with a session termination event.
A session is bound by the use of a session secret that the subscriber’s software (e.g., abrowser, application, or OS) can present to the RP to prove association of the session
with the authentication event.
session hijack attack
An attack in which the attacker is able to insert themselves between a claimant anda verifier subsequent to a successful authentication exchange between the latter twoparties. The attacker is able to pose as a subscriber to the verifier or vice versa to control
session data exchange. Sessions between the claimant and the RP can be similarlycompromised.
shared secretA secret used in authentication that is known to the subscriber and the verifier.
side-channel attack
An attack enabled by the leakage of information from a physical cryptosystem.
Characteristics that could be exploited in a side-channel attack include timing, power
consumption, and electromagnetic and acoustic emissions.
single-factor
A characteristic of an authentication system or an authenticator that requires only one
authentication factor (i.e., something you know, something you have, or something youare) for successful authentication.
single sign-on (SSO)
An authentication process by which one account and its authenticators are used toaccess multiple applications in a seamless manner, generally implemented with afederation protocol.
social engineering
The act of deceiving an individual into revealing sensitive information, obtaining
unauthorized access, or committing fraud by associating with the individual to gain
confidence and trust.

78

NIST SP 800-63-4 2pd
August 2024

2689
2690
2691

2692
2693

2694
2695
2696

2697
2698
2699

2700
2701
2702
2703

2704
2705
2706
2707

2708
2709
2710
2711

2712
2713
2714

2715
2716
2717
2718

2719
2720
2721

Digital Identity Guidelines

subject
A person, organization, device, hardware, network, software, or service. In theseguidelines, a subject is a natural person.
subscriber
An individual enrolled in the CSP identity service.
subscriber accountAn account established by the CSP containing information and authenticators registeredfor each subscriber enrolled in the CSP identity service.
supplemental controls
Controls that may be added, in addition to those specified in the organization’s tailoredassurance level, in order to address specific threats or attacks.
symmetric key
A cryptographic key used to perform both the cryptographic operation and its inverse.
(e.g., to encrypt and decrypt or create a message authentication code and to verify thecode).
sync fabric
Any on-premises, cloud-based, or hybrid service used to store, transmit, or manage
authentication keys generated by syncable authenticators that are not local to the user’s
device.
syncable authenticators
Software or hardware cryptographic authenticators that allow authentication keys to becloned and exported to other storage to sync those keys to other authenticators (i.e.,
devices).
synthetic identity fraud
The use of a combination of personally identifiable information (PII) to fabricate a personor entity in order to commit a dishonest act for personal or financial gain.
system of record (SOR)
An SOR is a collection of records that contain information about individuals and areunder the control of an agency. The records can be retrieved by the individual’s nameor by an identifying number, symbol, or other identifier.
System of Record Notice (SORN)
A notice that federal agencies publish in the Federal Register to describe their systems ofrecords.
79

NIST SP 800-63-4 2pd
August 2024

2722
2723
2724
2725
2726
2727
2728
2729

2730
2731

2732
2733

2734
2735
2736
2737
2738
2739

2740
2741
2742
2743

2744
2745
2746
2747
2748

2749
2750
2751
2752

2753
2754
2755
2756

Digital Identity Guidelines

tailoring
The process by which xALs and specified controls are modified by: considerations forthe impacts on privacy, usability, and equity on the user population, identifying anddesignating common controls, applying scoping considerations on the applicability andimplementation of specified controls, selecting any compensating controls, assigning
specific values to organization-defined security control parameters, supplementing xAL
controls with additional controls or control enhancements, and providing additional
specification information for control implementation.
token
See authenticator.
transaction
See digital transaction
Transport Layer Security (TLS)
An authentication and security protocol widely implemented in browsers and web
servers. TLS is defined by [RFC5246]. TLS is similar to the older SSL protocol, and TLS
1.0 is effectively SSL version 3.1. SP 800-52, Guidelines for the Selection and Use of
Transport Layer Security (TLS) Implementations [SP800-52], specifies how TLS is to be
used in government applications.
trust agreement
A set of conditions under which a CSP, IdP, and RP are allowed to participate in afederation transaction for the purposes of establishing an authentication session
between the subscriber and the RP.
trust anchor
A public or symmetric key that is trusted because it is built directly into hardware
or software or securely provisioned via out-of-band means rather than because it isvouched for by another trusted entity (e.g., in a public key certificate). A trust anchor
may have name or policy constraints that limit its scope.
trusted referee
An agent of the CSP who is trained to make risk-based decisions regarding an applicant’s
identity proofing case when that applicant is unable to meet the expected requirementsof a defined IAL proofing process.
usability
The extent to which a product can be used by specified users to achieve specified
goals with effectiveness, efficiency, and satisfaction in a specified context of use.
[ISO/IEC9241-11]
80

NIST SP 800-63-4 2pd
August 2024

2757
2758
2759
2760
2761
2762

2763
2764
2765
2766

2767
2768
2769
2770
2771

2772
2773

2774
2775
2776
2777
2778

2779
2780
2781
2782

Digital Identity Guidelines

validation
The process or act of checking and confirming that the evidence and attributes
supplied by an applicant are authentic, accurate and associated with a real-life identity.
Specifically, evidence validation is the process or act of checking that the presented
evidence is authentic, current, and issued from an acceptable source. See also attributevalidation.
verification
The process or act of confirming that the applicant undergoing identity proofing holds
the claimed real-life identity represented by the validated identity attributes andassociated evidence. Synonymous with “identity verification.”verifier
An entity that verifies the claimant’s identity by verifying the claimant’s possession andcontrol of one or more authenticators using an authentication protocol. To do this, theverifier needs to confirm the binding of the authenticators with the subscriber accountand check that the subscriber account is active.
verifier impersonation
See phishing.
zeroize
Overwrite a memory location with data that consists entirely of bits with the value zeroso that the data is destroyed and unrecoverable. This is often contrasted with deletion
methods that merely destroy references to data within a file system rather than the data
itself.
zero-knowledge password protocol
A password-based authentication protocol that allows a claimant to authenticate to averifier without revealing the password to the verifier. Examples of such protocols are
EKE, SPEKE and SRP.

81

NIST SP 800-63-4 2pd
August 2024

2783

2784
2785
2786
2787
2788
2789

2790
2791
2792
2793
2794
2795
2796

Digital Identity Guidelines

Appendix C. Change Log
C.1. SP 800-63-1
NIST SP 800-63-1 updated NIST SP 800-63 to reflect current authenticator (then referred
to as “token”) technologies and restructured it to provide a better understanding of
the digital identity architectural model used here. Additional (minimum) technicalrequirements were specified for the CSP, protocols used to transport authentication
information, and assertions if implemented within the digital identity model.
C.2. SP 800-63-2
NIST SP 800-63-2 was a limited update of SP 800-63-1 and substantive changes weremade only in Sec. 5, Registration and Issuance Processes. The substantive changes in
the revised draft were intended to facilitate the use of professional credentials in theidentity proofing process, and to reduce the need to send postal mail to an address ofrecord to issue credentials for level 3 remote registration. Other changes to Sec. 5 wereminor explanations and clarifications.

2806

C.3. SP 800-63-3
NIST SP 800-63-3 is a substantial update and restructuring of SP 800-63-2. SP 800-633 introduces individual components of digital authentication assurance — AAL, IAL,
and FAL — to support the growing need for independent treatment of authentication
strength and confidence in an individual’s claimed identity (e.g., in strong pseudonymous
authentication). A risk assessment methodology and its application to IAL, AAL, and FAL
has been included in this guideline. It also moves the whole of digital identity guidancecovered under SP 800-63 from a single document describing authentication to a suite offour documents (to separately address the individual components mentioned above) of
which SP 800-63-3 is the top-level document.

2807

Other areas updated in 800-63-3 include:

2797
2798
2799
2800
2801
2802
2803
2804
2805

2808
2809
2810

2811
2812

• Renamed to Digital Identity Guidelines to properly represent the scope includes
identity proofing and federation, and to support expanding the scope to include
device identity, or machine-to-machine authentication in future revisions.
• Changed terminology, including the use of authenticator in place of token to avoid
conflicting use of the word token in assertion technologies.

2814• Updated authentication and assertion requirements to reflect advances in bothsecurity technology and threats.

2815• Added requirements on the storage of long-term secrets by verifiers.

2816• Restructured identity proofing model.

2817• Updated requirements regarding remote identity proofing.

2813

82

NIST SP 800-63-4 2pd
August 2024

2818

2819
2820

Digital Identity Guidelines• Clarified the use of independent channels and devices as “something you have”.
• Removed pre-registered knowledge tokens (authenticators), with the recognition
that they are special cases of (often very weak) passwords.

2822• Added requirements regarding account recovery in the event of loss or theft of anauthenticator.

2823• Removed email as a valid channel for out-of-band authenticators.

2824• Expanded discussion of reauthentication and session management.

2821

2825
2826

2827
2828
2829

2830
2831

2832
2833
2834

2835
2836

2837
2838
2839
2840

2841
2842

2843
2844

• Expanded discussion of identity federation; restructuring of assertions in thecontext of federation.
C.4. SP 800-63-4
NIST SP 800-63-4 has substantial updates and re-organization from SP 800-63-3. Updates
to 800-63-4 include:• Expanded security and privacy considerations and added equity and usability
considerations.
• Updated digital identity models and added a user-controlled wallet federation
model that addresses the increased attention and adoption of digital wallets andattribute bundles.
• Expanded digital identity risk management process to include definition of theprotected online services, user groups, and impacted entities.
• A more descriptive introduction to establish the context of the DIRM process, thetwo dimensions of risk it addresses, and the intended outcomes. This contextsetting step includes defining and understanding the online service that theorganization is offering and intending to protect with identity systems.
• Expanded digital identity risk management process to include definition of theprotected online services, user groups, and impacted entities.
• Updated digital identity risk management process for additional assessments for
tailoring initial baseline control selections.

2846• Added performance metrics for the continuous evaluation of digital identity
systems.

2847• Added a new subsection on redress processes and requirements.

2845

2848
2849

• Added a new Artificial Intelligence subsection to address the use of Artificial
Intelligence in digital identity services.

83