Most identity proofing regulatory guidance was written for banks. If you’re a CTO at a HealthTech, EdTech, or SaaS company, the compliance landscape looks very different — less documented, less prescriptive, and genuinely harder to scope. But the obligations are real, and they’re growing.
Three core frameworks now reach well beyond financial services: NIST SP 800-63-4 (US federal guidance that has become widely adopted private-sector best practice), eIDAS 2.0 (EU regulation with a binding December 2027 EUDI Wallet acceptance deadline), and ISO/IEC 30107-3 implemented through iBeta PAD certification (the international biometric liveness standard). These frameworks are convergent — NIST assurance levels map directly to eIDAS assurance levels, and iBeta certification satisfies the biometric requirements of both.
This article maps each framework to specific sector obligations so you can scope which standards apply to you without paying for an initial compliance specialist engagement. For the broader context of identity proofing stack modernisation, see the full guide.
Why do identity proofing regulations mostly focus on financial services — and what applies to everyone else?
Financial services created the first generation of identity proofing regulation. Decades of anti-money-laundering requirements, Know Your Customer (KYC) obligations, and the PSD2 Strong Customer Authentication mandate drove financial institutions to build the earliest formalised verification frameworks.
Non-financial sectors took a different path. Privacy laws like HIPAA and FERPA specify outcomes — protect patient data, restrict access to student records — without saying anything about the methods for verifying who is actually requesting that access.
NIST SP 800-63-4 fills that gap. It applies to “all online services for which some level of assurance in a digital identity is required, regardless of the constituency” — not sector-restricted. eIDAS 2.0 takes the same approach for the EU: any online service provider with EU users is affected, regardless of industry. The EUDI Wallet acceptance mandate in December 2027 applies to HealthTech, EdTech, and SaaS equally.
What are NIST SP 800-63-4 identity assurance levels and what does IAL2 require?
NIST SP 800-63-4 (finalised July 2025) defines three Identity Assurance Levels (IAL) within a Digital Identity Risk Management (DIRM) framework.
IAL1 — Self-asserted identity. No proofing required. The user claims an identity and the system takes them at their word. That’s fine for low-risk accounts where unauthorised access causes minimal harm.
IAL2 — Remote identity proofing required. The user must present a government-issued identity document, undergo biometric capture (typically facial), and pass a liveness detection check against an authoritative source. This is the practical benchmark for most SMB use cases — high-confidence remote verification, no physical attendance needed.
IAL3 — In-person proofing with supervised biometrics. Reserved for national security clearances and critical infrastructure. Most SMBs will never need it.
SP 800-63-4 replaces a prescriptive checklist with the DIRM process — it’s risk-based, so you assess your service and select the appropriate assurance level. NIST is guidance, not law, for the private sector. But it’s increasingly embedded in enterprise procurement and cyber insurance requirements. Treating IAL2 as your benchmark gives you defensible alignment without a direct legal mandate. For certification requirements for liveness signal implementation, see the companion liveness guide.
Why does NIST now mandate injection attack detection, not just liveness checks?
SP 800-63-4 requires controls against injection attacks — going beyond the liveness detection of earlier versions.
Presentation attack detection (PAD) defends against spoofs presented to the camera: printed photos, screen replays, 3D masks. The sensor sees the attack. This is what iBeta PAD certification tests.
Injection attack detection (IAD) defends against a different method entirely. The attacker bypasses the camera, injecting a synthetic or deepfake image directly into the software pipeline. A PAD system never even sees it.
NIST added IAD because deepfake tools are now accessible enough that synthetic face images defeating sensor-level liveness checks are within reach of financially motivated fraud operations. The procurement implication: iBeta PAD Level 2 covers presentation attacks only — evaluate injection attack detection separately. For certification requirements for liveness signal implementation, the liveness guide covers vendor capability evaluation in full.
What does eIDAS Level of Assurance High require for biometric identity verification?
eIDAS 2.0 defines three Levels of Assurance that map directly to NIST IAL levels:
- Low = IAL1 (self-asserted, no proofing)
- Substantial = IAL2 (remote document verification + biometric + liveness)
- High = IAL3 (in-person proofing with supervised biometrics)
For most remote proofing contexts, eIDAS Substantial is the relevant benchmark. eIDAS High is for government services and qualified electronic signatures — most SMBs are operating at Substantial.
eIDAS 2.0’s scope is geographic, not sectoral. A HealthTech platform in Boston, an EdTech provider in Singapore, a SaaS company in Melbourne — all in scope if they serve EU residents.
The primary compliance obligation is the EUDI Wallet acceptance deadline: member states must issue EUDI Wallets by November 2026, and online service providers must accept them by December 2027. The wallet uses verifiable credentials with selective disclosure — users prove specific attributes without revealing underlying personal data — and that satisfies GDPR data minimisation requirements in one go.
What does iBeta PAD certification test and why does Level 2 matter?
iBeta Quality Assurance is an ISO/IEC 17025-accredited laboratory testing biometric systems for Presentation Attack Detection conformance against ISO/IEC 30107-3.
Level 1 tests against common attacks: printed photos, screen replays, simple masks — the baseline.
Level 2 tests against sophisticated attacks: 3D-printed masks, high-fidelity silicone replicas, advanced AI-generated synthetic images — the higher-assurance threshold.
Why Level 2 matters: deepfake tools are accessible enough now that Level 2 attack scenarios are no longer exclusively in the hands of sophisticated threat actors. Level 1 no longer adequately represents the threat landscape for systems protecting health data, financial transactions, or student records.
Require iBeta PAD Level 2 as a minimum vendor qualification. Ask for the specific Level 2 test report — not a general claim of “iBeta certified.” For certification requirements for liveness signal implementation, the liveness guide covers vendor certification in full.
How do GDPR and PSD2 constrain identity signal collection?
Under Article 9 of GDPR, biometric data processed for identification is special category data. Processing requires explicit consent with a clear purpose. Data minimisation under Article 5(1)(c) means collecting behavioural biometrics — keystroke dynamics, mouse movement — without documented necessity violates GDPR. GDPR does not ban behavioural biometrics; it constrains how you collect and justify them. For regulatory basis for IGA governance controls, see the IGA governance guide.
PSD2 mandates Strong Customer Authentication for payment services — two of three factors: knowledge, possession, inherence (biometric). It applies only to platforms that initiate or facilitate payments. For SaaS with embedded payment flows, PSD2’s SCA is layered on top of your NIST or eIDAS proofing obligations.
Which regulatory frameworks apply to HealthTech, EdTech, and SaaS companies specifically?
HealthTech
HIPAA mandates access controls for Protected Health Information but doesn’t prescribe proofing methods — NIST SP 800-63-4 provides the methodology, and DIRM applied to PHI access will almost always produce an IAL2 determination. HITRUST is commonly required by healthcare enterprise customers as a vendor qualification. iBeta PAD Level 2 is the appropriate minimum given the value of health data to fraud actors. GDPR applies if you’re serving EU patients.
EdTech
FERPA requires sufficient access controls to prevent unauthorised disclosure of student records — IAL2 is best practice for staff and administrator access. COPPA applies when users are under 13. GDPR applies if you’re serving EU students. The EUDI Wallet’s QEAA credential category explicitly includes educational qualifications — directly relevant to EdTech credentialing use cases.
SaaS (General)
GDPR is the most universal obligation for SaaS with EU customers. SOC 2 Type II is commonly required by enterprise customers — NIST 800-63-4 satisfies SOC 2 identity criteria. The eIDAS 2.0 EUDI Wallet December 2027 deadline applies to any SaaS platform with EU users. Perpetual KYC direction isn’t yet mandated outside financial services, but enterprise customers in regulated sectors are increasingly requiring continuous identity assurance in procurement. For pKYC as the regulatory mandate for continuous verification, the continuous verification guide covers how this is evolving.
Decision Framework
- Identify your user jurisdictions: US-only, EU-only, or both. EU presence activates GDPR and eIDAS 2.0 obligations.
- Identify sector-specific laws: HIPAA (healthcare data), FERPA (student records), COPPA (under-13 users).
- Run the NIST DIRM process: For most SMB use cases touching sensitive data, this produces an IAL2 determination — requiring iBeta PAD Level 2 from any biometric proofing vendor.
- Check eIDAS 2.0 applicability: If you have EU users, plan for EUDI Wallet acceptance by December 2027.
For the full guide to the modern identity stack, see identity proofing stack modernisation, which covers how these frameworks fit within a complete identity architecture.
FAQ
Is NIST SP 800-63-4 mandatory or just a guideline? Mandatory for US federal agencies and their contractors. For the private sector, it is guidance — but it is increasingly embedded as a contractual requirement by enterprise customers and cyber insurers. Treating IAL2 as your proofing standard gives you defensible alignment without a direct legal mandate.
Does GDPR ban behavioural biometrics? No. GDPR classifies biometric data processed for identification as special category data, requiring explicit consent, documented necessity, purpose limitation, and data minimisation. With proper implementation and disclosure, behavioural biometrics are deployable within GDPR.
What is the difference between IAL1 and IAL2 in plain terms? IAL1 means the system accepts the user’s self-declared identity without verification. IAL2 requires a government-issued identity document, a biometric check, and a liveness test with document validation against an authoritative source. Remote proofing is officially recognised for IAL2 — no in-person attendance required.
What is the difference between presentation attack detection and injection attack detection? PAD defends against spoofs presented to the camera — photos, replays, masks. IAD defends against synthetic images injected into the software pipeline, bypassing the camera entirely. NIST SP 800-63-4 requires both for IAL2. iBeta PAD covers presentation attacks; injection attack detection requires separate vendor evaluation.
Does eIDAS 2.0 apply to companies outside the EU? Yes. Any company offering services to EU residents is affected by the EUDI Wallet acceptance mandate, regardless of where they’re headquartered.
What is the EUDI Wallet and when must I accept it? A mobile credential wallet mandated by eIDAS 2.0. EU member states issue wallets by November 2026; online service providers must accept them by December 2027. The wallet uses verifiable credentials with selective disclosure — users prove specific attributes without revealing underlying personal data.
Which iBeta PAD level should I require from identity proofing vendors? Level 2, for any system where a successful spoof could result in access to sensitive data. Level 1 no longer represents the realistic threat landscape. Ask for the specific Level 2 test report.
Does FERPA require a specific identity assurance level for EdTech platforms? FERPA does not prescribe a specific level — it requires sufficient access controls to prevent unauthorised disclosure of student records. DIRM applied to FERPA’s obligation typically produces IAL2. For platforms serving users under 13, COPPA applies alongside FERPA.
What is perpetual KYC and does it apply outside financial services? Perpetual KYC (pKYC) is continuous identity monitoring rather than one-time onboarding verification. It originated in financial services and is not yet formally mandated elsewhere — but HIPAA’s ongoing access control requirements create a de facto pKYC obligation for HealthTech, and enterprise SaaS customers are increasingly requiring continuous identity assurance in procurement.
How do eIDAS assurance levels map to NIST IAL levels? eIDAS Low = NIST IAL1; Substantial = IAL2; High = IAL3. Documented by the EU-US TTC Digital Identity Mapping Exercise and confirmed in ISO 29115.
Do I need both SOC 2 and NIST SP 800-63-4 compliance for enterprise SaaS? They cover different concerns. SOC 2 covers operational security controls. NIST SP 800-63-4 specifies identity proofing assurance levels. Enterprise customers typically expect both — SOC 2 for general security posture and NIST-aligned IAL2 for identity assurance on sensitive data.
What happens if my company does not comply with eIDAS 2.0 by December 2027? Enforcement is managed by national supervisory authorities at EU member state level. Non-acceptance of EUDI Wallet presentations may result in service restrictions, fines, or inability to operate in EU markets. Start preparing now — don’t wait for enforcement clarity.
