Start by classifying the transaction, not the channel. High-risk services need stronger proofing, better uniqueness checks, and stricter acceptance criteria than low-risk convenience flows. The right threshold is the one that preserves trust when users, staff, and evidence are all remote.
How to set identity assurance levels for remote onboarding
Set assurance by the risk of the account and the value of the transaction, not by whether the user is remote. A low-risk self-service flow can justify lighter proofing, but regulated, high-impact, or fraud-prone onboarding needs stronger identity proofing, uniqueness checks, and tighter acceptance criteria. The goal is to keep trust durable when evidence, applicants, and approvers never meet in person.
What actually drives the assurance level
identity assurance is a decision about how much confidence you need that a person is real, unique, and entitled to the account or privilege being created. For remote onboarding, that confidence comes from the evidence set, the quality of validation, and the consequences of a false acceptance. The channel is only one input; it should not override the risk of the service or the sensitivity of the access being granted.
Higher assurance usually means more than one corroborating signal, stronger document or biometric checks where appropriate, and stricter policies for when a record can be accepted manually. For lower assurance, the organisation can allow simpler evidence paths, but it still needs basic fraud controls, auditability, and a way to step up verification if the request later becomes higher risk.
Good practice is to define clear thresholds for who can be onboarded with standard proofing, who needs enhanced proofing, and who must be rejected or referred. That threshold should be tied to business impact, regulatory exposure, and likely abuse cases, not to convenience or the shortest user journey.
How to make the threshold defensible in practice
Remote onboarding becomes defensible when the assurance policy is linked to a documented risk classification for the product or population. A consumer wallet, an internal employee account, a contractor account, and a regulated customer relationship do not deserve the same level of evidence or the same tolerance for exceptions. If the account can move money, access regulated data, or create downstream accounts, treat proofing as a control boundary, not a formality.
This is also where uniqueness matters. Remote proofing fails when the organisation confirms that a document looks valid but does not reliably determine whether the person is already known, duplicated, synthetic, or impersonating someone else. The policy should therefore specify when to check against internal records, when to use additional corroboration, and when to block reuse of weak or previously abused identity evidence. NIST SP 800-63 Digital Identity Guidelines provides a useful baseline for structuring that decision, especially around evidence strength and assurance levels.
For customer or business onboarding, the organisation should also align the threshold with the regulatory context. Know-your-customer and anti-money-laundering processes often demand a higher bar than ordinary access registration because the cost of a false accept can be financial, legal, and operational. FATF Recommendations and the EBA AML/CFT Guidance are relevant reference points when the onboarding decision carries financial crime obligations.
Risk and Threat Considerations
Remote onboarding is exposed to document forgery, synthetic identity, deepfake-assisted presentation attacks, account opening fraud, and exception abuse. The risk is not only that one bad account is created, but that weak proofing becomes a repeatable entry point for scale fraud, mule networks, or later privilege escalation.
Failure mechanism: The organisation accepts evidence that appears plausible but has not been tested against the actual abuse path, such as reused identity data, manipulated images, virtual camera injection, or weak uniqueness screening.
Impact: False acceptance creates accounts that look legitimate, which can lead to fraud losses, compliance failure, customer harm, and harder downstream remediation because the bad identity was given a trusted starting point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Defines identity assurance levels and proofing strength for remote onboarding. |
| Recommendation — Use IAL/AAL guidance to match proofing strength to account risk and required confidence. | ||
| NIST SP 800-53 Rev 5 | IA-12 — Identity Proofing | Remote onboarding depends on establishing trustworthy identity proofing before account creation. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | Remote onboarding commonly concerns external users whose identities must be enrolled and authenticated. | |
| IA-5 — Authenticator Management | Remote onboarding often issues or binds authenticators after proofing, making lifecycle controls material. | |
| Recommendation — Apply IA-12 to define identity proofing steps and acceptance criteria for remote enrollment. Use IA-8 to govern proofing and authentication for external onboarding populations. Use IA-5 to control authenticator issuance, storage, rotation, and revocation after onboarding. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control | Assurance levels determine how strongly identities are established before access is granted. |
| Recommendation — Set onboarding assurance rules within PR.AA so identity confidence matches access risk. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | Remote onboarding requires governed creation and verification of identities before access. |
| Recommendation — Define identity onboarding and verification rules under A.5.16 for consistent account establishment. | ||
Practitioner Guidance
What to prioritise: Classify onboarding flows by consequence first, then assign assurance levels that match the worst credible misuse of the account. If a false accept would create material financial, regulatory, or operational exposure, require stronger evidence and stronger uniqueness checks before approval.
What to verify: The policy should state which evidence types are acceptable, what manual review can and cannot override, and what triggers step-up review. Teams should be able to show that higher-risk flows have explicit acceptance criteria, not informal reviewer judgment.
Decision rule: If the transaction can create durable trust, access to regulated data, or the ability to onboard others, treat the assurance level as a control requirement rather than an experience decision. If the flow is low consequence, keep it simple but still measurable so it can be tightened when abuse patterns change.
Practitioner takeaway: Remote onboarding works best when assurance is proportional, documented, and tied to the harm that a false identity would enable, because convenience is never a substitute for a defensible trust threshold.
Related resources from NHI Mgmt Group
- What do organisations get wrong about identity checks in remote onboarding?
- How should organisations speed up customer onboarding without weakening identity assurance?
- How should security teams set assurance levels in digital onboarding?
- How should organisations govern remote onboarding when regulators allow digital identity verification?