NIST's IAL3 requirements are public. Anyone can read them. An agency, cloud provider, defense contractor, or any other organization can implement them with its own people and systems, hand the work to an external credential service provider (CSP), or split it between the two. NIST SP 800-63-4 expressly recognizes that assurance controls may be implemented by an external CSP or identity provider, so outsourcing is an architecture choice — not the definition of conformance.
NIST also does not issue an “IAL3 certified” product certificate, and it does not name a commercial trust mark as a condition of conforming to SP 800-63A-4. The standard defines outcomes, processes, records, and performance requirements. A team that implements those requirements and can substantiate them is not disqualified because it built the capability itself.
Our own experience is a useful real-world test of that. Trust Swiftly has supported a growing portfolio of independent customer implementations, spanning multiple third-party assessment organizations (3PAOs) and agency contexts. Across those programs, reviewers looked at the actual NIST control implementation: the proofing pathway, the operating procedures, the shared responsibilities, the exceptions, and the evidence. We have not encountered a FedRAMP High or defense authorization review that treated a named third-party IAL3 certificate as the prerequisite for satisfying the NIST control.
We treat that repeated scrutiny as the more meaningful validation. The same platform has had to hold up across different authorization boundaries, assessors, deployment models, and evidence requests. It does not tell you what every solicitation or nonpublic contract says — each program's governing procurement documents still control — but it does show why an operating record across independent customers is more informative than a standalone label.
So the honest build-versus-buy question was never “Who is allowed to do IAL3?” It is: Who will own the complete proofing operation, keep it effective as threats and technologies change, and produce evidence that the relying organization, assessor, and authorizing official can defend?
The short version: You do not need a vendor's private permission to implement NIST's public IAL3 requirements. What you do need is an evidence-backed system that keeps working through ambiguous source results, provider outages, model drift, human-review decisions, controlled-device state, shipment exceptions, privacy obligations, and audit requests. Buying changes who operates those systems. It does not change the control, and it does not guarantee an Authority to Operate (ATO).
The Control Is Public; the Implementation Is What Gets Tested
Three forms of assurance get collapsed into one in most sales conversations. They are materially different:
- NIST conformance: SP 800-63A-4 defines what an identity proofing and enrollment service must do at IAL3. It does not designate a preferred supplier or require a NIST-issued vendor certificate.
- Independent evidence: A laboratory report, external assessment, or other independent review can be valuable evidence. How valuable depends entirely on scope — the exact service, revision, proofing pathway, operating environment, and period assessed.
- Operational validation: Repeated use across independent customers, 3PAOs, agencies, and authorization boundaries tests whether the deployed service and its evidence hold up beyond a single point-in-time review.
All three feed the same evidence review, and the authorization decision sits at the end of it. A buyer is free to add qualifications beyond the NIST baseline, so the solicitation, contract, and agency policy always govern. And because no provider can see every public and nonpublic acquisition, sweeping claims about what no buyer has ever required are not supportable — ours included. That procurement caveat is a different thing from claiming that NIST itself requires a private IAL3 certificate.
The same distinction matters in federal authorization. Under the NIST Risk Management Framework, the authorizing official decides whether the system's security and privacy risk is acceptable. In a FedRAMP assessment, an independent assessor evaluates the cloud service's control implementation, and the agency makes its own ATO decision. FedRAMP's current identification and authentication guidance associates its highest certification class with level 3 digital identity requirements, but no private IAL3 label converts into an ATO.
A sound procurement looks at the deployed workflow, the shared responsibilities, the operating record, and the evidence. Read any external assessment inside its actual scope instead of treating it as a substitute for that review.
What an IAL3 Operator Actually Has to Own
The final SP 800-63A-4 is much more than a document-capture flow. Nine workstreams have to run at once, and each one feeds the others.
The table below separates the normative baseline from the recurring work of keeping each of them reliable. Read the last column as operating implications, not as a claim that every example is a literal NIST SHALL.
| Workstream | What the NIST baseline requires | What operational ownership looks like |
|---|---|---|
| Governance and practice statement | The CSP operates under documented procedures covering 16 areas, including accepted evidence, technologies, sources, exceptions, fraud, reverification, privacy, service changes, retention, metrics, and death or incapacity. The practice statement must be available to relying parties. | Named owners, version control, change review, customer communication, legal and privacy review, and evidence that practice matches production. |
| Evidence and attribute validation | IAL3 collects one FAIR plus one STRONG piece of evidence, two STRONG pieces, or one SUPERIOR piece. Core attributes are validated against authoritative or credible sources, or through valid digital signatures on SUPERIOR evidence. | Evidence-path design, source contracts, normalization, jurisdiction coverage, consent, outage handling, duplicate-call prevention, reason codes, and manual review for ambiguous results. |
| On-site attended ceremony | IAL3 is only delivered as on-site attended proofing. The proofing agent may be co-located with the applicant or participate remotely through a CSP-controlled kiosk or device. | Secure locations, appointment and queue management, agent assignment, device state, capture sequencing, accessibility accommodations, session recovery, and fraud escalation. |
| Controlled kiosk or device | For the kiosk-based path, all digital validation and verification of evidence must be performed by integrated scanners and sensors. Devices must be safeguarded from tampering through observation or monitoring plus physical and digital tamper-prevention features; protected by baseline security controls comparable to at least FISMA Moderate, including malware protection, administrator-specific access controls, and software update processes; and inspected periodically by trained technicians. | Provisioning, patching, configuration baselines, device identity and hardware attestation, inventory, monitoring, repair, inspection records, dispatch and return workflows when equipment travels. |
| Biometrics | IAL3 collects and retains a biometric sample. Biometric use requires informed consent, public use and deletion information, periodic testing of recognition and attack-detection algorithms by independent entities, operational testing, demographic-performance controls, and publicly available results. Remote collection and comparison also requires presentation attack detection meeting NIST's stated threshold, and all PAD testing must conform to ISO/IEC 30107-3:2023. | Capture quality, model and threshold governance, choice of independent laboratory or public benchmark (NIST's FATE and FRTE evaluations, for example), false-accept and false-reject analysis, manual review, accessibility, provider-change assessment, consent records, protected storage, retention, and deletion. |
| Proofing agents | Agents are trained to identify manipulation, coercion, and social engineering. Agents performing visual facial comparison or physical-evidence inspection need documented training, assessment, annual reassessment, and appropriate tools. | Hiring and access controls, training data, scheduling, quality review, segregation of duties, race-safe case assignment, decision reasons, escalations, and coverage during demand spikes. |
| Fraud and redress | The CSP maintains a documented fraud program, victim self-reporting and investigation capability, a death-record check for every proofing process, ongoing effectiveness monitoring, fraud signaling to relying parties, and usable redress. | Multi-signal rules, investigations, false-positive analysis, appeals, incident coordination, insider-collusion controls, source degradation monitoring, and safe failure modes. |
| Authenticator binding | The initial authenticator is distributed or enrolled during an on-site attended interaction. If registration occurs outside one authenticated protected session, the CSP compares a fresh biometric sample with the sample retained from proofing before registration. | Coordination with the customer's identity provider, authenticator inventory or attestation, protected handoff, binding logs, delayed-enrollment controls, loss and recovery procedures, and downgrade prevention. |
| Subscriber and audit records | The account records the evidence type and issuer, proofing type, validation and verification methods, exceptions, maximum IAL achieved, consent, attributes, and bound authenticators. | Data minimization, restricted artifact access, integrity protection, signed or otherwise verifiable decisions, schema and report versioning, retention, export monitoring, and assessor retrieval. |
| Continuous evaluation | The organization documents a continuous improvement program, monitors threats and fraud tactics, and measures outcomes such as pass, fail, abandonment, step failure, and completion time. | Dashboards, release gates, fraud feedback, retraining, capacity planning, customer-experience testing, control tuning, and documented responses to material changes. |
The source text matters here. SP 800-63A-4's general identity proofing requirements hold the governance, fraud, privacy, biometric, evidence-validation, forged-media, and exception controls. Its IAL3 section holds the evidence, attended-session, controlled-device, notification, and binding requirements. The subscriber-account section defines the records that tie the proofing event to the subscriber and their authenticators.
Two qualifications keep that table honest:
- NFC is not a universal IAL3 requirement. It is a strong way to validate chip-enabled evidence, and digitally signed SUPERIOR evidence does require signature validation, but NIST permits multiple evidence and validation pathways.
- Shipping and reverse logistics are not universal requirements either. They enter the control environment when the implementation uses portable CSP-controlled devices for distributed applicants. A fixed enrollment center has a different physical operating model.
Why a Correct Demo Is Not Yet a Proofing Service
The workflow users see is the front edge of the system. Whether it holds up in production comes down to how the operator handles the conditions that never show up in a happy-path demonstration.
An authoritative-source response is not a Boolean
A name or license check can come back as a confirmed match, a partial match, a mismatch, an unsupported jurisdiction, a maintenance window, a timeout, an interrupted request you were still billed for, an invalid configuration, or a result whose status is genuinely unknown. Treat every non-match as a denial and you punish legitimate applicants. Treat every error as a pass and you have defeated the control.
A mature implementation keeps those distinctions intact, prevents duplicate billable calls, records rerun lineage, retries only when a retry is safe, and routes uncertain outcomes to a defined review or alternate path. Our analysis of AAMVA and DMV verification tradeoffs works through this in detail. The same pattern shows up in carrier, financial, vital-record, and other source integrations.
Biometric performance has to survive production conditions
NIST's biometric requirements include periodic testing by independent entities, performance assessment under conditions substantially similar to the operating environment, 1:1 false-match and false-non-match thresholds, demographic testing, presentation attack detection tests conformant to ISO/IEC 30107-3:2023, and publicly available results. None of that reduces to “we integrated a face API.”
Lighting, camera position, accessibility needs, device changes, population mix, and model updates all move the numbers in production. Operators have to read false accepts, false rejects, inconclusive outcomes, coverage, and human-review load together, because tuning one of them moves the others. At Trust Swiftly, uncertainty is a first-class outcome: when signals disagree or the evidence is thin, the case goes to manual review instead of being rounded up into false confidence.
Human review needs an operating system, not a shared inbox
Attended proofing and exception handling create queues, and queues need plumbing. Every case needs an owner, timestamps, decision reasons, access boundaries, escalation paths, and protection against two reviewers overwriting one another. Service levels have to measure the oldest waiting case and the quality of the decisions, not just average handling time.
The team also needs a defensible answer when an applicant lacks the expected evidence, a source is down, a biometric comparison is inconclusive, or an accessibility barrier blocks the standard path. NIST requires documented exception and redress processes precisely because these are normal operating conditions, not rare bugs.
A controlled device becomes a fleet
A kiosk-based IAL3 session has state: prepared, assigned, in session, completed, failed, expired, or cancelled. The system has to know which agent controls the ceremony, whether the intended managed device is actually present, whether a capture came from that device, and what happens after a disconnect or a retry.
Once devices move between locations, that state machine grows to include inventory, outbound transit, delivery, assignment, return, inspection, loss, damage, stale tracking, and reconciliation. An applicant who has not scheduled, a carrier exception, and a device that should no longer be trusted can look identical from a dashboard. The implementation has to tell them apart.
Evidence has its own lifecycle
An application log that says verified=true does not reconstruct a proofing ceremony. The decision has to link back to the pathway, the evidence, the validation and verification methods, consent, the agent's action, controlled-device context, the binding event, and any exception. At the same time, copying raw documents and biometrics wholesale into an authorization package creates privacy and breach exposure nobody asked for.
Trust Swiftly keeps three things apart: reusable control documentation, a signed and data-minimized decision layer, and tightly controlled underlying artifacts. Customers and assessors can verify origin and integrity without raw identity data being handed to every person and system that consumes the decision. Our guide to machine-readable IAL3 evidence covers the limits as well as the benefits: a signed assertion proves its source and integrity, but substantive assessment still comes back to the procedure and the supporting evidence.
This is why IAL3 is not a set-and-forget control. NIST itself requires organizations to continuously evaluate performance, monitor changing threats, and take timely action.
Build, Buy, or Use a Hybrid Model
All three models can be the right answer. Which one depends on mission, scale, geography, data constraints, internal capability, and time — not on who has the best badge or the loudest sales claim.
| Model | Strong fit when | Advantages | Risks to plan for |
|---|---|---|---|
| Build internally | Proofing is a strategic capability; volume is sustained; the organization can staff security, privacy, biometrics, agents, hardware, fraud, and evidence operations for the long term. | Maximum design control, direct integration, internal data governance, and the ability to optimize deeply for one population and mission. | High fixed cost, specialist hiring, source and laboratory dependencies, longer learning curve, operational concentration, and full ownership of assessment findings and control drift. |
| Buy a managed service | The population is bounded or bursty; users are distributed; the authorization schedule is tight; specialized agents, devices, source access, or evidence tooling would otherwise be created for one program. | Faster access to an existing operation, variable capacity, reusable procedures and integrations, and one accountable service boundary. | Vendor dependency, scope mismatch, data-transfer and retention concerns, service availability, opaque subcontractors or models, integration work, and the possibility that a provider's evidence does not match the customer's authorization boundary. |
| Hybrid | The organization wants to retain policy, identity-provider, access, recovery, and authorization decisions while delegating the proofing ceremony or selected components. | Keeps mission decisions in-house while using specialist capacity; supports phased adoption and avoids rebuilding every component. | Shared-responsibility gaps, duplicated tooling, unclear incident ownership, inconsistent records, and weak handoffs between proofing, authenticator binding, and access enforcement. |
Building is most defensible when identity proofing is itself the product, when sovereignty or classified-environment constraints rule out an external service, or when stable scale can support a permanent multidisciplinary operation. Buying is often more economical for a workforce measured in hundreds, or for a rollout compressed around an assessment deadline — but let a cost model reach that conclusion, not a slogan.
The hybrid model gets overlooked more often than it should. NIST allows the functions to be distributed. A customer can keep risk selection, the Digital Identity Acceptance Statement (DIAS), its identity provider, AAL/FAL enforcement, the authorization package, recovery policy, and the final access decision, while a specialist runs the attended proofing and returns the evidence. The one non-negotiable is that the boundary be explicit enough that no requirement disappears into the gap between two diagrams.
Use a Full-Cost Model, Not a Per-API Estimate
A credible comparison prices fixed, variable, and risk costs together:
Year-one build cost = design and assessment + integrations and testing + controlled equipment + staffing and training + recurring operations + per-proofing costs + contingency
At minimum, estimate:
- policy, DIAS, practice-statement, privacy, legal, accessibility, and threat-model work;
- proofing application, device software, identity-provider integration, authenticator binding, evidence export, and recovery flows;
- biometric and document technology, independent and operational testing, authoritative or credible source access, and provider minimums;
- controlled devices, peripherals, secure configuration, inventory, inspection, replacement, facilities, and logistics where applicable;
- proofing agents, supervisors, fraud analysts, support, training, annual reassessment, quality review, and peak coverage;
- monitoring, incident response, redress, source outages, model changes, fraud investigations, release validation, and audit support;
- applicant retries, abandonment, accessibility accommodations, manual review, damaged or missing equipment, and reproofing; and
- the opportunity cost of delayed remediation or authorization.
Model normal demand and rollout peaks separately. A system with acceptable average capacity can still miss an authorization milestone when an entire cohort arrives in the same week. And test the economics against a realistic denominator: completed, defensible proofings — not invitations sent or API calls attempted.
Ask vendors for the same complete model. A low unit price often leaves out attended-agent time, shipping, retries, evidence retention, source charges, implementation, authenticator binding, and assessment support. A fair buy analysis includes all of it, and prices the work the customer still owns.
Buying Does Not Outsource Your ATO
No identity proofing provider can grant your ATO or absorb your digital identity obligations. The relying organization still determines the applicable assurance levels, documents tailoring and compensating controls, configures access, evaluates the provider, and decides what a proofing result actually does to an account.
At a minimum, the shared-responsibility boundary should cover this much:
| Owner | Responsibilities that remain visible |
|---|---|
| Customer or relying party | Risk assessment and DIAS; in-scope populations and roles; IAL/AAL/FAL decisions; identity-provider and access policy; approved evidence paths; authenticator and recovery policy; acceptance of residual risk; evidence retention in its package; final account and authorization decisions. |
| Proofing provider | The contracted proofing workflow; practice statement; agent and device controls; evidence and attribute validation; biometrics; fraud checks; decision records; service metrics; change notices; redress support; and protection of provider-held data. |
| Shared | Privacy notices and consent; applicant communications; incident and fraud reporting; exception handling; accessibility; authenticator handoff; source or model changes; evidence access; retention and deletion; business continuity; and assessment response. |
| Assessor and authorizing official | The assessor evaluates the scoped implementation and evidence. The authorizing official accepts or rejects the system risk. Neither role operates the customer's day-to-day control. |
NIST reinforces the split. Relying parties review a provider's practice statement and DIAS, periodically review the provider's fraud program and controls, and define the metrics and reporting they need from external identity services. Buying replaces a body of operating work. It does not replace governance.
Questions to Ask Any IAL3 Provider—including Trust Swiftly
The way to evaluate a provider is to test the service boundary and the evidence, not the marketing adjective in front of “IAL3.” Ask us these too.
- Map the deployed pathway to the current standard. Which SP 800-63A-4 requirements apply, which implementation choices satisfy them, and which responsibilities remain with us?
- Scope every external assurance claim. Who assessed what service; against which revision and criteria; on what date; for which proofing path; and in which operating environment? Is it required by our acquisition route, or offered as supporting evidence?
- Provide the practice statement. NIST requires it to be available to relying parties. Does it cover all 16 required areas, including source and algorithm changes, exceptions, reverification, retention, metrics, and service closure?
- Show biometric evidence. Public independent results; operational test results; demographic performance; fixed-threshold configuration; and ISO/IEC 30107-3 PAD test evidence where remote collection applies. Explain what triggers reassessment after a material change.
- Show the attended-session and device model. Is the agent co-located, or remote through a controlled device? How are device identity, integrated sensors, tamper safeguards, configuration, inspection, reassignment, and session failures evidenced?
- Show the agent program. Training and assessment procedures, annual reassessment records for applicable visual tasks, quality controls, fraud escalation, access restrictions, and segregation of duties.
- Explain sources and failure states. Which evidence and attributes are supported? Which sources are authoritative or credible? How are a mismatch, no record, unsupported jurisdiction, outage, timeout, and unknown provider outcome each handled differently? How is the universal death-record check implemented?
- Walk through exceptions, accessibility, and redress. What happens when a legitimate applicant lacks the expected evidence, cannot use the default biometric path, needs an accommodation, or disputes a decision?
- Demonstrate authenticator binding and recovery. How does the proofed person become linked to the exact authenticator? What changes if enrollment is delayed? Can recovery or a help-desk action silently reduce the assurance achieved?
- Produce a sample evidence package. Can an assessor determine the proofing type, evidence, methods, agent action, consent, exceptions, IAL, and binding event without broad distribution of raw biometrics and documents? How is integrity verified later?
- Show continuous-improvement evidence. What metrics are monitored, how are fraud and customer feedback incorporated, and how are customers told about material changes to a source, model, device, or process?
- Put the boundary in the contract. Subcontractors, data locations, retention, breach duties, service levels, audit access, exit assistance, evidence portability, and every customer responsibility.
Our IAL3 vendor RFP and scorecard and 3PAO-readiness evidence checklist turn these questions into reusable procurement artifacts.
Frequently Asked Questions
Does NIST issue an official IAL3 vendor certification?
No. NIST publishes the requirements, but it does not issue a commercial “IAL3 certified” product certificate or require a named private certificate in SP 800-63A-4. Independent assessments can provide useful evidence, though their scope matters and they do not replace review of the deployed implementation. A buyer can add its own qualifications, so always read the governing procurement documents.
Can an agency or company build its own IAL3 capability?
Yes. NIST's model allows the relevant CSP functions to be performed internally or by an external entity. An internal program still has to implement the applicable requirements, document any tailoring, operate the controls, and produce evidence that holds up in its assessment and authorization context.
Does FedRAMP High or an agency ATO require a particular IAL3 vendor?
Across every independent customer implementation Trust Swiftly has supported — spanning multiple 3PAOs and agency contexts — no FedRAMP High or defense authorization review has required a named third-party IAL3 certificate as the prerequisite for satisfying the NIST control. The applicable profile and authorization package define the outcomes, the 3PAO assesses the scoped implementation, and the agency authorizing official makes the ATO decision. We cannot speak for every public or nonpublic solicitation, so the governing procurement documents still control.
Is a live video call on an applicant's laptop enough for IAL3?
No. Under the final SP 800-63A-4, IAL3 is on-site attended. The agent may be remote, but in that model the applicant uses a CSP-controlled kiosk or device that satisfies the additional requirements. An ordinary video call on an unmanaged personal device is not the kiosk-based IAL3 pathway.
Is NFC passport reading mandatory for IAL3?
No. NFC is one useful implementation for compatible chip-enabled evidence, not a universal requirement. The accepted evidence strength and validation pathway determine what is necessary. If SUPERIOR evidence contains digitally signed attributes, those signatures must be validated; physical evidence also has permitted automated and trained visual-inspection pathways.
Does buying a proofing service eliminate the customer's compliance work?
No. The customer still owns its risk decisions, authorization boundary, identity-provider and access configuration, authenticator and recovery policy, provider oversight, and acceptance of the evidence. A strong provider makes the operating division explicit and hands over defensible artifacts, rather than promising compliance as an automatic outcome.
The Decision That Matters
IAL3 is not scarce knowledge. The standard is public, and a capable organization is free to build against it. What is scarce is sustained operating maturity — controlled ceremonies, evidence and sources, biometrics, people, fraud, privacy, binding, and audit evidence, all working at once, on an ordinary Tuesday, while something upstream is broken.
That is what Trust Swiftly should be judged on. We do not sell permission to satisfy IAL3, and we cannot grant your ATO. What we provide is an operating system for high-assurance proofing that we keep tuning against real failures and changing threats, with the responsibility boundary and the evidence visible.
If building is right for your mission, use the requirement map and the diligence questions above to make the build credible. If buying or a hybrid model is stronger, hold every provider to the same standard. Including us.
Talk with Trust Swiftly about an IAL3 build-versus-buy review. We will map the complete workflow, show where our responsibility ends and yours begins, and identify the evidence your assessment path actually needs.
