Withdrawn Draft
Warning Notice
The attached draft document has been withdrawn and is provided solely for historical purposes.
It has been followed by the document identified below.
Withdrawal Date August 21, 2024
Original Release Date December 16, 2022

The attached draft document is followed by:
Status Second Public Draft (2pd)
Series/Number NIST SP 800-63B-4 2pd
Title Digital Identity Guidelines: Authentication and Authenticator
Management
Publication Date August 2024
DOI https://doi.org/10.6028/NIST.SP.800-63B-4.2pd
CSRC URL https://csrc.nist.gov/pubs/sp/800/63/b/4/2pd
Additional Information https://www.nist.gov/identity-access-management/nist-specialpublication-800-63-digital-identity-guidelines

1

2

3

4

5

6
7
8
9
10
11

12
13

14

NIST Special Publication
NIST SP 800-63B-4 ipd

Digital Identity Guidelines
Authentication and Lifecycle Management

Initial Public Draft

David Temoshok
James L. Fenton
Yee-Yin Choong
Naomi Lefkovitz
Andrew Regenscheid
Justin P. Richer

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

15

16

17

18

19

20
21
22
23

24
25
26

27
28
29

30
31

32
33

34
35

36

NIST Special Publication
NIST SP 800-63B-4 ipd

Digital Identity Guidelines
Authentication and Lifecycle Management
Initial Public Draft
David Temoshok
Naomi Lefkovitz
Applied Cybersecurity Division
Information Technology Laboratory
Yee-Yin Choong
Information Access Division
Information Technology Laboratory
Andrew Regenscheid
Computer Security Division
Information Technology Laboratory
James L. Fenton
Altmode Networks
Justin P. Richer
Bespoke Engineering
This publication is available free of charge from:https://doi.org/10.6028/NIST.SP.800-63b-4.ipd
December 2022

37
38
39

40
41

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

42
43
44
45
46

47
48
49
50
51
52
53

Certain commercial entities, equipment, or materials may be identified in this document
in order to describe an experimental procedure or concept adequately. Such identification
is not intended to imply recommendation or endorsement by the National Institute ofStandards 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.

56

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.

57

Authority

54
55

58
59
60
61
62
63
64
65

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 withthe requirements of the Office of Management and Budget (OMB) Circular A-130.

72

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 understatutory 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 otherfederal official. This publication may be used by nongovernmental organizations on a
voluntary basis and is not subject to copyright in the United States. Attribution would,
however, be appreciated by NIST.

73

NIST Technical Series Policies

66
67
68
69
70
71

74
75

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

76

Publication History

78

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

79

How to Cite this NIST Technical Series Publication

77

83

Temoshok D, Fenton JL, Choong YY, Lefkovitz N, Regenscheid A, Richer JP (2022)
Digital Identity Guidelines: Authentication and Lifecycle Management. (National
Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication(SP) NIST SP 800-63B-4 ipd. https://doi.org/10.6028/NIST.SP.800-63b-4.ipd84

Author ORCID iDs

80
81
82

90

David Temoshok: 0000-0001-6195-0331
James L. Fenton: 0000-0002-2344-4291
Yee-Yin Choong: 0000-0002-3889-6047
Naomi Lefkovitz: 0000-0003-3777-3106
Andrew Regenscheid: 0000-0002-3930-527X
Justin P. Richer: 0000-0003-2130-5180

91

Public Comment Period

92

December 16, 2022 - March 24 April 14, 2023

93

Submit Comments

94

mailto:dig-comments@nist.gov

85
86
87
88
89

95
96

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

NIST SP 800-63B-4 ipd
December 2022

97

Digital Identity Guidelines
Authentication and Lifecycle Management

Reports on Computer Systems Technology

108

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, andphysical 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.

109

Abstract

98
99
100
101
102
103
104
105
106
107

118

These guidelines provide technical requirements for federal agencies implementing
digital identity services and are not intended to constrain the development or use ofstandards outside of this purpose. These guidelines focus on the authentication ofsubjects interacting with government information systems over networks, establishingthat a given claimant is a subscriber who has been previously authenticated. The
result of the authentication process may be used locally by the system performing
the authentication or may be asserted elsewhere in a federated identity system. This
document defines technical requirements for each of the three authenticator assurance
levels. This publication will supersede NIST Special Publication (SP) 800-63B.

119

Keywords

110
111
112
113
114
115
116
117

122

authentication; authentication assurance; credential service provider; digitalauthentication; digital credentials; electronic authentication; electronic credentials;
passwords.

123

Note to Reviewers

120
121

124
125

126
127
128
129
130

The rapid proliferation of online services over the past few years has heightened the needfor reliable, equitable, secure, and privacy-protective digital identity solutions.
Revision 4 of NIST Special Publication 800-63 Digital Identity Guidelines intends to
respond to the changing digital landscape that has emerged since the last major revisionof 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, and federation,iNIST SP 800-63B-4 ipd
December 2022

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
165

Digital Identity Guidelines
Authentication and Lifecycle Management

including requirements for security and privacy as well as considerations for fostering
equity and the usability of digital identity solutions and technology.
Taking into account feedback provided in response to our June 2020 Pre-Draft Callfor Comments, as well as research conducted into real-world implementations of theguidelines, market innovation, and the current threat environment, this draft seeks to:
1. Advance Equity: This draft seeks to expand upon the risk management content
of previous revisions and specifically mandates that agencies account for impacts
to individuals and communities in addition to impacts to the organization. It also
elevates risks to mission delivery – including challenges to providing services toall people who are eligible for and entitled to them – within the risk management
process and when implementing digital identity systems. Additionally, the guidance
now mandates continuous evaluation of potential impacts across demographics,
provides biometric performance requirements, and additional parameters for the
responsible use of biometric-based technologies, such as those that utilize facerecognition.
2. Emphasize Optionality and Choice for Consumers: In the interest of promoting
and investigating additional scalable, equitable, and convenient identify verification
options, including those that do and do not leverage face recognition technologies,
this draft expands the list of acceptable identity proofing alternatives to provide
new mechanisms to securely deliver services to individuals with differing means,motivations, and backgrounds. The revision also emphasizes the need for digital
identity services to support multiple authenticator options to address diverse
consumer needs and secure account recovery.
3. Deter Fraud and Advanced Threats: This draft enhances fraud prevention
measures from the third revision by updating risk and threat models to accountfor new attacks, providing new options for phishing resistant authentication, andintroducing requirements to prevent automated attacks against enrollment processes.
It also opens the door to new technology such as mobile driver’s licenses andverifiable credentials.
4. Address Implementation Lessons Learned: This draft addresses areas where
implementation experience has indicated that additional clarity or detail was
required to effectively operationalize the guidelines. This includes re-working
the federation assurance levels, providing greater detail on trusted referees,clarifying guidelines on identity attribute validation sources, and improving addressconfirmation requirements.

167

NIST is specifically interested in comments on and recommendations for the following
topics:

168

Authentication and Lifecycle Management

166

ii

NIST SP 800-63B-4 ipd
December 2022

169
170
171
172

173
174

175
176
177

178
179

180

181

Digital Identity Guidelines
Authentication and Lifecycle Management• Are emerging authentication models and techniques – such as FIDO passkey,
verifiable credentials, and mobile driver’s licenses – sufficiently addressed andaccommodated, as appropriate, by the guidelines? What are the potential associatedsecurity, privacy, and usability benefits and risks?
• Are the controls for phishing resistance as defined in the guidelines for AAL2 andAAL3 authentication clear and sufficient?
• How are session management thresholds and reauthentication requirements
implemented by agencies and organizations? Should NIST provide thresholds orleave session lengths to agencies based on applications, users, and mission needs?
• What impacts would the proposed biometric performance requirements for thisvolume have on real-world implementations of biometric technologies?
General• Is there an element of this guidance that you think is missing or could be expanded?

183• Is any language in the guidance confusing or hard to understand? Should we add
definitions or additional context to any language?

184• Does the guidance sufficiently address privacy?

185• Does the guidance sufficiently address equity?

182

186
187
188
189

190
191
192

193
194

195
196
197
198
199
200

– What equity assessment methods, impact evaluation models, or metrics
could we reference to better support organizations in preventing or detecting
disparate impacts that could arise as a result of identity verification
technologies or processes?
• What specific implementation guidance, reference architectures, metrics, or othersupporting resources may enable more rapid adoption and implementation of thisand future iterations of the Digital Identity Guidelines?
• What applied research and measurement efforts would provide the greatest impact
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 of the NIST SP 800-63-4 suite. NIST requests that all comments be submitted
by 11:59pm Eastern Time on March 24, 2023. Please submit your comments to digcomments@nist.gov. NIST will review all comments and make them available at the
NIST Identity and Access Management website. Commenters are encouraged to use thecomment template provided on the NIST Computer Security Resource Center website.

iii

NIST SP 800-63B-4 ipd
December 2022

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

Digital Identity Guidelines
Authentication and Lifecycle Management

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 in thisInformation 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.

227

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

228

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

226

iv

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

229

Table of Contents

230

1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

231

2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3232

3. Deﬁnitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . .

5233

4. Authentication Assurance Levels . . . . . . . . . . . . . . . . . . . . . . . .

6

234

4.1. Authentication Assurance Level 1 . . . . . . . . . . . . . . . . . . . . . .

6

235

4.1.1. Permitted Authenticator Types . . . . . . . . . . . . . . . . . . . .

6

236

4.1.2. Authenticator and Veriﬁer Requirements . . . . . . . . . . . . . .

7

237

4.1.3. Reauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

238

4.1.4. Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

239

4.1.5. Records Retention Policy . . . . . . . . . . . . . . . . . . . . . . .

7

2404.2. Authentication Assurance Level 2 . . . . . . . . . . . . . . . . . . . . . .

8

241

4.2.1. Permitted Authenticator Types . . . . . . . . . . . . . . . . . . . .

8

242

4.2.2. Authenticator and Veriﬁer Requirements . . . . . . . . . . . . . .

9243

4.2.3. Reauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . .

9244

4.2.4. Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . .

9245

4.2.5. Records Retention Policy . . . . . . . . . . . . . . . . . . . . . . . 10

246

4.3. Authentication Assurance Level 3 . . . . . . . . . . . . . . . . . . . . . . 10

247

4.3.1. Permitted Authenticator Types . . . . . . . . . . . . . . . . . . . . 10

248

4.3.2. Authenticator and Veriﬁer Requirements . . . . . . . . . . . . . . 10

249

4.3.3. Reauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

250

4.3.4. Security Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 11251

4.3.5. Records Retention Policy . . . . . . . . . . . . . . . . . . . . . . . 11

252

4.4. Privacy Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12253

4.5. Summary of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 12254

5. Authenticator and Veriﬁer Requirements . . . . . . . . . . . . . . . . . . . 14

255

5.1. Requirements by Authenticator Type . . . . . . . . . . . . . . . . . . . . . 14

256

5.1.1. Memorized Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . 14

257

5.1.2. Look-Up Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

258

5.1.3. Out-of-Band Devices . . . . . . . . . . . . . . . . . . . . . . . . . 18v

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management259

5.1.4. Single-Factor OTP Device . . . . . . . . . . . . . . . . . . . . . . 23

260

5.1.5. Multi-Factor OTP Devices . . . . . . . . . . . . . . . . . . . . . . 25

261

5.1.6. Single-Factor Cryptographic Software . . . . . . . . . . . . . . . . 27

262

5.1.7. Single-Factor Cryptographic Devices . . . . . . . . . . . . . . . . . 27263

5.1.8. Multi-Factor Cryptographic Software . . . . . . . . . . . . . . . . 29

264

5.1.9. Multi-Factor Cryptographic Devices . . . . . . . . . . . . . . . . . 30

265

5.2. General Authenticator Requirements . . . . . . . . . . . . . . . . . . . . . 31

266

5.2.1. Physical Authenticators . . . . . . . . . . . . . . . . . . . . . . . . 31

267

5.2.2. Rate Limiting (Throttling) . . . . . . . . . . . . . . . . . . . . . . 31

268

5.2.3. Use of Biometrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

269

5.2.4. Attestation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

270

5.2.5. Phishing (Veriﬁer Impersonation) Resistance . . . . . . . . . . . . 34

271

5.2.6. Veriﬁer-CSP Communications . . . . . . . . . . . . . . . . . . . . 36

272

5.2.7. Veriﬁer Compromise Resistance . . . . . . . . . . . . . . . . . . . 36

273

5.2.8. Replay Resistance . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

274

5.2.9. Authentication Intent . . . . . . . . . . . . . . . . . . . . . . . . . 37

275

5.2.10. Restricted Authenticators . . . . . . . . . . . . . . . . . . . . . . . 37

276

5.2.11. Activation Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . 38

277

5.2.12. Connected Authenticators . . . . . . . . . . . . . . . . . . . . . . 39

278

6. Authenticator Lifecycle Management . . . . . . . . . . . . . . . . . . . . . 41

279

6.1. Authenticator Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

280

6.1.1. Binding at Enrollment . . . . . . . . . . . . . . . . . . . . . . . . 42281

6.1.2. Post-Enrollment Binding . . . . . . . . . . . . . . . . . . . . . . . 43282

6.1.3. Binding to a Subscriber-provided Authenticator . . . . . . . . . . . 46

283

6.1.4. Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46284

6.2. Loss, Theft, Damage, and Unauthorized Duplication . . . . . . . . . . . . 46

285

6.3. Expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

286

6.4. Invalidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

287

7. Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

288

7.1. Session Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
vi

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management289

7.1.1. Browser Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

290

7.1.2. Access Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

291

7.1.3. Device Identiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . 50

292

7.2. Reauthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

293

7.2.1. Reauthentication from a Federation or Assertion . . . . . . . . . . 51

294

8. Threats and Security Considerations . . . . . . . . . . . . . . . . . . . . . 52

295

8.1. Authenticator Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

296

8.2. Threat Mitigation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . 55

297

8.3. Authenticator Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

298

8.4. Session Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

299

9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

300

9.1. Privacy Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

301

9.2. Privacy Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

302

9.3. Use Limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

303

9.4. Agency-Speciﬁc Privacy Compliance . . . . . . . . . . . . . . . . . . . . . 60

304

10.Usability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

305

10.1. Usability Considerations Common to Authenticators . . . . . . . . . . . . 62306

10.2. Usability Considerations by Authenticator Type . . . . . . . . . . . . . . . 64

307

10.2.1. Memorized Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . 64

308

10.2.2. Look-Up Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

309

10.2.3. Out-of-Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

310

10.2.4. Single-Factor OTP Device . . . . . . . . . . . . . . . . . . . . . . 66

311

10.2.5. Multi-Factor OTP Device . . . . . . . . . . . . . . . . . . . . . . 67

312

10.2.6. Single-Factor Cryptographic Software . . . . . . . . . . . . . . . . 68

313

10.2.7. Single-Factor Cryptographic Device . . . . . . . . . . . . . . . . . 68

314

10.2.8. Multi-Factor Cryptographic Software . . . . . . . . . . . . . . . . 68315

10.2.9. Multi-Factor Cryptographic Device . . . . . . . . . . . . . . . . . . 69

316

10.3. Summary of Usability Considerations . . . . . . . . . . . . . . . . . . . . . 69

317

10.4. Biometrics Usability Considerations . . . . . . . . . . . . . . . . . . . . . 72

318

11.Equity Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
vii

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management319

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

320

General References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

321

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

322

NIST Special Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

323

Federal Information Processing Standards . . . . . . . . . . . . . . . . . . . . . 79

324

Appendix A. Strength of Memorized Secrets . . . . . . . . . . . . . . . . . . 80

325

A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

326

A.2. Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

327

A.3. Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

328

A.4. Central vs. Local Veriﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . 82

329

A.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

330

Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

331

List of Tables

335

1.
2.
3.
4.

336

List of Figures

332
333
334

337
338
339

1.
2.
3.

AAL Summary of Requirements . . . . . . . . . . . . . . . . . . . . . . .
AAL Reauthentication Requirements . . . . . . . . . . . . . . . . . . . . .
Authenticator Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mitigating Authenticator Threats . . . . . . . . . . . . . . . . . . . . . .

13
50
52
55

Transfer of Secret to Primary Device . . . . . . . . . . . . . . . . . . . . . 19
Transfer of Secret to Out-of-band Device . . . . . . . . . . . . . . . . . . 20
Usability Considerations Summary by Authenticator Type . . . . . . . . . 71

viii

NIST SP 800-63B-4 ipd
December 2022

340

341
342
343
344
345
346
347

Digital Identity Guidelines
Authentication and Lifecycle Management

Acknowledgments
The authors would like to thank their fellow collaborators on the current revision ofthis special publication, Christine Abruzzi, Ryan Galluzzo, Sarbari Gupta, Connie
LaSalle, and Diana Proud-Madruga, as well as Kerrianne Buchanan and Greg Fiumara
for their contributions and review. The authors would like to also acknowledge the past
contributions of Donna F. Dodson, W. Timothy Polk, Emad A. Nabbus, Paul A. Grassi,
Elaine M. Newton, Ray Perlner, William E. Burr, Kristen K. Greene, Mary F. Theofanos,
Kaitlin Boeckl, Kat Megas, Ellen Nadeau, Ben Piccarreta, and Danna Gabel O’Rourke.

1

NIST SP 800-63B-4 ipd
December 2022

348

1.

349

This section is informative.

350
351
352

353
354

Digital Identity Guidelines
Authentication and Lifecycle Management

PurposeThis publication and its companion volumes, [SP800-63], [SP800-63A], and[SP800-63C], provide technical guidelines to organizations for the implementation ofdigital identity services.
This document, SP 800-63B, provides requirements to credential service providers (CSPs)
for remote user authentication at each of three authentication assurance levels (AALs).

2

NIST SP 800-63B-4 ipd
December 2022

355

2.

356

This section is informative.

357
358
359
360
361
362

363
364
365
366
367
368
369

370
371
372
373

374
375
376
377
378

379
380
381
382
383
384
385

386
387
388
389
390

391
392

Digital Identity Guidelines
Authentication and Lifecycle Management

Introduction

Digital authentication is the process of determining the validity of one or moreauthenticators used to claim a digital identity. Authentication establishes that a subject
attempting to access a digital service is in control of the technologies used to authenticate.
For services in which return visits are applicable, successfully authenticating provides
reasonable risk-based assurances that the subject accessing the service today is the sameas the one who accessed the service previously.
The ongoing authentication of subscribers is central to the process of associating a
subscriber with their online activity (i.e., with their subscriber account). Subscriber
authentication is performed by verifying that the claimant controls one or moreauthenticators (called tokens in some earlier versions of SP 800-63) associated witha given subscriber account. A successful authentication results in the assertion of apseudonymous or non-pseudonymous identifier and optionally other identity information
to the relying party (RP).
This document provides recommendations on types of authentication processes, including
choices of authenticators, that may be used at various authentication assurance levels(AALs). It also provides recommendations on the lifecycle of authenticators, including
revocation in the event of loss or theft.
This technical guideline applies to digital authentication of subjects to systems over a
network. It does not address the authentication of a person for physical access (e.g., to abuilding), though some credentials used for digital access may also be used for physicalaccess authentication. This technical guideline also requires that federal systems andservice providers participating in authentication protocols be authenticated to subscribers.
The AAL characterizes the strength of an authentication transaction as an ordinal
category. Stronger authentication (a higher AAL) requires malicious actors to havebetter capabilities and to expend greater resources in order to successfully subvert
the authentication process. Authentication at higher AALs can effectively reduce therisk of attacks. A high-level summary of the technical requirements for each of the
AALs is provided below; see Sec. 4 and Sec. 5 of this document for specific normativerequirements.
Authentication Assurance Level 1: AAL1 provides some assurance that the claimant
controls an authenticator bound to the subscriber account. AAL1 requires either singlefactor or multi-factor authentication using a wide range of available authentication
technologies. Successful authentication requires that the claimant prove possession andcontrol of the authenticator through a secure authentication protocol.
Authentication Assurance Level 2: AAL2 provides high confidence that the claimant
controls one or more authenticators bound to the subscriber account. Proof of3

NIST SP 800-63B-4 ipd
December 2022

393
394
395

396
397
398
399
400
401
402
403

404
405

Digital Identity Guidelines
Authentication and Lifecycle Management

possession and control of two different authentication factors is required through secureauthentication protocols. Approved cryptographic techniques are required at AAL2 andabove.
Authentication Assurance Level 3: AAL3 provides very high confidence thatthe claimant controls one or more authenticators bound to the subscriber account.
Authentication at AAL3 is based on proof of possession of a key through a cryptographic
protocol. AAL3 authentication requires a hardware-based authenticator and aphishing-resistant authenticator (see Sec. 5.2.5); the same device may fulfill boththese requirements. In order to authenticate at AAL3, claimants are required to prove
possession and control of two distinct authentication factors through secure authentication
protocols. Approved cryptographic techniques are required.
The following list states which sections of the document are normative and which are
informative:406• 1 Purpose Informative407• 2 Introduction Informative408• 3 Definitions and Abbreviations Informative409• 4 Authentication Assurance Levels Normative410• 5 Authenticator and Verifier Requirements Normative411• 6 Authenticator Lifecycle Management Normative412• 7 Session Management Normative

413• 8 Threat and Security Considerations Informative414• 9 Privacy Considerations Informative415• 10 Usability Considerations Informative416• 11 Equity Considerations Informative417• References Informative

418• Appendix A Strength of Memorized Secrets Informative

419• Appendix B Change Log Informative

4

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

420

3.

Deﬁnitions and Abbreviations

421

See [SP800-63], Appendix A for a complete set of definitions and abbreviations.

5

NIST SP 800-63B-4 ipd
December 2022

422

4.

423

This section is normative.

424
425
426
427
428
429
430

Digital Identity Guidelines
Authentication and Lifecycle Management

Authentication Assurance Levels

To satisfy the requirements of a given AAL and be recognized as a subscriber, a claimant
SHALL be authenticated with a process whose strength is equal to or greater than therequirements at that level. The result of an authentication process is an identifier that
SHALL be used each time that subscriber authenticates to that RP. The identifier MAY
be pseudonymous. Subscriber identifiers SHOULD NOT be reused for a different subject
but SHOULD be reused when a previously enrolled subject is re-enrolled by the CSP.
Other attributes that identify the subscriber as a unique subject MAY also be provided.

432

Detailed normative requirements for authenticators and verifiers at each AAL areprovided in Sec. 5.

433

See [SP800-63] Sec. 5 for details on how to choose the most appropriate AAL.

434

[FIPS140] requirements are satisfied by FIPS 140-3 or newer revisions.

431

435
436
437
438
439
440

441
442
443
444
445
446

447
448
449

Personal information collected during and subsequent to identity proofing MAY be madeavailable to the subscriber by the digital identity service. The release or online availabilityof any PII or other personal information, whether self-asserted or validated, by federal
government agencies requires multi-factor authentication in accordance with [EO13681].
Therefore, federal government agencies SHALL select a minimum of AAL2 when PII orother personal information is made available online.
4.1. Authentication Assurance Level 1
AAL1 provides some assurance that the claimant controls an authenticator bound to thesubscriber account. AAL1 requires either single-factor or multi-factor authentication
using a wide range of available authentication technologies. Successful authentication
requires that the claimant prove possession and control of the authenticator through asecure authentication protocol.
4.1.1. Permitted Authenticator Types
AAL1 authentication SHALL occur by the use of any of the following authenticatortypes, which are defined in Sec. 5:

450• Memorized secret (Sec. 5.1.1)

451• Look-Up secret (Sec. 5.1.2)

452• Out-of-band device (Sec. 5.1.3)

453• Single-factor one-time password (OTP) device (Sec. 5.1.4)

454• Multi-factor OTP device (Sec. 5.1.5)455• Single-factor cryptographic software (Sec. 5.1.6)
6

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management456• Single-factor cryptographic device (Sec. 5.1.7)

457• Multi-factor cryptographic software (Sec. 5.1.8)

458• Multi-factor cryptographic device (Sec. 5.1.9)

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
486
487
488
489

4.1.2. Authenticator and Veriﬁer Requirements
Cryptographic authenticators used at AAL1 SHALL use approved cryptography.
Software-based authenticators that operate within the context of an operating system
MAY , where applicable, attempt to detect compromise (e.g., by malware) of the user
endpoint in which they are running and SHOULD NOT complete the operation when sucha compromise is detected.
Communication between the claimant and verifier SHALL be via an authenticatedprotected channel to provide confidentiality of the authenticator output and resistanceto adversary-in-the-middle (AitM) attacks.
Verifiers operated by or on behalf of federal government agencies at AAL1 SHALL bevalidated to meet the requirements of [FIPS140] Level 1.
4.1.3. Reauthentication
Periodic reauthentication of subscriber sessions SHALL be performed as described inSec. 7.2. At AAL1, reauthentication of the subscriber SHOULD be repeated at least onceper 30 days during an extended usage session, regardless of user activity. The session
SHOULD be terminated (i.e., logged out) when this time limit is reached.
4.1.4. Security Controls
The CSP SHALL employ appropriately tailored security controls from the baseline
security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or
industry standard that the organization has determined for the information systems,
applications, and online services that these guidelines are used to protect. The CSPSHALL ensure that the minimum assurance-related controls for the appropriate systems,
or equivalent, are satisfied.
4.1.5. Records Retention Policy
The CSP SHALL comply with its respective records retention policies in accordancewith applicable laws, regulations, and policies, including any National Archives andRecords Administration (NARA) records retention schedules that may apply. If the CSP
opts to retain records in the absence of any mandatory requirements, the CSP SHALL
conduct a risk management process, including assessments of privacy and security risks,
to determine how long records should be retained and SHALL inform the subscriber ofthat retention policy.

7

NIST SP 800-63B-4 ipd
December 2022

490
491
492
493
494

Digital Identity Guidelines
Authentication and Lifecycle Management

4.2. Authentication Assurance Level 2
AAL2 provides high confidence that the claimant controls authenticators bound to thesubscriber account. Proof of possession and control of two distinct authentication factors
is required through secure authentication protocols. Approved cryptographic techniques
are required at AAL2 and above.

500

4.2.1. Permitted Authenticator Types
At AAL2, authentication SHALL occur by the use of either a multi-factor authenticator
or a combination of two single-factor authenticators. A multi-factor authenticatorrequires two factors to execute a single authentication event, such as a cryptographicallysecure device with an integrated biometric sensor that is required to activate the device.
Authenticator requirements are specified in Sec. 5.

501

When a multi-factor authenticator is used, any of the following MAY be used:

495
496
497
498
499

502

• Multi-Factor Out-of-Band Authenticator (Sec. 5.1.3.4)

503• Multi-Factor OTP Device (Sec. 5.1.5)

504• Multi-Factor Cryptographic Software (Sec. 5.1.8)

505• Multi-Factor Cryptographic Device (Sec. 5.1.9)

506
507
508

When a combination of two single-factor authenticators is used, the combination SHALL
include a Memorized Secret authenticator (Sec. 5.1.1) and one physical authenticator (i.e.,“something you have”) from the following list:509• Look-Up Secret (Sec. 5.1.2)

510• Out-of-Band Device (Sec. 5.1.3)

511• Single-Factor OTP Device (Sec. 5.1.4)

512• Single-Factor Cryptographic Software (Sec. 5.1.6)

513• Single-Factor Cryptographic Device (Sec. 5.1.7)

514
515
516
517
518
519
520

Note: When biometric authentication meets the requirements in Sec. 5.2.3,
the device has to be authenticated in addition to the biometric match. A
biometric characteristic is recognized as a factor, but not recognized as anauthenticator by itself. Therefore, when conducting authentication with abiometric characteristic, it is unnecessary to use two authenticators because
the associated device serves as “something you have,” while the biometricmatch serves as “something you are.”

8

NIST SP 800-63B-4 ipd
December 2022

521
522
523
524
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

Digital Identity Guidelines
Authentication and Lifecycle Management

4.2.2. Authenticator and Veriﬁer Requirements
Cryptographic authenticators used at AAL2 SHALL use approved cryptography.
Authenticators procured by federal government agencies SHALL be validated to meetthe requirements of [FIPS140] Level 1. Software-based authenticators that operate within
the context of an operating system MAY , where applicable, attempt to detect compromise(e.g., by malware) of the platform in which they are running. They SHOULD NOT
complete the operation when such a compromise is detected. At least one authenticatorused at AAL2 SHALL be replay resistant as described in Sec. 5.2.8. Authentication at
AAL2 SHOULD demonstrate authentication intent from at least one authenticator as
discussed in Sec. 5.2.9.
Communication between the claimant and verifier SHALL be via an authenticatedprotected channel to provide confidentiality of the authenticator output and resistanceto AitM attacks.
Verifiers operated by or on behalf of federal government agencies at AAL2 SHALL bevalidated to meet the requirements of [FIPS140] Level 1.
When a biometric factor is used in authentication at AAL2, the performance requirements
stated in Sec. 5.2.3 SHALL be met, and the verifier SHOULD make a determination thatthe biometric sensor and subsequent processing meet these requirements.
OMB Memorandum [M-22-09] requires federal government agencies to offer at least
one phishing-resistant authenticator option to public users at AAL2. While phishingresistance as described in Sec. 5.2.5 is not generally required for authentication at AAL2,
verifiers SHOULD encourage the use of phishing-resistant authenticators at AAL2
whenever practical since phishing is a significant threat vector.
4.2.3. Reauthentication
Periodic reauthentication of subscriber sessions SHALL be performed as described inSec. 7.2. At AAL2, authentication of the subscriber SHALL be repeated at least once per
12 hours during an extended usage session, regardless of user activity. Reauthentication of
the subscriber SHALL be repeated following any period of inactivity lasting 30 minutes
or longer. The session SHALL be terminated (i.e., logged out) when either of these time
limits is reached.
Reauthentication of a session that has not yet reached its time limit MAY require onlya memorized secret or a biometric in conjunction with the still-valid session secret. The
verifier MAY prompt the user to cause activity just before the inactivity timeout.
4.2.4. Security Controls
The CSP SHALL employ appropriately tailored security controls from the baseline
security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or
industry standard that the organization has determined for the information systems,
9

NIST SP 800-63B-4 ipd
December 2022

558
559
560

561
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

Digital Identity Guidelines
Authentication and Lifecycle Management

applications, and online services that these guidelines are used to protect. The CSPSHALL ensure that the minimum assurance-related controls for the appropriate systems,
or equivalent, are satisfied.
4.2.5. Records Retention Policy
The CSP SHALL comply with its respective records retention policies in accordancewith applicable laws, regulations, and policies, including any NARA records retention
schedules that may apply. If the CSP opts to retain records in the absence of any
mandatory requirements, the CSP SHALL conduct a risk management process, including
assessments of privacy and security risks to determine how long records should be
retained and SHALL inform the subscriber of that retention policy.
4.3. Authentication Assurance Level 3
AAL3 provides very high confidence that the claimant controls authenticators boundto the subscriber account. Authentication at AAL3 is based on proof of possession ofa key through a cryptographic protocol. AAL3 authentication SHALL use a hardwarebased authenticator and an authenticator that provides phishing resistance — the samedevice MAY fulfill both these requirements. In order to authenticate at AAL3, claimants
SHALL prove possession and control of two distinct authentication factors throughsecure authentication protocols. Approved cryptographic techniques are required.
4.3.1. Permitted Authenticator Types
AAL3 authentication SHALL occur by the use of one of a combination of authenticators
satisfying the requirements in Sec. 4.3. Possible combinations are:• Multi-Factor Cryptographic Device (Sec. 5.1.9)• Single-Factor Cryptographic Device (Sec. 5.1.7) used in conjunction with aMemorized Secret (Sec. 5.1.1)• Multi-Factor OTP device (software or hardware) (Sec. 5.1.5) used in conjunction
with a Single-Factor Cryptographic Device (Sec. 5.1.7)• Multi-Factor OTP device (hardware only) (Sec. 5.1.5) used in conjunction with aSingle-Factor Cryptographic Software (Sec. 5.1.6)• Single-Factor OTP device (hardware only) (Sec. 5.1.4) used in conjunction with a
Multi-Factor Cryptographic Software Authenticator (Sec. 5.1.8)
4.3.2. Authenticator and Veriﬁer Requirements
Communication between the claimant and verifier SHALL be via an authenticatedprotected channel to provide confidentiality of the authenticator output and resistanceto AitM attacks. At least one cryptographic authenticator used at AAL3 SHALL
be phishing resistant as described in Sec. 5.2.5 and SHALL be replay resistant as
10

NIST SP 800-63B-4 ipd
December 2022

593
594
595

Digital Identity Guidelines
Authentication and Lifecycle Management

described in Sec. 5.2.8. All authentication and reauthentication processes at AAL3
SHALL demonstrate authentication intent from at least one authenticator as describedin Sec. 5.2.9.

599

Multi-factor authenticators used at AAL3 SHALL be hardware cryptographic modules
validated at [FIPS140] Level 2 or higher overall with at least [FIPS140] Level 3 physicalsecurity. Single-factor cryptographic devices used at AAL3 SHALL be validated at[FIPS140] Level 1 or higher overall with at least [FIPS140] Level 3 physical security.

600

Verifiers at AAL3 SHALL be validated at [FIPS140] Level 1 or higher.

596
597
598

601
602

603
604

605
606
607

608
609
610
611
612
613
614
615
616

617
618
619
620
621
622
623

624
625
626
627

Verifiers at AAL3 SHALL be verifier compromise resistant as described in Sec. 5.2.7
with respect to at least one authentication factor.
Hardware-based authenticators and verifiers at AAL3 SHOULD resist relevant sidechannel (e.g., timing and power-consumption analysis) attacks.
When a biometric factor is used in authentication at AAL3, the verifier SHALL make adetermination that the biometric sensor and subsequent processing meet the performancerequirements stated in Sec. 5.2.3.
4.3.3. Reauthentication
Periodic reauthentication of subscriber sessions SHALL be performed as described inSec. 7.2. At AAL3, authentication of the subscriber SHALL be repeated at least once
per 12 hours during an extended usage session, regardless of user activity, as described inSec. 7.2. Reauthentication of the subscriber SHALL be repeated following any period ofinactivity lasting 15 minutes or longer. Reauthentication SHALL use both authentication
factors. The session SHALL be terminated (i.e., logged out) when either of these time
limits is reached. The verifier MAY prompt the user to cause activity just before theinactivity timeout.
4.3.4. Security Controls
The CSP SHALL employ appropriately tailored security controls from the baseline
security controls defined in [SP800-53] or equivalent federal (e.g., [FEDRAMP]) or
industry standard that the organization has determined for the information systems,
applications, and online services that these guidelines are used to protect. The CSPSHALL ensure that the minimum assurance-related controls for the appropriate systems,
or equivalent, are satisfied.
4.3.5. Records Retention Policy
The CSP SHALL comply with its respective records retention policies in accordancewith applicable laws, regulations, and policies, including any NARA records retention
schedules that may apply. If the CSP opts to retain records in the absence of any
11

NIST SP 800-63B-4 ipd
December 2022

628
629
630

631
632
633

634
635
636
637
638
639
640
641

642
643

644
645
646
647

648
649

650
651
652

653
654

655
656

Digital Identity Guidelines
Authentication and Lifecycle Management

mandatory requirements, the CSP SHALL conduct a risk management process, including
assessments of privacy and security risks, to determine how long records should be
retained and SHALL inform the subscriber of that retention policy.
4.4. Privacy Requirements
The CSP SHALL employ appropriately tailored privacy controls defined in [SP800-53]
or equivalent industry standard.
If CSPs process attributes for purposes other than identity proofing, authentication, or
attribute assertions (collectively “identity service”), related fraud mitigation, or to comply
with law or legal process, CSPs SHALL implement measures to maintain predictability
and manageability commensurate with the privacy risk arising from the additional
processing. Measures MAY include providing clear notice, obtaining subscriber consent,
or enabling selective use or disclosure of attributes. When CSPs use consent measures,
CSPs SHALL NOT make consent for the additional processing a condition of the identity
service.
Regardless of whether the CSP is an agency or private sector provider, the following
requirements apply to a federal agency offering or using the authentication service:
1. The agency SHALL consult with their Senior Agency Official for Privacy (SAOP)
and conduct an analysis to determine whether the collection of PII to issue ormaintain authenticators triggers the requirements of the Privacy Act of 1974
[PrivacyAct] (see Sec. 9.4).
2. The agency SHALL publish a System of Records Notice (SORN) to cover suchcollections, as applicable.
3. The agency SHALL consult with their SAOP and conduct an analysis to determine
whether the collection of PII to issue or maintain authenticators triggers therequirements of the E-Government Act of 2002 [E-Gov].
4. The agency SHALL publish a Privacy Impact Assessment (PIA) to cover suchcollection, as applicable.
4.5. Summary of Requirements
Table 1 provides a non-normative summary of the requirements for each of the AALs.

12

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

Table 1. AAL Summary of Requirements

Requirement
Permitted
authenticator
types

AAL1
Memorized Secret;Look-up Secret;Out-of-Band; SF
OTP Device; MF
OTP Device; SF
Crypto Software;
SF Crypto Device;
MF Crypto
Software; MF
Crypto Device[SP800-53] Low
Baseline (orequivalent)
Required
Not required

AAL2
AAL3
MF Out-ofMF Crypto Device;
Band; MF OTP
SF Crypto Device
Device; MF Crypto plus Memorized
Secret; SF OTP
Software; MF
Device plus MF
Crypto Device;
Crypto Device oror Memorized
Secret plus: Look- Software; SF OTP
Device plus SF
up Secret, OutCrypto Software plus
of-Band, SF OTP
Device, SF Crypto Memorized Secret
Software, SF
Crypto Device
Level 1
Level 2 overall (MF(Government
authenticators) Level
agency1 overall (verifiers
authenticators andand SF Crypto
Devices) Level 3
verifiers)
physical security (allauthenticators)
12 hours or 30
12 hours or 15
minutes inactivity; minutes inactivity;
one authentication both authentication
factorfactors[SP800-53][SP800-53] High
Moderate Baseline Baseline (or(or equivalent)
equivalent)
Required
RequiredRecommended
Required

FIPS 140
validation

Level 1(Government
agency verifiers)

Not required

Not required

Required

Not required

Required

Required

Not required

Recommended

Required

Reauthentication 30 days

Security
controls
AitM resistance
Phishing
resistance
Verifiercompromise
resistance
Replayresistance
Authentication
intent13

NIST SP 800-63B-4 ipd
December 2022

657

5.

658

This section is normative.

659
660
661
662
663

664
665
666
667
668
669
670

671
672
673
674

675
676
677

678
679
680
681
682

683
684
685
686
687
688
689
690
691

Digital Identity Guidelines
Authentication and Lifecycle Management

Authenticator and Veriﬁer Requirements

This section provides the detailed requirements specific to each type of authenticator.
With the exception of reauthentication requirements specified in Sec. 4 and therequirement for phishing resistance at AAL3 described in Sec. 5.2.5, the technicalrequirements for each of the authenticator types are the same regardless of the AAL at
which the authenticator is used.
5.1. Requirements by Authenticator Type5.1.1. Memorized Secrets
A Memorized Secret authenticator — commonly referred to as a password or, if numeric,a PIN — is a secret value intended to be chosen and memorized by the user. Memorized
secrets need to be of sufficient complexity and secrecy that it would be impractical for
an attacker to guess or otherwise discover the correct secret value. A memorized secret issomething you know.
The requirements in this section apply to centrally verified memorized secrets thatare used as an independent authentication factor, sent over an authenticated protectedchannel to the verifier of a CSP. Memorized secrets that are used locally by a multi-factor
authenticator are referred to as activation secrets and discussed in Sec. 5.2.11.
5.1.1.1. Memorized Secret Authenticators
Memorized secrets SHALL be at least 8 characters in length. Memorized secrets SHALL
be either chosen by the subscriber or assigned randomly by the CSP.
If the CSP disallows a chosen memorized secret because it is on a blocklist of commonly
used, expected, or compromised values (see Sec. 5.1.1.2), the subscriber SHALL be
required to choose a different memorized secret. No other complexity requirements formemorized secrets SHALL be imposed. A rationale for this is presented in Appendix A
Strength of Memorized Secrets.
5.1.1.2. Memorized Secret Veriﬁers
Verifiers SHALL require memorized secrets to be at least 8 characters in length. Verifiers
SHOULD permit memorized secrets to be at least 64 characters in length. All printing
ASCII [RFC20] characters as well as the space character SHOULD be acceptable inmemorized secrets. Unicode [ISO/ISC 10646] characters SHOULD be accepted as well.
Verifiers MAY make allowances for likely mistyping, such as removing leading andtrailing whitespace characters prior to verification or allowing verification of memorized
secrets with differing case for the leading character, provided memorized secrets remain
at least 8 characters in length after such processing.

14

NIST SP 800-63B-4 ipd
December 2022

692
693
694

695
696
697
698
699
700
701

702
703
704
705
706

707
708
709
710

Digital Identity Guidelines
Authentication and Lifecycle Management

Verifiers SHALL verify the entire submitted memorized secret (i.e., not truncate thesecret). For purposes of the above length requirements, each Unicode code point SHALL
be counted as a single character.
If Unicode characters are accepted in memorized secrets, the verifier SHOULD apply
the normalization process for stabilized strings using either the NFKC or NFKD
normalization defined in Sec. 12.1 of Unicode Normalization Forms [UAX15]. This
process is applied before hashing the byte string representing the memorized secret.
Subscribers choosing memorized secrets containing Unicode characters SHOULD beadvised that some characters may be represented differently by some endpoints, which
can affect their ability to authenticate successfully.
Memorized secret verifiers SHALL NOT permit the subscriber to store a hint that isaccessible to an unauthenticated claimant. Verifiers SHALL NOT prompt subscribers
to use specific types of information (e.g., “What was the name of your first pet?”, atechnique known as knowledge-based authentication (KBA) or security questions) whenchoosing memorized secrets.
When processing requests to establish and change memorized secrets, verifiers SHALL
compare the prospective secrets against a blocklist that contains values known to becommonly used, expected, or compromised. For example, the list MAY include, but
is not limited to:711• Passwords obtained from previous breach corpuses.

712• Dictionary words.

713• Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).

714
715

716
717
718
719
720
721
722
723
724

725
726
727
728

• Context-specific words, such as the name of the service, the username, andderivatives thereof.
If the chosen secret is found in the blocklist, the CSP or verifier SHALL advise thesubscriber that they need to select a different secret, SHALL provide the reason forrejection, and SHALL require the subscriber to choose a different value. Since theblocklist is used to defend against brute-force attacks and unsuccessful attempts arerate limited as described below, the blocklist SHOULD be of a size sufficient to prevent
subscribers from choosing memorized secrets that attackers are likely to guess before
reaching the attempt limit. Excessively large blocklists SHOULD NOT be used because
they frustrate subscribers’ attempts to establish an acceptable memorized secret and do
not provide significantly improved security.
Verifiers SHALL offer guidance to the subscriber to assist the user in choosing a strong
memorized secret. This is particularly important following the rejection of a memorized
secret on the above list as it discourages trivial modification of listed (and likely veryweak) memorized secrets [Blocklists].

15

NIST SP 800-63B-4 ipd
December 2022

729
730
731

732
733
734
735
736

737
738
739
740

Digital Identity Guidelines
Authentication and Lifecycle Management

Verifiers SHALL implement a rate-limiting mechanism that effectively limits the numberof failed authentication attempts that can be made on the subscriber account as describedin Sec. 5.2.2.
Verifiers SHALL NOT impose other composition rules (e.g., requiring mixtures ofdifferent character types or prohibiting consecutively repeated characters) for memorized
secrets. Verifiers SHALL NOT require users to periodically change memorized secrets.
However, verifiers SHALL force a change if there is evidence of compromise of theauthenticator.
Verifiers SHALL allow the use of password managers. To facilitate their use, verifiers
SHOULD permit claimants to use “paste” functionality when entering a memorized
secret. Password manangers may increase the likelihood that users will choose stronger
memorized secrets.

In order to assist the claimant in successfully entering a memorized secret, the verifier
SHOULD offer an option to display the secret — rather than a series of dots or asterisks
742
743 — while it is entered and until it is submitted to the verifier. This allows the claimant toconfirm their entry if they are in a location where their screen is unlikely to be observed.
744
The verifier MAY also permit the claimant’s device to display individual entered745
characters for a short time after each character is typed to verify correct entry. This is746
common on mobile devices.
747
741

748
749
750

751
752
753
754
755
756
757
758
759
760
761
762
763
764
765

766
767
768

The verifier SHALL use approved encryption and an authenticated protected channel
when requesting memorized secrets in order to provide resistance to eavesdropping andadversary-in-the-middle attacks.
Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks.
Memorized secrets SHALL be salted and hashed using a suitable password hashing
scheme. Password hashing schemes take a password, a salt, and a cost factor as inputs andgenerate a password hash. Their purpose is to make each password guess more expensive
for an attacker who has obtained a hashed password file and thereby make the cost of aguessing attack high or prohibitive. A function that is both memory-hard and computehard SHOULD be used because it increases the cost of an attack. While NIST has not
published guidelines on specific password hashing schemes, examples of such functions
include Argon2 [Argon2] and scrypt [Scrypt]. Examples of approved one-way functions
include Keyed Hash Message Authentication Code (HMAC) [FIPS198-1], any approved
hash function in [SP800-107], Secure Hash Algorithm 3 (SHA-3) [FIPS202], CMAC
[SP800-38B], Keccak Message Authentication Code (KMAC), Customizable SHAKE(cSHAKE), and ParallelHash [SP800-185]. The chosen output length of the password
hashing scheme SHOULD be the same as the length of the underlying one-way function
output.
The salt SHALL be at least 32 bits in length and be chosen arbitrarily so as to minimize
salt value collisions among stored hashes. Both the salt value and the resulting hash
SHALL be stored for each memorized secret authenticator.
16

NIST SP 800-63B-4 ipd
December 2022

769
770
771
772

773
774
775
776
777
778
779
780
781

782
783
784
785
786
787
788
789

790
791
792
793
794

795
796
797
798

799
800

801
802
803
804
805

Digital Identity Guidelines
Authentication and Lifecycle Management

For the Password-based Key Derivation Function 2 (PBKDF2) [SP800-132], the cost
factor is an iteration count: the more times the PBKDF2 function is iterated, the longer ittakes to compute the password hash. Therefore, the iteration count SHOULD be as large
as verification server performance will allow, typically at least 10,000 iterations.
In addition, verifiers SHOULD perform an additional iteration of a keyed hashing or
encryption operation using a secret key known only to the verifier. This key value, if used,
SHALL be generated by an approved random bit generator [SP800-90Ar1] and provide atleast the minimum security strength specified in the latest revision of NIST SP 800-131A,
Transitioning the Use of Cryptographic Algorithms and Key Lengths [SP800-131A] (112
bits as of the date of this publication). The secret key value SHALL be stored separatelyfrom the hashed memorized secrets (e.g., in a specialized device like a hardware security
module). With this additional iteration, brute-force attacks on the hashed memorized
secrets are impractical as long as the secret key value remains secret.
5.1.2. Look-Up Secrets
A look-up secret authenticator is a physical or electronic record that stores a set of secrets
shared between the claimant and the CSP. The claimant uses the authenticator to lookup the appropriate secrets needed to respond to a prompt from the verifier. For example,
the verifier could ask a claimant to provide a specific subset of the numeric or character
strings printed on a card in table format. A common application of look-up secrets isthe use of one-time “recovery keys” stored by the subscriber for use in the event anotherauthenticator is lost or malfunctions. A look-up secret is something you have.
5.1.2.1. Look-Up Secret Authenticators
CSPs creating look-up secret authenticators SHALL use an approved random bit
generator [SP800-90Ar1] to generate the list of secrets and SHALL deliver theauthenticator securely to the subscriber. Look-up secrets SHALL have at least 20 bitsof entropy.
Look-up secrets MAY be distributed by the CSP in person, by postal mail to thesubscriber’s address of record, or by online distribution. If distributed online, lookup secrets SHALL be distributed over a secure channel in accordance with the postenrollment binding requirements in Sec. 6.1.2.
If the authenticator uses look-up secrets sequentially from a list, the subscriber MAY
dispose of used secrets, but only after a successful authentication.
5.1.2.2. Look-Up Secret Veriﬁers
Verifiers of look-up secrets SHALL prompt the claimant for the next secret fromtheir authenticator or for a specific (e.g., numbered) secret. A given secret from anauthenticator SHALL be used successfully only once. If the look-up secret is derived
from a grid card, each cell of the grid SHALL be used only once.
17

NIST SP 800-63B-4 ipd
December 2022

806
807
808
809
810
811
812

813
814
815

816
817
818

819
820
821
822
823
824

Digital Identity Guidelines
Authentication and Lifecycle Management

Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Lookup secrets having at least 112 bits of entropy SHALL be hashed with an approved oneway function as described in Sec. 5.1.1.2. Look-up secrets with fewer than 112 bitsof entropy SHALL be salted and hashed using a suitable password hashing scheme,
also described in Sec. 5.1.1.2. The salt value SHALL be at least 32 bits in length andarbitrarily chosen so as to minimize salt value collisions among stored hashes. Both thesalt value and the resulting hash SHALL be stored for each look-up secret.
For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implementa rate-limiting mechanism that effectively limits the number of failed authentication
attempts that can be made on the subscriber account as described in Sec. 5.2.2.
The verifier SHALL use approved encryption and an authenticated protected channel
when requesting look-up secrets in order to provide resistance to eavesdropping and AitM
attacks.
5.1.3. Out-of-Band Devices
An out-of-band authenticator is a physical device that is uniquely addressable and cancommunicate securely with the verifier over a distinct communications channel, referred
to as the secondary channel. The device is possessed and controlled by the claimant andsupports private communication over this secondary channel, separate from the primarychannel for authentication. An out-of-band authenticator is something you have.

827

Out-of-band authentiction uses a short-term secret generated by the verifier. The secret’s
purpose is to securely bind the authentication operation on the primary and secondary
channel and establishes the claimant’s control of the out-of-band device.

828

The out-of-band authenticator can operate in one of the following ways:

825
826

829
830
831
832

833
834
835
836
837

838
839
840
841
842

• The claimant transfers a secret received by the out-of-band device via the secondary
channel to the verifier using the primary channel. For example, the claimant may
receive the secret (typically a 6-digit code) on their mobile device and type it into
their authentication session. This method is shown in Figure 1.
• The claimant transfers a secret received via the primary channel to the out-of-band
device for transmission to the verifier via the secondary channel. For example, theclaimant may view the secret on their authentication session and either type it into
an app on their mobile device or use a technology such as a barcode or QR code toeffect the transfer. This method is shown in Figure 2.
Note: A third method of out-of-band authentication involving the comparisonof secrets received from the primary and secondary channels and approvingon the secondary channel is no longer considered acceptable because it was
rarely implemented as described. It raised the likelihood that the claimant
would just approve without actually comparing the secrets. For example,
18

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

Figure 1. Transfer of Secret to Primary Device

19

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

Figure 2. Transfer of Secret to Out-of-band Device

20

NIST SP 800-63B-4 ipd
December 2022

843
844
845
846

847
848
849
850
851
852

853
854
855
856
857
858

859
860

861
862

863
864
865

866
867
868

869
870
871
872
873

874
875
876
877
878
879

Digital Identity Guidelines
Authentication and Lifecycle Management

an authenticator that receives a push notification from the verifier andsimply asks the claimant to approve the transaction (even if providing
some additional information about the authentication) does not meet therequirements of this section.
5.1.3.1. Out-of-Band Authenticators
The out-of-band authenticator SHALL establish a separate channel with the verifier
in order to retrieve the out-of-band secret or authentication request. This channel isconsidered to be out-of-band with respect to the primary communication channel (even if
it terminates on the same device) provided the device does not leak information from one
channel to the other without the authorization of the claimant.
The out-of-band device SHOULD be uniquely addressable by the verifier.
Communication over the secondary channel SHALL be encrypted unless sent via the
public switched telephone network (PSTN). For additional authenticator requirements
specific to use of the PSTN for out-of-band authentication, see Sec. 5.1.3.3. Channels or
addresses that do not prove possession of a specific device, such as voice-over-IP (VOIP)
telephone numbers, SHALL NOT be used for out-of-band authentication.
Email SHALL NOT be used for out-of-band authentication because it also does not prove
possession of a specific device and is typically accessed using only a memorized secret.
The out-of-band authenticator SHALL uniquely authenticate itself in one of the following
ways when communicating with the verifier:• Establish an authenticated protected channel to the verifier using approved
cryptography. The key used SHALL be stored in suitably secure storage available
to the authenticator application (e.g., keychain storage, TPM, TEE, secure element).
• Authenticate to a public mobile telephone network using a SIM card or equivalentthat uniquely identifies the device. This method SHALL only be used if a secret isbeing sent from the verifier to the out-of-band device via the PSTN (SMS or voice).
If a secret is sent by the verifier to the out-of-band device, the device SHOULD NOT
display the authentication secret while it is locked by the owner (i.e., SHOULD require
the presentation and verification of a PIN, passcode, or biometric characteristic to view).
However, authenticators SHOULD indicate the receipt of an authentication secret on alocked device.
If the out-of-band authenticator requests approval over the secondary communication
channel — rather than by the presenting a secret that the claimant transfers to the primarycommunication channel — it SHALL accept transfer of the secret from the primarychannel and send it to the verifier over the secondary channel to associate the approvalwith the authentication transaction. The claimant MAY perform the transfer manually or
use a technology such as a barcode or QR code to effect the transfer.
21

NIST SP 800-63B-4 ipd
December 2022

880
881

882
883
884
885
886
887
888

889
890

891
892
893
894
895

896
897
898
899

900
901
902

903
904
905
906
907

908
909
910
911
912

913
914
915

Digital Identity Guidelines
Authentication and Lifecycle Management

5.1.3.2. Out-of-Band Veriﬁers
For additional verification requirements specific to the PSTN, see Sec. 5.1.3.3.
When the out-of-band authenticator is a secure application, such as on a smart phone,
the verifier MAY send a push notification to that device. The verifier waits for theestablishment of an authenticated protected channel with the out-of-band authenticatorand verifies its identifying key. The verifier SHALL NOT store the identifying key
itself, but SHALL use a verification method (e.g., an approved hash function or proofof possession of the identifying key) to uniquely identify the authenticator. Onceauthenticated, the verifier transmits the authentication secret to the authenticator.
Depending on the type of out-of-band authenticator, one of the following SHALL takeplace:• Transfer of secret from the secondary to the primary channel: The verifier MAY
signal the device containing the subscriber’s authenticator to indicate readinessto authenticate. It SHALL then transmit a random secret to the out-of-band
authenticator. The verifier SHALL then wait for the secret to be returned on the
primary communication channel.
• Transfer of secret from the primary to the secondary channel: The verifier SHALL
display a random authentication secret to the claimant via the primary channel. It
SHALL then wait for the secret to be returned on the secondary channel from theclaimant’s out-of-band authenticator.
In all cases, the authentication SHALL be considered invalid if not completed within 10
minutes. In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL
accept a given authentication secret only once during the validity period.
The verifier SHALL generate random authentication secrets with at least 20 bits ofentropy using an approved random bit generator [SP800-90Ar1]. If the authentication
secret has less than 64 bits of entropy, the verifier SHALL implement a rate-limiting
mechanism that effectively limits the number of failed authentication attempts that can bemade on the subscriber account as described in Sec. 5.2.2.
Out-of-band verifiers SHALL consider all authentication operations to be single-factor
unless the CSP has confirmed that the out-of-band authentication meets the requirementsof Sec. 5.1.3.4. This requirement MAY be satisfied by issuance of the authenticator by
the CSP or a trusted third party or by use of an authentication application known by the
CSP to meet these requirements.
Out-of-band verifiers that send a push notification to a subscriber device SHOULD
implement a reasonable limit on the rate or total number of push notifications that will besent since the last successful authentication.

22

NIST SP 800-63B-4 ipd
December 2022

916
917
918
919
920
921

922
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

Digital Identity Guidelines
Authentication and Lifecycle Management

5.1.3.3. Authentication using the Public Switched Telephone Network
Use of the PSTN for out-of-band verification is restricted as described in this section
and in Sec. 5.2.10. If out-of-band verification is to be made using the PSTN, the verifier
SHALL verify that the pre-registered telephone number being used is associated with a
specific physical device. Changing the pre-registered telephone number is considered tobe the binding of a new authenticator and SHALL only occur as described in Sec. 6.1.2.
Use of the PSTN to deliver out-of-band authentication secrets is potentially not available
to some subscribers in areas with limited telephone coverage (particularly in areas
without mobile phone service). Accordingly, verifiers SHALL ensure that alternative
authenticator types are available to all subscribers and SHOULD remind subscribers of
this limitation of PSTN out-of-band authenticators prior to binding.
Verifiers SHOULD consider risk indicators such as device swap, SIM change, number
porting, or other abnormal behavior before using the PSTN to deliver an out-of-band
authentication secret.
NOTE: Consistent with the restriction of authenticators in Sec. 5.2.10, NIST
may adjust the restricted status of the PSTN over time based on the evolutionof the threat landscape and the technical operation of the PSTN.
5.1.3.4. Multi-Factor Out-of-Band Authenticators
Multi-factor out-of-band authenticators operate in a similar manner to single-factor outof-band authenticators (see Sec. 5.1.3.1) except that they require the presentation andverification of an additional factor, either a memorized secret or a biometric characteristic,prior to allowing the claimant to complete the authentication transaction (i.e., prior toaccessing the authentication secret, entering the authentication secret, or confirming
the transaction as appropriate for the authentication flow being used). Each use of theauthenticator SHALL require the presentation of the activation factor.
The use of an activation secret by the authenticator SHALL meet the requirements ofSec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3,
including limits on the number of consecutive authentication failures. Submission of theactivation factor SHALL be a separate operation from unlocking of the host device (e.g.,smartphone), although the same activation factor used to unlock the host device MAY
be used in the authentication operation. The memorized secret or biometric sample used
for activation — and any biometric data derived from the biometric sample such as aprobe produced through signal processing — SHALL be zeroized immediately after theauthentication operation.
5.1.4. Single-Factor OTP Device
A single-factor OTP device generates one-time passwords (OTPs). This category includes
hardware devices and software-based OTP generators installed on devices such as mobile
23

NIST SP 800-63B-4 ipd
December 2022

953
954
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

Digital Identity Guidelines
Authentication and Lifecycle Management

phones. These devices have an embedded secret that is used as the seed for generation of
OTPs and does not require activation through a second factor. The OTP is displayed on
the device and manually input for transmission to the verifier, thereby proving possession
and control of the device. An OTP device may, for example, display 6 characters at a time.
A single-factor OTP device is something you have.
Single-factor OTP devices are similar to look-up secret authenticators with the exceptionthat the secrets are cryptographically and independently generated by the authenticatorand verifier and compared by the verifier. The secret is computed based on a nonce that
may be time-based or from a counter on the authenticator and verifier.
5.1.4.1. Single-Factor OTP Authenticators
Single-factor OTP authenticators contain two persistent values. The first is a symmetric
key that persists for the device’s lifetime. The second is a nonce that is either changed
each time the authenticator is used or is based on a real-time clock.
The secret key and its algorithm SHALL provide at least the minimum security
strength specified in the latest revision of [SP800-131A] (112 bits as of the date of thispublication). The nonce SHALL be of sufficient length to ensure that it is unique for each
operation of the device over its lifetime. If a subscriber needs to change the device used
for a software-based OTP authenticator, they SHOULD bind the authenticator applicationon the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate
the authenticator application that will no longer be used.
The authenticator output is obtained by using an approved block cipher or hash function
to combine the key and nonce in a secure manner. The authenticator output MAY be
truncated to as few as 6 decimal digits (approximately 20 bits of entropy).
If the nonce used to generate the authenticator output is based on a real-time clock, thenonce SHALL be changed at least once every 2 minutes.
5.1.4.2. Single-Factor OTP Veriﬁers
Single-factor OTP verifiers effectively duplicate the process of generating the OTP usedby the authenticator. As such, the symmetric keys used by authenticators are also present
in the verifier, and SHALL be strongly protected against unauthorized disclosure by theuse of access controls that limit access to the keys to only those software components on
the device requiring access.
When a single-factor OTP authenticator is being associated with a subscriber account,the verifier or associated CSP SHALL use approved cryptography to either generate andexchange or to obtain the secrets required to duplicate the authenticator output.
The verifier SHALL use approved encryption and an authenticated protected channel
when collecting the OTP in order to provide resistance to eavesdropping and AitM attacks.
24

NIST SP 800-63B-4 ipd
December 2022

989
990
991
992
993

994
995
996

997
998
999

1000
1001
1002
1003
1004
1005
1006
1007
1008
1009

1010
1011
1012
1013
1014
1015

1016
1017
1018
1019

1020
1021
1022
1023
1024

Digital Identity Guidelines
Authentication and Lifecycle Management

In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL accept agiven OTP only once while it is valid. In the event a claimant’s authentication is denied
due to duplicate use of an OTP, verifiers MAY warn the claimant in case an attacker has
been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing
session of the attempted duplicate use of an OTP.
Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the
expected clock drift — in either direction — of the authenticator over its lifetime, plus
allowance for network delay and user entry of the OTP.
If the authenticator output has less than 64 bits of entropy, the verifier SHALL implementa rate-limiting mechanism that effectively limits the number of failed authentication
attempts that can be made on the subscriber account as described in Sec. 5.2.2.
5.1.5. Multi-Factor OTP Devices
A multi-factor OTP device generates OTPs for use in authentication after activation
through input of an activation factor. This includes hardware devices and softwarebased OTP generators installed on devices such as mobile phones. The second factor
of authentication may be achieved through some kind of integral entry pad, an integral
biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). The
OTP is displayed on the device and manually input for transmission to the verifier. For
example, an OTP device may display 6 characters at a time, thereby proving possession
and control of the device. The multi-factor OTP device is something you have, and it
SHALL be activated by either something you know or something you are.
5.1.5.1. Multi-Factor OTP Authenticators
Multi-factor OTP authenticators operate in a similar manner to single-factor OTP
authenticators (see Sec. 5.1.4.1), except that they require the presentation and verificationof either a memorized secret or a biometric characteristic to obtain the OTP from theauthenticator. Each use of the authenticator SHALL require the input of the activation
factor.
In addition to activation information, multi-factor OTP authenticators contain two
persistent values. The first is a symmetric key that persists for the device’s lifetime. The
second is a nonce that is either changed each time the authenticator is used or is based ona real-time clock.
The secret key and its algorithm SHALL provide at least the minimum security
strength specified in the latest revision of [SP800-131A] (112 bits as of the date of thispublication). The nonce SHALL be of sufficient length to ensure that it is unique for each
operation of the device over its lifetime. If a subscriber needs to change the device used
for a software-based OTP authenticator, they SHOULD bind the authenticator application

25

NIST SP 800-63B-4 ipd
December 2022

1025
1026

1027
1028
1029

1030
1031

1032
1033
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

Digital Identity Guidelines
Authentication and Lifecycle Managementon the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate
the authenticator application that will no longer be used.
The authenticator output is obtained by using an approved block cipher or hash function
to combine the key and nonce in a secure manner. The authenticator output MAY be
truncated to as few as 6 decimal digits (approximately 20 bits of entropy).
If the nonce used to generate the authenticator output is based on a real-time clock, thenonce SHALL be changed at least once every 2 minutes.
The use of an activation secret by the authenticator SHALL meet the requirements ofSec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3,
including limits on the number of consecutive authentication failures. Submission of theactivation factor SHALL be a separate operation from unlocking of the host device (e.g.,smartphone), although the same activation factor used to unlock the host device MAY
be used in the authentication operation. The unencrypted key and activation secret or
biometric sample — and any biometric data derived from the biometric sample such as aprobe produced through signal processing — SHALL be zeroized immediately after an
OTP has been generated.
5.1.5.2. Multi-Factor OTP Veriﬁers
Multi-factor OTP verifiers effectively duplicate the process of generating the OTP usedby the authenticator, but without the requirement that a second factor be provided. As
such, the symmetric keys used by authenticators SHALL be strongly protected against
unauthorized disclosure by the use of access controls that limit access to the keys to only
those software components on the device requiring access.
When a multi-factor OTP authenticator is being associated with a subscriber account,the verifier or associated CSP SHALL use approved cryptography to either generate
and exchange or to obtain the secrets required to duplicate the authenticator output.
The verifier or CSP SHALL also establish, by issuance of the authentictor, thatthe authenticator is a multi-factor device. Otherwise, the verifier SHALL treat theauthenticator as single-factor, in accordance with Sec. 5.1.4.
The verifier SHALL use approved encryption and an authenticated protected channel
when collecting the OTP in order to provide resistance to eavesdropping and AitM attacks.
In order to provide replay resistance as described in Sec. 5.2.8, verifiers SHALL accept agiven OTP only once while it is valid. In the event a claimant’s authentication is denied
due to duplicate use of an OTP, verifiers MAY warn the claimant in case an attacker has
been able to authenticate in advance. Verifiers MAY also warn a subscriber in an existing
session of the attempted duplicate use of an OTP.
Time-based OTPs [TOTP] SHALL have a defined lifetime that is determined by the
expected clock drift — in either direction — of the authenticator over its lifetime, plus
allowance for network delay and user entry of the OTP.
26

NIST SP 800-63B-4 ipd
December 2022

1063
1064
1065
1066

1067
1068
1069
1070
1071
1072

1073
1074
1075
1076
1077
1078
1079

1080
1081
1082
1083

1084
1085
1086

1087
1088
1089
1090
1091
1092
1093
1094
1095
1096

Digital Identity Guidelines
Authentication and Lifecycle Management

If the authenticator output or activation secret has less than 64 bits of entropy, the verifier
SHALL implement a rate-limiting mechanism that effectively limits the number offailed authentication attempts that can be made on the subscriber account as describedin Sec. 5.2.2.
5.1.6. Single-Factor Cryptographic Software
A single-factor cryptographic software authenticator is a cryptographic key stored on
disk or some other “soft” media. Authentication is accomplished by proving possession
and control of the key. The authenticator output is highly dependent on the specificcryptographic protocol, but it is generally some type of signed message. The single-factor
cryptographic software authenticator is something you have.
5.1.6.1. Single-Factor Cryptographic Software Authenticators
Single-factor cryptographic software authenticators encapsulate one or more secret keys
unique to the authenticator. The key SHALL be stored in suitably secure storage available
to the authenticator application (e.g., keychain storage, TPM, or TEE if available). The
key SHALL be strongly protected against unauthorized disclosure by the use of access
controls that limit access to the key to only those software components on the device
requiring access.
External cryptographic authenticators that do not meet the requirements of cryptographic
hardware authenticators (e.g., that have a mechanism to allow private keys to be exported)
are also considered to be cryptographic software authenticators. They SHALL meet therequirements for connected authenticators in Sec. 5.2.12.
5.1.6.2. Single-Factor Cryptographic Software Veriﬁers
The requirements for a single-factor cryptographic software verifier are identical to those
for a single-factor cryptographic device verifier, described in Sec. 5.1.7.2.
5.1.7. Single-Factor Cryptographic Devices
A single-factor cryptographic device is a hardware device that performs cryptographic
operations using protected cryptographic keys and provides the authenticator output
via direct connection to the user endpoint. The device uses embedded symmetric or
asymmetric cryptographic keys, and does not require activation through a second factor
of authentication. Authentication is accomplished by proving possession of the device
via the authentication protocol. The authenticator output is provided by direct connection
to the user endpoint and is highly dependent on the specific cryptographic device andprotocol, but it is typically some type of signed message. A single-factor cryptographic
device is something you have.

27

NIST SP 800-63B-4 ipd
December 2022

1097
1098
1099
1100
1101
1102
1103
1104

1105
1106
1107
1108

1109
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
1135

Digital Identity Guidelines
Authentication and Lifecycle Management

5.1.7.1. Single-Factor Cryptographic Device Authenticators
Single-factor cryptographic device authenticators use tamper-resistant hardware toencapsulate one or more secret keys unique to the authenticator that SHALL NOT be
exportable (i.e., cannot be removed from the device). The authenticator operates using
a secret key to sign a challenge nonce presented through a direct interface between theauthenticator and endpoint (e.g., a USB port or secured wireless connection) as specified
in Sec. 5.2.12. Alternatively, the authenticator could be a suitably secure processor
integrated with the user endpoint itself.
The secret key and its algorithm SHALL provide at least the minimum security
length specified in the latest revision of [SP800-131A] (112 bits as of the date of thispublication). The challenge nonce SHALL be at least 64 bits in length. Approved
cryptography SHALL be used.
Cryptographic device authenticators differ from cryptographic software authenticators
because of the greater protection afforded to the embedded authentication secrets bycryptographic devices. In order to be considered a cryptographic device, an authenticator
SHALL either be a separate piece of hardware or an embedded processor or execution
environment, e.g., secure element, trusted execution environment (TEE), trusted platform
module (TPM). These hardware authenticators or embedded processors are separate
from a host processor such as the CPU on a laptop or mobile device. A cryptographic
device authenticator SHALL be designed so as to prohibit the export of the authentication
secret to the host processor and SHALL NOT be capable of being reprogrammed by thehost processor so as to allow the secret to be extracted. The authenticator is subject toapplicable [FIPS140] requirements of the AAL at which the authenticator is being used.
Single-factor cryptographic device authenticators SHOULD require a physical input (e.g.,
the pressing of a button) in order to operate. This provides defense against unintended
operation of the device, which might occur if the endpoint to which it is connected iscompromised.
5.1.7.2. Single-Factor Cryptographic Device Veriﬁers
Single-factor cryptographic device verifiers generate a challenge nonce, send it to thecorresponding authenticator, and use the authenticator output to verify possession of thedevice. The authenticator output is highly dependent on the specific cryptographic device
and protocol, but it is generally some type of signed message.
The verifier has either symmetric or asymmetric cryptographic keys corresponding toeach authenticator. While both types of keys SHALL be protected against modification,
symmetric keys SHALL additionally be protected against unauthorized disclosure by theuse of access controls that limit access to the key to only those software components on
the device requiring access.
The challenge nonce SHALL be at least 64 bits in length, and SHALL either be uniqueover the authenticator’s lifetime or statistically unique (i.e., generated using an approved
28

NIST SP 800-63B-4 ipd
December 2022

1136
1137

1138
1139
1140
1141
1142
1143
1144
1145

1146
1147
1148
1149
1150
1151
1152
1153

1154
1155
1156
1157

1158
1159

1160
1161
1162
1163
1164
1165
1166
1167
1168

1169
1170
1171

Digital Identity Guidelines
Authentication and Lifecycle Management

random bit generator [SP800-90Ar1]). The verification operation SHALL use approved
cryptography.
5.1.8. Multi-Factor Cryptographic Software
A multi-factor cryptographic software authenticator is a cryptographic key stored on
disk or some other “soft” media that requires activation through a second factor ofauthentication. Authentication is accomplished by proving possession and control of thekey. The authenticator output is highly dependent on the specific cryptographic protocol,
but it is generally some type of signed message. The multi-factor cryptographic software
authenticator is something you have, and it SHALL be activated by either something you
know or something you are.
5.1.8.1. Multi-Factor Cryptographic Software Authenticators
Multi-factor cryptographic software authenticators encapsulate one or more secret keys
unique to the authenticator and accessible only through the presentation and verificationof an activation factor, either a memorized secret or a biometric characteristic. The key
SHOULD be stored in suitably secure storage available to the authenticator application(e.g., keychain storage, TPM, TEE). The key SHALL be strongly protected against
unauthorized disclosure by the use of access controls that limit access to the key to only
those software components on the device requiring access.
External cryptographic authenticators that do not meet the requirements of cryptographic
hardware authenticators (e.g., that have a mechanism to allow private keys to be exported)
are also considered to be cryptographic software authenticators. They SHALL meet therequirementss for connected authenticators in Sec. 5.2.12.
Each authentication operation using the authenticator SHALL require the input of theactivation factor.
The use of an activation secret by the authenticator SHALL meet the requirements ofSec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3,
including limits on the number of consecutive authentication failures. Submission of theactivation factor SHALL be a separate operation from unlocking of the host device (e.g.,smartphone), although the same activation factor used to unlock the host device MAY
be used in the authentication operation. The activation secret or biometric sample — andany biometric data derived from the biometric sample such as a probe produced throughsignal processing — SHALL be zeroized immediately after an authentication transaction
has taken place.
5.1.8.2. Multi-Factor Cryptographic Software Veriﬁers
The requirements for a multi-factor cryptographic software verifier are identical to those
for a single-factor cryptographic device verifier, described in Sec. 5.1.7.2. Verification
29

NIST SP 800-63B-4 ipd
December 2022

1172
1173

1174
1175
1176
1177
1178
1179
1180
1181
1182

1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193

1194
1195
1196
1197

1198
1199
1200
1201
1202
1203
1204
1205
1206
1207

Digital Identity Guidelines
Authentication and Lifecycle Managementof the output from a multi-factor cryptographic software authenticator proves use of theactivation factor.
5.1.9. Multi-Factor Cryptographic Devices
A multi-factor cryptographic device is a hardware device that performs cryptographic
operations using one or more protected cryptographic keys and requires activation
through a second authentication factor. Authentication is accomplished by proving
possession of the device and control of the key. The authenticator output is provided
by direct connection to the user endpoint and is highly dependent on the specificcryptographic device and protocol, but it is typically some type of signed message. The
multi-factor cryptographic device is something you have, and it SHALL be activated byeither something you know or something you are.
5.1.9.1. Multi-Factor Cryptographic Device Authenticators
Multi-factor cryptographic device authenticators use tamper-resistant hardware toencapsulate one or more secret keys unique to the authenticator that SHALL NOT
be exportable (i.e., cannot be removed from the device). The secret key SHALL beaccessible only through the presentation and verification of an activation factor, eithera biometric characteristic or an activation secret as described in Sec. 5.2.11. The
authenticator operates by using a secret key that was unlocked by the activation factor
to sign a challenge nonce presented through a direct interface between the authenticatorand endpoint (e.g., a USB port or secured wireless connection) as specified in Sec. 5.2.12.
Alternatively, the authenticator could be a suitably secure processor integrated with theuser endpoint itself (e.g., a hardware TPM).
The secret key and its algorithm SHALL provide at least the minimum security
length specified in the latest revision of [SP800-131A] (112 bits as of the date of thispublication). The challenge nonce SHALL be at least 64 bits in length. Approved
cryptography SHALL be used.
Cryptographic device authenticators differ from cryptographic software authenticators
because of the greater protection afforded to the embedded authentication secrets bycryptographic devices. In order to be considered a cryptographic device, an authenticator
SHALL either be a separate piece of hardware or an embedded processor or execution
environment, e.g., secure element, trusted execution environment (TEE), trusted platform
module (TPM). A cryptographic device authenticator SHALL be designed so as toprohibit the export of the authentication secret to the host processor and SHALL NOT
be capable of being reprogrammed by the host processor so as to allow the secret to be
extracted. The authenticator is subject to applicable [FIPS140] requirements of the AAL
at which the authenticator is being used.

30

NIST SP 800-63B-4 ipd
December 2022

1208
1209
1210

1211
1212
1213
1214
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

Digital Identity Guidelines
Authentication and Lifecycle Management

Each authentication operation using the authenticator SHOULD require the input of theactivation factor. Input of the activation factor MAY be accomplished via either direct
input on the device or via a hardware connection (e.g., USB, smartcard).
The use of an activation secret by the authenticator SHALL meet the requirements ofSec. 5.2.11. A biometric activation factor SHALL meet the requirements of Sec. 5.2.3,
including limits on the number of consecutive authentication failures. Submission of theactivation factor SHALL be a separate operation from unlocking of the host device (e.g.,smartphone), although the same activation factor used to unlock the host device MAY
be used in the authentication operation. The activation secret or biometric sample — andany biometric data derived from the biometric sample such as a probe produced throughsignal processing — SHALL be zeroized immediately after an authentication transaction
has taken place.
5.1.9.2. Multi-Factor Cryptographic Device Veriﬁers
The requirements for a multi-factor cryptographic device verifier are identical to those fora single-factor cryptographic device verifier, described in Sec. 5.1.7.2. Verification of theauthenticator output from a multi-factor cryptographic device proves use of the activation
factor.
5.2. General Authenticator Requirements
5.2.1. Physical Authenticators
CSPs SHALL provide subscriber instructions on how to appropriately protect theauthenticator against theft or loss. The CSP SHALL provide a mechanism to invalidate
the authenticator immediately upon notification from subscriber that loss or theft of theauthenticator is suspected.
5.2.2. Rate Limiting (Throttling)
When required by the authenticator type descriptions in Sec. 5.1, the verifier SHALL
implement controls to protect against online guessing attacks. Unless otherwise specified
in the description of a given authenticator, the verifier SHALL limit consecutive failed
authentication attempts on a single subscriber account to no more than 100.
Additional techniques MAY be used to reduce the likelihood that an attacker will lock thelegitimate claimant out as a result of rate limiting. These include:• Requiring the claimant to complete a bot-detection and mitigation challenge before
attempting authentication.
• Requiring the claimant to wait following a failed attempt for a period of timethat increases as the subscriber account approaches its maximum allowance forconsecutive failed attempts (e.g., 30 seconds up to an hour).

31

NIST SP 800-63B-4 ipd
December 2022

1243
1244
1245
1246
1247
1248

1249
1250

1251
1252
1253
1254
1255
1256

1257
1258

1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275

1276
1277

1278
1279

Digital Identity Guidelines
Authentication and Lifecycle Management• Accepting only authentication requests that come from an allowlist of IP addresses
from which the subscriber has been successfully authenticated before.
• Leveraging other risk-based or adaptive authentication techniques to identify user
behavior that falls within, or out of, typical norms. These might, for example,
include use of IP address, geolocation, timing of request patterns, or browser
metadata.
When the subscriber successfully authenticates, the verifier SHOULD disregard any
previous failed attempts for that user from the same IP address.
5.2.3. Use of Biometrics
The use of biometrics (something you are) in authentication includes both measurementof physical characteristics (e.g., fingerprint, iris, facial characteristics) and behavioral
characteristics (e.g., typing cadence). Both classes are considered biometric modalities,
although different modalities may differ in the extent to which they establish
authentication intent as described in Sec. 5.2.9.
For a variety of reasons, this document supports only limited use of biometrics forauthentication. These reasons include:• The biometric False Match Rate (FMR) does not provide confidence in theauthentication of the subscriber by itself. In addition, FMR does not account for
spoofing attacks.
• Biometric comparison is probabilistic, whereas the other authentication factors are
deterministic.
• Biometric template protection schemes provide a method for revoking biometriccredentials that is comparable to other authentication factors (e.g., PKI certificatesand passwords). However, the availability of such solutions is limited, andstandards for testing these methods are under development.
• Biometric characteristics do not constitute secrets. They can often be obtained
online or, in the case of a facial image, by taking a picture of someone with orwithout their knowledge. Latent fingerprints can be lifted from objects someone
touches, and iris patterns can be captured with high resolution images. While
presentation attack detection (PAD) technologies can mitigate the risk of thesetypes of attacks, additional trust in the sensor or biometric processing is required
to ensure that PAD is operating in accordance with the needs of the CSP and thesubscriber.
Therefore, the limited use of biometrics for authentication is supported with the following
requirements and guidelines:
Biometrics SHALL be used only as part of multi-factor authentication with a physicalauthenticator (something you have).
32

NIST SP 800-63B-4 ipd
December 2022

1280
1281
1282

1283
1284
1285
1286
1287
1288
1289

1290
1291
1292
1293
1294
1295
1296
1297
1298

1299
1300
1301

Digital Identity Guidelines
Authentication and Lifecycle Management

The biometric system SHALL operate with a false-match rate (FMR) [ISO/IEC2382-37]
of 1 in 10000 or better. This FMR SHALL be achieved under conditions of a conformant
attack (i.e., zero-effort impostor attempt) as defined in [ISO/IEC30107-1].
The biometric system SHOULD implement presentation attack detection (PAD). Testingof the biometric system to be deployed SHOULD demonstrate at least 90% resistanceto presentation attacks for each relevant attack type (i.e., species), where resistance isdefined as the number of thwarted presentation attacks divided by the number of trial
presentation attacks. Testing of presentation attack resistance SHALL be in accordancewith Clause 12 of [ISO/IEC30107-3]. The PAD decision MAY be made either locally on
the claimant’s device or by a central verifier.
The biometric system SHALL allow no more than 5 consecutive failed authentication
attempts or 10 consecutive failed attempts if PAD, meeting the above requirements, isimplemented. Once that limit has been reached, the biometric authenticator SHALL
impose a delay of at least 30 seconds before each subsequent attempt, with an overall
limit of no more than 50 consecutive failed authentication attempts (100 if PAD is
implemented). Once the overall limit is reached, the biometric system SHALL disablebiometric user authentication and offer another factor (e.g., a different biometric modality
or an activation secret if it is not already a required factor) if such an alternative method isalready available.
The verifier SHALL make a determination of sensor and endpoint performance, integrity,
and authenticity. Acceptable methods for making this determination include, but are notlimited to:1302• Authentication of the sensor or endpoint

1303• Certification by an approved accreditation authority

1304
1305

• Runtime interrogation of signed metadata (e.g., attestation) as described inSec. 5.2.4.

1308

Biometric comparison can be performed locally on the claimant’s device or at a central
verifier. Since the potential for attacks on a larger scale is greater at central verifiers,
comparison SHOULD be performed locally.

1309

If comparison is performed centrally:

1306
1307

1310
1311
1312
1313

1314
1315

• Use of the biometric as an authentication factor SHALL be limited to one ormore specific devices that are identified using approved cryptography. Since thebiometric has not yet unlocked the main authentication key, a separate key SHALL
be used for identifying the device.
• Biometric revocation, referred to as biometric template protection in[ISO/IEC24745], SHALL be implemented.

33

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management1319• An authenticated protected channel between sensor (or an endpoint containing asensor that resists sensor replacement) and verifier SHALL be established and thesensor or endpoint SHALL be authenticated prior to capturing the biometric sample
from the claimant.

1320• All transmission of biometrics SHALL be over an authenticated protected channel.

1316
1317
1318

1321
1322
1323
1324
1325

1326
1327

1328
1329
1330
1331

Biometric samples collected in the authentication process MAY be used to train
comparison algorithms or — with user consent — for other research purposes. Biometricsamples and any biometric data derived from the biometric sample such as a probe
produced through signal processing SHALL be zeroized immediately after any training or
research data has been derived.
Biometric authentication technologies SHALL provide similar performance forsubscribers of different demographic types (racial background, gender, ethnicity, etc.).
5.2.4. Attestation
An attestation is information conveyed to the verifier regarding a connected authenticatoror the endpoint involved in an authentication operation. Information conveyed byattestation MAY include, but is not limited to:1333• The provenance (e.g., manufacturer or supplier certification), health, and integrityof the authenticator and endpoint

1334• Security features of the authenticator

1335• Security and performance characteristics of biometric sensors

1336• Sensor modality

1332

1337
1338
1339

1340
1341

1342
1343
1344
1345
1346

1347
1348
1349

If this attestation is signed, it SHALL be signed using a digital signature that provides atleast the minimum security strength specified in the latest revision of [SP800-131A] (112
bits as of the date of this publication).
Attestation information MAY be used as part of a verifier’s risk-based authentication
decision.
5.2.5. Phishing (Veriﬁer Impersonation) Resistance
Phishing attacks, previously referred to in SP 800-63B as “verifier impersonation,” areattempts by fraudulent verifiers and RPs to fool an unwary claimant into presenting anauthenticator to an impostor. In some prior versions of SP 800-63, protocols resistant tophishing attacks were also referred to as “strongly MitM resistant.”
The term phishing is widely used to describe a variety of similar attacks. For the purposesof this document, phishing resistance is the ability of the authentication protocol to detectand prevent disclosure of authentication secrets and valid authenticator outputs to an
34

NIST SP 800-63B-4 ipd
December 2022

1350
1351
1352
1353

1354
1355
1356
1357

1358
1359
1360
1361
1362

1363
1364
1365

1366
1367
1368
1369

1370
1371
1372
1373
1374
1375
1376
1377
1378
1379

1380
1381
1382
1383

1384
1385
1386

Digital Identity Guidelines
Authentication and Lifecycle Management

impostor relying party without reliance on the vigilance of the subscriber. The meansby which the subscriber was directed to the impostor relying party are not relevant.
For example, regardless of whether the subscriber was directed there via search engine
optimization or prompted by email, it is considered to be a phishing attack.
Approved cryptographic algorithms SHALL be used to establish phishing resistance
where it is required. Keys used for this purpose SHALL provide at least the minimum
security strength specified in the latest revision of [SP800-131A] (112 bits as of the dateof this publication).
Authenticators that involve the manual entry of an authenticator output, such as out-ofband and OTP authenticators, SHALL NOT be considered phishing resistant because
the manual entry does not bind the authenticator output to the specific session being
authenticated. In an AitM attack, an impostor verifier could replay the OTP authenticator
output to the verifier and successfully authenticate.
While an individual authenticator may be phishing resistant, phishing resistance for agiven subscriber account is only achieved when all methods of authentication are phishingresistant.
Two methods of phishing resistance are recognized: channel binding and verifier namebinding. Channel binding is considered more secure than verifier name binding because
it is not vulnerable to mis-issuance or misappropriation of relying party certificates, buteither method satisfies the requirements for phishing resistance.
5.2.5.1. Channel Binding
An authentication protocol with channel binding SHALL establish an authenticatedprotected channel with the verifier. It SHALL then strongly and irreversibly bind achannel identifier that was negotiated in establishing the authenticated protected channel
to the authenticator output (e.g., by signing the two values together using a private
key controlled by the claimant for which the public key is known to the verifier). The
verifier SHALL validate the signature or other information used to prove phishingresistance. This prevents an impostor verifier, even one that has obtained a certificate
representing the actual verifier, from successfully relaying that authentication on adifferent authenticated protected channel.
An example of a phishing resistant authentication protocol that uses channel binding isclient-authenticated TLS, because the client signs the authenticator output along withearlier messages from the protocol that are unique to the particular TLS connection being
negotiated.
5.2.5.2. Veriﬁer Name Binding
An authentication protocol with authenticator name binding SHALL establish
an authenticated protected channel with the verifier. It SHALL then generate an
35

NIST SP 800-63B-4 ipd
December 2022

1387
1388
1389
1390
1391
1392
1393
1394

1395
1396
1397
1398
1399

Digital Identity Guidelines
Authentication and Lifecycle Management

authenticator output that is cryptographically bound to a verifier identifier that is
authenticated as part of the protocol. In the case of domain name system (DNS)
identifiers, the verifier identifier SHALL be either the authenticated hostname of theverifier or a parent domain that is at least one level below the public suffix [PSL]
associated with that hostname. The binding MAY be established by choosing an
associated authenticator secret, by deriving an authenticator secret using the verifier
identifier, by cryptographically signing the authenticator output with the verifier identifier,or similar cryptographically secure means.
5.2.6. Veriﬁer-CSP Communications
In situations where the verifier and CSP are separate entities (as shown by the dotted line
in [SP800-63] Figure 1), communications between the verifier and CSP SHALL occur
through a mutually authenticated secure channel (such as a client-authenticated TLS
connection) using approved cryptography.

1409

5.2.7. Veriﬁer Compromise ResistanceUse of some types of authenticators requires that the verifier store a copy of theauthenticator secret. For example, an OTP authenticator (described in Sec. 5.1.4) requiresthat the verifier independently generate the authenticator output for comparison against
the value sent by the claimant. Because of the potential for the verifier to be compromisedand stored secrets stolen, authentication protocols that do not require the verifier topersistently store secrets that could be used for authentication are considered stronger,
and are described herein as being verifier compromise resistant. Note that such verifiers
are not resistant to all attacks. A verifier could be compromised in a different way, such as
being manipulated into always accepting a particular authenticator output.

1410

Verifier compromise resistance can be achieved in different ways, for example:

1400
1401
1402
1403
1404
1405
1406
1407
1408

1411
1412
1413
1414

1415
1416
1417
1418

1419
1420
1421
1422
1423
1424

• Use a cryptographic authenticator that requires the verifier store a public key
corresponding to a private key held by the authenticator.
• Store the expected authenticator output in hashed form. This method can be usedwith some look-up secret authenticators (described in Sec. 5.1.2), for example.
To be considered verifier compromise resistant, public keys stored by the verifier SHALL
be associated with the use of approved cryptographic algorithms and SHALL provide atleast the minimum security strength specified in the latest revision of [SP800-131A] (112
bits as of the date of this publication).
Other verifier compromise resistant secrets SHALL use approved hash algorithms andthe underlying secrets SHALL have at least the minimum security strength specified in
the latest revision of [SP800-131A] (112 bits as of the date of this publication). Secrets(e.g., memorized secrets) having lower complexity SHALL NOT be considered verifiercompromise resistant when hashed because of the potential to defeat the hashing process
through dictionary lookup or exhaustive search.
36

NIST SP 800-63B-4 ipd
December 2022

1425
1426
1427
1428
1429
1430
1431
1432

1433
1434

1435
1436

1437
1438
1439
1440
1441
1442
1443
1444

1445
1446
1447
1448
1449

1450
1451
1452
1453

1454
1455
1456
1457

1458
1459
1460

Digital Identity Guidelines
Authentication and Lifecycle Management

5.2.8. Replay Resistance
An authentication process resists replay attacks if it is impractical to achieve a successfulauthentication by recording and replaying a previous authentication message. Replay
resistance is in addition to the replay-resistant nature of authenticated protected channel
protocols, since the output could be stolen prior to entry into the protected channel.
Protocols that use nonces or challenges to prove the “freshness” of the transaction areresistant to replay attacks since the verifier will easily detect when old protocol messages
are replayed since they will not contain the appropriate nonces or timeliness data.
Examples of replay-resistant authenticators are OTP devices, cryptographic authenticators,
and look-up secrets.
In contrast, memorized secrets are not considered replay resistant because theauthenticator output — the secret itself — is provided for each authentication.
5.2.9. Authentication Intent
An authentication process demonstrates intent if it requires the subject to explicitly
respond to each authentication or reauthentication request. The goal of authentication
intent is to make it more difficult for authenticators (e.g., multi-factor cryptographic
devices) to be used without the subject’s knowledge, such as by malware on the endpoint.
Authentication intent SHALL be established by the authenticator itself, although multifactor cryptographic devices MAY establish intent by reentry of the activation factor forthe authenticator.
Authentication intent MAY be established in a number of ways. Authentication processes
that require the subject’s intervention establish intent (e.g., a claimant entering anauthenticator output from an OTP device). Cryptographic devices that require user action
for each authentication or reauthentication operation also establish intent (e.g., pushing abutton or reinsertion).
Depending on the modality, presentation of a biometric characteristic may or may
not establish authentication intent. Behavioral biometrics similarly may or may notestablish authentication intent because they do not always require a specific action on
the claimant’s part.
5.2.10. Restricted Authenticators
As threats evolve, authenticators’ capability to resist attacks typically degrades.
Conversely, some authenticators’ performance may improve, for example, when changes
to their underlying standards increases their ability to resist particular attacks.
To account for these changes in authenticator performance, NIST places additional
restrictions on authenticator types or specific classes or instantiations of an authenticator
type.

37

NIST SP 800-63B-4 ipd
December 2022

1461
1462
1463
1464
1465
1466

1467
1468
1469
1470
1471

1472
1473

Digital Identity Guidelines
Authentication and Lifecycle Management

The use of a restricted authenticator requires that the implementing organization assess,understand, and accept the risks associated with that authenticator and acknowledge
that risk will likely increase over time. It is the responsibility of the organization todetermine the level of acceptable risk for their systems and associated data and to define
any methods for mitigating excessive risks. If at any time the organization determines thatthe risk to any party is unacceptable, then that authenticator SHALL NOT be used.
Further, the risk of an authentication error is typically borne by multiple parties, including
the implementing organization, organizations that rely on the authentication decision,and the subscriber. Because the subscriber may be exposed to additional risk when an
organization accepts a restricted authenticator and that the subscriber may have a limited
understanding of and ability to control that risk, the CSP SHALL :1. Offer subscribers at least one alternate authenticator that is not restricted and can beused to authenticate at the required AAL.

1475

2. Provide meaningful notice to subscribers regarding the security risks of therestricted authenticator and availability of alternatives that are not restricted.

1476

3. Address any additional risk to subscribers in its risk assessment.

1474

1477
1478
1479

1480
1481
1482
1483
1484
1485

1486
1487
1488
1489
1490
1491
1492
1493

1494
1495
1496
1497

4. Develop a migration plan for the possibility that the restricted authenticator is nolonger acceptable at some point in the future and include this migration plan in its
digital identity acceptance statement.
5.2.11. Activation Secrets
Memorized secrets that are used as an activation factor for a multi-factor authenticator
are referred to as activation secrets. An activation secret is used to decrypt a stored secretkey used for authentication or is compared against a locally held stored verifier to provide
access to the authentication key. In either of these cases, the activation secret SHALL
remain within the authenticator and its associated user endpoint.
Authenticators making use of activation secrets SHALL require the secrets to be atleast 6 characters in length. Activation secrets MAY be entirely numeric (i.e., a PIN).
If alphanumeric (rather than only numeric) values are permitted, all printing ASCII[RFC20] characters as well as the space character SHOULD be accepted. Unicode[ISO/ISC 10646] characters SHOULD be accepted as well in alphanumeric secrets. The
authenticator SHALL contain a blocklist (either specified by specific values or by analgorithm) of at least 10 commonly used activation values and SHALL prevent their use
as activation secrets.
The authenticator or verifier SHALL implement a retry-limiting mechanism that
effectively limits the number of consecutive failed activation attempts using theauthenticator to ten (10). If the entry of an incorrect activation secret causes theauthenticator to generate an invalid output that is sent to the central verifier, rate
38

NIST SP 800-63B-4 ipd
December 2022

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
1528
1529
1530
1531
1532
1533
1534

1535
1536

Digital Identity Guidelines
Authentication and Lifecycle Management

limiting MAY be implemented by the verifier. In all other cases, rate limiting SHALL
be implemented in the authenticator. Once the limit of 10 attempts is reached, theauthenticator SHALL be disabled and a different authenticator SHALL be required forauthentication.
If the authenticator verifies the activation secret locally (rather than using it for decryptionof a key), verification SHALL be performed within a hardware-based authenticator orin a secure element (e.g., TEE, TPM) that releases the authentication secret only uponpresentation of the correct activation secret. In other circumstances (i.e., software-based
multi-factor authenticators), the authenticator SHALL use the memorized secret as a key
to decrypt its stored authentication secret. Approved cryptography SHALL be used.
5.2.12. Connected Authenticators
Cryptographic authenticators require a direct connection between the authenticator andthe endpoint being authenticated. This connection MAY be wired (e.g., USB or directconnection with a smartcard) or wireless (e.g., NFC, Bluetooth). While in most cases
wired connections can be presumed to be secure from eavesdropping and adversaryin-the-middle attacks, additional precautions are required for authenticators that areconnected via wireless technologies.
Wired authenticator connections include both authenticators that are embedded in
endpoints (e.g., in a TPM) and those that are connected via an external interface, such as
USB. Claimants SHOULD be advised to use trusted hardware (cables, etc.) for external
connections for additional assurance that they have not been compromised.
Wireless authenticator connections are potentially vulnerable to threats including
eavesdropping, injection, and relay attacks. The potential for such attacks depends onthe effective range of the wireless technology being used.
Wireless technologies having an effective range of 1 meter or more (e.g., BluetoothLE) SHALL use an authenticated encrypted connection between the authenticatorand endpoint. A pairing process SHALL be used to establish a key for encrypted
communication between the authenticator and endpoint. A temporary wired connection
between the devices MAY also be used to establish the key in lieu of the pairing process.
The pairing process SHALL be authenticated through the use of a pairing code. The
pairing code SHALL be associated with either the authenticator or endpoint and SHALL
have at least 20 bits or 6 decimal digits of entropy. The pairing code MAY be printed on
the associated device and SHALL be conveyed between the devices by manual entry or
by using a QR code or similar representation that is optically communicated. An exampleof this is the pairing code used with the virtual contact interface specified in [SP800-73].
The entire authentication transaction SHALL be encrypted using a key established by thepairing process.
When a wireless technology with an effective range of less than 1 meter is in use (e.g.,
NFC), the activation secret, if any, transmitted from the endpoint to authenticator SHALL
39

NIST SP 800-63B-4 ipd
December 2022

1537
1538
1539
1540

1541
1542
1543
1544
1545
1546
1547

1548
1549
1550

1551
1552
1553
1554

Digital Identity Guidelines
Authentication and Lifecycle Management

be encrypted using a key established through a pairing process between the devices or
through a temporary wired connection. An authenticated connection using a pairing code
meeting the above requirements SHOULD be used. If the authenticator is configured torequire authenticated pairing, pairing code SHALL be used.
Note: Encryption of only the activation secret, and not the entire
authentication transaction, may expose sensitive information such as
the identity of the relying party, although this would require the attacker
to be very close to the subscriber. Special care should be taken withauthenticators containing personally identifiable information that do not
require authenticated pairing to protect that information against “skimming”
and eavesdropping attacks.
The key established as a result of the pairing process MAY be either temporary (valid
for a limited number of transactions or time) or persistent. A mechanism for endpoints toremove persistent keys SHALL be provided.
Where cryptographic operations are required, approved cryptography SHALL be used.
All communication of authentication data between authenticators and endpoints SHALL
occur directly between those devices or through an authenticated protected channel
between the authenticator and endpoint.

40

NIST SP 800-63B-4 ipd
December 2022

1555

6.

1556

This section is normative.

1557
1558
1559
1560

Digital Identity Guidelines
Authentication and Lifecycle Management

Authenticator Lifecycle Management

A number of events can occur over the lifecycle of a subscriber’s authenticator that
affect that authenticator’s use. These events include binding, loss, theft, unauthorized
duplication, expiration, and revocation. This section describes the actions to be taken in
response to those events.

1564

6.1. Authenticator Binding
Authenticator binding refers to the establishment of an association between a specificauthenticator and a subscriber account, enabling the authenticator to be used — possibly
in conjunction with other authenticators — to authenticate for that subscriber account.

1565

Authenticators SHALL be bound to subscriber accounts either

1561
1562
1563

1566

• by issuance by the CSP as part of enrollment or

1567• by registration of a subscriber-provided authenticator that is acceptable to the CSP.

1568
1569

1570
1571
1572
1573
1574
1575
1576

1577
1578
1579
1580
1581

1582
1583
1584
1585
1586
1587
1588
1589
1590

These guidelines refer to the binding rather than the issuance of an authenticator toaccommodate both options.
Throughout the digital identity lifecycle, CSPs SHALL maintain a record of allauthenticators that are or have been associated with each subscriber account. The CSP orverifier SHALL maintain the information required for throttling authentication attempts
when required, as described in Sec. 5.2.2. The CSP SHALL also verify the type ofuser-provided authenticator (e.g., single-factor cryptographic device vs. multi-factor
cryptographic device) so verifiers can determine compliance with requirements at each
AAL.
The record created by the CSP SHALL contain the date and time the authenticator wasbound to the subscriber account. The record SHOULD include information about thesource of the binding (e.g., IP address, device identifier) of any device associated with theenrollment. If available, the record SHOULD also contain information about the source of
unsuccessful authentications attempted with the authenticator.
When any new authenticator is bound to a subscriber account, the CSP SHALL ensurethat the binding protocol and the protocol for provisioning the associated keys are done
at a level of security commensurate with the AAL at which the authenticator will be used.
For example, protocols for key provisioning SHALL use authenticated protected channels
or be performed in person to protect against adversary-in-the-middle attacks. Binding ofmulti-factor authenticators SHALL require multi-factor authentication or equivalent (e.g.,association with the session in which identity proofing has been just completed) be usedin order to bind the authenticator. The same conditions apply when a key pair is generated
by the authenticator and the public key is sent to the CSP.
41

NIST SP 800-63B-4 ipd
December 2022

1591
1592
1593
1594

1595
1596
1597

1598
1599
1600
1601
1602
1603
1604

Digital Identity Guidelines
Authentication and Lifecycle Management

As part of the binding process, the CSP MAY require additional information about
the new authenticator or the endpoint it is associated with to determine that they aresuitable for the AAL being requested and to attempt to determine that the endpoint andauthenticator are free from malware.
6.1.1. Binding at Enrollment
The following requirements apply when an authenticator is bound to a subscriber accountas part of the enrollment process.
The CSP SHALL bind at least one — and SHOULD bind at least two — physical(something you have) authenticators to the subscriber account, in addition to amemorized secret or one or more biometric characteristics. Binding of multiple
authenticators provides a means to recover from the loss or theft of the subscriber’s
primary authenticator. Preservation of online material or an online reputation makes it
undesirable to lose control of a subscriber account due to the loss of an authenticator. The
second authenticator makes it possible to securely recover from an authenticator loss.

1608

If enrollment and binding cannot be completed in a single physical encounter orelectronic transaction (i.e., within a single protected session), the following methods
SHALL be used to ensure that the same party acts as the applicant throughout theprocesses:

1609

For remote transactions:

1605
1606
1607

1610
1611
1612
1613

1614
1615

1616

1. The applicant SHALL identify themselves in each new binding transaction
by presenting a temporary secret which was either established during a priortransaction, or sent to the applicant’s phone number, email address, or postal
address of record.
2. Long-term authenticator secrets SHALL only be issued to the applicant within aprotected session.
For in-person transactions:1619

1. The applicant SHALL identify themselves in person by either using a secret as
described in remote transaction (1) above, or through use of a biometric that wasrecorded during a prior encounter.

1620

2. Temporary secrets SHALL NOT be reused.

1617
1618

1621
1622
1623

3. If the CSP issues long-term authenticator secrets during a physical transaction, thenthey SHALL be loaded locally onto a physical device that is issued in person to theapplicant or delivered in a manner that confirms the address of record.

42

NIST SP 800-63B-4 ipd
December 2022

1624
1625
1626
1627
1628
1629
1630
1631
1632

1633
1634
1635
1636
1637
1638
1639
1640
1641
1642

1643
1644
1645
1646

1647
1648
1649
1650

1651
1652
1653

1654
1655
1656
1657
1658
1659
1660

Digital Identity Guidelines
Authentication and Lifecycle Management

6.1.2. Post-Enrollment Binding
6.1.2.1. Binding of an Additional Authenticator at Existing AAL
With the exception of memorized secrets, CSPs and verifiers SHOULD encourage
subscribers to maintain at least two valid authenticators of each factor that they will
be using. For example, a subscriber who usually uses an OTP device as a physicalauthenticator MAY also be issued a number of look-up secret authenticators, or registera device for out-of-band authentication, in case the physical authenticator is lost, stolen,
or damaged. See Sec. 6.1.2.3 for more information on replacement of memorized secretauthenticators.
Accordingly, CSPs SHOULD permit the binding of additional authenticators to a
subscriber account. Before adding the new authenticator, the CSP SHALL firstrequire the subscriber to authenticate at the AAL (or a higher AAL) at which the newauthenticator will be used. A separate authentication using existing authenticators
SHALL be performed following the request to bind a new authenticator, and SHALL
be valid for 20 minutes. When an authenticator is added, the CSP SHOULD send a
notification to the subscriber via a mechanism that is independent of the transaction
binding the new authenticator (e.g., email to an address previously associated with thesubscriber). The CSP MAY limit the number of authenticators that are bound in thismanner.
6.1.2.2. Adding an Additional Factor to a Single-Factor Subscriber AccountIf the subscriber account has only one authentication factor bound to it and an additional
authenticator of a different authentication factor is to be added, the subscriber MAY
request that the subscriber account be upgraded to AAL2.
Before binding the new authenticator, the CSP SHALL require the subscriber toauthenticate at AAL1. The CSP SHOULD send a notification of the event to thesubscriber via a mechanism independent of the transaction binding the new authenticator(e.g., email to an address previously associated with the subscriber).
6.1.2.3. Account Recovery
The situation where a subscriber loses control of authenticators necessary to successfullyauthenticate is commonly referred to as account recovery.
If a subscriber that has been identity proofed loses all authenticators necessary tocomplete authentication, that subscriber SHALL repeat the identity proofing processdescribed in [SP800-63A]. If the CSP has retained information from the evidence used in
the original identity proofing process (pursuant to a privacy risk assessment as describedin [SP800-63A] Sec. 5.2.2) that is sufficient to perform verification of the subscriber andif that evidence is still valid, it MAY repeat only the verification portion of the identity
proofing process as described in [SP800-63A].

43

NIST SP 800-63B-4 ipd
December 2022

1661
1662
1663
1664
1665
1666

1667
1668

1669
1670
1671
1672

1673
1674
1675
1676
1677

1678
1679
1680
1681
1682
1683

1684
1685

Digital Identity Guidelines
Authentication and Lifecycle Management

The CSP SHALL require the claimant to authenticate using an authenticator of
the remaining factor, if any, to confirm binding to the existing subscriber account.
Reestablishment of authentication factors at IAL3 SHALL be done in person or through asupervised remote process as described in [SP800-63A] Sec. 5.6.8, and SHALL performa successful biometric comparison against the biometric characteristic collected during
the original identity proofing process.
The CSP SHOULD send a notification of the event to the subscriber. This MAY be thesame notice that is required as part of the identity proofing process.
Subscriber accounts that have not been identity proofed (i.e., without IAL) cannot berecovered because there is no reliable means for reassociating the subscriber with that
account. Such accounts SHALL be treated as abandoned and a new subscriber account
SHALL be established.
Replacement of a lost (i.e., forgotten) memorized secret is problematic because it is very
common. Additional “backup” memorized secrets do not mitigate this because they are
just as likely to also have been forgotten. If a biometric is bound to the subscriber account,the biometric characteristic and associated physical authenticator SHOULD be used toestablish a new memorized secret.
As an alternative to the above re-proofing process when there is no biometric bound to
the subscriber account, the CSP MAY bind a new memorized secret with authentication
using two physical authenticators, along with a confirmation code that has been sent to
one of the subscriber’s addresses of record. The confirmation code SHALL consist of atleast 6 random alphanumeric characters generated by an approved random bit generator[SP800-90Ar1]. Confirmation codes SHALL be valid for at most:• 21 days, when sent to a postal address of record within the contiguous UnitedStates;1687• 30 days, when sent to a postal address of record outside the contiguous UnitedStates;1688• 10 minutes, when sent to a telephone of record (SMS or voice); or

1689• 24 hours, when sent to an email address of record.

1686

1690
1691
1692
1693
1694
1695

1696
1697

6.1.2.4. External Authenticator Binding
External authenticator binding refers to the process of binding an authenticator toa subscriber account when it is not connected to (or embedded in) the authenticatedendpoint. This process is typically used when adding authenticators that are embedded ina new endpoint, or when connectivity limitations prevent the newly bound authenticatorfrom being connected to an authenticated endpoint.
The binding process MAY begin with a request from an endpoint that has authenticated to
the CSP obtaining a binding code from the CSP that is input into the endpoint associated44

NIST SP 800-63B-4 ipd
December 2022

1698
1699
1700

1701
1702
1703

1704
1705

1706
1707

1708
1709
1710
1711
1712

1713
1714
1715
1716

1717
1718

1719
1720
1721
1722

1723
1724
1725
1726
1727

1728
1729
1730
1731
1732
1733
1734

Digital Identity Guidelines
Authentication and Lifecycle Managementwith the new authenticator and sent to that CSP. Alternatively, the endpoint associatedwith the new authenticator MAY obtain a binding code from the CSP, which is input to anauthenticated endpoint and sent to the CSP.
In addition to the requirements given in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above
as applicable, the following requirements SHALL apply when binding an external
authenticator:• An authenticated protected session SHALL be established by the endpoint
associated with the new authenticator and the CSP.
• The subscriber MAY be prompted to enter an identifier by which they are known
by the CSP on the endpoint associated with the new authenticator.
• The CSP SHALL generate a binding code using an approved random number
generator and send it to either the new authenticator endpoint or the authenticatedendpoint approving the binding. The binding code SHALL have at least 40 bitsof entropy if used in conjunction with an identifier entered on the previous step;otherwise a binding code with at least 112 bits of entropy SHALL be required.
• The subscriber SHALL transfer the binding code to the other endpoint. Thistransfer SHALL be either manual or via a local out-of-band method such as a QR
code. The binding code SHALL NOT be communicated over any insecure channelsuch as email or PSTN (SMS or voice).
• The binding code SHALL be usable only once and SHALL be valid for a
maximum of 10 minutes.
• Following the binding of the new authenticator (or issuance of a certificate, in thecase of PKI-based authenticators), the CSP SHOULD encourage the subscriber toauthenticate with the new authenticator to confirm that the process has completed
successfully.
• The CSP SHALL provide clear instruction on what the subscriber should do in theevent of an authenticator binding mishap, such as a button or contact address toallow a mis-bound authenticator to be quickly invalidated as appropriate. This
MAY be provided in the authenticated session or in the binding notification
described in Sec. 6.1.2.1, Sec. 6.1.2.2, and Sec. 6.1.2.3 above.
Binding an external authenticator is a potentially risky operation because of the potential
for the subscriber to be tricked into using a binding code by an attacker or supplying abinding code to an attacker. In some cases, QR codes obtained from a trusted source (suchas from an authenticated session, especially when that authentication is phishing resistant)are considered to be more robust against such attacks, because they typically contain the
URL of the CSP as well as the binding code. There is less potential for the subscriber tobe fooled into entering a binding code at a phishing site as a result.

45

NIST SP 800-63B-4 ipd
December 2022

1735
1736
1737
1738
1739

1740
1741
1742
1743
1744
1745
1746
1747

1748
1749
1750
1751
1752
1753
1754

1755
1756
1757
1758
1759
1760
1761
1762

1763
1764
1765

1766
1767
1768
1769
1770
1771
1772

Digital Identity Guidelines
Authentication and Lifecycle Management

6.1.3. Binding to a Subscriber-provided Authenticator
A subscriber may already possess authenticators suitable for authentication at a particular
AAL. For example, they may have a two-factor authenticator from a social network
provider, considered AAL2 and IAL1, and would like to use those credentials at an RPthat requires IAL2.
CSPs SHOULD , where practical, accommodate the use of subscriber-provided
authenticators in order to relieve the burden to the subscriber of managing a large
number of authenticators. Binding of these authenticators SHALL be done as describedin Sec. 6.1.2. In situations where the authenticator strength is not self-evident (e.g.,
between single-factor and multi-factor authenticators of a given type), the CSP SHALL
assume the use of the weaker authenticator unless it is able to establish that the stronger
authenticator is in fact being used (e.g., by verification with the issuer or manufacturer of
the authenticator).
6.1.4. Renewal
The subscriber SHOULD bind a new or updated authenticator an appropriate amount oftime before an existing authenticator’s expiration. The process for this SHOULD conform
closely to the binding process for an additional authenticator described in Sec. 6.1.2.1.
The CSP MAY periodically take other actions, such as reconfirming address of record,either as a part of the renewal process or separately. Following successful use of thereplacement authenticator, the CSP MAY invalidate the authenticator that is expiring.
6.2. Loss, Theft, Damage, and Unauthorized Duplication
Compromised authenticators include those that have been lost, stolen, or subject
to unauthorized duplication. Generally, one must assume that a lost authenticator
has been stolen or compromised by someone that is not the legitimate subscriber of
the authenticator. Damaged or malfunctioning authenticators are also considered
compromised to guard against any possibility of extraction of the authenticator secret.
One notable exception is a memorized secret that has been forgotten without otherindications of having been compromised, such as having been obtained by an attacker.
Suspension, revocation, or destruction of compromised authenticators SHOULD occur aspromptly as practical following detection. Organizations SHOULD establish time limits
for this process.
To facilitate secure reporting of the loss, theft, or damage to an authenticator, the
CSP SHOULD provide the subscriber with a method of authenticating to the CSP
using a backup or alternate authenticator. This backup authenticator SHALL be eithera memorized secret or a physical authenticator. Either could be used, but only one
authentication factor is required to make this report. Alternatively, the subscriber MAY
establish an authenticated protected channel to the CSP and verify information collectedduring the proofing process. The CSP MAY choose to verify an address of record (i.e.,
46

NIST SP 800-63B-4 ipd
December 2022

1773
1774
1775
1776
1777

1778
1779
1780
1781
1782

1783
1784
1785

1786
1787
1788

1789
1790
1791
1792

Digital Identity Guidelines
Authentication and Lifecycle Management

email, telephone, postal) and suspend authenticators reported to have been compromised.
The suspension SHALL be reversible if the subscriber successfully authenticates to the
CSP using a valid (i.e., not suspended) authenticator and requests reactivation of anauthenticator suspended in this manner. The CSP MAY set a time limit after which asuspended authenticator can no longer be reactivated.
6.3. Expiration
CSPs MAY issue authenticators that expire. If and when an authenticator expires, it
SHALL NOT be usable for authentication. When an authentication is attempted using
an expired authenticator, the CSP SHOULD give an indication to the subscriber that theauthentication failure is due to expiration rather than some other cause.
The CSP SHALL require subscribers to surrender or prove destruction of any physicalauthenticator containing attribute certificates signed by the CSP as soon as practical after
expiration or receipt of a renewed authenticator.
6.4. Invalidation
Invalidation of an authenticator (sometimes referred to as revocation or termination) refers
to removal of the binding between an authenticator and a subscriber account.
CSPs SHALL invalidate authenticators promptly when a subscriber account ceases toexist (e.g., subscriber’s death, discovery of a fraudulent subscriber), when requestedby the subscriber, or when the CSP determines that the subscriber no longer meets its
eligibility requirements.

1797

The CSP SHALL require subscribers to surrender or certify destruction of any physicalauthenticator containing subscriber attributes, such as certificates signed by the CSP, assoon as practical after invalidation takes place. This is necessary to protect the privacyof the subscriber and to block the use of any certificates in offline situations between
invalidation and expiration of the certificates.

1798

Further requirements on the invalidation of PIV authenticators are found in [FIPS201].

1793
1794
1795
1796

47

NIST SP 800-63B-4 ipd
December 2022

1799

7.

1800

This section is normative.

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

Digital Identity Guidelines
Authentication and Lifecycle Management

Session Management

Once an authentication event has taken place, it is often desirable to allow the subscriber
to continue using the application across multiple subsequent interactions without
requiring them to repeat the authentication event. This requirement is particularly true
for federation scenarios — described in [SP800-63C] — where the authentication event
necessarily involves several components and parties coordinating across a network.
To facilitate this behavior, a session MAY be started in response to an authentication
event, and continue the session until such time that it is terminated. The session MAY be
terminated for any number of reasons, including but not limited to an inactivity timeout,
an explicit logout event, or other means. The session MAY be continued through areauthentication event — described in Sec. 7.2 — wherein the subscriber repeats some or
all of the initial authentication event, thereby re-establishing the session.
Session management is preferable over continual presentation of credentials as the poor
usability of continual presentation often creates incentives for workarounds such as
caching of activation factors, negating authentication intent and obscuring the freshness of
the authentication event.
7.1. Session Bindings
A session occurs between the software that a subscriber is running — such as a browser,
application, or operating system (i.e., the session subject) — and the RP or CSP thatthe subscriber is accessing (i.e., the session host). A session secret SHALL be shared
between the subscriber’s software and the service being accessed. This secret binds thetwo ends of the session, allowing the subscriber to continue using the service over time.
The secret SHALL be presented directly by the subscriber’s software or possession of thesecret SHALL be proven using a cryptographic mechanism.
Continuity of authenticated sessions SHALL be based upon the possession of a session
secret issued by the verifier at the time of authentication and optionally refreshed during
the session. The nature of a session depends on the application, such as:1827• a web browser session with a “session” cookie, or1828• an instance of a mobile application that retains a session secret.

1829
1830

1831
1832
1833

Session secrets SHALL NOT be persistent (retained across a restart of the associatedapplication or a reboot of the host device).
The secret used for session binding SHALL be generated by the session host in direct
response to an authentication event. A session SHOULD inherit the AAL properties of
the authentication event which triggered its creation. A session MAY be considered at a

48

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

1835

lower AAL than the authentication event but SHALL NOT be considered at a higher AAL
than the authentication event.

1836

Secrets used for session binding SHALL meet all of the following requirements:

1834

1837
1838

1839
1840

1841
1842

1843
1844

1845
1846

1847
1848

1849
1850
1851
1852

1853
1854

1855
1856

1857
1858
1859
1860

1. Secrets are generated by the session host during an interaction, typically
immediately following authentication.
2. Secrets are generated by an approved random bit generator [SP800-90Ar1] andcontain at least 64 bits of entropy.
3. Secrets are erased or invalidated by the session subject when the subscriber logsout.
4. Secrets are sent to and received from the device using an authenticated protectedchannel.
5. Secrets will time out and are not accepted after the times specified in Sections 4.1.3,
4.2.3, and 4.3.3, as appropriate for the AAL.
6. Secrets are not made available to insecure communications between the host andsubscriber’s endpoint.
In addition, secrets used for session binding SHOULD be erased on the subscriber
endpoint when they log out or when the secret is deemed to have expired. TheySHOULD NOT be placed in insecure locations such as HTML5 Local Storage due tothe potential exposure of local storage to cross-site scripting (XSS) attacks.
Authenticated sessions SHALL NOT fall back to an insecure transport, such as from httpsto http, following authentication.
URLs or POST content SHALL contain a session identifier that SHALL be verified by
the RP to protect against cross-site request forgery.
There are several mechanisms for managing a session over time. The following sections
give different examples along with additional requirements and considerations particular
to each example technology. Additional informative guidance is available in the OWASP
Session Management Cheat Sheet [OWASP-session].

1864

7.1.1. Browser Cookies
Browser cookies are the predominant mechanism by which a session will be created andtracked for a subscriber accessing a service. Cookies are not authenticators, but they aresuitable as short-term secrets (for the duration of a session).

1865

Cookies used for session maintenance SHALL meet all of the following requirements:

1861
1862
1863

1866

1. Cookies are tagged to be accessible only on secure (HTTPS) sessions.

1867

2. Cookies are accessible to the minimum practical set of hostnames and paths.
49

NIST SP 800-63B-4 ipd
December 2022

1868
1869
1870
1871
1872
1873

1874
1875
1876
1877
1878
1879
1880

1881
1882
1883
1884

1885
1886
1887
1888

1889
1890
1891
1892

1893
1894

Digital Identity Guidelines
Authentication and Lifecycle Management

In addition, session maintenance cookies SHOULD be tagged to be inaccessible via
JavaScript (HttpOnly). They SHOULD contain only an opaque string (such as a session
identifier), and SHOULD NOT contain cleartext PII. They SHOULD be tagged to expire
at, or soon after, the session’s validity period. This latter requirement is intended to limit
the accumulation of cookies, but SHALL NOT be depended upon to enforce session
timeouts.
7.1.2. Access Tokens
An access token — such as found in OAuth — is used to allow an application to access a
set of services on a subscriber’s behalf following an authentication event. The presenceof an OAuth access token SHALL NOT be interpreted by the RP as presence of thesubscriber, in the absence of other signals. The OAuth access token, and any associatedrefresh tokens, MAY be valid long after the authentication session has ended and thesubscriber has left the application.
7.1.3. Device Identiﬁcation
Other methods of secure device identification — including but not limited to mutual
TLS, token binding, or other mechanisms — MAY be used to enact a session between asubscriber and a service.
7.2. Reauthentication
Periodic reauthentication of sessions SHALL be performed to confirm the continued
presence of the subscriber at an authenticated session (i.e., that the subscriber has notwalked away without logging out).
A session SHALL NOT be extended past the guidelines in Sections 4.1.3, 4.2.3, and4.3.3 (depending on AAL) based on presentation of the session secret alone. Prior tosession expiration, the reauthentication time limit SHALL be extended by prompting thesubscriber for the authentication factors specified in Table 2.
When a session has been terminated, due to a time-out or other action, the subscriber
SHALL be required to establish a new session by authenticating again.
Table 2. AAL Reauthentication Requirements

AAL
1
2
3
1895
1896
1897

Requirement
Presentation of any one factor
Presentation of a memorized secret or biometricPresentation of all factors

Note: At AAL2, a memorized secret or biometric, and not a physicalauthenticator, is required because the session secret is something you have,and an additional authentication factor is required to continue the session.
50

NIST SP 800-63B-4 ipd
December 2022

1898
1899
1900
1901
1902
1903
1904
1905
1906
1907

1908
1909
1910
1911
1912
1913
1914

Digital Identity Guidelines
Authentication and Lifecycle Management

7.2.1. Reauthentication from a Federation or Assertion
When using a federation protocol and Identity Provider (IdP) to authenticate at the RP
as described in [SP800-63C], special considerations apply to session management andreauthentication. The federation protocol communicates an authentication event at the IdP
to the RP using an assertion, and the RP then begins an authenticated session based on the
successful validation of this assertion. Since the IdP and RP manage sessions separatelyfrom each other and the federation protocol does not connect the session management
between the IdP and RP, the termination of the subscriber’s sessions at an IdP and at an
RP are independent of each other. Likewise, the subscriber’s sessions at multiple different
RPs are established and terminated independently of each other.
Consequently, when an RP session expires and the RP requires reauthentication, it isentirely possible that the session at the IdP has not expired and that a new assertion could
be generated from this session at the IdP without explicitly reauthenticating the subscriber.
The IdP can communicate the time and details of the authentication event to the RP, but
it is up to the RP to determine if reauthentication requirements have been met. Section
5.3 of [SP800-63C] provides additional details and requirements for session management
within a federation context.

51

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

1915

8.

1916

This section is informative.

1917
1918
1919
1920

1921
1922
1923
1924
1925
1926
1927
1928

1929
1930
1931
1932
1933

1934
1935

Threats and Security Considerations

8.1. Authenticator Threats
An attacker who can gain control of an authenticator will often be able to masquerade as
the authenticator’s owner. Threats to authenticators can be categorized based on attacks
on the types of authentication factors that comprise the authenticator:• Something you know may be disclosed to an attacker. The attacker might guessa memorized secret. Where the authenticator is a shared secret, the attacker
could gain access to the CSP or verifier and obtain the secret value or perform a
dictionary attack on a hash of that value. An attacker may observe the entry ofa PIN or passcode, find a written record or journal entry of a PIN or passcode,or may install malicious software (e.g., a keyboard logger) to capture the secret.
Additionally, an attacker may determine the secret through offline attacks on apassword database maintained by the verifier.
• Something you have may be lost, damaged, stolen from the owner, or cloned by anattacker. For example, an attacker who gains access to the owner’s computer might
copy a software authenticator. A hardware authenticator might be stolen, tampered
with, or duplicated. Out-of-band secrets may be intercepted by an attacker and used
to authenticate their own session.
• Something you are may be replicated. For example, an attacker may obtain a copyof the subscriber’s fingerprint and construct a replica.

1939

This document assumes that the subscriber is not colluding with an attacker who isattempting to falsely authenticate to the verifier. With this assumption in mind, the threats
to the authenticators used for digital authentication are listed in Table 3, along with someexamples.

1940

Table 3. Authenticator Threats

1936
1937
1938

AuthenticatorThreat/Attack
Assertion
Manufactureor Modification

Description

ExamplesThe attacker generates a false
assertion

Compromised CSP asserts
identity of a claimant who has
not properly authenticatedCompromised proxythat changes AAL of anauthentication assertion
A hardware cryptographic
device is stolen.
An OTP device is stolen.

The attacker modifies anexisting assertion
Theft

A physical authenticator isstolen by an Attacker.

52

NIST SP 800-63B-4 ipd
December 2022

Duplication

Eavesdropping

OfflineCracking

Side Channel
AttackDigital Identity Guidelines
Authentication and Lifecycle Management

The subscriber’s authenticator
has been copied with orwithout their knowledge.

A look-up secret authenticatoris stolen.
A cell phone is stolen.
Passwords written on paper are
disclosed.

Passwords stored in anelectronic file are copied.
Software PKI authenticator(private key) copied.
Look-up secret authenticator
copied.
Counterfeit biometricauthenticator manufactured.
The authenticator secret or
Memorized secrets areauthenticator output is revealed obtained by watching keyboard
to the attacker as the subscriber entry.
is authenticating.
Memorized secrets orauthenticator outputs areintercepted by keystroke
logging software.
A PIN is captured from a PIN
pad device.
A hashed password is obtained
and used by an attacker for
another authentication (passthe-hash attack).
An out-of-band secret is
An out-of-band secret isintercepted by the attacker
transmitted via unencryptedby compromising the
Wi-Fi and received by thecommunication channel.
attacker.
The authenticator is exposed
A software PKI authenticatorusing analytical methods
is subjected to dictionary
outside the authentication
attack to identify the correct
password to use to decrypt themechanism.
private key.
The authenticator secret
A key is extracted by
is exposed using physicaldifferential power analysis
characteristics of theon a hardware cryptographic
authenticator.
authenticator.
53

NIST SP 800-63B-4 ipd
December 2022

Phishing or
Pharming

SocialEngineering

Online Guessing

Digital Identity Guidelines
Authentication and Lifecycle Management

The authenticator output
is captured by fooling thesubscriber into thinking theattacker is a verifier or RP.

The attacker establishes alevel of trust with a subscriber
in order to convince thesubscriber to reveal theirauthenticator secret or
authenticator output.

The attacker connects to theverifier online and attempts
to guess a valid authenticator
output in the context of thatverifier.

54

A cryptographic authenticator
secret is extracted by analysisof the response time of theauthenticator over a number ofattempts.
A password is revealed
by subscriber to a website
impersonating the verifier.
A memorized secret is revealed
by a bank subscriber in
response to an email inquiry
from a phisher pretending torepresent the bank.
A memorized secret is revealedby the subscriber at a bogus
verifier website reachedthrough DNS spoofing.
A memorized secret isrevealed by the subscriber
to an officemate asking forthe password on behalf of thesubscriber’s boss.
A memorized secret is revealed
by a subscriber in a telephoneinquiry from an attacker
masquerading as a systemadministrator.
An out of band secret sent
via SMS is received by anattacker who has convinced
the mobile operator to redirect
the victim’s mobile phone tothe attacker.
Online dictionary attacks areused to guess memorized
secrets.

NIST SP 800-63B-4 ipd
December 2022

Endpoint
Compromise

Unauthorized
Binding

Digital Identity Guidelines
Authentication and Lifecycle Management

Malicious code on the endpointproxies remote access toa connected authenticator
without the subscriber’s
consent.
Malicious code on the endpointcauses authentication to otherthan the intended verifier.

Malicious code on the endpoint
compromises a multi-factor
software cryptographic
authenticator.
An attacker is able to cause
an authenticator under theircontrol to be bound to a
subscriber account.

Online guessing is used toguess authenticator outputs for
an OTP device registered to alegitimate claimant.
A cryptographic authenticatorconnected to the endpoint isused to authenticate remoteattackers.
Authentication is performedon behalf of an attacker rather
than the subscriber.
A malicious app on theendpoint reads an out-of-bandsecret sent via SMS and theattacker uses the secret toauthenticate.
Malicious code proxies
authentication or exports
authenticator keys from theendpoint.
An attacker intercepts anauthenticator or provisioning
key en route to the subscriber.

1943

8.2. Threat Mitigation Strategies
Related mechanisms that assist in mitigating the threats identified above are summarizedin Table 4.

1944

Table 4. Mitigating Authenticator Threats

1941
1942

AuthenticatorThreat/Attack
Theft

Threat Mitigation
Mechanisms
Use multi-factor authenticatorsthat need to be activatedthrough a memorized secretor biometric.
Use a combination ofauthenticators that includes amemorized secret or biometric.
55

Normative References
4.2.1, 4.3.1

4.2.1, 4.3.1

NIST SP 800-63B-4 ipd
December 2022

Duplication

Eavesdropping

OfflineCracking

Side Channel
AttackPhishing or
Pharming

Digital Identity Guidelines
Authentication and Lifecycle Management

Use authenticators fromwhich it is difficult to extractand duplicate long-term
authentication secrets.
Ensure the security of theendpoint, especially withrespect to freedom frommalware such as key loggers,
prior to use.
Avoid use of unauthenticatedand unencrypted
communication channels tosend out-of-band authenticator
secrets.
Authenticate overauthenticated protectedchannels (e.g., observe lockicon in browser window).
Use authentication protocols
that are resistant to replay
attacks such as pass-the-hash.
Use authentication endpoints
that employ trusted input andtrusted display capabilities.
Use an authenticator with ahigh entropy authenticator
secret.
Store centrally verified
memorized secrets in a salted,
hashed form, including a keyedhash.
Use authenticator algorithms
that are designed to maintain
constant power consumption
and timing regardless of secretvalues.
Use authenticators that provide
phishing resistance.

56

4.2.2, 4.3.2, 5.1.7.1

4.2.2

5.1.3.1

4.1.2, 4.2.2, 4.3.2

5.2.8

5.1.6.1, 5.1.8.1

5.1.2.1, 5.1.4.1, 5.1.5.1, 5.1.7.1,
5.1.9.1
5.1.1.1.2, 5.2.7

4.3.2

5.2.5

NIST SP 800-63B-4 ipd
December 2022

SocialEngineering

Online Guessing

Endpoint
Compromise

Unauthorized
Binding

1945

1946
1947
1948

1949
1950
1951

1952
1953

1954
1955

1956
1957
1958
1959

1960
1961

Digital Identity Guidelines
Authentication and Lifecycle Management

Avoid use of authenticatorsthat present a risk of social
engineering of third parties
such as customer service
agents.
Use authenticators thatgenerate high entropy output.
Use an authenticator that locks
up after a number of repeatedfailed activation attempts.
Use hardware authenticatorsthat require physical action by
the subscriber.
Maintain software-based keys
in restricted-access storage.
Use AitM-resistant
protocols for provisioning ofauthenticators and associatedkeys.

6.1.2.1, 6.1.2.3

5.1.2.1, 5.1.7.1, 5.1.9.1
5.2.2

5.2.9

5.1.3.1, 5.1.6.1, 5.1.8.1
6.1

Several other strategies may be applied to mitigate the threats described in Table 3:• Multiple factors make successful attacks more difficult to accomplish. If an attacker
needs to both steal a cryptographic authenticator and guess a memorized secret,then the work to discover both factors may be too high.
• Physical security mechanisms may be employed to protect a stolen authenticatorfrom duplication. Physical security mechanisms can provide tamper evidence,
detection, and response.
• Requiring the use of long memorized secrets that don’t appear in common
dictionaries may force attackers to try every possible value.
• System and network security controls may be employed to prevent an attacker fromgaining access to a system or installing malicious software.
• Periodic training may be performed to ensure subscribers understand whenand how to report compromise — or suspicion of compromise — or otherwise
recognize patterns of behavior that may signify an attacker attempting tocompromise the authentication process.
• Out of band techniques may be employed to verify proof of possession of registereddevices (e.g., cell phones).

57

NIST SP 800-63B-4 ipd
December 2022

1962
1963
1964
1965
1966
1967
1968

1969
1970
1971
1972

1973
1974
1975
1976
1977
1978
1979
1980

1981
1982
1983
1984

Digital Identity Guidelines
Authentication and Lifecycle Management

8.3. Authenticator Recovery
The weak point in many authentication mechanisms is the process followed when asubscriber loses control of one or more authenticators and needs to replace them. In manycases, the options remaining available to authenticate the subscriber are limited, andeconomic concerns (e.g., cost of maintaining call centers) motivate the use of inexpensive,and often less secure, backup authentication methods. To the extent that authenticator
recovery is human-assisted, there is also the risk of social engineering attacks.
To maintain the integrity of the authentication factors, it is essential that it not be possible
to leverage an authentication involving one factor to obtain an authenticator of a different
factor. For example, a memorized secret must not be usable to obtain a new list of look-up
secrets.
8.4. Session Attacks
The above discussion focuses on threats to the authentication event itself, but hijacking
attacks on the session following an authentication event can have similar security impacts.
The session management guidelines in Sec. 7 are essential to maintain session integrity
against attacks, such as XSS. In addition, it is important to sanitize all information to be
displayed [OWASP-XSS-prevention] to ensure that it does not contain executable content.
These guidelines also recommend that session secrets be made inaccessible to mobile
code in order to provide extra protection against exfiltration of session secrets.
Another post-authentication threat, cross-site request forgery (CSRF), takes advantage ofusers’ tendency to have multiple sessions active at the same time. It is important to embedand verify a session identifier into web requests to prevent the ability for a valid URL orrequest to be unintentionally or maliciously activated.

58

NIST SP 800-63B-4 ipd
December 2022

1985

1986
1987

1988
1989
1990

9.

Digital Identity Guidelines
Authentication and Lifecycle Management

Privacy Considerations

These privacy considerations supplement the guidance in Sec. 4. This section is
informative.
9.1. Privacy Risk Assessment
Sections 4.1.5, 4.2.5, and 4.3.5 require the CSP to conduct a privacy risk assessment forrecords retention. Such a privacy risk assessment would include:

1992

1. The likelihood that the records retention could create a problem for the subscriber,such as invasiveness or unauthorized access to the information.

1993

2. The impact if such a problem did occur.

1991

1994
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

CSPs should be able to reasonably justify any response they take to identified privacy
risks, including accepting the risk, mitigating the risk, and sharing the risk. The use ofsubscriber consent is a form of sharing the risk, and therefore appropriate for use only
when a subscriber could reasonably be expected to have the capacity to assess and accept
the shared risk.
9.2. Privacy Controls
Section 4.4 requires CSPs to employ appropriately tailored privacy controls. [SP800-53]
provides a set of privacy controls for CSPs to consider when deploying authentication
mechanisms. These controls cover notices, redress, and other important considerations for
successful and trustworthy deployments.
9.3. Use Limitation
Section 4.4 requires CSPs to use measures to maintain the objectives of predictability(enabling reliable assumptions by individuals, owners, and operators about PII and its
processing by an information system) and manageability (providing the capability for
granular administration of PII, including alteration, deletion, and selective disclosure)commensurate with privacy risks that can arise from the processing of attributes forpurposes other than identity proofing, authentication, authorization, or attribute assertion,
related fraud mitigation, or to comply with law or legal process [NISTIR8062].
CSPs may have various business purposes for processing attributes, including providing
non-identity services to subscribers. However, processing attributes for other purposes
than those specified at collection can create privacy risks when individuals are notexpecting or comfortable with the additional processing. CSPs can determine appropriate
measures commensurate with the privacy risk arising from the additional processing.
For example, absent applicable law, regulation or policy, it may not be necessary to
get consent when processing attributes to provide non-identity services requested bysubscribers, although notices may help subscribers maintain reliable assumptions about

59

NIST SP 800-63B-4 ipd
December 2022

2020
2021
2022
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
2051
2052

Digital Identity Guidelines
Authentication and Lifecycle Management

the processing (predictability). Other processing of attributes may carry different privacy
risks that call for obtaining consent or allowing subscribers more control over the useor disclosure of specific attributes (manageability). Subscriber consent needs to bemeaningful; therefore, as stated in Sec. 4.4, when CSPs use consent measures, acceptanceby the subscriber of additional uses shall not be a condition of providing authentication
services.
Consult the agency SAOP if there are questions about whether the proposed processing
falls outside the scope of the permitted processing or the appropriate privacy risk
mitigation measures.
9.4. Agency-Speciﬁc Privacy Compliance
Section 4.4 covers specific compliance obligations for federal CSPs. It is criticalto involve the agency SAOP in the earliest stages of digital authentication systemdevelopment in order to assess and mitigate privacy risks and advise the agency oncompliance requirements, such as whether or not the collection of PII to issue or maintainauthenticators triggers the Privacy Act of 1974 [PrivacyAct] or the E-Government Act
of 2002 [E-Gov] requirement to conduct a PIA. For example, with respect to centralized
maintenance of biometrics, it is likely that the Privacy Act requirements will be triggered
and require coverage by either a new or existing Privacy Act system of records due to thecollection and maintenance of PII and any other attributes necessary for authentication.
The SAOP can similarly assist the agency in determining whether a PIA is required.
These considerations should not be read as a requirement to develop a Privacy Act SORN
or PIA for authentication alone. In many cases it will make the most sense to draft a
PIA and SORN that encompasses the entire digital identity process or include the digitalauthentication process as part of a larger programmatic PIA that discusses the online
service or benefit that the agency is establishing.
Due to the many components of digital authentication, it is important for the SAOP tohave an awareness and understanding of each individual component. For example, otherprivacy artifacts may be applicable to an agency offering or using federated CSP or RP
services (e.g., Data Use Agreements, Computer Matching Agreements). The SAOP
can assist the agency in determining what additional requirements apply. Moreover, athorough understanding of the individual components of digital authentication will enable
the SAOP to thoroughly assess and mitigate privacy risks either through compliance
processes or by other means.

60

NIST SP 800-63B-4 ipd
December 2022

2053

10.

2054

This section is informative.

2055

2056
2057
2058
2059
2060
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
2089

Digital Identity Guidelines
Authentication and Lifecycle Management

Usability Considerations

Note: In this section, the term users means claimants or subscribers.
[ISO/IEC9241-11] defines usability as the “extent to which a system, product, or service
can be used by specified users to achieve specified goals with effectiveness, efficiency
and satisfaction in a specified context of use.” This definition focuses on users, theirgoals, and the context of use as key elements necessary for achieving effectiveness,
efficiency, and satisfaction. A holistic approach that accounts for these key elements
is necessary to achieve usability.
A user’s goal for accessing an information system is to perform an intended task.
Authentication is the function that enables this goal. However, from the user’s perspective,
authentication stands between them and their intended task. Effective design andimplementation of authentication makes it easy to do the right thing, hard to do the wrong
thing, and easy to recover when the wrong thing happens.
Organizations need to be cognizant of the overall implications of their stakeholders’ entire
digital authentication ecosystem. Users often employ multiple authenticators, each fora different RP. They then struggle to remember passwords, to recall which authenticator
goes with which RP, and to carry multiple physical authentication devices. Evaluating theusability of authentication is critical, as poor usability often results in coping mechanisms
and unintended workarounds that can ultimately degrade the effectiveness of security
controls.
Integrating usability into the development process can lead to authentication solutions thatare secure and usable while still addressing users’ authentication needs and organizations’business goals.
The impact of usability across digital systems needs to be considered as part of therisk assessment when deciding on the appropriate AAL. Authenticators with a higher
AAL sometimes offer better usability and should be allowed for use with lower AAL
applications.
Leveraging federation for authentication can alleviate many of the usability issues, thoughsuch an approach has its own tradeoffs, as discussed in [SP800-63C].
This section provides general usability considerations and possible implementations, butdoes not recommend specific solutions. The implementations mentioned are examples
to encourage innovative technological approaches to address specific usability needs.
Further, usability considerations and their implementations are sensitive to many factorsthat prevent a one-size-fits-all solution. For example, a font size that works in thedesktop computing environment may force text to scroll off of a small OTP device screen.
Performing a usability evaluation on the selected authenticator is a critical component of61

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

2091

implementation. It is important to conduct evaluations with representative users, realistic
goals and tasks, and appropriate contexts of use.

2092

Guidelines and considerations are described from the users’ perspective.

2090

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

Accessibility differs from usability and is out of scope for this document. Section 508[Section508] was enacted to eliminate barriers in information technology and require
federal government agencies to make their online public content accessible to people withdisabilities. Refer to Section 508 law and standards for accessibility guidance.
10.1. Usability Considerations Common to Authenticators
When selecting and implementing an authentication system, consider usability across theentire lifecycle of the selected authenticators (e.g., typical use and intermittent events),
while being mindful of the combination of users, their goals, and context of use.
A single authenticator type usually does not suffice for the entire user population.
Therefore, whenever possible — based on AAL requirements — CSPs should support
alternative authenticator types and allow users to choose based on their needs. Task
immediacy, perceived cost benefit tradeoffs, and unfamiliarity with certain authenticators
often impact choice. Users tend to choose options that incur the least burden or cost atthat moment. For example, if a task requires immediate access to an information system,
a user may prefer to create a new subscriber account and password rather than select anauthenticator requiring more steps. Alternatively, users may choose a federated identity
option — approved at the appropriate AAL — if they already have a subscriber accountwith an identity provider. Users may understand some authenticators better than others,
and have different levels of trust based on their understanding and experience.
Positive user authentication experiences are integral to the success of an organizationachieving desired business outcomes. Therefore, they should strive to consider
authenticators from the users’ perspective. The overarching authentication usability goal
is to minimize user burden and authentication friction (e.g., the number of times a user
has to authenticate, the steps involved, and the amount of information they have to track).
Single sign-on exemplifies one such minimization strategy.

2120

Usability considerations applicable to most authenticators are described below.
Subsequent sections describe usability considerations specific to a particularauthenticator.

2121

Usability considerations for typical usage of all authenticators include:

2118
2119

2122
2123
2124

• Provide information on the use and maintenance of the authenticator, e.g., what to
do if the authenticator is lost or stolen, and instructions for use — especially if there
are different requirements for first-time use or initialization.

62

NIST SP 800-63B-4 ipd
December 2022

2125
2126
2127
2128

Digital Identity Guidelines
Authentication and Lifecycle Management• Authenticator availability should also be considered as users will need to remember
to have their authenticator readily available. Consider the need for alternate
authentication options to protect against loss, damage, or other negative impacts
to the original authenticator.

2133• Whenever possible, based on AAL requirements, users should be provided withalternate authentication options. This allows users to choose an authenticator basedon their context, goals, and tasks (e.g., the frequency and immediacy of the task).
Alternate authentication options also help address availability issues that may occur
with a particular authenticator.

2134• Characteristics of user-facing text:

2129
2130
2131
2132

2135
2136
2137

2138
2139
2140

2141

2142

2143
2144

2145
2146

2147

2148
2149
2150
2151
2152
2153

2154
2155
2156

2157
2158
2159

– Write user-facing text (e.g., instructions, prompts, notifications, error
messages) in plain language for the intended audience. Avoid technical jargon
and write for the audience’s expected literacy level.
– Consider the legibility of user-facing and user-entered text, including fontstyle, size, color, and contrast with surrounding background. Illegible text
contributes to user entry errors. To enhance legibility, consider the use of:* High contrast. The highest contrast is black on white.
* Sans serif fonts for electronic displays. Serif fonts for printed materials.
* Fonts that clearly distinguish between easily confusable characters (e.g.,
the capital letter “O” and the number “0”).
* A minimum font size of 12 points as long as the text fits for display on
the device.
• User experience during authenticator entry:– Offer the option to display text during entry, as masked text entry is errorprone. Once a given character is displayed long enough for the user to see, it
can be hidden. Consider the device when determining masking delay time, as
it takes longer to enter memorized secrets on mobile devices (e.g., tablets andsmartphones) than on traditional desktop computers. Ensure masking delay
durations are consistent with user needs.
– Ensure the time allowed for text entry is adequate (i.e., the entry screen does
not time out prematurely). Ensure allowed text entry times are consistent withuser needs.
– Provide clear, meaningful and actionable feedback on entry errors to reduce
user confusion and frustration. Significant usability implications arise whenusers do not know they have entered text incorrectly.

63

NIST SP 800-63B-4 ipd
December 2022

2160
2161
2162
2163
2164
2165
2166
2167

Digital Identity Guidelines
Authentication and Lifecycle Management– Allow at least 10 entry attempts for authenticators requiring the entry of theauthenticator output by the user. The longer and more complex the entry text,
the greater the likelihood of user entry errors.
– Provide clear, meaningful feedback on the number of remaining allowed
attempts. For rate limiting (i.e., throttling), inform users how long they have to
wait until the next attempt to reduce confusion and frustration.
• Minimize the impact of form-factor constraints, such as limited touch and display
areas on mobile devices:2172– Larger touch areas improve usability for text entry since typing on small
devices is significantly more error prone and time consuming than typing
on a full-size keyboard. The smaller the onscreen keyboard, the more difficult
it is to type, due to the size of the input mechanism (e.g., a finger) relative tothe size of the on-screen target.

2173– Follow good user interface and information design for small displays.

2168
2169
2170
2171

2175

Intermittent events include events such as reauthentication, subscriber account lock-out,
expiration, revocation, damage, loss, theft, and non-functional software.

2176

Usability considerations for intermittent events across authenticator types include:

2174

2177
2178
2179
2180
2181
2182
2183
2184
2185
2186

2187
2188
2189
2190

• To prevent users from needing to reauthenticate due to user inactivity, prompt users
in order to trigger activity just before (e.g., 2 minutes) an inactivity timeout would
otherwise occur.
• Prompt users with adequate time (e.g., 1 hour) to save their work before the fixed
periodic reauthentication event required regardless of user activity.
• Clearly communicate how and where to acquire technical assistance. For example,
provide users with information such as a link to an online self-service feature, chatsessions or a phone number for help desk support. Ideally, sufficient information
can be provided to enable users to recover from intermittent events on their own
without outside intervention.
10.2. Usability Considerations by Authenticator TypeIn addition to the previously described general usability considerations applicable to mostauthenticators (Sec. 10.1), the following sections describe other usability considerations
specific to particular authenticator types.

2192

10.2.1. Memorized Secrets
Typical Usage

2193

Users manually input the memorized secret (commonly referred to as a password or PIN).

2194

Usability considerations for typical usage include:

2191

64

NIST SP 800-63B-4 ipd
December 2022

2195

Digital Identity Guidelines
Authentication and Lifecycle Management• Memorability of the memorized secret2198– The likelihood of recall failure increases as there are more items for users toremember. With fewer memorized secrets, users can more easily recall the
specific memorized secret needed for a particular RP.

2199– The memory burden is greater for a less frequently used password.

2196
2197

2200

2201
2202

• User experience during entry of the memorized secret– Support copy and paste functionality in fields for entering memorized secrets,
including passphrases.

2203

Intermittent Events

2204

Usability considerations for intermittent events include:2205• When users create and change memorized secrets:

2206
2207

2208
2209

2210
2211
2212

2213
2214

2215
2216
2217

2218
2219
2220

2221
2222

– Clearly communicate information on how to create and change memorized
secrets.
– Clearly communicate memorized secret requirements, as specified inSec. 5.1.1.
– Allow at least 64 characters in length to support the use of passphrases.
Encourage users to make memorized secrets as lengthy as they want, using
any characters they like (including spaces), thus aiding memorization.
– Do not impose other composition rules (e.g. mixtures of different charactertypes) on memorized secrets.
– Do not require that memorized secrets be changed arbitrarily (e.g.,
periodically) unless there is a user request or evidence of authenticator
compromise. (See Sec. 5.1.1 for additional information).
• Provide clear, meaningful and actionable feedback when chosen passwords are
rejected (e.g., when it appears on a “blocklist” of unacceptable passwords or has
been used previously).
10.2.2. Look-Up Secrets
Typical Usage

2225

Users use the authenticator — printed or electronic — to look up the appropriate secret(s)needed to respond to a verifier’s prompt. For example, a user may be asked to provide a
specific subset of the numeric or character strings printed on a card in table format.

2226

Usability considerations for typical usage include:

2223
2224

2227

• User experience during entry of look-up secrets.
65

NIST SP 800-63B-4 ipd
December 2022

2228
2229
2230
2231
2232

2233
2234

Digital Identity Guidelines
Authentication and Lifecycle Management– Consider the prompts’ complexity and size. The larger the subset of secrets
a user is prompted to look up, the greater the usability implications. Boththe cognitive workload and physical difficulty for entry should be taken into
account when selecting the quantity and complexity of look-up secrets forauthentication.
10.2.3. Out-of-Band
Typical Usage2236

Out-of-band authentication requires users have access to a primary and secondarycommunication channel.

2237

Usability considerations for typical usage:

2235

2238
2239
2240

2241
2242
2243

2244
2245
2246
2247
2248
2249
2250

2251
2252

• Notify users of the receipt of a secret on a locked device. However, if the out-ofband device is locked, authentication to the device should be required to access thesecret.
• Depending on the implementation, consider form-factor constraints as they areparticularly problematic when users must enter text on mobile devices. Providing
larger touch areas will improve usability for entering secrets on mobile devices.
• A better usability option is to offer features that do not require text entry on mobile
devices (e.g., a single tap on the screen, or a copy feature so users can copy andpaste out-of-band secrets). Providing users such features is particularly helpfulwhen the primary and secondary channels are on the same device. For example, it
is difficult for users to transfer the authentication secret on a smartphone because
they must switch back and forth — potentially multiple times — between the outof-band application and the primary channel.
10.2.4. Single-Factor OTP Device
Typical Usage

2254

Users access the OTP generated by the single-factor OTP device. The authenticator
output is typically displayed on the device and the user enters it for the verifier.

2255

Usability considerations for typical usage include:

2253

2256
2257
2258
2259

2260
2261

• Authenticator output allows at least one minute between changes, but ideally allows
users the full two minutes as specified in Sec. 5.1.4.1. Users need adequate timeto enter the authenticator output (including looking back and forth between the
single-factor OTP device and the entry screen).
• Depending on the implementation, the following are additional usability
considerations for implementers:

66

NIST SP 800-63B-4 ipd
December 2022

2262
2263
2264
2265
2266
2267

2268
2269
2270
2271

2272
2273

Digital Identity Guidelines
Authentication and Lifecycle Management– If the single-factor OTP device supplies its output via an electronic interface(e.g, USB) this is preferable since users do not have to manually enter theauthenticator output. However, if a physical input (e.g., pressing a button)
is required to operate, the location of the USB ports could pose usability
difficulties. For example, the USB ports of some computers are located on
the back of the computer and will be difficult for users to reach.
– Limited availability of a direct computer interface such as a USB port could
pose usability difficulties. For example, the number of USB ports on laptop
computers is often very limited. This may force users to unplug other USB
peripherals in order to use the single-factor OTP device.
10.2.5. Multi-Factor OTP Device
Typical Usage

2280

Users access the OTP generated by the multi-factor OTP device through a second
authentication factor. The OTP is typically displayed on the device and the user manuallyenters it for the verifier. The second authentication factor may be achieved throughsome kind of integral entry pad to enter a memorized secret, an integral biometric(e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Usability
considerations for the additional factor apply as well — see Sec. 10.2.1 for memorized
secrets and Sec. 10.4 for biometrics used in multi-factor authenticators.

2281

Usability considerations for typical usage include:

2274
2275
2276
2277
2278
2279

2282

2283
2284
2285
2286

2287
2288
2289
2290
2291
2292
2293

2294
2295
2296
2297

• User experience during manual entry of the authenticator output.
– For time-based OTP, provide a grace period in addition to the time during
which the OTP is displayed. Users need adequate time to enter theauthenticator output, including looking back and forth between the multifactor OTP device and the entry screen.
– Consider form-factor constraints if users must unlock the multi-factor OTP
device via an integral entry pad or enter the authenticator output on mobile
devices. Typing on small devices is significantly more error prone and timeconsuming than typing on a traditional keyboard. The smaller the integral
entry pad and onscreen keyboard, the more difficult it is to type. Providing
larger touch areas improves usability for unlocking the multi-factor OTP
device or entering the authenticator output on mobile devices.
– Limited availability of a direct computer interface like a USB port could poseusability difficulties. For example, laptop computers often have a limited
number of USB ports, which may force users to unplug other USB peripherals
to use the multi-factor OTP device.

67

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

2299

10.2.6. Single-Factor Cryptographic Software
Typical Usage

2300

Users authenticate by proving possession and control of the cryptographic software key.

2301

Usability considerations for typical usage include:

2298

2302
2303
2304
2305
2306
2307

• Give cryptographic keys appropriately descriptive names that are meaningful tousers since users have to recognize and recall which cryptographic key to use forwhich authentication task. This prevents users from having to deal with multiple
similarly and ambiguously named cryptographic keys. Selecting from multiple
cryptographic keys on smaller mobile devices may be particularly problematic if
the names of the cryptographic keys are shortened due to reduced screen size.

2309

10.2.7. Single-Factor Cryptographic Device
Typical Usage

2310

Users authenticate by proving possession of the single-factor cryptographic device.

2311

Usability considerations for typical usage include:

2308

2312
2313
2314

2315
2316
2317
2318

2319
2320

• Requiring a physical input (e.g., pressing a button) to operate the single-factor
cryptographic device could pose usability difficulties. For example, some USB
ports are located on the back of computers, making it difficult for users to reach.
• Limited availability of a direct computer interface like a USB port could poseusability difficulties. For example, laptop computers often have a limited numberof USB ports, which may force users to unplug other USB peripherals to use thesingle-factor cryptographic device.
10.2.8. Multi-Factor Cryptographic Software
Typical Usage

In order to authenticate, users prove possession and control of the cryptographic key
stored on disk or some other “soft” media that requires activation. The activation is2322
through the input of a second authentication factor, either a memorized secret or a2323
biometric characteristic. Usability considerations for the additional factor apply as well2324
2325 — see Sec. 10.2.1 for memorized secrets and Sec. 10.4 for biometrics used in multi-factor
authenticators.
2326
2321

2327

2328
2329
2330
2331

Usability considerations for typical usage include:• Give cryptographic keys appropriately descriptive names that are meaningful tousers since users have to recognize and recall which cryptographic key to use forwhich authentication task. This prevents users from having to deal with multiple
similarly and ambiguously named cryptographic keys. Selecting from multiple
68

NIST SP 800-63B-4 ipd
December 2022

2332
2333

2334
2335

Digital Identity Guidelines
Authentication and Lifecycle Management

cryptographic keys on smaller mobile devices may be particularly problematic if
the names of the cryptographic keys areas shortened due to reduced screen size.
10.2.9. Multi-Factor Cryptographic Device
Typical Usage

2340

Users authenticate by proving possession of the multi-factor cryptographic device
and control of the protected cryptographic key. The device is activated by a second
authentication factor, either a memorized secret or a biometric. Usability considerations
for the additional factor apply as well — see Sec. 10.2.1 for memorized secrets andSec. 10.4 for biometrics used in multi-factor authenticators.

2341

Usability considerations for typical usage include:

2336
2337
2338
2339

2342
2343
2344
2345

2346
2347

2348
2349
2350
2351
2352
2353
2354

2355
2356
2357
2358

2359
2360
2361
2362
2363
2364
2365
2366
2367

• Do not require users to keep multi-factor cryptographic devices connectedfollowing authentication. Users may forget to disconnect the multi-factor
cryptographic device when they are done with it (e.g., forgetting a smartcard in
the smartcard reader and walking away from the computer).
– Users need to be informed regarding whether the multi-factor cryptographic
device is required to stay connected or not.
• Give cryptographic keys appropriately descriptive names that are meaningful tousers since users have to recognize and recall which cryptographic key to use
for which authentication task. This prevents users being faced with multiple
similarly and ambiguously named cryptographic keys. Selecting from multiple
cryptographic keys on smaller mobile devices (such as smartphones) may beparticularly problematic if the names of the cryptographic keys are shortened due toreduced screen size.
• Limited availability of a direct computer interface like a USB port could poseusability difficulties. For example, laptop computers often have a limited numberof USB ports, which may force users to unplug other USB peripherals to use themulti-factor cryptographic device.
10.3. Summary of Usability Considerations
Figure 3 summarizes the usability considerations for typical usage and intermittent
events for each authenticator type. Many of the usability considerations for typicalusage apply to most of the authenticator types, as demonstrated in the rows. The tablehighlights common and divergent usability characteristics across the authenticator types.
Each column allows readers to easily identify the usability attributes to address for eachauthenticator. Depending on users’ goals and context of use, certain attributes may bevalued over others. Whenever possible, provide alternative authenticator types and allow
users to choose between them.
69

NIST SP 800-63B-4 ipd
December 2022

2368
2369
2370
2371
2372

Digital Identity Guidelines
Authentication and Lifecycle Management

Multi-factor authenticators (e.g., multi-factor OTP devices, multi-factor cryptographic
software, and multi-factor cryptographic devices) also inherit their secondary factor’s
usability considerations. As biometrics are only allowed as an activation factor in multifactor authentication solutions, usability considerations for biometrics are not included in
Figure 3 and are discussed in Sec. 10.4.

70

NIST SP 800-63B-4 ipd
December 2022

Digital Identity Guidelines
Authentication and Lifecycle Management

Figure 3. Usability Considerations Summary by Authenticator Type71

NIST SP 800-63B-4 ipd
December 2022

2373
2374
2375
2376

Digital Identity Guidelines
Authentication and Lifecycle Management

10.4. Biometrics Usability Considerations
This section provides a high-level overview of general usability considerations forbiometrics. A more detailed discussion of biometric usability can be found in Usability &Biometrics, Ensuring Successful Biometric Systems [UsabilityBiometrics].

2378

Although there are other biometric modalities, the following three biometric modalities
are more commonly used for authentication: fingerprint, face and iris.

2379

Typical Usage

2377

2380
2381

2382
2383
2384
2385

• For all modalities, user familiarity and practice with the device improves
performance.
• Device affordances (i.e., properties of a device that allow a user to perform anaction), feedback, and clear instructions are critical to a user’s success with thebiometric device. For example, provide clear instructions on the required actions for
liveness detection.

2388• Ideally, users can select the modality they are most comfortable with for theirsecond authentication factor. The user population may be more comfortable andfamiliar with — and accepting of — some biometric modalities than others.

2389• User experience with biometrics as an activation factor.

2386
2387

2390
2391
2392
2393

2394

2395

2396
2397

2398
2399
2400

2401

2402
2403

2404
2405

2406
2407

– Provide clear, meaningful feedback on the number of remaining allowed
attempts. For example, for rate limiting (i.e., throttling), inform users of thetime period they have to wait until next attempt to reduce user confusion andfrustration.
• Fingerprint Usability Considerations:– Users have to remember which finger(s) they used for initial enrollment.
– The amount of moisture on the finger(s) affects the sensor’s ability forsuccessful capture.
– Additional factors influencing fingerprint capture quality include age, gender,and occupation (e.g., users handling chemicals or working extensively with
their hands may have degraded friction ridges).
• Face Usability Considerations:– Users have to remember whether they wore any artifacts (e.g., glasses) during
enrollment because it affects facial recognition accuracy.
– Differences in environmental lighting conditions can affect facial recognition
accuracy.
– Facial expressions affect facial recognition accuracy (e.g., smiling versus
neutral expression).
72

NIST SP 800-63B-4 ipd
December 2022

2408
2409

2410

Digital Identity Guidelines
Authentication and Lifecycle Management– Facial poses affect facial recognition accuracy (e.g., looking down or awayfrom the camera).
• Iris Usability Considerations:2411– Wearing colored contacts may affect the iris recognition accuracy.

2412– Users who have had eye surgery may need to re-enroll post-surgery.

2413
2414

2415

2416
2417
2418
2419

2420
2421

– Differences in environmental lighting conditions can affect iris recognition
accuracy, especially for certain iris colors.
Intermittent Events
As biometrics are only permitted as a second factor for multi-factor authentication,
usability considerations for intermittent events with the primary factor still apply.
Intermittent events with biometrics use include, but are not limited to, the following,
which may affect recognition accuracy:• If users injure their enrolled finger(s), fingerprint recognition may not work.
Fingerprint authentication will be difficult for users with degraded fingerprints.

2424• The time elapsed between the time of facial recognition for authentication andthe time of the initial enrollment can affect recognition accuracy as a user’s facechanges naturally over time. A user’s weight change may also be a factor.

2425• Iris recognition may not work for people who had eye surgery, unless they re-enroll.

2422
2423

2426

Across all biometric modalities, usability considerations for intermittent events include:2429• An alternative authentication method must be available and functioning. In
cases where biometrics do not work, allow users to use a memorized secret as analternative second factor.

2430• Provisions for technical assistance:

2427
2428

2431
2432
2433
2434
2435

2436
2437

– Clearly communicate information on how and where to acquire technicalassistance. For example, provide users information such as a link to an
online self-service feature and a phone number for help desk support. Ideally,
provide sufficient information to enable users to recover from intermittent
events on their own without outside intervention.
– Inform users of factors that may affect the sensitivity of the biometric sensor(e.g., cleanliness of the sensor).

73

NIST SP 800-63B-4 ipd
December 2022

2438

11.

2439

This section is informative.

2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451

2452
2453
2454

Digital Identity Guidelines
Authentication and Lifecycle Management

Equity Considerations

Accurate and equitable authentication service is an essential element of a digital
identity system. While the accuracy aspects of authentication are largely the subjectof the security requirements found elsewhere in this document, the ability for all
subscribers to authenticate reliably is required to provide equitable access to government
services as specified in Executive Order 13985, “Advancing Racial Equity and Support
for Underserved Communities Through the Federal Government” [EO13985]. In
assessing equity risks, a CSP should consider the overall user population served by its
authentication service. Additionally, the CSP further identifies groups of users within
the population whose shared characteristic(s) can cause them to be subject to inequitable
access, treatment, or outcomes when using that service. The usability considerations
provided in Sec. 10 should also be considered to help ensure the overall usability andequity for all persons using authentication services.
A primary aspect of equity is that the CSP needs to anticipate the needs of its subscriber
population and offer authenticator options that are suitable for that population. Some
examples of authenticator suitability problems are as follows:

2456• SMS-based out-of-band authentication may not be usable for subscribers in rural
areas where mobile phone service is not available.

2457• OTP devices may be difficult for subscribers with vision difficulties to read.

2455

2458
2459

2460
2461

2462
2463

2464
2465

2466
2467
2468

2469
2470
2471
2472
2473
2474

• Out-of-band authentication secrets sent via a voice telephone call may be difficult
for subscribers with hearing difficulties to understand.
• Facial matching algorithms may less effectively match facial characteristics ofsubscribers of some ethnicities.
• The cost of hardware-based authenticators may be beyond the means of somesubscribers.
• Accurate manual entry of memorized secrets may be difficult for subscribers withsome mobility and dexterity-related physical disabilities.
• The use of certain authenticator types may be challenging for subscribers withsome disabilities such as intellectual, developmental, learning, and neurocognitivedifficulties.
Normative requirements have been established requiring CSPs to mitigate the problems
in this area that are expected to be most common. However, it is not feasible to anticipate
all potential equity problems. Potential equity problems also will vary for different
applications. Accordingly, CSPs need to provide mechanisms for subscribers to reportinequitable authentication requirements and to advise them on potential alternative
authentication strategies.
74

NIST SP 800-63B-4 ipd
December 2022

2475
2476
2477
2478
2479

2480
2481
2482
2483

Digital Identity Guidelines
Authentication and Lifecycle Management

This guideline recommends the binding of additional authenticators to minimize theneed for account recovery (see Sec. 6.1.2.3). However, a subscriber might find it difficult
to purchase a second hardware-based authenticator as a backup. This inequity can beaddressed by making inexpensive authenticators such as look-up secrets (see Sec. 5.1.2)
available for use in the event of a primary authenticator failure or loss.
CSPs need to be responsive to subscribers that experience authentication challenges
that cannot be solved using authenticators they currently support. This might involve
supporting a new authenticator type or allowing federated authentication through a trusted
service that meets the needs of the subscriber.

75

NIST SP 800-63B-4 ipd
December 2022

2484

References

2485

This section is informative.

2486
2487
2488
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

Digital Identity Guidelines
Authentication and Lifecycle Management

General References[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, “Argon2 MemoryHard Function for Password Hashing and Proof-of-Work Applications“, RFC 9106, DOI
10.17487/RFC9106, September 2021, https://www.rfc-editor.org/info/rfc9106.
[Blocklists] Habib, Hana, Jessica Colnago, William Melicher, Blase Ur, Sean Segreti,
Lujo Bauer, Nicolas Christin, and Lorrie Cranor. “Password Creation in the Presence ofBlacklists,” 2017. Available at: https://www.ndss-symposium.org/wp-content/uploads/
2017/09/usec2017 01 3 Habib paper.pdf[Composition] Komanduri, Saranga, Richard Shay, Patrick Gage Kelley, Michelle L
Mazurek, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Serge Egelman. “Of
Passwords and People: Measuring the Effect of Password-Composition Policies.” In
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems,
2595–2604. ACM, 2011. Available at: https://www.ece.cmu.edu/∼lbauer/papers/2011/
chi2011-passwords.pdf.
[E-Gov] E-Government Act (includes FISMA) (P.L. 107-347), December 2002,
available at: https://www.gpo.gov/fdsys/pkg/PLAW-107publ347/pdf/PLAW-107publ347.
pdf.
[EO13681] Executive Order 13681, Improving the Security of Consumer Financial
Transactions, October 17, 2014, available at: https://www.federalregister.gov/d/201425439.
[EO13985] Executive Order 13985, Advancing Racial Equity and Support for
Underserved Communities Through the Federal Government, January 25, 2021, available
at: https://www.federalregister.gov/d/2021-01753.
[FEDRAMP] General Services Administration, Federal Risk and Authorization
Management Program, available at: https://www.fedramp.gov/.
[M-22-09] OMB Memorandum M-22-09, Moving the U.S. Government Toward Zero
Trust Cybersecurity Principles, January 26, 2022, available at: https://www.whitehouse.
gov/wp-content/uploads/2022/01/M-22-09.pdf.
[NISTIR8062] NIST Internal Report 8062, An Introduction to Privacy Engineering and
Risk Management in Federal Systems, January 2017, available at: https://nvlpubs.nist.gov/
nistpubs/ir/2017/NIST.IR.8062.pdf.
[UsabilityBiometrics] National Institute and Standards and Technology, Usability& Biometrics, Ensuring Successful Biometric Systems, June 11, 2008, available at:
76

NIST SP 800-63B-4 ipd
December 2022

2519

2520
2521

2522
2523
2524

2525
2526
2527

2528
2529
2530
2531

Digital Identity Guidelines
Authentication and Lifecycle Management

https://www.nist.gov/customcf/get pdf.cfm?pub id=152184.
[OWASP-session] Open Web Application Security Project, Session Management Cheat
Sheet, available at: https://www.owasp.org/index.php/Session Management Cheat Sheet.
[OWASP-XSS-prevention] Open Web Application Security Project, XSS (Cross Site
Scripting) Prevention Cheat Sheet, available at: https://www.owasp.org/index.php/
XSS (Cross Site Scripting) Prevention Cheat Sheet.
[Persistence] herley, cormac, and Paul van Oorschot. “A Research Agenda
Acknowledging the Persistence of Passwords,” IEEE Security&Privacy Magazine, 2012.
Available at: https://research.microsoft.com/apps/pubs/default.aspx?id=154077.
[Policies] Weir, Matt, Sudhir Aggarwal, Michael Collins, and Henry Stern. “Testing
Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords.”
In Proceedings of the 17th ACM Conference on Computer and Communications Security,
162–175. CCS ‘10. New York, NY, USA: ACM, 2010. doi:10.1145/1866307.1866327.

2533[PrivacyAct] Privacy Act of 1974 (P.L. 93-579), December 1974, available at: https://www.justice.gov/opcl/privacy-act-1974.

2534[PSL] Public Suffix List https://publicsuffix.org/list/

2532

2535
2536
2537

2538
2539

2540
2541

2542
2543
2544
2545
2546
2547

2548
2549
2550

[Scrypt] Percival, C. and S. Josefsson, The scrypt Password-Based Key Derivation
Function, RFC 7914, DOI 10.17487/RFC7914, August 2016, https://www.rfc-editor.
org/info/rfc7914.
[Section508] Section 508 Law and Related Laws and Policies (January 30, 2017),
available at: https://www.section508.gov/manage/laws-and-policies/.
[Shannon] Shannon, Claude E. “A Mathematical Theory of Communication,” Bell
System Technical Journal, v. 27, pp. 379-423, 623-656, July, October, 1948.
[Strength] Kelley, Patrick Gage, Saranga Komanduri, Michelle L Mazurek, Richard
Shay, Timothy Vidas, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor, and Julio Lopez.
“Guess Again (and Again and Again): Measuring Password Strength by Simulating
Password-Cracking Algorithms.” In Security and Privacy (SP), 2012 IEEE Symposium
On, 523–537. IEEE, 2012. Available at: https://ieeexplore.ieee.org/iel5/6233637/
6234400/06234434.pdf.
[TOTP] M’Raihi, D., Machani, S., Pei, M., and J. Rydell, TOTP: Time-Based One-Time
Password Algorithm, RFC 6238, DOI 10.17487/RFC6238, May 2011, https://www.rfceditor.org/info/rfc6238.

77

NIST SP 800-63B-4 ipd
December 2022

2551
2552
2553
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

Digital Identity Guidelines
Authentication and Lifecycle Management

Standards[ISO/IEC9241-11] International Standards Organization, ISO/IEC 9241-11 Ergonomic
requirements for office work with visual display terminals (VDTs) — Part 11: Guidanceon usability, March 1998, available at: https://www.iso.org/standard/16883.html.
[ISO/IEC2382-37] International Standards Organization, Information technology —Vocabulary — Part 37: Biometrics, 2017, available at: https://standards.iso.org/ittf/
PubliclyAvailableStandards/c066693 ISO IEC 2382-37 2017.zip.
[ISO/IEC10646] International Standards Organization, Information technology —Universal coded character set (UCS), 2020, available at: https://www.iso.org/standard/
76835.html.
[ISO/IEC24745] International Standards Organization, Information technology —Security techniques — Biometric information protection, 2011, available at: https://www.iso.org/iso/iso catalogue/catalogue tc/catalogue detail.htm?csnumber=52946.
[ISO/IEC30107-1] International Standards Organization, Information technology —Biometric presentation attack detection — Part 1: Framework, 2016, available at: https://standards.iso.org/ittf/PubliclyAvailableStandards/c053227 ISO IEC 30107-1 2016.zip.
[ISO/IEC30107-3] International Standards Organization, Information technology —Biometric presentation attack detection — Part 3: Testing and reporting, 2017.
[RFC20] Cerf, V., “ASCII format for network interchange“, STD 80, RFC 20, DOI
10.17487/RFC0020, October 1969, https://www.rfc-editor.org/info/rfc20.
[UAX15] Unicode Consortium, Unicode Normalization Forms, Unicode Standard Annex
15, Version 9.0.0, February 2016, available at: https://www.unicode.org/reports/tr15/.
NIST Special Publications
NIST 800 Series Special Publications are available at https://csrc.nist.gov/publications/
sp800. The following publications may be of particular interest to those implementing
systems of applications requiring digital authentication.
[SP800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher
Modes of Operation: the CMAC Mode for Authentication, October, 2016, https://dx.doi.
org/10.6028/NIST.SP.800-38B.
[SP800-53] NIST Special Publication 800-53 Revision 5, Security and Privacy Controls
for Information Systems and Organizations, September 2020 (updated December 10,2020), https://dx.doi.org/10.6028/NIST.SP.800-53r5.

2584[SP800-63] NIST Special Publication 800-63-4, Digital Identity Guidelines, December
2022, https://doi.org/10.6028/NIST.SP.800-63-4.ipd.

2585[SP800-63A] NIST Special Publication 800-63B-4, Digital Identity Guidelines:

2583

78

NIST SP 800-63B-4 ipd
December 2022

2586
2587

2588
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

Digital Identity Guidelines
Authentication and Lifecycle Management

Enrollment and Identity Proofing, December 2022, https://doi.org/10.6028/
NIST.SP.800-63a-4.ipd.
[SP800-63C] NIST Special Publication 800-63C-4, Digital Identity Guidelines:
Assertions and Federation, November 2022, https://doi.org/10.6028/
NIST.SP.800-63c-4.ipd.
[SP800-73] NIST Special Publication 800-73-4, Interfaces for Personal Identity
Verification, February 2016, https://doi.org/10.6028/NIST.SP.800-73-4.
[SP800-90A] NIST Special Publication 800-90A Revision 1, Recommendation for
Random Number Generation Using Deterministic Random Bit Generators, June 2015,
https://dx.doi.org/10.6028/NIST.SP.800-90Ar1.
[SP800-107] NIST Special Publication 800-107 Revision 1, Recommendation forApplications Using Approved Hash Algorithms, August 2012, https://dx.doi.org/10.6028/
NIST.SP.800-107r1.
[SP800-131A] NIST Special Publication 800-131A Revision 2, Transitioning the Use of
Cryptographic Algorithms and Key Lengths, March 2019, https://dx.doi.org/10.6028/
NIST.SP.800-131Ar2[SP800-132] NIST Special Publication 800-132, Recommendation for Password-Based
Key Derivation, December 2010, https://dx.doi.org/10.6028/NIST.SP.800-132.
[SP800-185] NIST Special Publication 800-185, SHA-3 Derived Functions: cSHAKE,
KMAC, TupleHash, and ParallelHash, December 2016, https://doi.org/10.6028/
NIST.SP. 800-185.
Federal Information Processing Standards[FIPS140] Federal Information Processing Standard Publication 140-3, Security
Requirements for Cryptographic Modules, March 22, 2019, https://doi.org/10.6028/
NIST. FIPS.140-3.
[FIPS198] Federal Information Processing Standard Publication 198-1, The Keyed-Hash
Message Authentication Code (HMAC), July 2008, https://doi.org/10.6028/NIST.FIPS.
198-1.
[FIPS201] Federal Information Processing Standard Publication 201-3, Personal Identity
Verification (PIV) of Federal Employees and Contractors, January 2022, https: //dx.doi.org/10.6028/NIST.FIPS.201-3.
[FIPS202] Federal Information Processing Standard Publication 202, SHA-3 Standard:
Permutation-Based Hash and Extendable-Output Functions, August 2015, https://dx.doi.
org/10.6028/NIST.FIPS.202.

79

NIST SP 800-63B-4 ipd
December 2022

2620

Appendix A.

2621

This appendix is informative.

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
2655
2656

Digital Identity Guidelines
Authentication and Lifecycle Management

Strength of Memorized Secrets

Throughout this appendix, the word “password” is used for ease of discussion. Where
used, it should be interpreted to include passphrases and PINs as well as passwords.
A.1. Introduction
Despite widespread frustration with the use of passwords from both a usability andsecurity standpoint, they remain a very widely used form of authentication [Persistence].
Humans, however, have only a limited ability to memorize complex, arbitrary secrets, sothey often choose passwords that can be easily guessed. To address the resultant security
concerns, online services have introduced rules in an effort to increase the complexityof these memorized secrets. The most notable form of these is composition rules, which
require the user to choose passwords constructed using a mix of character types, such as
at least one digit, uppercase letter, and symbol. However, analyses of breached password
databases reveal that the benefit of such rules is not nearly as significant as initiallythought [Policies], although the impact on usability and memorability is severe.
Complexity of user-chosen passwords has often been characterized using the information
theory concept of entropy [Shannon]. While entropy can be readily calculated for data
having deterministic distribution functions, estimating the entropy for user-chosenpasswords is difficult and past efforts to do so have not been particularly accurate. For
this reason, a different and somewhat simpler approach, based primarily on password
length, is presented herein.
Many attacks associated with the use of passwords are not affected by password
complexity and length. Keystroke logging, phishing, and social engineering attacks areequally effective on lengthy, complex passwords as simple ones. These attacks are outside
the scope of this Appendix.
A.2. Length
Password length has been found to be a primary factor in characterizing password
strength [Strength] [Composition]. Passwords that are too short yield to brute force
attacks as well as to dictionary attacks using words and commonly chosen passwords.
The minimum password length that should be required depends to a large extent on thethreat model being addressed. Online attacks where the attacker attempts to log in byguessing the password can be mitigated by limiting the rate of login attempts permitted.
In order to prevent an attacker (or a persistent claimant with poor typing skills) fromeasily inflicting a denial-of-service attack on the subscriber by making many incorrect
guesses, passwords need to be complex enough that rate limiting does not occur after amodest number of erroneous attempts, but does occur before there is a significant chanceof a successful guess.
80

NIST SP 800-63B-4 ipd
December 2022

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
2689
2690
2691
2692
2693
2694
2695

Digital Identity Guidelines
Authentication and Lifecycle Management

Offline attacks are sometimes possible when one or more hashed passwords is obtainedby the attacker through a database breach. The ability of the attacker to determine one ormore users’ passwords depends on the way in which the password is stored. Commonly,
passwords are salted with a random value and hashed, preferably using a computationallyexpensive algorithm. Even with such measures, the current ability of attackers to computemany billions of hashes per second with no rate limiting requires passwords intended toresist such attacks to be orders of magnitude more complex than those that are expected toresist only online attacks.
Users should be encouraged to make their passwords as lengthy as they want, withinreason. Since the size of a hashed password is independent of its length, there is no reason
not to permit the use of lengthy passwords (or pass phrases) if the user wishes. Extremely
long passwords (perhaps megabytes in length) could conceivably require excessive
processing time to hash, so it is reasonable to have some limit.
A.3. Complexity
As noted above, composition rules are commonly used in an attempt to increase thedifficulty of guessing user-chosen passwords. Research has shown, however, that users
respond in very predictable ways to the requirements imposed by composition rules[Policies]. For example, a user that might have chosen “password” as their password
would be relatively likely to choose “Password1” if required to include an uppercase letterand a number, or “Password1!” if a symbol is also required.
Users also express frustration when attempts to create complex passwords are rejectedby online services. Many services reject passwords with spaces and various special
characters. In some cases, the special characters that are not accepted might be an effort
to avoid attacks like SQL injection that depend on those characters. But a properly hashedpassword would not be sent intact to a database in any case, so such precautions areunnecessary. Users should also be able to include space characters to allow the use ofphrases. Spaces themselves, however, add little to the complexity of passwords and may
introduce usability issues (e.g., the undetected use of two spaces rather than one), so it
may be beneficial to remove repeated spaces in typed passwords prior to verification.
Users’ password choices are very predictable, so attackers are likely to guess passwords
that have been successful in the past. These include dictionary words and passwords
from previous breaches, such as the “Password1!” example above. For this reason,
it is recommended that passwords chosen by users be compared against a blocklistof unacceptable passwords. This list should include passwords from previous breach
corpuses, dictionary words, and specific words (such as the name of the service itself)that users are likely to choose. Since user choice of passwords will also be governedby a minimum length requirement, this dictionary need only include entries meetingthat requirement. As noted in Sec. 5.1.1.2, it is not beneficial for the blocklist to be
excessively large or comprehensive, since its primary purpose is to prevent the use of very
81

NIST SP 800-63B-4 ipd
December 2022

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
2722
2723
2724
2725
2726

2727
2728
2729
2730
2731
2732
2733
2734

Digital Identity Guidelines
Authentication and Lifecycle Management

common passwords that might be guessed in an online attack before throttling restrictions
take effect. An excessively large blocklist is likely to frustrate users that attempt to choose
a memorable password.
Highly complex memorized secrets introduce a new potential vulnerability: they are lesslikely to be memorable, and it is more likely that they will be written down or stored
electronically in an unsafe manner. While these practices are not necessarily vulnerable,
statistically some methods of recording such secrets will be. This is an additional
motivation not to require excessively long or complex memorized secrets.
A.4. Central vs. Local Veriﬁcation
While passwords that are used as a separate authentication factor are generally verified
centrally by the CSP’s verifier, those that are used as an activation factor for a multifactor authenticator are either verified locally or are used to derive the authenticator
output, which will be incorrect if the wrong activation factor is used. Both of thesesituations are referred to as “local verification”.
The attack surface and vulnerabilities for central and local verification are very different
from each other. Accordingly, the requirements for memorized secrets verified centrally
is different from those verified locally. Centrally verified secrets require the verifier,which is an online resource, to store salted and iteratively hashed verification secrets
for all subscribers’ passwords. Although the salting and hashing process increases thecomputational effort to determine the passwords from the hashes, the verifier is an
attractive target for attackers, particularly those who are interested in compromising an
arbitrary subscriber rather than a specific one.
Local verifiers do not have the same concerns with attacks at scale on a central online
verifier, but depend to a greater extent on the physical security of the authenticator andthe integrity of its associated endpoint. To the extent that the authenticator stores theactivation factor, that factor must be protected against physical and side-channel (e.g.,
power and timing analysis) attacks on the authenticator. When the activation factor isentered through the associated endpoint, the endpoint needs to be free of malware, suchas key-logging software, if the password is to be protected. Since these threats are lessdependant on the length and complexity of the password, those requirements are relaxed
for local verification.
Online password-guessing attacks are a similar threat for centrally and locally verified
passwords. Throttling, which is the primary defense against online attacks, can beparticularly challenging for local verifiers because of the limited ability of someauthenticators to securely store information about unsuccessful attempts. Throttling
can be performed by either keeping a count of invalid attempts in the authenticator, orby generating an authenticator output that is rejected by the CSP verifier, which does
the throttling. In this case it is important that the invalid outputs not be obvious to theattacker, who could otherwise make offline attempts until a valid-looking output appears.
82

NIST SP 800-63B-4 ipd
December 2022

2735
2736
2737
2738
2739
2740
2741

Digital Identity Guidelines
Authentication and Lifecycle Management

A.5. Summary
Length and complexity requirements beyond those recommended here significantly
increase the difficulty of memorized secrets and increase user frustration. As aresult, users often work around these restrictions in a way that is counterproductive.
Furthermore, other mitigations such as blocklists, secure hashed storage, and rate limiting
are more effective at preventing modern brute-force attacks. Therefore, no additional
complexity requirements are imposed.

83

NIST SP 800-63B-4 ipd
December 2022

2742

2743
2744

2745
2746

2747
2748

2749
2750

2751
2752

Appendix B.

Digital Identity Guidelines
Authentication and Lifecycle Management

Change Log

This appendix is informative. It provides an overview of the changes to SP 800-63B since
its initial release.
• Section 5.2.3 — Updated biometric performance requirements and metrics andincluded discussion of equity impacts.
• Section 5.2.5 — Added definition and updated requirements for phishing resistantauthenticators.
• Section 5.2.11 — Established separate requirements for locally verified memorized
secrets known as activation secrets.
• Section 5.2.12 — Added requirements for authenticators that are connected via
wireless technologies such as NFC and Bluetooth.

84