If your app touches EPIC data or serves patients tied to a federal program, someone on your team has probably typed nist digital identity guidelines into a search bar at some point. The NIST SP 800-63 guidelines are the federal government's rulebook for proving who a user is online, and health tech vendors run into them constantly when a health system's security team asks how identity is verified before data ever reaches FHIR endpoints.

This article walks through what SP 800-63 actually requires: the three levels of identity assurance, the separate track for authenticator assurance, and how federal agencies and their vendors are expected to implement each piece. You'll see where the standard applies, where it doesn't, and how it differs from HIPAA or SOC2 controls you may already have in place.

We wrote this from the vendor side of EPIC integrations, where identity assurance questions come up during security review right alongside SMART on FHIR and OAuth scopes. By the end, you'll know which assurance level applies to your use case and what documentation your compliance team needs to satisfy an auditor or a health system's IT department.

Why the NIST digital identity guidelines matter

NIST published SP 800-63 as Special Publication guidance, not a law. Federal agencies must follow it under OMB Memorandum M-19-17, but the real-world reach goes far beyond federal systems. Health systems, state Medicaid programs, and cloud vendors serving government contracts all point back to these guidelines when they ask a vendor how identity gets verified before any clinical data moves. If you're building an EPIC-integrated app that touches patient data tied to a federal program, expect a security reviewer to reference SP 800-63 by name, even if your company never signs a contract with a federal agency directly.

Health systems adopted this framework because it gives them a shared vocabulary for identity risk. Before SP 800-63, every hospital security team had its own informal standard for what counted as "verified enough." Now a CISO can say "we require IAL2 for provider onboarding" and every vendor in the room knows exactly what that means: government ID verification, biometric or knowledge-based matching, and a documented chain of evidence. That shared language speeds up security review, which matters when your EPIC Showroom listing is sitting in a queue waiting for sign-off.

If you can't state your identity assurance level in one sentence, your security review will take longer than it needs to.

Skipping this step creates real exposure. A digital health vendor that can't answer "what assurance level does your login flow meet" during a health system's vendor security questionnaire will stall the deal, sometimes for months. Compliance teams increasingly treat SP 800-63 alignment as a proxy for maturity, similar to how a SOC2 report signals operational discipline. Get this wrong and you're not just failing an audit checkbox, you're signaling to a hospital IT department that your identity verification process was never designed with intention.

VectorCare's SMART on FHIR apps run inside EPIC's own OAuth and identity layer, so a lot of the assurance-level burden shifts to EPIC's infrastructure rather than sitting entirely on your app. But you still need to understand where responsibility lands, because auditors ask specific questions and "EPIC handles it" isn't always the full answer they're looking for.

How to apply IAL, AAL, and FAL assurance levels

SP 800-63 splits identity into three separate tracks, and mixing them up is the fastest way to fail a security review. Identity Assurance Level (IAL) covers how confident you are that a real person is who they claim to be during enrollment. Authenticator Assurance Level (AAL) covers how confident you are that the person logging in today is the same person who enrolled. Federation Assurance Level (FAL) covers how trustworthy the assertion is when identity gets passed between systems, which matters a lot once EPIC's SMART on FHIR layer sits between your app and the end user.

Each track runs on its own three-tier scale, and picking the right tier depends on what happens if identity fails.

Pick your assurance level based on the harm a bad login could cause, not the level that sounds impressive on paper.

Most EPIC-integrated apps land at IAL2 and AAL2, with FAL2 covering the federation piece since EPIC's identity provider issues the signed assertions your app consumes. Document which tier applies to each track separately, because auditors will ask for all three.

What SP 800-63A, 63B, and 63C each require

The full NIST digital identity guidelines split into three companion documents, and each one governs a different part of the identity lifecycle. Reviewers rarely cite "SP 800-63" alone, they point to the specific sub-document that covers whatever piece of your app is under scrutiny, so knowing which one applies to your login flow saves a lot of back-and-forth during a security questionnaire.

SP 800-63A: Enrollment and Identity Proofing

SP 800-63A governs how you verify a person is real before you ever hand them credentials. It sets the evidence requirements behind each IAL tier, covering acceptable ID documents, biometric comparison methods, and how long you keep proofing records for audit purposes.

SP 800-63B: Authentication and Lifecycle Management

SP 800-63B covers everything that happens after enrollment: password rules, multi-factor requirements, session timeouts, and credential recovery. This is the document your AAL tier maps to, and it's the one most EPIC-integrated vendors spend the most time reviewing since it directly shapes login architecture.

SP 800-63C: Federation and Assertions

SP 800-63C handles what occurs when identity gets passed between systems through SAML or OAuth assertions, which is exactly the model SMART on FHIR apps use inside EPIC.

The document that matters most to your build is whichever one governs the step where identity actually fails if something goes wrong.

Understanding this split lets your team answer audit questions with precision instead of pointing vaguely at "NIST compliance" as a blanket claim.

Common pitfalls when implementing the guidelines

Teams building against SP 800-63 tend to trip on the same handful of mistakes, and most of them come from treating the guidelines as a single checkbox instead of three separate tracks. Watch for these before your next security review:

• Conflating IAL and AAL. Verifying someone's identity at enrollment doesn't say anything about how strong their login is today. A vendor claiming "we're NIST compliant" without naming both levels usually hasn't separated the two.
• Skipping FAL when EPIC handles authentication. Just because EPIC's identity provider issues the assertion doesn't mean your app is off the hook. You still need to document how you validate that signed token.
• Overbuilding for low-risk workflows. Forcing IAL2 proofing onto a low-risk patient portal adds friction and cost with no security benefit. Match the tier to actual harm, not to whatever sounds most rigorous.
• Underbuilding for clinical data. The opposite mistake, running AAL1 single-factor login on an app that touches PHI, is the one that gets flagged fastest in a health system's vendor questionnaire.

The most common failure isn't picking the wrong assurance level, it's never documenting which level you picked.

Compliance teams that skip documentation lose the most time, since auditors can't verify a level that was never written down, and reviewers default to assuming the weakest possible posture when evidence is missing. Write down your IAL, AAL, and FAL tiers the same way you'd document a HIPAA risk assessment, because that's exactly how a health system's security team will treat it.

Putting the guidelines into practice

Getting SP 800-63 right comes down to three decisions: pick your IAL tier based on how much harm a fake identity could cause, pick your AAL tier based on how much harm a stolen login could cause, and document both before an auditor asks. Federation adds a fourth piece, but if EPIC's identity provider is issuing your assertions, most of that burden already sits upstream of your app.

None of this requires a dedicated compliance engineer if you build on infrastructure that already handles the assurance mapping for you. That's the whole point of a managed SMART on FHIR platform: the identity, OAuth, and FHIR plumbing are solved once, correctly, instead of re-solved by every vendor who wants an EPIC listing.

If you'd rather spend your engineering time on your actual product than on assurance-level paperwork, build and deploy your SMART on FHIR app with VectorCare and let the platform carry the identity compliance weight for you.