They should treat identity proofing, application capture, and login assurance as a single governed journey. When those controls are split, customers face duplicated checks and inconsistent risk treatment. A unified flow lets stronger verification reduce manual review, while authentication decisions remain aligned to the same identity evidence used at onboarding.
Unifying onboarding and authentication around one identity journey
Challenger banks get better outcomes when onboarding and authentication are designed as one policy-led journey, not two disconnected products. The customer should prove who they are, the bank should capture the evidence needed for account opening, and the same assurance level should flow into sign-in. That reduces duplicate friction, avoids inconsistent decisions, and makes step-up controls easier to apply consistently.
A practical way to think about this is that the onboarding checkpoint and the login checkpoint should share the same trust signal. If onboarding finds a stronger evidence set, that should lower later review or enable stronger authentication options. If login assurance is weaker than the onboarding evidence, the bank should treat that as a reason to re-verify, not as a separate siloed problem.
Done well, this also improves operations. Support teams see fewer “why am I being asked again?” cases, risk teams get a clearer trail from identity proofing to account access, and product teams can tune the flow for the right balance of conversion and assurance. The key is governance: one journey, one evidence model, one decision record.
Where split journeys usually break down
When onboarding and authentication are engineered separately, the bank often ends up with two risk engines, two evidence sets, and two different views of the same customer. That creates avoidable inconsistency, for example when onboarding accepts one level of proof but login treats the account as if it started from a weaker baseline. It also invites customer drop-off because each handoff feels like a new process.
Security problems appear when the authentication layer is allowed to drift away from the identity evidence collected at onboarding. A weaker login policy can undermine a strong onboarding flow, while an overly strict login policy can force unnecessary manual review after the account is already established. In practice, the failure is not just friction, it is a broken control chain.
For this reason, the strongest designs use the onboarding event to establish the initial trust posture, then preserve that posture through the authenticator choice, recovery path, and step-up rules. That makes future authentication decisions explainable, auditable, and proportional to the original verification.
What a combined flow should actually coordinate
A combined flow should coordinate four things: identity proofing, application capture, initial authentication strength, and post-enrolment recovery. The bank should decide which identity evidence is sufficient for account creation, which authenticators are acceptable for first access, and what conditions trigger additional checks later. That alignment is especially important when the bank supports passkeys, MFA, or risk-based step-up.
- Use the onboarding evidence to determine the starting authenticator assurance level.
- Bind account recovery to the same identity proofing standard, not a weaker helpdesk shortcut.
- Keep risk rules consistent so sign-in, password reset, and device change all inherit the same trust posture.
- Record the decision path so operations can explain why a customer was accepted, stepped up, or routed to review.
The bank should also be careful about what it externalises to vendors and what it keeps under its own policy control. Identity proofing can be outsourced, but the acceptance threshold, fraud rules, and authentication policy should remain internally governed. That is what prevents a vendor workflow from silently becoming the bank’s security policy.
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 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Onboarding-to-login assurance depends on identity proofing, authenticators, and assurance levels. |
| Recommendation — Align proofing, authenticator strength, and recovery to the required assurance level. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The flow must establish and preserve authenticated identity before access is granted. |
| IA-5 — Authenticator Management | The journey must govern credentials, resets, and lifecycle continuity across onboarding and login. | |
| Recommendation — Bind account access to a consistent identification and authentication policy. Control authenticator issuance, reset, rotation, and revocation as one lifecycle. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | A unified journey needs one access policy spanning proofing, login, and re-verification. |
| A.8.5 — Secure authentication | Authentication strength must match the trust established during onboarding. | |
| Recommendation — Define one access policy for onboarding, authentication, and step-up decisions. Set authentication strength to match the onboarding assurance outcome. | ||
Practitioner Guidance
What to prioritise: Start by defining one assurance model that spans registration, first login, and recovery. If a customer can open the account with one set of checks but later reset access with a much weaker path, the flow is not unified in any meaningful security sense.
What to verify: Confirm that the onboarding event produces a durable policy signal, not just a pass/fail outcome. Teams should be able to show which evidence level, authenticator class, and recovery path were approved for each account, and why.
Common mistake: Treating onboarding as a product journey and authentication as an IAM integration. That split usually creates duplicate checks, inconsistent step-up logic, and a poor recovery experience that attackers can target.
Practitioner takeaway: The best design is not the one with the most checks, it is the one where every later authentication decision can be traced back to the same identity evidence used to open the account.
Related resources from NHI Mgmt Group
- Why is it crucial to adopt new authentication methods in MCP usage?
- What breaks when an MCP server tries to handle both authentication and authorization in one flow?
- What breaks when new employee onboarding does not include secure authentication on day one?
- What are the signs that a Web3 onboarding flow is failing users before they complete authentication?