Digital Identity Acceptance Statement (DIAS) is a policy statement that defines which digital identity evidence, assurance levels, and verification methods an organisation will accept. It helps prevent inconsistent onboarding and unsupported trust decisions. Security teams use it to align identity proofing, acceptable credentials, and escalation paths when evidence is weak or disputed.
What a DIAS governs
A digital identity Acceptance Statement sets the organisation’s rules for which identity evidence, assurance levels, and verification methods are acceptable before a digital identity is trusted. It is a policy control for consistency, not just a procedural checklist, and it defines the boundary between accepted proof and unsupported trust.
Because DIAS determines what evidence is valid enough to open an account, approve access, or escalate a disputed case, it directly shapes the organisation’s trust model. A weak or vague statement tends to produce inconsistent onboarding decisions, uneven exceptions, and informal workarounds that are difficult to audit later.
Why acceptance criteria matter
Identity proofing is only useful when the organisation knows what it will accept and when it will reject or step up scrutiny. A DIAS makes that decision explicit, so security, fraud, and operations teams do not improvise different standards for the same identity journey.
In practice, a DIAS often sits alongside identity proofing guidance and assurance frameworks. For example, organisations building digital onboarding flows can align their acceptance rules with the evidence and assurance concepts described in the Identity Proofing and KYC Guide, then use those rules to decide when a check is sufficient, when to request more evidence, and when to reject the attempt.
What it typically defines
A useful DIAS usually specifies three things: the kinds of evidence that are acceptable, the assurance level or confidence threshold required, and the verification methods permitted to establish that confidence. Those decisions may cover documents, biometrics, electronic credentials, trusted intermediaries, or other forms of attestable identity evidence.
It should also define how to handle disputes and weak evidence. If the supplied evidence is incomplete, contradictory, or operationally hard to verify, the statement should point to an escalation path rather than leaving staff to make ad hoc trust decisions.
Where an organisation relies on digital identity wallet or reusable credentials, the acceptance statement should make clear which external trust frameworks and presentation methods are recognised. The eIDAS 2.0 framework is a useful reference point for understanding how regulated digital identity ecosystems formalise trust, verification, and cross-border acceptance.
Operational and governance implications
DIAS is as much about governance as it is about verification. It creates a common rulebook for onboarding teams, fraud analysts, support staff, and security reviewers so the organisation can treat similar cases consistently and defend those decisions later.
That consistency becomes especially important when multiple channels feed the same identity lifecycle, such as remote onboarding, delegated enrolment, recovery flows, or re-verification after a risk event. A clear DIAS reduces the chance that one channel becomes the weak exception path for the whole programme.
For broader identity programmes, DIAS works best when it is connected to lifecycle and control ownership rather than written as a standalone policy. The Identity Security Programme Guide provides a broader operating-model lens for turning policy decisions into accountable identity governance.
Risk and Threat Considerations
DIAS exists because inconsistent acceptance criteria create real exposure. If teams accept weak evidence in one workflow but demand stronger proof in another, attackers can target the easiest path, while legitimate users can be over-trusted, under-verified, or pushed into unsupported exception handling.
Failure mechanism: Ambiguous or overly permissive acceptance rules lead to inconsistent identity proofing, which can enable synthetic identity fraud, account-opening abuse, or unauthorized enrollment through the weakest approved method.
Impact: The organisation may grant access to the wrong person, create poor auditability for trust decisions, and inherit downstream identity risk that is difficult to unwind once an account, credential, or recovery path has been issued.
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 | IA-12 — Identity Proofing | DIAS sets acceptable identity evidence and verification thresholds. |
| Recommendation — Define proofing acceptance levels and step up verification when evidence is weak or disputed. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | DIAS governs how external identities are verified before access is accepted. |
| Recommendation — Apply external-user proofing rules before issuing access or account recovery paths. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | DIAS supports consistent identity verification and accepted trust decisions. |
| A.5.17 — Authentication information | DIAS defines what credential or evidence types are acceptable in identity checks. | |
| Recommendation — Document identity acceptance rules and ensure they are approved, maintained, and enforced. Restrict accepted authentication evidence to approved methods and assurance levels. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication, and Access Control Policies | DIAS is a policy statement for accepted identity evidence and trust paths. |
| Recommendation — Establish and maintain policy for accepted identity evidence and verification methods. | ||
Practitioner Guidance
Governance implication: Treat DIAS as a controlled trust policy owned jointly by identity, security, fraud, and operations, not as an informal guidance note. The statement should define who can approve exceptions, who reviews disputed evidence, and when stronger verification is mandatory.
What to watch for: A DIAS usually needs revision when onboarding outcomes drift, exception rates rise, or new identity methods are introduced without a matching trust decision. If the organisation cannot explain why a specific evidence type is accepted, the policy is probably too vague to operate safely.
Related resources from NHI Mgmt Group
- How should organisations implement interoperable digital identity acceptance without exposing unnecessary personal data?
- Who should own policy for digital credential acceptance in a customer identity programme?
- How should security teams govern credential acceptance in digital identity flows?
- Why do digital identity programmes need explicit acceptance rules for choice?