What should organisations do when consumers still prefer legacy verification methods?

Organisations should keep multiple verification options available and treat them as part of one orchestration model, not separate programmes. Wallets, in-person checks and remote identity methods will coexist, so the programme should flex to user preference without lowering assurance.

Why legacy verification should remain available

When consumers still prefer older methods, the practical answer is not to force a single channel. Organisations need to preserve continuity across wallets, in-person checks and remote identity flows so the user can choose a method that matches context, risk and comfort level. The programme should be designed as one assurance model with multiple entry points, not as competing verification silos.

That approach matters because adoption usually lags capability. If a newer method is technically strong but too unfamiliar, too inconvenient, or unavailable at the point of need, people will route around it. The better design is to make the assurance target consistent while allowing the front door to vary.

How orchestration keeps assurance consistent

Multi-method verification only works if the organisation controls the underlying policy, not just the user interface. The method can change, but the trust decision should still be driven by the same rules for identity confidence, step-up triggers, transaction sensitivity and fallback handling.

In practice, that means the organisation should define which signals are equivalent, which are interchangeable only in lower-risk scenarios, and which are never acceptable substitutes. If the programme lacks that orchestration layer, legacy channels can become a weak parallel path rather than a managed part of the verification architecture.

For teams building that control layer, OWASP ASVS is useful because its authentication, session and access-control expectations reinforce the idea that the user journey and the assurance decision are separate design problems.

What organisations should optimise for

The goal is not to preserve every old method forever, but to keep choice available while measuring whether each method still meets the same assurance threshold. Legacy verification is acceptable when it remains observable, supportable and governed, and when it does not force the organisation to relax controls simply to keep users moving.

That usually means keeping the strongest methods available for higher-risk actions, while still supporting lower-friction options for routine use cases. It also means treating migration as a staged transition rather than a hard cutover, especially where customer familiarity or regulatory expectations still favour older flows.

If the programme is moving toward digital identity wallets or other modern methods, the policy baseline should still allow a mixed ecosystem. The objective is consistent trust decisions across channels, not premature retirement of a method that remains the only practical option for part of the population. Current European identity policy already assumes that wallets and other verification methods will coexist during rollout, so orchestration needs to be designed for coexistence rather than purity.

That policy direction is reflected in eIDAS 2.0, the EU Digital Identity Framework, which supports a multi-channel identity environment rather than a single mandated user experience.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V6 — Authentication	Covers authentication design across multiple verification methods.
	V7 — Session Management	Legacy and modern verification both depend on consistent session handling after authentication.
	V8 — Authorization	The issue is deciding which verified users can proceed under the same assurance rules.
Recommendation — Map each verification path to a common authentication assurance requirement. Apply one session policy across all verification channels. Tie each verification outcome to the correct authorization decision.
NIST SP 800-63	Digital Identity Guidelines	Supports choosing among identity proofing and authenticator paths with different assurance levels.
Recommendation — Align each verification method to the needed identity assurance level.

Practitioner Guidance

What to prioritise: Keep the verification policy centralised even when the user-facing methods vary. The important design decision is whether a method satisfies the required assurance level for the specific action, not whether it is the newest option.

What to verify: Confirm that every supported method maps to an explicit policy path for onboarding, step-up, exception handling and recovery. If a legacy method only exists because “users still like it,” it is usually under-governed.

Decision rule: If a consumer can still be served safely with a legacy method, keep it until the organisation can remove it without weakening accessibility or trust. If it cannot meet the required assurance level for certain transactions, constrain it rather than removing all alternatives.

Practitioner takeaway: The mature move is to manage verification as a portfolio of governed options, with a single assurance standard underneath and multiple user journeys above it.