How should organisations decide whether a mobile identity method is acceptable for onboarding?

What makes a mobile identity method acceptable for onboarding?

An acceptable mobile identity method is one that can be tied to a recognised proofing process and a defined assurance level. The device format is secondary. Organisations should be able to show what method was used, what evidence it produced, and why that evidence is sufficient for the intended onboarding decision.

That distinction matters because “mobile” can describe many different things, from a wallet-held credential to an app-based authenticator or a scanned document. Only some of those support regulated identity proofing. If the method cannot be mapped to an accepted assurance model, the organisation is really accepting convenience, not identity confidence.

Why the method name matters more than the phone

The onboarding decision should focus on the proofing method, the issuer, and the level of trust that method establishes. A credential stored on a phone is not automatically strong, and a wallet presentation is not automatically authoritative. The question is whether the method is bound to the person, traceable to a trusted process, and appropriate for the risk of the account being created.

For practitioners, the useful test is whether the mobile method changes the onboarding outcome beyond simple convenience. If it does not improve proofing quality, fraud resistance, or traceability, then it should not be treated as an acceptable basis for higher-risk onboarding just because it is modern or user-friendly.

When teams evaluate digital identity methods, the relevant benchmark is the assurance the method gives to the relying party, not the user interface. Standards such as NIST SP 800-63 Digital Identity Guidelines are useful because they separate identity proofing and authenticator strength from the form factor used to deliver them.

What evidence should the onboarding rule require?

Good onboarding policy should require a named method, a named assurance level, and evidence that can be audited later. That usually means the organisation can answer three questions: how the identity was proofed, what the mobile method actually asserted, and what record was retained to support the decision.

This is where many onboarding controls fail. A vague rule such as “accept mobile ID” leaves too much room for inconsistent operator judgement and makes it hard to prove that regulated onboarding was handled consistently. The policy should instead specify which methods are acceptable, which are only acceptable at lower assurance, and which need fallback checks or manual review.

Where mobile identity is used in a broader digital identity stack, the organisation should also verify the trust chain behind the credential. The relying party needs confidence that the assertion came from an approved process, not just from a device that can display it. That is why identity proofing, issuer trust, and binding to the subject matter more than the phone itself.

Related identity guidance such as IAM and IGA Basics is helpful for keeping the onboarding rule anchored in authentication, authorization, and governance rather than in the user experience layer.

What should organisations do when mobile identity is only partly trustworthy?

When a mobile method is useful but not sufficient on its own, the onboarding rule should treat it as one input among several. That might mean requiring a stronger proofing step, a second independent attribute check, or a manual exception path for higher-risk enrolments. The key is to decide in advance which cases need more than a phone-based presentation.

Organisations should also avoid letting onboarding teams improvise acceptable use case by use case. If the method is accepted for low-risk access but not for regulated customer onboarding, that distinction must be explicit. Otherwise, operators tend to over-accept whatever is easiest to process.

For mobile identity methods that depend on wallet-held or app-presented credentials, it is useful to compare the method to adjacent controls for authentication and proofing, not to assume equivalence. OpenID Connect Core 1.0 is a useful reference point when teams need to separate federation-based authentication from actual identity proofing.

Risk and Threat Considerations

Accepting a mobile identity method without a clear proofing standard creates fraud, impersonation, and auditability risk. The main failure mode is over-trusting a convenient presentation layer and under-checking whether the identity was actually established to the required assurance level.

Failure mechanism: The onboarding rule becomes vague enough that operators treat any phone-based credential, wallet token, or app assertion as “good enough”, even when the method does not match the regulated identity requirement.

Impact: Weak proofing can lead to account takeover at creation time, false enrolment, inconsistent customer treatment, and poor defensibility if the onboarding decision is challenged later.

Practitioner Guidance

Decision rule: If the organisation cannot name the proofing method, the issuer, and the evidence retained for the onboarding decision, do not accept the mobile method for regulated onboarding. Treat it as a usability feature until it is tied to a recognised assurance model.

What to verify: Check that the policy distinguishes between proofing strength and device form factor. The strongest onboarding control is the one that can be explained, repeated, and audited without relying on operator interpretation.

Practitioner takeaway: Mobile delivery is not the control, the recognised proofing method and its assurance level are the control.

Related resources from NHI Mgmt Group

• How can organisations decide whether to move from seat-based to usage-based identity pricing?
• How can organisations decide whether environment visibility is acceptable?
• How should organisations decide whether to build or buy workload identity tooling?
• How should organisations decide whether their multi-cloud identity model is working?