nextAuth: bank-grade authentication, built into your own app

nextAuth is the cryptographic engine inside itsme^®, opened up to the market. It is a mobile-first authentication and transaction-signing component that you embed inside your own app. NextAuth turns the user’s phone into a secure login and signing device using device-bound, public-key cryptography. You ship our SDK in your mobile app and run our server on your own infrastructure or cloud, with REST integration into the rest of your stack.

nextAuth does not provide identity data. The solution proves that ‘this device/user performed this action’, not who the person is. Identity (KYC, eID) is a separate layer. itsme^® handles that layer.

nextAuth is built for organisations whose users perform high-value or high-frequency actions inside your mobile app, where passwords, SMS OTP, push approvals, and hardware tokens fall short due to cost, user experience, security, or a combination of both.

Here’s where nextAuth makes the difference with the aforementioned:

• For end users, nextAuth offers the best UX alongside high-level security, with a smooth biometric login and fallback to PIN.
• For product owners, nextAuth replaces per-message OTP and per-token cost with a predictable model based on user count, not login or transaction volume.
• For legal and compliance, nextAuth offers true non-repudiation. Every login and signature is based on cryptographic signatures from private keys that never leave the device and are independently verifiable by a third party. The user can’t credibly deny it and the platform can’t fabricate it.
• For risk and audit teams, the solution provides evidence-grade actions. Signatures are eIDAS-aligned and court-admissible. The second-factor verification is Common Criteria EAL3+ certified.
• For CTOs and architects, it means retaining ownership of the authentication layer. There’s no need to build a solution from scratch, nor to hand it over to a third party.

nextAuth is built to evidentiary standards, not just security standards. The solutions combines the following layers to achieve this:

• Device-bound public-key cryptography. Private keys are generated and stored on the user’s phone.
• Patented True MFA™ (zero-knowledge). The private key stays on the device; the server holds only the public counterpart. Neither side, on its own, is enough to impersonate the user.
• Non-repudiation by construction. No shared secret to protect server-side: only the SDK on the user’s phone holds the signing key. Signatures are independently verifiable, court-admissible , and let auditors trace a specific action to a specific device at a specific time.
• Encrypted channels. Push notifications and app-to-backend communication are wrapped in an additional encryption layer.
• Independent certification. nextAuth carries Common Criteria EAL3+ certification from an external evaluator, and is the core cryptographic solution behind itsme, the identity layer trusted by Belgian banks, government, and regulated industries.
• PQC roadmap. Our roadmap includes migrating signature schemes once NIST/ENISA standards and library implementations are mature enough to deploy responsibly. nextAuth’s architecture is crypto-agile, meaning algorithms can easily be swapped. In the meantime, the 'harvest now, decrypt later' threat that drives PQC urgency in encryption does not apply in the same way to authentication signatures: a captured signature has no value once the action it authorised is completed.

You decide. The nextAuth server runs on your own infrastructure, on-premise or in your own cloud tenant (AWS, Azure, GCP, or a sovereign European cloud). The mobile SDK lives inside your app. The private keys live on your end users’ phones. Authentication data does not flow through a nextAuth-operated cloud.

That also means:

• Full data sovereignty. Authentication patterns, identifiers, signature events, and audit logs stay inside your perimeter and your jurisdiction. This is relevant for GDPR, NIS2, sector data-residency rules, and the EU’s wider digital-sovereignty push.
• No third-party processor on a critical layer. Nothing to add to your DPIA. No third-party outage, breach, or sub-processor chain to inherit.
• No cross-border transfer questions. Data doesn’t leave your infrastructure, so you don’t have to worry about Schrems II / CLOUD Act.
• Your logs, your retention. You define what is logged, how long it’s kept, and who can query it. 

Because nextAuth is a component and not a rebuild, standard integration paths (REST) slot neatly into existing IdP and session layers. That makes nextAuth easier to integrate than many alternatives.

A high-level view on the actual steps you’ll need to take:

• Embed the mobile SDK (iOS and Android) in your app for enrolment, authentication, and signing.
• Deploy the nextAuth server on your infrastructure or cloud. REST API.
• Wire it into your flows, i.e. login, transaction approval, e-signature, web login via QR (the SD Worx pattern), and any backend calls that need a signed authorisation.

To justify a nextAuth integration, you need to have a mobile app and enough transaction volume. For one-off, low-frequency interactions, an external IdP like itsme^® is the better fit.