How do organisations implement a Digital Identity Acceptance Statement (DIAS)?

What a Digital Identity Acceptance Statement should decide

A DIAS is not just a policy label, it is the organisation’s operating rule for which identity evidence is acceptable, for which journeys, and at what assurance level. The useful version makes the decision repeatable: what is accepted, what is never accepted, who can approve exceptions, and when the decision must be reviewed as fraud patterns, regulation, or business risk changes.

That means the statement should separate use cases rather than try to define one universal bar. Onboarding, account recovery, high-risk transaction approval, employee access, and regulated customer journeys often need different evidence, different proofing strength, and different fallback paths. A single acceptance rule that ignores context usually becomes either too weak to trust or too strict to operate.

The statement also needs to map evidence to assurance, not just list documents or technologies. In practice that means defining how identity proofing methods, credential types, and any trusted sources of identity are weighed, then linking that to a risk decision. For cross-border or wallet-based journeys, eIDAS 2.0, the EU Digital Identity Framework is a useful external anchor because it shows how identity acceptance rules become formalised around trusted wallets, electronic identification, and verification across jurisdictions.

How to structure DIAS decisions so they can be executed

A workable DIAS should be written as an operations document, not a narrative aspiration. The clearest structure is: acceptable evidence, required proofing standard, permitted alternatives, explicit exceptions, owner, review cadence, and the downstream policy that consumes the decision. That makes it usable by onboarding teams, IAM teams, fraud teams, and application owners without each group inventing its own interpretation.

Use risk tiers to decide where stronger identity evidence is mandatory. Low-risk self-service actions may accept lighter evidence, while regulated access, payment release, or privileged account creation usually require stronger proofing and better auditability. If the organisation already runs a formal digital identity or wallet programme, the acceptance statement should align with that operating model rather than sit beside it as an isolated rulebook.

For identity proofing journeys, the acceptance statement should specify whether the organisation accepts documentary proof, remote proofing, biometric checks, trusted digital credentials, or a combination of these. A practical reference point is the Identity Proofing and KYC Guide, which aligns closely with the assurance and fraud considerations that usually drive DIAS decisions. If the organisation accepts higher-risk evidence, it should also define what independent validation or step-up review is required before that evidence can be trusted.

Identity acceptance also needs lifecycle discipline. Accepted evidence and methods tend to drift over time, especially after mergers, product launches, or new fraud patterns. A review cycle prevents a stale DIAS from silently becoming policy debt, and it gives owners a clear point to tighten, retire, or broaden accepted methods when risk changes.

Where DIAS usually fails in practice

The most common failure is ambiguity. If the statement says “strong identity evidence” without naming what that means for each use case, teams will improvise. That creates inconsistent onboarding outcomes, uneven customer experience, and an audit trail that cannot explain why one person was accepted and another was rejected.

Another frequent failure is allowing exceptions to accumulate without governance. Exceptions are sometimes necessary, but if they are not time-bound, owned, and reviewed, they become a shadow acceptance policy. Over time, that can undermine fraud controls, create compliance gaps, and weaken confidence in the data the organisation uses to establish identity.

Many organisations also under-specify the relationship between accepted identity evidence and access decisions. A proofing decision is not the same thing as an authorisation decision, and the DIAS should not blur those boundaries. The evidence accepted to establish identity should be sufficient for the intended risk level, but it should still feed into separate onboarding, access, and privilege controls rather than replace them.

Operationally, the statement is only as strong as the processes around it. If staff can override the stated acceptance rules without logging the reason, or if application teams can bypass the approved proofing path, the DIAS becomes advisory text instead of a control. That is where governance, ownership, and system enforcement matter more than wording.

Risk and Threat Considerations

A DIAS creates security exposure when an organisation accepts identity evidence that is easier to fake, replay, or socially engineer than the risk of the journey warrants. Weak or inconsistent acceptance rules can let synthetic identities, stolen documents, account-takeover attempts, or fraudulent enrolments pass as legitimate, especially when the same acceptance standard is reused across very different use cases.

Failure mechanism: Accepted evidence does not match the real assurance needed for the transaction, or exceptions become routine and bypass the intended control path. That weakens fraud prevention, increases account-opening abuse, and can propagate bad identity data into downstream access and trust decisions.

Impact: Organisations can end up onboarding the wrong person, granting access on a false basis, or retaining identities that should never have been accepted. The result is not just immediate fraud loss, but longer-lived governance and access risk because later controls inherit a bad identity decision.

Practitioner Guidance

What to prioritise: Start by classifying the top three identity journeys by risk, then define acceptance rules for each one instead of trying to write one universal standard. The highest-value work is usually where identity acceptance feeds directly into account opening, regulated access, or privileged onboarding.

What to verify: Every accepted method should have a named owner, a stated assurance threshold, an exception path, and a review trigger. If a team cannot explain why a particular credential or proofing method is acceptable for that journey, the DIAS is too vague to govern.

Practitioner takeaway: A good DIAS is less about listing approved methods and more about making identity acceptance auditable, risk-based, and hard to bypass when business pressure rises.

Related resources from NHI Mgmt Group

• Guide: Digital Identity, eID and Identity Wallets Guide
• How should organisations implement interoperable digital identity acceptance without exposing unnecessary personal data?
• How does Digital Identity Acceptance Statement (DIAS) work?
• Digital Identity Acceptance Statement (DIAS)
• How should healthcare organisations implement digital identity so patients can share only the records they intend to share?