How ID Dataweb Enables IAL2-Compliant Identity Proofing at Scale

In July 2025, the National Institute of Standards and Technology (NIST) released the final version of Special Publication (SP) 800-63, Revision 4. This update reflects nearly four years of research, two public draft cycles, and close to 6,000 public comments. The revision defines updated Digital Identity Guidelines designed to address the evolving digital landscape since the previous version was published in 2017.

Among other changes, NIST SP 800-63-4 expands requirements and recommendations for identity fraud prevention within identity proofing processes, including what Identity Assurance Level 2 (IAL2) means in practice. The previous revision defined Identity Assurance Levels as fixed tiers. The current guidelines instead frame them as control objectives tied to specific attacker models. They also require organizations to tailor controls to their unique threat exposure.

Organizations that built proofing workflows around the 2017 version, or relied on vendors aligned to it, will likely find gaps between their current implementations and the updated guidelines.

This blog maps the capabilities of the ID Dataweb™ SaaS platform to those revised requirements. It focuses on the details that matter during implementation planning, including which control objectives apply, which signals address them, how the policy engine handles conflicting inputs, and how integration works within an existing identity and access management (IAM) stack.

What NIST requires at IAL2 and where most implementations fall short

The IAL2 summary table in NIST SP 800-63-4 states that assurance levels must limit scaled and targeted attacks, protect against falsified or stolen evidence, and defend against basic social engineering. In practice, this means a proofing system must detect forged documents, block impersonation attempts, and identify identity reuse across applications.

The companion volume, NIST SP 800-63A-4, expands on remote proofing requirements. It addresses digital injection attacks and forged media, including deepfakes. It requires credential service providers (CSPs) to implement controls such as virtual camera detection, media manipulation analysis, and testing against known attack artifacts. It also requires providers to document false negative rates for forged media detection and make them available to relying parties upon request.

Two additional changes are critical for deployment decisions. First, knowledge-based authentication (KBA) is now explicitly prohibited for identity verification in proofing workflows. Organizations still using KBA for portal activation or call center scripts must adopt alternatives. Second, NIST positions the framework as risk-based rather than compliance-driven. An IAL2 implementation must demonstrate that selected controls align with the organization’s specific threat exposure, not simply that the controls exist.

Why identity threat detection matters more than compliance checklists

NIST SP 800-63-4 acknowledges that no single assurance level can cover the full spectrum of organizational risk. It instructs organizations to apply a digital identity risk management approach.

This shift has practical implications. An implementation that applies the same document check and liveness test to every applicant satisfies a checklist. It does not meet the requirement for risk-based decisioning. A healthcare provider onboarding patients and clients of a financial institution opening brokerage accounts face different threat profiles. A static workflow cannot address both effectively.

ID Dataweb approaches this from the opposite direction. The ID Dataweb platform evaluates contextual risk signals at the moment of the identity event and adapts the workflow accordingly.

Device telemetry captured during the session establishes the environmental baseline. This includes browser fingerprinting, geolocation, VPN detection, and virtual camera indicators. Carrier risk signals such as SIM tenure, porting history, subscriber status, and recent SIM swaps indicate whether a phone number is stable or recently manipulated. Credit bureau and public records checks confirm whether the personally identifiable information (PII) footprint is consistent with a real individual or reflects patterns typical of synthetic identities.

Each risk signal category aligns with specific attack vectors described in NIST’s IAL2 control objectives, including evidence falsification, social engineering, and large-scale identity reuse.

This adaptability is essential because different industries face different attack patterns. A healthcare organization participating in the Trusted Exchange Framework and Common Agreement (TEFCA) may encounter elevated risk from synthetic identities used to create fraudulent patient records. A financial services firm may see higher volumes of account takeover driven by stolen credentials.

These threats do not appear only during document verification. They emerge across the entire session context. ID Dataweb captures and evaluates that context by combining device, carrier, behavioral, and document-based risk signals within a single policy decision. The policy engine can weight these risk signals differently depending on the workflow.

Both workflows operate on the same platform while addressing distinct threat models. This distinction separates identity threat detection from static compliance verification.

How ID Dataweb maps to IAL2 control objectives

The pre-packaged ID Dataweb IAL2 workflow follows the NIST-defined sequence. The applicant receives a secure link, captures a government-issued ID, and completes a real-time selfie for liveness detection and biometric comparison. Extracted PII is then cross-checked against authoritative data sources.

If PII verification fails, the system triggers a step-up process that requires a second government-issued document. The ID Dataweb platform evaluates each document using multiple checks, including optical character recognition (OCR) confidence, barcode integrity, tamper detection, screen and paper liveness, visible security feature validation, and cross-zone data consistency for name, date of birth, and document number.

On the biometric side, BioGovID™ evaluates liveness using eye movement, three-dimensional shape analysis, and natural lighting conditions. It also performs mask and lens detection, brightness validation, and facial matching between the selfie and the ID photo.

A key differentiator of a multi-signal platform like ID Dataweb is how it handles conflicting inputs. For example, a document may validate successfully while the phone number shows a recent SIM swap and the device profile indicates VPN usage from a location inconsistent with the applicant’s address. The ID Dataweb policy engine evaluates all risk signals together and can return an obligation decision that triggers additional verification steps instead of issuing a simple approve or deny outcome.

This step-up logic is configurable within the ID Dataweb administrative console and does not require code changes.

Conclusion

The updates to NIST’s IAL2 guidelines reflect a broader reality. Identity proofing systems that cannot detect contextual threats or adapt decisions to varying risk environments do not provide meaningful protection against modern attack methods.