01
Where customers abandon enrollment
At the top of a funnel you are talking to somebody who has decided nothing yet. Asking that person to compose a secret, satisfy a rule about its contents and then find somewhere safe to keep it is the first moment in the flow that demands work rather than interest, and measured drop-off gathers exactly there.
The common workaround is a code mailed on every visit. That removes the memory problem and installs a wait in its place, on every subsequent sign-in, and the code remains phishable in the ordinary way.
New accounts inherit old passwords
Whatever the customer types is probably in use on three other services already, so the account opens exposed to a breach that happened somewhere else last year.
Email codes add friction to every return visit
The friction moves from sign-up to every visit afterwards, which is the worse place to put it, and the wait is measured in inbox latency you do not control.
Recovery adds work before launch
Choosing a password commits you to reset flows, rate limits, mailbox trust and a support queue, all of which must exist before the first customer forgets anything.
02
Two doors into enrollment
Which door you open depends on what you already hold. Where a verified photo exists, in a KYC file, a membership record or an onboarding pack, tokens are minted in bulk and coverage exists before any customer does anything at all.
Where it does not, self-signup is turned on for a specific application, restricted to email domains you approve, and pointed at a group that is closed by default, so a new account holds no access until it is placed deliberately.
Both doors finish in the same state. The image itself is short-lived: a firewalled minting service holds it in memory only for as long as minting takes, and it is never written to a disk, a database or a log.
Minted in bulk from records you already hold
Import the list and the tokens come out of the import. There is no enrollment campaign to schedule and no month afterwards spent chasing whoever ignored it.
Self-signup behind a domain allow-list
Enable it for one application, admit only the email domains you name, and place every new account in a group scoped in advance. The gate is closed by default at sign-in rather than applied as a filter afterwards.
Pending accounts await enrollment
A user created ahead of a usable photo waits in a pending state and comes alive at the first ceremony, so provisioning from your own systems never blocks on an image.
A replaced photo is verified
Updating a photo mints a new token only when the new image is biometrically the same person, which closes the obvious route to a quiet account takeover through a profile edit.
03
Bind the phone once, then nothing to remember
Registration is not a second errand. Nothing arrives asking the customer to choose a credential, and no activation link has to be dug out of a spam folder. The companion app is installed, the phone is bound once against a one-time PIN delivered to the mailbox on the account, and from that point the sign-in is a look at the camera.
The device the customer is actually using stays out of it. A laptop browser shows a code, a kiosk shows a code, a phone browser shows a code, and none of them are enrolled, provisioned or trusted with anything.
The PIN has exactly one job
It belongs to the device binding and appears nowhere else in the customer's life. That is a rule you can publish in your own security guidance without qualifications or exceptions attached to it.
Passkeys where the requirement is phishing resistance
Enabling the passkey path gives the customer a real FIDO2/WebAuthn credential produced on their phone after the face check and bound to your origin.
Integrate through standard identity protocols
Sign-up and sign-in travel over OpenID Connect and OAuth 2.0 with PKCE and pushed authorization requests. Accounts arriving from another system come in over SCIM 2.0.
04
What you can tell your privacy reviewer
The reviewer will ask what is stored, and the answer should be precise rather than merely reassuring. IdP retains quantum-safe, sealed, biometric-free, disposable face tokens and their verifier challenges. Standard OIDC/SAML account records, device public keys, sessions, logs and encrypted tenant signing keys also persist. No face images or templates are retained in the documented phone flow. Licensed on-premises Webcam processes captures inside the customer deployment.
The retained face token is quantum-safe, sealed, biometric-free and disposable. No face images or templates are retained in the documented phone flow. Tokens are tenant-bound and stored alongside the required account records. ISO/IEC 24745:2022 names those properties, irreversibility, unlinkability and renewability, and they are the design target rather than a description written after the fact.
The consent question stays with you. Using a photo you already hold as an authentication factor is a purpose your privacy notice has to cover, and in several jurisdictions it requires explicit consent before the first token is minted.
05
What it costs when a customer goes quiet
Consumer populations are mostly dormant, which is why the shape of the bill matters more than the headline rate. Accounts outside your organization are counted after the fact, by the month, and only when the person actually signed in. A quiet account is not a line item.
Against a floor of 20 seats, the list rate is a dollar for each user in a month. Two things sit outside it. A signing key held as a non-exportable key in a managed key service, where the key cannot be copied out by anyone, including us, is twenty dollars monthly for that key. Tenants and custom domains are free for the first three, then ten dollars each per month. Evaluation runs for 30 days with no card required, which is long enough to put the flow in front of a live funnel before anyone commits a budget line.
06
Frequently asked questions
What does passwordless onboarding mean here?
No credential is ever chosen. The account is minted from a photo already in your records, or opened through a gated self-signup, and what would have been the set-a-password step is instead the customer's first face ceremony on their own phone.
What if we hold no photo of the customer?
Use self-signup, restricted to email domains you approve, with new accounts landing in a group that is closed by default. The customer supplies the enrollment capture themselves and the account activates at the first ceremony.
Do customers have to install an app?
Yes. The companion app on the customer's phone is where the face check runs. The laptop, tablet or kiosk they are signing in on needs nothing installed and holds no enrollment.
Is a face login at sign-up the same as identity verification?
No. It confirms that the live person matches the enrollment on that account. It is not KYC, not document verification and not age estimation, and those steps, where you need them, sit upstream of enrollment.
How do developers wire it up?
As a standard identity provider: OpenID Connect and OAuth 2.0 with PKCE and pushed authorization requests, SAML 2.0 where an application prefers it, and SCIM 2.0 for provisioning. The redirect, the code exchange and the token validation are the ones your team has written before.
Do dormant accounts cost anything?
Accounts outside your organization are counted after the fact, by the month, and only when the person signed in. An account that stayed quiet does not appear on the invoice.