6 Selecting Assurance Levels
All changes in this version
Title changed
Before · SP 800-63-3
Selecting Assurance Levels
After · SP 800-63-4
Selecting Assurance Levels
Control changed
Before · SP 800-63-3
This section is normative.
The risk assessment results are the primary factor in selecting the most appropriate levels. This section details how to apply the results of the risk assessment with additional factors unrelated to risk to determine the most advantageous x AL selection.
First, compare the risk assessment impact profile to the impact profiles associated with each assurance level, as shown in Table 6-1 below. To determine the required assurance level, find the lowest level whose impact profile meets or exceeds the potential impact for every category analyzed in the risk assessment.
Table 6-1 Maximum Potential Impacts for Each Assurance Level
Assurance Level
Impact Categories 1 2 3
Inconvenience, distress or damage to standing or reputation Low Mod High
Financial loss or agency liability Low Mod High
Harm to agency programs or public interests N/A Low/Mod High
Unauthorized release of sensitive information N/A Low/Mod High
Personal Safety N/A Low Mod/High
Civil or criminal violations N/A Low/Mod High
In analyzing risks, the agency SHALL consider all of the expected direct and indirect results of an authentication failure, including the possibility that there will be more than one failure, or harms to more than one person or organization. The definitions of potential impacts contain some relative terms, like “serious” or “minor,” whose meaning will depend on context. The agency SHOULD consider the context and the nature of the persons or entities affected to decide the relative significance of these harms. Over time, the meaning of these terms will become more definite as agencies gain practical experience with these issues. The analysis of harms to agency programs or other public interests depends strongly on the context; the agency SHOULD consider these issues with care.
It is possible that the assurance levels may differ across IAL, AAL, and FAL. For example, suppose an agency establishes a “health tracker” application in which users submit personal information in the form of personal health information (PHI). In line with the terms of EO 13681 requiring “that all agencies making personal data accessible to citizens through digital applications require the use of multiple factors of authentication,” the agency is required to implement MFA at AAL2 or AAL3.
EO 13681 also requires agencies employ “an effective identity proofing process, as appropriate” when personal information is released. This does not mean that proofing at IAL2 or IAL3 (to match the required AAL) is necessary. In the above example, there may be no need for the agency system to know the actual identity of the user. In this case, an “effective proofing process” would be to not proof at all, therefore the agency would select IAL1. This allows the user of the health tracker system to be pseudonymous.
Despite the user being pseudonymous, the agency should still select AAL2 or AAL3 for authentication because a malicious actor could gain access to the user’s PHI by compromising the account.
Note: An agency can accept a higher assurance level than those required in the table above. For example, in a federated transaction, an agency can accept an IAL3 identity if their application is assessed at IAL2. The same holds true for authenticators: stronger authenticators can be used at RPs that have lower authenticator requirements. However, RPs will have to ensure that this only occurs in federated scenarios with appropriate privacy protections by the CSP such that only attributes that have been requested by the RP and authorized by the subscriber are provided to the RP and that excessive personal information does not leak from the credential or an assertion. See the privacy considerations in SP 800-63C for more details.
Note: The upshot of potentially having a different IAL, AAL, and FAL within a single application stems from the fact that this document no longer supports the notion of an overall LOA — the “low watermark” approach to determining LOA no longer applies. An application with IAL1 and AAL2 should not be considered any less secure or privacy- enhancing than an application with IAL2 and AAL2. The only difference between these applications is the amount of proofing required, which may not impact the security and privacy of each application. That said, if an agency incorrectly determines the x AL, security and privacy could very well be impacted.
After · SP 800-63-4
This section is normative.
The risk assessment results are the primary factor in selecting the most appropriate levels. This section details how to apply the results of the risk assessment with additional factors unrelated to risk to determine the most advantageous x AL selection.
First, compare the risk assessment impact profile to the impact profiles associated with each assurance level, as shown in Table 6-1 below. To determine the required assurance level, find the lowest level whose impact profile meets or exceeds the potential impact for every category analyzed in the risk assessment.
Table 6-1 Maximum Potential Impacts for Each Assurance Level
Assurance Level
Impact Categories 1 2 3
Inconvenience, distress or damage to standing or reputation Low Mod High
Financial loss or agency liability Low Mod High
Harm to agency programs or public interests N/A Low/Mod High
Unauthorized release of sensitive information N/A Low/Mod High
Personal Safety N/A Low Mod/High
Civil or criminal violations N/A Low/Mod High
In analyzing risks, the agency SHALL consider all of the expected direct and indirect results of an authentication failure, including the possibility that there will be more than one failure, or harms to more than one person or organization. The definitions of potential impacts contain some relative terms, like “serious” or “minor,” whose meaning will depend on context. The agency SHOULD consider the context and the nature of the persons or entities affected to decide the relative significance of these harms. Over time, the meaning of these terms will become more definite as agencies gain practical experience with these issues. The analysis of harms to agency programs or other public interests depends strongly on the context; the agency SHOULD consider these issues with care.
It is possible that the assurance levels may differ across IAL, AAL, and FAL. For example, suppose an agency establishes a “health tracker” application in which users submit personal information in the form of personal health information (PHI). In line with the terms of EO 13681 requiring “that all agencies making personal data accessible to citizens through digital applications require the use of multiple factors of authentication,” the agency is required to implement MFA at AAL2 or AAL3.
EO 13681 also requires agencies employ “an effective identity proofing process, as appropriate” when personal information is released. This does not mean that proofing at IAL2 or IAL3 (to match the required AAL) is necessary. In the above example, there may be no need for the agency system to know the actual identity of the user. In this case, an “effective proofing process” would be to not proof at all, therefore the agency would select IAL1. This allows the user of the health tracker system to be pseudonymous.
Despite the user being pseudonymous, the agency should still select AAL2 or AAL3 for authentication because a malicious actor could gain access to the user’s PHI by compromising the account.
Note: An agency can accept a higher assurance level than those required in the table above. For example, in a federated transaction, an agency can accept an IAL3 identity if their application is assessed at IAL2. The same holds true for authenticators: stronger authenticators can be used at RPs that have lower authenticator requirements. However, RPs will have to ensure that this only occurs in federated scenarios with appropriate privacy protections by the CSP such that only attributes that have been requested by the RP and authorized by the subscriber are provided to the RP and that excessive personal information does not leak from the credential or an assertion. See the privacy considerations in SP 800-63C for more details.
Note: The upshot of potentially having a different IAL, AAL, and FAL within a single application stems from the fact that this document no longer supports the notion of an overall LOA — the “low watermark” approach to determining LOA no longer applies. An application with IAL1 and AAL2 should not be considered any less secure or privacy- enhancing than an application with IAL2 and AAL2. The only difference between these applications is the amount of proofing required, which may not impact the security and privacy of each application. That said, if an agency incorrectly determines the x AL, security and privacy could very well be impacted.