FortAuth · Passwordless authentication

Passwordless today, quantum-ready for tomorrow.

Passwordless authentication for banks and financial institutions, built on FIDO2 passkeys. Nothing to phish, nothing to leak, and ready for post-quantum signatures as FIDO2 adopts them.

As post-quantum signature algorithms come to FIDO2, passkeys will stay unforgeable even against a quantum computer, and a crypto-agile design means adopting them is a rollout, not a rebuild.

Face ID

Fingerprint

Device PIN

Screen pattern

fortanixorSearchAlex MorganACME CORPAM

Dashboard

FortAuth: Sign-ins that can't be phished.

A password is something an attacker can take from you. A device-bound passkey is not: the private half never leaves the handset, so there is nothing to intercept, reuse or leak — and getting in takes one touch.

What changes once the password is gone

What your engineers build against, what your customers actually do at the sign-in screen, and what is left for an attacker to work with.

Fits the stack you already run

Swift, Kotlin, Java, React, Angular and Flutter each get a native SDK, and everything underneath them is a documented REST API. Teams generally have a working passwordless flow the same afternoon they start.

A native SDK per platform

JSTSJSTS

Every platform your customers carry

A separate credential on each handset, Apple through Huawei

FIDO2

Phishing-resistant

Origin-bound · by design

Passwords to steal

There is nothing to phish, guess or leak. Every key is device-bound and never shared with the server.

The unlock never leaves the handset

A face, a fingerprint, a PIN or a pattern releases the key locally. The biometric itself is never transmitted; your server receives a signature and checks it.

Face IDFingerprintPINPattern

Verification speed

One tap, no waiting

No codes and no resets. A passkey sign-in finishes in well under a second.

<1s

Certified & compliant

FIDO2 certified, independently

Certified by the FIDO Alliance against the authentication standard banks and regulators reference.

FIDO2 Certified

Crypto-agile by architecture

Crypto-agile today, post-quantum next

Passkeys sign with ECDSA today. As FIDO2 adopts post-quantum signature algorithms, starting most likely with NIST’s ML-DSA, a crypto-agile design lets us take them up as the spec and the authenticators support them, without re-architecting your integration. Signatures are not exposed to harvest-now-decrypt-later, so what matters is being able to move before a cryptographically-relevant quantum computer exists.

FIDO2 passkeys on a crypto-agile design, ready to adopt post-quantum signatures as FIDO2 standardises them.

Crypto-agileML-DSA roadmapStandards-trackingQ-Day prepared

Q-Day

prepared

One tap on the phone. A whole handshake behind it.

9:41

Welcome back

alex@company.com

Continue with Google

Continue with Microsoft

Secured by Fortanixor

Scroll to explore

Device fingerprinting

Each device is given a unique ID and recognised by it every time you sign in.

3-D Secure

Debit Card

1234567890123456

Alex MorganVALID
THRU09/32

Approve the transaction with your passkey instead of an OTP.

Approve on your phone

FortAuthnowApprove sign inMacBook Pro · Chrome · 2 min ago

A sign in started on another device waits here for your approval.

QR based login

Scan with your phone to withdraw. No card or PIN needed.

Device access

Trust the person. Verify the device.

The passkey ties every sign-in to specific hardware and the person holding it. On top of that, FortAuth hardens the client itself. It fingerprints the device, locks down the screen and watches the network, so a stolen credential has nowhere to run.

Passwordless

Nothing to phish. Nothing to leak.

Passwords, OTPs, and push prompts all share one flaw: a secret that travels and can be intercepted, reused, or fatigued into approval. FortAuth passkeys replace them with FIDO2 public-key credentials that stay bound to the device and the real site.

// the options your server returns - spec

// field names only, no wrapper, no vendor key

{

"challenge": "9WqE4h1tKf0v2Nx7bQ",

"rpId": "example.com",

"userVerification": "required",

"timeout": 60000,

"allowCredentials": [

{

"type": "public-key",

"id": "AY5kQ2r8...T1c",

"transports": ["internal", "hybrid"]

}

]

}

// hand it straight to the browser

const credential =

await navigator.credentials.get({

publicKey: options,

});

// what comes back is spec-shaped too

{

"id": "AY5kQ2r8...T1c",

"response": {

"authenticatorData": "SZYN5Y...",

"clientDataJSON": "eyJ0eXBl...",

"signature": "MEUCIQD..."

},

"type": "public-key"

}

// the options your server returns - spec

// field names only, no wrapper, no vendor key

{

"challenge": "9WqE4h1tKf0v2Nx7bQ",

"rpId": "example.com",

"userVerification": "required",

"timeout": 60000,

"allowCredentials": [

{

"type": "public-key",

"id": "AY5kQ2r8...T1c",

"transports": ["internal", "hybrid"]

}

]

}

// hand it straight to the browser

const credential =

await navigator.credentials.get({

publicKey: options,

});

// what comes back is spec-shaped too

{

"id": "AY5kQ2r8...T1c",

"response": {

"authenticatorData": "SZYN5Y...",

"clientDataJSON": "eyJ0eXBl...",

"signature": "MEUCIQD..."

},

"type": "public-key"

}

// 1 - begin the assertion

const options = await api.post(

"/assertion/options", { userId }

);

const assertion =

await navigator.credentials.get({

publicKey: options,

});

// 2 - verify it

const { session } = await api.post(

"/assertion/result", assertion

);

// that is the whole ceremony - no hosted

// page, no callback URL, no redirect

req.session.user = session.user;

// registration is the same two calls

const opts = await api.post(

"/attestation/options"

);

const cred =

await navigator.credentials.create({

publicKey: opts,

});

await api.post("/attestation/result", cred);

// 1 - begin the assertion

const options = await api.post(

"/assertion/options", { userId }

);

const assertion =

await navigator.credentials.get({

publicKey: options,

});

// 2 - verify it

const { session } = await api.post(

"/assertion/result", assertion

);

// that is the whole ceremony - no hosted

// page, no callback URL, no redirect

req.session.user = session.user;

// registration is the same two calls

const opts = await api.post(

"/attestation/options"

);

const cred =

await navigator.credentials.create({

publicKey: opts,

});

await api.post("/attestation/result", cred);

// one credential, one rpId, four surfaces

const rpId = "example.com";

// web and mobile app: the same assertion

await navigator.credentials.get({

publicKey: options,

});

// cardless ATM: the phone answers for the

// machine, over cross-device transport

options.allowCredentials[0]

.transports = ["hybrid"];

// payment step-up: SPC binds amount and

// payee into what gets signed - the

// dynamic linking SCA asks for

await new PaymentRequest([{

supportedMethods:

"secure-payment-confirmation",

data: {

rpId,

credentialIds: [credentialId],

challenge,

payeeName: "ACME Ltd",

instrument: {

displayName: "Visa ...4821",

},

}], {

total: {

amount: {

currency: "AED",

value: "420.00",

},

}]).show();

// wire it once. a new surface is a client

// call, not another project.

// one credential, one rpId, four surfaces

const rpId = "example.com";

// web and mobile app: the same assertion

await navigator.credentials.get({

publicKey: options,

});

// cardless ATM: the phone answers for the

// machine, over cross-device transport

options.allowCredentials[0]

.transports = ["hybrid"];

// payment step-up: SPC binds amount and

// payee into what gets signed - the

// dynamic linking SCA asks for

await new PaymentRequest([{

supportedMethods:

"secure-payment-confirmation",

data: {

rpId,

credentialIds: [credentialId],

challenge,

payeeName: "ACME Ltd",

instrument: {

displayName: "Visa ...4821",

},

}], {

total: {

amount: {

currency: "AED",

value: "420.00",

},

}]).show();

// wire it once. a new surface is a client

// call, not another project.

// a virtual authenticator, so CI needs no

// hardware and no hands on a phone

await cdp.send("WebAuthn.enable");

const { authenticatorId } = await cdp.send(

"WebAuthn.addVirtualAuthenticator", {

options: {

protocol: "ctap2",

transport: "internal",

hasUserVerification: true,

isUserVerified: true,

},

}

);

await signIn(page, "alex@company.com");

// every ceremony lands in the event log

// with the reason it passed or failed

expect(await lastCeremony()).toMatchObject({

status: "ok",

userVerified: true,

origin: "https://example.com",

counter: 41,

});

// a virtual authenticator, so CI needs no

// hardware and no hands on a phone

await cdp.send("WebAuthn.enable");

const { authenticatorId } = await cdp.send(

"WebAuthn.addVirtualAuthenticator", {

options: {

protocol: "ctap2",

transport: "internal",

hasUserVerification: true,

isUserVerified: true,

},

}

);

await signIn(page, "alex@company.com");

// every ceremony lands in the event log

// with the reason it passed or failed

expect(await lastCeremony()).toMatchObject({

status: "ok",

userVerified: true,

origin: "https://example.com",

counter: 41,

});

Built for developers

Drop it in. Ship it this sprint.

FortAuth speaks FIDO2 and OIDC on the wire, so it plugs into the stack you already run. Add a couple of calls to the login screen you have, keep your identity provider, and roll passwordless out one app at a time.

Who it's for

Built for the people who own the problem.

FortAuth is bought by three groups inside a bank, exchange house, fintech or other regulated institution — usually for three different reasons. These are the ones we hear.

Heads of Digital Banking, CIOs and CISOs

Replacing SMS OTP and passwords across customer channels — mobile, web, ATM and 3-D Secure — without a separate rollout for each one.

Fraud teams

Facing OTP interception, SIM swap and phishing kits that replay one-time codes in real time. A device-bound passkey has no code to intercept.

Compliance teams

Mapping authentication controls to SAMA, SBP and the Gulf regulators' strong-customer-authentication expectations, with evidence they can hand to an auditor.

Compliance and security

What your auditors will ask about.

Passkeys are possession plus inherence in one gesture: a private key bound to the customer's device, unlocked by their biometric or PIN. That is the shape most strong-customer-authentication rules are asking for, and it is what the mappings below set out control by control.

Strong customer authentication

Two independent factors, one gesture

Possession — the device holds the private key
Inherence — a biometric or PIN unlocks it
No shared secret held server-side to breach

On every sign-in and every payment

FIDO2 certified

Certified by the FIDO Alliance against the published specification

Certified by the FIDO Alliance
Tested against the published specification

FIDO Alliance certified

Phishing resistance

Credentials scoped to your origin

A lookalike domain collects nothing usable
Nothing to replay and nothing to intercept
The failure mode that defeats one-time codes

Phishing-resistant by design

Audit evidence

A record for every authentication

Which authenticator, and its device binding
Which verification method the customer used
Exportable for supervisory review

Ready for the question an auditor asks

Data residency

On-premiseIn-region cloudHybrid

Control mappings

SAMA SBP CBUAE QCB CBJ Bangladesh Bank BDDK

Questions

FortAuth questions, answered.

Yes. A passkey covers both factors a one-time code was standing in for — the device is the possession factor, the biometric or PIN that unlocks it is the inherence factor — so the SMS leg can be retired rather than layered on top. Most banks run the two in parallel during migration and switch cohorts over as enrolment builds, which also removes the per-message cost and the delivery failures that come with it.

Both. At the ATM the customer approves a signed challenge on their phone instead of entering a PIN into the machine, and for 3-D Secure the passkey satisfies the issuer's authentication step in the same gesture the customer already uses to unlock their phone. The same credential and the same enrolment cover mobile, web, ATM and 3DS — there is no separate rollout per channel.

A passkey presents two independent factors in a single gesture, which is the structure strong-customer-authentication rules describe. We publish control-by-control mappings for SAMA, SBP, CBUAE, QCB, CBJ, Bangladesh Bank and BDDK so your compliance team can check the wording against their own reading rather than take ours — and we expect them to, since the supervisory interpretation is the bank's to make.

The private key is generated in the device's secure element or keystore and cannot be exported from it. What leaves the device is a signature over a challenge — never the key, never a password, and never anything that can be replayed against another site. Server-side there is only a public key, which is of no use to an attacker who steals it.

For a single channel, most teams are through a working integration in days rather than weeks: the SDK handles enrolment and the WebAuthn ceremony, and the bank's side is an API call at sign-in and a fallback path. The longer part is never the code — it is enrolment strategy, cohort selection and the support playbook for customers who change or lose a device.

Book a demo

See passkeys in your own sign-in flow.

Bring your current authentication journey and we'll show you where the passkey replaces the password and the OTP — and what the migration looks like for customers who are mid-enrolment.

Book a demo Get the passkey rollout guide for banks →