The MFA box on your insurance renewal takes one answer. Your estate has at least three.
Push notifications for the service desk. TOTP for finance. Hardware keys for the four people with domain admin.
You tick "yes, MFA enforced" because the alternative is a call with the broker.
Then a federal customer sends a vendor security questionnaire that asks for an authentication assurance level instead of a yes, and now you have two answers on file that do not agree.
NIST SP 800-63-4 decides which one is defensible. It is guidance, not a checkbox, and it will not let you answer for the whole company at once.
What the July 2025 revision changed about how assurance levels are selected
The change log at the back of SP 800-63-4 is blunt. It substantially updates and reorganizes SP 800-63-3, with an expanded digital identity risk management process that "now defines protected online services, user groups, and impacted entities," additional assessments to tailor initial baseline control selections, added performance metrics, and new subsections on redress and on AI and ML in identity systems.
Three of those matter to the person filling in a questionnaire.
User groups became the unit of analysis. The impact assessment runs per user group, and the level is selected per user group. There is no single assurance level for "the company."
Tailoring became a documented step. The level you derive from impact is not the final level. It gets assessed for privacy, customer experience and threat resistance, and any modification has to be justified in writing.
The output became an artifact. The process terminates in a Digital Identity Acceptance Statement, which is what your customer's assessor should be asking for.
These controls "augment but do not replace or alter the information and information system controls determined under FISMA and the RMF," and federal relying parties "SHALL implement the DIRM process for all online services." The introduction adds that this version updates authentication risk and threat models for new attacks and provides new options for phishing-resistant authentication. That last clause is the one your underwriter has heard about.
IAL, AAL and FAL measure different things, and only one of them shows up on a questionnaire
The guidance separates three assurance levels, and Sec. 3.3.1 defines each by the failure it mitigates.
IAL is the robustness of the identity proofing process used to determine the identity of an individual, selected to mitigate identity proofing failures.
AAL is the robustness of the authentication process itself and the binding between an authenticator and a specific individual's identifier, selected to mitigate authentication failures.
FAL is the robustness of the federation process used to communicate authentication and attribute information to a relying party from an identity provider.
An underwriter's loss data is dominated by account takeover, so AAL is the one that ends up on the form. That is an observation about how the market underwrites, not a statement in the guidance.
The levels are not required to move together. Sec. 3.4.4 states that "the final implemented xALs do not all need to be at the same level," and Sec. 3.3.3 gives the worked example: an assessment can land on low impact indicating IAL1 and FAL1, and still determine that personal information is accessible and therefore requires AAL2.
You can legitimately be IAL1 and AAL2 at once. If your questionnaire answer implies otherwise, an assessor will find it.
The impact-to-assurance mapping in Sec. 3.3.3 is deterministic once you have the impact rating
The mapping is the easy part. Sec. 3.3.3.2 sets out a simple mapping for authentication: low impact selects AAL1, moderate selects AAL2, high selects AAL3.
Identity proofing follows the same shape in Sec. 3.3.3.1: low to IAL1, moderate to IAL2, high to IAL3. IAL2, per Sec. 3.3.2.1, "requires collecting additional evidence and a more rigorous process for validating the evidence and verifying the identity." Federation runs low to FAL1, moderate to FAL2, and high to FAL2 or FAL3, with a further assessment at high impact to evaluate the risk of a compromised identity provider.
There is a floor that is easy to miss. Sec. 3.3.3.2 cites Executive Order 13681, which states that "all organizations making personal data accessible to citizens through digital applications require the use of multiple factors of authentication," and the guidance reads that as requiring "a minimum selection of AAL2 for applications that meet those criteria."
The work is upstream of the mapping. The sequence that produces a defensible level:
- Define the online service. Functional scope, the user groups it serves, the transactions available to each group, and the data those interfaces process.
- Run the impact assessment per user group. The transactions available to a group drive its rating, not the sensitivity of the system as a whole.
- Determine the combined impact level for each user group. This is the input to everything downstream.
- Apply the mapping. Low to AAL1, moderate to AAL2, high to AAL3, per group.
- Tailor. Assess privacy, customer experience and threat resistance, then add compensating or supplemental controls where the baseline does not fit.
- Write the Digital Identity Acceptance Statement. Initial assessment, assessed levels, any tailored level with rationale, and every compensating and supplemental control.
Sec. 3.3.3 requires this be governed, not improvised: organizations "SHALL develop and document a process and governance model for selecting initial assurance levels and controls." The selection duty is explicit - the organization SHALL document whether authentication is needed for the online service and, if it is, SHALL select an initial AAL for each user group.
"MFA everywhere" is not the same claim as AAL2, and AAL3 starts at the private key
This is where over-claiming happens.
Sec. 3.3.2.2 describes AAL2 as requiring "proof of the possession and control of two distinct authentication factors" through secure authentication protocols, with approved cryptographic techniques. Table 2 summarizes the AAL2 control objective as "Require multifactor authentication. Offer phishing-resistant options."
Note the verb. AAL2 offers phishing-resistant options. It does not require them.
AAL3 does. Sec. 3.3.2.2 states that "AAL3 authentication requires the use of a public-key cryptographic authenticator with a non-exportable private key that provides phishing resistance," based on proof of possession of a key through a cryptographic protocol and either an activation factor or a password. Table 2 gives the AAL3 objective as "Require phishing resistance and verifier compromise protections."
Two words carry the distinction: non-exportable. A software certificate a user can copy out of a keystore does not meet the description. Neither does a push-approval prompt or an OTP a user can be talked into reading aloud.
AAL1, by contrast, permits either single-factor or multi-factor authentication across a wide range of technologies.
What breaks
The failure mode is not the primary login path. It is everything routed around it.
Your SSO enforces hardware keys. Your break-glass accounts do not. Your legacy mail protocol still accepts a password. Your contractor tenant runs on a separate identity stack nobody mapped. Your CI/CD service principals authenticate with long-lived secrets and are, on paper, a user group.
Because levels are selected per user group, an unmapped group is not a rounding error. It is a group with no documented level at all. "AAL2 across the organization" is falsified by a single population you never assessed, and that surfaces in a claim investigation or a customer audit, both of which happen after you made the statement.
Run the enumeration before you answer.
The Digital Identity Acceptance Statement is the artifact your customer should be asking for
Sec. 3.4.4 opens with a duty: "Organizations SHALL develop a Digital Identity Acceptance Statement (DIAS)" documenting the results of the risk management process for each online service the organization manages, and for each external online service used to support the mission, "including software-as-a-service offerings (e.g., social media platforms, email services, online marketing services)."
Read that scope twice. It covers the SaaS you consume, not only what you sell.
At a minimum it includes the initial impact assessment results, the initially assessed levels, the tailored level and rationale where it differs, all compensating controls with their comparability or residual risks, and all supplemental controls. Federal agencies SHOULD include this in the information system authorization package.
There is a supply-chain clause too. Relying parties who intend to use a particular credential service provider or identity provider SHALL review that provider's DIAS and incorporate relevant information into their own. Sec. 3.4 states the duty from the other side: as part of tailoring, organizations SHALL review the acceptance statements and practice statements from providers they use or intend to use.
Your DIAS is a document your federal customers are directed to read. Build it once and it answers the AAL question for every buyer, which is the argument for treating third-party risk as an evidence exchange rather than a spreadsheet.
Compensating and supplemental controls are how you stay honest at a lower level
Not every population can carry the baseline. Sec. 3.4.2 defines a compensating control as one "employed by an organization in lieu of a normative control (i.e., SHALL statements) in the defined xALs," intended to address the same risks as the control it replaces.
The price is documentation. Organizations SHALL document the compensating control, the rationale for the deviation, the comparability of the chosen alternative, and any resulting residual risks. Providers that implement compensating controls SHALL communicate this to all potential relying parties before integration.
Supplemental controls run the other direction. Sec. 3.4.3 covers additions that strengthen the baseline, and one of its own examples answers half the questionnaires you will receive: "An organization could restrict users to only phishing-resistant authentication at AAL2." Supplemental controls SHALL be assessed on the same basis as the tailoring and SHALL be documented.
That gives you a precise, true sentence for a form with room for a checkbox: AAL2 with a supplemental control restricting the population to phishing-resistant authenticators. Stronger than "MFA enforced," and traceable to a section number.
One nuance operators get wrong: tailoring is mandatory, changing the level is not. The guidance notes that while organizations are required to implement and document a tailoring process, it "does not require the initial assurance levels or control sets to be modified as a result."
How to answer the AAL question on a questionnaire without over-claiming
Underwriting practice is not in the guidance, so treat this as field advice rather than a cited requirement. The pattern that survives scrutiny:
Name the scope. "For the customer-facing portal and the administrative console," not "for the organization."
Answer per user group. End users at one level, privileged administrators at another.
Give the level plus the tailoring. "AAL2, with a supplemental control restricting privileged users to phishing-resistant authenticators" is more accurate than either "AAL2" or "AAL3."
Do not claim AAL3 unless every authenticator in that population uses a non-exportable private key. The description is specific enough to disprove.
Offer the acceptance statement. It converts an assertion into evidence.
Then keep it true. Sec. 3.5 requires a documented continuous evaluation and improvement program, "including the metrics that are collected, the sources of data required to enable performance evaluation, and the processes in place for taking timely actions," plus monitoring of the evolving threat landscape and regular assessment of security and fraud detection effectiveness. Sec. 3.5.1 adds that relying parties SHALL document their metrics, reporting requirements and data inputs for any provider or integrated identity service.
That is next year's renewal answer, already assembled. The audit pack is a query, not a project.
If your assurance levels, the controls behind them and the acceptance statement live in three systems, renewal is a scramble every year. Aigis GRC maps your organizational profile to the obligations that actually apply, every one traced to a verbatim quote from the source text. Source-grounded, not generated. See how it works for cyber insurance attestations, or look at the platform.
FAQ
Does enforcing MFA on all users mean we are at AAL2?
Not automatically. Sec. 3.3.2.2 requires proof of possession and control of two distinct authentication factors through secure authentication protocols, with approved cryptographic techniques, and it has to hold for the user group you are claiming it for. Any population with a bypass path needs its own assessment.
Where is the line between AAL2 and AAL3?
The private key. Sec. 3.3.2.2 states that AAL3 requires a public-key cryptographic authenticator with a non-exportable private key that provides phishing resistance, which Table 2 pairs with verifier compromise protections. AAL2's summarized objective is to require multifactor authentication and offer phishing-resistant options.
Do IAL and AAL have to match?
No. Sec. 3.4.4 states that the final implemented levels do not all need to be at the same level, and Sec. 3.3.3 gives the example of a low-impact assessment indicating IAL1 while accessible personal information drives AAL2.
We are a SaaS vendor, not a federal agency. Does the acceptance statement apply to us?
The duty in Sec. 3.4.4 is written for organizations and covers external online services used to support the mission, including software-as-a-service offerings. Federal relying parties are directed to review a provider's statement and incorporate it into their own. In practice your federal customers will ask for yours, whether or not you carry the obligation directly.
