eAuthentication: Choosing the Right Identity Assurance Level
Key Takeaways
- Teams default to "MFA = done" without understanding that IAL, AAL, and FAL are three independent decisions, each based on actual risk.
- Current CISA guidance is pushing federal systems toward phishing-resistant MFA — which sits at the AAL2/AAL3 boundary, not basic two-factor.
- Assigning a level isn't enough — it has to be documented and reflected in your SSPP, or it doesn't exist as far as an assessor is concerned.
Every system that asks someone to authenticate is making a risk decision, whether or not anyone treats it that way. eAuthentication — governed by NIST SP 800-63 — breaks that decision into three independent levels: how confident you are in someone's identity (IAL), how hard their login is to fake (AAL), and how much you trust an outside login via federation (FAL). The organizations that get this wrong almost never do so through negligence; they do it by treating "we have MFA" as a finished sentence, when MFA alone doesn't specify which of the three levels actually apply. If your access controls have never been tied to a documented IAL/AAL/FAL decision, that gap is worth closing before an assessor finds it.
Busy executives can stop here. The full guide below is for the team assigning the actual levels.
The Full Guide
eAuthentication ensures that users are who they claim to be — but "ensures" is doing a lot of work in that sentence. The actual standard, NIST SP 800-63, doesn't give you one dial to turn. It gives you three independent levels, each answering a different question, each requiring its own deliberate decision.
The Three Levels
- IAL — Identity Assurance Level. How confident are you this person is real? IAL1 is low confidence; IAL3 requires in-person verification with actual documents.
- AAL — Authenticator Assurance Level. How hard is it to fake their login? AAL1 is single-factor; AAL3 is hardware-based.
- FAL — Federation Assurance Level. How much do you trust an outside login, via SSO or a third-party identity provider?
"We have MFA" is not an eAuth decision — it's a fragment of one. MFA could mean AAL2 (password plus a text code) or something much closer to AAL3 (hardware security key), and current CISA guidance is specifically pushing federal systems toward the latter — phishing-resistant MFA, which sits at the AAL2/AAL3 boundary, not basic two-factor.
How to Actually Assign These Levels
- Identify the role or transaction — who's accessing what, and for what purpose.
- Analyze the risk of misidentification for that specific role or transaction.
- Assign IAL, AAL, and FAL independently, based on that risk — not as a bundle.
- Document the rationale, not just the levels chosen.
That last step is where the real exposure lives. A level assigned without documented reasoning is a level nobody can defend when an assessor asks "why AAL2, not AAL3?"
A Concrete Comparison
Public Comment Form
No sensitive data, low stakes. Reasonably lands at IAL1, AAL1, FAL1 — low assurance, appropriately.
Patient Health Records
IAL2–3, AAL2–3, FAL2–3 — high assurance across all three, driven by what's actually at risk.
Same framework, very different outcomes — because the actual risk is different, not because someone picked a stricter default.
Where Teams Get This Wrong
- Over-assigning IALs "to be safe," without a documented risk basis — wastes effort and budget in the opposite direction.
- Treating any MFA as automatically AAL2 or higher without verifying the actual method used.
- Selecting levels without writing down the rationale behind them.
- Never revisiting levels as roles or transactions change over time.
Why This Ripples Forward
Documented IAL, AAL, and FAL levels have to be reflected in your SSPP and system risk assessments. Implementing the right level technically isn't enough — if it isn't captured in documentation, it doesn't exist as far as an assessor is concerned.
Where to Go From Here
The honest test: for your highest-risk roles or transactions, can you name the specific IAL, AAL, and FAL assigned — and explain why, in writing? If the answer is "we just have MFA," that's worth fixing before anything downstream gets built on top of it.
eAuth Decision Worksheet
A fillable PDF that walks you through assigning IAL, AAL, and FAL levels role by role — with a dedicated rationale field for each, and a direct link to NIST SP 800-63.
Choose Your Next Step
Download the Worksheet
Self-serve level assignment, guided role by role, with NIST SP 800-63 referenced throughout.
Get the TemplateTalk to MS Capital
Have someone who's carried the accountability for this call before get it right the first time.
Book a Discovery Call