Digital banking today is all about trust without friction. But behind every seamless app experience are deliberate security choices—one of the most important being the separation of onboarding and device activation.
In this post, we’ll explore why modern banks split these two steps, how the process works, and what it means for security and user experience.
What’s the Difference?
Let’s start by defining the two terms:
- Onboarding = verifying that the person is a legitimate new customer
- Device Activation = securely registering a specific device for account access
They might seem like the same thing—but treating them as separate steps brings important benefits in terms of security, control, and flexibility.
Why Separate Them?
1. Defense in Depth
By isolating onboarding from device activation, banks introduce an extra layer of control. Even if onboarding is completed fraudulently, device activation can still be blocked based on risk signals.
2. Regulatory Compliance
Frameworks like PSD2 and EBA guidelines demand Strong Customer Authentication (SCA), including device binding and transaction signing. Separating device registration helps banks meet these obligations more clearly.
3. Support for Multiple Channels
Some users onboard via web, others via mobile. By treating device registration as a standalone step, banks allow seamless cross-channel flows—like onboarding on desktop, activating later on mobile.
4. Frictionless Recovery
Lost your phone? With a separate activation process, recovery doesn’t mean re-onboarding. You just go through a fresh device verification flow, while keeping your existing customer identity intact.
Explanation of some important keyword
Multi-Factor Authentication (MFA) from Day One
The foundation of any secure onboarding process is MFA. Most banks today implement two or more of the following factors:
- Something you know (e.g., password, PIN)
- Something you have (e.g., device, card, token)
- Something you are (e.g., biometric data like fingerprint or face)
During onboarding, this can mean a combination of SMS OTPs, email confirmations, and biometric scans—all working together to verify identity.
Video Identification and eID Integration
In regions with strict regulatory requirements (like Europe’s eIDAS), banks often leverage video identification or national digital identity systems. Popular methods include:
- Live video calls with trained agents verifying ID documents in real time.
- eID integration (e.g., SwissID, BankID, eIDAS) to authenticate users via national systems.
- Liveness detection to prevent deepfakes or photo-based spoofing.
Out-of-Band Verification
To reduce the risk of device compromise, banks use out-of-band (OOB) channels (not necessary devices). This involves:
- Initiating onboarding on one channel (e.g., web)
- Confirming it on another (e.g., SMS or app push notification)
This separation ensures that even if one channel is compromised, the attacker cannot complete the process.
How the whole process works in practice: Step-by-Step
Let’s take a closer look at how this separation plays out in a typical flow:
Step 1: User Onboards via Web or App
- The user creates an account by providing ID, personal info, and credentials.
- Identity is verified via:
- eID (e.g., BankID, SwissID)
- Video identification
- ID scan + selfie (liveness check)
✅ At this point, the user identity is verified, but no device is trusted yet.
What the User Receives After Onboarding Approval
1. Activation Code / Link
A one-time code, URL, or QR code to trigger device activation securely.
- 🔐 Purpose: Ensures device is trusted before allowing access
- 🛡️ Often tied to expiration and IP/device conditions
2. Customer Number / Contract ID
A unique identifier (e.g., customer ID, contract number) that links the user to their account.
- 🔐 Purpose: Used to complete setup on new devices
- 🧩 Sometimes needed to configure the app
3. Temporary Login Credentials
Some banks issue temporary usernames or passwords to be changed on first login.
- 🔐 Purpose: Minimizes exposure in case of delayed delivery
- ⏳ Often expires in 24–48 hours
4. Instructions for Device Activation
A step-by-step guide (printed or digital) describing how to activate their device or complete login setup.
How is this materials delivered to the customer?
Depending on the country, bank decision and used identity for verification this process may complete immediately or take couple of days. But what follows as next?
| Method | Used By | Security Characteristics |
|---|---|---|
| Postal Mail | Swiss banks (e.g., ZKB, UBS), traditional banks | Secure and legally compliant, but slow (3–5 days) |
| Secure Email | Challenger banks, Erste, sometimes UBS | Encrypted or signed, may include a download link or code |
| SMS with One-Time Code | N26, Revolut, Erste | Used only as part of 2FA or in-app flows, not standalone for full onboarding |
| In-App Notification (after approval) | N26, Revolut | Approval happens in background; user is prompted to activate directly |
| Out-of-Band App (e.g., UBS Access, ZKB Auth) | UBS, ZKB | Code appears in secure app, avoids email/SMS risks |
| Phone Call or Video Session Confirmation | Some traditional banks | Often used in regulated environments like wealth management |
Step 2: User Is Prompted to Activate a Device
- The user logs into the mobile app or scans a QR code from the received materials from the bank.
- The device sends a request to be activated, using:
- Device fingerprint (model, OS, location)
- Cryptographic key exchange (public/private key pair)
- One-time code sent via secure channel
Step 3: Device Activation is Evaluated
The bank’s backend does a risk analysis:
- Is this device consistent with the onboarding session?
- Is it from the same region or network?
- Is the device jailbroken, rooted, or flagged by MTD tools?
If the risk is acceptable:
✅ The device is now bound to the user account and stored as trusted.
| 🏦 Bank | 🧾 Onboarding Flow | 📱 Device Activation Flow | 📦 Separate App Used? |
|---|---|---|---|
| Revolut | Self-onboarding in main Revolut app with ID scan + selfie | Device auto-registered during app setup, fallback via QR scan from web | ❌ No (all in one app) |
| ZKB (Zürcher Kantonalbank) | SwissID, in-branch, or via postal code in main banking app | Activation via ZKB Auth app using QR code and second factor | ✅ Yes, ZKB Auth for activation |
| Erste Bank | Onboarding via George app or web portal, using ID scan and biometrics | Activation in George app using OTP and biometric | ❌ No (George app handles both) |
| N26 | In-app onboarding via ID check or video call in main N26 app | QR scan if web-based start, otherwise bound during app setup | ❌ No |
| UBS | SwissID or video ID (sometimes using a separate app or in-branch) | Activation via UBS Access App with QR scan + second factor | ✅ Yes, UBS Access App for activation |
| Traditional Banks (generic) | Often in-branch or via separate video ID app | OTP or app-based device registration post-onboarding | ✅ Often yes (e.g., separate video ID or authentication app) |
What If Something Looks Suspicious?
If risk scores are high (e.g., unknown IP, abnormal behavior), banks may:
- Prompt for extra verification (OTP, biometric scan)
- Deny the activation and flag the session
- Require approval from a previously registered device
This ensures the device activation step acts as a gatekeeper, even if onboarding succeeded.
Technologies for Secure Onboarding & Device Activation
Identity Verification & Management
| 🔐 Use Case | 📦 Technology / Standard | 🚀 Type | 🔒 Security Level | 📝 Notes |
|---|---|---|---|---|
| Identity Proof | Video Ident, OCR + Selfie | Traditional | ✅ Strong | Widely used, time-intensive |
| Identity Proof | SSI (Self-Sovereign Identity) | Emerging | ✅ Strong | User controls data, no central storage |
| ID Document Check | MRZ scan, barcode, OCR | Traditional | ✅ Strong | Easily spoofed if not combined with NFC |
| ID Authenticity | NFC chip reading (eID) | Emerging | ✅ Strong | Cryptographic ID verification |
| Legal Framework | eIDAS 2.0, Swiss E-ID | Emerging | ✅ Strong | Government-backed digital IDs |
| Identity Sharing | Verifiable Credentials (VCs) | Emerging | ✅ Strong | Share only necessary attributes |
| Identifier Format | DIDs (Decentralized Identifiers) | Emerging | ✅ Strong | Unique, user-owned identifiers |
| Age / KYC Claims | ZK-Proofs of Identity | Emerging | ✅ Strong | Prove facts without exposing data |
Authentication
| 🔐 Use Case | 📦 Technology / Standard | 🚀 Type | 🔒 Security Level | 📝 Notes |
|---|---|---|---|---|
| Auth Factor | Password + SMS OTP | Traditional | ⚠️ Medium | Weak against phishing & SIM swap |
| Auth Factor | App-based OTP / Push TAN | Traditional | ✅ Medium | Better UX, but still phishable |
| Phishing-resistant Login | FIDO2 / WebAuthn | Modern | ✅✅ Very Strong | Biometric or PIN with device key |
| Passwordless Login | Passkeys | Modern | ✅✅ Very Strong | Cross-device sync, biometric-first |
| Biometric Factor | Fingerprint, Face ID | Modern | ✅ Strong | Depends on local hardware security |
| Auth Layer for VCs | OIDC4VP / SIOP | Emerging | ✅ Strong | Uses OpenID to carry VCs for login |
Device Trust & Activation
| 🔐 Use Case | 📦 Technology / Standard | 🚀 Type | 🔒 Security Level | 📝 Notes |
|---|---|---|---|---|
| Device Binding | Device fingerprinting | Traditional | ⚠️ Medium | Spoofable, privacy risks |
| Device Binding | QR pairing + signature | Modern | ✅ Strong | Authenticated and user-initiated |
| Device Binding | WebAuthn / FIDO key-pair | Modern | ✅✅ Very Strong | Bound to secure enclave |
| Device Security | Trusted Execution Environment (TEE) | Emerging | ✅✅ Very Strong | Hardware-based secure key store |
| Device Trust | Mobile Threat Defense (MTD) | Emerging | ✅ Strong | Detects jailbroken or risky devices |
| Activation Recovery | Email/SMS fallback | Traditional | ⚠️ Weak | Prone to takeover |
| Activation Recovery | WebAuthn backup keys | Modern | ✅ Strong | Non-phishable, device-based |
Secure Data & Credential Exchange
| 🔐 Use Case | 📦 Technology / Standard | 🚀 Type | 🔒 Security Level | 📝 Notes |
|---|---|---|---|---|
| Credential Sharing | Email, paper PDF IDs | Traditional | ⚠️ Weak | No authenticity guarantees |
| Credential Exchange | Verifiable Credentials (VC) | Modern | ✅ Strong | Cryptographically signed |
| Interoperable Exchange | OIDC4VP, WACI | Emerging | ✅ Strong | Bridges SSI with OpenID/OAuth |
| Wallet Interaction | CHAPI (Credential Handler API) | Emerging | ✅ Strong | UX layer for browser/SSI |
| Consent Tracking | Consent Receipts (MyData, Kantara) | Emerging | ✅ Strong | Ensures compliance, transparency |
| Credential Minimization | ZKP (Zero-Knowledge Proofs) | Emerging | ✅ Strong | Prevents over-disclosure |
| Encrypted Computation | Homomorphic Encryption | Experimental | ⚠️ Medium | Not yet practical at scale |
Privacy, Security & Compliance Enhancements
| 🔐 Use Case | 📦 Technology / Standard | 🚀 Type | 🔒 Security Level | 📝 Notes |
|---|---|---|---|---|
| Communication Security | TLS 1.2 / 1.3, HTTPS | Standard | ✅ Strong | TLS 1.3 offers better security & speed |
| Certificate Trust | Certificate Pinning | Standard | ✅ Strong | Prevents MITM via rogue CAs |
| User Behavior Risk Scoring | Behavioral Biometrics | Emerging | ✅ Strong | Adds invisible auth layer |
| Privacy-respecting tracking | Privacy-preserving Fingerprinting | Emerging | ✅ Medium | Avoids tracking by obfuscation |
| Identity Governance | EU eIDAS 2.0, Swiss E-ID Law | Regulation | ✅ Strong | Legal, cross-border trust frameworks |
